Repository navigation
fix(review): materialize exact-head review jobs after Ready transition #2045
Description
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:
2785e682e0ebb96fc15e5576729e253057538c2fon livemain@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
- Add executable RED fixtures for Draft synchronize → Draft skip-success → unchanged-head
ready_for_review. - 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.
- Never treat a Draft-path skip-success as substantive Ready-state review evidence.
- Require an authenticated exact-head
APPROVEDorCHANGES_REQUESTEDReviews API submission; status-only success is insufficient. - Re-read live open/Draft/head state before dispatch and before verdict admission; stale events must not review or cancel a newer head.
- Keep
orchestrator/free, gateway-token-only routing, fail-closed missing capability, existing concurrency isolation, and ordinary branch protection. - Prove GREEN on both canaries without empty commits, source-neutral leaf churn, manual bypass, or predecessor evidence transfer.
- 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.
Activity
seonghobae commentedon Sep 8, 2026
Third Ready-transition canary: .github#1946 (2026-09-08)
1cb8cceb8719eb054979d84141cda9a95c0c68732026-09-08T12:38:43Z34225564319, SAST34225564279, Python Security34225564305, and CodeQL PR34225564271were terminal GREEN. The only existingCHANGES_REQUESTEDreview targets obsolete headdb361daa….34227246550, SAST34227246506, Python Security34227246456, CodeQL PR34227246385), but created zero OpenCode/Noema review workflows and zero current-head review submissions..githubowner repository itself. Ready admission must materialize required exact-head model-review jobs; source/security reruns alone cannot replace review.seonghobae commentedon Sep 8, 2026
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_targetreview runs that Ready did create.Exact Ready-event evidence:
34227246936, job102064305362, was created forready_for_reviewand exact head1cb8cceb8719eb054979d84141cda9a95c0c6873. 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.34227247127, job102064798463, was also created. Central preflight examined 24 candidates, probed 16, and foundready_count=0; observed failures were provider 429/404/timeout outcomes.34227368475subsequently submitted current-headCHANGES_REQUESTED, but its only finding is the failed-check rollup above plus CodeQL's temporary pending receipt.34227246385has 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 commentedon Sep 8, 2026
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 event30760345148at 2026-09-08 14:01:51 UTC on exact head45ef97c71d2684e0c5437fd8e799fd8fcf7e6dc1. Current commit statuses include Devin, CodeRabbit, and CodeQL dispatch contexts, but noopencode-review; there is no qualifying independent APPROVED review on this head..github#2040: Ready event30760350170at 2026-09-08 14:01:56 UTC on exact head9054b5e664d1540736c6b83a7c4a2bb9399651a3. Current statuses include Devin and CodeRabbit only; noopencode-reviewand 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 commentedon Sep 8, 2026
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
73339df4e9617e533569388b136cd33bd1f6fdc4on unchangedmain@a52ccd0a24a727d9349bb32def7713882d8cad1e.Fresh Ready-state review identities now materialize on that exact head:
opencode-reviewjob102196792181andnoema-reviewjob102196709217. 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 authenticatedAPPROVEDorCHANGES_REQUESTEDfromopencode-agentexists on the current head; the workflow says dispatch will rerun the failed job after publishing an authenticated exact-head verdict. Noema remainsin_progresson 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 commentedon Sep 9, 2026
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#81is 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
ce40bd89e803642d62268bfab13a831171f2bc62, unchanged since 2026-08-30opencode-reviewjob99291035386is the fail-closed generation and is RED:No APPROVED or CHANGES_REQUESTED from opencode-agent on the current headopencode-agent[bot]: 0 — and 0 at every commit on the PR, not only the current one@opencode-agentapproval requests (2026-08-25, 08-26, 08-30, 08-31) produced no verdictUnlike 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:2205is what emits theopencode-reviewrepository_dispatchthat produces a verdict. The same file's per-PR decision function discards drafts as its first action, at:2383:That
returnprecedescancel_stale_pr_runs, thebase_refbranch, 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 anopencode-agentCHANGES_REQUESTEDon 2026-09-09 at head1681a7f2. 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:
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
mainhas 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, sotrivy-fsstays RED on the shared base and the rest of the queue inherits it. Recorded from the consumer side insemantic-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
docs(gap): link the #81 deadlock to its owner issue
seonghobae commentedon Sep 10, 2026
Fresh Wardnet canary confirms the Ready-state OpenCode materialization/receipt defect remains active on a newer exact head without leaf source ambiguity.
ContextualWisdomLab/wardnet#130cc9c9a568ac30f6a3114e1304a4a582cf41f09e2, basemain@a52ccd0a24a727d9349bb32def7713882d8cad1e102791996045(run34451773791)APPROVEDorCHANGES_REQUESTEDfromopencode-agentexisted on the exact headNo APPROVED or CHANGES_REQUESTED from opencode-agent on the current head. The dispatch workflow will rerun this failed job after publishing an authenticated exact-head verdict.34451774981, Security Scan34451774931, SAST Semgrep34451774988, CodeQL PR34451774929, coverage-evidence and coverage-source-tree terminal SUCCESS; the OpenCode receipt itself is the missing evidence, not a Wardnet source/test failurePlease keep GREEN acceptance bound to an authenticated Reviews-API verdict on the unchanged exact head. Do not convert the failed wrapper/status into approval, require a no-op consumer commit, or count a Draft-path/previous-head receipt.
seonghobae commentedon Sep 10, 2026
Fresh Orgmetra Draft→Ready consumer canary for the exact-head review-materialization contract.
Target PR:
ContextualWisdomLab/Orgmetra#293Exact head:
c35591f460164e6691f7f558488d951e6bcf19d3Protected base:
develop@eb9757f8649aaad026a9865508d9aad50c1a7a4fReady transition: 2026-09-10T09:18:03Z; head did not move.
Before Ready, exact-head
opencode-reviewcheck102814043243completed SUCCESS at 09:15:26Z only because the live PR was Draft. Its log explicitly says no current-head OpenCode review was requested and no verdict was required until Ready. Formal Reviews API was empty. The exact-head Noema check102814071537began at 09:15:23Z before the transition and remained IN_PROGRESS.After marking the same exact head Ready and re-reading the commit checks, total check-run count remained 30 and the visible OpenCode identity was still the pre-Ready Draft-path
102814043243; no fresh OpenCode review identity or authenticated Reviews API verdict had materialized in these post-transition reads. Do not treat the pre-Ready SUCCESS as substantive evidence. The Noema identity also remained the pre-transition job in progress, so its eventual result must be interpreted from its live Ready/head behavior rather than inherited as Draft review evidence.This is a consumer canary, not a request for leaf polling/sleep, synthetic status, self-approval, or gate weakening. Canonical repair remains central: Ready transition must materialize fresh exact-head model-review identities where needed and acceptance must bind to authenticated current-head Reviews API verdicts.
seonghobae commentedon Sep 10, 2026
Orgmetra#293 updates this lifecycle canary. Exact head
c35591f460164e6691f7f558488d951e6bcf19d3was marked Ready without a source/head change. The pre-existing OpenCode check102814043243remained the Draft-path skip-success and no fresh OpenCode identity appeared. The pre-existing Noema workflow34459580183/job102814071537had also been created before the Ready transition; it later ran and failed during model-verdict preparation, so it is not a fresh Ready-transition identity. However CodeRabbit did subsequently materialize a real review on the exact head at 2026-09-10T09:24:07Z with three actionable inline comments, so the earlier broad statement that no review of any kind materialized is now superseded. The defect tracked here remains specifically the absence of fresh Ready-bound OpenCode/Noema identities and authenticated exact-head review verdicts. Those CodeRabbit findings have since been repaired by ordinary-forward Orgmetra commitae0f0e9398f5e8788ca323f3a97813618f6774a0; do not transferc355...Draft-path OpenCode/Noema status to the new head.seonghobae commentedon Sep 10, 2026
Fresh Wardnet Ready-head canary —
ContextualWisdomLab/wardnet#130@8b0acc4189976636c0a80437c3ac5c5c726b4e1fon 2026-09-10 KST.Required OpenCode Review run
34475308142materialized immediately on the unchanged Ready head. Exact jobs prove the wrapper/control-plane path is healthy through admission but still produces no current-head verdict:required-workflow-bootstrap102864539329: SUCCESS; materialized/verified immutable central policy source and edge policy.cancel-superseded-opencode-review-runs102864539708: SUCCESS.admit-current-head102864570414: SUCCESS; exact live Ready/head admitted.opencode-review102864655283: hosted runner acquired;Request current-head OpenCode review executionSUCCESS, thenFail closed without a current-head OpenCode verdictFAILURE.Same exact Wardnet head has repository CI
34475310485, CodeQL PR34475310521, Security Scan34475310535, and SAST Semgrep34475310566terminal SUCCESS. Do not synthesize an approval/status, pin a provider/model, or churn this documentation-only source. Acceptance remains an authenticated exact-head OpenCode verdict/review receipt that the required wrapper can consume deterministically.seonghobae commentedon Sep 10, 2026
Fresh unchanged-head Ready-transition canary from
ContextualWisdomLab/Orgmetra#293after repairing #294. Exact source headd907edf320fe291de1c373afbcc115f4bf416254, live basedevelop@eb9757f8649aaad026a9865508d9aad50c1a7a4f. The PR was Draft while #294 docs were inconsistent; after ordinary-forward ADR/TRACEABILITY/doctoring repair and exact-head Foundation/SAST/Security/CodeQL completion, it was marked Ready at 2026-09-10T15:10:29Z without changing head/base.Immediately after Ready, the exact-head check inventory still had total_count=30 and only the pre-transition OpenCode identity
102925831377(run34493436763, 15:06:31–15:06:37Z SUCCESS) plus the already-running Noema identity102925795984(run34493436603, started 15:06:25Z). No fresh post-Ready OpenCode/Noema check identity materialized, and formal Reviews inventory still contained COMMENTED only / no qualifying APPROVED. Because the OpenCode identity predates Ready, its SUCCESS is not sufficient evidence that Ready-state substantive review occurred; please preserve exact-head lifecycle evidence and prove the fresh post-transition identity/verdict path per this issue's acceptance contract. No empty commit, leaf rerun shim, predecessor verdict transfer, self-approval, or bypass was used.seonghobae commentedon Sep 10, 2026
Fresh unchanged-head Draft→Ready canary:
ContextualWisdomLab/Orgmetra#295, exact headd15a741c10685208b124477e9d7820cdf17339e8, basedevelop@eb9757f8649aaad026a9865508d9aad50c1a7a4f.#295 was marked Ready at 18:37:32Z with no head/base mutation. Fresh post-transition check inventory remains
total_count=32. There is no new OpenCode or Noema check identity attributable to the Ready transition:34515071712/102998414057ran 18:33:48–18:33:53Z while the PR was still Draft and is only a Draft-path SUCCESS;34515071821/102998527419started 18:34:23Z before Ready and remains the same current-head identity;This reproduces the materialization gap without an empty commit: unchanged-head
ready_for_reviewdid not create fresh current-head OpenCode/Noema review identities or an authenticated current-head review verdict. Keep the canonical repair at the central event/materialization layer; do not require leaf no-op pushes or predecessor verdict transfer.17 remaining items
seonghobae commentedon Sep 13, 2026
Canonical partial owner convergence: #2109 — 2026-09-13
Fresh owner-repository review found that the generalized non-model portion of this lifecycle defect already has an active canonical source lane: #2109, exact
cc6e39f207649c3738a93fe1d6ca1447d090885a, Ready on.github/main@fb17ef556f94f673234aa557254ae52779e9a7b0.#2109 is not just adjacent queue work. Its explicit contract covers Draft admission plus unchanged-head Ready restoration for the five central workflows Security Scan, Runtime Quality, Python Security, SAST, and CodeQL PR. Its hosted canary records Draft executions skipped and fresh same-head Ready executions materialized for all five (
34690412444,34690412462,34690412487,34690412394,34690412449). On the current #2109 head, Security/Runtime/Python-Security/SAST are terminal SUCCESS; CodeQL remains terminal FAILURE at a separate run-wide settlement defect attributed there to #2106 rather than to missing Ready materialization.This means LineageWeave canaries #1047/#1054/#1055 must not trigger a second
.githubimplementation for Security/SAST/CodeQL Ready restoration. Preserve #2109 as that source writer and, after its ordinary protected integration, rerun an unchanged LineageWeave consumer head to prove the cross-repositoryready_for_reviewpath actually materializes those deferred identities.This does not close #2045. Its remaining acceptance still includes the model-review/cross-repository side: fresh OpenCode/Noema (and where governed, Strix) identities on unchanged-head Ready, authenticated exact-head Reviews API publication, stale-event/head checks, and downstream consumer proof without empty commits, lifecycle cycling, synthetic statuses, or predecessor verdict transfer. The existing #1055 observation that a real causal head move while already Ready materializes the whole central workflow set remains useful scope-control evidence; it is not a substitute for unchanged-head Ready reconciliation.
seonghobae commentedon Sep 13, 2026
LineageWeave unchanged/casual-head reconciliation canary update: PR #1055 exact
50c4935eef1029467595f7004818643598b737c9, Required OpenCode run34746057593.All admission/bootstrap paths succeeded: required-workflow materialization, immutable central policy resolution/verification, Pingora policy, superseded-run cancellation, exact live-head admission, and dispatch request.
opencode-reviewjob103694143716then failed specifically atFail closed without a current-head OpenCode verdictimmediately afterRequest current-head OpenCode review executionsucceeded. This is not a leaf source/test failure and no provider/model fallback or manual success was added in LineageWeave.The current-head causal commit did correctly materialize a fresh Required OpenCode identity, so this canary is narrower than the Ready-transition materialization defect: it demonstrates verdict publication/settlement is not available to the required consumer at the point it evaluates the exact head. Please preserve exact-head fail-closed semantics while reconciling a legitimately late current-head verdict rather than requiring leaf no-op churn/repeated lifecycle flips.
seonghobae commentedon Sep 13, 2026
LineageWeave #1055 late OpenCode publication canary — terminal verdict/reconciliation gap
Fresh exact-head evidence narrows the remaining OpenCode defect for
ContextualWisdomLab/LineageWeave#1055@50c4935eef1029467595f7004818643598b737c9.Required OpenCode run
34746057593/ job103694143716admitted the exact live ready head and successfully dispatched the review request. At2026-09-13T07:47:12Zit then failed closed because there was no current-headAPPROVEDorCHANGES_REQUESTEDreview fromopencode-agent.The dispatch did later publish a current-head OpenCode review:
opencode-agentsubmitted aCOMMENTEDreview at2026-09-13T07:58:55Z, identifying head50c4935eef1029467595f7004818643598b737c9and workflow run34746082362. The review reports no source-backed product finding and a separate coverage-gate failure. It is therefore both late relative to the already-terminal required consumer and non-admissible under the required consumer contract, which accepts only exact-headAPPROVEDorCHANGES_REQUESTEDverdicts.This canary should not trigger any LineageWeave-local reviewer, provider/model fallback, no-op commit, lifecycle cycling, synthetic status, or gate weakening. Canonical-owner acceptance should ensure that a successful OpenCode dispatch publishes an authenticated exact-head terminal verdict (
APPROVEDorCHANGES_REQUESTED) and deterministically reconciles/reruns the already-created required consumer after legitimate late publication, while preserving fail-closed behavior when no terminal verdict can be produced.seonghobae commentedon Sep 13, 2026
Additional unchanged-head Ready canary from
ContextualWisdomLab/LineageWeave#859: exact head2550e8d88339e30297fa0aa19ffae77f9b78b73bwas moved Draft→Ready at 2026-09-13T11:03:55Z after source repair and descendant convergence had settled. A fresh actions inventory immediately after the lifecycle transition still contained only the three pre-existing repository Tests identities (34752865986failure/zero jobs,34752892232cancelled,34752900076skipped); no new Security/SAST/CodeQL/model-review or repository Tests identity materialized for the Ready event. #859 was therefore returned to Draft rather than manufacturing a no-op head move. This reinforces the existing acceptance: unchanged-headready_for_reviewmust deterministically reconcile required workflow identities without requiring a contentless commit or repeated lifecycle toggle.seonghobae commentedon Sep 13, 2026
Fresh consumer canary from
ContextualWisdomLab/LineageWeave#1079on exact product-only head34ef53d653cd399b7ab329261e357f6112623063.The PR moved Draft → Ready once at 2026-09-13T23:46:55Z after its temporary source patcher had removed itself and the stale authorization test contracts were repaired. The Ready transition immediately materialized repository Tests run
34790684671with Frontend job103814199309and Full-suite job103814199431, both bound to the unchanged exact head. At the same fresh observation, there was no new OpenCode or Noema workflow/check identity on that head and the Reviews API still had zero submissions. The earlier Draft-triggered central identities remainaction_required/zero-job and are not transferable Ready evidence.This is a useful partial-materialization canary: repository-local
ready_for_reviewadmission works, while the model-review identities owned here still have not materialized. Do not churn the LineageWeave head or repeat Draft/Ready solely to trigger them; re-read this unchanged consumer head after the owner repair/reconciliation path advances.seonghobae commentedon Sep 14, 2026
Fresh consumer canary: LineageWeave #1079 returned to Draft for a valid CodeRabbit finding, moved normally to repaired product-only head
e463aba8bf37d36ed0d6041a556c4d66fba90025, resolved that thread, then made one Ready transition on the unchanged head at 2026-09-14T00:52:40Z. Repository Tests run34794068177materialized, but exact-head check lookup currently returns 0opencode-reviewand 0noema-reviewidentities. No leaf no-op commit, repeated Ready/Draft cycling, or synthetic verdict will be used. Treat this head as an additional exact consumer canary for Ready-state review materialization/reconciliation.seonghobae commentedon Sep 14, 2026
LineageWeave #1079 canary legitimately advanced again for an acceptance-path defect (not review-trigger churn) to exact
a3c589d55d4745397664e90e437abea5728a856f, then made one Ready admission. Repository Tests now materialized all three current-head jobs, including the new real-stack authorization lane, but commit-filtered PR workflows still show no freshopencode-reviewornoema-reviewidentity. Treat predecessore463aba8...as obsolete and this exact head as the live consumer canary.There is also a useful negative evidence case on the same head: commit status
Devin Reviewissuccesswhile its own description saysFull review skipped: trial expired and no credits remaining. That status is explicitly non-substantive and must not satisfy any independent-review/admission heuristic. This does not make Devin canonical here; it reinforces #2045's existing rule that status-only/skip-success cannot replace an authenticated exact-headAPPROVEDorCHANGES_REQUESTEDReviews API verdict.seonghobae commentedon Sep 14, 2026
Fresh LineageWeave lifecycle canary, corrected after an immediate test-fixture contract repair:
ContextualWisdomLab/LineageWeave#1079@d7bc66c6cc21ac9046078b78369b9c388e7c8b7b, basemain@83eba56149eb802cd63642c507c324c9976ec78e.The earlier Ready sample
7c0df2db...is obsolete: static review found its new stale-summary fixture used a string wheresummary_contract_versionis integer, so the PR returned to Draft and moved by one causal test-only commit. #1079 was then marked Ready once on unchanged correctedd7bc66c6....Repository Tests rematerialized as
34804318535with three real exact-head queued jobs (103853037512,103853037588,103853037604), so the Ready transition itself is observed. Fresh exact-head review/check inventory still has no qualifying OpenCode/Noema/Strix identity or authenticated exact-head Reviews API verdict to inherit from predecessor heads.This remains the #2045 failure mode: Ready-state repository validation exists while model-review/reconciliation identities do not. Do not compensate in LineageWeave with another lifecycle flip, empty commit, synthetic status, provider/model override, or predecessor approval transfer. Owner acceptance remains fresh exact-head OpenCode/Noema review materialization and authenticated verdict on this unchanged substantive head.
seonghobae commentedon Sep 14, 2026
Fresh LineageWeave canary after a genuine source head move:
LineageWeave#1079@c2923950e73c88a9f9fd932332ddd47682da124bwas converted Draft for repair, then Ready once. Repository Tests34815479029materialized correctly. Central lifecycle checks also materialized (required-workflow-bootstrap,cancel-superseded-opencode-review-runs,admit-current-head, etc.), but the exact-head check inventory still has no substantiveopencode-review, Noema, or Strix review identity and Reviews API has no exact-head approval. This remains a valid #2045 consumer canary; do not compensate in the leaf with another lifecycle flip or no-op commit.seonghobae commentedon Oct 1, 2026
Orgmetra unchanged-head Ready review canaries — 2026-10-01
Three source-complete root PRs made one ordinary Draft → Ready transition after exact-head and thread revalidation:
Orgmetra#259@f1f152b0838e11cba1cf583706eb0983d56af373: reviews remain 0; threads 0.Orgmetra#448@6a06062e9d4f6e07bf4780a60384f264f7983353: reviews remain the two pre-existing COMMENTED submissions; threads 0.Orgmetra#100@301f843c01f301088234c27f758c2a074cfa9aed: reviews remain the 91 pre-existing COMMENTED submissions; all 65 threads resolved.Fresh post-transition reads show no new substantive authenticated review submission on any exact head. Product-owned Foundation and SAST are terminal GREEN, while Security remains fail-closed on the separately tracked Dependency Review 403 and fresh CodeQL identities also did not materialize. These are valid review-admission canaries, not merge-ready claims. No repeated Draft/Ready flip, no-op commit, manual rerun, provider/model override, synthetic status, or predecessor approval transfer was used.
seonghobae commentedon Oct 1, 2026
The live unchanged-head canaries now separate two defects. CodeQL's permanent Draft skip has a canonical owner repair at Draft .github#2548 exact head
8f6a870bca516d34a737bc8bd4abf5d3573573ae. OpenCode, Strix, and Noema are intentionally not made to review Draft PRs; their missing Ready materialization remains unresolved here. Orgmetra #235/#259/#448/#100 received no fresh authenticated substantive review after Ready. Ready remains review admission, and no synthetic approval/status or no-op rerun was used.seonghobae commentedon Oct 1, 2026
Fresh exact CodeQL canary — AppGuardrail #1327 (2026-10-01)
This reproduces the same Draft → Ready materialization gap for the central CodeQL required workflow and broadens this issue's owner evidence beyond model review jobs.
ContextualWisdomLab/appguardrail#1327cc08d337d986f46e8a89af4b42c958b877ea7ddc31e47e0e2d3854e11a5d38303515eb84492449333d1b3d851280c4266b19c94ad4b7a16769dcf7e5; compare is ahead by 1 with zero file delta36867096862, jobs110385195948/110385197916/110385235241, all skipped because the event snapshot was Draft110386630074/110386631416/110386632415, all skipped again because rerun preserves the original Draft event snapshotCentral protected authority at observation time is
ContextualWisdomLab/.github@37b10243cec3d160ecc9c1be75c71428b160a703. Its.github/workflows/codeql-pr.ymlexplicitly includespull_request.types: [opened, synchronize, reopened, ready_for_review, closed]and says Ready should rerun the same head, yet the organization required-workflow surface did not emit that event/run for this consumer. A leaf empty commit would manufacture asynchronizeevent and hide the lifecycle defect, so none was added.After preserving this evidence, the target PR was returned to Draft to avoid representing skipped CodeQL as merge readiness.
Acceptance extension: include CodeQL in the unchanged-head Draft → Ready fixture and prove that organization required workflows materialize a fresh run whose live event sees
draft=false; do not reuse or rerun a Draft-snapshot skipped run as Ready evidence. Refs #1929.Follow-up source-neutral head observations
The same AppGuardrail PR subsequently received two ordinary source-neutral Sentinel children without any file delta:
67b42a1a5c371f9b5776328f4a5ae830702bfc69: exact tree31e47e0e2d3854e11a5d38303515eb8449244933; all eight non-CodeQL workflows succeeded; CodeQL36868347072skipped.73cf780ffa680eb1e303310ba7a96553e872fa3c: ordinary child of67b42a1a…, the same exact tree, compare fromcc08d337…ahead 2 / behind 0 / zero changed files; all eight non-CodeQL workflows succeeded; CodeQL36873653133skipped.These source-neutral
synchronizeevents did not produce successful CodeQL analysis either. They are evidence of the same central admission defect, not justification for further empty commits or merge readiness.