[Half-state patrol] check-half-states live sweep — generated view (please pin)

[os-warren]

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.

Swept 2026-09-10T19:46:50.675Z · run 34521869784 · commit cac62d5f9de14f1d332c0bdb3b3630bec62b6e39 · trigger schedule

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.

⚠️ 5 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 499 open pm-/p0-labeled issue(s), 581 open issue(s) in the unscoped pass (H13–H15, H18), 19 open PR(s) (merge state read on 1 of 1 H16 candidate(s)) and 1185 recently-merged PR(s) in objectstack-ai/objectstack — 316 half-state(s) found. H8's merged window is a TIME cap of 8 day(s), read in 13 page(s) (horizon reached: a delivery inside the window was seen, not merely the first N rows). H22 read 421 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), reaching back to 2026-09-07, read in 5 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 (~415.1/day, measured 2026-09-06), 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. ⚠️ RATE PREMISE DRIFTED — this sweep observed ~148.9 closed-issue updates/day against a pinned MEASURED_CLOSED_ISSUE_UPDATES_PER_DAY = 415.1/day, measured 2026-09-06 (5d ago): a factor of 0.36, outside the 2x band. H22's window states its reach in days by dividing by that constant, so the coverage this very line quotes is misdescribed by the same factor. ⛔ A sweep never overwrites the pin: it is re-pinned by hand, from a fresh measurement. Re-measure. H23 read 409 squash commit message(s) from the default branch, carrying 8 closing-keyword binding(s) across 7 message(s). H23's commit window is a TIME cap of 3 day(s), read in 5 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 18 page(s) (complete: paging reached the end of the stream, so this IS the whole population). Hold comments read on 100 of 100 H17 candidate(s). Blocked-by: comment fallback read on 85 of 85 candidate(s). Restart-when: hold comments read on 54 of 54 H9 candidate(s). Awaiting-maintainer entries (H55): 0 open pm:awaiting-maintainer card(s) last touched before 2026-09-10T00:00:00Z — COUNTED here and filed as no row (they entered before the Maintainer-action: line was owed; the bounded reclassification worklist is a separate act); 0 with no readable updated_at, judged rather than counted; Maintainer-action: threads read on 0 of 0 judged candidate(s). Blocker liveness (H19): targets resolved on 60 of 65 distinct Blocked-by: target(s) named by open pm:blocked card(s) — the 5 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 12 of 12 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 5 of 5 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 18 of 18 open PR(s) — a pair needs both sides read, so a shortfall can only MISS a hold, never invent one. Governed review requests (H43): 10 of the open PR(s) whose changed-file page was read hit the governed register, and the submitted-review leg answered on 3 of 3 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): 0 live shared branch(es) claimed by more than their own chain head, and a member comment page read on 0 of 0 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): 322 of 400 attempted resolution(s) answered, over 5899 distinct # reference(s) read off the LIVE board — 600 open card(s)/PR(s) and 217 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. 1237 number(s) were answered free from listings already in hand, and 4262 were NOT ATTEMPTED at the 400-resolution budget (newest-first; this pass reached down to #14564) — not attempted is not clean; 1 reference(s) name a number above the highest this sweep saw and were held out rather than resolved. 78 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): 1588 comment(s) across 216 thread(s) ALREADY in hand were read for the five artefact shapes, and the seat leg widened the fetch to 7 of 7 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. Estimated stamps (H56): 1588 of the comment(s) above carried a platform created_at to judge a typed stamp against, 0 did not and are UNJUDGED rather than clean, and 10 stamped line(s) carried more than one stamp and were held out rather than guessed at. Tolerance 15 min, measured against the whole created_at..updated_at window, so a stamp legitimately refreshed by a later EDIT never fires and a comment edited long after posting is judged against a wide window — a stated under-read, and the safe direction for a patrol reading somebody else's artefact. Claim-less implementations (H46): 15 of 15 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): 8 of 8 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. Release records (H47): 42 of 322 card(s) this row can speak about had a comment thread ALREADY in hand to judge. It fetches NOTHING of its own, so a card whose thread no other row bought is UNJUDGED rather than clean, and the no-assignee pm:queue leg is the thinnest half of that corpus — H2 buys a thread only for an ASSIGNED card. A card that was never claimed is clean and indistinguishable from an exit nobody recorded, so this count is a LOWER BOUND. Maintainer briefs (H48): 10 of 10 governed open PRs judged, one issue-comment thread bought per governed open PR (at most 5 page(s) of 100). This is a NEW fetch class rather than a second reader of one already in hand: commentCache holds CARD threads only. A thread that failed or reached that ceiling is UNJUDGED rather than short, a PR whose changed-file page went unread is not in this population at all, and a governed PR with NO **ACCEPT** verdict is CLEAN rather than quiet. Partial landings (H49): 26 of 26 open pm:dispatched + assigned card(s) had a comment thread in hand to judge against the merged window. It fetches NOTHING of its own — H2 buys that thread for exactly this population, so a shortfall is a thread H2 could not read, and such a card is UNJUDGED rather than clean. The PR side is the H8 merged window plus the open listing, so a Refs landing older than the window is invisible here. Thread-read fields (H50): 26 of 26 open pm:dispatched card(s) had a COMPLETE comment thread in hand to judge the newest Claim: against (0 still full at the page ceiling or failed mid-walk — UNJUDGED rather than clean, since the newest claim may sit on a page this row never saw); 0 extra comment page(s) bought completing full first pages. A claim stamped before the field landed is never a row. Open questions (H52): 208 of 499 listed open card(s) had a COMPLETE comment thread in hand to judge the newest os-dev-report against (3 carried a newest report whose JSON payload did not read — UNJUDGED rather than clean, since an unread payload has an UNKNOWN open_questions array). It fetches NOTHING of its own, so a shortfall is a thread no other row bought, or one still full at its first page, and such a card is UNJUDGED rather than clean. A CLOSED card is out of this population entirely, and the residual-question rule is what carries a question past its own card. Contract-review handoffs (H51): 2 of 2 gated open PR(s) had a readable issue-comment thread to judge the newest contract-review verdict against (at most 5 page(s) of 100, shared with H48's cache). A thread that failed or reached that ceiling is UNJUDGED rather than clean, and a verdict naming an OLDER head is CLEAN rather than quiet — the head moved, so the carrier is genuinely live again. Carriers without increment (H53): 3 of 3 gated open card(s) had a COMPLETE comment thread to judge for a Claim: (0 extra comment page(s) bought completing full first pages). It BUYS that thread rather than reading a cache: the population is unassigned by construction and H2 buys one only for an ASSIGNED card, so a cache-only reading would report this whole shape UNJUDGED while looking healthy. An incomplete or failed walk is UNJUDGED rather than clean, since a full page may hide the newest claim. The PR leg is the open listing plus H8's bounded merged window, so a landing older than that window is as invisible here as it is to H8. Report-only: findings are patrol input, not a gate verdict.

Findings

• H19 #12104 — pm:blocked and 1 of 1 Blocked-by: target(s) could NOT be resolved this sweep (#14313 (HTTP 404)) — 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. A cross-repo target resolves only when its repo answers this sweep's credential. 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 it is the landed ACT — 「释放是显式动作:让卡离手者同笔清 assignee + Release: 行(会话/因/去向);下一任重新认领。」 — ONE write with TWO halves: it clears the assignee AND carries the Release: line (session, cause, destination). Dropping the field alone leaves no record of who let the card go, the half-state H47 reports. 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 #14822 — pm:blocked and 1 of 1 Blocked-by: target(s) could NOT be resolved this sweep (#14832 (HTTP 404)) — 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. A cross-repo target resolves only when its repo answers this sweep's credential. 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 it is the landed ACT — 「释放是显式动作:让卡离手者同笔清 assignee + Release: 行(会话/因/去向);下一任重新认领。」 — ONE write with TWO halves: it clears the assignee AND carries the Release: line (session, cause, destination). Dropping the field alone leaves no record of who let the card go, the half-state H47 reports. 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 #15140 — pm:blocked and 1 of 1 Blocked-by: target(s) could NOT be resolved this sweep (objectstack-ai/cloud#1962 (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. 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 it is the landed ACT — 「释放是显式动作:让卡离手者同笔清 assignee + Release: 行(会话/因/去向);下一任重新认领。」 — ONE write with TWO halves: it clears the assignee AND carries the Release: line (session, cause, destination). Dropping the field alone leaves no record of who let the card go, the half-state H47 reports. 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 #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 it is the landed ACT — 「释放是显式动作:让卡离手者同笔清 assignee + Release: 行(会话/因/去向);下一任重新认领。」 — ONE write with TWO halves: it clears the assignee AND carries the Release: line (session, cause, destination). Dropping the field alone leaves no record of who let the card go, the half-state H47 reports. 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 #15484 — pm:blocked and 1 of 1 Blocked-by: target(s) could NOT be resolved this sweep (#14366 (HTTP 404)) — 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. A cross-repo target resolves only when its repo answers this sweep's credential. 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 it is the landed ACT — 「释放是显式动作:让卡离手者同笔清 assignee + Release: 行(会话/因/去向);下一任重新认领。」 — ONE write with TWO halves: it clears the assignee AND carries the Release: line (session, cause, destination). Dropping the field alone leaves no record of who let the card go, the half-state H47 reports. 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.
• H35 #16929 — needs:contract-review was REMOVED from this CARD by os-bill at 2026-09-10T11:54:16Z 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 #6021 — pm:seat post is STALE — its lane domain:services carries a Claim: on A min/max over a formula field cannot be typed: sourceFieldMeta does not carry FieldSchema.returnType, the key whose own JSDoc names dataset measures as its consumer #16236 written 0.2h AFTER this post's last event (claim 2026-09-10T19:26:12.000Z, post 2026-09-10T19:14:56.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.
• H32 #6023 — pm:seat HELD, and its lane domain:devx has 73 unclaimed pm:queue card(s) with NOTHING in flight — ~26209 min since the seat's latest marker (threshold 480 min). The board is asserting two things that cannot both be healthy: a lane with dispatchable work and zero throughput, and a named holder on the clock for it. Neither half is visible from any card — a queued card looks exactly like an ordinary queued card however long it has been one (H30), and a seat post looks exactly like a seat post — which is why the measured incident was reported by the seat ITSELF and by no gauge: it ended round after round with 「要我继续派吗?」 while in-flight was zero and 40+ dispatchable cards sat in the queue, against a clause that already says ⛔ 不等人闸 in as many words. ⛔ So this row is NOT a new rule and must not be read as one — the rule is not missing, the detectability was (「规则不缺,措辞也不含糊」). ⚠️ A DECLARED wait is exempt here regardless of elapsed time: a latest marker naming 等 CI / 等裁决 / 等人工步骤 or an awaiting-class state silences this row, so a seat that IS waiting states it and is not reported. That is also the remedy when this fires and the wait is real — say what it is waiting on, in the marker. Otherwise the move is the one the clause already names: dispatch the next wave, or hand the seat over and mark it vacant so the lane reads as unheld rather than held-and-still. Report-only: ⛔ never a label, a title or a marker written from this script — which of those two moves applies is the whole judgement.
• H52 #9659 — the newest os-dev-report (comment 5330963994, 2026-08-18T16:15:12Z) carries 1 non-empty open_questions entry(ies) while the card carries NO needs-user-decision label: 「Do you want a PRE-EMPTIVE injection of @objectstack/formula, given zero divergence today but live call sites? It is the only one of the four whose bundled surfa…」. So a question only the maintainer can answer is filed, well-formed and UNREACHABLE — it is in no inbox, no candidate query and no staleness alert, while the card's own state label — whichever of the six it is — reads as work in progress on every board, so nothing a reader can see says a decision is owed. ⚠️ This is the shape that produces three success signals and a wrong answer: the dev did its job, the report validated, the seat accepted it, and the decision never arrived. Remedy, in the order the protocol asks for it: if the question is the one this card was dispatched on, put the card in the inbox (needs-user-decision) and present it; if it is a RESIDUAL raised while EXECUTING a ruling this card already carries, ⛔ never re-hang the label here — file a NEW card carrying the question and linking the ruled one, because a re-flagged card leaves the inbox unable to say WHICH question is open and invites a reader to re-present a ruling that has already been executed, and because this card's close would take the label, and the question's only visibility, with it. If the question has already been ANSWERED, say so in the next report, whose empty open_questions is the record that stands this row down. ⛔ Nothing here changes the report contract: the array is the right place for the question. Report-only patrol INPUT: nothing is blocked and no label is written.
• H52 #9707 — the newest os-dev-report (comment 5335163974, 2026-08-18T22:56:20Z) carries 1 non-empty open_questions entry(ies) while the card carries NO needs-user-decision label: 「Should packages/lint gain an additive, browser-safe subpath export (e.g. './authoring-capabilities') carrying validateCapabilityReferences without the node-only…」. So a question only the maintainer can answer is filed, well-formed and UNREACHABLE — it is in no inbox, no candidate query and no staleness alert, while the card's own state label — whichever of the six it is — reads as work in progress on every board, so nothing a reader can see says a decision is owed. ⚠️ This is the shape that produces three success signals and a wrong answer: the dev did its job, the report validated, the seat accepted it, and the decision never arrived. Remedy, in the order the protocol asks for it: if the question is the one this card was dispatched on, put the card in the inbox (needs-user-decision) and present it; if it is a RESIDUAL raised while EXECUTING a ruling this card already carries, ⛔ never re-hang the label here — file a NEW card carrying the question and linking the ruled one, because a re-flagged card leaves the inbox unable to say WHICH question is open and invites a reader to re-present a ruling that has already been executed, and because this card's close would take the label, and the question's only visibility, with it. If the question has already been ANSWERED, say so in the next report, whose empty open_questions is the record that stands this row down. ⛔ Nothing here changes the report contract: the array is the right place for the question. Report-only patrol INPUT: nothing is blocked and no label is written.
• H52 #10032 — the newest os-dev-report (comment 5363412215, 2026-08-20T23:45:14Z) carries 2 non-empty open_questions entry(ies) while the card carries NO needs-user-decision label: 「My own instrument wrote a raw NUL byte into scripts/check-test-completeness.mjs mid-run, and I want it recorded rather than quietly fixed. perl -0pi -e 's{...}…」 · 「This card's title carries two claims and only one is now discharged. The zero-output half has been chased twice and both cited occurrences dissolved on inspecti…」. So a question only the maintainer can answer is filed, well-formed and UNREACHABLE — it is in no inbox, no candidate query and no staleness alert, while the card's own state label — whichever of the six it is — reads as work in progress on every board, so nothing a reader can see says a decision is owed. ⚠️ This is the shape that produces three success signals and a wrong answer: the dev did its job, the report validated, the seat accepted it, and the decision never arrived. Remedy, in the order the protocol asks for it: if the question is the one this card was dispatched on, put the card in the inbox (needs-user-decision) and present it; if it is a RESIDUAL raised while EXECUTING a ruling this card already carries, ⛔ never re-hang the label here — file a NEW card carrying the question and linking the ruled one, because a re-flagged card leaves the inbox unable to say WHICH question is open and invites a reader to re-present a ruling that has already been executed, and because this card's close would take the label, and the question's only visibility, with it. If the question has already been ANSWERED, say so in the next report, whose empty open_questions` is the record that stands this row down. ⛔ Nothing here changes the report contract: the array is the right place for the question. Report-only patrol INPUT: nothing is blocked and no label is written.
• H52 #11286 — the newest os-dev-report (comment 5393404811, 2026-08-24T09:39:41Z) carries 1 non-empty open_questions entry(ies) while the card carries NO needs-user-decision label: 「The card's own reasoning for the removal option rests on a dependency that does not exist. [finding] sys_user.manager_id now carries two independent organization screens, in two packages, with no shared code #11286 says 'plugin-approvals already depends on plugin-sharing, so t…」. So a question only the maintainer can answer is filed, well-formed and UNREACHABLE — it is in no inbox, no candidate query and no staleness alert, while the card's own state label — whichever of the six it is — reads as work in progress on every board, so nothing a reader can see says a decision is owed. ⚠️ This is the shape that produces three success signals and a wrong answer: the dev did its job, the report validated, the seat accepted it, and the decision never arrived. Remedy, in the order the protocol asks for it: if the question is the one this card was dispatched on, put the card in the inbox (needs-user-decision) and present it; if it is a RESIDUAL raised while EXECUTING a ruling this card already carries, ⛔ never re-hang the label here — file a NEW card carrying the question and linking the ruled one, because a re-flagged card leaves the inbox unable to say WHICH question is open and invites a reader to re-present a ruling that has already been executed, and because this card's close would take the label, and the question's only visibility, with it. If the question has already been ANSWERED, say so in the next report, whose empty open_questions is the record that stands this row down. ⛔ Nothing here changes the report contract: the array is the right place for the question. Report-only patrol INPUT: nothing is blocked and no label is written.
• H19 #11333 — pm:blocked while 1 of 3 Blocked-by: target(s) — read from body OR comment — is CLOSED (#12400 (closed 2026-08-29T15:16:12Z)): 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 it is the landed ACT — 「释放是显式动作:让卡离手者同笔清 assignee + Release: 行(会话/因/去向);下一任重新认领。」 — ONE write with TWO halves: it clears the assignee AND carries the Release: line (session, cause, destination). Dropping the field alone leaves no record of who let the card go, the half-state H47 reports. 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: #13458 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.
• H52 #11453 — the newest os-dev-report (comment 5401760566, 2026-08-24T21:43:12Z) carries 1 non-empty open_questions entry(ies) while the card carries NO needs-user-decision label: 「Non-blocking, for the contract-review tier: DELIVERY_NOT_ELIGIBLE is reused rather than minted, and the ledger's inline gloss for it (packages/spec/src/api/e…」. So a question only the maintainer can answer is filed, well-formed and UNREACHABLE — it is in no inbox, no candidate query and no staleness alert, while the card's own state label — whichever of the six it is — reads as work in progress on every board, so nothing a reader can see says a decision is owed. ⚠️ This is the shape that produces three success signals and a wrong answer: the dev did its job, the report validated, the seat accepted it, and the decision never arrived. Remedy, in the order the protocol asks for it: if the question is the one this card was dispatched on, put the card in the inbox (needs-user-decision) and present it; if it is a RESIDUAL raised while EXECUTING a ruling this card already carries, ⛔ never re-hang the label here — file a NEW card carrying the question and linking the ruled one, because a re-flagged card leaves the inbox unable to say WHICH question is open and invites a reader to re-present a ruling that has already been executed, and because this card's close would take the label, and the question's only visibility, with it. If the question has already been ANSWERED, say so in the next report, whose empty open_questions` is the record that stands this row down. ⛔ Nothing here changes the report contract: the array is the right place for the question. Report-only patrol INPUT: nothing is blocked and no label is written.
• 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.
• H19 #11925 — pm:blocked while 4 of 4 Blocked-by: target(s) — read from body OR comment — are CLOSED (#12034 (closed 2026-09-10T14:03:47Z), #12036 (closed 2026-09-07T01:56:13Z), #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. 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 it is the landed ACT — 「释放是显式动作:让卡离手者同笔清 assignee + Release: 行(会话/因/去向);下一任重新认领。」 — ONE write with TWO halves: it clears the assignee AND carries the Release: line (session, cause, destination). Dropping the field alone leaves no record of who let the card go, the half-state H47 reports. 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 #11973 — pm:blocked while 1 of 2 Blocked-by: target(s) — read from body OR comment — is CLOSED (#13689 (closed 2026-09-07T12:00:53Z)): 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 (#11978), 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 it is the landed ACT — 「释放是显式动作:让卡离手者同笔清 assignee + Release: 行(会话/因/去向);下一任重新认领。」 — ONE write with TWO halves: it clears the assignee AND carries the Release: line (session, cause, destination). Dropping the field alone leaves no record of who let the card go, the half-state H47 reports. 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 #11973 — pm:blocked on 1 target(s) that can never CLOSE: #11978 (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.
• … 297 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.

⚠️ 26 family(ies) had rows omitted by the body trim: H4 (0/17), H12 (0/1), H19 (8/24), H20 (0/2), H26 (3/13), H28 (0/1), H36 (0/2), H43 (0/3), H52 (5/31), H2 (0/1), H8 (0/4), H9 (0/15), +14 more in the table.

family	band	computed	rendered
H35	gate	1	1
H4	stall	17	0
H12	stall	1	0
H19	stall	24	8
H20	stall	2	0
H26	stall	13	3
H28	stall	1	0
H32	stall	1	1
H36	stall	2	0
H38	stall	1	1
H43	stall	3	0
H52	stall	31	5
H2	state	1	0
H8	state	4	0
H9	state	15	0
H10	state	2	0
H13	state	1	0
H24	state	1	0
H30	state	39	0
H44	state	47	0
H46	state	4	0
H50	state	21	0
H54	state	3	0
H56	state	7	0
H5	inventory	7	0
H6	inventory	11	0
H11	inventory	35	0
H14	inventory	20	0
H15	inventory	1	0

Computed 0 row(s) this sweep, and therefore absent from the table (21): H1, H3, H7, H16, H18, H21, H23, H25, H27, H29, H31, H33, H34, H37, H45, H47, H48, H49, H51, H53, H55. 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)

