You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
os-half-state-sweep — machine-findable marker for this generated view.
Generated view — not a second tracker. Authority lives on each card and PR (one-board rule); this body is rewritten IN PLACE by the scheduled patrol workflow (.github/workflows/half-state-patrol.yml) on every run, and the edit history is the archive. Report-only: every row is patrol input, never a gate verdict, and this sweep never fixes a state. Each predicate and the protocol clause it enforces are documented in scripts/pm/check-half-states.mjs.
The timestamp above is the patrol's own heartbeat: a Swept line that stops advancing means the standing caller died, which is the failure this anchor was created to make visible. Read it before you read the rows.
⚠️1 UNJUDGED row(s) in this sweep — an input this patrol could NOT read, not a state it read and found clean. They are sorted above the ordinary rows so the body's size trim can never be what removes them (#4690, #11218), and they are the rows to judge BY HAND: nothing in a later sweep will resolve them on its own.
check-half-states: swept 474 open pm-/p0-labeled issue(s), 585 open issue(s) in the unscoped pass (H13–H15, H18), 30 open PR(s) (merge state read on 4 of 4 H16 candidate(s)) and 1132 recently-merged PR(s) in objectstack-ai/objectstack — 269 half-state(s) found. H8's merged window is a TIME cap of 8 day(s), read in 12 page(s) (horizon reached: a delivery inside the window was seen, not merely the first N rows). H22 read 618 recently-closed issue(s) for pm:* state residue, COUNTED into the census line above and filed as no row at all (ruled 2026-08-31, 批 #13; folded #14072) (older closed carriers are outside the window by design). H22's closed-card window is a TIME cap of 3 day(s), read in 7 page(s) (boundary reached: paging ran past the horizon, not merely the first N rows). It is a CLOSURE horizon: rows are selected on closed_at, while paging is bounded by updated_at — the stream is consumed by closed-issue ACTIVITY (~188.3/day, measured 2026-08-31), not by closures (~11/day), which is why the page cap it replaced covered a ragged 2.1 days of update-recency rather than the closure window it read as. H23 read 575 squash commit message(s) from the default branch, carrying 27 closing-keyword binding(s) across 26 message(s). H23's commit window is a TIME cap of 3 day(s), read in 6 page(s) (boundary reached: paging ran past the horizon, not merely the first N rows). The open listings (H1–H18 inventory, H13 unscoped pass, open PRs) is an EXHAUSTIVE listing, read in 17 page(s) (complete: paging reached the end of the stream, so this IS the whole population). Hold comments read on 107 of 107 H17 candidate(s). Blocked-by: comment fallback read on 93 of 93 candidate(s). Restart-when: hold comments read on 58 of 58 H9 candidate(s). Blocker liveness (H19): targets resolved on 73 of 74 distinct Blocked-by: target(s) named by open pm:blocked card(s) — the 1 unresolved target(s) are named on their own cards' rows, and those rows sort ABOVE the size trim so they cannot be what a truncated body drops (#11218: this clause used to be an unconditional promise, and on the 2026-08-25T02:08Z sweep it was false — 199 rows were trimmed and not one rendered row carried an unresolved target). Cross-repo reachability was measured directly on 1 sibling repo(s), of which 1 do(es) not answer this credential — those targets are unjudgeable by ruling (each install reads its own repo with its own repo-scoped token) and ⛔ no re-run resolves them. Dispatch liveness (H20 + H27): remote branch read on 13 of 13 distinct claimed branch(es) named by open pm:dispatched card(s) past the 60-minute threshold — one read serving both rows, so H27's 24h population is a subset of this one and costs no request of its own. Seat liveness (H32): marker thread read on 6 of 6 HELD seat post(s) whose lane is countable on THIS board — a seat held for a sibling repo's lane is out of scope here (its inventory is unreadable from this sweep, so an empty-looking queue would mean nothing), and an unread thread makes H32 decline to judge that seat rather than accuse it. Gate-removal patrol (H35): 0 removal(s) of a gate-semantic label read from 0 page(s) of the repo-wide issue-event stream over the last 12h — no per-card timeline fetch. 0 of them are UNJUDGEABLE (a gate that only ever had ONE carrier leaves 「双载体同笔清标」 no evidence in either direction, so neither H31 nor H35 can say cleared-or-stripped). Shared-file holds (H36): changed-file page read on 29 of 29 open PR(s) — a pair needs both sides read, so a shortfall can only MISS a hold, never invent one. Governed review requests (H43): 8 of the open PR(s) whose changed-file page was read hit the governed register, and the submitted-review leg answered on 7 of 7 that the request/assignment union already left short (oldest-first, 25 per run). An unread review leg leaves its row standing on the two cheap fields and the row says so; a PR whose file page went unread is not judged by this item at all. Family folds (H37): 2 live shared branch(es) claimed by more than their own chain head, and a member comment page read on 199 of 199 open pm:queue card(s) — that second read is bought ONLY when a fold is live, so 0 of 0 is a board with no fold in flight rather than a pass that skipped one, and an unread member can only MISS a drifted write, never invent one. Dangling references (H40): 363 of 400 attempted resolution(s) answered, over 6092 distinct # reference(s) read off the LIVE board — 616 open card(s)/PR(s) and 456 already-cached comment thread(s), so comment coverage is the gated subset rather than the whole board, and merged/closed archive is out of the corpus by design. 1536 number(s) were answered free from listings already in hand, and 4156 were NOT ATTEMPTED at the 400-resolution budget (newest-first; this pass reached down to #12598) — not attempted is not clean. 37 do(es) not resolve and 0 could not be judged — ⛔ only HTTP 404 is read as unresolvable, a CLOSED card resolves normally and is never a finding, and no cause is asserted for any of them. Suppressed content is invisible, so every count here is a LOWER BOUND. Untimestamped readings (H44): 2260 comment(s) across 456 thread(s) ALREADY in hand were read for the five artefact shapes, and the seat leg widened the fetch to 11 of 11 HELD seat post(s) — every held seat, whatever its lane spelling, which is wider than H32's own population and deliberately so. ⛔ A verdict posted on a PULL REQUEST is NOT in this corpus: no listing here fetches a PR comment page, so this row's silence about PRs is an unread surface and never a clean one, and every count above is a LOWER BOUND. Claim-less implementations (H46): 28 of 28 bound card thread(s) were read for a Claim: naming the PR's head branch. A bound number this sweep cannot see as an OPEN card — closed, a PR, or beyond the listing ceiling — is UNJUDGED rather than clean, so this count is a LOWER BOUND. Epic parent reads (H45): 5 of 5 open pm:epic card(s) had their sub-issues parent read answered — a 404 No parent issue found IS an answer here, because parentless is what it means. That index is enumerated as its own population and kept OUT of the label pages every other row is judged over (SEEN_LABEL_PAGES), so this row buys one page plus one read per carrier and moves no other row's input. A carrier whose parent read did not answer is UNJUDGED rather than clean. Report-only: findings are patrol input, not a gate verdict.
Findings
H19#15214 — pm:blocked and 1 of 3 Blocked-by: target(s) could NOT be resolved this sweep (objectstack-ai/cloud#1979 (HTTP 404; objectstack-ai/cloud is NOT readable to this sweep's credential)) — so whether this block has outlived its blocker is UNJUDGED, not confirmed. Unread is not still-open (check:react-declaration-parity 是唯一没接进任何 workflow 的源码审计门禁,且无 MANIFEST 时静默 skip 退出 0 —— 它现在永远不可能红 #4690): a target dropped in silence reads as a healthy block forever, which is the exact failure this item exists to end, so it is named here instead. ⚠️ UNJUDGED is not a quiet row and must not be skimmed as one: this card's block is exactly as unverified as if nothing had been read at all. ⚠️ 1 of them are unjudgeable for a reason that has NOTHING to do with this card: the repo itself does not answer this sweep's credential (measured directly, by a separate GET /repos/<owner>/<name> — not inferred from the issue 404). That is the cross-repo class the contract-first split manufactures, and it is a standing, ACCEPTED limit rather than a defect to chase: each patrol install reads its own repo with its own repo-scoped token by ruling, so no re-run and no re-read of this card will ever resolve these. ⛔ Do not "fix" it on the card — judge the target BY HAND, or take a credential change to routing/security, whose call it is. The card's other 2 target(s) did resolve, and are still open. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-hold row, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned to pm:queue still carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind — ⚠️ agent identity only, a HUMAN assignment is ⛔ never cleared by an agent.
H31#14147 — needs:contract-review on the CARD while its delivering open PR docs(skills): readonly is stripped from any non-system write, not only an UPDATE payload #15382 (draft) does NOT carry it — the two carriers of one gate disagree, so the pair was written half way: either the hang never reached the PR side (「PR 一存在即挂」, and the PR exists), or a PASS cleared the PR side and stopped there, leaving the card gated behind a review that has already passed. The gate is a DUAL carrier — 「两边都挂好」, hung in one stroke and cleared in one stroke, each carrier written read-modify-write with a READ-BACK (「闸门被剥不是红灯是放行」: a stripped gate is a GREEN light, and 「被剥」 and 「从未挂过」 are indistinguishable in the evidence, so the read-back is the only way either is ever noticed). Report-only: ⛔ never a label written from this script — hanging or clearing a review gate from a sweeper would be issuing the verdict, which is 自查放行.
H31#14519 — needs:contract-review on the delivering open PR feat(spec)!: duration-shaped number keys carry their unit in the key name — no-baseline gate + seven ADR-0087 renames (timeoutMs, ttlSeconds/ttlMs, *TimeoutSeconds) #15626 (draft) while the CARD does NOT carry it — the more dangerous half of the same split: to the enqueue path an ungated card is a card that was never gated, so the review chain this PR is still waiting on is invisible to the queue, and the card can be enqueued straight past a gate that is demonstrably still live one carrier over. The gate is a DUAL carrier — 「两边都挂好」, hung in one stroke and cleared in one stroke, each carrier written read-modify-write with a READ-BACK (「闸门被剥不是红灯是放行」: a stripped gate is a GREEN light, and 「被剥」 and 「从未挂过」 are indistinguishable in the evidence, so the read-back is the only way either is ever noticed). Report-only: ⛔ never a label written from this script — hanging or clearing a review gate from a sweeper would be issuing the verdict, which is 自查放行.
H31#15072 — needs:contract-review on the delivering open PR feat(plugin-sharing): expand the field sharing recipient per matched record — the services half of the #14103 ruling #15235 (draft) while the CARD does NOT carry it — the more dangerous half of the same split: to the enqueue path an ungated card is a card that was never gated, so the review chain this PR is still waiting on is invisible to the queue, and the card can be enqueued straight past a gate that is demonstrably still live one carrier over. The gate is a DUAL carrier — 「两边都挂好」, hung in one stroke and cleared in one stroke, each carrier written read-modify-write with a READ-BACK (「闸门被剥不是红灯是放行」: a stripped gate is a GREEN light, and 「被剥」 and 「从未挂过」 are indistinguishable in the evidence, so the read-back is the only way either is ever noticed). Report-only: ⛔ never a label written from this script — hanging or clearing a review gate from a sweeper would be issuing the verdict, which is 自查放行.
H35#15325 — needs:contract-review was REMOVED from this CARD by os-litant at 2026-09-05T03:51:30Z in a LONE stroke, while the hang it clears was written across BOTH carriers — so the pair was cleared half way. 「PASS 双载体同笔清标」 makes a legitimate clear two removals seconds apart, one per carrier; this one has no sibling within 120s. Either the clear never reached the second carrier, or the label was stripped — and 「闸门被剥不是红灯是放行」, so the failure direction is TOWARD release: an ungated carrier reads to the enqueue path as one that was never gated. Remedy is a READ, not a write: check the card thread for a current review verdict before re-hanging — 「PASS 评论 + 标签缺失 + PR head 自复审后未动 = 已复审清标,不是被剥」. Report-only: ⛔ never a label written from this script — re-hanging a review gate from a sweeper would be issuing the verdict, which is 自查放行. Detection only; escalation and enforcement are a later card by the 2026-08-25 ruling.
H35#15578 — needs:contract-review was REMOVED from this CARD by os-litant at 2026-09-05T03:50:15Z in a LONE stroke, while the hang it clears was written across BOTH carriers — so the pair was cleared half way. 「PASS 双载体同笔清标」 makes a legitimate clear two removals seconds apart, one per carrier; this one has no sibling within 120s. Either the clear never reached the second carrier, or the label was stripped — and 「闸门被剥不是红灯是放行」, so the failure direction is TOWARD release: an ungated carrier reads to the enqueue path as one that was never gated. Remedy is a READ, not a write: check the card thread for a current review verdict before re-hanging — 「PASS 评论 + 标签缺失 + PR head 自复审后未动 = 已复审清标,不是被剥」. Report-only: ⛔ never a label written from this script — re-hanging a review gate from a sweeper would be issuing the verdict, which is 自查放行. Detection only; escalation and enforcement are a later card by the 2026-08-25 ruling.
H38#6367 — pm:seat post is STALE — its lane domain:engine carries a Claim: on [finding] The ruling's own offset shape completed_at <= due_date + duty.grace_days is refused on SQL push-down — a cross-field reference (and its addDays offset) may not name a relation column, so the duly dataset needs grace_days on the task or a join-aware push-down ruling #15103 written 19.6h AFTER this post's last event (claim 2026-09-05T07:41:31.000Z, post 2026-09-04T12:07:54.000Z). A shift dispatched work and did not record it, so every number the post states — 在飞 / 队列 / 决策箱 / the round number — describes a round that has since moved on, while updated_at makes the post read as SETTLED rather than as stale. ⚠️ This is the measured shape: one seat ran ~31h to wave 4 and dispatched five cards under a title still claiming the previous round. ⛔ Not an accusation of carelessness — the same post already carried this exact lesson in its own ledger, written one shift earlier, and the next shift reproduced it; that is the evidence prose does not hold here, not evidence about any seat. Remedy: refresh the seat post (or post a round marker) so the successor reading it sees the round that is actually running. Report-only: ⛔ this row never writes a label, a title or a marker.
H19#11331 — pm:blocked while 3 of 4 Blocked-by: target(s) — read from body OR comment — are CLOSED (#12400 (closed 2026-08-29T15:16:12Z), #12456 (closed 2026-08-26T03:58:22Z), #13464 (closed 2026-08-31T01:10:40Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. 1 target(s) are still open (#13563), so this is a PARTIAL discharge and the card may still be legitimately blocked — the row reports it, it does not decide it. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-hold row, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned to pm:queue still carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind — ⚠️ agent identity only, a HUMAN assignment is ⛔ never cleared by an agent.
H26#11331 — pm:blocked on 1 target(s) that can never CLOSE: #13563 (needs-user-decision). The unlock predicate is "the Blocked-by: target closed", and pm:on-hold / needs-user-decision are by definition states a card sits in WHILE OPEN — so this block has NO MECHANISM THAT WILL EVER RELEASE IT. Every existing check passes on this card (the line is present, the target resolves, the target is open, the label is correct), which is why the measured instances were found by a human reading and by no gauge; H9 asks the mirror question about the HELD card and nothing asked about the WAITING one. ⚠️ Not a claim that the block is wrong — waiting on a deferred card is sometimes exactly right. It says the wait is indefinite BY CONSTRUCTION, so the release has to come from the target's own state changing (a ruling answered, a hold restarted) and someone has to want that.
H19#11333 — pm:blocked while 2 of 4 Blocked-by: target(s) — read from body OR comment — are CLOSED (#12400 (closed 2026-08-29T15:16:12Z), #12456 (closed 2026-08-26T03:58:22Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. 2 target(s) are still open (#13457, #13458), so this is a PARTIAL discharge and the card may still be legitimately blocked — the row reports it, it does not decide it. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-hold row, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned to pm:queue still carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind — ⚠️ agent identity only, a HUMAN assignment is ⛔ never cleared by an agent.
H26#11333 — The wait is TRANSITIVE: #13457, #13458 are itself pm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.
H26#11753 — The wait is TRANSITIVE: objectstack-ai/objectui#7611 is itself pm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.
H4#11809 — pm:blocked with a Blocked-by: line in NEITHER channel — not in the body, and not in any comment on the thread (both were read). Either channel discharges the duty: seats park the line in a comment on purpose, because rewriting a body through the MCP escaping hazard ([finding] GitHub MCP issue reads return HTML-escaped bodies, so any seat that appends a line by rewriting a card body may store ' literals into its code blocks #8813) is the riskier write. So this is not a formatting nit — no machine reader anywhere knows what this card is waiting for. The unlock sweep greps this literal line, so without it in SOME channel nothing can ever return this card to the queue — the block outlives its blocker in silence.
H19#11925 — pm:blocked while 2 of 4 Blocked-by: target(s) — read from body OR comment — are CLOSED (#12037 (closed 2026-08-26T01:52:11Z), #12038 (closed 2026-08-28T05:57:39Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. 2 target(s) are still open (#12034, #12036), so this is a PARTIAL discharge and the card may still be legitimately blocked — the row reports it, it does not decide it. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-hold row, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned to pm:queue still carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind — ⚠️ agent identity only, a HUMAN assignment is ⛔ never cleared by an agent.
H26#11925 — The wait is TRANSITIVE: #12036 is itself pm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.
H26#11975 — pm:blocked on 1 target(s) that can never CLOSE: #13515 (pm:on-hold). The unlock predicate is "the Blocked-by: target closed", and pm:on-hold / needs-user-decision are by definition states a card sits in WHILE OPEN — so this block has NO MECHANISM THAT WILL EVER RELEASE IT. Every existing check passes on this card (the line is present, the target resolves, the target is open, the label is correct), which is why the measured instances were found by a human reading and by no gauge; H9 asks the mirror question about the HELD card and nothing asked about the WAITING one. ⚠️ Not a claim that the block is wrong — waiting on a deferred card is sometimes exactly right. It says the wait is indefinite BY CONSTRUCTION, so the release has to come from the target's own state changing (a ruling answered, a hold restarted) and someone has to want that.
H26#11978 — The wait is TRANSITIVE: #11975 is itself pm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.
H26#11979 — The wait is TRANSITIVE: #11978 is itself pm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.
H19#12036 — pm:blocked while 1 of 1 Blocked-by: target(s) — read from body OR comment — is CLOSED (#12412 (closed 2026-09-03T04:52:57Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. Every target it names is closed: nothing this card declared a wait on is still running. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-hold row, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned to pm:queue still carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind — ⚠️ agent identity only, a HUMAN assignment is ⛔ never cleared by an agent.
H19#12211 — pm:blocked while 1 of 1 Blocked-by: target(s) — read from body OR comment — is CLOSED (#12343 (closed 2026-09-02T14:19:35Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. Every target it names is closed: nothing this card declared a wait on is still running. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-hold row, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned to pm:queue still carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind — ⚠️ agent identity only, a HUMAN assignment is ⛔ never cleared by an agent.
H26#12753 — pm:blocked on 1 target(s) that can never CLOSE: #8901 (pm:on-hold). The unlock predicate is "the Blocked-by: target closed", and pm:on-hold / needs-user-decision are by definition states a card sits in WHILE OPEN — so this block has NO MECHANISM THAT WILL EVER RELEASE IT. Every existing check passes on this card (the line is present, the target resolves, the target is open, the label is correct), which is why the measured instances were found by a human reading and by no gauge; H9 asks the mirror question about the HELD card and nothing asked about the WAITING one. ⚠️ Not a claim that the block is wrong — waiting on a deferred card is sometimes exactly right. It says the wait is indefinite BY CONSTRUCTION, so the release has to come from the target's own state changing (a ruling answered, a hold restarted) and someone has to want that.
H26#13457 — The wait is TRANSITIVE: #14034 is itself pm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.
H26#13458 — The wait is TRANSITIVE: #13457 is itself pm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.
H19#13504 — pm:blocked while 1 of 1 Blocked-by: target(s) — read from body OR comment — is CLOSED (#14539 (closed 2026-09-05T01:55:25Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. Every target it names is closed: nothing this card declared a wait on is still running. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-hold row, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned to pm:queue still carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind — ⚠️ agent identity only, a HUMAN assignment is ⛔ never cleared by an agent.
H19#13681 — pm:blocked while 2 of 2 Blocked-by: target(s) — read from body OR comment — are CLOSED (#14456 (closed 2026-09-05T00:43:05Z), #14394 (closed 2026-09-02T18:39:19Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. Every target it names is closed: nothing this card declared a wait on is still running. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-hold row, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned to pm:queue still carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind — ⚠️ agent identity only, a HUMAN assignment is ⛔ never cleared by an agent.
H19#14034 — pm:blocked while 1 of 1 Blocked-by: target(s) — read from body OR comment — is CLOSED (#14865 (closed 2026-09-03T17:59:30Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. Every target it names is closed: nothing this card declared a wait on is still running. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-hold row, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned to pm:queue still carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind — ⚠️ agent identity only, a HUMAN assignment is ⛔ never cleared by an agent.
H20#14312 — pm:dispatched with a complete claim comment naming claude/issue-14312-client-oauth-wire-shapes — and NO SUCH REMOTE REF EXISTS, ~1398 min after the claim was posted (threshold 60 min). Claiming and dispatching are two acts with a gap between them: the claim is an atom (assign + label swap in one write, the claim comment, a race re-read) and LAUNCHING the dev is a third act outside it, so a seat interrupted between the two leaves exactly this card — every field correct, every gauge reading "in progress", nobody working it. It is invisible from the card itself: only the absence of something elsewhere is wrong. The measured specimen sat 74 min before a patrol tick compared branch heads. ⚠️ This symptom is IDENTICAL to a dev agent that died (no branch, no PR, no report) and the remedies are OPPOSITE — a dead agent needs a probe, an undispatched claim needs a dispatch — so read the claiming seat's own action sequence before assuming either. ⛔ This row keys on NO REF AT ALL, never on "no PR yet": a dev inside a long build legitimately has a ref and no PR for over an hour. One reading to rule out first: if this card's delivery already MERGED, the branch is gone by design and the missing paired write is H8's, not this one. Report-only: the remedy is a DISPATCH or a withdrawn claim, ⛔ never a label written from this script — the same posture H14 holds for pm:blocking and H19 for a released block.
H26#14314 — The wait is TRANSITIVE: #14313 is itself pm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.
H26#14343 — The wait is TRANSITIVE: #14791 is itself pm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.
H20#14366 — pm:dispatched with a complete claim comment naming claude/issue-14366-normalize-config-consume-api-parse — and NO SUCH REMOTE REF EXISTS, ~1398 min after the claim was posted (threshold 60 min). Claiming and dispatching are two acts with a gap between them: the claim is an atom (assign + label swap in one write, the claim comment, a race re-read) and LAUNCHING the dev is a third act outside it, so a seat interrupted between the two leaves exactly this card — every field correct, every gauge reading "in progress", nobody working it. It is invisible from the card itself: only the absence of something elsewhere is wrong. The measured specimen sat 74 min before a patrol tick compared branch heads. ⚠️ This symptom is IDENTICAL to a dev agent that died (no branch, no PR, no report) and the remedies are OPPOSITE — a dead agent needs a probe, an undispatched claim needs a dispatch — so read the claiming seat's own action sequence before assuming either. ⛔ This row keys on NO REF AT ALL, never on "no PR yet": a dev inside a long build legitimately has a ref and no PR for over an hour. One reading to rule out first: if this card's delivery already MERGED, the branch is gone by design and the missing paired write is H8's, not this one. Report-only: the remedy is a DISPATCH or a withdrawn claim, ⛔ never a label written from this script — the same posture H14 holds for pm:blocking and H19 for a released block.
H20#14483 — pm:dispatched with a complete claim comment naming claude/issue-14483-automation-skill-wall-clock-and-hook-runas — and NO SUCH REMOTE REF EXISTS, ~306 min after the claim was posted (threshold 60 min). Claiming and dispatching are two acts with a gap between them: the claim is an atom (assign + label swap in one write, the claim comment, a race re-read) and LAUNCHING the dev is a third act outside it, so a seat interrupted between the two leaves exactly this card — every field correct, every gauge reading "in progress", nobody working it. It is invisible from the card itself: only the absence of something elsewhere is wrong. The measured specimen sat 74 min before a patrol tick compared branch heads. ⚠️ This symptom is IDENTICAL to a dev agent that died (no branch, no PR, no report) and the remedies are OPPOSITE — a dead agent needs a probe, an undispatched claim needs a dispatch — so read the claiming seat's own action sequence before assuming either. ⛔ This row keys on NO REF AT ALL, never on "no PR yet": a dev inside a long build legitimately has a ref and no PR for over an hour. One reading to rule out first: if this card's delivery already MERGED, the branch is gone by design and the missing paired write is H8's, not this one. Report-only: the remedy is a DISPATCH or a withdrawn claim, ⛔ never a label written from this script — the same posture H14 holds for pm:blocking and H19 for a released block.
H19#14490 — pm:blocked while 1 of 1 Blocked-by: target(s) — read from body OR comment — is CLOSED (objectstack-ai/objectui#7415 (closed 2026-09-03T05:03:08Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. Every target it names is closed: nothing this card declared a wait on is still running. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-hold row, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned to pm:queue still carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind — ⚠️ agent identity only, a HUMAN assignment is ⛔ never cleared by an agent.
H19#14501 — pm:blocked while 1 of 1 Blocked-by: target(s) — read from body OR comment — is CLOSED (#14766 (closed 2026-09-04T14:26:03Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. Every target it names is closed: nothing this card declared a wait on is still running. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-hold row, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned to pm:queue still carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind — ⚠️ agent identity only, a HUMAN assignment is ⛔ never cleared by an agent.
… 236 further row(s) omitted to fit GitHub's issue-body limit; the full list is in the workflow run log.
Family ledger — computed vs rendered, every row family (#13947)
What each row family COMPUTED this sweep, and how much of it reached the list above. rendered below computed means the body's size trim ate the difference; the full list is in the workflow run log. This table is RESERVED out of the render budget BEFORE the finding rows are laid out — the same reservation the H17 index, the H39 census and the H40 section hold — so the trim can never be what removes it. Rows above are ordered by the same band shown here (HALF_STATE_FAMILY_BAND), highest band first, so a row survives the trim on what it IS rather than on how many unrelated rows were laid out before it.
⚠️22 family(ies) had rows omitted by the body trim: H4 (1/4), H12 (0/3), H19 (11/24), H20 (3/5), H26 (12/22), H36 (0/13), H43 (0/5), H2 (0/27), H8 (0/8), H9 (0/12), H10 (0/2), H13 (0/3), +10 more in the table.
family
band
computed
rendered
H31
gate
3
3
H35
gate
2
2
H4
stall
4
1
H12
stall
3
0
H19
stall
24
11
H20
stall
5
3
H26
stall
22
12
H36
stall
13
0
H38
stall
1
1
H43
stall
5
0
H2
state
27
0
H8
state
8
0
H9
state
12
0
H10
state
2
0
H13
state
3
0
H21
state
1
0
H24
state
1
0
H30
state
6
0
H44
state
48
0
H46
state
15
0
H5
inventory
9
0
H6
inventory
11
0
H11
inventory
14
0
H14
inventory
29
0
H15
inventory
1
0
Computed 0 row(s) this sweep, and therefore absent from the table (15): H1, H3, H7, H16, H18, H23, H25, H27, H28, H29, H32, H33, H34, H37, H45. These families were EVALUATED and found nothing — they have no rows to omit. Every family that computed a row is IN the table with its count, whether or not the trim left any of that row family in the body above, so a family missing from the list of findings is never ambiguous between the two readings.
Dangling references (H40)
37 number(s) referred to by the live board do NOT resolve, and 0 could not be judged. ⛔ Report-only, and ⛔ no cause is asserted: a number can fail to resolve because it was deleted, transferred, or made unreachable, and this sweep cannot tell those apart — a reference that fails is a fact, everything after it is a question for a human. ⛔ Do not rewrite the referring text and do not close anything; if a number returns, the reference was always correct. 400 resolution(s) attempted of 6092 distinct # reference(s) read off 2876 live-board text(s) (616 open card(s)/PR(s) + 456 already-cached comment thread(s)); 1536 answered free from listings in hand, 4156 NOT ATTEMPTED at the 400-resolution budget (attempted down to #12598).
… 12 further number(s) omitted at the H40_ROW_CAP render budget; the full list is in the workflow run log.
On-hold trigger-file index (H17)
Before dispatching, intersect your dispatch's file surface against this list and NAME any card it hits in the dispatch brief. These are the trigger files open holds declare — the opportunistic-restart mechanism (maintainer-accepted 2026-08-11) whose intersection was measured at 0-for-19 while it lived only as a remembered protocol step (#10034). Report-only: a card here is a hold in good standing, never a finding. Extraction is deterministic — every path shown is a tracked file; anything unverifiable was dropped rather than guessed, so this list under-reports and never invents. (read on 107 of 107 open pm:on-hold card(s); 7625 tracked file(s) in the oracle.)
Closed-card pm:* residue (H39 census, informational): pm:dispatched 2145, pm:queue 857, pm:blocking 41, pm:blocked 21, pm:on-hold 14, pm:awaiting-maintainer 1, oldest closed 2026-08-02; 555 carrying both pm:queue and pm:dispatched. H22's 3-day closure window, read separately, holds 64 of 618 closed card(s) still carrying residue (pm:dispatched 53, pm:blocking 6, pm:queue 5, pm:blocked 1). Archive, not state — no cleanup is owed and none is planned (ruled 2026-08-31, 批 #13); readers scope pm:* queries to open cards, and that reason reaches a residue two hours old exactly as it reaches one from August, which is why the window above is counted here rather than filed as rows (#14072).
rate premise OK — observed ~141.9/day against pinned MEASURED_MERGES_PER_DAY = 137.5/day, measured 2026-08-23 (13d ago) (factor 1.03, band 2x).
os-half-state-sweep — machine-findable marker for this generated view.
Generated view — not a second tracker. Authority lives on each card and PR (one-board rule); this body is rewritten IN PLACE by the scheduled patrol workflow (
.github/workflows/half-state-patrol.yml) on every run, and the edit history is the archive. Report-only: every row is patrol input, never a gate verdict, and this sweep never fixes a state. Each predicate and the protocol clause it enforces are documented inscripts/pm/check-half-states.mjs.Swept 2026-09-05T07:45:52.886Z · run 33953235721 · commit
e52bb6a442421d8decff89ae2270e1c5f790624c· triggerscheduleThe timestamp above is the patrol's own heartbeat: a
Sweptline that stops advancing means the standing caller died, which is the failure this anchor was created to make visible. Read it before you read the rows.check-half-states: swept 474 open pm-/p0-labeled issue(s), 585 open issue(s) in the unscoped pass (H13–H15, H18), 30 open PR(s) (merge state read on 4 of 4 H16 candidate(s)) and 1132 recently-merged PR(s) in objectstack-ai/objectstack — 269 half-state(s) found. H8's merged window is a TIME cap of 8 day(s), read in 12 page(s) (horizon reached: a delivery inside the window was seen, not merely the first N rows). H22 read 618 recently-closed issue(s) for
pm:*state residue, COUNTED into the census line above and filed as no row at all (ruled 2026-08-31, 批 #13; folded #14072) (older closed carriers are outside the window by design). H22's closed-card window is a TIME cap of 3 day(s), read in 7 page(s) (boundary reached: paging ran past the horizon, not merely the first N rows). It is a CLOSURE horizon: rows are selected onclosed_at, while paging is bounded byupdated_at— the stream is consumed by closed-issue ACTIVITY (~188.3/day, measured 2026-08-31), not by closures (~11/day), which is why the page cap it replaced covered a ragged 2.1 days of update-recency rather than the closure window it read as. H23 read 575 squash commit message(s) from the default branch, carrying 27 closing-keyword binding(s) across 26 message(s). H23's commit window is a TIME cap of 3 day(s), read in 6 page(s) (boundary reached: paging ran past the horizon, not merely the first N rows). The open listings (H1–H18 inventory, H13 unscoped pass, open PRs) is an EXHAUSTIVE listing, read in 17 page(s) (complete: paging reached the end of the stream, so this IS the whole population). Hold comments read on 107 of 107 H17 candidate(s).Blocked-by:comment fallback read on 93 of 93 candidate(s).Restart-when:hold comments read on 58 of 58 H9 candidate(s). Blocker liveness (H19): targets resolved on 73 of 74 distinctBlocked-by:target(s) named by openpm:blockedcard(s) — the 1 unresolved target(s) are named on their own cards' rows, and those rows sort ABOVE the size trim so they cannot be what a truncated body drops (#11218: this clause used to be an unconditional promise, and on the 2026-08-25T02:08Z sweep it was false — 199 rows were trimmed and not one rendered row carried an unresolved target). Cross-repo reachability was measured directly on 1 sibling repo(s), of which 1 do(es) not answer this credential — those targets are unjudgeable by ruling (each install reads its own repo with its own repo-scoped token) and ⛔ no re-run resolves them. Dispatch liveness (H20 + H27): remote branch read on 13 of 13 distinct claimed branch(es) named by openpm:dispatchedcard(s) past the 60-minute threshold — one read serving both rows, so H27's 24h population is a subset of this one and costs no request of its own. Seat liveness (H32): marker thread read on 6 of 6 HELD seat post(s) whose lane is countable on THIS board — a seat held for a sibling repo's lane is out of scope here (its inventory is unreadable from this sweep, so an empty-looking queue would mean nothing), and an unread thread makes H32 decline to judge that seat rather than accuse it. Gate-removal patrol (H35): 0 removal(s) of a gate-semantic label read from 0 page(s) of the repo-wide issue-event stream over the last 12h — no per-card timeline fetch. 0 of them are UNJUDGEABLE (a gate that only ever had ONE carrier leaves 「双载体同笔清标」 no evidence in either direction, so neither H31 nor H35 can say cleared-or-stripped). Shared-file holds (H36): changed-file page read on 29 of 29 open PR(s) — a pair needs both sides read, so a shortfall can only MISS a hold, never invent one. Governed review requests (H43): 8 of the open PR(s) whose changed-file page was read hit the governed register, and the submitted-review leg answered on 7 of 7 that the request/assignment union already left short (oldest-first, 25 per run). An unread review leg leaves its row standing on the two cheap fields and the row says so; a PR whose file page went unread is not judged by this item at all. Family folds (H37): 2 live shared branch(es) claimed by more than their own chain head, and a member comment page read on 199 of 199 openpm:queuecard(s) — that second read is bought ONLY when a fold is live, so 0 of 0 is a board with no fold in flight rather than a pass that skipped one, and an unread member can only MISS a drifted write, never invent one. Dangling references (H40): 363 of 400 attempted resolution(s) answered, over 6092 distinct#reference(s) read off the LIVE board — 616 open card(s)/PR(s) and 456 already-cached comment thread(s), so comment coverage is the gated subset rather than the whole board, and merged/closed archive is out of the corpus by design. 1536 number(s) were answered free from listings already in hand, and 4156 were NOT ATTEMPTED at the 400-resolution budget (newest-first; this pass reached down to #12598) — not attempted is not clean. 37 do(es) not resolve and 0 could not be judged — ⛔ only HTTP 404 is read as unresolvable, a CLOSED card resolves normally and is never a finding, and no cause is asserted for any of them. Suppressed content is invisible, so every count here is a LOWER BOUND. Untimestamped readings (H44): 2260 comment(s) across 456 thread(s) ALREADY in hand were read for the five artefact shapes, and the seat leg widened the fetch to 11 of 11 HELD seat post(s) — every held seat, whatever its lane spelling, which is wider than H32's own population and deliberately so. ⛔ A verdict posted on a PULL REQUEST is NOT in this corpus: no listing here fetches a PR comment page, so this row's silence about PRs is an unread surface and never a clean one, and every count above is a LOWER BOUND. Claim-less implementations (H46): 28 of 28 bound card thread(s) were read for aClaim:naming the PR's head branch. A bound number this sweep cannot see as an OPEN card — closed, a PR, or beyond the listing ceiling — is UNJUDGED rather than clean, so this count is a LOWER BOUND. Epic parent reads (H45): 5 of 5 openpm:epiccard(s) had their sub-issues parent read answered — a 404No parent issue foundIS an answer here, because parentless is what it means. That index is enumerated as its own population and kept OUT of the label pages every other row is judged over (SEEN_LABEL_PAGES), so this row buys one page plus one read per carrier and moves no other row's input. A carrier whose parent read did not answer is UNJUDGED rather than clean. Report-only: findings are patrol input, not a gate verdict.Findings
pm:blockedand 1 of 3Blocked-by:target(s) could NOT be resolved this sweep (objectstack-ai/cloud#1979(HTTP 404;objectstack-ai/cloudis NOT readable to this sweep's credential)) — so whether this block has outlived its blocker is UNJUDGED, not confirmed. Unread is not still-open (check:react-declaration-parity 是唯一没接进任何 workflow 的源码审计门禁,且无 MANIFEST 时静默 skip 退出 0 —— 它现在永远不可能红 #4690): a target dropped in silence reads as a healthy block forever, which is the exact failure this item exists to end, so it is named here instead.GET /repos/<owner>/<name>— not inferred from the issue 404). That is the cross-repo class the contract-first split manufactures, and it is a standing, ACCEPTED limit rather than a defect to chase: each patrol install reads its own repo with its own repo-scoped token by ruling, so no re-run and no re-read of this card will ever resolve these. ⛔ Do not "fix" it on the card — judge the target BY HAND, or take a credential change to routing/security, whose call it is. The card's other 2 target(s) did resolve, and are still open. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-holdrow, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned topm:queuestill carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind —needs:contract-reviewon the CARD while its delivering open PR docs(skills):readonlyis stripped from any non-system write, not only an UPDATE payload #15382 (draft) does NOT carry it — the two carriers of one gate disagree, so the pair was written half way: either the hang never reached the PR side (「PR 一存在即挂」, and the PR exists), or a PASS cleared the PR side and stopped there, leaving the card gated behind a review that has already passed. The gate is a DUAL carrier — 「两边都挂好」, hung in one stroke and cleared in one stroke, each carrier written read-modify-write with a READ-BACK (「闸门被剥不是红灯是放行」: a stripped gate is a GREEN light, and 「被剥」 and 「从未挂过」 are indistinguishable in the evidence, so the read-back is the only way either is ever noticed). Report-only: ⛔ never a label written from this script — hanging or clearing a review gate from a sweeper would be issuing the verdict, which is 自查放行.needs:contract-reviewon the delivering open PR feat(spec)!: duration-shaped number keys carry their unit in the key name — no-baseline gate + seven ADR-0087 renames (timeoutMs, ttlSeconds/ttlMs, *TimeoutSeconds) #15626 (draft) while the CARD does NOT carry it — the more dangerous half of the same split: to the enqueue path an ungated card is a card that was never gated, so the review chain this PR is still waiting on is invisible to the queue, and the card can be enqueued straight past a gate that is demonstrably still live one carrier over. The gate is a DUAL carrier — 「两边都挂好」, hung in one stroke and cleared in one stroke, each carrier written read-modify-write with a READ-BACK (「闸门被剥不是红灯是放行」: a stripped gate is a GREEN light, and 「被剥」 and 「从未挂过」 are indistinguishable in the evidence, so the read-back is the only way either is ever noticed). Report-only: ⛔ never a label written from this script — hanging or clearing a review gate from a sweeper would be issuing the verdict, which is 自查放行.needs:contract-reviewon the delivering open PR feat(plugin-sharing): expand thefieldsharing recipient per matched record — the services half of the #14103 ruling #15235 (draft) while the CARD does NOT carry it — the more dangerous half of the same split: to the enqueue path an ungated card is a card that was never gated, so the review chain this PR is still waiting on is invisible to the queue, and the card can be enqueued straight past a gate that is demonstrably still live one carrier over. The gate is a DUAL carrier — 「两边都挂好」, hung in one stroke and cleared in one stroke, each carrier written read-modify-write with a READ-BACK (「闸门被剥不是红灯是放行」: a stripped gate is a GREEN light, and 「被剥」 and 「从未挂过」 are indistinguishable in the evidence, so the read-back is the only way either is ever noticed). Report-only: ⛔ never a label written from this script — hanging or clearing a review gate from a sweeper would be issuing the verdict, which is 自查放行.needs:contract-reviewwas REMOVED from this CARD byos-litantat 2026-09-05T03:51:30Z in a LONE stroke, while the hang it clears was written across BOTH carriers — so the pair was cleared half way. 「PASS 双载体同笔清标」 makes a legitimate clear two removals seconds apart, one per carrier; this one has no sibling within 120s. Either the clear never reached the second carrier, or the label was stripped — and 「闸门被剥不是红灯是放行」, so the failure direction is TOWARD release: an ungated carrier reads to the enqueue path as one that was never gated. Remedy is a READ, not a write: check the card thread for a current review verdict before re-hanging — 「PASS 评论 + 标签缺失 + PR head 自复审后未动 = 已复审清标,不是被剥」. Report-only: ⛔ never a label written from this script — re-hanging a review gate from a sweeper would be issuing the verdict, which is 自查放行. Detection only; escalation and enforcement are a later card by the 2026-08-25 ruling.needs:contract-reviewwas REMOVED from this CARD byos-litantat 2026-09-05T03:50:15Z in a LONE stroke, while the hang it clears was written across BOTH carriers — so the pair was cleared half way. 「PASS 双载体同笔清标」 makes a legitimate clear two removals seconds apart, one per carrier; this one has no sibling within 120s. Either the clear never reached the second carrier, or the label was stripped — and 「闸门被剥不是红灯是放行」, so the failure direction is TOWARD release: an ungated carrier reads to the enqueue path as one that was never gated. Remedy is a READ, not a write: check the card thread for a current review verdict before re-hanging — 「PASS 评论 + 标签缺失 + PR head 自复审后未动 = 已复审清标,不是被剥」. Report-only: ⛔ never a label written from this script — re-hanging a review gate from a sweeper would be issuing the verdict, which is 自查放行. Detection only; escalation and enforcement are a later card by the 2026-08-25 ruling.pm:seatpost is STALE — its lanedomain:enginecarries aClaim:on [finding] The ruling's own offset shapecompleted_at <= due_date + duty.grace_daysis refused on SQL push-down — a cross-field reference (and itsaddDaysoffset) may not name a relation column, so thedulydataset needsgrace_dayson the task or a join-aware push-down ruling #15103 written 19.6h AFTER this post's last event (claim 2026-09-05T07:41:31.000Z, post 2026-09-04T12:07:54.000Z). A shift dispatched work and did not record it, so every number the post states — 在飞 / 队列 / 决策箱 / the round number — describes a round that has since moved on, whileupdated_atmakes the post read as SETTLED rather than as stale.pm:blockedwhile 3 of 4Blocked-by:target(s) — read from body OR comment — are CLOSED (#12400(closed 2026-08-29T15:16:12Z),#12456(closed 2026-08-26T03:58:22Z),#13464(closed 2026-08-31T01:10:40Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. 1 target(s) are still open (#13563), so this is a PARTIAL discharge and the card may still be legitimately blocked — the row reports it, it does not decide it. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-holdrow, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned topm:queuestill carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind —pm:blockedon 1 target(s) that can never CLOSE:#13563(needs-user-decision). The unlock predicate is "theBlocked-by:target closed", andpm:on-hold/needs-user-decisionare by definition states a card sits in WHILE OPEN — so this block has NO MECHANISM THAT WILL EVER RELEASE IT. Every existing check passes on this card (the line is present, the target resolves, the target is open, the label is correct), which is why the measured instances were found by a human reading and by no gauge; H9 asks the mirror question about the HELD card and nothing asked about the WAITING one.pm:blockedwhile 2 of 4Blocked-by:target(s) — read from body OR comment — are CLOSED (#12400(closed 2026-08-29T15:16:12Z),#12456(closed 2026-08-26T03:58:22Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. 2 target(s) are still open (#13457,#13458), so this is a PARTIAL discharge and the card may still be legitimately blocked — the row reports it, it does not decide it. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-holdrow, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned topm:queuestill carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind —#13457,#13458are itselfpm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.objectstack-ai/objectui#7611is itselfpm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.pm:blockedwith aBlocked-by:line in NEITHER channel — not in the body, and not in any comment on the thread (both were read). Either channel discharges the duty: seats park the line in a comment on purpose, because rewriting a body through the MCP escaping hazard ([finding] GitHub MCP issue reads return HTML-escaped bodies, so any seat that appends a line by rewriting a card body may store'literals into its code blocks #8813) is the riskier write. So this is not a formatting nit — no machine reader anywhere knows what this card is waiting for. The unlock sweep greps this literal line, so without it in SOME channel nothing can ever return this card to the queue — the block outlives its blocker in silence.pm:blockedwhile 2 of 4Blocked-by:target(s) — read from body OR comment — are CLOSED (#12037(closed 2026-08-26T01:52:11Z),#12038(closed 2026-08-28T05:57:39Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. 2 target(s) are still open (#12034,#12036), so this is a PARTIAL discharge and the card may still be legitimately blocked — the row reports it, it does not decide it. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-holdrow, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned topm:queuestill carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind —#12036is itselfpm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.pm:blockedon 1 target(s) that can never CLOSE:#13515(pm:on-hold). The unlock predicate is "theBlocked-by:target closed", andpm:on-hold/needs-user-decisionare by definition states a card sits in WHILE OPEN — so this block has NO MECHANISM THAT WILL EVER RELEASE IT. Every existing check passes on this card (the line is present, the target resolves, the target is open, the label is correct), which is why the measured instances were found by a human reading and by no gauge; H9 asks the mirror question about the HELD card and nothing asked about the WAITING one.#11975is itselfpm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.#11978is itselfpm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.pm:blockedwhile 1 of 1Blocked-by:target(s) — read from body OR comment — is CLOSED (#12412(closed 2026-09-03T04:52:57Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. Every target it names is closed: nothing this card declared a wait on is still running. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-holdrow, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned topm:queuestill carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind —pm:blockedwhile 1 of 1Blocked-by:target(s) — read from body OR comment — is CLOSED (#12343(closed 2026-09-02T14:19:35Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. Every target it names is closed: nothing this card declared a wait on is still running. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-holdrow, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned topm:queuestill carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind —pm:blockedon 1 target(s) that can never CLOSE:#8901(pm:on-hold). The unlock predicate is "theBlocked-by:target closed", andpm:on-hold/needs-user-decisionare by definition states a card sits in WHILE OPEN — so this block has NO MECHANISM THAT WILL EVER RELEASE IT. Every existing check passes on this card (the line is present, the target resolves, the target is open, the label is correct), which is why the measured instances were found by a human reading and by no gauge; H9 asks the mirror question about the HELD card and nothing asked about the WAITING one.#14034is itselfpm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.#13457is itselfpm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.pm:blockedwhile 1 of 1Blocked-by:target(s) — read from body OR comment — is CLOSED (#14539(closed 2026-09-05T01:55:25Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. Every target it names is closed: nothing this card declared a wait on is still running. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-holdrow, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned topm:queuestill carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind —pm:blockedwhile 2 of 2Blocked-by:target(s) — read from body OR comment — are CLOSED (#14456(closed 2026-09-05T00:43:05Z),#14394(closed 2026-09-02T18:39:19Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. Every target it names is closed: nothing this card declared a wait on is still running. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-holdrow, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned topm:queuestill carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind —pm:blockedwhile 1 of 1Blocked-by:target(s) — read from body OR comment — is CLOSED (#14865(closed 2026-09-03T17:59:30Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. Every target it names is closed: nothing this card declared a wait on is still running. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-holdrow, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned topm:queuestill carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind —pm:dispatchedwith a complete claim comment namingclaude/issue-14312-client-oauth-wire-shapes— and NO SUCH REMOTE REF EXISTS, ~1398 min after the claim was posted (threshold 60 min). Claiming and dispatching are two acts with a gap between them: the claim is an atom (assign + label swap in one write, the claim comment, a race re-read) and LAUNCHING the dev is a third act outside it, so a seat interrupted between the two leaves exactly this card — every field correct, every gauge reading "in progress", nobody working it. It is invisible from the card itself: only the absence of something elsewhere is wrong. The measured specimen sat 74 min before a patrol tick compared branch heads.pm:blockingand H19 for a released block.#14313is itselfpm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.#14791is itselfpm:blocked, so this card is waiting on a card that is waiting. A single-level predicate cannot see past one hop, and the measured chain was real one level up and FALSE two levels up (the target was an H19 finding on the same sweep — both of ITS blockers had closed). This row does not chase the chain; it says to look one level further.pm:dispatchedwith a complete claim comment namingclaude/issue-14366-normalize-config-consume-api-parse— and NO SUCH REMOTE REF EXISTS, ~1398 min after the claim was posted (threshold 60 min). Claiming and dispatching are two acts with a gap between them: the claim is an atom (assign + label swap in one write, the claim comment, a race re-read) and LAUNCHING the dev is a third act outside it, so a seat interrupted between the two leaves exactly this card — every field correct, every gauge reading "in progress", nobody working it. It is invisible from the card itself: only the absence of something elsewhere is wrong. The measured specimen sat 74 min before a patrol tick compared branch heads.pm:blockingand H19 for a released block.pm:dispatchedwith a complete claim comment namingclaude/issue-14483-automation-skill-wall-clock-and-hook-runas— and NO SUCH REMOTE REF EXISTS, ~306 min after the claim was posted (threshold 60 min). Claiming and dispatching are two acts with a gap between them: the claim is an atom (assign + label swap in one write, the claim comment, a race re-read) and LAUNCHING the dev is a third act outside it, so a seat interrupted between the two leaves exactly this card — every field correct, every gauge reading "in progress", nobody working it. It is invisible from the card itself: only the absence of something elsewhere is wrong. The measured specimen sat 74 min before a patrol tick compared branch heads.pm:blockingand H19 for a released block.pm:blockedwhile 1 of 1Blocked-by:target(s) — read from body OR comment — is CLOSED (objectstack-ai/objectui#7415(closed 2026-09-03T05:03:08Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. Every target it names is closed: nothing this card declared a wait on is still running. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-holdrow, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned topm:queuestill carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind —pm:blockedwhile 1 of 1Blocked-by:target(s) — read from body OR comment — is CLOSED (#14766(closed 2026-09-04T14:26:03Z)): the block has outlived its blocker. Nothing else here asks this question — H4 asks whether the line EXISTS, H14 asks the REVERSE index — so an expired block sits with a well-formed line, a correct label and no row anywhere: one measured card sat ~4.5h past its blocker's close and was found only by a human walking the graph, another was released only by a manual triage pass. Every target it names is closed: nothing this card declared a wait on is still running. Report-only, and the release is NOT this script's to make: the state model gives it two mechanical double-checks (pm:blocked/pm:on-holdrow, 「放行双查」) — ① release only against the condition carried by the MOST RECENT conversion comment, never an earlier blocker on the thread (a condition already spent, re-fired, reinstates an expired premise as the current one), and ② refuse to release when the card carries a MERGED PR newer than that conversion comment (the card moved on after the condition was written, so the cited fact can be true and no longer current). This row surfaces the candidate; the unlock sweep releases it — ⛔ never a label written from this script. When that release does happen, its paired write includes 「同笔摘 assignee」: a card returned topm:queuestill carrying the assignee of the seat that parked it is dispatchable to the queue view and taken to the claim rule at the same time (H24), which is the state the unlock scan was measured leaving behind —Family ledger — computed vs rendered, every row family (#13947)
What each row family COMPUTED this sweep, and how much of it reached the list above.
renderedbelowcomputedmeans the body's size trim ate the difference; the full list is in the workflow run log. This table is RESERVED out of the render budget BEFORE the finding rows are laid out — the same reservation the H17 index, the H39 census and the H40 section hold — so the trim can never be what removes it. Rows above are ordered by the same band shown here (HALF_STATE_FAMILY_BAND), highest band first, so a row survives the trim on what it IS rather than on how many unrelated rows were laid out before it.H4(1/4),H12(0/3),H19(11/24),H20(3/5),H26(12/22),H36(0/13),H43(0/5),H2(0/27),H8(0/8),H9(0/12),H10(0/2),H13(0/3), +10 more in the table.H31H35H4H12H19H20H26H36H38H43H2H8H9H10H13H21H24H30H44H46H5H6H11H14H15Computed 0 row(s) this sweep, and therefore absent from the table (15):
H1,H3,H7,H16,H18,H23,H25,H27,H28,H29,H32,H33,H34,H37,H45. These families were EVALUATED and found nothing — they have no rows to omit. Every family that computed a row is IN the table with its count, whether or not the trim left any of that row family in the body above, so a family missing from the list of findings is never ambiguous between the two readings.Dangling references (H40)
37 number(s) referred to by the live board do NOT resolve, and 0 could not be judged. ⛔ Report-only, and ⛔ no cause is asserted: a number can fail to resolve because it was deleted, transferred, or made unreachable, and this sweep cannot tell those apart — a reference that fails is a fact, everything after it is a question for a human. ⛔ Do not rewrite the referring text and do not close anything; if a number returns, the reference was always correct. 400 resolution(s) attempted of 6092 distinct
#reference(s) read off 2876 live-board text(s) (616 open card(s)/PR(s) + 456 already-cached comment thread(s)); 1536 answered free from listings in hand, 4156 NOT ATTEMPTED at the 400-resolution budget (attempted down to #12598).pnpm check:harvest ofdispatch-gates.mjsoutput silently drops a third of the gate list #13462 — HTTP 404, does not resolve; referred to by #9857cleanup-package-permissions.tsasserts "no ghost grants" from a read that never answered #13422 — HTTP 404, does not resolve; referred to by #6021, #9857needs:contract-reviewstripped, with no review on either #13412 — HTTP 404, does not resolve; referred to by #9857, #13417, #13597needs:contract-reviewattaches to the CARD, but contract-review seats scan PRs — 2 measured instances of a parked PR that was invisible instead #13410 — HTTP 404, does not resolve; referred to by #9857, #13417isMissingTableErroris a cross-package contract whose home no plugin can reach — two plugin-auth audit writes stay silently dark because of it #13399 — HTTP 404, does not resolve; referred to by #6021, #6367, #9857warnwhere AGENTS.md puts it aterror— and the card that was supposed to carry the level is CLOSED #13398 — HTTP 404, does not resolve; referred to by #6021, #9857, #15603dispatch-gates --residueprints THREE fabricated leads for check:query-options-erasure — literals naming files that have never existed, unannotated because one live sibling keeps the family reachable #13312 — HTTP 404, does not resolve; referred to by #9857, #13326Restart-when:line, never the REACHABILITY of the target it names — a hold pointing at an issue that cannot fire passes forever (refused twice over; maintainer call) #13278 — HTTP 404, does not resolve; referred to by #9857, #13597scripts/**costs 11 unmeasured rows and still misses every live scanner there #13274 — HTTP 404, does not resolve; referred to by #9857.catch(() => undefined)把执行上下文解析失败静默降级为「无上下文」— 该行为在包管理门上可达什么错误状态,未测 #13255 — HTTP 404, does not resolve; referred to by #9857--self-testis wired into nocheck:*family, so its 32 assertions never run in CI #13246 — HTTP 404, does not resolve; referred to by #9857codehelperto the object-literal stamp position — the blast radius is now measured, and 4 undischargeableunresolvedfindings are the blocker #13233 — HTTP 404, does not resolve; referred to by #9857On-hold trigger-file index (H17)
Before dispatching, intersect your dispatch's file surface against this list and NAME any card it hits in the dispatch brief. These are the trigger files open holds declare — the opportunistic-restart mechanism (maintainer-accepted 2026-08-11) whose intersection was measured at 0-for-19 while it lived only as a remembered protocol step (#10034). Report-only: a card here is a hold in good standing, never a finding. Extraction is deterministic — every path shown is a tracked file; anything unverifiable was dropped rather than guessed, so this list under-reports and never invents. (read on 107 of 107 open
pm:on-holdcard(s); 7625 tracked file(s) in the oracle.)packages/spec/src/automation/webhook.zod.ts,packages/spec/src/integration/connector.zod.ts,packages/spec/src/kernel/metadata-plugin.zod.ts,packages/spec/src/kernel/metadata-type-schemas.ts,packages/spec/src/security/sharing.zod.tspackages/drivers/driver-sql/src/sql-driver.tspackages/plugins/plugin-sharing/src/sharing-service.tspackages/plugins/plugin-security/src/security-plugin.tspackages/core/src/security/auth-gate.ts,packages/runtime/src/http-dispatcher.tspackages/services/service-analytics/src/analytics-service.ts,packages/spec/src/data/currency-fraction-digits.ts,packages/spec/src/data/field.zod.tsdocs/PLATFORM_GAPS_FROM_TEMPLATES.md,packages/spec/src/ui/view.zod.tspackages/client/src/realtime-api.ts,packages/runtime/src/http-dispatcher.tspackages/drivers/driver-sql/src/sql-driver.tsscripts/check-durability-degradation-log-level.mjsscripts/check-durability-degradation-log-level.mjscontent/docs/deployment/meta.json,content/docs/meta.jsonpackages/lint/src/data-model-rules.ts,packages/lint/src/validate-security-posture.test.tsscripts/check-cross-package-test-inputs.mjsexamples/app-todo/package.jsonscripts/check-cross-package-test-inputs.mjspackages/drivers/driver-sql/src/schema-drift.ts,packages/drivers/driver-sql/src/sql-driver.tsscripts/docs-audit/affected-docs.mjs,scripts/docs-audit/check-drift-comment.mjsscripts/pm/os-verify-lock.shscripts/durability-read-invention.baseline.jsonpackages/objectql/src/registry.tsscripts/pm/dispatch-gates.mjsscripts/check-type-check-coverage.mjsscripts/check-cross-package-test-inputs.mjs,scripts/pm/dispatch-gates.mjspackages/services/service-storage/src/metadata-store.ts,packages/services/service-storage/src/storage-routes.tspackages/plugins/plugin-security/src/security-plugin.tspackages/metadata/src/loaders/database-loader.tspackages/drivers/driver-mongodb/src/mongodb-driver.tsscripts/objectui-changeset-digest.mjsClosed-card
pm:*residue (H39 census, informational): pm:dispatched 2145, pm:queue 857, pm:blocking 41, pm:blocked 21, pm:on-hold 14, pm:awaiting-maintainer 1, oldest closed 2026-08-02; 555 carrying bothpm:queueandpm:dispatched. H22's 3-day closure window, read separately, holds 64 of 618 closed card(s) still carrying residue (pm:dispatched 53, pm:blocking 6, pm:queue 5, pm:blocked 1). Archive, not state — no cleanup is owed and none is planned (ruled 2026-08-31, 批 #13); readers scopepm:*queries to open cards, and that reason reaches a residue two hours old exactly as it reaches one from August, which is why the window above is counted here rather than filed as rows (#14072).rate premise OK — observed ~141.9/day against pinned
MEASURED_MERGES_PER_DAY= 137.5/day, measured 2026-08-23 (13d ago) (factor 1.03, band 2x).