chore(ci): advance the vendored orchestrator pin to 012beaac and guard unattested providers

[seonghobae]

Advances the central review sidecar's pinned contextual-orchestrator revision from 414f2297 to 012beaacd0631f8cd3391c77744eeb626269b5de — 175 commits, a clean ancestor of CO main (ahead_by=175, behind_by=0) — synchronously across all four locations that carry it, and closes the latent outage the advance would otherwise create.

Why now

The pin was recorded as waiting on contextual-orchestrator#1053 ("fix(gateway): remove implicit model request timeout"). That premise was wrong, and I am correcting it here rather than leaving it in the record: co#1053 is still open, but its substance landed via 35a428ca in contextual-orchestrator#1118, merged 2026-09-10. ModelClient.__init__'s timeout default is float | None = None at the target and int = 90 at the current pin, so the implicit per-request wall-clock cap that ADR-0003's 2026-08-31 amendment forbids is already gone from the vendored runtime. The blocking condition is satisfied in substance; the form it was recorded in never happened.

Three changes in the range are the reason to take it rather than incidental to it:

1. Output cap becomes per-model. build_review_orchestrator now builds ModelClient() instead of ModelClient(max_output_tokens=32768), and the new effective_max_output_tokens(agent) resolves request-scope → client → the selected agent's provider-published max_output_tokens. A flat 32768 both over-asked models whose published ceiling is lower — a provider 400, which reads as a routing failure — and under-used models with a higher one.
2. request_id correlation. Error payloads and the request_failed log line now carry a request_id. That is the exact field whose absence made Strix run ended "cancelled" at 6h with no verdict: 909 provider attempts, 92% on one route, 0 exhaustion events, request identity absent from evidence #2000's caller-retry question unanswerable from the evidence: with no request identity, a caller re-selecting a dead route is indistinguishable from concurrent requests.
3. Discovery fixes against a single-family pool. The range carries 8586e9aa fix(discovery): recover usable Bytez chat models plus several OpenRouter/models.dev union fixes. The last five recorded free-pool preflights admitted only nvidia_nim/nvidia_nim_sub routes, with Bytez failing discovery at http_status_500 every time ([CO owner] eliminate orchestrator/free provider-family SPOF before gateway release #1915). This does not by itself prove the SPOF is fixed — it makes the next preflight census worth reading.

Evidence the advance is safe

A 175-commit jump on the pin that decides which code the sidecar executes with five provider secrets in its KV should not rest on reading the range. Four properties were executed against the target, not inferred:

Check	Result
git diff 414f2297..012beaac -- requirements.lock	empty — byte-identical, so --require-hashes --no-deps resolves the same wheels
Sidecar startup contract, extracted and run against a 012beaac worktree	passes unmodified
All 11 imported symbols resolved + signatures inspected at target	compatible
ModelClient.__init__ timeout default	float | None = None (was int = 90)

On the lockfile: pyproject.toml's fast-mlsirm spec did move (release tarball → git+https commit pin), but the sidecar never runs pip install -e . — it installs requirements.lock and sets PYTHONPATH — so that spec is not on this execution path.

On the startup contract: this is the check that actually matters, because contextual_orchestrator/orchestrator.py changed +1092/-251 in the range and the sidecar's python - <<'PY' block subclasses ModelClient, overrides proxy_send, and calls the private _mock_raw. I extracted the heredoc verbatim and ran it with PYTHONPATH pointed at a 012beaac worktree: the 413 envelope, the 64 KiB+ accepted body, and the byte-exact tool-description passthrough all still hold. Note this also survives a real format change — the request_failed log line gained request_id=…, and the contract's substring assertion still matches.

On the discovery shape: DiscoveredModel is purely additive (one new supports_parallel_tool_calls field, all existing fields unchanged and in order), and the launcher reads every discovery field through getattr with a default.

The risk the advance creates, and the guard

012beaac ships two new provider sources — opencode_zen and opencode_go, both keyed on an optional OPENCODE_ZEN_API_KEY — and review_gateway.REVIEW_CREDENTIAL_NAMES now defaults to PROVIDER_ACCEPTED_CREDENTIAL_NAMES. The launcher calls register_review_credentials(os.environ) with the full process environment, so that key would be registered straight out of the job environment if it were ever present.

scripts/ci/zdr_policy.py has no entry for either provider, and contextual_orchestrator_review_policy.parse_discovery_report raises PolicyError for an unregistered provider rather than skipping the row. So adding that one secret to a workflow's env: would have failed every central review sidecar closed — on a provider nobody had asked to route to.

The secret is not seeded today, so nothing is failing. The exposure is latent and one line of workflow YAML away, which is why it is fixed in the same change that creates it.

_report_rows now drops a discovered row whose provider is absent from the org ZDR policy table, with a bounded discovery_row_skipped_unattested_provider provider=<name> model=<id> stderr diagnostic. The safety property is unchanged and is the point: an unattested provider still never serves review traffic, and parse_discovery_report keeps its fail-closed contract verbatim for rows that are submitted — one of the six new tests pins exactly that, so the launcher guard cannot later be mistaken for a policy relaxation. Attesting OpenCode Zen/Go for the free pool needs a real retention-posture determination for opencode.ai; it is deliberately not granted here and must not be inferred from this PR.

Also in this change

ADR-0003 item 1 has been broken prose since f8823a54 (#1364): that commit inserted the requirements.lock sentences after "into RUNNER_TEMP. The", orphaning the pre-existing "runtime entry (…) registers the five provider secrets" line from its subject. Restored from that commit's parent text — I am amending this exact ADR item, so leaving the sentence broken underneath the amendment was not an option.

Verification

3045 passed, 1 skipped, 36 subtests passed
coverage: 100%   interrogate: RESULT: PASSED (minimum: 100.0%, actual: 100.0%)
bash -n scripts/ci/contextual_orchestrator_review_sidecar.sh — OK

New: tests/test_contextual_orchestrator_review_unattested_provider_skip.py (6 cases).

Not in this change

• CHANGELOG.md is structurally broken on main and I did not repair it here. # Changelog sits at line 162, with 161 lines of entries prepended above the file title, plus a duplicate ## [Unreleased] at line 70 and a dated release section at 155 stranded between them. Successive PRs have been prepending to line 1 rather than under the real ## [Unreleased] at line 170. My entry follows the established (wrong) convention so it sits with its peers and the eventual repair stays one coherent change; filing separately.
• contextual_orchestrator/review_gateway.py at 012beaac annotates review_pool_admissions(agents: Sequence[Any]) without importing Any. Inert at runtime under from __future__ import annotations, but it breaks typing.get_type_hints(). Upstream nit, filing on CO.

Refs #1915, #2000, ContextualWisdomLab/contextual-orchestrator#1118.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KPmJErfkcHer4UVEgrQxUX

---

Generated by Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[seonghobae]

CodeQL compatibility analysis (python) and (actions) — red on the base branch, not this PR's

Failing checks on 3d39fe7c: CodeQL compatibility analysis (python) and (actions). Everything else on this head is green or still running: 22 success, 2 in progress (noema-review, strix), 1 queued, 5 skipped.

Why it is not this PR's. The base branch is red on the same class. main@fb17ef556f94f673234aa557254ae52779e9a7b0 — this PR's merge base — carries roughly two dozen CodeQL dispatch scan (…) check runs across python, actions, and javascript-typescript, and every one of them is failure. The eight most recent CodeQL Scan Dispatch workflow runs org-wide are completed/failure. This PR's diff is a vendored-revision pin, one launcher guard, and docs; it touches no CodeQL workflow, no scan configuration, and no query.

Root cause, established from the logs rather than assumed. The scan is not what fails. In run 34733576667 (job 103660988908) the database builds, 45 query packs load, Exporting results to SARIF... completes, and the artifact uploads. It then fails at the final publication step, on both credentials:

##[notice] CodeQL dispatch status publish using target-app-token did not succeed:
           gh: Resource not accessible by integration (HTTP 403)
##[notice] CodeQL dispatch status publish using github-token did not succeed:
           gh: Resource not accessible by integration (HTTP 403)
##[error]  Could not publish the CodeQL dispatch status after all configured credentials
           failed; the exact required job will remain failed and will not be woken.

The refused call is POST /repos/${TARGET_REPOSITORY}/statuses/${HEAD_SHA}. The matrix job already declares the permission it is refused (codeql-scan-dispatch.yml:279-284 — statuses: write, actions: write), and TARGET_REPOSITORY is .github itself, so this is not the cross-repo case where GITHUB_TOKEN would have no standing. Because publication is what wakes the required check, CodeQL compatibility analysis (<lang>) here fails fast by design and then never gets woken.

No fix exists for me to port. #2040 is the open work on this producer/handler cycle, but it is another owner session's lane (150 commits, 29 files) and porting it into a pin advance would not be a fix, it would be a different PR. More to the point, the evidence says the blocker is not in the code this PR could carry: a declared statuses: write being refused 403 in its own repository points at an org- or repo-level workflow-permission cap plus a missing statuses grant on the App installation — owner settings. I have posted that evidence on #2040 and flagged it there as the hypothesis the logs point to, not a verified finding, because I have not read those settings.

On the one permitted re-run: deliberately unspent. A 403 on a fixed endpoint with two fixed credentials is deterministic, and the base-branch evidence above already settles the "not this PR's" question on its own. Burning a runner to watch the same call be refused would add nothing. The re-run stays available if something changes and it becomes informative.

What happens to this PR. Nothing on my side unblocks these two checks; they turn green when the publication credential does. This PR stays watched and I will re-check at each check-in — if the required checks are woken and this head's scan reports cleanly, they resolve without another push. Dispatch current-head CodeQL scan is still queued on this head, so the sequence has not finished yet either.

Refs #1929, #2040.

---

Generated by Claude Code

[seonghobae]

Hold: production evidence shows this pin removes a bound nothing replaces

I found this after opening the PR, while root-causing #1884's noema-review failure. It is a real exposure this change carries, and it belongs here before any merge.

What I claimed in the PR body. Under "Evidence the advance is safe" I listed, as a reason to take the pin: ModelClient.__init__'s timeout default moving from int = 90 to float | None = None, "so the implicit per-request wall-clock cap this ADR's 2026-08-31 amendment forbids is gone from the vendored runtime." That is accurate and the removal is correct. What I did not check is what the 90 s cap is currently doing.

It is doing a lot. #1884 head e85fc437, run 34732993973, sidecar stderr artifact 10310273053. Serving phase 02:41:17Z → 02:56:27Z, 907.3 s, ending HTTP 503. Fifteen provider attempts inside it, and the attempt→failure durations:

  90.0s   90.0s   22.0s   90.0s   90.0s
  90.0s   90.0s   90.0s   90.0s    0.0s

Eight of ten land on exactly 90.0 s. Roughly 720 of the 907 seconds is that default expiring against endpoints that never respond. The cap is what turns a black-holed provider socket into a bounded, diagnosable failure.

Nothing below six hours replaces it at the target pin.

layer	bound
ModelClient default @ 012beaac	timeout: float | None = None
contextual_orchestrator_review_launcher.py:1240 (serving client)	passes no timeout
noema-review.yml:261	"No job-level timeout-minutes here, deliberately."
GitHub job ceiling	6 h

So this PR, as written, would convert #1884's failure mode from "15 minutes, bounded, 503, full attempt trace" into a single open attempt that can hold a review runner for hours with no verdict. Every central review job inherits that.

I am not proposing to re-add a timeout. Passing an explicit timeout= at the launcher's serving call site would reinstate the reverted cap under a different name — #1889/#1890/#1892 all did a version of that on genuine hang evidence and were all reverted (#1891, #1895), and docs/product-goal-directive.md §8 is explicit that elapsed inference time must never become a model-failure verdict. The directive names the alternative: bound occupancy at the admission/continuation boundary. That work does not exist yet, so I filed it as #2139 with the evidence and a proposed shape (bound progress — an idle-socket bound reset on every byte — rather than total elapsed time, so a legitimately slow model is never interrupted).

Two smaller corrections to this PR's body, since they were part of my case for the advance and one of them was wrong:

• I wrote that the range's request_id correlation and provider_one_shot_call_failed would improve the evidence. provider_one_shot_call_failed is not new — it is present at the current pin 414f2297 and appears throughout the trace above. I inferred it was new from the sanitizer's allowlist rather than checking the source. The request_id half stands.
• Separately verified and fine: I checked whether the target pin's log templates would survive sanitize_contextual_orchestrator_sidecar_stream.py. All eleven provider_*/circuit_* templates at 012beaac are admitted, request_id is preserved, error_message still omitted. main already handles the optional request_id and provider_one_shot_call_failed. No drift, nothing needed.

Where that leaves this PR. The rest of the change stands on its evidence — the byte-identical lockfile, the startup contract executing green against 012beaac, the eleven-symbol signature check, the unattested-provider guard. Staying draft until #2139 is decided. The options, for the owner:

1. land Removing the implicit 90 s model timeout leaves review runner occupancy unbounded — needs an admission/continuation bound first #2139's occupancy bound first, then this;
2. land this and accept a window where a hung provider can hold a review runner up to 6 h;
3. split the guard and the ADR repair out of here and let them land now, leaving only the pin bump blocked on Removing the implicit 90 s model timeout leaves review runner occupancy unbounded — needs an admission/continuation bound first #2139.

I lean (1), and (3) is a cheap consolation if #2139 will take a while — the unattested-provider guard closes its own latent outage and does not depend on the pin moving. Say the word and I will split it. Not merging past this on my own judgment.

Refs #1884, #1915, #2139.

---

Generated by Claude Code

[seonghobae]

Correction: the CodeQL diagnosis above was wrong, and this PR is nearly green

My standing-down comment said these checks "turn green when the publication credential does" and that nothing on my side unblocks them. Both wrong. Current state:

check	was	now
CodeQL compatibility analysis (actions)	failure	success 03:13:05Z
noema-review	in progress	success 03:10:36Z
opencode-review	in progress	success 02:53:32Z
CodeQL compatibility analysis (python)	failure	failure
strix	in progress	in progress

24 success, 1 failure, 1 in progress, 1 queued.

Where I went wrong. I cited run 34733576667 as a .github-targeting dispatch. It targets naruon. The dispatch workflow runs in .github, so its jobs post check runs on .github's head whatever repository they scan, and I read that list without checking each run's target. The base-branch redness I leaned on is largely other repositories' scans.

What the wake step actually does. The 403 on POST /statuses/<sha> is real, but it is not terminal — the code falls through to POST /actions/jobs/{id}/rerun, and for a same-repository target that works. This PR's own dispatch, run 34734286494, proves it in one run:

• CodeQL dispatch scan (actions) → publish 403 → rerun succeeded (CodeQL job status was success) → required check green.
• CodeQL dispatch scan (python) → publish 403 → rerun refused: gh: The workflow run containing this job is already running (HTTP 403).

Same run, same credentials, same repository, opposite outcomes — which rules out the permission cap I hypothesised. POST /actions/jobs/{id}/rerun re-runs the containing run, both shards target jobs in run 34733728747, so whichever shard arrives first wins and the second is refused. That is the inter-shard race #2051 and #2056 are written to fix, not an owner setting.

On the re-run I said I was saving. With the race passed it became informative, so I used it — and GitHub refused: 403 This workflow is already running. Something is already re-running that run, so the python shard may yet be woken without my help. Effectively unspent; I will not spend it again while the run is active.

What this does not change. #2139 stands untouched. The occupancy exposure is about ModelClient's timeout default going to None with no bound below the 6-hour job ceiling, and none of today's CodeQL findings bear on it. This PR stays draft and held on that question, not on CodeQL. The three options in my previous comment are unchanged, and I still lean on landing #2139's bound first.

What I got right and am not re-litigating: the cross-repo half. For naruon and contextual-orchestrator the wake exits at Actions-capable CodeQL wake credential is unavailable and never reaches the rerun, so sibling repositories are blocked on a genuinely different thing. Details and the full retraction are on #2040.

---

Generated by Claude Code

[seonghobae]

The python CodeQL scan on this head is clean — the red is a false verdict

The re-run I queued came back failure again, but with a different reason than before, and it is worth being precise because the wording is alarming and wrong:

DISPATCH_OUTCOME: success
VERDICT_STATE:    failure
##[error] CodeQL dispatch scan for python did not pass (state=failure).
          See the linked dispatch run for SARIF evidence.

There is no such SARIF evidence. In dispatch run 34734286494, job CodeQL dispatch scan (python), every step of the analysis passed:

  8 success  Initialize CodeQL
  9 success  Perform CodeQL Analysis
 10 success  Enforce CodeQL Medium+ SARIF gate   <-- passed
 11 success  Preserve CodeQL SARIF evidence
 12 success  Publish CodeQL dispatch status
 13 failure  Wake exact CodeQL required job      <-- only this

The job's conclusion is failure from step 13 alone, and the required check reads that job conclusion as the verdict (job_conclusion | … | echo "verdict=${job_conclusion}"). So a scan that cleared the Medium+ gate is reported as a scan that did not pass. Filed as #2141, separately from the wake race in #2051/#2056 — the race delays a check, this misreports one.

For this PR specifically: CodeQL found nothing in the diff. That is now positive evidence rather than an open question, which is the one useful thing the re-run bought.

On the re-run budget. This was the second failure of that shard, so by my own statement I am not re-running it again — a third attempt would produce the same false verdict from the same clean scan. Nothing here is fixable inside this PR: the defect is in codeql-scan-dispatch.yml, which is #2040's surface and which I am not touching.

Status of this PR is unchanged in substance: 25 success, this one false red, strix still running. It remains held on #2139/#2140 — the runner-occupancy question — and not on CodeQL. ADR-0030 is now drafted at #2140 if the sequencing question is what you were waiting on.

Refs #2140, #2141.

---

Generated by Claude Code