78 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 5899 distinct # reference(s) read off 2193 live-board text(s) (600 open card(s)/PR(s) + 217 already-cached comment thread(s)); 1237 answered free from listings in hand, 4262 NOT ATTEMPTED at the 400-resolution budget (attempted down to #14564), 1 above #17529, the highest number this sweep saw.

• fix(service-automation): a notify node that reached nobody stops reading like a run with nobody to reach #17324 — HTTP 404, does not resolve; referred to by #9857, #17374
• READ_SCOPE_COMPILE_FAILED 的 ledger 注释只说 "lowering"，但从 #17130 起 resolution 阶段也盖这个章 #17318 — HTTP 404, does not resolve; referred to by #9857, #17374
• fix(service-analytics): declare an envelope on the row-scope fail-closed refusals, so a security refusal can never be served as an empty chart #17316 — HTTP 404, does not resolve; referred to by #9857, #17374
• dispatch-gates --ran 把一次被杀死的 gate 读作 RUN：kill 码留在声明路径上，而文件自己的教义说它是 UNRUN #17313 — HTTP 404, does not resolve; referred to by #9857, #17374
• [Decision] 批量创建把作者声明的行级 check 整个跳过，违规行照落 —— 修法方向已定，要裁的是「失败语义」 #17297 — HTTP 404, does not resolve; referred to by #9857, #17374
• security(rls): refuse RESERVED_RLS_MEMBERSHIP_KEYS by name at the RLS compiler merge #17289 — HTTP 404, does not resolve; referred to by #9857, #17366
• 授权时点看不见驱动能力差：os validate / os lint 接受一个在目标驱动上不可用的 analytics 键，作者只能在运行时的错误卡上发现 #17276 — HTTP 404, does not resolve; referred to by #9857, #17374
• fix(security): OAuth-connected MCP agents run at the delegator's record depth; narrowed delegated reads say so #17256 — HTTP 404, does not resolve; referred to by #9857, #17374
• fix(objectql): the in-memory aggregate lowering asks the driver for rows, so a measure filter stops being refused on driver-memory (#16642) #17251 — HTTP 404, does not resolve; referred to by #9857, #17366
• dispatch-gates --ran's headline "0 NOT-MEASURED" is the runner's claim, not a measurement — a seat whose gates exited 3 still gets a green tick #17204 — HTTP 404, does not resolve; referred to by #9857, #17366, #17382
• The 4096 heavy-command prefix in os-dev.md makes check:type-check-debt OOM into exit 3 — the gate pins its own 6144 CI-shaped ceiling #17151 — HTTP 404, does not resolve; referred to by #9857
• [needs decision] #16659's ruled fix refuses the repo's own four example scheduled flows at bind, and today a package-shipped flow has no legal organization to name #17150 — HTTP 404, does not resolve; referred to by #9857, #12708, #17374, #17396
• [finding] a bare-Error refusal reaching queryDataset is classified by WORDING — a security refusal whose text happens to contain "not registered" becomes a 200 with an empty chart #17130 — HTTP 404, does not resolve; referred to by #9857, #17374
• ADR-0095 delta c's carve-out now holds only at the read call site — PR #17115 tightens the compiler past it, and the asymmetry is undocumented #17129 — HTTP 404, does not resolve; referred to by #9857, #17323
• [finding] the RLS check post-image gate is guarded by !Array.isArray(opCtx.data), and it is the ONLY site that computes the check filter — so whether an array-shaped write is judged at all is unestablished #17128 — HTTP 404, does not resolve; referred to by #9857, #17374
• fix(triggers,spec,service-automation): a time-triggered flow declares its acting organization and runs as it (#16659) #17126 — HTTP 404, does not resolve; referred to by #9857, #12708, #17374
• fix(service-analytics): row-scope bridge tells absent from broken security service #17125 — HTTP 404, does not resolve; referred to by #9857
• A notify node that enqueued NOTHING reports the same as one that delivered: unmeasured=0 makes a zero-delivery run indistinguishable from a successful one #17123 — HTTP 404, does not resolve; referred to by #9857, #17366, #17374, #17396
• fix(plugin-security): stop letting org-admin row count decide whether a platform admin already exists #17116 — HTTP 404, does not resolve; referred to by #9857, #12708, #17346, #17368
• fix(security)!: an RLS predicate naming an undeclared column denies in every position #17115 — HTTP 404, does not resolve; referred to by #9857, #12708
• [finding] service-settings' route ledger has no conformance guard — the pattern every sibling ledger follows is silently missing here #17062 — HTTP 404, does not resolve; referred to by #9857, #17111
• fix(service-analytics): translate select dimension option labels on dataset charts #17061 — HTTP 404, does not resolve; referred to by #9857, #12708
• [finding] Two dev seats stalled within one hour by ending their turn on a watcher they spawned themselves — the os-dev contract never says a subagent cannot be woken by its own background job #17044 — HTTP 404, does not resolve; referred to by #7623, #9857
• [finding] The route-ledger conformance suite asserts only at DOMAIN granularity, so ANY single route row can vanish from ANY of the 11 ledgers with nothing red — measured by deleting one #17041 — HTTP 404, does not resolve; referred to by #9857, #12708, #17111
• [finding] No rule anywhere says what two open PRs touching the same file means — so a seat read it off a CHECK NAME, and the check's name over-reads its one-entry key by design #17032 — HTTP 404, does not resolve; referred to by #7623, #9857
• … 53 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 100 of 100 open pm:on-hold card(s); 8322 tracked file(s) in the oracle.)

• #2657 — 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.ts
• #6009 — packages/drivers/driver-sql/src/sql-driver.ts
• #6736 — packages/plugins/plugin-sharing/src/sharing-service.ts
• #7401 — packages/plugins/plugin-security/src/security-plugin.ts
• #8345 — packages/services/service-analytics/src/analytics-service.ts, packages/spec/src/data/currency-fraction-digits.ts, packages/spec/src/data/field.zod.ts
• #8346 — docs/PLATFORM_GAPS_FROM_TEMPLATES.md, packages/spec/src/ui/view.zod.ts
• #8347 — packages/client/src/realtime-api.ts, packages/runtime/src/http-dispatcher.ts
• #8740 — packages/drivers/driver-sql/src/sql-driver.ts
• #8897 — scripts/check-durability-degradation-log-level.mjs
• #8966 — content/docs/deployment/meta.json, content/docs/meta.json
• #9139 — packages/lint/src/data-model-rules.ts, packages/lint/src/validate-security-posture.test.ts
• #10315 — scripts/check-cross-package-test-inputs.mjs
• #10572 — examples/app-todo/package.json
• #10694 — scripts/check-cross-package-test-inputs.mjs
• #11331 — packages/cli/src/utils/osplugin.ts, packages/core/src/security/plugin-artifact-integrity.ts
• #12576 — scripts/durability-read-invention.baseline.json
• #12789 — packages/objectql/src/registry.ts
• #12799 — scripts/check-type-check-coverage.mjs
• #13528 — packages/services/service-storage/src/metadata-store.ts, packages/services/service-storage/src/storage-routes.ts
• #13542 — packages/plugins/plugin-security/src/security-plugin.ts
• #14121 — packages/metadata/src/loaders/database-loader.ts
• #14169 — packages/drivers/driver-mongodb/src/mongodb-driver.ts
• #14290 — scripts/objectui-changeset-digest.mjs, scripts/pm/dispatch-gates.mjs
• #14490 — .objectui-sha, scripts/sdui-manifest.record.json
• #16173 — scripts/test-shard-timings.json
• #16222 — scripts/test-shard-timings.json

Closed-card pm:* residue (H39 census, informational): pm:dispatched 2072, pm:queue 857, pm:blocking 41, pm:blocked 20, 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 3 of 421 closed card(s) still carrying residue (pm:dispatched 2, pm:blocking 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 ~148.4/day against pinned MEASURED_MERGES_PER_DAY = 137.5/day, measured 2026-08-23 (19d ago) (factor 1.08, band 2x).