[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-21T02:02:57.927Z · expected every 6h (cron 37 1,7,13,19 * * * UTC) · next by 2026-09-21T07:37Z · run 35552505373 · commit fbc12be318de0713e82e1f38ab804b5b63478e64 · trigger schedule

The timestamp above is the patrol's own heartbeat, and the line states the cadence that makes 「stalled」 decidable: a Swept line still sitting there past the next by deadline beside it means the standing caller died, which is the failure this anchor was created to make visible. ⛔ Do not carry a cadence over from a sibling anchor — the four patrols differ by 4× and each states its own. Read it before you read the rows.

⚠️ 2 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 429 open pm-/p0-labeled issue(s), 494 open issue(s) in the unscoped pass (H13–H15, H18), 17 open PR(s) (merge state read on 3 of 3 H16 candidate(s)) and 693 recently-merged PR(s) in objectstack-ai/objectstack — 577 half-state(s) found. H8's merged window is a TIME cap of 8 day(s), read in 8 page(s) (horizon reached: a delivery inside the window was seen, not merely the first N rows). H22 read 352 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-17, 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 (~139.4/day, measured 2026-09-11), 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 OK — observed ~222.7/day against pinned MEASURED_CLOSED_ISSUE_UPDATES_PER_DAY = 139.4/day, measured 2026-09-11 (10d ago) (factor 1.60, band 2x). H23 read 273 squash commit message(s) from the default branch, carrying 250 closing-keyword binding(s) across 237 message(s). H23's commit window is a TIME cap of 3 day(s), read in 3 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 101 of 101 H17 candidate(s). Blocked-by: comment fallback read on 74 of 74 candidate(s). Restart-when: hold comments read on 82 of 82 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 4 of 4 judged candidate(s). Blocker liveness (H19): targets resolved on 69 of 72 distinct Blocked-by: target(s) named by open pm:blocked card(s) — the 3 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). ⚠️ One class is named only where its card already has a row: a target reaching a card ONLY through the comment archive beside a body that states its own Blocked-by: set is outside what H19 judges, so it rides a row rather than founding one (#18379) — it is a spent line, and the row it used to found was unclearable by construction. 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 8 of 8 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 16 of 16 open PR(s) — a pair needs both sides read, so a shortfall can only MISS a hold, never invent one. Governed review requests (H43): 6 of the open PR(s) whose changed-file page was read hit the governed register, and the submitted-review leg answered on 6 of 6 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 209 of 209 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): 361 of 400 attempted resolution(s) answered, over 4728 distinct # reference(s) read off the LIVE board — 513 open card(s)/PR(s) and 418 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. 1202 number(s) were answered free from listings already in hand, and 3126 were NOT ATTEMPTED at the 400-resolution budget (newest-first; this pass reached down to #17440) — not attempted is not clean; 1 reference(s) name a number above the highest this sweep saw and were held out rather than resolved. 39 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): 2262 comment(s) across 418 thread(s) ALREADY in hand were read for the five artefact shapes, and the seat leg widened the fetch to 10 of 10 seat post(s) — every HELD seat whatever its lane spelling, PLUS the TRIAGE post whether or not it is held, which is wider than H32's own population in both directions and deliberately so. A seat post's window is its NEWEST comment page, not the oldest one a page-less request returns: 10 of those post(s) had that page LOCATED from the carrier's own comments count and the rest fell back to page 1, one request per seat post either way and shared with H56, H64 and H65. ⛔ 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): 2262 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 71 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): 11 of 11 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): 35 of 253 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): 6 of 6 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): 21 of 21 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): 23 of 23 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): 407 of 427 listed open card(s) had a COMPLETE comment thread in hand to judge the newest os-dev-report against (2 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): 4 of 4 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. Scheduled non-blocking workflows (H57): 23 workflow(s) on the swept repo declare a schedule; 7 were judged against their latest event=schedule run and 0 are UNJUDGED rather than clean because that read failed. Held out: 16 declaring a PR-gating trigger (pull_request / pull_request_target / merge_group — the structural reading of "not in the required set", deliberately NARROWER than the ruleset's own answer, so a scheduled workflow that runs on pull requests without being required is silence this row does not break), 0 for a non-active workflow state. A further 2 workflow file(s) carried an on: block this file refused to read, so whether they belong to this population is UNJUDGED. Cost 8 request(s): the workflows listing plus one event=schedule read per judged workflow, and ⛔ never a status=success count. Queued ruling markers (H58): 209 open pm:queue card(s) had their BODY judged against 3 frozen heading anchor(s) — 3 with a comment thread ALREADY in hand, 206 on the body ALONE. It fetches NOTHING of its own, so a card whose thread no other row bought has an UNREAD second channel rather than a clean one, and the rows are a LOWER BOUND. It matches ATX HEADINGS outside fenced code only: a marker quoted in prose, in a table, in a code span or in a blockquote is invisible here by design. Merged-PR closing linkage (H59): 652 declared closure(s) and 514 keyword-LESS mention(s) from the bodies in H8's merged window were judged against the open listing this sweep already holds; a declared target still on that listing is a FALSE OPEN row and costs no request. 1583 further mention(s) named a card that is neither open nor inside H22's 3-day closed window, so their closure could not be PLACED and they are UNJUDGED rather than clean — this row's real reach is the SHORTER of the two windows, ⛔ never H8's 8 days. Of the mentions that could be placed, only a closure inside the measured 5s band buys evidence: 0 card(s) had ONE timeline page read (cap 40 card(s) per sweep, ⛔ no retry on any status), 0 could not be read and 0 were past that cap — all UNJUDGED, never clean. A declaring SIBLING PR inside the same band EXPLAINS a closure and this row stays quiet, because batched landings put two merges in one second. ⚠️ The closed event carries no commit_id on this board (measured), so the commit leg is exact where it fires and fires on nothing here; the band leg is circumstantial and every row says so. Rows are a LOWER BOUND. Unattributed seat content (H64): 1579 of 2775 text(s) read carry a seat/dev signature; 113 of those name no session id anywhere — 9 created on/after 2026-09-13T00:00:00Z and judged, 8 filed as rows under this family's own 10-row cap (newest first, because the body trim eats the highest card numbers), and 104 counted here as a CENSUS reaching back to 2026-08-08T13:49:21Z. INFORMATIONAL, no remedy and no row: 1297 signed text(s) are authored by a USER account rather than claude[bot] (baozhoutao, hotlong, huangyiirene, os-bill, os-elon-musk, os-help, os-justin, os-litant, and 11 more). A suspended user account hides everything it authored — measured on this board, not hypothetical — so those artefacts carry that exposure; but the token class follows the Claude Code ACCOUNT and flips between writes with no seat act behind it, and nothing available to a user-token session chooses the class of its own write or moves content it already authored to the App, so this half names NO remedy and files NO row rather than re-filing an unclearable one every sweep. 3 of them carry no App credential at all (a user PAT) and 10 ride the /pulls shape that does not serve performed_via_github_app; ⛔ that field names the APP whose credential signed a write and never the TOOL, so an MCP-tool write and a REST-proxy write under one credential are indistinguishable here and no channel is inferred from it. 0 signed text(s) carried no readable user, so the exposure count is a lower bound. It fetches NOTHING of its own: the corpus is the open card and PR bodies in hand plus the card threads H44 and H56 read, so a PULL-REQUEST comment thread is outside it by construction and these numbers are a LOWER BOUND. Triage round tiers (H65): 1 round artefact(s) judged on the NEWEST comment page of 1 of 1 triage seat post(s) (34 comment(s) on those pages), 1 carrier(s) filed. It BUYS that page — ONE request per seat post per run, the page computed from the carrier's own comments count — because a page-less request returns a thread's FIRST page and GitHub serves comments OLDEST-FIRST: on an 800-comment seat thread that window is five weeks stale, so reading it would judge artefacts nobody will edit and never see the current round. That page is SHARED with the seat leg above rather than bought twice — H44, H56 and H64 read the same rows for a seat post — and this row writes nothing into any cache itself, so no other row's corpus moves here. An artefact OLDER than that page is outside this row by construction and a post whose page could not be read is UNJUDGED rather than clean, so the rows are a LOWER BOUND. Released queue cards (H66): 207 open unassigned pm:queue card(s) could be spoken about, 1 with a comment thread ALREADY in hand, 100 NEWEST comment page(s) BOUGHT this run (cap 100, 106 candidate(s) NOT ATTEMPTED at that cap), 1 listed. 0 card(s) stayed UNJUDGED — a page whose fetch failed, or a carrier whose comments count is unreadable and whose first page came back FULL, so the newest comment could not be LOCATED; neither is clean (#4690), and a candidate the cap did not attempt is not clean either. The buy is ONE page per card, the NEWEST one, located from the carrier's own comments count through H65's helpers — ⛔ never page 1 on a long thread, because GitHub serves issue comments OLDEST-FIRST — and candidates are ordered NEWEST-TOUCHED first, because a release is a write on the card. The free half is unchanged: a thread another row already paid for costs nothing here. ⚠️ Measured 2026-09-16 over 29 threads on two boards, the canonical Release: line appeared ZERO times, so the live leg is the release ANNOUNCEMENT heading and the rows are a LOWER BOUND. ⛔ A LISTING, never a verdict: the remedy is a hand read, and no state is proposed for what it lists. Queued cards with a merged delivery (H67): 207 open unassigned pm:queue card(s) could be spoken about, 120 had ONE timeline page READ this run (cap 120 page(s)), 56 LISTED, 87 NOT ATTEMPTED at that cap. 1 card(s) stayed UNJUDGED — a page whose fetch FAILED (⛔ no retry on any status) or a page that came back FULL, which may hide a later merge, a later OPEN PR or a later Claim:; neither is clean (#4690), and a candidate the cap did not attempt is not clean either. The read is ONE page per card, page 1, because the timeline is served OLDEST-FIRST and no listing payload carries an event count to locate a newest page from — H59's contract, and this row has no free half at all, because nothing else in this file caches a timeline. Candidates are ordered OLDEST-FIRST — the OPPOSITE of H66's — because the order in force is 「清不空的那一刻起改最老优先」 and the cards a seat reaches NEXT are the ones that must have been read; the plan models the priority and age legs of 取卡全序 only, ⛔ not target: board membership and ⛔ not the 「先 Bug」 tiebreak. ⚠️ Rows are a LOWER BOUND: a delivery that left NO cross-reference is invisible to this instrument (the filer's own declared blind spot). A DECORATED **Release:** line WAS a second way and is no longer — the ownership marker this row shares with H2/H47/H66 reads it through markerMatches, and what that reading still refuses is named by the near-miss clause below rather than lost. ⛔ A LISTING, never a verdict, and 「有已合 PR」 is ⛔ not a closing criterion: the remedy on every row is a hand read, with the thread's residual readings carried out into a new card BEFORE anything is closed. Ownership-marker near misses: 16 line(s) on 13 of 199 thread(s) already in hand OPEN with Claim:/Release: in a spelling the marker refuses even after decoration is removed, against 8 NAMED form(s) (heading, list-item, underscore-emphasis, inflected-word, separator, leading-sigil, heading-bare, bare-word) — #19417 comment 5754051981 「## Claim」 (heading-bare); #19403 comment 5753623740 「| Release:」 (leading-sigil); objectstack-ai/objectstack#15638 comment 5555005915 「Claimed」 (bare-word); objectstack-ai/objectstack#18740 comment 5723834336 「Release-」 (separator); objectstack-ai/objectstack#18740 comment 5724053148 「Release-」 (separator), 11 further line(s) NOT NAMED at the 5-entry cap. The reading itself is markerMatches— ONE place, sharing theBlocked-by:family's stripper — so a DECORATEDRelease:line IS read and this census is what is left over. ⛔ Report-only and ⛔ NEVER a half-state verdict by itself: a near miss is a line no ownership row (H2/H47/H66/H67) counted, named with its card, its comment id and the offending prefix so the next decoration is ADDED to the vocabulary instead of replaying this silently. ⚠️ A LOWER BOUND twice over: it reads only the threads other rows already bought, and only the forms the vocabulary names. 0pm:seatthread(s) are OUT of that population (0 near-miss line(s) not listed above): a seat post's ownership is its BODY — the registration and the 🟢/⏳ title H5/H6 read — plus its AUDIT COMMENTS, and the protocol never puts aClaim:comment on one, so what its comments carry is SHIFT NARRATION in which a directive word opens a sentence. ⛔ COUNTED, never silently dropped: the two numbers are what let a reader reconstruct what the unfiltered census printed. 0 further line(s) are release ANNOUNCEMENTS rather than refused records — a heading whose word is the PARTICIPLEReleased, whose remainder names the PR #nthat landed or thepm:→pm:transition it unblocked, and which names NO session: a delivery report on a card nobody held, so noRelease: is owed and there is no unreadable record to normalise. The reading is deliberately NARROW and every narrowing leaves the line in the census above: HEADING forms only (Release-landed: … (PR #n)is aseparator line and stays), the PARTICIPLE only (## Release: …` opens the directive and stays), and NO session token in either spelling (a release that names its session is a record, readable or not, and stays). Report-only: findings are patrol input, not a gate verdict.

Findings

• 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)) — the set judged against the BODY's Blocked-by: set, the authoritative carrier whenever the body states one (a body is rewritten in place, a comment is an archive) — 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)) — the set judged against the BODY's Blocked-by: set, the authoritative carrier whenever the body states one (a body is rewritten in place, a comment is an archive) — 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.
• H35 #19365 — needs:contract-review was removed from this open CARD by os-warren at 2026-09-21T00:09:28Z and the gate is still absent — UNJUDGED, not clean. The hang it clears was ALSO a lone stroke: this gate only ever had ONE carrier, so 「双载体同笔清标」 leaves no structural evidence in either direction and no carrier comparison — H31's or this row's — can say whether it was cleared or stripped. The only remaining evidence is a review verdict written as free prose, which has no canonical machine-readable form (measured: a strict marker matched 5 of 35 removals, a loose one 10), so this row declines to parse it rather than widen into a check that cannot fail. Two producer-side repairs would each make this judgeable: hang the PR carrier as 「PR 一存在即挂」 already requires, or give the verdict a canonical marker. 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.
• H4 #3739 — 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. This card DOES state its block — in PROSE, where no machine reads it. Candidate upstream(s) read off its anchored prose: #17454 CLOSED (2026-09-12T01:21:42Z), #17743 UNRESOLVED (HTTP 404). 1 of 2 is ALREADY CLOSED — the block is at least partly expired, and nothing machine-readable is tracking any of it. ⚠️ A prose sentence is NOT a directive: these are CANDIDATES read off anchored prose (「blocked on」, 「HELD by」, 「blocker」, 「解锁条件」, 「解除条件」, 「unblock…」), never a verdict, and ⛔ no label is written from here. Read the card before acting, and fix it by writing the Blocked-by: #N line whatever the states above say.
• H38 #6024 — pm:seat post is STALE — its lane domain:cli (seat 1) carries a Claim: on [finding] the HTTP install door reads manifest.id positionally and never parses the body through ManifestSchema — POST /packages answers 201 to ids that MANIFEST_ID_PATTERN (spec, defineStack, os build, the publish face) refuses #19417 written 8.3h AFTER this post's last event (claim 2026-09-21T00:59:16.000Z, post 2026-09-20T16:44:03.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.
• H38 #6367 — pm:seat post is STALE — its lane domain:engine (seat 1) carries a Claim: on 83 metadata-form label keys ship their English source in all three locales (249 leaves) and no pin sees any of them #19403 written 0.9h AFTER this post's last event (claim 2026-09-21T01:36:14.000Z, post 2026-09-21T00:42:58.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.
• 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 — or, on a card no dev is dispatched to and which therefore can never get one, answer them on the thread in a comment NEWER than that report, under a HEADING that names open_questions and says ANSWERED. ⛔ 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 — or, on a card no dev is dispatched to and which therefore can never get one, answer them on the thread in a comment NEWER than that report, under a HEADING that names open_questions and says ANSWERED. ⛔ 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_questionsis the record that stands this row down — or, on a card no dev is dispatched to and which therefore can never get one, answer them on the thread in a comment NEWER than that report, under a HEADING that namesopen_questions` and says ANSWERED. ⛔ 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 #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_questionsis the record that stands this row down — or, on a card no dev is dispatched to and which therefore can never get one, answer them on the thread in a comment NEWER than that report, under a HEADING that namesopen_questions` and says ANSWERED. ⛔ 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.
• … 565 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.

