Repository navigation
Migrate OpenCode review model pool off GitHub Models before 2026-07-30 retirement #624
Copy link
Copy link
Open
Labels
area: 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 preventionmaintenancepriority: criticalImmediate blocker, P0, urgent deadlock, or critical incidentImmediate blocker, P0, urgent deadlock, or critical incidentstatus: blockedBlocked by conflict, dependency, or required prerequisiteBlocked by conflict, dependency, or required prerequisitetype: featureNew or expanded product capabilityNew or expanded product capabilitytype: maintenanceMaintenance, build, dependency, or operational upkeepMaintenance, build, dependency, or operational upkeep
Description
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/completions returns 403 with Sunset: Thu, 30 Jul 2026 00:00:00 GMT and a deprecation Link header. User-attributed inference still returns 200, but that also dies on Jul 30.
Consequences observed today:
- Every
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. - The org secret
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). - Remaining pool providers need billing: OpenAI (
insufficient_quota), OpenRouter (HTTP 402 credit-exhausted).
Immediate mitigation (any one restores reviews now)
- Top up OpenRouter credits (pool falls through automatically), or
- Restore OpenAI quota, or
- Stopgap until Jul 30 only: fine-grained PAT with Models read set as org secret
STRIX_GITHUB_MODELS_TOKEN.
Migration work (before 2026-07-30)
- Remove/replace the
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. - Update the model pool candidate list so
github-models/*entries are removed (they burn 8 of every 10 pool attempts today and guarantee slower exhaustion). - Update
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). - Update contract tests that pin the token expressions:
scripts/ci/test_strix_quick_gate.sh(lines ~312–317, ~584–585, ~3820, ~5262) andscripts/ci/strix_quick_gate.sh(~3605, ~3620). - Update sibling-repo
opencode.jsonccopies (naruon, scopeweave, newsdom-api, bandscope, pg-erd-cloud, codec-carver) andnoemacentral-review.ymlNOEMA_FALLBACK_LLM_API_KEY. - Update prose/docs:
docs/org-required-workflow-rollout.md(model token posture, line ~42),PR_GOVERNANCE_AUDIT.mdif it references GitHub Models, AGENTS.md notes in naruon. - Decide replacement default route (Microsoft Foundry per changelog, or OpenRouter/OpenAI as primary) and wire budget monitoring so credit exhaustion pages a human before reviews stall.
Evidence trail
Full diagnosis on #618 (comment 5077949855): provider failure classes, run IDs, before/after fallback signatures.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
area: 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 preventionmaintenancepriority: criticalImmediate blocker, P0, urgent deadlock, or critical incidentImmediate blocker, P0, urgent deadlock, or critical incidentstatus: blockedBlocked by conflict, dependency, or required prerequisiteBlocked by conflict, dependency, or required prerequisitetype: featureNew or expanded product capabilityNew or expanded product capabilitytype: maintenanceMaintenance, build, dependency, or operational upkeepMaintenance, build, dependency, or operational upkeep
Type
Projects
- StatusShow more project fieldsTodo
Activity
seonghobae commentedon Jul 30, 2026
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):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: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
seonghobae commentedon Aug 1, 2026
Current-head Strix evidence update (2026-08-01)
The provider migration remains active and now has exact current-head evidence from
.github#687atcf51e0481c75b6ac4b9abec1d7a4f2d29aa2ced9.91306582553)strix-reports, artifact id8810954014run.json:status=failed,scan_mode=quick, 4 requests, 17,674 total tokens.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.429 Too Many Requests.410 github_models_retirement_brownoutforopenai/o3andopenai/gpt-5-chat.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.seonghobae commentedon Aug 1, 2026
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.
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.
seonghobae commentedon Aug 1, 2026
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 commentedon Aug 8, 2026
Fresh protected-main runtime RCA — 2026-08-09 KST
Revalidated the live protected-main review plane rather than reusing the July/August-1 canaries.
mainis still6eb06cdd08c79a06f7b390069d4ffa49e2eb7dba.31265950492,opencode-reviewjob93139645486, successfully materialized source/coverage evidence and entered the model pool.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.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
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.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.
seonghobae commentedon Aug 23, 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 commentedon Aug 30, 2026
Post-
#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.6917e41f9053fab6f7e99f8185f2137e8fc5fca5develop@9e3e4847510e1e612b48474ba42b177b8ed824df3329499159499261729259coverage-source-treejob99261729346:SUCCESScoverage-evidencejob99261729773:SUCCESSrequired-workflow-bootstrapjob99261746015:SUCCESS, including immutable central-policy materialization/verification and Pingora edge-policy enforcementopencode-agent/opencode-agent[bot]APPROVEDorCHANGES_REQUESTEDbound tocommit_id=6917e41f...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.seonghobae commentedon Aug 30, 2026
Post-#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.ContextualWisdomLab/Orgmetra#406917e41f9053fab6f7e99f8185f2137e8fc5fca5develop@9e3e4847510e1e612b48474ba42b177b8ed824df33294991594required-workflow-bootstrapcheck99261746015: SUCCESScoverage-source-treecheck99261729346: SUCCESScoverage-evidencecheck99261729773: SUCCESSopencode-reviewjob/check99261729259: terminal FAILUREExact 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.seonghobae commentedon Aug 30, 2026
Fresh 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 commentedon Aug 30, 2026
Fresh unchanged-head Orgmetra consumer canary on the current protected central control plane:
ContextualWisdomLab/Orgmetra#711d7ed5bbfb18b35d589c69a6e8d93754ba299589develop@9e3e4847510e1e612b48474ba42b177b8ed824df.github/main:1ff8268255b061461d9d49b4cab4febf9a8e7bfa32843325247, replacement job99329036209The 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.seonghobae commentedon Aug 31, 2026
Post-#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.6917e41f9053fab6f7e99f8185f2137e8fc5fca5develop@9e3e4847510e1e612b48474ba42b177b8ed824df33294991594, attempt6opencode-reviewjob:99364149987required-workflow-bootstrap,coverage-source-tree, andcoverage-evidence: terminal SUCCESS on the same consumer headFail closed without a current-head OpenCode verdictopencode-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.seonghobae commentedon Aug 31, 2026
Distinct 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:
opencode-agent/opencode-agent[bot]APPROVEDorCHANGES_REQUESTEDfor this head;.githubrepository-dispatch inventory for02:00Z..02:15Zcontains three runs and none targetsOrgmetra#44/dbe465d...;issue_commentworkflow run in that same interval, so there is no consumer-local review execution to treat as evidence;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 commentedon Aug 31, 2026
Post-#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#406917e41f9053fab6f7e99f8185f2137e8fc5fca5develop@9e3e4847510e1e612b48474ba42b177b8ed824df33294991594, attempt7, started2026-08-31T03:59:57Z99377019398SUCCESS; coverage-source-tree99377019756SUCCESS; coverage-evidence99377020011SUCCESS;opencode-review99377019594FAILUREFail 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.seonghobae commentedon Aug 31, 2026
Fresh 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
6917e41f9053fab6f7e99f8185f2137e8fc5fca5develop@9e3e4847510e1e612b48474ba42b177b8ed824df33294991594, latest attempt8opencode-reviewjob:99422517837.githubrun:33371238759coverage-evidence99423028429opencode-agent[bot]review5064395734, stateCOMMENTED, body classifies the review asCOVERAGE_BLOCKED; it is not anAPPROVED/CHANGES_REQUESTEDverdictCausal 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.seonghobae commentedon Aug 31, 2026
Downstream 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:
iter_json_objectsJSON 디코딩 성능 최적화 #42fb03c0837b38424412fa774576a8ded0f9847896develop@9e3e4847510e1e612b48474ba42b177b8ed824df33371635973coverage-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)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:
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%.packages/hris-kernel/pyproject.toml, whose pytestaddoptsalready enables pytest-cov:--cov=orgmetra_hris --cov-report=term-missing --cov-fail-under=100 --cov-branch.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.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.seonghobae commentedon Sep 1, 2026
Fresh 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.seonghobae commentedon Sep 12, 2026
Fresh 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:
github-modelsfrom every executable Strix/NiM candidate/fallback route, not only prose/configuration that is no longer selected.This is owner evidence only; Wardnet will not copy Strix/NiM/provider-routing logic.