Repository navigation
Migrate OpenCode review model pool off GitHub Models before 2026-07-30 retirement #624
Description
Activity
Day-of-cutoff status (2026-07-30) — provider is now the sole org-wide merge blocker
Two things changed since this issue was filed (07-25):
1. The GitHub Models retirement is now in effect. Mitigation option 3 (stopgap fine-grained PAT with
models: readasSTRIX_GITHUB_MODELS_TOKEN) no longer works as of today — user-attributed inference dies with the org-attributed path. Only these remain to restore reviews immediately, no code change required (self-healing per #628):- Top up OpenRouter credits (pool falls through automatically), or
- Restore OpenAI quota, or
- Provision a supported replacement provider and wire it (the migration checklist in this issue), e.g. OpenCode Zen / Microsoft Foundry. This one does need a new org secret + one bootstrap admin-merge because of the review-gate chicken-and-egg.
2. The coverage-evidence root cause is fixed and verified. #657 makes the offline coverage sandbox discover hash-pinned base locks by content instead of an exact-basename whitelist. On the current head
d262e446the run reportsCOVERAGE_EVIDENCE_RESULT: success— the only failing signal isOPENCODE_MODEL_POOL_OUTCOME: exhausted. This matters for the recovery plan: before #657, restoring a provider would still have left keyverse / semantic-data-portal failing atModuleNotFoundErrorin the sandbox (empty base deps), so the review would fail on coverage evidence even with a working model. After #657, restoring any provider cascade-heals the whole backlog cleanly.Bootstrap note
#657 itself (and the 5 sibling base-fix PRs it unblocks) cannot self-merge while every provider is exhausted — the required
opencode-reviewcheck has no model to produce APPROVE evidence, and the ruleset (non-pusher approval + passingopencode-review) correctly blocks a force-merge. The cleanest sequence once a provider is available:- Restore a provider (option 1/2 above = zero code), or admin-merge fix(review): materialize base coverage locks by content, not exact filename (org-backlog root cause) #657 to land the coverage fix first.
- The :00/:30 repo and :15/:45 org scheduled scans auto-redispatch the stale reviews; approved heads then auto-merge.
I can implement the full OpenCode Zen migration (opencode.jsonc + the embedded workflow provider blocks + strix routing + contract tests + sibling copies + docs, per the checklist above) on request — it just needs the human decision on the replacement provider and its secret, since I can neither set org secrets nor bypass the ruleset.
Generated by Claude Code
Current-head Strix evidence update (2026-08-01)
The provider migration remains active and now has exact current-head evidence from
.github#687atcf51e0481c75b6ac4b9abec1d7a4f2d29aa2ced9.- Workflow run: https://github.com/ContextualWisdomLab/.github/actions/runs/30677113527 (job
91306582553) - Artifact:
strix-reports, artifact id8810954014 - Structured
run.json:status=failed,scan_mode=quick, 4 requests, 17,674 total tokens. - No structured vulnerability report artifact was produced. The console UI printed
Vulnerabilities 0, but the gate correctly logged that this is incomplete evidence after provider failure and must not be described as a clean Strix scan. - Attempts 1-3: NVIDIA NIM
429 Too Many Requests. - Attempts 4-5: GitHub Models
410 github_models_retirement_brownoutforopenai/o3andopenai/gpt-5-chat. - The outer required check concluded success only through the documented backend-unavailable neutral-skip path, consistent with the policy that uncontrollable provider outages are not merge blockers. Independent Trivy, OSV, dependency-review, pip-audit, Bandit, Semgrep, Gitleaks, CodeQL, and uploaded SARIF evidence for the same head all reported zero findings.
Governance classification: high-sensitivity provider-routing debt, not a source vulnerability and not clean Strix evidence. Remove the retired
github_models/*fallback and wire a supported provider as tracked by this issue.- Workflow run: https://github.com/ContextualWisdomLab/.github/actions/runs/30677113527 (job
Current-head OpenCode canary update (2026-08-01)
The central provider/receipt cascade was exercised end-to-end against ContextualWisdomLab/naruon#1206 at exact head 0ce9d0c215bd7b341a129e362ca05cc94cdbfbe6.
- Scheduler run: https://github.com/ContextualWisdomLab/.github/actions/runs/30677734977
- Central review run: https://github.com/ContextualWisdomLab/.github/actions/runs/30677743465 (job 91308615124)
- Coverage source tree and coverage evidence both succeeded.
- The model pool ran for 66 minutes and reached the bounded 30-attempt ceiling.
- NVIDIA NIM candidates returned a mix of missing control JSON, provider/authentication failures, and bounded timeouts; the combined NIM budget stopped at approximately 900 seconds.
- OpenCode free candidates frequently produced review prose but failed the trusted receipt contract, including missing top-level control JSON, missing exact path/positive-line probe evidence, missing observed proof outcomes, or incomplete verification posture.
- OpenRouter candidates failed with credit-exhausted classification. Later OpenCode/OpenAI/GitHub Models candidates failed immediately and no candidate produced an accepted current-head control block.
- Final outcome: OPENCODE_MODEL_POOL_OUTCOME=exhausted and MODEL_OUTPUT_UNAVAILABLE. No APPROVE or REQUEST_CHANGES review was posted, preserving fail-closed review semantics.
This is not a clean review and not a source-code failure. It confirms that provider availability plus reliable structured-control compliance remain the active review-plane debt. A separate publication-capability defect discovered by the same canary is tracked in #691.
Additional current-head Strix provider evidence from
naruon#1210at76c1c2df3c7f80b8a270864dea2ce63ec4fd86b0: run 30686711308, job 91333886096 attempted NVIDIA NIM and received HTTP 429, then attemptedgithub_models/openai/o3andgithub_models/openai/gpt-5-chat, both returning HTTP 410github_models_retirement_brownout. No structured vulnerability report was produced; the gate explicitly logged that a displayed zero is incomplete evidence after provider failure and only then used the documented backend-unavailable neutral-skip path. This exact head independently has 0 open branch code-scanning alerts, 0 open Medium/High/Critical Dependabot alerts, 0 open secret-scanning alerts, and passing Trivy FS, OSV, dependency-review, Bandit, Semgrep, CodeQL, application tests, production build/image validation, coverage, lint, and typecheck evidence. Classification: provider-routing debt, not a clean Strix report and not a source defect.seonghobae commented
on Aug 8, 2026 ContributorAuthorMore actionsFresh protected-main runtime RCA — 2026-08-09 KST
Revalidated the live protected-main review plane rather than reusing the July/August-1 canaries.
- Protected
mainis still6eb06cdd08c79a06f7b390069d4ffa49e2eb7dba. - Current central OpenCode run
31265950492,opencode-reviewjob93139645486, successfully materialized source/coverage evidence and entered the model pool. - The pool configured 13 candidates. After
nvidia-nim/mistralai/mistral-small-4-119b-2603consumed its bounded 180-second attempt and timed out, the next candidates still included retired GitHub Models entries such asgithub-models/openai/gpt-5,github-models/openai/gpt-5-chat,github-models/openai/o3, plus othergithub-models/*fallbacks. - The same protected-main source still contains those
github-models/*candidates after the July 30 retirement. This is therefore live routing debt, not merely historical documentation.
RCA
The root cause remains stale provider eligibility in the protected-main candidate pool: a permanently retired provider class is still eligible for runtime fallback after a live provider attempt fails. Even without relying on the later provider-specific failure text from this run, attempting a provider retired by contract cannot restore review availability and consumes bounded failover time/attempt budget.
Feasibility screening
- Retry/top-up only: can improve NVIDIA/OpenRouter/OpenAI availability but cannot make retired GitHub Models viable. Reject as a migration fix.
- Add invented/replacement credentials: rejected; this loop has no authority to create org secrets and credentials cannot resurrect a retired service.
- Remove retired
github-models/*candidates and update exact contracts: technically verifiable and causal, but the authoritative model-pool wrapper/tests are currently being modified on PR fix(opencode): allow governed free models for private repositories #830 under an active writer handoff. Starting a competing branch now would violate the repository-writer lease and create avoidable conflict on the same control-plane files. - Wait for fix(opencode): allow governed free models for private repositories #830 to reach a stable exact head, then replay the smallest retirement cleanup onto the resulting protected base: realistic. Acceptance must prove the retired provider prefix is absent from the executable pool/config and exact-head contracts, while supported fallback providers remain fail-closed and bounded.
No source write is being made from this issue while #830 owns the overlapping model-pool files. Re-evaluate immediately after #830 stabilizes/merges; do not close this issue until a protected-main run proves no retired GitHub Models candidate is attempted.
- Protected
- addedarea: apiAPI, protocol, event, or external contractAPI, protocol, event, or external contractarea: ci-cdCI, GitHub Actions, checks, release, or supply chainCI, GitHub Actions, checks, release, or supply chainarea: dataDatabase, schema, migration, ETL, or lineageDatabase, schema, migration, ETL, or lineagearea: securitySecurity boundary, hardening, or vulnerability preventionSecurity boundary, hardening, or vulnerability preventionpriority: mediumNormal-priority or P2 workNormal-priority or P2 workstatus: blockedBlocked by conflict, dependency, or required prerequisiteBlocked by conflict, dependency, or required prerequisitetype: featureNew or expanded product capabilityNew or expanded product capability
on Aug 22, 2026 Current-head evidence update (2026-08-22/23)
Two more current-head reviews stalled on the same
OPENCODE_MODEL_POOL_OUTCOME: exhaustedpath this cycle, org-wide review-dispatch backlog directly attributable to this:ContextualWisdomLab/.github#1238at head23f022c9863c66dadc60fdf21fb3da91965d350c: run 32601740155,opencode-reviewjob failed withMODEL: github-models/deepseek/deepseek-v3-0324,OPENCODE_MODEL_POOL_OUTCOME: exhausted,OPENCODE_MODEL_POOL_MODEL:empty. "existing-approval gate found no reusable real-model approval for head=...; same-head candidates=0" →MODEL_OUTPUT_UNAVAILABLE. The subsequent failure-status publish step then also hitgh: API rate limit exceeded for installation ID 141441800, so even the failure signal itself didn't reliably post back to the PR.ContextualWisdomLab/ThreadWeave#34at headc2cd1763d839d2600cc77cf47e5a866eecee7472: run 32600666270 (dispatched centrally from.github), sameopencode-reviewfailure shape.
Both PRs are otherwise fully green (all required checks pass, no unresolved review threads) and have been re-dispatched multiple times over the last several hours without a successful model-pool pass. Consistent with the migration checklist in this issue still being open — the
github-models/*pool entries are still present and apparently still being attempted first, still guaranteeing early exhaustion before any working provider gets a turn. Not attempting the multi-repo provider migration myself given its scope (7+ repos, billing-dependent options); flagging fresh current-head evidence since the last update here was 2026-08-08.94 remaining items
seonghobae commented
on Aug 30, 2026 ContributorAuthorMore actionsPost-
#1451unchanged-head Orgmetra OpenCode acceptance canary; existing owner lane only.Central
.github/mainhas now advanced to1d8e872487838e16a003e96e76df9300c388e258(fix(ci): close the org-wide 100%-coverage gap blocking OpenCode review dispatch). I therefore reran only the supported required OpenCode job forContextualWisdomLab/Orgmetra#40without changing consumer source/head.- exact consumer head:
6917e41f9053fab6f7e99f8185f2137e8fc5fca5 - exact live base:
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - Required OpenCode run:
33294991594 - new replacement verifier job:
99261729259 - replacement
coverage-source-treejob99261729346:SUCCESS - replacement
coverage-evidencejob99261729773:SUCCESS - newly materialized
required-workflow-bootstrapjob99261746015:SUCCESS, including immutable central-policy materialization/verification and Pingora edge-policy enforcement - fresh formal review enumeration after the rerun still contains no
opencode-agent/opencode-agent[bot]APPROVEDorCHANGES_REQUESTEDbound tocommit_id=6917e41f... - verifier therefore terminates
FAILUREwith the same precise message: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.
This narrows the post-#1451 boundary: required-workflow materialization and same-head coverage support are now GREEN on this 100%-coverage consumer, but the authenticated default-branch OpenCode dispatch still does not produce a formal exact-head verdict during the supported rerun path. The verifier is behaving correctly and must remain fail-closed; no Orgmetra-local source change, synthetic review, predecessor verdict transfer, or self-approval is valid.
GREEN acceptance remains: on unchanged
6917e41f..., cause the existing authenticated OpenCode dispatch path to actually review and post a real terminal formal verdict, then let the required verifier consume that exact review.- exact consumer head:
seonghobae commented
on Aug 30, 2026 ContributorAuthorMore actionsPost-#1451 Orgmetra unchanged-head OpenCode canary — coverage repair is GREEN, verdict publication still absent
Dedicated-writer handoff only; no
.githubsource/ref/workflow/settings mutation was made from the Orgmetra loop.Central protected
mainhas advanced to1d8e872487838e16a003e96e76df9300c388e258via #1451 (fix(ci): close the org-wide 100%-coverage gap blocking OpenCode review dispatch). A fresh required-workflow attempt against an unchanged Orgmetra consumer ran after that integration and isolates the remaining boundary cleanly.- consumer:
ContextualWisdomLab/Orgmetra#40 - exact head:
6917e41f9053fab6f7e99f8185f2137e8fc5fca5 - independently resolved live base:
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - required OpenCode run:
33294991594 required-workflow-bootstrapcheck99261746015: SUCCESScoverage-source-treecheck99261729346: SUCCESScoverage-evidencecheck99261729773: SUCCESSopencode-reviewjob/check99261729259: terminal FAILURE
Exact verifier log for
99261729259bindsTARGET_REPOSITORY=ContextualWisdomLab/Orgmetra,PR_NUMBER=40, andHEAD_SHA=6917e41f..., queries the Reviews API, and fails only with: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.Fresh PR review enumeration likewise has no authenticated
opencode-agent/opencode-agent[bot]APPROVED or CHANGES_REQUESTED review bound to this current head; the historical CHANGES_REQUESTED review is bound to predecessor8d8896b...and cannot transfer.This proves #1451 repaired the coverage prerequisite but does not by itself restore current-head review production/publication for this consumer. There is no correct Orgmetra-local source/status/review workaround.
GREEN acceptance remains: exercise the existing authenticated OpenCode evaluator/dispatch on unchanged
6917e41f..., publish one genuine formal APPROVED or CHANGES_REQUESTED Reviews API verdict bound to that exact SHA, then require the existing verifier to consume it. For an APPROVED verdict,opencode-reviewmust become terminal SUCCESS while bootstrap/source-tree/coverage evidence remains exact-head GREEN; absent/model-only/status-only/predecessor evidence must remain non-passing.- consumer:
seonghobae commented
on Aug 30, 2026 ContributorAuthorMore actionsFresh Orgmetra exact-head canary after the coverage-evidence prerequisite recovered:
ContextualWisdomLab/Orgmetra#54head90e2cffdafb2ca385359068b53f5ca1dc437a5af, live basedevelop@9e3e4847510e1e612b48474ba42b177b8ed824df. Required OpenCode workflow run33329979102now hascoverage-source-treejob99306796483SUCCESS andcoverage-evidencejob99306945527SUCCESS on this exact head. The downstreamopencode-reviewverifier job99307012940then failed solely because the PR review API contained noAPPROVEDorCHANGES_REQUESTEDreview fromopencode-agentwhosecommit_idequals90e2cff...; log: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 stale predecessor REQUEST_CHANGES bound tocc6784ec...was dismissed explicitly as non-transferable evidence; this does not satisfy the gate. Acceptance for this unchanged consumer head: authenticated OpenCode dispatch must actually review90e2cff..., publish a formal current-headAPPROVEDorCHANGES_REQUESTED, then the verifier must consume that exact verdict without fallback/synthetic/model-only evidence.seonghobae commented
on Aug 30, 2026 ContributorAuthorMore actionsFresh unchanged-head Orgmetra consumer canary on the current protected central control plane:
- consumer:
ContextualWisdomLab/Orgmetra#71 - exact consumer head:
1d7ed5bbfb18b35d589c69a6e8d93754ba299589 - independently resolved protected base:
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - protected central
.github/main:1ff8268255b061461d9d49b4cab4febf9a8e7bfa - supported unchanged-head Required OpenCode rerun: run
32843325247, replacement job99329036209
The rerun fails closed in the verifier with:
No APPROVED or CHANGES_REQUESTED from opencode-agent on the current head.The job's target metadata is correct (TARGET_REPOSITORY=ContextualWisdomLab/Orgmetra,PR_NUMBER=71,HEAD_SHA=1d7ed5bb...). The verifier explicitly accepts only authenticatedopencode-agent/opencode-agent[bot]formal reviews whosecommit_idequals that exact head and whose state isAPPROVEDorCHANGES_REQUESTED, so the first causal boundary is current-head review production/publication rather than Orgmetra source or target binding.There is no correct Orgmetra-local root repair: a leaf change cannot cause the foreign reviewer identity to publish an authenticated formal verdict, and a synthetic/status-only/fallback approval would weaken the required control.
RED acceptance is this unchanged exact-head verifier failure. Required GREEN proof: publish a substantive authenticated
opencode-agentformalAPPROVEDorCHANGES_REQUESTEDreview bound tocommit_id=1d7ed5bbfb18b35d589c69a6e8d93754ba299589, then rerun the required verifier to terminal success. Model-only, deterministic fallback, status-only, predecessor-head, or unauthenticated evidence remains non-passing.No Orgmetra source/ref workaround and no
.githubsource/ref/workflow/settings mutation was performed from the Orgmetra writer loop.- consumer:
seonghobae commented
on Aug 31, 2026 ContributorAuthorMore actionsPost-#1456 unchanged-head Orgmetra OpenCode acceptance canary; existing owner lane only.
Central protected
.github/mainis now046bc2beb2e0bb4be804255764bcbb4c49e973e9, which includes #1456's explicit/draft review-dispatch fixes and subsequent scheduler changes. Without changing Orgmetra source or head, I used the supported single-job rerun onContextualWisdomLab/Orgmetra#40.- consumer exact head:
6917e41f9053fab6f7e99f8185f2137e8fc5fca5 - independently resolved live base:
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - Required OpenCode run:
33294991594, attempt6 - replacement
opencode-reviewjob:99364149987 required-workflow-bootstrap,coverage-source-tree, andcoverage-evidence: terminal SUCCESS on the same consumer head- verifier: terminal FAILURE at
Fail closed without a current-head OpenCode verdict - fresh formal-review inventory still has no
opencode-agent/opencode-agent[bot]APPROVEDorCHANGES_REQUESTEDbound tocommit_id=6917e41f...; the only historical OpenCode REQUEST_CHANGES is dismissed and bound to predecessor8d8896b...
This narrows the first failing boundary after #1456/current scheduler integration: consumer-side coverage/bootstrap is no longer causal; an authenticated exact-head OpenCode Reviews API verdict is still not being materialized for this unchanged non-draft consumer. No Orgmetra-local repair can safely synthesize that reviewer identity/verdict.
Acceptance: the existing authenticated OpenCode dispatch/publication path must actually review
6917e41f...(or a fresh successor), publish exactly one formal current-headAPPROVEDorCHANGES_REQUESTEDverdict, and then let the unchanged required verifier terminate consistently with that verdict. No status-only/model-only substitute, author approval, gate weakening, or consumer no-op commit.- consumer exact head:
seonghobae commented
on Aug 31, 2026 ContributorAuthorMore actionsDistinct post-#1456 Draft-consumer canary from Orgmetra; existing owner lane only.
ContextualWisdomLab/Orgmetra#44is still Draft at exact headdbe465daad3c4ec60a2328046d09a93b1b9e67ecover livedevelop@9e3e4847510e1e612b48474ba42b177b8ed824df. After #1456's draft explicit-review dispatch change was already integrated, an explicit review-only@opencode-agentrequest was posted at2026-08-31T02:07:39Z(issue comment5472818654) while central main was1cf2f9120a2cd494ed5079135bb10822c27b5947.Fresh verification more than twenty minutes later:
- PR remains on the same exact Draft head and is mergeable-as-Draft only;
- formal review inventory still contains no
opencode-agent/opencode-agent[bot]APPROVEDorCHANGES_REQUESTEDfor this head; - central
.githubrepository-dispatch inventory for02:00Z..02:15Zcontains three runs and none targetsOrgmetra#44/dbe465d...; - Orgmetra itself has no
issue_commentworkflow run in that same interval, so there is no consumer-local review execution to treat as evidence; - owned Performance Review Quality/Foundation/Recovery/SAST remain same-head GREEN; the separate Dependency Review/Noema/Strix control-plane issues remain non-substitutable.
This is materially distinct from the non-Draft #40 verifier canary: it exercises #1456's intended explicit-review-only path for a Draft sibling-repository consumer and still has no authenticated formal verdict or identifiable dispatched review execution. No Orgmetra-local source or Draft-state change can correctly substitute for that owner behavior.
Acceptance: an explicit sibling-repository Draft mention must be durably routed to the authenticated OpenCode review dispatcher, preserve exact repo/PR/head identity across any Strix→OpenCode sequencing, publish a formal Reviews API verdict on that exact head, and never mark/merge/update the Draft as a side effect. If a queue intentionally delays this path, expose a durable dispatch/queued receipt tied to repo/PR/head rather than silently leaving no authoritative evidence.
seonghobae commented
on Aug 31, 2026 ContributorAuthorMore actionsPost-#1468 unchanged-head Orgmetra acceptance canary; existing owner lane only.
Central protected
.github/mainadvanced tob80e0c24fabd423fe0fe7f692578bff370123070. That history includes #1468 (d7b01bc643333bd969d8c3c77da2043fba3d01a3), which explicitly updated Noema/Strix/OpenCode sidecars to contextual-orchestratorc107e3e52371993aa9c326fcc245e01c41fc3850and credential-account/model-group semantics. Because this is materially newer than the prior #40 canary, I reran only the supported Required OpenCode job without changing Orgmetra source/head.Consumer:
ContextualWisdomLab/Orgmetra#40- exact head:
6917e41f9053fab6f7e99f8185f2137e8fc5fca5 - independently resolved live base:
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - Required OpenCode run:
33294991594, attempt7, started2026-08-31T03:59:57Z - replacement jobs: bootstrap
99377019398SUCCESS; coverage-source-tree99377019756SUCCESS; coverage-evidence99377020011SUCCESS;opencode-review99377019594FAILURE - first failing boundary remains exactly
Fail closed without a current-head OpenCode verdict.
Fresh formal-review state still has no authenticated
opencode-agent/opencode-agent[bot]current-headAPPROVEDorCHANGES_REQUESTEDreview for6917e41f.... Thus #1468's provider-account/model-group repair does not by itself restore the missing sibling-repository Reviews API verdict publication path. Orgmetra source/bootstrap/coverage remain non-causal; no correct Orgmetra-local fix can synthesize the foreign reviewer identity or downgrade the gate.RED acceptance is this unchanged exact-head attempt-7 verifier failure. Required GREEN proof remains: the existing authenticated dispatcher actually reviews the exact consumer head (or its fresh successor), publishes one formal Reviews API
APPROVEDorCHANGES_REQUESTEDbound to that exact commit, and the unchanged required verifier then terminates consistently with that verdict. Status/model-only output, predecessor reviews, author/self approval, no-op commits, and gate weakening remain non-passing.No
.githubsource/ref/workflow/settings mutation and no Orgmetra workaround was performed from this writer loop.- exact head:
seonghobae commented
on Aug 31, 2026 ContributorAuthorMore actionsFresh unchanged-head downstream canary (2026-08-31) narrows the remaining OpenCode failure to the central acquisition-coverage wrapper, not Orgmetra source/tests.
Consumer: ContextualWisdomLab/Orgmetra PR #40
- exact head:
6917e41f9053fab6f7e99f8185f2137e8fc5fca5 - live base:
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - downstream Required OpenCode run:
33294991594, latest attempt8 - failing downstream
opencode-reviewjob:99422517837 - dispatched central
.githubrun:33371238759 - first failing central job:
coverage-evidence99423028429 - exact-head authenticated formal review:
opencode-agent[bot]review5064395734, stateCOMMENTED, body classifies the review asCOVERAGE_BLOCKED; it is not anAPPROVED/CHANGES_REQUESTEDverdict
Causal evidence: exact target checkout/materialization and dispatch succeed. The target project already runs pytest with pytest-cov and independently reports 136/136 tests with exact 100% owned statement/branch coverage. The central fallback then wraps that pytest invocation again with
python3 -m coverage run -m pytest tests; pytest-cov owns/initializes measurement inside that process, so the outer coverage invocation cannot produce the expected report (No data to report/coverage-data ownership collision). AST inspection of the exact production tree finds 37 callable/class definitions and zero missing docstrings, while the package's own docstring regression passes. The dispatch therefore publishes onlyCOMMENTED/COVERAGE_BLOCKEDevidence rather than a qualifying verdict.The downstream required verifier is no longer merely pending: attempt 8 is terminal FAILURE. In the same attempt,
required-workflow-bootstrap,coverage-source-tree, and the stablecoverage-evidenceslot complete successfully; after the exact-head COMMENTED review exists, verifier job99422517837still terminates atFail closed without a current-head OpenCode verdict. This confirms fail-closed verifier semantics are working; the missing qualifying verdict remains downstream of the central acquisition-coverage collision.This is not correctly repairable in Orgmetra by adding arbitrary docstrings, weakening pytest-cov, disabling native coverage, or creating a leaf workaround. The smallest root-cause-changing repair belongs to the central coverage-evidence acquisition path: when a target already has a project-native coverage runner/plugin, consume that authoritative evidence or invoke it without nesting another coverage.py controller.
RED acceptance: rerun the central acquisition flow against the unchanged Orgmetra #40 head above; the current nested-coverage path must reproduce the central coverage-evidence failure and only non-verdict review evidence.
Required GREEN proof: on that same unchanged head, central
coverage-evidencepasses using one coherent measurement owner, preserves the 100% statement/branch and documentation gates, the OpenCode review proceeds, and an authenticated Reviews APIAPPROVEDorCHANGES_REQUESTEDverdict is published for exact head6917e41...; the required verifier must then terminate consistently with that verdict.COMMENTED/COVERAGE_BLOCKED, status-only, model-only, or predecessor evidence is not sufficient.- exact head:
seonghobae commented
on Aug 31, 2026 ContributorAuthorMore actionsDownstream RED acceptance canary from read-only consumer
ContextualWisdomLab/Orgmetra; this is a central coverage-evidence ownership defect, not an Orgmetra source/test defect.Exact consumer state:
- PR: Orgmetra ⚡ Bolt:
iter_json_objectsJSON 디코딩 성능 최적화 #42 - head:
fb03c0837b38424412fa774576a8ded0f9847896 - live protected base:
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - central review run:
33371635973 coverage-source-treejob:99424380243(FAILURE)coverage-evidencejob:99424380250(FAILURE)dispatch-opencode-reviewjob:99424380269(SUCCESS)opencode-pr-reviewjob:99424431232(SUCCESS, exact-head formal review published asVERDICT: COVERAGE_BLOCKED)- final
opencode-reviewjob:99424431239(FAILURE, correctly fail-closed because the formal verdict is not substantive)
First causal boundary, reproduced within the SAME exact run/source/tests:
- Conventional detector executes
python -m coverage run --branch --source packages/hris-kernel/src --omit '*/tests/*,*/test_*.py' -m pytest packages/hris-kernel/tests --maxfail=1 -qand gets 119 passed; 397/397 statements; 224/224 branches = 100%. - The config-root detector then reads
packages/hris-kernel/pyproject.toml, whose pytestaddoptsalready enables pytest-cov:--cov=orgmetra_hris --cov-report=term-missing --cov-fail-under=100 --cov-branch. - Central evidence code wraps those same tests again in outer
python -m coverage run ... -m pytest .... The nested coverage controllers collide: pytest-cov reportsmodule-not-measured/no-data-collected, produces an artificial 0% report and fails its 100% threshold; outer coverage then reportsmodule-not-imported/No data to report. - Central manifest marks
python_configblocked withtest_command_failedeven thoughpython_conventionalproved the identical production tree/tests at 100% immediately beforehand.
Smallest root-cause remedies are at the central detector boundary, without weakening the 100% requirement: either (a) detect native pytest-cov coverage addopts and run project-native pytest instrumentation exactly once, or (b) when the outer
coverage runowns instrumentation, suppress only the native coverage addopts/config for that invocation so exactly one coverage controller exists.RED → GREEN acceptance: after the owner repair reaches protected central
main, exercise the unchanged Orgmetra #42 head/base above. Both conventional/config-root evidence must agree on 119 tests and 397 statements / 224 branches at 100%, with nono-data-collected,module-not-measured,module-not-imported, orNo data to report; source-tree/evidence contracts must be GREEN; only then may exact-head OpenCode proceed beyondCOVERAGE_BLOCKED. Do not lower thresholds or transfer predecessor evidence.- PR: Orgmetra ⚡ Bolt:
seonghobae commented
on Sep 1, 2026 ContributorAuthorMore actionsFresh Orgmetra exact-head OpenCode canary, 2026-09-01:
ContextualWisdomLab/Orgmetra#40@6917e41f9053fab6f7e99f8185f2137e8fc5fca5requiredopencode-reviewrun33294991594, job/check99422517837acquired an Ubuntu 24.04 runner and the authenticated OIDC/App-token dispatch step succeeded. The job then polled exact-head formal reviews for 180×30s and failed after ~93 minutes because noopencode-agent/opencode-agent[bot]APPROVEDorCHANGES_REQUESTEDverdict existed on that SHA. This is review-delivery/control-plane evidence, not an Orgmetra source finding; repository-owned structured-interview, Foundation, Recovery, SAST, coverage and Strix gates are independently terminal-success on the same head. Central.github/mainhas since advanced to476e8be3037800fb84e7ba780ed2068ffdfe3da5with the scheduler-pressure repair, so I have re-run this exact failed OpenCode job without mutating the Orgmetra head. GREEN remains: authenticated dispatch produces a qualifying exact-head formal verdict within a bounded budget; status/fallback/predecessor evidence must not count.- addedpriority: criticalImmediate blocker, P0, urgent deadlock, or critical incidentImmediate blocker, P0, urgent deadlock, or critical incidenttype: maintenanceMaintenance, build, dependency, or operational upkeepMaintenance, build, dependency, or operational upkeep
on Sep 7, 2026 seonghobae commented
on Sep 12, 2026 ContributorAuthorMore actionsFresh Wardnet Strix consumer canary — 2026-09-12 KST, exact
ContextualWisdomLab/wardnet#93@5733ea5af9e8684851b05e82678768d3c1adbd93, protected basemain@f8260f1e03836039ff9463dd99fa982e4e270c4b.Central Strix run
34571842119, job103176422726, checked out the exact Wardnet head, acquired OIDC, prepared the repository-scoped MCP token, and reached the NiM MCP call successfully. The scan then failed with HTTP 504:{"error":"runner_error","detail":"remote runner_failed: remote python failed with exit 1: Provider github-models model openai/gpt-5 did not return any responses","owned_by":"nim-ci"}The central job correctly failed closed, but this proves the retired
github-modelsprovider is still reachable in the live Strix execution path more than six weeks after the 2026-07-30 retirement date tracked by this issue. Wardnet's leaf CI/Fuzz/Security/SAST are GREEN on the same exact head; no Wardnet source change can repair this provider route.RED→GREEN acceptance for the central owner/successor:
- Keep this consumer head/base unchanged and remove
github-modelsfrom every executable Strix/NiM candidate/fallback route, not only prose/configuration that is no longer selected. - Re-run the same-head canary through the supported provider contract. A successful scan must bind repository + PR + base SHA + head SHA + agent + provider/model + central run identity.
- If all supported providers are unavailable, publish a typed terminal provider-unavailable receipt owned by the central/NiM control plane; do not collapse it into an apparent Wardnet source/security finding and do not silently fall through to retired GitHub Models.
- Re-read the live consumer head/base before terminal publication and reject stale-head evidence.
- No leaf source churn, synthetic status, mutable provider dependency, or routine bypass.
This is owner evidence only; Wardnet will not copy Strix/NiM/provider-routing logic.
- Keep this consumer head/base unchanged and remove
- removedpriority: mediumNormal-priority or P2 workNormal-priority or P2 work
on Sep 19, 2026
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsTodo
Problem
GitHub Models is fully retired on 2026-07-30 (changelog). Org-attributed inference for ContextualWisdomLab is already cut off (since ~2026-07-25T00:26Z):
POST https://models.github.ai/orgs/ContextualWisdomLab/inference/chat/completionsreturns403withSunset: Thu, 30 Jul 2026 00:00:00 GMTand a deprecation Link header. User-attributed inference still returns 200, but that also dies on Jul 30.Consequences observed today:
opencode-reviewrepository_dispatch run org-wide fails withOPENCODE_MODEL_POOL_OUTCOME: exhausted→MODEL_OUTPUT_UNAVAILABLE(e.g. runs 30150610014, 30150959330, 30151278716 in.github). All PR merges are blocked because the required review cannot produce approval evidence.STRIX_GITHUB_MODELS_TOKENwas failing 401/403 and masking the|| github.tokenfallback; the dead secret was deleted 2026-07-25. The fallback engages now but is equally rejected (Actions tokens attribute to the org).insufficient_quota), OpenRouter (HTTP 402 credit-exhausted).Immediate mitigation (any one restores reviews now)
STRIX_GITHUB_MODELS_TOKEN.Migration work (before 2026-07-30)
github-modelsprovider block inopencode.jsonc(line ~87"apiKey": "{env:STRIX_GITHUB_MODELS_TOKEN}") and the embedded copies in.github/workflows/opencode-review.yml(~line 3325) and.github/workflows/pr-review-autofix.yml(~line 277) inContextualWisdomLab/.github.github-models/*entries are removed (they burn 8 of every 10 pool attempts today and guarantee slower exhaustion).strix.ymlGitHub Models routing (provider_mode == 'github_models',GITHUB_MODELS_FALLBACK_TOKEN, "STRIX_GITHUB_MODELS_TOKEN is required" gates) to a supported provider (changelog suggests Microsoft Foundry / Copilot).scripts/ci/test_strix_quick_gate.sh(lines ~312–317, ~584–585, ~3820, ~5262) andscripts/ci/strix_quick_gate.sh(~3605, ~3620).opencode.jsonccopies (naruon, scopeweave, newsdom-api, bandscope, pg-erd-cloud, codec-carver) andnoemacentral-review.ymlNOEMA_FALLBACK_LLM_API_KEY.docs/org-required-workflow-rollout.md(model token posture, line ~42),PR_GOVERNANCE_AUDIT.mdif it references GitHub Models, AGENTS.md notes in naruon.Evidence trail
Full diagnosis on #618 (comment 5077949855): provider failure classes, run IDs, before/after fallback signatures.