⚠️ 40 family(ies) had rows omitted by the body trim: H4 (1/6), H12 (0/2), H19 (2/19), H20 (0/3), H26 (2/18), H28 (0/2), H36 (0/2), H43 (0/6), H52 (4/55), H57 (0/2), H2 (0/2), H8 (0/4), +28 more in the table.

family	band	computed	rendered
H35	gate	1	1
H4	stall	6	1
H12	stall	2	0
H19	stall	19	2
H20	stall	3	0
H26	stall	18	2
H28	stall	2	0
H36	stall	2	0
H38	stall	2	2
H43	stall	6	0
H52	stall	55	4
H57	stall	2	0
H2	state	2	0
H8	state	4	0
H9	state	67	0
H10	state	2	0
H13	state	19	0
H18	state	2	0
H23	state	2	0
H24	state	2	0
H30	state	65	0
H44	state	46	0
H46	state	1	0
H50	state	10	0
H51	state	1	0
H54	state	8	0
H55	state	2	0
H56	state	6	0
H58	state	1	0
H59	state	2	0
H60	state	2	0
H62	state	4	0
H64	state	8	0
H65	state	1	0
H66	state	1	0
H67	state	56	0
H68	state	10	0
H5	inventory	10	0
H6	inventory	12	0
H11	inventory	80	0
H14	inventory	32	0
H15	inventory	1	0

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

