Skip to content

fix(strix): reserve NIM budget after GitHub Models 410 brownout - #955

Open
seonghobae wants to merge 1 commit into
mainfrom
fix/strix-github-models-retirement-nim-budget
Open

fix(strix): reserve NIM budget after GitHub Models 410 brownout#955
seonghobae wants to merge 1 commit into
mainfrom
fix/strix-github-models-retirement-nim-budget

Conversation

@seonghobae

@seonghobae seonghobae commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Purpose

Required Strix runs can fail before producing source-backed security evidence when a hosted model/provider consumes the scan budget, a provider family becomes unavailable, or the backend cannot warm/connect/rate-limit successfully. The control plane must distinguish those provider/infrastructure failures from both actionable source vulnerabilities and successful security scans.

The original incident was a primary hosted NVIDIA attempt consuming nearly the full process budget followed by the GitHub Models scheduled-retirement HTTP 410 signal. Fresh Inkspan consumer evidence now proves a second same-class contract defect: required Strix checks can conclude success while their own annotations say the Strix backend was unavailable and the scan was treated as a neutral skip so the outage would not block merges.

Bounded repair

  • cap each NVIDIA NIM attempt at 1,800 seconds inside the existing 5,700-second total retry budget;
  • use Ultra-253B → Super-49B → GitHub Models, preserving the protected-main Super-49B → GitHub Models smoke contract while reserving a second hosted NVIDIA attempt;
  • classify only a same-line github_models_retirement_brownout plus GitHub Models context plus HTTP 410 as family-dead, then skip remaining github_models/* candidates;
  • preserve fail-closed treatment of reported vulnerabilities, incomplete scans, malformed evidence, cross-line spoofing, unrelated application HTTP 410 responses, and backend/provider unavailability that exhausts governed fallback;
  • keep public scans on NVIDIA_NIM_API_KEY; never add COPILOT_GITHUB_TOKEN or merge reviewer credential chains.

A provider/backend outage may trigger bounded provider fallback, but it must never become successful merge-readiness evidence merely because no vulnerability report was produced. If all governed providers are exhausted or unavailable before a complete scan, emit an explicit typed non-passing infrastructure/provider state that remains separate from source vulnerability findings.

Exact identity and scope

  • protected base and live tip: main@c47afc2dc68488292c1db7c9d6f82dcd5360f181;
  • exact current head: 69850cdbb8b9f5791ae6b216366ee630bff24721;
  • state: Ready and mechanically mergeable at the latest refetch;
  • bounded files: central Strix workflow, gate/smoke harnesses, two focused regression modules, doctoring, and CHANGELOG.md.

The body previously named predecessor head 1eb99cdff72fa30ea4df1ea45a2643759ef3f876 as current. That claim is superseded; no check, review, or approval from that or any earlier head transfers to 69850cdb....

Fresh Inkspan consumer contradictions

Two independent current Inkspan heads reproduce the same false-green provider-unavailability boundary.

Inkspan #188

ContextualWisdomLab/inkspan#188 exact head c72e9255aaa8865c6e01708c5bc3626136dfc973 has required Strix workflow run 31951728796 recorded as successful, but the bound Strix check annotation states:

  • title: Strix backend unavailable;
  • Strix could not complete because its LLM backend was unavailable due to rate-limit/token-cap/connection/warm-up failure before producing a vulnerability report; and
  • the workflow treated that condition as a neutral skip so an infrastructure outage would not block merges.

Inkspan #155

ContextualWisdomLab/inkspan#155 exact head 52f7a1c3c0d0c59b27f7bef7168905a728a77da5 independently reproduces the same semantics. Strix check run 95155716435 / workflow run 31943399053 concluded success, while its annotation says Strix backend unavailable and explicitly states the incomplete scan was treated as a neutral skip so the outage would not block merges.

These are control-plane evidence contradictions, not Inkspan source vulnerabilities. A required security scan did not complete on either head, so success cannot be authoritative merge-readiness evidence for those executions.

Required test-first convergence

Before this lane can be treated as operationally complete, add or preserve deterministic regressions proving all of the following:

  1. the known GitHub Models retirement brownout remains a narrowly authenticated provider-family failure and cannot be spoofed by arbitrary target/model text;
  2. backend rate-limit/token-cap/connection/warm-up exhaustion may advance only through bounded governed fallback;
  3. exhausting the governed provider pool before a complete scan yields a typed non-passing provider/infrastructure result, never success, neutral-success, or a fabricated source finding;
  4. a genuine complete scan with no findings remains passing;
  5. genuine source-backed vulnerability/incomplete/malformed evidence remains fail-closed;
  6. scheduler/merge-readiness consumers cannot count a provider-unavailable Strix result as satisfied required security evidence; and
  7. the final result remains bound to the exact repository/head/run/job/artifact identities required by the central Strix evidence contract.

The regression must include at least the exact neutral-skip outcome now demonstrated by Inkspan #188 and #155 so this cannot regress to a green required check under another provider outage.

Do not broadly catch provider/model exceptions, convert unknown failures to success, weaken the required Strix workflow, or invent path:line findings from infrastructure evidence.

Evidence lineage

Predecessor trees passed focused brownout regressions and required-workflow smoke contracts. Those results establish lineage only. The current head 69850cdb... must regenerate terminal-success exact-head quality, security, SAST, dependency/SBOM, supply-chain, and semantic-review evidence after any source change.

GREEN operational acceptance

After the central repair reaches protected main, rerun then-current unchanged affected Inkspan heads. Acceptance requires one of two explicit outcomes for each canary:

  • the governed fallback reaches a real complete Strix scan and the exact-head required workflow passes with coherent source-backed evidence; or
  • providers remain unavailable and Strix remains explicitly non-passing/unavailable, without fabricated source vulnerability attribution and without being counted as merge-ready.

A successful workflow whose own bound annotation says the security scan never completed is not acceptance.

Merge gate

Merge or auto-merge only after the unchanged final head has terminal required gates whose security semantics actually completed, zero valid unresolved findings, a qualifying current-head semantic verdict, the independent non-author approvals and last-push approval required by live protection, a compatible live base, and ordinary expected-head merge authority. No admin merge, self-approval, review dismissal, predecessor-evidence transfer, or ruleset bypass is requested.

Summary by CodeRabbit

  • 개선 사항

    • NVIDIA 호스팅 모델에 별도 30분 실행 제한을 적용해 대체 모델 전환이 안정적으로 이루어집니다.
    • 기본 NVIDIA 모델을 사용할 수 없을 때 추가 Nemotron 모델을 먼저 시도한 뒤 다른 제공자로 전환합니다.
    • GitHub Models의 공식 은퇴·일시 중단 신호를 감지하면 불필요한 재시도를 건너뜁니다.
    • 해당 인프라 중단은 취약점 보고와 구분되어 정상적인 대체 경로로 처리됩니다.
  • 문서

    • GitHub Models 은퇴 상황의 처리 기준과 fallback 정책을 문서화했습니다.

@coderabbitai

coderabbitai Bot commented Aug 13, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

Strix의 NVIDIA NIM fallback에 Nemotron Ultra 모델과 1,800초 전용 제한을 추가했다. GitHub Models retirement brownout을 정확한 HTTP 410 증거로 분류하고, 감지 후 남은 GitHub Models fallback을 건너뛰도록 변경했다. 관련 워크플로와 회귀 테스트도 갱신했다.

Changes

Strix availability flow

Layer / File(s) Summary
NVIDIA NIM fallback 예산
.github/workflows/strix.yml, scripts/ci/strix_quick_gate.sh, tests/test_strix_nvidia_nim_not_found_fallback.py, scripts/ci/test_strix_quick_gate.sh
NVIDIA NIM fallback에 Nemotron Ultra를 추가했다. NIM 모델에는 전역 제한과 전용 1,800초 제한 중 짧은 값을 적용한다.
GitHub Models retirement brownout 라우팅
scripts/ci/strix_quick_gate.sh, docs/doctoring/strix-github-models-retirement-brownout.md
동일 로그 라인에서 GitHub Models 문맥과 정확한 HTTP 410 또는 retirement brownout 증거를 확인한다. brownout 이후 남은 GitHub Models fallback을 건너뛴다.
가용성 검증과 회귀 테스트
scripts/ci/strix_required_workflow_smoke.sh, scripts/ci/test_strix_quick_gate.sh, tests/test_strix_github_models_retirement_brownout.py, tests/test_strix_nvidia_nim_not_found_fallback.py, CHANGELOG.md, docs/doctoring/...
정확한 brownout 신호와 거부해야 하는 유사 신호를 검증한다. 모델 순서, 프로세스 예산, fallback 생략 동작을 검증한다.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Merge Risk: 🔴 Critical · up to 69850

Required security checks can still report success when the scan did not complete, and malformed provider-retirement signals may incorrectly alter fallback behavior. This can allow merges without authoritative security evidence, so the PR is not ready to merge until these paths are corrected.

Sequence Diagram(s)

sequenceDiagram
  participant StrixWorkflow
  participant StrixQuickGate
  participant NVIDIA_NIM
  participant GitHubModels
  StrixWorkflow->>StrixQuickGate: fallback 모델과 프로세스 제한 전달
  StrixQuickGate->>NVIDIA_NIM: Nemotron Ultra 실행
  NVIDIA_NIM-->>StrixQuickGate: 실패 또는 결과 반환
  StrixQuickGate->>NVIDIA_NIM: 다음 NVIDIA fallback 실행
  NVIDIA_NIM-->>StrixQuickGate: 실패 또는 결과 반환
  StrixQuickGate->>GitHubModels: 남은 fallback 실행
  GitHubModels-->>StrixQuickGate: retirement brownout 오류 반환
  StrixQuickGate->>StrixQuickGate: brownout 상태 설정
  StrixQuickGate-->>StrixWorkflow: 남은 GitHub Models fallback 생략
Loading

Possibly related issues

Possibly related PRs

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed 제목은 NIM 예산 예약과 GitHub Models 410 브라운아웃 처리를 정확히 언급하며 변경 사항의 주요 내용을 간결하게 요약합니다.
Docstring Coverage ✅ Passed Docstring coverage is 92.31% which is sufficient. The required threshold is 80.00%.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/strix-github-models-retirement-nim-budget

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

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

@seonghobae
seonghobae enabled auto-merge (squash) August 13, 2026 05:48
@seonghobae

Copy link
Copy Markdown
Contributor Author

@opencode-agent Review-only request for exact current head a73b7bb53ae169e2a72fb44db2ae31c170736e74; do not mutate or merge. Re-evaluate NVIDIA NIM 1800s process cap, Llama-3.1-Nemotron-Ultra-253B fallback, and same-line GitHub Models 410 retirement-brownout family skip. Vulnerability neutralization must stay fail-closed.

@seonghobae

Copy link
Copy Markdown
Contributor Author

@opencode-agent @cwl-noema-review Review-only request for exact current head 832d1cca; do not mutate or merge. Re-evaluate digit-terminated HTTP 410 brownout skip (4100/4104/#410 must not skip remaining github_models fallbacks) and the reserved NVIDIA NIM 1800s process cap. Independent current-head approval is required for the two-approval gate.

@opencode-agent

opencode-agent Bot commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

OpenCode Review Overview

  • Head SHA: 1eb99cdff72fa30ea4df1ea45a2643759ef3f876
  • Workflow run: 31896224814
  • Workflow attempt: 1
  • Gate result: REQUEST_CHANGES (approval step)

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 1eb99cdff72fa30ea4df1ea45a2643759ef3f876.
  • 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:

Changed-File Evidence Map

flowchart LR
  PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
  Evidence --> S1["Workflow: strix.yml"]
  S1 --> I1["GitHub Actions review job"]
  I1 --> R1["Review risk: Workflow: strix.yml"]
  R1 --> V1["actionlint plus required checks"]
  Evidence --> S2["Changed file: CHANGELOG.md"]
  S2 --> I2["repository behavior"]
  I2 --> R2["Review risk: Changed file: CHANGELOG.md"]
  R2 --> V2["required checks"]
  Evidence --> S3["Docs: strix-github-models-retirement-brownout.md"]
  S3 --> I3["operator or user guidance"]
  I3 --> R3["Review risk: Docs: strix-github-models-retirement-brownout.md"]
  R3 --> V3["docs review"]
  Evidence --> S4["CI script (3 files)"]
  S4 --> I4["review and security gate shell path"]
  I4 --> R4["Review risk: CI script (3 files)"]
  R4 --> V4["bash -n plus Strix self-test"]
  Evidence --> S5["Test (2 files)"]
  S5 --> I5["regression suite"]
  I5 --> R5["Review risk: Test (2 files)"]
  R5 --> V5["targeted test run"]
Loading

@opencode-agent opencode-agent Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 13118614c6699a94aa8d60316c70406c59a7a178.
  • 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:

Changed-File Evidence Map

flowchart LR
  PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
  Evidence --> S1["Workflow: strix.yml"]
  S1 --> I1["GitHub Actions review job"]
  I1 --> R1["Review risk: Workflow: strix.yml"]
  R1 --> V1["actionlint plus required checks"]
  Evidence --> S2["Changed file (4 files)"]
  S2 --> I2["repository behavior"]
  I2 --> R2["Review risk: Changed file (4 files)"]
  R2 --> V2["required checks"]
  Evidence --> S3["Docs: strix-github-models-retirement-brownout.md"]
  S3 --> I3["operator or user guidance"]
  I3 --> R3["Review risk: Docs: strix-github-models-retirement-brownout.md"]
  R3 --> V3["docs review"]
  Evidence --> S4["CI script (4 files)"]
  S4 --> I4["review and security gate shell path"]
  I4 --> R4["Review risk: CI script (4 files)"]
  R4 --> V4["bash -n plus Strix self-test"]
  Evidence --> S5["Test (3 files)"]
  S5 --> I5["regression suite"]
  I5 --> R5["Review risk: Test (3 files)"]
  R5 --> V5["targeted test run"]
Loading

@opencode-agent
opencode-agent Bot disabled auto-merge August 14, 2026 01:26
@seonghobae
seonghobae enabled auto-merge (squash) August 14, 2026 01:30
@opencode-agent
opencode-agent Bot disabled auto-merge August 14, 2026 01:55
@seonghobae
seonghobae marked this pull request as draft August 14, 2026 09:09

Copy link
Copy Markdown
Contributor Author

Returned to Draft because the exact current tree mixes the Strix provider-family/budget repair with an unrelated trusted-uv materializer branch.

The intended resilience boundary is narrow: reserve bounded compute for multiple hosted NIM candidates, classify only the exact same-line GitHub Models HTTP-410 retirement brownout as family-dead, and never neutralize vulnerability findings or generic application 410s. Head 13118614c6699a94aa8d60316c70406c59a7a178 additionally changes materialize_base_python_requirements.py and its tests plus broad governance files.

Rebuild from protected main retaining only the Strix workflow/gate/smoke surfaces, focused spoofing and budget regressions, doctoring, directly attributable governance/changelog evidence, and no materializer changes. Revalidate the live NIM/model catalog immediately before Ready, then reacquire exact-head Strix/security/supply-chain and independent-review evidence.

Copy link
Copy Markdown
Contributor Author

Additional exact downstream evidence for this central fix:

  • target: ContextualWisdomLab/fast-mlsirm#831
  • exact source head: a52de8a80acc67409a5cab2d0d4c998239798eaf
  • required Strix run/job: 31797203043 / 94756792810
  • selected model: nvidia_nim/nvidia/nemotron-3-super-120b-a12b
  • elapsed attempt: 5,402 seconds
  • terminal cause: Strix run timed out after 5400s, exit 124; no authoritative vulnerability report artifact was produced, so the leaf workflow correctly failed closed.
  • all installation, exact-head materialization, contract self-test, credential selection, and artifact-collection steps completed; only Run Strix (quick) failed.

This is owning-layer provider-budget evidence, not a backend/source finding in fast-mlsirm #831. The observed 5,400-second first NIM attempt exhausted the entire scan budget exactly as this PR's 1,800-second per-attempt cap is intended to prevent. Preserve fail-closed missing-report behavior; after protected integration, rerun the unchanged #831 head and require either an authoritative clean/finding report or bounded fallback exhaustion rather than a single-model full-budget timeout.

@seonghobae
seonghobae marked this pull request as ready for review August 14, 2026 14:09

Copy link
Copy Markdown
Contributor Author

@coderabbitai review
@opencode-agent review
@cwl-noema-review review
@strix review

Review only exact current head 2efd7d8607527cacde2aeeb33f3accc02c8367c3 against live protected main@6eb06cdd08c79a06f7b390069d4ffa49e2eb7dba. I removed the unrelated trusted-uv production delta by restoring the exact bounded Strix provider-budget tree as a new descendant. The current branch caps each NVIDIA NIM attempt at 1800s within the existing 5700s total budget, adds a second NIM candidate before retired GitHub Models, and classifies only same-line GitHub Models HTTP 410 retirement-brownout evidence as family-dead; application 410 and 4100/4104 remain non-matches. Vulnerability findings are never neutralized. No review thread exists. Exact-head checks are regenerating; nonterminal evidence is not acceptance. Review read-only; do not mutate source, synthesize approval, weaken security evidence, or merge.

@coderabbitai

coderabbitai Bot commented Aug 14, 2026

Copy link
Copy Markdown
🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

head_expected='2efd7d8607527cacde2aeeb33f3accc02c8367c3'
base_expected='6eb06cdd08c79a06f7b390069d4ffa49e2eb7dba'

printf '%s\n' '== checked-out HEAD =='
git rev-parse HEAD
printf '%s\n' '== expected objects =='
git cat-file -t "$head_expected"
git cat-file -t "$base_expected"
printf '%s\n' '== ancestry and merge base =='
git merge-base "$base_expected" "$head_expected"
git merge-base --is-ancestor "$base_expected" "$head_expected" && echo 'base-is-ancestor=yes'
printf '%s\n' '== changed files =='
git diff --name-status "$base_expected" "$head_expected"
printf '%s\n' '== changed paths: outlines =='
git diff --name-only "$base_expected" "$head_expected" | while IFS= read -r path; do
  printf '\n--- %s ---\n' "$path"
  case "$path" in
    *.yml|*.yaml) ast-grep outline "$path" --lang yaml --items all 2>/dev/null || true ;;
    *.py) ast-grep outline "$path" --lang python --items all 2>/dev/null || true ;;
    *.sh) ast-grep outline "$path" --lang bash --items all 2>/dev/null || true ;;
    *) sed -n '1,80p' "$path" ;;
  esac
done
printf '%s\n' '== full scoped diff =='
git diff --find-renames --find-copies --unified=80 "$base_expected" "$head_expected"

Length of output: 164645


🏁 Script executed:

#!/bin/bash
set -euo pipefail

head='2efd7d8607527cacde2aeeb33f3accc02c8367c3'

printf '%s\n' '== workflow neutralization block with line numbers =='
git show "$head:.github/workflows/strix.yml" |
  nl -ba |
  sed -n '/backend_unavailable_signal=/,/exit "\$strix_rc"/p'

printf '%s\n' '== gate brownout classifier and fallback handling with line numbers =='
git show "$head:scripts/ci/strix_quick_gate.sh" |
  nl -ba |
  sed -n '/is_github_models_retirement_brownout_error()/,/^}/p;/skip_remaining_github_models=0/,/if should_fail_pull_request_infra_zero_findings/p'

printf '%s\n' '== regression assertions for workflow-level neutralization =='
git show "$head:tests/test_strix_github_models_retirement_brownout.py" |
  nl -ba |
  sed -n '1,220p'

printf '%s\n' '== current PR status checks =='
gh api "repos/ContextualWisdomLab/.github/commits/${head}/check-runs?per_page=100" \
  --jq '.check_runs[] | [.name, .status, (.conclusion // ""), .details_url] | `@tsv`' || true

Length of output: 1372


🏁 Script executed:

#!/bin/bash
set -euo pipefail

head='2efd7d8607527cacde2aeeb33f3accc02c8367c3'

printf '%s\n' '== workflow neutralization block with line numbers =='
git show "$head:.github/workflows/strix.yml" |
  awk '
    /backend_unavailable_signal=/ {show=1}
    show {printf "%6d  %s\n", NR, $0}
    show && /exit "\$strix_rc"/ {exit}
  '

printf '%s\n' '== gate brownout classifier with line numbers =='
git show "$head:scripts/ci/strix_quick_gate.sh" |
  awk '
    /^is_github_models_retirement_brownout_error\(\)/ {show=1}
    show {printf "%6d  %s\n", NR, $0}
    show && /^}$/ {exit}
  '

printf '%s\n' '== workflow-level brownout regression coverage =='
git show "$head:tests/test_strix_github_models_retirement_brownout.py" |
  awk '{printf "%6d  %s\n", NR, $0}'

printf '%s\n' '== current PR status checks =='
if command -v gh >/dev/null 2>&1; then
  gh api "repos/ContextualWisdomLab/.github/commits/${head}/check-runs?per_page=100" \
    --jq '.check_runs[] | [.name, .status, (.conclusion // ""), .details_url] | `@tsv`' || \
    echo 'GitHub check query was unavailable.'
else
  echo 'GitHub CLI is unavailable in this sandbox.'
fi

Length of output: 21690


@seonghobae Review found one fail-closed regression.

  • High — Preserve the terminated HTTP-status check in the outer neutralization path. Line 866 of .github/workflows/strix.yml matches Error code: 410 without a non-digit boundary. Therefore, a same-line log entry such as github_models_retirement_brownout ... Error code: 4100 or 4104 matches backend_unavailable_signal. If no vulnerability marker exists, Lines 877-880 convert the gate failure into workflow success. The gate classifier correctly rejects these longer codes at scripts/ci/strix_quick_gate.sh Line 2864, but the outer workflow bypasses that classifier.

    Add ([^0-9]|$) after both workflow-level 410 alternatives. Add regression coverage that executes the workflow neutralization condition for 4100, 4104, and #410. Those inputs must remain failures.

The reviewed checkout equals the requested head. The requested base is its ancestor. Current required checks are queued or in progress, so they are not acceptance evidence.

⚠️ Action not completed

Review rate limited.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@opencode-agent opencode-agent Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 2efd7d8607527cacde2aeeb33f3accc02c8367c3.
  • 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:

Changed-File Evidence Map

flowchart LR
  PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
  Evidence --> S1["Workflow: strix.yml"]
  S1 --> I1["GitHub Actions review job"]
  I1 --> R1["Review risk: Workflow: strix.yml"]
  R1 --> V1["actionlint plus required checks"]
  Evidence --> S2["Changed file (4 files)"]
  S2 --> I2["repository behavior"]
  I2 --> R2["Review risk: Changed file (4 files)"]
  R2 --> V2["required checks"]
  Evidence --> S3["Docs: strix-github-models-retirement-brownout.md"]
  S3 --> I3["operator or user guidance"]
  I3 --> R3["Review risk: Docs: strix-github-models-retirement-brownout.md"]
  R3 --> V3["docs review"]
  Evidence --> S4["CI script (3 files)"]
  S4 --> I4["review and security gate shell path"]
  I4 --> R4["Review risk: CI script (3 files)"]
  R4 --> V4["bash -n plus Strix self-test"]
  Evidence --> S5["Test (3 files)"]
  S5 --> I5["regression suite"]
  I5 --> R5["Review risk: Test (3 files)"]
  R5 --> V5["targeted test run"]
Loading

@opencode-agent opencode-agent Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 2efd7d8607527cacde2aeeb33f3accc02c8367c3.
  • 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:

Changed-File Evidence Map

flowchart LR
  PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
  Evidence --> S1["Workflow: strix.yml"]
  S1 --> I1["GitHub Actions review job"]
  I1 --> R1["Review risk: Workflow: strix.yml"]
  R1 --> V1["actionlint plus required checks"]
  Evidence --> S2["Changed file (4 files)"]
  S2 --> I2["repository behavior"]
  I2 --> R2["Review risk: Changed file (4 files)"]
  R2 --> V2["required checks"]
  Evidence --> S3["Docs: strix-github-models-retirement-brownout.md"]
  S3 --> I3["operator or user guidance"]
  I3 --> R3["Review risk: Docs: strix-github-models-retirement-brownout.md"]
  R3 --> V3["docs review"]
  Evidence --> S4["CI script (3 files)"]
  S4 --> I4["review and security gate shell path"]
  I4 --> R4["Review risk: CI script (3 files)"]
  R4 --> V4["bash -n plus Strix self-test"]
  Evidence --> S5["Test (3 files)"]
  S5 --> I5["regression suite"]
  I5 --> R5["Review risk: Test (3 files)"]
  R5 --> V5["targeted test run"]
Loading

Comment thread .github/workflows/repair-strix-nim-order.yml Fixed
@seonghobae
seonghobae enabled auto-merge (squash) August 15, 2026 12:01

Copy link
Copy Markdown
Contributor Author

@opencode-agent @cwl-noema-review @coderabbitai review

Review exact head e4bc13c481db0765bf7223542b9f042d83b35b90. Verify the 1800-second per-NIM cap within the unchanged 5700-second total budget; Ultra-253B → Super-49B → GitHub Models fallback order; exact same-line GitHub Models retirement-410 classifier; rejection of unrelated/cross-line 410 evidence; preservation of fail-closed vulnerability/incomplete-scan behavior; NVIDIA_NIM_API_KEY and reviewer-credential separation; removal of all one-shot and unrelated scope drift; and focused smoke/brownout regression evidence. Submit a formal exact-head verdict.

@coderabbitai

coderabbitai Bot commented Aug 15, 2026

Copy link
Copy Markdown

Rate Limit Exceeded

@seonghobae have exceeded the limit for the number of chat messages per hour. Please wait 32 minutes and 37 seconds before sending another message.

Copy link
Copy Markdown
Contributor Author

Exact-current-head read-only review request for 1eb99cdff72fa30ea4df1ea45a2643759ef3f876 over protected base 6eb06cdd08c79a06f7b390069d4ffa49e2eb7dba.

The current head is an owner-authored metadata-only rebind of the verified 2af893c... tree because the bot-authored head produced action_required runs with zero jobs. Recheck the unchanged eight-file repair: 1,800-second per-NIM attempt within the 5,700-second total budget; Ultra→Super→GitHub Models order; same-line GitHub Models 410 retirement classification only; cross-line/application-410 rejection; vulnerability/malformed/incomplete evidence remains fail closed; NVIDIA_NIM_API_KEY and reviewer credential separation unchanged.

Submit a verdict for this unchanged content/current head only. Treat predecessor checks/reviews as historical. Do not mutate or merge the branch, synthesize author approval, or weaken protection.

@opencode-agent review
@cwl-noema-review review
@coderabbitai review

@coderabbitai

coderabbitai Bot commented Aug 15, 2026

Copy link
Copy Markdown

Rate Limit Exceeded

@seonghobae have exceeded the limit for the number of chat messages per hour. Please wait 9 minutes and 33 seconds before sending another message.

@opencode-agent opencode-agent Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 1eb99cdff72fa30ea4df1ea45a2643759ef3f876.
  • 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:

Changed-File Evidence Map

flowchart LR
  PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
  Evidence --> S1["Workflow: strix.yml"]
  S1 --> I1["GitHub Actions review job"]
  I1 --> R1["Review risk: Workflow: strix.yml"]
  R1 --> V1["actionlint plus required checks"]
  Evidence --> S2["Changed file: CHANGELOG.md"]
  S2 --> I2["repository behavior"]
  I2 --> R2["Review risk: Changed file: CHANGELOG.md"]
  R2 --> V2["required checks"]
  Evidence --> S3["Docs: strix-github-models-retirement-brownout.md"]
  S3 --> I3["operator or user guidance"]
  I3 --> R3["Review risk: Docs: strix-github-models-retirement-brownout.md"]
  R3 --> V3["docs review"]
  Evidence --> S4["CI script (3 files)"]
  S4 --> I4["review and security gate shell path"]
  I4 --> R4["Review risk: CI script (3 files)"]
  R4 --> V4["bash -n plus Strix self-test"]
  Evidence --> S5["Test (2 files)"]
  S5 --> I5["regression suite"]
  I5 --> R5["Review risk: Test (2 files)"]
  R5 --> V5["targeted test run"]
Loading

@opencode-agent
opencode-agent Bot disabled auto-merge August 15, 2026 19:14

@opencode-agent opencode-agent Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 1eb99cdff72fa30ea4df1ea45a2643759ef3f876.
  • 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:

Changed-File Evidence Map

flowchart LR
  PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
  Evidence --> S1["Workflow: strix.yml"]
  S1 --> I1["GitHub Actions review job"]
  I1 --> R1["Review risk: Workflow: strix.yml"]
  R1 --> V1["actionlint plus required checks"]
  Evidence --> S2["Changed file: CHANGELOG.md"]
  S2 --> I2["repository behavior"]
  I2 --> R2["Review risk: Changed file: CHANGELOG.md"]
  R2 --> V2["required checks"]
  Evidence --> S3["Docs: strix-github-models-retirement-brownout.md"]
  S3 --> I3["operator or user guidance"]
  I3 --> R3["Review risk: Docs: strix-github-models-retirement-brownout.md"]
  R3 --> V3["docs review"]
  Evidence --> S4["CI script (3 files)"]
  S4 --> I4["review and security gate shell path"]
  I4 --> R4["Review risk: CI script (3 files)"]
  R4 --> V4["bash -n plus Strix self-test"]
  Evidence --> S5["Test (2 files)"]
  S5 --> I5["regression suite"]
  I5 --> R5["Review risk: Test (2 files)"]
  R5 --> V5["targeted test run"]
Loading

@seonghobae
seonghobae enabled auto-merge (squash) August 17, 2026 06:25
@opencode-agent
opencode-agent Bot disabled auto-merge August 17, 2026 06:25
@seonghobae
seonghobae enabled auto-merge (squash) August 17, 2026 06:30
@opencode-agent
opencode-agent Bot disabled auto-merge August 17, 2026 06:32

Copy link
Copy Markdown
Contributor Author

New same-class canary from ContextualWisdomLab/scopeweave#523: exact head 58b542103a3c6009d693d32410340c1262ee87a3, central workflow run 31978036107, Strix job/check 95289898139. GitHub recorded conclusion=success, but the bound annotation title is Strix backend unavailable and states the backend failed on rate-limit/token-cap/connection/warm-up before producing any vulnerability report, then was treated as a neutral skip so the outage would not block merges. ScopeWeave therefore treats this execution as non-passing security evidence. I have re-run that exact Strix job without changing the clean contributor head to exercise provider recovery. Please include this exact ScopeWeave canary in the fail-closed provider-unavailability regression/operational acceptance for this central repair; GREEN means either a real complete exact-head scan or an explicit non-passing provider-unavailable result, never success-with-unavailable annotation.

@seonghobae
seonghobae enabled auto-merge (squash) August 17, 2026 07:05
@opencode-agent
opencode-agent Bot disabled auto-merge August 17, 2026 07:06

Copy link
Copy Markdown
Contributor Author

The bounded no-head-churn retry has now reproduced the same false-green contract on a second ScopeWeave canary. ContextualWisdomLab/scopeweave#545 remained on exact unchanged head ef9f9a9912b37946ee340aef26f7f2d62a03e32d against protected develop@44e7903cf8891c65410f7fc6ca5144de3fdb5185; re-run job/check 95307272272 completed success at 2026-08-17T07:06:58Z, but its only annotation is again Strix backend unavailable, explicitly saying the LLM backend failed before producing a vulnerability report and the workflow treated that as a neutral skip so merges would not block. This proves simple waiting/retry does not repair the evidence semantics. Keep #545 as a post-fix acceptance canary: after the central repair reaches protected main, the exact unchanged head must produce either a complete attributable scan or an explicit non-passing unavailable state, never success with unavailable-only evidence.

Copy link
Copy Markdown
Contributor Author

A third unchanged-head ScopeWeave canary reproduces the same false-green security contract: ContextualWisdomLab/scopeweave#497, exact head 58e3ae819fc6cee42ddb62c3bdac65cae69f5e87, protected base develop@44e7903cf8891c65410f7fc6ca5144de3fdb5185, Strix run 31980411211, job/check 95260091442. GitHub records conclusion=success, but the sole annotation is again Strix backend unavailable, explicitly stating the LLM backend failed before producing a vulnerability report and the workflow neutral-skipped to avoid blocking merges. This head is otherwise the read-only workflow-registry audit slice, so there is no leaf source change that can repair the scanner evidence semantics. Please include #497 with #523/#545 in post-fix acceptance: unchanged exact head must yield either complete attributable scan evidence or an explicit non-passing unavailable state, never success-with-unavailable-only evidence.

Copy link
Copy Markdown
Contributor Author

Fresh ScopeWeave #508 also reproduces the same false-green contract on a materially different product slice. Exact unchanged head e27f57d837232538a9c7476ac4a9a1a5d1021945, protected base develop@44e7903cf8891c65410f7fc6ca5144de3fdb5185, Strix run 31999500595, job/check 95297058272: GitHub conclusion is success, while the sole annotation is Strix backend unavailable and explicitly says the backend failed before any vulnerability report, then neutral-skipped so merges would not block. This extends the same central evidence defect beyond workflow/config PRs into the WBS performance slice. Please retain #508 as another post-fix canary; no ScopeWeave source churn can causally repair this control-plane behavior.

@seonghobae
seonghobae enabled auto-merge (squash) August 17, 2026 07:14
@opencode-agent
opencode-agent Bot disabled auto-merge August 17, 2026 07:14

Copy link
Copy Markdown
Contributor Author

Fresh same-class consumer evidence from ScopeWeave confirms this central Strix contract defect on a third repository/head and gives an exact acceptance canary.

  • consumer: ContextualWisdomLab/scopeweave#523
  • exact contributor head: 58b542103a3c6009d693d32410340c1262ee87a3
  • protected base observed by that PR: develop@44e7903cf8891c65410f7fc6ca5144de3fdb5185
  • Strix check run: 95240357165
  • GitHub conclusion: success
  • bound annotation title: Strix backend unavailable
  • bound annotation message says the LLM backend failed before producing a vulnerability report because of rate-limit/token-cap/connection/warm-up failure and was treated as a neutral skip so the outage would not block merges.

This is infrastructure/provider evidence, not a ScopeWeave source vulnerability. ScopeWeave deliberately treats that exact check as non-passing despite GitHub's success, so #523 remains blocked from merge classification rather than adding a leaf workaround.

Please include this exact consumer identity in the protected-main acceptance set for the central repair: after this PR integrates, rerun Strix against the unchanged #523 head if it still exists (or its freshly reconciled successor). Acceptance is either (a) a real complete source-backed scan with coherent passing evidence or (b) explicit non-passing provider/infrastructure unavailability; success plus Strix backend unavailable must be impossible. No fabricated path/line vulnerability should be emitted from this provider failure.

@seonghobae
seonghobae enabled auto-merge (squash) August 17, 2026 08:29

Copy link
Copy Markdown
Contributor Author

Fresh ScopeWeave canaries reproduce the same central false-green Strix contract on exact current heads. scopeweave#545@ef9f9a9912b37946ee340aef26f7f2d62a03e32d: Strix check 95314069815 / workflow run 31972488686 concluded success, while its sole warning annotation is titled Strix backend unavailable and says the LLM backend failed before producing a vulnerability report and was treated as a neutral skip. scopeweave#523@58b542103a3c6009d693d32410340c1262ee87a3: Strix check 95306997178 / run 31978036107 has the same contradiction. ScopeWeave treats both as non-passing and has rerun only those exact Strix jobs; the reruns are currently queued (#545 job 95333056399, #523 job 95333219605). These are canary/acceptance evidence for #955, not leaf source defects. After protected-main integration, acceptance should require either a coherent completed scan or an explicit non-passing provider-unavailable result on these unchanged/freshly-reconciled heads; a green check carrying Strix backend unavailable remains non-acceptance.

seonghobae commented Aug 17, 2026

Copy link
Copy Markdown
Contributor Author

Fresh ScopeWeave consumer reproductions for the current Strix false-green contract:

ScopeWeave #545 — repeated exact-head retry still false-green

  • repository/PR: ContextualWisdomLab/scopeweave#545
  • exact consumer head: ef9f9a9912b37946ee340aef26f7f2d62a03e32d
  • protected consumer base ref/tip: develop@44e7903cf8891c65410f7fc6ca5144de3fdb5185
  • original Strix check: 95333056399, GitHub conclusion success, bound annotation Strix backend unavailable
  • fresh bounded retry job: 95347796584 in workflow run 31972488686
  • retry GitHub conclusion: success
  • retry bound annotation again says Strix backend unavailable: the LLM backend failed from rate-limit/token-cap/connection-or-warm-up before producing a vulnerability report, then the central workflow converted the incomplete scan into a neutral success.

This is stronger than a one-off transient observation: an exact-head rerun produced the same contradiction. Under fail-closed merge evidence, neither 95333056399 nor 95347796584 is a passing security scan because no vulnerability report was produced. Repeating the leaf rerun cannot change the causal central contract; #955 owns the repair.

ScopeWeave #523

  • repository/PR: ContextualWisdomLab/scopeweave#523
  • exact consumer head: 58b542103a3c6009d693d32410340c1262ee87a3
  • observed protected base: develop@44e7903cf8891c65410f7fc6ca5144de3fdb5185
  • Strix check 95333219605: GitHub success with the same Strix backend unavailable annotation and no completed report.

These are independent current ScopeWeave consumer heads demonstrating the same control-plane evidence contradiction #955 is intended to eliminate. They are not ScopeWeave source vulnerabilities and should not generate fabricated path/line findings.

Acceptance after the central repair reaches protected main: rerun then-current exact heads (or freshly reconciled successors). Either (a) governed fallback produces a complete source-backed scan and Strix passes coherently, or (b) providers remain unavailable and required Strix evidence remains explicitly non-passing/unavailable. A successful check whose own bound evidence says the scan never completed must not satisfy merge readiness.

Copy link
Copy Markdown
Contributor Author

Fresh ScopeWeave canary for the existing Strix false-green repair matrix:

  • consumer: ContextualWisdomLab/scopeweave#509
  • exact contributor head: c8f7c5c7995793516b28068ac59caa73351cc1fa
  • independently resolved protected base: develop@44e7903cf8891c65410f7fc6ca5144de3fdb5185
  • required Strix check-run/job: 95228824486 in workflow run 31973244150
  • GitHub state: completed/success
  • bound annotation: Strix backend unavailable; the backend failed before producing a vulnerability report due to rate-limit/token-cap/connection/warm-up failure, and the workflow explicitly says it was treated as a neutral skip so the outage would not block merges.

This head is otherwise mechanically current against protected develop, and its repository-owned Server Tests, Fuzz, Security Scan, Dependency Review, SAST Semgrep, and OSV Scanner all completed successfully. Under the central evidence contract, the Strix execution is still non-passing because no scan completed. Please retain #509 as another downstream acceptance canary: after the owner repair reaches protected main, rerun the then-current unchanged ScopeWeave head and accept only either a complete coherent scan result or an explicit non-passing provider/infrastructure outcome that cannot satisfy required security evidence. No ScopeWeave leaf workaround is appropriate.

Copy link
Copy Markdown
Contributor Author

Fresh ScopeWeave canary evidence reproduces the same central Strix false-green contract on two independent unchanged exact heads. This is control-plane evidence only; no ScopeWeave source vulnerability is inferred.

  • ContextualWisdomLab/scopeweave#523 exact head 58b542103a3c6009d693d32410340c1262ee87a3: Strix check 95333219605 completed with GitHub conclusion success, but its bound annotation is titled Strix backend unavailable and states that the LLM backend failed due to rate-limit/token-cap/connection/warm-up before producing a vulnerability report, then was treated as a neutral skip so the outage would not block merges. Repository-native Server Tests, OSV, Fuzz, Semgrep, Security Scan, Dependency Review, and CodeQL are independently terminal-success on this exact head; the Strix contradiction is therefore isolated rather than a leaf CI failure.
  • ContextualWisdomLab/scopeweave#545 exact head ef9f9a9912b37946ee340aef26f7f2d62a03e32d: Strix check 95347796584 likewise completed success while its annotation says Strix backend unavailable with the same no-report/neutral-skip semantics. This PR already has an exact-head non-author APPROVED review because its author is cursor[bot]; Strix is the remaining known security-evidence contradiction rather than an approval substitute.

Acceptance for these ScopeWeave canaries after #955 reaches protected main: rerun/re-dispatch Strix on the then-current unchanged/reconciled heads and require either (a) a real complete scan with coherent passing evidence, or (b) an explicit non-passing provider/infrastructure result if governed providers remain unavailable. A GitHub success whose bound evidence says no vulnerability scan completed must remain non-authorizing.

Copy link
Copy Markdown
Contributor Author

@opencode-agent Please repair the EXISTING owner branch for exact current head 69850cdbb8b9f5791ae6b216366ee630bff24721; do not create a competing PR and do not merge. Revalidate the two unresolved current CodeRabbit threads first, then fix only still-valid findings test-first: (1) provider/brownout detection must require same physical line GitHub Models context + provider-exception marker + terminal HTTP 410 with non-digit boundary, rejecting 4100/4104, target-output spoofing, cross-line evidence, and retirement brownout without HTTP 410; (2) provider/fallback exhaustion or incomplete scan must remain explicitly non-passing rather than exit 0; (3) repair the Markdown #949 line. Preserve vulnerability/incomplete/malformed fail-closed behavior, the 1800s per-NIM attempt cap within 5700s total budget, Ultra→Super→GitHub Models order, NVIDIA_NIM_API_KEY, reviewer credential separation, and exact repository/head/run/job evidence binding. Add/strengthen RED regressions before source change, obtain focused/full GREEN evidence, and leave current-head formal review/recheck to independent reviewers afterward.

Copy link
Copy Markdown
Contributor Author

Fresh ScopeWeave consumer reproduction for the existing Strix false-green boundary:

  • repository: ContextualWisdomLab/scopeweave
  • PR: #545
  • exact contributor head: ef9f9a9912b37946ee340aef26f7f2d62a03e32d
  • required Strix check/job: 95377257315
  • workflow run: 31972488686
  • GitHub conclusion: success
  • bound annotation title: Strix backend unavailable
  • annotation semantics: backend failed from rate-limit/token-cap/connection/warm-up before any vulnerability report and was treated as a neutral skip so the outage would not block merges.

This is the same control-plane contradiction already described in this PR: no completed security scan exists, so the green conclusion is non-authoritative merge-readiness evidence. I have rerun the exact ScopeWeave Strix job without changing its clean head; acceptance is either a real completed exact-head scan or an explicit non-passing provider/infrastructure outcome under this central repair. No ScopeWeave leaf workaround or fabricated source finding was introduced.

Copy link
Copy Markdown
Contributor Author

Fresh same-class consumer evidence from ContextualWisdomLab/scopeweave#545 confirms the false-green provider-unavailable boundary is still live.

  • ScopeWeave exact head: ef9f9a9912b37946ee340aef26f7f2d62a03e32d
  • required Strix workflow run: 31972488686
  • Strix check/job: 95391734674
  • GitHub conclusion: success
  • bound annotation: Strix backend unavailable — backend failed from rate-limit/token-cap/connection/warm-up before producing a vulnerability report, then was treated as a neutral skip so the outage would not block merges.

This is infrastructure/provider evidence, not a ScopeWeave source vulnerability. Acceptance for this exact defect class remains: provider exhaustion before a complete scan must yield an explicit non-passing unavailable/infrastructure result and must not satisfy required merge-readiness. After this central repair reaches protected main, re-dispatch Strix on an unchanged/reconciled ScopeWeave consumer head and require either a complete coherent scan or an explicit non-passing provider-unavailable outcome.

Copy link
Copy Markdown
Contributor Author

Fresh ScopeWeave consumer canary for this central Strix contract (2026-08-18 KST): ContextualWisdomLab/scopeweave#545 is unchanged at exact head ef9f9a9912b37946ee340aef26f7f2d62a03e32d on protected develop@44e7903cf8891c65410f7fc6ca5144de3fdb5185. Required Strix check run 95391734674 is recorded success, but its bound annotation is Strix backend unavailable and states the backend failed before producing a vulnerability report and was treated as a neutral skip so the outage would not block merges. Under ScopeWeave's live rules this is non-passing security evidence, not a source finding. Please keep this exact repo/head/check as an additional GREEN canary for #955: after the central repair reaches protected main, re-dispatch the then-current unchanged/descendant ScopeWeave head and require either a completed coherent scan or an explicit non-passing provider/infrastructure result—never success with an incomplete-scan annotation.

Copy link
Copy Markdown
Contributor Author

Fresh ScopeWeave consumer evidence reproduces this exact false-green provider-unavailability boundary and should be included in the existing owner acceptance lane.

  • consumer: ContextualWisdomLab/scopeweave#545
  • exact contributor head: ef9f9a9912b37946ee340aef26f7f2d62a03e32d
  • protected base at the run: develop@44e7903cf8891c65410f7fc6ca5144de3fdb5185
  • required Strix check-run/job: 95391734674
  • workflow run: 31972488686
  • GitHub conclusion: success
  • bound annotation title: Strix backend unavailable
  • annotation states that the LLM backend was unavailable because of rate-limit/token-cap/connection/warm-up failure before producing a vulnerability report, and that the workflow treated this as a neutral skip so the outage would not block merges.

This is control-plane evidence contradiction, not a ScopeWeave source vulnerability. ScopeWeave is therefore treating that check as non-passing despite the GitHub success conclusion and is not adding a leaf workaround.

Acceptance after this central repair reaches protected main: rerun the then-current unchanged ScopeWeave head (or its freshly reconciled successor). Either (a) Strix completes a real exact-head scan and emits coherent source-backed passing evidence, or (b) governed providers remain unavailable and the required Strix result remains explicitly non-passing/unavailable. A success check whose own annotation says no vulnerability report was produced must not satisfy merge readiness.

Copy link
Copy Markdown
Contributor Author

Fresh ScopeWeave canary for the same false-green Strix provider-unavailable contract: ContextualWisdomLab/scopeweave#545 exact unchanged head ef9f9a9912b37946ee340aef26f7f2d62a03e32d, protected base develop@44e7903cf8891c65410f7fc6ca5144de3fdb5185. Required Strix workflow run 31972488686, attempt 10, job/check 95391734674 concluded success, but its bound annotation is titled Strix backend unavailable and states that the LLM backend failed before producing a vulnerability report and was treated as a neutral skip so an infrastructure outage would not block merges. This is not a ScopeWeave source vulnerability and must not authorize merge readiness. Acceptance for #955 should include this canary (or its then-current descendant): after central repair reaches protected main, rerun the exact current ScopeWeave head and require either a real complete source-backed Strix result or an explicit non-passing provider/infrastructure state. Current consumer evidence: all six repository-native workflows are terminal success on this head and an independent exact-head APPROVED review exists, so the Strix evidence contradiction is materially gating this otherwise mature lane.

Copy link
Copy Markdown
Contributor Author

Fresh ScopeWeave consumer canary for the same fail-closed Strix contract:

  • consumer: ContextualWisdomLab/scopeweave#523
  • protected consumer base: develop@44e7903cf8891c65410f7fc6ca5144de3fdb5185
  • exact consumer head: 58b542103a3c6009d693d32410340c1262ee87a3
  • current PR remains Ready/mechanically mergeable, but merge is intentionally held
  • its current-head Strix check is recorded as success while the bound annotation states Strix backend unavailable and says the LLM backend failed before producing a vulnerability report because of rate-limit/token-cap/connection/warm-up failure and the workflow treated that as a neutral skip so infrastructure outage would not block merges

This reproduces the same evidence contradiction already described here from another dedicated consumer repository; it is not a ScopeWeave source vulnerability. Please include this unchanged (or freshly reconciled descendant) ScopeWeave head in post-merge operational acceptance for this owner repair. Acceptance is either a real complete source-backed Strix scan or an explicit non-passing provider/infrastructure state; success with backend unavailable remains non-acceptance.

Also note the current CodeRabbit review on this exact central head 69850cdbb8b9f5791ae6b216366ee630bff24721 independently flags the backend-unavailability exit 0 branch as critical. Preserve the current owner branch and test-first repair there; no consumer leaf workaround is appropriate.

Copy link
Copy Markdown
Contributor Author

Fresh ScopeWeave canary after both consumer head and protected base moved; this supersedes the earlier ScopeWeave #523 identities for operational revalidation only.

  • consumer: ContextualWisdomLab/scopeweave#523
  • exact contributor head: f36eb4a838f8d86f9890133f3102aee4f0f46119
  • independently resolved live base: develop@1fadec04195805722829b386475a09a15f8cd926
  • Strix check/job: 95477311978 (workflow run 32059506525)
  • GitHub result: completed/success
  • bound warning annotation: Strix backend unavailable; the backend failed before producing any vulnerability report due to rate-limit/token-cap/connection/warm-up failure and the workflow explicitly treated this as a neutral skip so infrastructure outage would not block merges.

This is the same central false-green contract, now reproduced on the current #523 head. Acceptance for the owner repair remains test-first: provider exhaustion before a complete scan must yield a typed non-passing provider/infrastructure result; complete clean scans may pass; real source findings remain fail-closed and source-backed. After #955 integrates to protected main, rerun the then-current unchanged #523 head and bind acceptance to its exact head/run/job/annotation identities. No ScopeWeave-local workaround is appropriate.

@opencode-agent
opencode-agent Bot disabled auto-merge August 18, 2026 01:27

Copy link
Copy Markdown
Contributor Author

Fresh consumer-owner evidence from ScopeWeave: central protected main has advanced to 092df969f71c7afc56dd9ab2662b016ad40696c8 (merge of #1116), while #955 remains on 69850cdbb8b9f5791ae6b216366ee630bff24721 and GitHub now reports mergeable: false. Please reconcile this existing owner branch non-destructively with the live main before regenerating exact-head Strix evidence. Preserve the current repair contract: provider/backend exhaustion must be typed non-passing, never success/neutral-success; then rerun unchanged ScopeWeave canary #523 (f36eb4a838f8d86f9890133f3102aee4f0f46119) or its freshly reconciled successor after protected integration.

Copy link
Copy Markdown
Contributor Author

Fresh Context Fabric consumer reproduction on ContextualWisdomLab/enterprise-architecture-core#14 confirms the same required-Strix false-green boundary on a new exact head.

Exact identities

  • consumer PR/head: enterprise-architecture-core#14 @ ca6889497728e1a3f09d68790a9096576e13a3ff
  • live base: develop@1c0fa8b15ceb9e72186274aeb255d6777eb84ef4
  • required Strix run/job: 32036458615 / 95407832860
  • central workflow SHA used by the run: .github@c47afc2dc68488292c1db7c9d6f82dcd5360f181
  • event: pull_request_target; the job first checked out the base and then explicitly fetched/materialized the exact PR head above, so target identity is not the defect.

Observed first failing boundary
The scan never produced complete clean security evidence, yet the required workflow concluded success. The primary NVIDIA NIM attempt (nvidia/nemotron-3-super-120b-a12b) hit repeated HTTP 429 rate limits. The next NIM fallback ran but emitted internally contradictory/incomplete output (1 blocking issue identified / Semgrep vulnerability language while the UI summary reported Vulnerabilities 0) and no governed vulnerability-report artifact was accepted. GitHub Models fallbacks (openai/o3, openai/gpt-5-chat) then failed warm-up with HTTP 410 github_models_retirement_brownout.

The trusted wrapper correctly logged that this was not clean evidence — Strix reported zero vulnerabilities before provider infrastructure failure; failing closed because provider infrastructure failures are not clean scan evidence. — but the outer backend-unavailable branch subsequently converted that non-passing state to exit 0 with the warning that it was Treating as a neutral skip so an infrastructure outage does not block merges. Job 95407832860 therefore ended success despite provider exhaustion/incomplete evidence. Artifact strix-reports is 9291327660 (digest d554ddbf238211a2baecf2049978fd972ceaf4fceb07d181ebb437e39d63d19a). OpenCode app-token exchange also returned HTTP 500, but the public-repo path continued; it is not the causal false-green boundary.

RED acceptance
A deterministic required-workflow regression where all governed backends are unavailable/rate-limited/retired and no complete structured vulnerability report exists must conclude non-passing (failure or an explicitly unavailable state that cannot satisfy the required check), never success/neutral-success. The regression should also reject contradictory/incomplete scanner output as clean zero-vulnerability evidence.

Smallest central remedy
Preserve bounded fallback/retry, but remove the required-workflow mapping from exhausted backend/provider unavailability to exit 0. Optional/manual diagnostics may remain neutral if desired, but a required Strix check must fail closed until a complete exact-head scan exists. Do not fabricate source findings from infrastructure failure.

GREEN / Context Fabric revalidation
After this PR (or its accepted successor) reaches protected central main, prove (1) synthetic all-provider-unavailable coverage is non-success, and (2) rerunning then-current unchanged EA #14 either yields a complete coherent exact-head Strix scan with no unresolved findings or remains explicitly non-passing. Until then, run 32036458615 is status-success only and is not merge-readiness evidence for EA #14.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

2 participants