Repository navigation
fix(strix): break contextual-orchestrator sidecar bootstrap deadlock #1399
Description
Activity
Fresh owner-path evidence: shared trusted sidecar now fails at 413/preflight on exact protected source
New exact evidence shows the bootstrap deadlock has moved beyond the original
stream_options.include_usage=truesymptom and now blocks both Required Noema Review and required Strix through the same protected trusted-sidecar boundary.Protected authority / target identity
- central protected source:
.github/main@86fe907b6732a20aaa17260701687c0267e275a3(GitHub-verified); - consumer under validation:
.github#897, base86fe907b6732a20aaa17260701687c0267e275a3, exact headd240ba4657300bb7e127fa0b539516a9a48cee4a; - trusted sidecar script in both paths vendors
ContextualWisdomLab/contextual-orchestrator@b21645116b352967e50fc497b87eb745b9cc8c61rather than target-PR code, preserving the credential boundary.
Required Noema Review reproduction
- run
33250134550, attempt 2, job99100874276; - trusted source materialization, repository-scoped GitHub App token mint, and target visibility all succeed;
Provision contextual-orchestrator review sidecarfails;- after hash-pinned dependency installation, the shared bootstrap reports
request_failed status=413 code=request_too_large, thenusing live OpenRouter ZDR endpoint feed, starts127.0.0.1:18080, and exits before healthz withreview sidecar preflight failed; - the LLM review step is skipped, so there is no reviewer verdict to treat as source evidence.
Required Strix reproduction
- repository-dispatch run
33250300490, job99100893968; - exact live PR metadata is validated, exact base/head are fetched, and the Strix required-workflow smoke test passes;
Provision contextual-orchestrator Strix sidecarthen vendors the sameb2164511...pin and fails after the samerequest_failed status=413 code=request_too_largeboundary;- the sidecar starts but exits before healthz with
sidecar emitted an unexpected exception;Run Strix (quick)is skipped, so no vulnerability verdict exists. The workflow correctly remains non-passing rather than manufacturing scan success.
First causal boundary
The common failure is the protected central trusted-sidecar bootstrap/preflight around the pinned contextual-orchestrator, before either Noema Review or Strix can execute. It is not evidence that #897's Dependency Review source repair is defective. No correct Noema-local or #897-leaf product-code workaround exists.Owner repair / RED-GREEN acceptance
- Add a realistic regression in the existing central owner lane that reproduces the current
413 request_too_large/ preflight failure using the trustedb2164511...path and bounded provider-endpoint/preflight inputs. - Identify which bounded bootstrap payload or endpoint-feed material crosses the receiving size contract; repair that owning trusted boundary (for example bounded/truncated/normalized preflight material, or a normally integrated trusted pin once the dedicated contextual-orchestrator owner makes it authoritative). Do not execute arbitrary target-PR gateway code with
NVIDIA_NIM_API_KEY, weaken Strix/Noema Review, convert provider/bootstrap failure to success, or accept predecessor/model-only evidence. - GREEN must prove on one unchanged exact owner state that Required Noema Review for
.github#897@d240ba4657300bb7e127fa0b539516a9a48cee4areaches a real terminal review verdict and required Strix for that same exact head reaches a real terminal vulnerability verdict. Exact source/head/live-base identities must remain machine-verifiable; skipped/neutral/synthetic/provider-unavailable results remain non-passing. - After protected integration, regenerate the then-current
ContextualWisdomLab/noema#500exact-head/live-base Security/OIDC canary; no predecessor Noema evidence transfers.
This is owner-path evidence only. No central or contextual-orchestrator source/ref/workflow/branch/PR-source state was mutated from the Noema writer.
- central protected source:
Fresh cross-gate consumer canary from Orgmetra #149 shows the shared trusted review-sidecar bootstrap is now failing Noema before
/healthz, not only Strix.- consumer:
ContextualWisdomLab/Orgmetra#149 - exact target head:
44c83128701f1985f8566b39cbf837c7b20f0111 - exact live base:
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - Required Noema run/job:
33257526054/99113733567 - trusted central workflow SHA:
6c8ee24046d743b3981c566c6e29f99f09137f6a - shared script:
scripts/ci/contextual_orchestrator_review_sidecar.sh - pinned contextual-orchestrator:
b21645116b352967e50fc497b87eb745b9cc8c61
First causal boundary: trusted-source materialization, repository-scoped Noema App token, repository visibility, and all five configured provider credentials succeed. During sidecar provisioning the OpenRouter endpoint feed first returns
413 request_too_large, then the live ZDR feed is selected; the sidecar starts on127.0.0.1:18080but exits status 1 before/healthzwithreview sidecar preflight failed. The actual Noema review/verdict step is therefore skipped. This is not an Orgmetra source/test failure and no Noema verdict exists for the head.Acceptance canary: without changing Orgmetra head
44c8312…, the trusted sidecar must reach healthy/healthz, Noema must execute against that exact target/base, and the required workflow must publish a real terminal review verdict. Provider/bootstrap failure, skipped review, synthetic evidence, or predecessor-head evidence remains non-passing. Please keep the existing secret boundary; do not execute untrusted target code with reviewer/provider credentials.- consumer:
Fresh shared-sidecar canary from
ContextualWisdomLab/Orgmetra#48reproduces the current Noema bootstrap failure on an unchanged product head.- target head:
9eab9d50ae0a202f4c3398ae60fba726c60ccb67 - live base:
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - Required Noema run/job:
33260305322/99121013039 - trusted central workflow SHA:
6c8ee24046d743b3981c566c6e29f99f09137f6a - shared sidecar pins
contextual-orchestrator@b21645116b352967e50fc497b87eb745b9cc8c61
Trusted-source materialization, repository-scoped Noema App token, target visibility, and five provider credentials all succeed. Sidecar provisioning then logs
request_failed status=413 code=request_too_large, selects the live OpenRouter ZDR endpoint feed, starts on127.0.0.1:18080, and exits status 1 before/healthzwithreview sidecar preflight failed. The actual Noema LLM review is skipped, so no authoritative review verdict exists.This is the same protected shared-sidecar causal boundary already owned here, not an Orgmetra source failure. Acceptance on unchanged/current #48 requires healthy
/healthzfollowed by a real exact-head Noema terminal verdict; bootstrap/provider failure, skipped review, synthetic output, or predecessor evidence remains non-passing. No foreign source/ref/workflow state was changed from the Orgmetra lane.- target head:
Fresh Strix canary from
ContextualWisdomLab/Orgmetra#48advances the shared-sidecar causal boundary beyond/healthzon the same exact product head.- target head:
9eab9d50ae0a202f4c3398ae60fba726c60ccb67 - live base:
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - Required Strix run/job:
33260305384/99121050020 - trusted central workflow SHA:
6c8ee24046d743b3981c566c6e29f99f09137f6a - contextual-orchestrator pin:
b21645116b352967e50fc497b87eb745b9cc8c61
Exact target/base materialization, workflow smoke, token/visibility checks and five provider credentials succeed. Endpoint-feed retrieval first logs
413 request_too_large, then selects the live OpenRouter ZDR feed. Unlike the sibling Noema canary, this Strix attempt reacheshealthz and provider-route preflight confirmed after 11s(pid 7224), but the subsequent gateway preflight request receives zero bytes and times out after 30,001 ms; the sidecar is stopped and pinned Strix installation/analysis are skipped. No authoritative vulnerability finding/no-finding report exists.Diagnostic-only
strix-reportsartifact: id9717135488, 12,251 bytes, SHA-256bfdd676e50e1fdb13423d3782f20f8069af85c12a52b90cb193941c3fb85f328.Acceptance canary: on the unchanged/current Orgmetra #48 head, the shared sidecar must pass
/healthzAND complete the bounded gateway/provider-route preflight, after which pinned Strix must actually run and produce an authoritative exact-head report. Health-only success, gateway timeout, skipped analysis, diagnostic artifact, or predecessor evidence remains non-passing. No foreign source/ref/workflow state was changed from the Orgmetra lane.- target head:
Fresh shared-sidecar consumer canary from Noema, not closure.
ContextualWisdomLab/Orgmetra#73remains at exact headacaebb70d777bf4aecbe64d0e71430c0ec0fefa3againstdevelop@9e3e4847510e1e612b48474ba42b177b8ed824df. Required Noema job99133254694materializes trusted central source6c8ee24046d743b3981c566c6e29f99f09137f6a, mints the repository-scoped Noema app token, resolves target visibility, sees all five provider secrets, and vendorscontextual-orchestrator@b21645116b352967e50fc497b87eb745b9cc8c61. OpenRouter's endpoint-feed request first returns 413, the live ZDR feed is selected, then the review sidecar starts on127.0.0.1:18080and exits status 1 before/healthzwithreview sidecar preflight failed(omitted_unstructured_lines=4). Thus no authoritative Noema verdict exists. This reproduces the shared trusted-sidecar bootstrap boundary on a non-contextual-orchestrator consumer; no correct Orgmetra-local fix exists. Acceptance for this consumer: without altering the Orgmetra head, the trusted sidecar must reach healthz and Noema must run to an authenticated terminal review verdict; provider/sidecar unavailability remains non-passing and reviewer credentials must remain outside target PR code.Fresh Orgmetra #152 exact-head canary, superseding the predecessor-head values in this existing Noema owner handoff.
- consumer:
ContextualWisdomLab/Orgmetra#152 - exact head/base:
44282cdb61269937f55bd1a69a106e948130d844/develop@9e3e4847510e1e612b48474ba42b177b8ed824df - Required Noema run/job:
33268072329/99141582057 - trusted-source resolution/materialization: GREEN
- repository-scoped reviewer credential/token and target visibility: GREEN
Provision contextual-orchestrator review sidecar: terminal FAILURE- actual
Run Noema LLM review and submit verdict: SKIPPED
The first causal boundary is still the shared trusted review-sidecar bootstrap before Noema executes; no Noema verdict exists for this exact head and there is no correct Position-history product-code repair for that control-plane failure.
Acceptance canary: on unchanged Orgmetra head
44282cdb…, the trusted sidecar must become healthy, Noema must actually execute against the exact target/base, and the required workflow must publish a real terminal current-head review verdict. Bootstrap/provider failure, skipped review, synthetic evidence, or predecessor evidence remains non-passing. Preserve the existing credential boundary; do not execute untrusted target code with reviewer/provider credentials.- consumer:
Fresh Orgmetra #42 exact-head Noema consumer canary; this advances the existing owner boundary only.
- consumer:
ContextualWisdomLab/Orgmetra#42 - protected live base:
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - exact contributor head:
f5d91b15ed20b243fc9a50ae3b529eac1ace4046 - Required Noema run:
33268617048 - job:
99143018696 - trusted central workflow SHA:
6c8ee24046d743b3981c566c6e29f99f09137f6a - contextual-orchestrator pin:
b21645116b352967e50fc497b87eb745b9cc8c61
Exact first causal boundary: trusted-source materialization, reviewer credential selection/mint, repository visibility resolution, and all prior setup passed. The shared
contextual_orchestrator_review_sidecar.shthen installed the hash-pinned orchestrator dependencies, received the known OpenRouter endpoint-feed HTTP 413 and selected the live ZDR feed, started the review sidecar on127.0.0.1:18080, then failed before/healthzwithsidecar exited before healthz (status 1); stderr: review sidecar preflight failed. The actual Noema LLM review/verdict step was skipped. This is before any Orgmetra source review and there is no Orgmetra-local root-cause repair.Acceptance for this exact consumer: after canonical owner repair, regenerate Required Noema on the then-current unchanged/successor #42 head and require the pinned shared sidecar to reach health, then execute the actual Noema review and submit a current-head authoritative verdict. A pre-health sidecar exit or skipped review remains non-passing; do not transfer predecessor evidence.
- consumer:
Fresh BandScope Strix canary: sidecar reaches healthz, then gateway preflight hangs
New exact consumer evidence narrows the shared trusted-sidecar failure one boundary later than the earlier pre-healthz reports in this issue.
- consumer:
ContextualWisdomLab/bandscope#970 - exact target head:
817cb56e4f8caf46fe76423b4160ad790d0957ca - exact live base:
develop@749511c3ad4000090048718f685c6bee6b3d2c25 - required Strix run/job:
33267512128/99140129196 - trusted central workflow SHA:
6c8ee24046d743b3981c566c6e29f99f09137f6a - shared sidecar script:
scripts/ci/contextual_orchestrator_review_sidecar.sh - pinned contextual-orchestrator:
b21645116b352967e50fc497b87eb745b9cc8c61
Exact sequence: target/base fetch and Strix workflow self-test succeed; all five provider credentials are present; sidecar setup logs
request_failed status=413 code=request_too_large, falls back to the live OpenRouter ZDR endpoint feed, starts on127.0.0.1:18080, and then reportshealthz and provider-route preflight confirmed after 22s. The next bounded gateway preflight request hangs for 30 seconds with zero bytes (curl: (28) Operation timed out after 30002 milliseconds with 0 bytes received) and the script terminates withgateway preflight request could not reach the local sidecar.Run Strix (quick)is therefore skipped and no authoritative vulnerability verdict exists.This falsifies the narrower hypothesis that the current failure is only sidecar startup/healthz readiness: on this consumer the trusted sidecar is alive and route-ready before the OpenAI-compatible gateway preflight stalls. There is no correct BandScope-local product-code workaround; weakening or synthesizing Strix evidence would violate the required fail-closed contract.
Acceptance extension for the existing owner lane: reproduce the post-healthz gateway-preflight hang against the trusted pinned sidecar, make that bounded request return an OpenAI-compatible terminal response (or a precise classified provider/fallback failure rather than hanging), preserve the credential boundary and fail-closed semantics, then rerun unchanged
bandscope#970@817cb56e...through actual Strix execution and produce structured authoritative exact-head scan evidence. Predecessor, skipped, neutral, timeout, or synthetic evidence remains non-passing.- consumer:
Orgmetra exact-current-head Noema canary — PR #59
bd1ac69ec5d3daa95387f0d7458e724897062ae3, live base9e3e4847510e1e612b48474ba42b177b8ed824df.Required Noema run
33272729947, job99154025444resolved/materialized trusted.githubsource6c8ee24046d743b3981c566c6e29f99f09137f6a, selected/minted the repository-scoped reviewer token, resolved the public target, and vendoredcontextual-orchestrator@b21645116b352967e50fc497b87eb745b9cc8c61. After the OpenRouter endpoint-feed request returned 413 and the live ZDR feed was selected, the shared sidecar started on127.0.0.1:18080but exited status 1 before/healthzwithreview sidecar preflight failed; Noema review/verdict was skipped.This is upstream of Orgmetra source analysis, so no correct consumer-local repair exists. Acceptance: unchanged consumer head/base reaches sidecar
/healthz, runs the bounded Noema review, posts an authoritative current-head verdict, and the required job terminates based on that verdict rather than bootstrap failure.Fresh Orgmetra exact-head Noema canary after the leaf-owned quality-trigger repair:
- consumer:
ContextualWisdomLab/Orgmetra#57 - exact head/base:
6ca554791595d925a76587378b543e7dbc3dc20b/develop@9e3e4847510e1e612b48474ba42b177b8ed824df - Required Noema run:
33279352311 - job:
99171739205 - trusted source materialization, reviewer credential selection, GitHub App token mint, and target visibility all succeed.
- first failing boundary:
Provision contextual-orchestrator review sidecar(step 9) fails;Run Noema LLM review and submit verdictis skipped.
No Noema finding/verdict exists for this consumer head, and there is no correct Orgmetra-local root repair before the shared sidecar boundary. Acceptance remains a healthy sidecar followed by an authoritative terminal Noema finding/no-finding verdict on the unchanged consumer head or a fresh equivalent canary.
- consumer:
Fresh unchanged-boundary consumer canary from
ContextualWisdomLab/Orgmetra#40; this advances the existing owner path only.- exact target head:
bd4d0cfad9e2e1c484f79087d80775a04afbf80b - exact live base:
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - Required Noema run/job:
33279862767/99173115585 - trusted central workflow SHA:
6c8ee24046d743b3981c566c6e29f99f09137f6a - pinned contextual-orchestrator:
b21645116b352967e50fc497b87eb745b9cc8c61
Trusted-source materialization, repository-scoped Noema App token mint, public target visibility, and all five provider credentials succeed. During
Provision contextual-orchestrator review sidecar, the endpoint feed returns413 request_too_large, the live OpenRouter ZDR feed is selected, the sidecar starts on127.0.0.1:18080, then exits status 1 before/healthzwithreview sidecar preflight failed. The actual Noema review/verdict step never executes. There is no Orgmetra-local source repair for this trusted shared sidecar boundary.GREEN acceptance for this consumer: on the unchanged/current exact Orgmetra head, the trusted sidecar must reach healthy
/healthz, the real Noema review must execute against exact target/base, and an authoritative terminal review verdict must be published. Provider/bootstrap failure, skipped review, synthetic/model-only output, or predecessor evidence remains non-passing.- exact target head:
Superseding Noema consumer canary for
ContextualWisdomLab/Orgmetra#40after the Orgmetra-owned Foundation hygiene repair advanced the branch.- exact target head:
bf8897affee31b494b490c8932c62bbf46a06cb4 - exact live base:
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - Required Noema run/job:
33280172790/99173896832 - trusted central workflow SHA:
6c8ee24046d743b3981c566c6e29f99f09137f6a - pinned contextual-orchestrator:
b21645116b352967e50fc497b87eb745b9cc8c61
Trusted-source materialization, repository-scoped cwl-noema-review App token, public target visibility, and all five provider credentials succeed. During the shared sidecar provision step the endpoint-feed request returns
413 request_too_large, the live OpenRouter ZDR feed is selected, the sidecar starts on127.0.0.1:18080, then exits status 1 before/healthzwithreview sidecar preflight failed. The actual Noema review/verdict step never executes. The predecessorbd4d0cf...canary is stale and must not transfer.No Orgmetra-local product repair exists for this trusted shared sidecar bootstrap boundary. GREEN acceptance remains: on the unchanged/current exact Orgmetra head, sidecar
/healthzmust succeed, the real Noema review must execute against exact target/base, and an authoritative terminal verdict must be published. Bootstrap/provider failure, skipped review, synthetic/model-only, or predecessor evidence remains non-passing.- exact target head:
Fresh exact-head Noema consumer canary from
ContextualWisdomLab/Orgmetra#46; existing owner path only.- exact target head:
15d534fc8e36d3455523cf5d8e22e77010fc9d4b - exact live base:
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - Required Noema run/job:
33278974481/99170747871 - trusted central workflow SHA:
6c8ee24046d743b3981c566c6e29f99f09137f6a - pinned contextual-orchestrator:
b21645116b352967e50fc497b87eb745b9cc8c61
Trusted-source materialization, repository-scoped cwl-noema-review App token, public target visibility, and all five provider credentials succeed. During shared sidecar provisioning the endpoint-feed request returns
413 request_too_large, the live OpenRouter ZDR feed is selected, the sidecar starts on127.0.0.1:18080, then exits status 1 before/healthzwithreview sidecar preflight failed. The actual Noema review/verdict never executes.No Orgmetra-local Employment Separation source repair exists for this trusted shared sidecar bootstrap boundary. GREEN acceptance remains sidecar health on the unchanged/current exact consumer head followed by a real Noema review against exact target/base and an authoritative terminal verdict. Bootstrap/provider failure, skipped review, synthetic/model-only, or predecessor evidence remains non-passing.
- exact target head:
Fresh exact-head Noema consumer canary from
ContextualWisdomLab/Orgmetra#48; existing owner path only.- exact target head:
b9e487cc1e07267ff69d222b0917ec108804b799 - exact live base:
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - Required Noema run/job:
33279023408/99170871640 - trusted central workflow SHA:
6c8ee24046d743b3981c566c6e29f99f09137f6a - pinned contextual-orchestrator:
b21645116b352967e50fc497b87eb745b9cc8c61
Trusted-source materialization, repository-scoped cwl-noema-review token, public target visibility, and all five provider credentials succeed. During shared sidecar provisioning the endpoint-feed request returns
413 request_too_large, the live OpenRouter ZDR feed is selected, the sidecar starts on127.0.0.1:18080, then exits status 1 before/healthzwithreview sidecar preflight failed. The actual Noema review/verdict never executes.No compensation-review/Orgmetra product-source repair exists for this trusted shared sidecar bootstrap boundary. GREEN acceptance remains sidecar health on the unchanged/current exact consumer head followed by a real Noema review against exact target/base and an authoritative terminal verdict. Bootstrap/provider failure, skipped review, synthetic/model-only, or predecessor evidence remains non-passing.
- exact target head:
Fresh downstream Strix canary from
ContextualWisdomLab/bandscope#1072narrows the shared trusted-sidecar failure beyond startup on an unchanged product head.- BandScope exact head:
31d854162004b76ad6749607f9ae811668d82ae1 - live base:
develop@749511c3ad4000090048718f685c6bee6b3d2c25 - required Strix run/job:
33278554369/99170350374 - trusted central workflow SHA:
6c8ee24046d743b3981c566c6e29f99f09137f6a - pinned contextual-orchestrator:
b21645116b352967e50fc497b87eb745b9cc8c61
The trusted target/base materialization and required-workflow contract smoke test succeed. Sidecar provisioning emits the expected oversized local ingress
413 request_too_largecontract probe, selects the live OpenRouter ZDR feed, starts127.0.0.1:18080, and—unlike the current Noema exhaustion case—reaches healthy/healthzplus provider-route preflight after 8 seconds. The next OpenAI-compatible gateway preflight then receives 0 bytes for 30.002 seconds and fails withcurl: (28) Operation timed out; the bootstrap reportsgateway preflight request could not reach the local sidecar.Run Strix (quick)therefore never executes and no authoritative vulnerability verdict exists.This falsifies “sidecar cannot become healthy” as the complete remaining Strix hypothesis for this consumer. The first unresolved boundary is now post-healthz gateway request/fallback handling in the trusted central sidecar path, not BandScope source. Acceptance canary: on unchanged
bandscope#1072@31d8541…, preserve the secret boundary and fail-closed scanner policy while making the bounded gateway preflight terminate successfully and allowing Strix to emit a real terminal vulnerability verdict. Timeout/provider-unavailable/skipped/synthetic/predecessor evidence remains non-passing.- BandScope exact head:
27 remaining items
A second fresh BandScope consumer canary reproduces the cancelled-before-job-materialization Strix failure on an independent repaired product lane, so this is not isolated to #1103.
- consumer:
ContextualWisdomLab/bandscope#1102 - exact target head:
e1c091de54a243fb7938e910af6b3c7ff9220c22 - exact live base (refetched immediately before recovery):
develop@749511c3ad4000090048718f685c6bee6b3d2c25 - required Strix run:
33359166487 - run conclusion:
cancelled - jobs endpoint:
total_count: 0— no checkout, sidecar, scanner job, or vulnerability verdict materialized - bounded recovery on the unchanged head/base: GitHub rejected
rerun failed jobswith HTTP 403This workflow run cannot be retried
The same exact consumer head has terminal-success repository-local CI, build/release, Security Scan, Semgrep, Bandit, security-audit, SBOM/supply-chain, secret scan, Noema, scheduler and Code Quality evidence, so there is no BandScope product/security repair that can manufacture the missing Strix verdict. The required cancelled run remains non-passing.
Acceptance extension for the existing central owner remains: a required Strix
pull_request_targetdispatch that is cancelled before any job materializes must have a bounded trusted redelivery/recovery path that produces an exact-head terminal scanner verdict, or a deterministic owner-actionable retry state. Zero-job/non-rerunnable cancellation must never be translated to success, and target code must not gain provider/reviewer credentials.- consumer:
Fresh post-#1504 unchanged-head Noema canary from
ContextualWisdomLab/Orgmetra#40confirms the remaining first causal boundary is still the substantive review transaction timeout, after the latest central structured-verdict repair.- target repo/PR:
ContextualWisdomLab/Orgmetra#40 - exact target head:
6917e41f9053fab6f7e99f8185f2137e8fc5fca5 - live base:
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - Required Noema run:
33294991587, attempt8 - replacement job:
99436298297 - trusted central workflow source:
.github@1cbb6aaf0a24c3628d24c3dd6d9dcaa8a7eec0c5(includes merged fix(noema): repair invalid structured verdict once #1504) - pinned contextual-orchestrator:
8cd99f139915131ba0239bce12a5d6a5fd85394e
Fresh execution advances through repository-scoped
cwl-noema-reviewApp token mint, target visibility, sidecar provisioning,/healthz, provider-route preflight, and gatewaychat/completionspreflight. The runtime has three ready routes and the actual Noema review starts. It then blocks inscripts/ci/noema_review_gate.py::call_llmuntil the hardopener.open(..., timeout=120)expires withTimeoutError: timed out; job is terminal FAILURE and no authenticated Noema Reviews API verdict is published.This is the same post-preflight owner boundary previously reproduced on attempt 7, now re-proven after #1504 on the unchanged consumer head. The one-repair invalid-structured-verdict path is never reached, so no Orgmetra-local source change can repair it.
Acceptance remains: on this unchanged repo/PR/head/base, the trusted bounded review transaction must return within the gate contract (or use a correctly bounded timeout/retry/cancellation design), validate the structured verdict, and publish an authenticated terminal Noema formal review. Timeout/provider fallback/skipped/model-only/predecessor evidence remains non-passing.
- target repo/PR:
Fresh downstream exact-head Strix canary from
ContextualWisdomLab/bandscope#985confirms the same trusted-sidecar owner defect and narrows the current failure signature.- consumer PR:
ContextualWisdomLab/bandscope#985 - exact target head:
209cc2fea4dea04876264bdf0cd8cb58c6b75eb5 - exact live base:
develop@749511c3ad4000090048718f685c6bee6b3d2c25 - required Strix run/job:
33287967042/99194826557 - trusted central workflow SHA:
6c8ee24046d743b3981c566c6e29f99f09137f6a - pinned contextual-orchestrator:
b21645116b352967e50fc497b87eb745b9cc8c61
Exact job evidence: target-repository visibility, exact base/head fetch, Strix required-workflow smoke test, and all five provider-secret gates succeed.
Provision contextual-orchestrator Strix sidecarthen recordsrequest_failed status=413 code=request_too_large, falls back to the live OpenRouter ZDR endpoint feed, starts the sidecar on127.0.0.1:18080, and initially confirms/healthzplus provider-route readiness. The subsequent gateway preflight returns HTTP 502, the sidecar is stopped, andRun Strix (quick)is skipped. No vulnerability verdict exists for this head.This consumer is useful because the repository-local exact-head gates are otherwise terminal-success on
209cc2…(CI/build/release/security/SAST/SBOM lanes), so there is no BandScope-local source change that can correctly repair this first failing boundary. Please keep the repair in the existing central trusted-sidecar owner lane; do not execute target PR gateway code with provider credentials or convert bootstrap/provider failure to scan success.Acceptance canary: without changing BandScope head
209cc2…or base749511…, the central sidecar must complete bootstrap and gateway preflight, Strix must actually execute against that exact target/base, and the required workflow must emit a real terminal vulnerability verdict. Provider-unavailable, 413/502 bootstrap failure, skipped scan, synthetic/manual status, or predecessor-head evidence remains non-passing.- consumer PR:
Fresh BandScope consumer evidence (2026-08-31):
ContextualWisdomLab/bandscope#1103is unchanged at exact head2e5658166fa8f9c55874fa7110c7f865e6e7eaf0against protecteddevelop@749511c3ad4000090048718f685c6bee6b3d2c25. Required Strix run33373082621completedcancelled, andGET /actions/runs/33373082621/jobsreturnstotal_count: 0, so no scanner job materialized and no vulnerability verdict exists. A bounded recovery attempt using GitHub's failed-run rerun endpoint returned HTTP 403This workflow run cannot be retried; this is therefore not repairable by BandScope source or by rerunning an existing Strix job. Acceptance canary for the central owner: on the unchanged BandScope head/base above, a fresh required Strix invocation must materialize a job, checkout/identify the exact consumer SHA, reach the scanner, and emit a terminal real vulnerability verdict; cancelled/no-job/skipped/neutral/provider-unavailable states remain non-passing. No BandScope leaf workaround or gate weakening should be introduced.Current owner overlap — do not duplicate
A fresh live audit on 2026-09-01 KST found an existing open owner branch for the current plain-text Strix sidecar catalog defect:
- implementing PR: fix(ci): exclude non-text-input models from review sidecar catalog #1529
- exact live head:
7fea1cdc0df5cff08ea48b51c18807303cc118ed - exact base observed:
main@1cbb6aaf0a24c3628d24c3dd6d9dcaa8a7eec0c5 - owned production path:
scripts/ci/contextual_orchestrator_review_launcher.py - owned regression path:
tests/test_contextual_orchestrator_review_sidecar_contract.py - supporting release record:
CHANGELOG.md
The PR identifies a concrete current failure: the central catalog builder filters text output but not non-text input, so a vision-only NVIDIA NIM model can enter the plain-text review pool and reject Strix's prompt with HTTP 400 after consuming the bounded failover budget. Its minimal change uses contextual-orchestrator's shared
requires_non_text_input(...)contract before catalog construction, and its focused/full local evidence is recorded on the PR. HostedqualityandPython 3.14 exact contract and complete coverageare terminal success for this head.This is exact code/path overlap, so I did not create a competing branch or mutate the shared sidecar. The owner PR is not yet admissible:
exact-head-path-policyis terminal failure at run33438060933, job99639234092, and required review/security jobs remain incomplete/cancelled/queued. This comment is routing evidence only, not closure of #1399 and not passing Strix evidence. Keep the issue open until the owner PR is repaired through normal protection and an unchanged/current consumer reaches a real exact-head Strix verdict.Fresh Orgmetra exact-head canary shows the shared-sidecar repair lane has progressed past
/healthz, but required Strix now fails at the next central adapter boundary before any vulnerability analysis.Consumer evidence:
ContextualWisdomLab/Orgmetra#73- exact head
acaebb70d777bf4aecbe64d0e71430c0ec0fefa3 - live base
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - Strix run/job
33264946855/99133441789 - trusted central workflow used by that run:
.github@6c8ee24046d743b3981c566c6e29f99f09137f6a - pinned Strix executable:
strix-agent==1.5.3, executable SHA-256d2dd9753453674e0081508a08d869e7b629c15f11b70294b980033272734f073
The trusted contextual-orchestrator sidecar itself succeeds on this canary: it starts at
127.0.0.1:18080, reaches/healthz, and passes the gatewaychat/completionspreflight. The primary free routes return 429, but the bounded fallback set reports ready routes, so the earlier pre-healthz bootstrap failure is not the first causal boundary here.The first failing boundary is
Run Strix (quick). The central workflow writes the local trusted gateway origin toLLM_API_BASE_FILEashttp://127.0.0.1:18080/v1; Strix then terminates immediately with exit 2 and the exact messageERROR: LLM_API_BASE must be an https URL when configured.No scanner analysis or vulnerability finding is produced.This remains current in protected central source:
.github/main@4ae90e18b03a3a455e13e501628010cabc5c37a8still constructsllm_api_base_filefrom the loopback sidecar base withprintf '%s/v1', so a blind rerun of the unchanged Orgmetra head would reproduce the same contract mismatch rather than create new evidence.First causal owner boundary: central Strix↔trusted-contextual-orchestrator adapter contract, not Orgmetra source. The correct repair must preserve the existing credential boundary and Strix's HTTPS requirement for remote provider origins; do not globally weaken remote HTTPS validation and do not execute target-PR gateway code with reviewer/provider credentials.
RED acceptance: reproduce the trusted loopback sidecar + Strix 1.5.3 invocation and prove the current central adapter cannot reach scanner analysis because the configured API base is rejected before inference.
GREEN acceptance: the trusted central adapter supplies Strix an accepted local-gateway transport contract (or equivalently trusted loopback TLS) while retaining HTTPS enforcement for remote origins; then an unchanged/current consumer head must reach actual Strix analysis and emit an authoritative exact-head finding/no-finding receipt. Provider unavailable, configuration failure, skipped/neutral, synthetic, or predecessor evidence remains non-passing.
No
.github, contextual-orchestrator, or other foreign source/ref/PR state was mutated from the Orgmetra writer.fast-mlsirm exact-head Strix canary after central timeout repair
Fresh downstream evidence from
ContextualWisdomLab/fast-mlsirm#1690separates the leaf source from the remaining shared-sidecar/provider boundary.- target PR:
fast-mlsirm#1690 - unchanged exact head:
c7f08bb0b1ad00019f664b59f885e3991ba201ce - live protected base:
main@45627700c26c29bca150896a9519a9b7426acb56 - leaf CI/CodeQL/SAST/Security Scan and repository-required
rust,python,package,fuzz,coverage-evidence,dependency-review,trivy-fs,scorecard,osv-scanare terminal success on this exact head. - predecessor required Strix run/job:
33360743954/99391470519; the trusted sidecar reached health/provider-route and then the gateway preflight timed out three times at 120 s with zero response bytes. This was upstream control-plane/provider evidence, not a CodeQL-pin source failure. - I requested a job rerun without moving the clean head. GitHub accepted it. The current rerun check is job
100097770327in the same workflow run33360743954; it is presentlypending, therefore still non-passing.
This canary is after the central
LLM_TIMEOUT=0immediate-cancellation defect was repaired on protected.githubmain. It therefore exercises the next boundary rather than re-reporting that predecessor defect.RED/GREEN acceptance for this owner lane: keep
fast-mlsirm#1690@c7f08bb…unchanged; the trusted Strix sidecar must complete provider/gateway preflight and produce a real terminal Strix vulnerability verdict for that exact target head. Timeout/provider/bootstrap failure, cancellation, synthetic verdicts, skipped execution, or predecessor-head evidence remain non-passing. Do not move provider credentials into target-PR execution and do not weaken the required gate.- target PR:
Fresh Wardnet evidence shows the trusted contextual-orchestrator sidecar can now reach its own OpenAI-compatible preflight while the actual Strix client still cannot complete a scan, so the bootstrap/compatibility lane remains open in a newer form.
Exact evidence:
ContextualWisdomLab/wardnet#138@e6f05d77858e91c176cff25c4b11e790bc5dcdd1, Strix run33505617601, job99848826685, trusted central workflow.github@5768f2bd29b0856ad49f18a0fda72b871eb95b46. The job fetched exact Wardnet basecc15cc2c34daf8c104eeb83d52a6a66f3cd6e128and exact head, retained 4 scannable changed files, and started a sidecar vendored from contextual-orchestrator8cd99f139915131ba0239bce12a5d6a5fd85394e. Sidecar health/provider-route startup eventually succeeded; its own/v1/chat/completionsgateway preflight succeeded on attempt 1 and reported five ready free routes. Immediately afterward pinned Strix 1.5.3, configured asopenai/orchestrator/freeagainst that same local OpenAI-compatible gateway, failed three bounded attempts withLLM CONNECTION FAILED / Could not establish connection to the language model. No structured vulnerability report was produced; the wrapper correctly emittedSTRIX_PROVIDER_UNAVAILABLEand failed closed.This is not Wardnet source vulnerability evidence. RED extension: a test/harness where sidecar health + gateway chat/completions preflight are GREEN but the real Strix client/provider adapter cannot use
orchestrator/freemust fail as a typed compatibility defect and preserve exact-head scan non-passing. GREEN: unchangedwardnet#138@e6f05d...reaches an authoritative Strix vulnerability verdict through the trusted sidecar; no target PR code receives provider credentials; existing fail-closed severity and exact-head rules stay intact. Please re-evaluate the current model/provider identifier and OpenAI-compatible base/transport contract used by Strix rather than treating successful sidecar preflight as end-to-end proof.Fresh OriginWeave #82 consumer RCA found a distinct current central Strix bootstrap defect that is still present on protected
.github/main@8c085835fbf77de2321b72fa6b8dd946227e523e.Exact consumer evidence: OriginWeave #82 head
90c4e9a8f31eb94eb46243343160d3f6c96921ef, Strix run33497088613attempt 2, job/check100091557792. The trusted workflow source was immutable.github@2792b964b321d096ed292979e175510cf94aa03c. contextual-orchestrator sidecar startup andorchestrator/freegateway chat/completions preflight succeeded; the scan then failed before Strix analysis with:AttributeError: 'function' object has no attribute 'asyncio'at the timeout compatibility launcher line that does
strix_main.asyncio = UnboundedInferenceAsyncio(strix_main.asyncio).Current protected main still contains the same import shape in
scripts/ci/strix_timeout_compat.py:from strix.interface import main as strix_mainthen treats
strix_mainas thestrix.interface.mainmodule. With installedstrix-agent==1.5.3, the package export resolvesstrix.interface.mainhere as a function, so the compatibility launcher fails before any authoritative vulnerability report. This is central trusted-workflow/runtime code, not an OriginWeave security finding.The existing regression
tests/test_strix_llm_timeout_contract.py::test_runtime_compatibility_patches_only_strix_model_boundariesmisses the production behavior because its fake package explicitly assignsinterface_package.main = main_module; it therefore forces the attribute import to return the module and cannot reproduce the real package export collision.Required causal repair: import the actual module explicitly (for example
importlib.import_module("strix.interface.main"), while keeping the version gate and only patching the two reviewed module-local asyncio references), and add a RED→GREEN regression whose fake package exposesstrix.interface.mainas a function whilesys.modules["strix.interface.main"]contains the module. Also run the pinnedstrix-agent==1.5.3launcher integration path far enough to prove module resolution before accepting GREEN. Do not classify this as provider unavailable, do not weaken Strix, and do not convert absence of a report artifact to success.Consumer artifact
strix-reportsID9844370378, SHA-2562213dd9a0bbe40aa996ca064adda0777c0477310f625755ae6cb4f9456d8595fpreserves the failed run evidence.Fresh downstream Strix runtime-compatibility failure, 2026-09-02, extends this same central trusted-bootstrap owner boundary and is not a ConceptWeave source finding.
ContextualWisdomLab/ConceptWeave#1@bba351b77bf5f1ab5cfd55979fbb2bd158f78b81required Strix run33527145692, job100235753250, acquired GitHub-hosted Ubuntu 24.04 runner1001626827and used trusted central workflow SHAb4eec000d21084accb736d289eb64cfd78e7a91a. Exact PR base/head materialization completed. The contextual-orchestrator sidecar also completed successfully: it vendored orchestrator045d17da5e2aea56a97e241ee158ab1628d78660, started on loopback, admitted 54 free routes, selected 12orchestrator/freecandidates, and confirmed three ready routes plus a successful gatewaychat/completionspreflight. Provider availability therefore precedes the actual failure.The first failing boundary is the central installed
cwl-strix-timeout-compatwrapper before Strix can emit an authoritative report:File "/opt/hostedtoolcache/Python/3.13.15/x64/bin/cwl-strix-timeout-compat", line 88, in install_runtime_compatibility strix_main.asyncio = UnboundedInferenceAsyncio(strix_main.asyncio) AttributeError: 'function' object has no attribute 'asyncio'The same job installed pinned
strix-agent==1.5.3. The wrapper is assuming that its importedstrix_mainvalue exposes the module attributeasyncio; the current runtime shape is a function, so the compatibility shim crashes before vulnerability analysis. The gate correctly fails closed and uploads only diagnostic artifacts; zero ConceptWeave vulnerability evidence is produced.Please treat this as a new executable RED under the existing central Strix bootstrap/compatibility owner, not as permission to change ConceptWeave. Minimal GREEN acceptance:
- Central regression executes the exact
strix-agent==1.5.3import/runtime shape and reproduces the wrapper crash before repair. - Repair locates/patches the intended asyncio dependency at the actual owning module/object boundary instead of assuming a function has
.asyncio; keep the unbounded-inference semantics, credential isolation, exact trusted-source binding,orchestrator/freegateway-only route, and fail-closed classification unchanged. - Integrate the repair on protected
.githubtruth through its existing writer/governance path. - Fresh rerun on the unchanged ConceptWeave
#1@bba351b...must pass the wrapper boundary and reach real Strix vulnerability analysis. Terminal authoritative success or a real source finding is acceptable; another wrapper/provider/synthetic result is non-passing.
Do not rerun this unchanged ConceptWeave Strix lane merely to churn evidence before the central causal condition changes.
- Central regression executes the exact
Fresh owner-path RCA from ConceptWeave, 2026-09-03 UTC. Re-read protected
.github/main@bf5970df983dd36e3372c124778ec60857414eba; the currentscripts/ci/strix_timeout_compat.pystill importsmainwithfrom strix.interface import main as strix_mainand immediately dereferencesstrix_main.asyncio.new_event_loop. That source shape still admits the exact observed ConceptWeave foundation failure when the installedstrix.interfacepackage exports a callablemain: the compatibility wrapper receives a function instead of thestrix.interface.mainsubmodule and raises'function' object has no attribute 'asyncio'before Strix can produce authoritative scanner evidence.Treat this as a current central source defect, not a ConceptWeave finding and not a runner-admission issue. Minimal executable RED: construct/import a fixture where
strix.interface.__init__exports a callablemainwhile the realstrix.interface.mainsubmodule exists; current compatibility code must reproduce the attribute failure. Minimal causal repair: bind the actual submodule explicitly (for example via a boundedimportlib.import_module("strix.interface.main"), or move the compatibility patch to the lower-level client boundary) and keep the real cross-event-loopRuntime got Future ... attached to a different loopretry/fail-closed semantics unchanged. Do not catch-and-pass the wrapper exception and do not weaken Strix.GREEN acceptance: focused compatibility regression including the package-export shadow case + repository-required exact-head quality/coverage/security evidence on the central repair; normal protected-main integration; then fresh revalidation of the still-current ConceptWeave foundation head (refetch its SHA, do not hard-code this comment's remembered value) must show Strix reaching actual scanner execution rather than the compatibility-wrapper exception. Existing
.githubwriter remains the sole source owner for this repair.
Buyer / organization impact
The required Strix gate is currently unable to validate the exact PR that repairs the gateway contract Strix itself needs. This also blocks unrelated product PRs that route Strix through the same trusted contextual-orchestrator sidecar.
Fresh exact evidence
main:3a7941aa92de00b8b39fd11cbe7bf3da2fbbeddc.scripts/ci/contextual_orchestrator_review_sidecar.shon that exact main still defaultsORCHESTRATOR_PIN_SHAtob21645116b352967e50fc497b87eb745b9cc8c61.ContextualWisdomLab/contextual-orchestrator#914is Ready/mergeable at exact head3db6b77ca7f5b25f47488e61371b0007a34f0dbband specifically acceptsstream_options.include_usage=true, preserves provider usage, emits the usage-only SSE chunk after the stop chunk, and retains fail-closed unsupported options.33229504026, job99039694157, materialized the target PR head for scan scope but loggedvendoring contextual-orchestrator @ b21645116b352967e50fc497b87eb745b9cc8c61for the credentialed review sidecar. OpenAI Agents then sentstream_options.include_usage=true; the pinned gateway returned400 invalid_stream_optionson all bounded attempts, so Strix correctly failed closed as provider unavailable.ContextualWisdomLab/naruon#1206exact headcb55a7eda5152fe2250c7eb1bd416911b59a5e43; its source/security checks otherwise reach terminal success, but required Strix fails before producing a vulnerability verdict.This is a central trusted-review bootstrap dependency, not evidence that #914's source repair fails.
Security boundary
Do not solve this by executing an arbitrary contextual-orchestrator PR head with provider credentials. The trusted
pull_request_target/central workflow must not exposeNVIDIA_NIM_API_KEYor other reviewer credentials to untrusted target code. Do not weaken required Strix, convert provider failure to success, bypass protection, or accept predecessor/synthetic evidence.Required repair
Provide a trusted bootstrap path that lets Strix obtain an actual vulnerability verdict while the protected-main contextual-orchestrator pin lacks the protocol feature being repaired. Prefer a bounded transport/provider compatibility path owned by central
.github(usingNVIDIA_NIM_API_KEYfor LLM execution) rather than running untrusted PR-head gateway code with secrets. Once #914 integrates through normal protection, advance the protected sidecar pin and remove any temporary compatibility path that is no longer required.Acceptance criteria
stream_options.include_usage=truefailure against the currently pinned sidecar.contextual-orchestrator#914@3db6b77...reaches the scanner and returns a real terminal vulnerability verdict; provider-unavailable, skipped, neutral, or synthetic results remain non-passing.naruon#1206@cb55a7e...likewise reaches a real verdict.Concurrency note
An active writer is currently moving overlapping central review artifacts (including
.github/workflows/strix.ymlon open PR #1382), so this issue intentionally records the dependency without racing that branch. Reuse/coordinate with the active writer if it already owns the fix.