Skip to content

Migrate OpenCode review model pool off GitHub Models before 2026-07-30 retirement #624

Description

@seonghobae

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-review repository_dispatch run org-wide fails with OPENCODE_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_TOKEN was failing 401/403 and masking the || github.token fallback; 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)

  1. Top up OpenRouter credits (pool falls through automatically), or
  2. Restore OpenAI quota, or
  3. 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-models provider block in opencode.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) in ContextualWisdomLab/.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.yml GitHub 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) and scripts/ci/strix_quick_gate.sh (~3605, ~3620).
  • Update sibling-repo opencode.jsonc copies (naruon, scopeweave, newsdom-api, bandscope, pg-erd-cloud, codec-carver) and noema central-review.yml NOEMA_FALLBACK_LLM_API_KEY.
  • Update prose/docs: docs/org-required-workflow-rollout.md (model token posture, line ~42), PR_GOVERNANCE_AUDIT.md if 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.

Activity

  1. seonghobae commented on Jul 30, 2026

    @seonghobae
    ContributorAuthor

    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: read as STRIX_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 d262e446 the run reports COVERAGE_EVIDENCE_RESULT: success — the only failing signal is OPENCODE_MODEL_POOL_OUTCOME: exhausted. This matters for the recovery plan: before #657, restoring a provider would still have left keyverse / semantic-data-portal failing at ModuleNotFoundError in 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-review check has no model to produce APPROVE evidence, and the ruleset (non-pusher approval + passing opencode-review) correctly blocks a force-merge. The cleanest sequence once a provider is available:

    1. 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.
    2. 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

  2. seonghobae commented on Aug 1, 2026

    @seonghobae
    ContributorAuthor

    Current-head Strix evidence update (2026-08-01)

    The provider migration remains active and now has exact current-head evidence from .github#687 at cf51e0481c75b6ac4b9abec1d7a4f2d29aa2ced9.

    • Workflow run: https://github.com/ContextualWisdomLab/.github/actions/runs/30677113527 (job 91306582553)
    • Artifact: strix-reports, artifact id 8810954014
    • 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_brownout for openai/o3 and openai/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.

  3. seonghobae commented on Aug 1, 2026

    @seonghobae
    ContributorAuthor

    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.

  4. seonghobae commented on Aug 1, 2026

    @seonghobae
    ContributorAuthor

    Additional current-head Strix provider evidence from naruon#1210 at 76c1c2df3c7f80b8a270864dea2ce63ec4fd86b0: run 30686711308, job 91333886096 attempted NVIDIA NIM and received HTTP 429, then attempted github_models/openai/o3 and github_models/openai/gpt-5-chat, both returning HTTP 410 github_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.

  5. seonghobae commented on Aug 8, 2026

    @seonghobae
    ContributorAuthor

    Fresh protected-main runtime RCA — 2026-08-09 KST

    Revalidated the live protected-main review plane rather than reusing the July/August-1 canaries.

    • Protected main is still 6eb06cdd08c79a06f7b390069d4ffa49e2eb7dba.
    • Current central OpenCode run 31265950492, opencode-review job 93139645486, successfully materialized source/coverage evidence and entered the model pool.
    • The pool configured 13 candidates. After nvidia-nim/mistralai/mistral-small-4-119b-2603 consumed its bounded 180-second attempt and timed out, the next candidates still included retired GitHub Models entries such as github-models/openai/gpt-5, github-models/openai/gpt-5-chat, github-models/openai/o3, plus other github-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

    1. Retry/top-up only: can improve NVIDIA/OpenRouter/OpenAI availability but cannot make retired GitHub Models viable. Reject as a migration fix.
    2. Add invented/replacement credentials: rejected; this loop has no authority to create org secrets and credentials cannot resurrect a retired service.
    3. 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.
    4. 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.

  6. added
    area: apiAPI, protocol, event, or external contract
    area: ci-cdCI, GitHub Actions, checks, release, or supply chain
    area: dataDatabase, schema, migration, ETL, or lineage
    area: securitySecurity boundary, hardening, or vulnerability prevention
    status: blockedBlocked by conflict, dependency, or required prerequisite
    type: featureNew or expanded product capability
    on Aug 22, 2026
  7. seonghobae commented on Aug 23, 2026

    @seonghobae
    ContributorAuthor

    Current-head evidence update (2026-08-22/23)

    Two more current-head reviews stalled on the same OPENCODE_MODEL_POOL_OUTCOME: exhausted path this cycle, org-wide review-dispatch backlog directly attributable to this:

    • ContextualWisdomLab/.github#1238 at head 23f022c9863c66dadc60fdf21fb3da91965d350c: run 32601740155, opencode-review job failed with MODEL: 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 hit gh: API rate limit exceeded for installation ID 141441800, so even the failure signal itself didn't reliably post back to the PR.
    • ContextualWisdomLab/ThreadWeave#34 at head c2cd1763d839d2600cc77cf47e5a866eecee7472: run 32600666270 (dispatched centrally from .github), same opencode-review failure 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.

  8. 94 remaining items

  9. seonghobae commented on Aug 30, 2026

    @seonghobae
    ContributorAuthor

    Post-#1451 unchanged-head Orgmetra OpenCode acceptance canary; existing owner lane only.

    Central .github/main has now advanced to 1d8e872487838e16a003e96e76df9300c388e258 (fix(ci): close the org-wide 100%-coverage gap blocking OpenCode review dispatch). I therefore reran only the supported required OpenCode job for ContextualWisdomLab/Orgmetra#40 without 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-tree job 99261729346: SUCCESS
    • replacement coverage-evidence job 99261729773: SUCCESS
    • newly materialized required-workflow-bootstrap job 99261746015: 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] APPROVED or CHANGES_REQUESTED bound to commit_id=6917e41f...
    • verifier therefore terminates FAILURE with 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.

  10. seonghobae commented on Aug 30, 2026

    @seonghobae
    ContributorAuthor

    Post-#1451 Orgmetra unchanged-head OpenCode canary — coverage repair is GREEN, verdict publication still absent

    Dedicated-writer handoff only; no .github source/ref/workflow/settings mutation was made from the Orgmetra loop.

    Central protected main has advanced to 1d8e872487838e16a003e96e76df9300c388e258 via #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-bootstrap check 99261746015: SUCCESS
    • coverage-source-tree check 99261729346: SUCCESS
    • coverage-evidence check 99261729773: SUCCESS
    • opencode-review job/check 99261729259: terminal FAILURE

    Exact verifier log for 99261729259 binds TARGET_REPOSITORY=ContextualWisdomLab/Orgmetra, PR_NUMBER=40, and HEAD_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 predecessor 8d8896b... 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-review must become terminal SUCCESS while bootstrap/source-tree/coverage evidence remains exact-head GREEN; absent/model-only/status-only/predecessor evidence must remain non-passing.

  11. seonghobae commented on Aug 30, 2026

    @seonghobae
    ContributorAuthor

    Fresh Orgmetra exact-head canary after the coverage-evidence prerequisite recovered: ContextualWisdomLab/Orgmetra#54 head 90e2cffdafb2ca385359068b53f5ca1dc437a5af, live base develop@9e3e4847510e1e612b48474ba42b177b8ed824df. Required OpenCode workflow run 33329979102 now has coverage-source-tree job 99306796483 SUCCESS and coverage-evidence job 99306945527 SUCCESS on this exact head. The downstream opencode-review verifier job 99307012940 then failed solely because the PR review API contained no APPROVED or CHANGES_REQUESTED review from opencode-agent whose commit_id equals 90e2cff...; 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 to cc6784ec... was dismissed explicitly as non-transferable evidence; this does not satisfy the gate. Acceptance for this unchanged consumer head: authenticated OpenCode dispatch must actually review 90e2cff..., publish a formal current-head APPROVED or CHANGES_REQUESTED, then the verifier must consume that exact verdict without fallback/synthetic/model-only evidence.

  12. seonghobae commented on Aug 30, 2026

    @seonghobae
    ContributorAuthor

    Fresh 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 job 99329036209

    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 authenticated opencode-agent / opencode-agent[bot] formal reviews whose commit_id equals that exact head and whose state is APPROVED or CHANGES_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-agent formal APPROVED or CHANGES_REQUESTED review bound to commit_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 .github source/ref/workflow/settings mutation was performed from the Orgmetra writer loop.

  13. seonghobae commented on Aug 31, 2026

    @seonghobae
    ContributorAuthor

    Post-#1456 unchanged-head Orgmetra OpenCode acceptance canary; existing owner lane only.

    Central protected .github/main is now 046bc2beb2e0bb4be804255764bcbb4c49e973e9, 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 on ContextualWisdomLab/Orgmetra#40.

    • consumer exact head: 6917e41f9053fab6f7e99f8185f2137e8fc5fca5
    • independently resolved live base: develop@9e3e4847510e1e612b48474ba42b177b8ed824df
    • Required OpenCode run: 33294991594, attempt 6
    • replacement opencode-review job: 99364149987
    • required-workflow-bootstrap, coverage-source-tree, and coverage-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] APPROVED or CHANGES_REQUESTED bound to commit_id=6917e41f...; the only historical OpenCode REQUEST_CHANGES is dismissed and bound to predecessor 8d8896b...

    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-head APPROVED or CHANGES_REQUESTED verdict, 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.

  14. seonghobae commented on Aug 31, 2026

    @seonghobae
    ContributorAuthor

    Distinct post-#1456 Draft-consumer canary from Orgmetra; existing owner lane only.

    ContextualWisdomLab/Orgmetra#44 is still Draft at exact head dbe465daad3c4ec60a2328046d09a93b1b9e67ec over live develop@9e3e4847510e1e612b48474ba42b177b8ed824df. After #1456's draft explicit-review dispatch change was already integrated, an explicit review-only @opencode-agent request was posted at 2026-08-31T02:07:39Z (issue comment 5472818654) while central main was 1cf2f9120a2cd494ed5079135bb10822c27b5947.

    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] APPROVED or CHANGES_REQUESTED for this head;
    • central .github repository-dispatch inventory for 02:00Z..02:15Z contains three runs and none targets Orgmetra#44 / dbe465d...;
    • Orgmetra itself has no issue_comment workflow 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.

  15. seonghobae commented on Aug 31, 2026

    @seonghobae
    ContributorAuthor

    Post-#1468 unchanged-head Orgmetra acceptance canary; existing owner lane only.

    Central protected .github/main advanced to b80e0c24fabd423fe0fe7f692578bff370123070. That history includes #1468 (d7b01bc643333bd969d8c3c77da2043fba3d01a3), which explicitly updated Noema/Strix/OpenCode sidecars to contextual-orchestrator c107e3e52371993aa9c326fcc245e01c41fc3850 and 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, attempt 7, started 2026-08-31T03:59:57Z
    • replacement jobs: bootstrap 99377019398 SUCCESS; coverage-source-tree 99377019756 SUCCESS; coverage-evidence 99377020011 SUCCESS; opencode-review 99377019594 FAILURE
    • 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-head APPROVED or CHANGES_REQUESTED review for 6917e41f.... 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 APPROVED or CHANGES_REQUESTED bound 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 .github source/ref/workflow/settings mutation and no Orgmetra workaround was performed from this writer loop.

  16. seonghobae commented on Aug 31, 2026

    @seonghobae
    ContributorAuthor

    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

    • exact head: 6917e41f9053fab6f7e99f8185f2137e8fc5fca5
    • live base: develop@9e3e4847510e1e612b48474ba42b177b8ed824df
    • downstream Required OpenCode run: 33294991594, latest attempt 8
    • failing downstream opencode-review job: 99422517837
    • dispatched central .github run: 33371238759
    • first failing central job: coverage-evidence 99423028429
    • exact-head authenticated formal review: opencode-agent[bot] review 5064395734, state COMMENTED, body classifies the review as COVERAGE_BLOCKED; it is not an APPROVED/CHANGES_REQUESTED verdict

    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 only COMMENTED/COVERAGE_BLOCKED evidence 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 stable coverage-evidence slot complete successfully; after the exact-head COMMENTED review exists, verifier job 99422517837 still terminates at Fail 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-evidence passes using one coherent measurement owner, preserves the 100% statement/branch and documentation gates, the OpenCode review proceeds, and an authenticated Reviews API APPROVED or CHANGES_REQUESTED verdict is published for exact head 6917e41...; the required verifier must then terminate consistently with that verdict. COMMENTED/COVERAGE_BLOCKED, status-only, model-only, or predecessor evidence is not sufficient.

  17. seonghobae commented on Aug 31, 2026

    @seonghobae
    ContributorAuthor

    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:

    • PR: Orgmetra ⚡ Bolt: iter_json_objects JSON 디코딩 성능 최적화 #42
    • head: fb03c0837b38424412fa774576a8ded0f9847896
    • live protected base: develop@9e3e4847510e1e612b48474ba42b177b8ed824df
    • central review run: 33371635973
    • coverage-source-tree job: 99424380243 (FAILURE)
    • coverage-evidence job: 99424380250 (FAILURE)
    • dispatch-opencode-review job: 99424380269 (SUCCESS)
    • opencode-pr-review job: 99424431232 (SUCCESS, exact-head formal review published as VERDICT: COVERAGE_BLOCKED)
    • final opencode-review job: 99424431239 (FAILURE, correctly fail-closed because the formal verdict is not substantive)

    First causal boundary, reproduced within the SAME exact run/source/tests:

    1. 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 -q and gets 119 passed; 397/397 statements; 224/224 branches = 100%.
    2. The config-root detector then reads packages/hris-kernel/pyproject.toml, whose pytest addopts already enables pytest-cov: --cov=orgmetra_hris --cov-report=term-missing --cov-fail-under=100 --cov-branch.
    3. Central evidence code wraps those same tests again in outer python -m coverage run ... -m pytest .... The nested coverage controllers collide: pytest-cov reports module-not-measured/no-data-collected, produces an artificial 0% report and fails its 100% threshold; outer coverage then reports module-not-imported/No data to report.
    4. Central manifest marks python_config blocked with test_command_failed even though python_conventional proved 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 run owns 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 no no-data-collected, module-not-measured, module-not-imported, or No data to report; source-tree/evidence contracts must be GREEN; only then may exact-head OpenCode proceed beyond COVERAGE_BLOCKED. Do not lower thresholds or transfer predecessor evidence.

  18. seonghobae commented on Sep 1, 2026

    @seonghobae
    ContributorAuthor

    Fresh Orgmetra exact-head OpenCode canary, 2026-09-01: ContextualWisdomLab/Orgmetra#40@6917e41f9053fab6f7e99f8185f2137e8fc5fca5 required opencode-review run 33294991594, job/check 99422517837 acquired 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 no opencode-agent / opencode-agent[bot] APPROVED or CHANGES_REQUESTED verdict 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/main has since advanced to 476e8be3037800fb84e7ba780ed2068ffdfe3da5 with 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.

  19. added
    priority: criticalImmediate blocker, P0, urgent deadlock, or critical incident
    type: maintenanceMaintenance, build, dependency, or operational upkeep
    on Sep 7, 2026
  20. seonghobae commented on Sep 12, 2026

    @seonghobae
    ContributorAuthor

    Fresh Wardnet Strix consumer canary — 2026-09-12 KST, exact ContextualWisdomLab/wardnet#93@5733ea5af9e8684851b05e82678768d3c1adbd93, protected base main@f8260f1e03836039ff9463dd99fa982e4e270c4b.

    Central Strix run 34571842119, job 103176422726, 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-models provider 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:

    1. Keep this consumer head/base unchanged and remove github-models from every executable Strix/NiM candidate/fallback route, not only prose/configuration that is no longer selected.
    2. 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.
    3. 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.
    4. Re-read the live consumer head/base before terminal publication and reject stale-head evidence.
    5. 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.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: apiAPI, protocol, event, or external contractarea: ci-cdCI, GitHub Actions, checks, release, or supply chainarea: dataDatabase, schema, migration, ETL, or lineagearea: securitySecurity boundary, hardening, or vulnerability preventionmaintenancepriority: criticalImmediate blocker, P0, urgent deadlock, or critical incidentstatus: blockedBlocked by conflict, dependency, or required prerequisitetype: featureNew or expanded product capabilitytype: maintenanceMaintenance, build, dependency, or operational upkeep

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions