Migrate review consumers to released orchestrator/free gateway contract

[seonghobae]

Problem

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 not the canonical end state.

Fresh protected authority on 2026-09-13:

• ContextualWisdomLab/.github/main@78393ea901efc0d57b35dd1e383e473425b7c1da is protected. Normal merge chore(sidecar): advance contextual-orchestrator pin to 767e67fb (no implicit model timeout) #2163 advanced the vendored review sidecar from old CO 414f2297... to exact contextual-orchestrator@767e67fbc6b881a452761f32abb69b9971b9b03b.
• ContextualWisdomLab/contextual-orchestrator/main@767e67fbc6b881a452761f32abb69b9971b9b03b is protected after fix(redaction): skip gh run view job/step prefixes #1053 removed the implicit 90-second model request timeout. Default model timeout is now null unless an audited administrator policy sets one.
• This source-SHA bump is an incident repair, not released-contract migration. contextual-orchestrator still has no GitHub Release, and .github still vendors owner source and carries consumer-side provider credential/discovery/admission logic.

A composite action can consolidate sidecar provisioning, but preserving raw provider secrets and local discovery inside the consumer would only consolidate the duplication. It would not satisfy canonical ownership.

Canonical ownership

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

Issue contextual-orchestrator#1106 is the live owner for removing leaf heuristic preflight and moving free-pool admission/routing authority into CO. The immutable release mechanism remains contextual-orchestrator#1030 (ADR 0129). #1030 is still Draft/non-mergeable on stale ancestry and no GitHub Release exists. Do not treat protected CO main, exact source SHA 767e67fb..., or any mutable owner PR/head as released API/client/schema authority.

Current incident evidence

Merged .github#2163 documents the immediate timeout incident: the old vendored CO pin defaulted ModelClient to 90 seconds; model attempts repeatedly terminated at that deadline and review callers eventually received provider-connection failures. CO #1053 repaired the owner-side timeout default and #2163 advanced the central sidecar pin to that protected source.

This removes one known implicit-timeout defect from future sidecar executions, but it does not prove free-pool availability, routing correctness, immutable client/schema compatibility, or released gateway ownership. Fresh unchanged-consumer Noema/OpenCode/Strix evidence is still required after the protected pin movement.

Repair order

1. Complete contextual-orchestrator#1106 (or verified successor) with owner RED→GREEN contracts for credential registration, discovery/admission/routing/TTC ownership and typed failure provenance. Preserve null model timeout by default and distinguish caller cancellation, provider termination, and audited admin timeout.
2. Reconcile the canonical release lane fix(storage): require DNS pinning and reject cluster rebinding hosts #1030 onto the then-current protected CO ancestry after its real prerequisites integrate. Produce an immutable API/client/schema release with version/tag/package, SBOM, provenance, reproducibility, rollback and typed failure semantics.
3. Central .github consumers adopt that exact released contract. Remove raw provider-key inputs, provider inventory/catalog construction, probing/admission thresholds, provider/model/group selection, heuristic TTC/fallback policy, and paid fallback from workflow/composite/script boundaries. Use gateway bearer + orchestrator/free only.
4. Restrict consumer egress to the reviewed gateway plus GitHub/artifact endpoints as applicable and keep failures fail-closed.
5. Verify central exact-head workflow/contract/security evidence, then replay unchanged consumer heads. Require exact checkout binding and authenticated Noema/OpenCode/Strix verdict evidence before merge admission.
6. 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/source-SHA release substitution, self-approval, synthetic success, or gate weakening is acceptance evidence.

Refs #2163, ContextualWisdomLab/contextual-orchestrator#1053, ContextualWisdomLab/contextual-orchestrator#1106, ContextualWisdomLab/contextual-orchestrator#1030.

[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.

[seonghobae]

Fresh unchanged-head consumer evidence from ContextualWisdomLab/LineageWeave#1035@23d2fa07c8edb5bd84d15c742c3698588e7ba97c matches this owner boundary.

Required Noema run 34668887409 successfully admitted the exact live head, resolved the trusted source, minted the repository-scoped reviewer App token, validated the live PR head, and provisioned the contextual-orchestrator review sidecar. Job 103486344997 then failed specifically in Prepare Noema model verdict after the sidecar had been provisioned; the exact-head verdict publication step was skipped and failure evidence was uploaded.

Leaf repository evidence on the same SHA is otherwise strong: LineageWeave Tests 34668892818 are terminal SUCCESS including the real PostgreSQL full suite, PROV-O contract run 34668892850 is GREEN, Security 34668887418 and SAST 34668887355 are GREEN. Treat the Noema result as fail-closed review/model-path evidence, not a LineageWeave source defect and not a reason for a leaf no-op retrigger or provider-specific fallback.

I am not assigning a narrower 429/502/malformed-JSON class without the retained sidecar artifact. Acceptance remains owner-side: released orchestrator/free gateway/client/schema ownership, typed failure provenance, then replay this unchanged leaf head and publish an authenticated exact-head Noema verdict or explicit typed unavailable outcome without copying routing policy into the leaf.

[seonghobae]

Fresh downstream governance drift found in ContextualWisdomLab/Orgmetra exact head af87c0fd21ea5b5443cc552817863f1881843e91: root AGENTS.md still says Use NVIDIA_NIM_API_KEY for model-backed tests and OpenCode development paths. This now conflicts with the canonical consumer boundary tracked here: model-backed GitHub Actions should call only the released contextual-orchestrator gateway using its bearer and model: orchestrator/free, with provider credentials/discovery/routing owned by CO.

I did not edit Orgmetra's global AGENTS file from the active People-domain PR #64 because that would mix repository-governance ownership into the People writer. Please include downstream governance-text reconciliation in the existing migration owner path once the immutable owner contract is available; until then, do not expand the stale direct-provider instruction or treat it as permission for new direct NIM wiring.

[seonghobae]

Fresh consumer canary sharpens the owner boundary with an exact failure mechanism.

.github#2126@51299f1a4398ce8481d14bbb0515dd5367aefaee Required Noema run 34707140933, attempt 3, job 103635607612 admitted the exact live head, minted the repository-scoped reviewer token, validated the head, and provisioned the sidecar successfully. The job then failed only in Prepare Noema model verdict; verdict publication was skipped. The retained noema-sidecar-evidence artifact 10307437409 is bound to that same SHA.

The artifact proves this is not a #2126 scheduler/source finding. Preflight probed 16 of 24 candidates and reached ready_count=4, yet the vendored runtime repeatedly terminated NIM/NIM_SUB provider calls at an almost exact 90-second boundary: 90.088s, 90.101s, 90.104s, 90.105s, 90.051s and 90.079s during preflight, followed by 90.085s and 90.102s failures in the model-verdict path; the final typed result was 502 provider_connection_error. A successful readiness probe therefore did not remove the serving-time cutoff.

Protected .github/main@fb17ef556f94f673234aa557254ae52779e9a7b0 still hard-defaults ORCHESTRATOR_PIN_SHA=414f22973658c4ddc3d4320fcf7acd9b4e8ba991. Protected contextual-orchestrator has advanced to main@012beaacd0631f8cd3391c77744eeb626269b5de (including the protected-integrated review-readiness owner work and the earlier extracted default-timeout repair), but still publishes zero GitHub Releases. Therefore pinning mutable CO main is still not acceptable.

Acceptance remains: ordinary reconciliation of the canonical immutable-release lane to current protected CO main -> immutable CO API/client/schema release -> central gateway-token-only orchestrator/free consumer bump/removal of raw provider credential/catalog/probing ownership -> exact central GREEN -> unchanged #2126 replay producing an authenticated current-head review or typed unavailable result. Do not spend another #2126 rerun against the known stale 414f2297... consumer pin.

[seonghobae]

Fresh current-central acceptance evidence for the migration boundary: .github#2106@611ccd73460ab0188e0085956ade6180bb28a91a Required Noema attempt 2 (34742109506, job 103689361547) still materialized the legacy consumer bridge and logged vendoring contextual-orchestrator @ 414f22973658c4ddc3d4320fcf7acd9b4e8ba991 before model work.

That run passed exact-head admission, reviewer credential selection, live PR validation and sidecar startup, then artifact 10313499693 (sha256:b95f44d2798488afaa8ee0016d7235b4113f352b5b94abf73e5d07248dfa1c83) measured 24 candidates / 16 probed / 1 ready / 11 deferred / 4 rejected. The actual single orchestrator/free caller ended HTTP 429 after 274.3 s with no verdict. This is current evidence that the unreleased vendored SHA plus consumer-local discovery/probing path is still on the production review boundary; it is not authority to bump that SHA to mutable CO main or another PR head.

Keep the repair order in this issue: immutable CO API/client/schema release first, then central consumers adopt that exact released identity and retire raw provider-key/local-discovery ownership. After that integration, rerun unchanged canaries; do not use another leaf wake commit or provider/model/paid fallback.

[seonghobae]

Fresh current-head evidence sharpens this migration issue in two independent ways.

1. .github#2106@611ccd73460ab0188e0085956ade6180bb28a91a Required Noema attempt 2 (run 34742109506, job 103689361547) passed admission, token/head validation and sidecar provisioning, then failed in Prepare Noema model verdict. Retained noema-sidecar-evidence artifact 10313499693 shows candidate_count=24, probed_count=16, ready_count=1, rejected_count=4, gateway ready, with the sole ready route nvidia_nim/google/gemma-4-31b-it; the actual verdict request then terminated with provider HTTP 429 / rate_limit_exceeded. This is no longer a zero-ready preflight failure, but it is still provider/orchestration runtime evidence rather than a fix(codeql): bootstrap versioned dispatch handler #2106 CodeQL source finding.

Protected .github/main@64f483db9d052322c65bcdf1675d66138156f306 still hard-defaults contextual_orchestrator_review_sidecar.sh to ORCHESTRATOR_PIN_SHA=414f22973658c4ddc3d4320fcf7acd9b4e8ba991. Protected CO main@012beaacd0631f8cd3391c77744eeb626269b5de has since integrated directly relevant runtime repairs, including correlated provider-attempt diagnostics, ambiguous passthrough failure classification, and the null/default model-timeout prerequisite (no implicit 90-second cap). Mutable-main pinning is still not acceptable; immutable release → gateway-token-only consumer migration remains the causal path.

2. The same fix(codeql): bootstrap versioned dispatch handler #2106 Strix artifact found a LOW CWE-915 defect in the current legacy consumer policy: parse_discovery_report accepts row-supplied base_url and auth_scheme, overriding canonical PROVIDER_BASE_URLS[provider] / PROVIDER_AUTH_SCHEMES[provider]. A crafted discovery artifact can therefore redirect a credentialed provider route while this legacy local-discovery path exists. The long-term repair is already this issue's architecture: provider endpoint/auth ownership moves behind the released CO gateway and consumers stop constructing provider catalogs. Until that cutover is protected and the legacy path is drained, the current parser should fail closed on endpoint/auth identity (canonical registry only or an explicit immutable owner-issued allowlist); do not accept arbitrary row overrides as a bridge.

Do not rerun the stale 414f runtime repeatedly, pin mutable CO main, or add provider-specific fallback. Preserve this exact #2106 canary through CO #995 → reconciled immutable release #1030 → released central consumer migration, then replay the unchanged leaf/review heads.