Migrate review consumers to released orchestrator/free gateway contract

[seonghobae]

Problem

The central Strix/OpenCode/Noema/autofix review consumers still provision contextual-orchestrator inside .github, perform provider/model discovery locally, and inject raw provider credentials into the workflow boundary. That is no longer an acceptable end state.

Protected .github/main@cb0872c9a20d5584703dffacca65c096fc034c6c still hard-defaults scripts/ci/contextual_orchestrator_review_sidecar.sh to ORCHESTRATOR_PIN_SHA=414f22973658c4ddc3d4320fcf7acd9b4e8ba991. The script requires at least one of BYTEZ_API_KEY, NVIDIA_NIM_API_KEY, NVIDIA_NIM_API_KEY_SUB, OPENROUTER_API_KEY, or OPENAI_API_KEY, then constructs/probes the free candidate pool in the consumer repository.

A composite action already exists for shared sidecar provisioning, but migrating callers to that action while preserving the same raw provider-secret and local-discovery contract would only consolidate the duplication; it would not satisfy the canonical ownership boundary.

Canonical ownership

contextual-orchestrator owns provider credential registration, provider/model discovery, free-pool eligibility/admission, request-scoped routing/fallback, capability matching, and typed provider/gateway failure provenance. GitHub Actions callers use only the released gateway/client/schema contract, a gateway bearer, and model: orchestrator/free. They do not name providers/models/groups or own paid fallback.

contextual-orchestrator#1094 is protected-integrated and restores virtual structured-output failover on retryable provider outcomes, but contextual-orchestrator still publishes no immutable GitHub Release. Do not pin mutable CO main, vendor a mutable owner PR/head, or copy its routing logic into .github as a bridge.

Consumer canary

fast-mlsirm#1519@dfac8acab49845d2328df6cf08d0fc748f2de711 is a current unchanged-leaf canary. Ordinary CI, Required CodeQL PR, repository CodeQL, Security Scan and Semgrep are terminal GREEN. Required Noema run 34475270437 admitted that exact head and provisioned the sidecar, then failed in model-verdict preparation; retained artifact noema-sidecar-evidence is bound to the same SHA with digest sha256:5013fa48ead37b7ef5da4c5b01fb4910661953a6569fac666c2cbb37c518e610. OpenCode consequently fails closed rather than manufacturing an approval. This is review-gateway availability/ownership evidence, not a fast-mlsirm source finding.

Repair order

1. contextual-orchestrator completes chore(deps): bump typing-inspection from 0.4.2 to 0.4.4 #1106 (or its verified successor) with RED→GREEN contracts for credential/admission/routing ownership and publishes an immutable API/client/schema release with reproducible identity and typed failure semantics.
2. Central .github consumers adopt that exact released contract. Remove raw provider-key inputs, provider inventory/catalog construction, probing/admission thresholds, provider/model/group selection, and fallback policy from workflow/composite/script boundaries. Preserve private-target/ZDR policy through the released owner contract rather than reimplementing provider selection here.
3. Restrict consumer egress to the reviewed gateway plus GitHub/artifact endpoints as applicable and keep failures fail-closed.
4. Verify central exact-head workflow/contract/security evidence, then replay unchanged consumer heads such as fast-mlsirm chore(deps): bump anchore/sbom-action from 0.24.0 to 0.24.2 #1519. Require exact checkout binding and authenticated Noema/OpenCode/Strix verdict evidence before merge admission.
5. Remove purpose-complete legacy sidecar/bootstrap code only after released-path consumers are GREEN and in-flight legacy executions are drained.

No leaf no-op retrigger, provider-specific fallback, paid fallback, mutable-main pin, self-approval, synthetic success, or gate weakening is acceptance evidence.

[seonghobae]

Fresh owner-boundary evidence (2026-09-05 UTC; all remembered snapshots discarded):

• Protected .github/main is 6d7fbebec8aec31d88a30a36e71ca5b3925d241d.
• newsdom-api#682 is still open/Draft at unchanged head 585bb4e0fb719ab6a576cf46d1ef12b77872557b. Its failed required Strix run 32638076034 / job 97190711585 is predecessor evidence from 2026-08-23. The exact log proves the old trusted workflow selected nvidia_nim/nvidia/nemotron-3-super-120b-a12b, received NVIDIA HTTP 429, then attempted NVIDIA and openai-direct/gpt-5.6-luna fallbacks while harden-runner reported egress-policy: audit. This is provider infrastructure evidence, not a NewsDOM source vulnerability.
• Protected current strix.yml no longer uses that old model selector: it fixes contextual-orchestrator/orchestrator/free and a loopback gateway. But the provisioning step still injects BYTEZ_API_KEY, NVIDIA_NIM_API_KEY, NVIDIA_NIM_API_KEY_SUB, OPENROUTER_API_KEY, and OPENAI_API_KEY; scripts/ci/contextual_orchestrator_review_sidecar.sh fails unless at least one is present, clones a pinned CO source tree, and performs provider discovery locally. The Strix job also remains egress-policy: audit.
• Contextual-orchestrator currently publishes zero GitHub Releases, so there is no immutable released gateway/client artifact that this required workflow can consume with only an endpoint + gateway bearer.

