fix(review): materialize exact-head review jobs after Ready transition

[seonghobae]

Problem

A pull request can move from Draft to Ready without materializing a fresh OpenCode or Noema workflow/check. The existing check names remain GREEN only because their Draft-path jobs exited successfully without publishing an authenticated review. This creates a circular review-admission state: the PR is Ready and mechanically mergeable, but the only visible review checks explicitly say review was deferred until Ready.

Exact RED canaries — 2026-09-08

html4tree#600

• exact head: b7fb8140b6bdcbe3d58defe526408d24d6b2d8d3;
• Ready transition: 2026-09-08T11:10:12Z;
• existing OpenCode job 101586092792: PR is still a draft ... review is not requested until it is marked ready;
• existing Noema job 101580026200: PR is draft; Noema verdict preparation skipped;
• new runs/checks after Ready: 0;
• exact-head Reviews API verdicts: 0;
• related repository-enrollment issue: [PR governance] Enroll html4tree in central OpenCode review dispatch #1003.

wardnet#130

• exact head: 2785e682e0ebb96fc15e5576729e253057538c2f on live main@a52ccd0a24a727d9349bb32def7713882d8cad1e;
• Ready transition: 2026-09-08T12:07:22Z;
• existing OpenCode job 102040819368: Draft-path review deferral;
• existing Noema job 102040038685: PR is draft; Noema verdict preparation skipped;
• all 30 source/security checks were terminal GREEN or contract-valid skipped and unresolved threads were 0 before admission;
• new runs/checks after Ready: 0;
• exact-head Reviews API verdicts: 0.

Owner repair contract

1. Add executable RED fixtures for Draft synchronize → Draft skip-success → unchanged-head ready_for_review.
2. Ensure the Ready transition or bounded central reconciliation materializes fresh OpenCode and Noema check identities bound to the live repository, PR number, and exact current head.
3. Never treat a Draft-path skip-success as substantive Ready-state review evidence.
4. Require an authenticated exact-head APPROVED or CHANGES_REQUESTED Reviews API submission; status-only success is insufficient.
5. Re-read live open/Draft/head state before dispatch and before verdict admission; stale events must not review or cancel a newer head.
6. Keep orchestrator/free, gateway-token-only routing, fail-closed missing capability, existing concurrency isolation, and ordinary branch protection.
7. Prove GREEN on both canaries without empty commits, source-neutral leaf churn, manual bypass, or predecessor evidence transfer.
8. Integrate through the canonical active .github writer stack, then rerun unchanged consumer heads and record exact run/job/review IDs before closing.

This issue is distinct from #1003's html4tree allowlist enrollment and complements #1800's model-job concurrency work; it owns lifecycle materialization after Draft → Ready.

[seonghobae]

Third Ready-transition canary: .github#1946 (2026-09-08)

• PR: #1946
• Exact head: 1cb8cceb8719eb054979d84141cda9a95c0c6873
• Ready transition: 2026-09-08T12:38:43Z
• Preconditions: mergeable, ahead 5 / behind 0, unresolved threads 0; prior exact-head Security 34225564319, SAST 34225564279, Python Security 34225564305, and CodeQL PR 34225564271 were terminal GREEN. The only existing CHANGES_REQUESTED review targets obsolete head db361daa….
• Observed after more than 50 seconds: Ready did create new same-head source/security runs (Security 34227246550, SAST 34227246506, Python Security 34227246456, CodeQL PR 34227246385), but created zero OpenCode/Noema review workflows and zero current-head review submissions.
• This reproduces the lifecycle gap inside the canonical .github owner repository itself. Ready admission must materialize required exact-head model-review jobs; source/security reruns alone cannot replace review.

[seonghobae]

Correction to the .github#1946 canary (2026-09-08)

The earlier comment's “zero OpenCode/Noema review workflows” conclusion is withdrawn. The commit-filtered workflow listing returns pull-request-triggered runs and omitted the pull_request_target review runs that Ready did create.

Exact Ready-event evidence:

• Required Noema Review run 34227246936, job 102064305362, was created for ready_for_review and exact head 1cb8cceb8719eb054979d84141cda9a95c0c6873. It failed in the central gateway with HTTP 429 after 97.0 s (phase=response_error, served_model=google/gemma-4-31b-it:free), not on a leaf-source finding.
• Strix run 34227247127, job 102064798463, was also created. Central preflight examined 24 candidates, probed 16, and found ready_count=0; observed failures were provider 429/404/timeout outcomes.
• OpenCode run 34227368475 subsequently submitted current-head CHANGES_REQUESTED, but its only finding is the failed-check rollup above plus CodeQL's temporary pending receipt.
• Same-head CodeQL PR run 34227246385 has since converged to terminal GREEN, and both authenticated CodeQL dispatch status contexts are GREEN.

Therefore .github#1946 does not reproduce “Ready creates no review jobs.” Keep the original html4tree#600 and wardnet#130 canaries and their owner repair contract; exclude .github#1946 from that evidence set. The remaining .github#1946 blocker is central free-pool transport/availability and the derived no-source-verdict review, not lifecycle materialization absence.

[seonghobae]

Fresh Ready-transition canaries still lack exact-head review materialization

Two additional live canaries reproduce the issue without treating Ready as merge authority:

