Repository navigation
Migrate review consumers to released orchestrator/free gateway contract #1759
Description
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@78393ea901efc0d57b35dd1e383e473425b7c1dais protected. Normal merge chore(sidecar): advance contextual-orchestrator pin to 767e67fb (no implicit model timeout) #2163 advanced the vendored review sidecar from old CO414f2297...to exactcontextual-orchestrator@767e67fbc6b881a452761f32abb69b9971b9b03b.ContextualWisdomLab/contextual-orchestrator/main@767e67fbc6b881a452761f32abb69b9971b9b03bis 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-orchestratorstill has no GitHub Release, and.githubstill 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
- 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. - 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.
- Central
.githubconsumers 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/freeonly. - Restrict consumer egress to the reviewed gateway plus GitHub/artifact endpoints as applicable and keep failures fail-closed.
- 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.
- 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.
Activity
seonghobae commentedon Sep 5, 2026
Fresh owner-boundary evidence (2026-09-05 UTC; all remembered snapshots discarded):
.github/mainis6d7fbebec8aec31d88a30a36e71ca5b3925d241d.newsdom-api#682is still open/Draft at unchanged head585bb4e0fb719ab6a576cf46d1ef12b77872557b. Its failed required Strix run32638076034/ job97190711585is predecessor evidence from 2026-08-23. The exact log proves the old trusted workflow selectednvidia_nim/nvidia/nemotron-3-super-120b-a12b, received NVIDIA HTTP 429, then attempted NVIDIA andopenai-direct/gpt-5.6-lunafallbacks while harden-runner reportedegress-policy: audit. This is provider infrastructure evidence, not a NewsDOM source vulnerability.strix.ymlno longer uses that old model selector: it fixescontextual-orchestrator/orchestrator/freeand a loopback gateway. But the provisioning step still injectsBYTEZ_API_KEY,NVIDIA_NIM_API_KEY,NVIDIA_NIM_API_KEY_SUB,OPENROUTER_API_KEY, andOPENAI_API_KEY;scripts/ci/contextual_orchestrator_review_sidecar.shfails unless at least one is present, clones a pinned CO source tree, and performs provider discovery locally. The Strix job also remainsegress-policy: audit.Therefore the safe dependency order is:
orchestrator/free; it must emit typed source-finding vs provider/gateway/capability outcomes and remain fail closed.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 commentedon Sep 6, 2026
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 at414f22973658c4ddc3d4320fcf7acd9b4e8ba991, 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 directnvidia_nim,nvidia_nim_sub, andopenrouter; Bytez discovery also reportedhttp_status_500. The sidecar exited before/healthz, so “Run Strix (quick)” never produced source analysis.Live prerequisites remain absent: protected CO
main@414f22973658c4ddc3d4320fcf7acd9b4e8ba991has no tags/releases, and protected.github/main@43024633eba9d96b0456970391360da5a171fbdastill uses runtime source vendoring/direct provider secrets andegress-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 commentedon Sep 10, 2026
Fresh integration evidence tightens this consumer issue.
fast-mlsirm#1519@84000d861ddc9b8cc72a39e7c78f8016051e0e6c, Required Noema run34469361714/ job102845420373, executed trusted.github@cb0872c9a20d5584703dffacca65c096fc034c6cand loggedvendoring contextual-orchestrator @ 414f22973658c4ddc3d4320fcf7acd9b4e8ba991. That exact central source still hard-defaultsORCHESTRATOR_PIN_SHAto414f2297…and bootstraps the sidecar with five raw provider secrets.The review preflight did become ready, but the actual
orchestrator/freerequest failed after 182.4 s with HTTP 429 (response_error, servedgoogle/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 commentedon Sep 10, 2026
Fresh unchanged-leaf canary from
fast-mlsirm#1519@dfac8acab49845d2328df6cf08d0fc748f2de711sharpens the consumer acceptance. Required Noema run34475270437admitted the exact head, provisioned the sidecar successfully, then failed inPrepare Noema model verdict; retained artifactnoema-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-headCHANGES_REQUESTEDonly because Noema remained RED.Protected
.github/main@cb0872c9a20d5584703dffacca65c096fc034c6cstill hard-defaultsORCHESTRATOR_PIN_SHA=414f22973658c4ddc3d4320fcf7acd9b4e8ba991and 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-onlyorchestrator/freeconsumer with provider credentials/catalog/probing removed from.github→ exact central GREEN → fresh unchanged-leaf Noema/OpenCode verdict.[-]Migrate Strix/OpenCode/Noema/autofix sidecar steps to the orchestrator-free-sidecar composite action[/-][+]Migrate review consumers to released orchestrator/free gateway contract[/+]seonghobae commentedon Sep 10, 2026
Fresh consumer reconciliation update: contextual-orchestrator now has a concrete narrow #1106 implementation slice, PR
#1124@e3482266658ed871476c98cc720ebeabc66ae3da, based exactly on current protected COmain@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.githubmust not vendor/pin #1124 or mutable CO main as a bridge.The unchanged consumer canary
fast-mlsirm#1519@dfac8acab49845d2328df6cf08d0fc748f2de711gives a fresh failure specimen against trusted.github@cb0872c9a20d5584703dffacca65c096fc034c6c: Noema exact-head admission and sidecar provisioning succeeded; the sidecar still vendored CO414f22973658c4ddc3d4320fcf7acd9b4e8ba991. Its local preflight admitted 24 candidates across three accounts and reachedready_count=1, but the oneorchestrator/freecall terminated HTTP 429 after 131.528 s on servednvidia/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
.githubto that exact released identity while exposing only gateway bearer +orchestrator/freeand 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 commentedon Sep 10, 2026
Fresh gateway-only migration canary:
fast-mlsirm#1519@3bafc62cf98c9c6dacc1afff0d299626f888330a, Required Noema run34508861855/ job102977747307, trusted central source.github@cb0872c9a20d5584703dffacca65c096fc034c6c. The current consumer still injects all five raw provider secrets and vendorscontextual-orchestrator@414f22973658c4ddc3d4320fcf7acd9b4e8ba991. Its local preflight producedready_count=3,deferred_count=4,rejected_count=9, then the one caller request toorchestrator/freefailed after 610.1 s with HTTP 502 (phase=response_error, served modelgoogle/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 commentedon Sep 12, 2026
Fresh unchanged-head consumer evidence from
ContextualWisdomLab/LineageWeave#1035@23d2fa07c8edb5bd84d15c742c3698588e7ba97cmatches this owner boundary.Required Noema run
34668887409successfully 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. Job103486344997then failed specifically inPrepare Noema model verdictafter 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
34668892818are terminal SUCCESS including the real PostgreSQL full suite, PROV-O contract run34668892850is GREEN, Security34668887418and SAST34668887355are 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/freegateway/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 commentedon Sep 12, 2026
Fresh downstream governance drift found in
ContextualWisdomLab/Orgmetraexact headaf87c0fd21ea5b5443cc552817863f1881843e91: rootAGENTS.mdstill saysUse 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 andmodel: 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 commentedon Sep 13, 2026
Fresh consumer canary sharpens the owner boundary with an exact failure mechanism.
.github#2126@51299f1a4398ce8481d14bbb0515dd5367aefaeeRequired Noema run34707140933, attempt 3, job103635607612admitted the exact live head, minted the repository-scoped reviewer token, validated the head, and provisioned the sidecar successfully. The job then failed only inPrepare Noema model verdict; verdict publication was skipped. The retainednoema-sidecar-evidenceartifact10307437409is 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 was502 provider_connection_error. A successful readiness probe therefore did not remove the serving-time cutoff.Protected
.github/main@fb17ef556f94f673234aa557254ae52779e9a7b0still hard-defaultsORCHESTRATOR_PIN_SHA=414f22973658c4ddc3d4320fcf7acd9b4e8ba991. Protected contextual-orchestrator has advanced tomain@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/freeconsumer 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 stale414f2297...consumer pin.seonghobae commentedon Sep 13, 2026
Fresh current-central acceptance evidence for the migration boundary:
.github#2106@611ccd73460ab0188e0085956ade6180bb28a91aRequired Noema attempt 2 (34742109506, job103689361547) still materialized the legacy consumer bridge and loggedvendoring contextual-orchestrator @ 414f22973658c4ddc3d4320fcf7acd9b4e8ba991before 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 singleorchestrator/freecaller 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 commentedon Sep 13, 2026
Fresh current-head evidence sharpens this migration issue in two independent ways.
.github#2106@611ccd73460ab0188e0085956ade6180bb28a91aRequired Noema attempt 2 (run34742109506, job103689361547) passed admission, token/head validation and sidecar provisioning, then failed inPrepare Noema model verdict. Retainednoema-sidecar-evidenceartifact10313499693showscandidate_count=24,probed_count=16,ready_count=1,rejected_count=4, gatewayready, with the sole ready routenvidia_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@64f483db9d052322c65bcdf1675d66138156f306still hard-defaultscontextual_orchestrator_review_sidecar.shtoORCHESTRATOR_PIN_SHA=414f22973658c4ddc3d4320fcf7acd9b4e8ba991. Protected COmain@012beaacd0631f8cd3391c77744eeb626269b5dehas 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.parse_discovery_reportaccepts row-suppliedbase_urlandauth_scheme, overriding canonicalPROVIDER_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.