fix(strix): break contextual-orchestrator sidecar bootstrap deadlock

[seonghobae]

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

• Central control-plane main: 3a7941aa92de00b8b39fd11cbe7bf3da2fbbeddc.
• scripts/ci/contextual_orchestrator_review_sidecar.sh on that exact main still defaults ORCHESTRATOR_PIN_SHA to b21645116b352967e50fc497b87eb745b9cc8c61.
• ContextualWisdomLab/contextual-orchestrator#914 is Ready/mergeable at exact head 3db6b77ca7f5b25f47488e61371b0007a34f0dbb and specifically accepts stream_options.include_usage=true, preserves provider usage, emits the usage-only SSE chunk after the stop chunk, and retains fail-closed unsupported options.
• All current chore(deps): bump types-requests from 2.33.0.20260518 to 2.33.0.20260712 #914 review threads are resolved; latest Devin review reports zero new findings.
• Required Strix run 33229504026, job 99039694157, materialized the target PR head for scan scope but logged vendoring contextual-orchestrator @ b21645116b352967e50fc497b87eb745b9cc8c61 for the credentialed review sidecar. OpenAI Agents then sent stream_options.include_usage=true; the pinned gateway returned 400 invalid_stream_options on all bounded attempts, so Strix correctly failed closed as provider unavailable.
• The same transport failure is present on ContextualWisdomLab/naruon#1206 exact head cb55a7eda5152fe2250c7eb1bd416911b59a5e43; 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 expose NVIDIA_NIM_API_KEY or 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 (using NVIDIA_NIM_API_KEY for 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

1. Add a test-first regression reproducing the stream_options.include_usage=true failure against the currently pinned sidecar.
2. Preserve the secret boundary: no target PR code receives reviewer/provider credentials merely because it is the contextual-orchestrator repository.
3. A fresh required Strix run on unchanged contextual-orchestrator#914@3db6b77... reaches the scanner and returns a real terminal vulnerability verdict; provider-unavailable, skipped, neutral, or synthetic results remain non-passing.
4. A fresh required Strix run on unchanged naruon#1206@cb55a7e... likewise reaches a real verdict.
5. Keep current severity/fail-closed rules, bounded retries/timeouts, raw evidence, and exact-head identity checks intact.
6. Re-run live central ruleset requirements and merge only with all required checks, zero valid unresolved findings, and qualifying independent approval.

Concurrency note

An active writer is currently moving overlapping central review artifacts (including .github/workflows/strix.yml on 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.

[seonghobae]

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=true symptom 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, base 86fe907b6732a20aaa17260701687c0267e275a3, exact head d240ba4657300bb7e127fa0b539516a9a48cee4a;
• trusted sidecar script in both paths vendors ContextualWisdomLab/contextual-orchestrator@b21645116b352967e50fc497b87eb745b9cc8c61 rather than target-PR code, preserving the credential boundary.

Required Noema Review reproduction

• run 33250134550, attempt 2, job 99100874276;
• trusted source materialization, repository-scoped GitHub App token mint, and target visibility all succeed;
• Provision contextual-orchestrator review sidecar fails;
• after hash-pinned dependency installation, the shared bootstrap reports request_failed status=413 code=request_too_large, then using live OpenRouter ZDR endpoint feed, starts 127.0.0.1:18080, and exits before healthz with review 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, job 99100893968;
• exact live PR metadata is validated, exact base/head are fetched, and the Strix required-workflow smoke test passes;
• Provision contextual-orchestrator Strix sidecar then vendors the same b2164511... pin and fails after the same request_failed status=413 code=request_too_large boundary;
• 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

1. Add a realistic regression in the existing central owner lane that reproduces the current 413 request_too_large / preflight failure using the trusted b2164511... path and bounded provider-endpoint/preflight inputs.
2. 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.
3. GREEN must prove on one unchanged exact owner state that Required Noema Review for .github#897@d240ba4657300bb7e127fa0b539516a9a48cee4a reaches 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.
4. After protected integration, regenerate the then-current ContextualWisdomLab/noema#500 exact-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.

[seonghobae]

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 on 127.0.0.1:18080 but exits status 1 before /healthz with review 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.

[seonghobae]

Fresh shared-sidecar canary from ContextualWisdomLab/Orgmetra#48 reproduces 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 on 127.0.0.1:18080, and exits status 1 before /healthz with review 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 /healthz followed 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.

[seonghobae]

Fresh Strix canary from ContextualWisdomLab/Orgmetra#48 advances the shared-sidecar causal boundary beyond /healthz on 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 reaches healthz 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-reports artifact: id 9717135488, 12,251 bytes, SHA-256 bfdd676e50e1fdb13423d3782f20f8069af85c12a52b90cb193941c3fb85f328.

Acceptance canary: on the unchanged/current Orgmetra #48 head, the shared sidecar must pass /healthz AND 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.

[seonghobae]

Fresh shared-sidecar consumer canary from Noema, not closure. ContextualWisdomLab/Orgmetra#73 remains at exact head acaebb70d777bf4aecbe64d0e71430c0ec0fefa3 against develop@9e3e4847510e1e612b48474ba42b177b8ed824df. Required Noema job 99133254694 materializes trusted central source 6c8ee24046d743b3981c566c6e29f99f09137f6a, mints the repository-scoped Noema app token, resolves target visibility, sees all five provider secrets, and vendors contextual-orchestrator@b21645116b352967e50fc497b87eb745b9cc8c61. OpenRouter's endpoint-feed request first returns 413, the live ZDR feed is selected, then the review sidecar starts on 127.0.0.1:18080 and exits status 1 before /healthz with review 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.

[seonghobae]

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.

[seonghobae]

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.sh then installed the hash-pinned orchestrator dependencies, received the known OpenRouter endpoint-feed HTTP 413 and selected the live ZDR feed, started the review sidecar on 127.0.0.1:18080, then failed before /healthz with sidecar 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.

[seonghobae]

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 on 127.0.0.1:18080, and then reports healthz 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 with gateway 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.

[seonghobae]

Orgmetra exact-current-head Noema canary — PR #59 bd1ac69ec5d3daa95387f0d7458e724897062ae3, live base 9e3e4847510e1e612b48474ba42b177b8ed824df.

Required Noema run 33272729947, job 99154025444 resolved/materialized trusted .github source 6c8ee24046d743b3981c566c6e29f99f09137f6a, selected/minted the repository-scoped reviewer token, resolved the public target, and vendored contextual-orchestrator@b21645116b352967e50fc497b87eb745b9cc8c61. After the OpenRouter endpoint-feed request returned 413 and the live ZDR feed was selected, the shared sidecar started on 127.0.0.1:18080 but exited status 1 before /healthz with review 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.

[seonghobae]

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 verdict is 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.

[seonghobae]

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 returns 413 request_too_large, the live OpenRouter ZDR feed is selected, the sidecar starts on 127.0.0.1:18080, then exits status 1 before /healthz with review 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.

[seonghobae]

Superseding Noema consumer canary for ContextualWisdomLab/Orgmetra#40 after 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 on 127.0.0.1:18080, then exits status 1 before /healthz with review sidecar preflight failed. The actual Noema review/verdict step never executes. The predecessor bd4d0cf... 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 /healthz must 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.

[seonghobae]

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 on 127.0.0.1:18080, then exits status 1 before /healthz with review 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.

[seonghobae]

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 on 127.0.0.1:18080, then exits status 1 before /healthz with review 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.