• .github#2043: Ready event 30760345148 at 2026-09-08 14:01:51 UTC on exact head 45ef97c71d2684e0c5437fd8e799fd8fcf7e6dc1. Current commit statuses include Devin, CodeRabbit, and CodeQL dispatch contexts, but no opencode-review; there is no qualifying independent APPROVED review on this head.
• .github#2040: Ready event 30760350170 at 2026-09-08 14:01:56 UTC on exact head 9054b5e664d1540736c6b83a7c4a2bb9399651a3. Current statuses include Devin and CodeRabbit only; no opencode-review and no current-head qualifying approval are present.

Both PRs have replacement hosted workflows queued/in-progress, which is a merge-gate state, not a reason for Draft. Separately, the inherited stale-base status P1 is a source defect and remains recorded on #2040. This comment only adds exact canary evidence; it does not toggle lifecycle, synthesize status, request a bypass, or manually rerun a workflow.

[seonghobae]

Wardnet #130 canary has progressed from the original missing-materialization RED, but exact-head verdict admission is still not complete. Current Wardnet #130 head is 73339df4e9617e533569388b136cd33bd1f6fdc4 on unchanged main@a52ccd0a24a727d9349bb32def7713882d8cad1e.

Fresh Ready-state review identities now materialize on that exact head: opencode-review job 102196792181 and noema-review job 102196709217. The OpenCode job acquired a hosted runner, bound the exact current head, attempted the central dispatch path, and completed FAILURE with the explicit fail-closed condition: no authenticated APPROVED or CHANGES_REQUESTED from opencode-agent exists on the current head; the workflow says dispatch will rerun the failed job after publishing an authenticated exact-head verdict. Noema remains in_progress on the same exact head at the latest read. Repository CI/Security/SAST/CodeQL source checks are otherwise current-head successful; #130's historical reviews do not transfer and current unresolved inline threads are 0.

This is evidence that lifecycle materialization itself now works for the Wardnet canary, so do not repair Wardnet source or use no-op commits. Remaining acceptance for this owner path is: publish authenticated current-head OpenCode/Noema Reviews API verdicts, rerun/reconcile the existing exact-head check identities to terminal conclusions, then re-read PR head/base before admission. Preserve orchestrator/free, gateway-token-only routing and normal protection; no synthetic status or predecessor verdict.

[seonghobae]

Third canary, opposite direction: a PR that cannot reach the Ready transition at all

The two canaries here both crossed Draft → Ready and kept a stale GREEN. semantic-data-portal#81 is the same root defect pointed the other way — it never crosses, and it cannot, because the thing gating its transition is the very verdict the Draft path withholds.

semantic-data-portal#81

• exact head ce40bd89e803642d62268bfab13a831171f2bc62, unchanged since 2026-08-30
• currently Draft; 31 of its 32 checks terminal-success
• opencode-review job 99291035386 is the fail-closed generation and is RED: No APPROVED or CHANGES_REQUESTED from opencode-agent on the current head
• exact-head Reviews API verdicts by opencode-agent[bot]: 0 — and 0 at every commit on the PR, not only the current one
• four @opencode-agent approval requests (2026-08-25, 08-26, 08-30, 08-31) produced no verdict

Unlike html4tree#600 and wardnet#130, this one shows no false green. Its review check is correctly RED. The problem is that nothing can turn it GREEN.

The loop

scripts/ci/pr_review_merge_scheduler.py:2205 is what emits the opencode-review repository_dispatch that produces a verdict. The same file's per-PR decision function discards drafts as its first action, at :2383:

if pr.get("isDraft"):
    return Decision(number, "skip", "draft PR")

That return precedes cancel_stale_pr_runs, the base_ref branch, and every path reaching the dispatch. So a Draft PR is never dispatched.

#81's body sets its own promotion acceptance, item 4: "all valid review threads are resolved and a qualifying independent non-author approval is current."

Draft → scheduler skips → no dispatch → no verdict → item 4 unmet → stays Draft.

The asymmetry inside one repository confirms the mechanism rather than a repo enrollment gap: semantic-data-portal#73, not a draft, received an opencode-agent CHANGES_REQUESTED on 2026-09-09 at head 1681a7f2. The dispatch reaches that repo fine. It just cannot reach a draft.

What this adds to the repair contract

Item 2 currently says "the Ready transition or bounded central reconciliation materializes fresh OpenCode and Noema check identities." The Ready-transition half does not help a PR in this state, since the transition is what is blocked. So the reconciliation half has to be able to reach a still-Draft PR, or the contract has to say explicitly that a verdict is never a precondition for leaving Draft.

Suggested addition as a fourth RED fixture alongside the three in item 1:

Draft PR, unchanged head, fail-closed opencode-review RED, zero exact-head verdicts, no Ready transition available → bounded central reconciliation must still produce an authenticated exact-head verdict, or the run must emit a typed result naming the transition as the required human action.

The second branch is a legitimate outcome — it just needs to be stated, because right now the state is silent rather than typed, and reads from the outside as an ordinary review wait.

#1992 (drop Noema sidecar prep before the Draft skip) is adjacent: it optimizes the Draft skip path, and this note is about that path's terminal state.

Consumer impact

semantic-data-portal's protected main has had no merge since 2026-08-17 with 35 PRs open. #81 is the cryptography 49.0.0 → 50.0.0 bump for CVE-2026-69247, and it is the single writer for that fix, so trivy-fs stays RED on the shared base and the rest of the queue inherits it. Recorded from the consumer side in semantic-data-portal#102, which points here rather than adding any portal-side workaround.

No change proposed to the fail-closed direction, and no transition performed on #81 — that is its author's decision, taken deliberately with criteria in the PR body.

---

Generated by Claude Code