Therefore the safe dependency order is:

1. contextual-orchestrator publishes an immutable versioned client/action/package or image plus exact API/schema/source digest and a gateway endpoint/token contract for orchestrator/free; it must emit typed source-finding vs provider/gateway/capability outcomes and remain fail closed.
2. This central owner migrates Strix to that release, removes all five provider-secret references from the workflow/job/composite boundary, permits egress only to the reviewed gateway/GitHub/artifact endpoints with block-mode enforcement, and adds RED/GREEN contracts that forbid direct provider inventory.
3. Re-run a current central exact-head gate, then dispatch a fresh required Strix execution against unchanged NewsDOM head 585bb4e0...; require actual checkout binding, authoritative report evidence, and terminal success before Ready/merge.

Do not rerun job 97190711585: a rerun would retain predecessor workflow semantics and cannot prove this repair. Do not delete the provider secrets or switch audit→block in isolation; the present sidecar would fail before analysis and create a false repair.

[seonghobae]

2026-09-06 UTC fresh owner evidence: two unchanged central PR heads failed before scanner execution at the contextual-orchestrator sidecar preflight. These are typed provider/gateway-capability failures, not source-vulnerability findings.

• .github#1563@52ac4eefd0fdc66a3622a80111ce241b9a918b7a: Strix run 34021998836, job 101465146909, terminal failure at 2026-09-06 10:31:03Z.
• .github#1879@d4366f837afd9f988707618c6855c1661f81c3f8: Strix run 34023014163, job 101467958914, terminal failure at 2026-09-06 10:52:50Z.

Both logs say provider secrets present: 5 of 5, vendor CO source at 414f22973658c4ddc3d4320fcf7acd9b4e8ba991, and report the same bounded preflight receipt: candidate_count=24, probed_count=6, ready_count=0, rejected_count=6. The six probes were rejected with HTTP 429 across direct nvidia_nim, nvidia_nim_sub, and openrouter; Bytez discovery also reported http_status_500. The sidecar exited before /healthz, so “Run Strix (quick)” never produced source analysis.

Live prerequisites remain absent: protected CO main@414f22973658c4ddc3d4320fcf7acd9b4e8ba991 has no tags/releases, and protected .github/main@43024633eba9d96b0456970391360da5a171fbda still uses runtime source vendoring/direct provider secrets and egress-policy: audit. Therefore neither failure is consumer/source evidence, and neither authorizes retry, bypass, gate weakening, or a partial provider-secret/egress-only edit. Acceptance remains immutable released CO gateway contract → gateway-token-only central workflow with enforced egress → exact-head central GREEN → unchanged NewsDOM #682 canary GREEN.

[seonghobae]

Fresh integration evidence tightens this consumer issue. fast-mlsirm#1519@84000d861ddc9b8cc72a39e7c78f8016051e0e6c, Required Noema run 34469361714 / job 102845420373, executed trusted .github@cb0872c9a20d5584703dffacca65c096fc034c6c and logged vendoring contextual-orchestrator @ 414f22973658c4ddc3d4320fcf7acd9b4e8ba991. That exact central source still hard-defaults ORCHESTRATOR_PIN_SHA to 414f2297… and bootstraps the sidecar with five raw provider secrets.

The review preflight did become ready, but the actual orchestrator/free request failed after 182.4 s with HTTP 429 (response_error, served google/gemma-4-31b-it:free, caller attempts=1). Meanwhile contextual-orchestrator #1094, which adds virtual structured-output re-selection for retryable 429/502/timeout, merged on 2026-09-09 and protected CO main has moved beyond it; the central consumer never exercised that behavior because its pin is older. CO still has no immutable GitHub Release, so do not solve this by pinning mutable CO main or copying routing logic here.

