fix(strix): recognize orchestrator/auto in is_contextual_orchestrator_model

[seonghobae]

Root cause

Every PR-scoped Strix run across the org has been failing identically since
#1401 merged, e.g.:

ERROR: LLM_API_BASE must be an https URL when configured.
##[error]Process completed with exit code 2.

Confirmed on #1414, #789, #1382, #1276 and others (identical signature:
"Strix Security Scan/strix: failure — Default-branch repository_dispatch
Strix evidence failed").

#1401 renamed Strix's primary model from orchestrator/free to
orchestrator/auto throughout strix.yml and its contract tests, but did
not update scripts/ci/strix_quick_gate.sh's is_contextual_orchestrator_model(),
which still only recognized the old orchestrator/free spelling. That made
resolved_llm_api_base_for_model() treat orchestrator/auto as a
non-gateway model, so its https-only check rejected the legitimate pinned
loopback sidecar base (http://127.0.0.1:18080/v1) the workflow always
provisions for the contextual-orchestrator provider — failing the gate with
exit code 2 before a scan could even start.

This didn't fail #1401's own CI because pull_request_target required
workflows run the base branch's trusted workflow file — #1401's own run
used the pre-rename strix.yml. The new-workflow / old-gate-script mismatch
only became observable on every PR opened after #1401 merged into main.

Fix (scripts/ci/strix_quick_gate.sh)

• is_contextual_orchestrator_model(): also recognize orchestrator/auto
  and contextual-orchestrator/orchestrator/auto, alongside the existing
  orchestrator/free spellings. CONTEXTUAL_ORCHESTRATOR_POOL supports both
  free and auto, and contextual_orchestrator/orchestrator.py's
  TaskOrchestrator.AUTO_MODEL / FREE_MODEL are both real sentinels the
  gateway itself distinguishes by this exact model string.
• child_model_for_api_base(): qualify the child-process model from the
  actual resolved $model instead of a hardcoded openai/orchestrator/free
  literal — otherwise a scan configured for the auto pool would silently
  keep asking the gateway for the free pool regardless of
  CONTEXTUAL_ORCHESTRATOR_POOL.
• Two STRIX_PROVIDER_UNAVAILABLE log lines now name whichever model was
  actually primary instead of hardcoding orchestrator/free.

Tests

• New mirrored orchestrator/auto qualification scenario in
  scripts/ci/test_strix_quick_gate.sh (added to the function-dispatch case,
  the STRIX_TEST_CASE_FILTER-driven dispatch, and the flat sequential run),
  alongside the pre-existing orchestrator/free case.
• New Python regression test in tests/test_strix_openai_fallback_api_base.py
  (test_workflow_gateway_base_accepts_auto_pool_model) exercising
  resolved_llm_api_base_for_model() directly against orchestrator/auto.

Validation

• python3 -m pytest tests -q: 1874 passed, 1 skipped — no regressions vs.
  the pre-fix baseline (confirmed by running the identical suite on
  unmodified main).
• interrogate: RESULT: PASSED (100%).
• coverage report: pre-existing 1-line gap in
  scripts/ci/pingora_edge_policy.py (line 274, an unreachable

  3,000-file pagination guard) reproduces identically on unmodified
  main — unrelated to this change, not introduced by it.

• Targeted scripts/ci/test_strix_quick_gate.sh scenarios via
  STRIX_TEST_CASE_FILTER (contextual-orchestrator-gateway-model-qualification,
  the new -auto variant, and contextual-orchestrator-missing-api-base-fails-closed)
  all pass with no scenario-specific failures. The suite's one remaining
  failure — an unrelated opencode-review.yml bootstrap shape-drift
  assertion — reproduces identically on unmodified main and is out of
  scope here.

Known limitation: this PR's own Strix check

Per CLAUDE.md's "pull_request_target trust boundary" note and the
identical situation documented in #1401's own description: this PR's Strix
check runs against the current (buggy) main gate script, since
pull_request_target required workflows execute the base branch's trusted
scripts rather than this PR's head. So this PR is expected to reproduce the
exact same pre-existing failure it fixes, on its own check, until it merges
— the same trusted-workflow deadlock #1401 hit and documented. All other
required checks (security scans, CodeQL, OpenCode review) are expected to
be unaffected and should be evaluated on their own merits.

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

---

Generated by Claude Code

---

[coderabbitai]

Warning

Review limit reached

Next included review available in 5 minutes.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: de6e3336-3dd1-4df5-b171-ae87f0041580

📥 Commits

Reviewing files that changed from the base of the PR and between 6c8ee24 and ac5eca4.

📒 Files selected for processing (8)

• .github/workflows/opencode-review.yml
• CHANGELOG.md
• docs/product-technical-gap-baseline.md
• scripts/ci/strix_quick_gate.sh
• scripts/ci/test_strix_quick_gate.sh
• tests/test_pingora_edge_policy.py
• tests/test_pingora_edge_workflow_contract.py
• tests/test_strix_openai_fallback_api_base.py

---

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]