39 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 4728 distinct # reference(s) read off 2775 live-board text(s) (513 open card(s)/PR(s) + 418 already-cached comment thread(s)); 1202 answered free from listings in hand, 3126 NOT ATTEMPTED at the 400-resolution budget (attempted down to #17440), 1 above #19473, the highest number this sweep saw.

• docs(adr-0087): state the npm level half of the launch-window exemption #18027 — HTTP 404, does not resolve; referred to by #9857, #12708
• [finding] The mandated Served-tier: top line puts a model identifier in a GitHub comment, which AGENTS.md forbids in terms — and it is the one part of the tier control the protocol already says is NOT a reading #18026 — HTTP 404, does not resolve; referred to by #9857
• [finding] Six retiredKey() tombstones tell authors a key "was removed in @objectstack/spec 18" — a version that does not exist; the package is 17.4.0 and these ship on the launch-window minor route, where npm major and protocol major decouple #18021 — HTTP 404, does not resolve; referred to by #9857, #18048
• spec/kernel: carve the package-registry persistence (sys_packages container + hydration) out of marketplace into an always-on core capability under its own name — the spec half of #17676 ruling A′ item 1 #18013 — HTTP 404, does not resolve; referred to by #9857
• feat(service-analytics)!: judge min / max against the aggregate x field-type table — all 74 refused pairs answer DATASET_INVALID at one compile door (#17560) #18011 — HTTP 404, does not resolve; referred to by #6023, #9857
• [finding] check-reference-carrier-shape reportedly has no holder rule for a JSON-Schema properties map and leaves any non-literal value unjudged — reported at tier, ⚠️ NOT verified (the seat's own re-measurement was void) #18009 — HTTP 404, does not resolve; referred to by #9857, #18065
• [finding] Concurrently dispatched subagents of one PM session share ONE flat scratchpad, so generic filenames (pr.json, card.json) collide — a reviewer's fetched PR payload was overwritten mid-review by a sibling round's fetch of a different PR #18008 — HTTP 404, does not resolve; referred to by #9857, #18065
• [finding] PackageInstallRequestSchema is a published, route-bound request contract that no layer parses — the install door is declared and enforced nowhere, while its sibling read doors are gated (ADR-0049) #18006 — HTTP 404, does not resolve; referred to by #9857, #18065
• [finding] ⏰ .changeset/plain-donkeys-repeat.md ships a compile-breaking change to two published response types as a bare minor — its own body says .manifest.version goes string → unknown, and it carries no BREAKING token and no ADR-0087 marker. Still unreleased. #18005 — HTTP 404, does not resolve; referred to by #9857, #18065
• docs(core): state the ADR-0053 D-D bound width in the filter-tokens header #18004 — HTTP 404, does not resolve; referred to by #6367, #9857
• [Decision] 两条裁决援引同一个 launch-window convention，却给出相反的 changeset 等级（minor vs major）—— 退役一个可写键到底发哪一级？ #18003 — HTTP 404, does not resolve; referred to by #9857
• [finding] warnEmailTemplateLocaleFloor has two silent early-returns that skip exactly the floorless bundles it exists to catch — a stack with no i18n block, and a bundle whose tags all fall outside supportedLocales #18002 — HTTP 404, does not resolve; referred to by #9857, #18065
• [finding] packages/spec states two different rung counts for email-template locale resolution — email-template.zod.ts publishes "the sole rung / no fallback floor at all" while contracts/email-service.ts documents a third rung the CI pins as reachable #18001 — HTTP 404, does not resolve; referred to by #9857, #18065
• docs(metadata-protocol): the repeated-parameter docblock stops calling its wording packages/rest's verbatim #17996 — HTTP 404, does not resolve; referred to by #6367, #9857
• test(platform-objects): widen app-nav translation parity to runtime-contributed nav ids #17980 — HTTP 404, does not resolve; referred to by #6367, #9857
• [finding] 落地的 ContainsAny 探测器对**联合类型的门**全盲 —— 它在联合上分配而求值为 boolean，于是回归时那条腿照常绿（含 #17876 自己的 findOne 腿） #17970 — HTTP 404, does not resolve; referred to by #9857, #18065
• 常设分诊指令 ④(决策箱依赖旗标)在当前工具面下不可穷尽测量 —— MCP search_issues 是纯语义通道,匹配不到 Blocked-by: 这样的字面串 #17968 — HTTP 404, does not resolve; referred to by #6015, #9857
• docs(drivers): measure the ContainsAny phantom-leg sweep across eight door pins #17967 — HTTP 404, does not resolve; referred to by #6367, #9857
• fix(driver-sql): attribute an unresolvable distinct() column to the clause the caller named #17945 — HTTP 404, does not resolve; referred to by #6367, #9857
• app-nav-translation-parity 的反方向断言只走静态声明 —— 贡献式导航条目在它眼里不存在,而天真地扩到 ACCOUNT_APP 会把一个正确的翻译键判成孤儿(从 #17891 拆出) #17930 — HTTP 404, does not resolve; referred to by #6367, #9857
• spec: ManifestSchema.id's .describe() says only "reverse domain style" while publish refuses anything off PackageSchema.manifestId's regex — the rule an author is held to never reaches the generated schema #17921 — HTTP 404, does not resolve; referred to by #9857
• spec: analyticsDateRangeRefusalMessage's array clause is false on the path PR #17593 opened — it says "a non-string bound" and "Refused at the schema" for ['2026-01-01'], where both are untrue #17918 — HTTP 404, does not resolve; referred to by #9857
• docs(cloud-connection): correct the vitest config's trailing effect claim #17907 — HTTP 404, does not resolve; referred to by #6367, #9857
• [finding] 「默认翻转」类别没有记录在案的声明 —— 三扇开退役窗口的缝只有一扇拒绝它,而存量行那扇有一个已测出前提为假的情形 #17901 — HTTP 404, does not resolve; referred to by #9857
• [finding] 两个机制对贡献式导航条目的缺翻译都结构性失明 —— check-app-nav-i18n 按 APP_NAME=setup 缩窄,parity 测试只走静态声明 #17891 — HTTP 404, does not resolve; referred to by #6024, #9857
• … 14 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 101 of 101 open pm:on-hold card(s); 9104 tracked file(s) in the oracle.) Read in /home/runner/work/objectstack/objectstack (origin https://github.com/objectstack-ai/objectstack).

• #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-plugin.ts, packages/plugins/plugin-sharing/src/sharing-service.ts
• #7401 — packages/plugins/plugin-security/src/security-plugin.ts
• #7881 — packages/plugins/plugin-auth/src/objectql-adapter.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
• #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
• #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
• #13776 — packages/rest/src/rest-route-ledger.ts, packages/runtime/src/route-ledger.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

Decision-box dependency flags (instruction ④)

Report-only and derived at READ TIME: a card below is an open needs-user-decision card that at least one OPEN card's Blocked-by: line names, and ⛔ no priority label is written for it. The standing instruction this discharges, verbatim: 「④(决策箱依赖旗标,2026-08-11 维护者裁决):每轮收尾简报的决策箱段须标注带有 open 下游依赖的决策卡(判据:任一 open 卡的 Blocked-by: 行指向它;读时派生,⛔ 不打优先级标签)。」 It is one lookup over the same reverse index H14 is judged against — no second channel and no second parser (#17968).

• #19376 — waited on by 1 open card(s): finding(spec): the RUNTIME filter door accepts a blank $between endpoint that the published endpoint contract now refuses — parseFilterAST disagrees with RANGE_ENDPOINT_DESCRIPTION #19071

1 of 6 open needs-user-decision card(s) have an open downstream dependent.

NOT MEASURED beside it: 6 open pm:blocked card(s) carry no machine-readable Blocked-by: line in EITHER channel — H4's own count, reused rather than re-derived. Whatever those cards wait on cannot appear above. ⛔ Cite BOTH numbers or write NOT MEASURED: the flag count alone is a number that ran, and therefore reads as complete.

Population scope: dependent BODIES are read from every open issue in this repo (the unscoped listing); dependent COMMENTS only from open pm:blocked / pm:blocking cards whose body carries no Blocked-by: line. A dependent that states the wait in a comment and carries neither label, and any dependent in a sibling repo, is outside this reading — unread, not absent.

Closed-card pm:* residue (H39 census, informational): pm:dispatched 2070, pm:queue 858, pm:blocking 40, pm:blocked 20, pm:on-hold 14, pm:awaiting-maintainer 3, oldest closed 2026-08-02; 555 carrying both pm:queue and pm:dispatched. H22's 3-day closure window, read separately, holds 4 of 352 closed card(s) still carrying residue (pm:dispatched 2, pm:awaiting-maintainer 1, 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 ~88.0/day against pinned MEASURED_MERGES_PER_DAY = 137.5/day, measured 2026-08-23 (29d ago) (factor 0.64, band 2x).

[huangyiirene]

⚠️ This body's heartbeat line now manufactures a FALSE 「the standing caller died」 — the schedule it advertises was retired by ruling, ⛔ and re-adding it is forbidden

domain:engine execution PM seat, session_01NcPSwnmJHczmTu6FG7NMjE, written 2026-09-21T12:55Z. ⛔ A pointer, not a card and not a gate — the filing gate's 「⛔ 不是卡:既有卡一条评论能承载的指针/知会/请求;那条评论即其记录」. This comment is that record.

What this body says, and why a reader believes it

Its subscript still reads, verbatim:

Swept 2026-09-21T02:02:57Z · expected every 6h (cron 37 1,7,13,19 * * *) · next by 2026-09-21T07:37Z …

and the paragraph under it tells the reader exactly how to use that:

The timestamp above is the patrol's own heartbeat, and the line states the cadence that makes 「stalled」 decidable: a Swept line still sitting there past the next by deadline beside it means the standing caller died, which is the failure this anchor was created to make visible.

At the time of writing, that deadline is ≈5 h 20 m past. ⇒ read as written, this anchor is asserting its own caller is dead.

It is not. The caller was RETIRED, and the primary source says so

.github/workflows/half-state-patrol.yml on origin/main, in its own on: block:

⛔ ON DEMAND ONLY — this workflow declares NO schedule, and re-adding one takes the maintainer's sentence, not a reading of the history above. Ruling #208 on objectstack#19491, executed by objectstack#19497 … The triage seat dispatches this workflow when it wants the board reconciled; nothing fires it by the clock.

Confirmed from three independent readings, ⛔ none of them this body:

reading	result
the workflow's on: block on origin/main	no schedule: — retired deliberately, with the ruling cited in-file
GET /actions/workflows/half-state-patrol.yml/runs?event=schedule	last scheduled run #282, 2026-09-21T01:56:25Z, success. ⭐ POSITIVE CONTROL: the seven before it are the four-a-day cadence exactly (09-19 07:42 · 13:40 · 19:41 · 09-20 01:53 · 07:42 · 13:40 · 19:40) ⇒ the stop is sharp and total, ⛔ not a flaky slot
#19497	closed/completed, landed 2026-09-21T06:09:05Z — after this body's last sweep, which is precisely why the body could not know
the dispatch charter	「半状态巡查按需跑…H 行是读数不是前提;⛔ 不因锚行停派发」 ⇒ the precondition the ruling deleted is in fact gone

⇒ ⭐ The three pull_request runs since (#283 05:04Z, #284 10:05Z, #285 10:11Z) all succeeded and all ran --dry-run, so they could not refresh this body either. A reader seeing 「success」 in the Actions tab and a stale Swept line here has two true facts and no way to join them.

Why this is worth a comment at all

⛔⛔ I was one step from firing the workflow to 「restore」 a cadence a maintainer ruling deliberately removed — and the workflow's own text forbids exactly that:

⛔ Do not re-add a schedule: block on the argument the history above makes ("an alarm nobody runs is silence"). That argument is answered, not forgotten … If a month passes with nobody dispatching this, the ruling is that the sweeper is deleted whole on its own card — ⛔ never quietly re-scheduled.

⇒ ⭐⭐ This is the exact defect class the instrument itself exists to name: a condition that cannot tell apart the two cases it is invoked to tell apart. 「The caller died」 and 「the caller was retired by ruling」 produce byte-identical evidence here, and the body only rewrites on a run — so on demand, the staleness is permanent and grows monotonically, and every seat that reads this anchor pays the same handling step. That is the cost ruling #208 measured and removed from the four-a-day path; this is the same cost arriving by the other door.

⛔ No remedy is prescribed here and no state is proposed. The body belongs to the workflow; a hand-edit would be overwritten by the next run and is not this seat's to make.

• Acting reader / step: domain:engine execution PM seat, at the 12:33Z patrol fire, deriving its lane's pm:on-hold release scan (H9). The scan is what brought me here; it is reported on my own round report and needs nothing from this card.
• Dedupe, run before writing: [Half-state patrol] check-half-states live sweep — generated view (please pin) #9857 — 0 comments, so 0 hits. ci(pm): retire the half-state patrol's schedule — on demand only; every scheduled invocation of the patrol action stops (ruling #208 on #19491) #19497 — 3 comments, 0 naming it. [Decision] 仪器与吞吐的取舍：哪些闸门该硬、达档复核保留到什么程度 #19491 — 6 comments, 2 mention the anchor and 0 name this; the nearer one (5755393331, 2026-09-21T04:27Z) still describes the body as 「regenerated in place every 6h」, which was true when written and went false 1 h 42 m later. ⛔ /search/* is denied by the egress proxy from this seat, so this is a thread-by-thread dedupe over the three cards that could carry it, ⛔ not a board-wide one.
• Whose it is: the workflow is domain:skills (ci(pm): retire the half-state patrol's schedule — on demand only; every scheduled invocation of the patrol action stops (ruling #208 on #19491) #19497); the dispatching caller is the triage seat. ⛔ Not mine to change, and ⛔ ⛔ not a card — a report-only instrument's own prose going stale is an instrument observation, which the filing gate keeps out of the queue by name.

---

Generated by Claude Code