Consumer acceptance should therefore be sequenced with contextual-orchestrator#1106: immutable CO API/client/schema release first, then this central composite/consumer migration and exact release bump, with callers exposing only gateway token + orchestrator/free; provider credentials/catalog/probing/admission stay with CO. Re-run the unchanged leaf canary after the protected central change. No leaf no-op retrigger or provider-specific fallback is warranted.

[seonghobae]

Fresh unchanged-leaf canary from fast-mlsirm#1519@dfac8acab49845d2328df6cf08d0fc748f2de711 sharpens the consumer acceptance. Required Noema run 34475270437 admitted the exact head, provisioned the sidecar successfully, then failed in Prepare Noema model verdict; retained artifact noema-sidecar-evidence (sha256:5013fa48ead37b7ef5da4c5b01fb4910661953a6569fac666c2cbb37c518e610) is bound to that SHA. The same leaf head now has ordinary CI, Required CodeQL PR, repository CodeQL, Security Scan and Semgrep terminal GREEN; OpenCode therefore correctly issued current-head CHANGES_REQUESTED only because Noema remained RED.

Protected .github/main@cb0872c9a20d5584703dffacca65c096fc034c6c still hard-defaults ORCHESTRATOR_PIN_SHA=414f22973658c4ddc3d4320fcf7acd9b4e8ba991 and the sidecar boundary still receives/validates the five raw provider secrets. Protected contextual-orchestrator has since advanced to a descendant containing merged #1094, but publishes no GitHub Release. Do not repair this by rerunning the leaf, pinning mutable CO main, or retaining provider discovery in the composite. Acceptance remains immutable CO gateway/API/client/schema release → central gateway-token-only orchestrator/free consumer with provider credentials/catalog/probing removed from .github → exact central GREEN → fresh unchanged-leaf Noema/OpenCode verdict.

[seonghobae]

Fresh consumer reconciliation update: contextual-orchestrator now has a concrete narrow #1106 implementation slice, PR #1124@e3482266658ed871476c98cc720ebeabc66ae3da, based exactly on current protected CO main@abc2dea8da61118f4ff31fee214d824458f8cd78. It exposes a versioned review-readiness contract and dedicated regression. This is progress in the owner lane, but it is Draft and CO still publishes no immutable GitHub Release, so .github must not vendor/pin #1124 or mutable CO main as a bridge.

The unchanged consumer canary fast-mlsirm#1519@dfac8acab49845d2328df6cf08d0fc748f2de711 gives a fresh failure specimen against trusted .github@cb0872c9a20d5584703dffacca65c096fc034c6c: Noema exact-head admission and sidecar provisioning succeeded; the sidecar still vendored CO 414f22973658c4ddc3d4320fcf7acd9b4e8ba991. Its local preflight admitted 24 candidates across three accounts and reached ready_count=1, but the one orchestrator/free call terminated HTTP 429 after 131.528 s on served nvidia/llama-3.3-nemotron-super-49b-v1.5. OpenCode dispatched successfully and then failed closed for absence of an authenticated exact-head verdict. Leaf CI, required/repository CodeQL, Security Scan and Semgrep are GREEN.

Keep the central acceptance order strict: complete/protect-integrate #1106's full owner contract → immutable CO API/client/schema release → bump .github to that exact released identity while exposing only gateway bearer + orchestrator/free and deleting consumer-owned provider credentials/catalog/probing/admission/fallback → central exact-head GREEN → unchanged leaf replay. No source-neutral leaf retrigger, raw-provider fallback, mutable-owner pin, or synthetic review receipt.

[seonghobae]

Fresh gateway-only migration canary: fast-mlsirm#1519@3bafc62cf98c9c6dacc1afff0d299626f888330a, Required Noema run 34508861855 / job 102977747307, trusted central source .github@cb0872c9a20d5584703dffacca65c096fc034c6c. The current consumer still injects all five raw provider secrets and vendors contextual-orchestrator@414f22973658c4ddc3d4320fcf7acd9b4e8ba991. Its local preflight produced ready_count=3, deferred_count=4, rejected_count=9, then the one caller request to orchestrator/free failed after 610.1 s with HTTP 502 (phase=response_error, served model google/gemma-4-31b-it) and no publishable Noema verdict. This is direct evidence that the current sidecar/local-discovery boundary remains both stale and behaviorally insufficient despite successful preflight. Keep the migration order unchanged: #1106 executable owner contract -> immutable CO release -> exact released consumer bump using only gateway bearer + orchestrator/free -> unchanged-leaf replay -> legacy provider-secret/probing bootstrap removal. Do not treat leaf rerun, provider-specific fallback, mutable CO pin, or added caller retry as repair evidence.