opencode-review failing on this exact head is expected, not a defect in this diff. Its job log shows it's a gate that checks for an existing opencode-agent review (APPROVED/CHANGES_REQUESTED) on head d1c587b:

::error::No APPROVED or CHANGES_REQUESTED from opencode-agent on the current head. This required check is not a review and must not succeed until the authenticated dispatch posts a current-head verdict.

The PR was opened only seconds before this check ran, so the async OpenCode review dispatch hadn't had a chance to post a verdict yet — there's nothing in the diff to fix here. Re-running now would just reproduce the same result (not a flake, so I'm not spending the one re-run on it). I'll keep this PR watched and act once the actual OpenCode verdict lands and/or Strix, CodeQL, and the other in-flight checks complete.

---

Generated by Claude Code

---

Generated by Claude Code

[seonghobae]

Verified Devin's finding on child_model_for_api_base (line 2575) — confirmed real: is_contextual_orchestrator_model() accepts both orchestrator/auto and the provider-prefixed contextual-orchestrator/orchestrator/auto, but the qualifier wasn't stripping that prefix, so the provider-prefixed spelling produced openai/contextual-orchestrator/orchestrator/auto instead of the gateway's expected openai/orchestrator/auto.

Pushed a fix (${model#contextual-orchestrator/}) plus a new regression scenario (contextual-orchestrator-gateway-model-qualification-auto-prefixed, mirrored across all three dispatch sites per this file's convention). Confirmed the new scenario fails with the exact reported mismatch on the pre-fix code and passes after; full suite otherwise unchanged (the one remaining failure is the pre-existing, unrelated opencode-review.yml bootstrap assertion already noted in this PR's description, which also reproduces on unmodified main).

---

Generated by Claude Code

---

Generated by Claude Code

[seonghobae]

The strix check failure on this head (and any repeat of it on future pushes to this branch) is the documented known limitation from this PR's description, not a new or fixable defect: pull_request_target-triggered required workflows run main's currently-buggy strix_quick_gate.sh/is_contextual_orchestrator_model(), which is exactly what this PR fixes. There is no code change within this PR's own diff that can make its own Strix check pass — it can only go green after this PR merges into main and a subsequent push re-runs it there. This is the same pull_request_target trust-boundary deadlock #1401 hit and documented in CLAUDE.md.

All other required checks (CodeQL, security scans, OpenCode review, dependency review, etc.) are unaffected by this and should be evaluated normally. Resolving this specific check needs either a maintainer/admin merge decision that accounts for the deadlock, or an org-level process for this situation — I don't have a safe way to make this PR's own Strix run pass without bypassing the gate, which I won't do. Keeping this PR watched; I won't re-comment on further repeats of this same expected strix failure.

---

Generated by Claude Code

---

Generated by Claude Code

[seonghobae]

noema-review failed on this head with:

request_failed status=413 code=request_too_large
[contextual-orchestrator-sidecar] using live OpenRouter ZDR endpoint feed
[contextual-orchestrator-sidecar] error: sidecar exited before healthz (status 1); stderr: review sidecar preflight failed

This is not a defect in this PR's diff — it's a shared-infrastructure failure in scripts/ci/contextual_orchestrator_review_sidecar.sh's route preflight, already being tracked by #1415 ("fix(noema): batch sidecar route preflight"), which targets exactly this 413/route-preflight failure mode. However #1415's own current head still shows noema-review failing too (a different symptom there — HTTP 502 from the live gateway rather than 413), so there is no confirmed-green fix yet to port into this PR, and pulling its 16-file/739-line change into this PR would badly widen an otherwise narrow, unrelated fix. Not spending the one re-run here either — this reproduces a known, already-diagnosed condition rather than a one-off flake. Leaving this to resolve via #1415 (or a further fix on top of it) rather than duplicating that work here; keeping this PR watched.

---

Generated by Claude Code

---

Generated by Claude Code

[devin-ai-integration]

Devin Review found 2 new potential issues.

[seonghobae]

Ported #1414's fix into this branch: removed the redundant if: ${{ github.event_name == 'pull_request_target' }} guard on the "Enforce Cloudflare Pingora edge policy" step inside required-workflow-bootstrap. That guard was tripping test_strix_quick_gate.sh's bootstrap contract (which correctly rejects any if: inside that job) on every push to this branch, showing up as the exact-head-path-policy failure.

Why port rather than wait for #1414 to merge: #1414 hits the identical pull_request_target deadlock in the other direction — its own Strix check needs this PR's orchestrator/auto fix landed on main first. Neither PR could get fully green waiting on the other, so this PR now carries both fixes and should clear exact-head-path-policy on its own.

Full local validation on the combined change: coverage run -m pytest tests → 1876 passed / 1 skipped; bash scripts/ci/test_strix_quick_gate.sh → full PASS, no bootstrap-guard failure. This PR's own strix check will still fail until merge (documented deadlock, unrelated to this addition) and noema-review remains blocked on the separate shared sidecar issue (tracked in #1415 and, per a broader finding this session, likely a stale vendored contextual-orchestrator pin in scripts/ci/contextual_orchestrator_review_sidecar.sh — will open a dedicated fix for that separately).

---

Generated by Claude Code

---

Generated by Claude Code

[opencode-agent]

Pull request overview

OpenCode could not approve from deterministic current-head evidence because GitHub Checks have failed.

Findings

1. HIGH Current-head GitHub Checks - Fix failed required checks before approval

• Problem: Failed same-head checks remain for ac5eca40071835a4ce42355d305c7da1b3145308.
• Root cause: The model-unavailable evidence fallback is allowed only when peer GitHub Checks are complete and clean.
• Fix: Read and fix the failed check logs below, then rerun the current-head checks.
• Regression test: Keep the model-unavailable fallback gated on an empty failed-check rollup.

Failed checks:

• Required Noema Review/noema-review: FAILURE (https://github.com/ContextualWisdomLab/.github/actions/runs/33290820461/job/99202021322)
• Strix Security Scan/strix: FAILURE (https://github.com/ContextualWisdomLab/.github/actions/runs/33290820383/job/99202021270)
• Strix Security Scan/strix: failure (https://github.com/ContextualWisdomLab/.github/actions/runs/33290820383/job/99202021270)
• noema-review check run: failure (https://github.com/ContextualWisdomLab/.github/actions/runs/33290820461/job/99202021322)

Changed-File Evidence Map

flowchart LR
  PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
  Evidence --> S1["Workflow: opencode-review.yml"]
  S1 --> I1["GitHub Actions review job"]
  I1 --> R1["Review risk: Workflow: opencode-review.yml"]
  R1 --> V1["actionlint plus required checks"]
  Evidence --> S2["Repository file: CHANGELOG.md"]
  S2 --> I2["repository behavior"]
  I2 --> R2["Review risk: Repository file: CHANGELOG.md"]
  R2 --> V2["required checks"]
  Evidence --> S3["Docs: product-technical-gap-baseline.md"]
  S3 --> I3["operator or user guidance"]
  I3 --> R3["Review risk: Docs: product-technical-gap-baseline.md"]
  R3 --> V3["docs review"]
  Evidence --> S4["CI script: strix_quick_gate.sh"]
  S4 --> I4["review and security gate shell path"]
  I4 --> R4["Review risk: CI script: strix_quick_gate.sh"]
  R4 --> V4["bash -n plus Strix self-test"]
  Evidence --> S5["CI script: test_strix_quick_gate.sh"]
  S5 --> I5["review and security gate shell path"]
  I5 --> R5["Review risk: CI script: test_strix_quick_gate.sh"]
  R5 --> V5["bash -n plus Strix self-test"]
  Evidence --> S6["Test: test_pingora_edge_policy.py (3 files)"]
  S6 --> I6["regression suite"]
  I6 --> R6["Review risk: Test: test_pingora_edge_policy.py (3 files)"]
  R6 --> V6["targeted test run"]

Loading

[opencode-agent]

OpenCode Review Overview

• Head SHA: ac5eca40071835a4ce42355d305c7da1b3145308
• Workflow run: 33291069178
• Workflow attempt: 1
• Gate result: REQUEST_CHANGES
• Coverage gate: success
• Model pool: unknown
• Verdict: REQUEST_CHANGES
• Formal review: fix(strix): recognize orchestrator/auto in is_contextual_orchestrator_model #1421 (review)

[seonghobae]

Fresh independent owner-canary reproduction on PR #1176 exact head 0b0a45b34aa135f10db82d2a81d685f2d5f64980: Strix run 33290847382, job 99202625237, successfully provisioned the contextual-orchestrator sidecar, bound PR_HEAD_SHA to the exact current head, and retained two changed files for scan attribution. It then failed before any scan with ERROR: LLM_API_BASE must be an https URL when configured. while using the pinned local gateway http://127.0.0.1:18080/v1. Exit code was 2; artifact 9726027498 is diagnostic only and contains no authoritative vulnerability report or source finding. This corroborates #1421's protected-main model-classification root cause. Acceptance remains a fresh post-integration exact-head Strix run that reaches authoritative scanning; this failure must not be reclassified as a source vulnerability or pass.

[seonghobae]

Closing this in favor of #1413, which was opened earlier and already carries the identical, correctly-implemented is_contextual_orchestrator_model/child_model_for_api_base fix (including the prefix-strip that Devin Review had to catch on this PR — #1413 got it right from the start). I opened this PR without knowing #1413 already existed; keeping both would just mean two PRs racing to fix the same root cause.

I've ported the ported-from-#1414 bootstrap-guard fix (the other genuinely useful addition from this PR) onto #1413's branch as well, so nothing is lost. #1413 also has more thorough documentation and real canary evidence (DiskSage, LineageWeave #774) worth preserving as the surviving PR.

---

Generated by Claude Code

---

Generated by Claude Code