[finding] Census of all 47 `pm:blocked` cards: 32 park `Blocked-by:` outside the body (invisible to the unlock scan), 16 wait on already-closed upstreams, 7 name no blocker at all

[os-sam]

Filed unassigned, observation-class, awaiting first grading. Suggested lane for triage: domain:skills (this is protocol machinery, and #8941 — the card that first recorded the blind spot measured here — sits there). Not self-labelled: domain:* is the triage seat's to produce.

Provenance: maintainer, 2026-08-24, live PM chat, verbatim: 「跑一遍并把结果落成卡」 — instructing that the reverse-index reconciliation offered in that chat be run in full and recorded as a card. PM session session_01FfmmQb8d7McMLXnzbor3UX.

This card is the measurement, not a re-statement of the problem. #8941 already records that the unlock scan greps issue bodies only while seats park Blocked-by: in comments. Nothing here re-opens that; what was missing was the population, and the population turns out to carry three separate defects, only one of which #8941 names.

Method

Snapshot 2026-08-24 ~14:00–15:00Z, objectstack + objectui (the two repos reachable from this session).

1. Every open issue labelled pm:blocked in both repos — 33 + 14 = 47.
2. For each: issue body read in full, matched against ^\s*(?:[-*>]\s*)?\**?Blocked-by:??\**\s*(.+)$ (deliberately looser than the production predicate, so that a body counted as "has a line" is a superset of what any body-grep scan could find).
3. For every card with no body line: the latest comment read (the protocol's authoritative "最近一次转换评论").
4. Every named upstream resolved to open/closed by set-difference against the full open-issue number set of its repo.
5. Every closed upstream then tested against state:CLOSED since:2026-08-24T00:00:00Z to separate "closed today, next sweep will catch it" from "closed on an earlier day and the card is still parked".

Result 1 — where the Blocked-by: line actually lives

channel	cards	share
body (the only channel the unlock scan greps)	15	32%
comment only — legal under the dual-channel contract, invisible to the scan	24	51%
no machine-readable line found (body + latest comment)	7	15%
self-closed mid-census (#9652)	1	2%

So two out of three parked cards cannot be discharged by a body-grep scan, and the comment channel is not a rare accident — it is the majority spelling, produced by the triage seat's own routing comments (Triage: … pm:blocked / Blocked-by: in the same comment) and by PM state-transition comments.

Result 2 — a second, independent hazard: the line's spelling varies

Even a scan that read comments would miss part of the population, because the marker is written at least four ways in live cards:

spelling	example
Blocked-by: #N	#11333, #9592 (body)
`Blocked-by:` #N (backticked key)	#11668, #11611, #11187, #11225
**Blocked-by: #N** (bolded)	#11423, #11410
Blocked-by: <owner/repo>#N with a trailing stray backtick	#11617

The strict ^Blocked-by: predicate the skill mandates matches only the first. Widening the scan to comments without also settling the spelling would move the blind spot rather than close it.

Result 3 — 16 cards are parked on upstreams that are already closed

Genuinely overdue (upstream closed on an earlier day; the card has not been re-queued):

card	upstream	channel	note
#9592	#9255 (closed 2026-08-19T11:28Z)	body	5 days parked with a body-visible line — a body-grep scan should have caught this one and did not
#11187	#11082	comment
objectui#5831	#11166	body
objectui#3906	objectui#3789	body

Three of the four carry a body line, so this is not only #8941's comment-channel gap: the scan is also not discharging what it can already see. That is a separate defect and worth its own diagnosis.

Closed today — legitimately awaiting the next sweep, listed so nobody re-derives them:

upstream (closed 2026-08-24)	cards still parked on it
#9689	#11668 · #11423 · #11410 · #9784
#10812	#11333 · #11332 · #11331 · #11330
#11485	#11617
#11303	#11611
#11513	objectui#5987
objectui#5930	objectui#5931

Result 4 — 7 cards name no blocker anywhere the census could see

#10726 · #10692 · objectui#5521 · objectui#5493 · objectui#5453 · objectui#4356 · objectui#3719

A pm:blocked card with no machine-readable upstream is a state nothing can ever leave — strictly worse than the comment-channel case, because there is no line to find. objectui#3719 is the proof that this is not self-healing: the unlock scan itself recorded the exact diagnosis on that card on 2026-08-19, asked the owning seat to add a line or swap the label back, and the card is unchanged five days later. Two of the seven (objectui#5453, objectui#4356) carry a triage comment that says in so many words pm:blocked untouched — i.e. the lane was set by a seat that never wrote the blocker down.

Limit on this row: body + latest comment were read. A line sitting in an older comment would be missed here — which does not change the operational verdict (a scan reading the latest transition comment would miss it too), but does mean "no blocker exists" is not proven for these six.

What this suggests (for the grader, not decided here)

1. The cheap half is the spelling, not the channel: pin one canonical marker and make the mis-spellings a gate error, or widen the predicate to the four live forms. Either is mechanical.
2. Widening the scan to the comment channel is what [finding] the pm:blocked unlock scan greps issue BODIES only, while seats deliberately park Blocked-by: lines in COMMENTS — blocked cards go invisible and sat 24h+ past discharged upstreams #8941 already asks for; this census gives it a denominator (24 cards today).
3. The four overdue cards are lane work available immediately: tooling: check-adr-anchors should verify that a cited ADR-NNNN Dk decision letter is a real heading of the cited ADR #9592 (domain:devx), [finding] Publish-time lint for a chained controlled_by_parent declaration (direction 3 of #11082) — and its value CHANGED once direction 1 was implemented #11187 (domain:services), objectui#5831 and objectui#3906 (objectui lanes).
4. The 7 blocker-less cards need their owning seats to either write the line or return the card to pm:queue. A report-only half-state patrol row ("pm:blocked with no resolvable Blocked-by: in body or comments") would make this class visible without a new label.
5. Worth noting as the counter-example: [finding] AGGREGATION_ROWS has no boolean column, so the cross-driver aggregation conformance family cannot see a boolean aggregand on any face #11152's seat found its upstream ([Decision] min/max over a boolean aggregand: pin the cross-driver JSON answer — 0/1 (SQL) vs false/true (both in-memory faces) #11249) closed, and rewrote the Blocked-by: to the new real blocker (driver-sql: boolean aggregands need a lowering cast on PG (+ a MySQL min/max presentation check) — the ruled false/true + arithmetic answers are unproducible on the PG face #11635) instead of discharging the card. That is the behaviour the mechanism should make cheap.

Scope limits

• cloud and hotcrm are not reachable from this session, so cards parked on cloud#1509 ([seam] Ruling clause 2 of #11184 (walled + invite-only ⇒ no self-registrant auto-joins the Default Organization) is unverified in the enterprise organizations package #11225) and cloud#944 (CLI: retire the flat fail() accommodation in readErrorMessage once the control plane finishes converting (cloud#944) #10938) are recorded as unresolved rather than judged. Both repos have their own pm:blocked inventories that this census does not cover.
• Both repos are being written continuously; Every better-auth-native /admin/ route refuses ObjectStack platform admins — the vendor gates on the legacy user.role === 'admin' scalar ADR-0068 D2 stopped synthesizing #9652 closed itself between the inventory read and the comment read, and pm:dispatched totals moved by one during the run. Counts are a snapshot, not a ledger.
• Raw per-card table (47 rows: card · blocker · channel · upstream state) is reproducible from the method above; every row was read individually, none inferred from titles.

Refs: #8941 (the blind spot this measures) · objectui#3719 (the scan's own 2026-08-19 diagnosis of the blocker-less class) · #11152 (the rewrite-the-blocker counter-example)

[os-zhuang]

Triage — graded into the skills lane as the unlock-scan overhaul CHARTER (skills seat, session 5213b871-5164-5bc3-8874-28b336bbcd40, self-triaged under the skills-lane exception; the census was maintainer-instructed 「跑一遍并把结果落成卡」 and the maintainer relayed it to this seat for root-cause handling in the same chat). Labels: domain:skills + pm:queue.

Scope for the claiming seat — five deliverables, the census's own suggestions adopted with two rulings:

1. Spelling first, channel second (the census's key insight — widening the channel without settling the spelling moves the blind spot): pin ONE canonical marker (Blocked-by: #N / full-name form for cross-repo, line-start, no decoration) AND widen the production predicate to accept the four live forms during a migration window; a patrol row flags non-canonical spellings so they migrate rather than accrete.
2. Dual-channel scan — body remains the SINGLE canonical home (the platform-readings doctrine row stands), but the scan READS both channels and treats a comment-channel hit as "line exists, home is wrong: migrate it to the body", not as a discharge source. This subsumes [finding] the pm:blocked unlock scan greps issue BODIES only, while seats deliberately park Blocked-by: lines in COMMENTS — blocked cards go invisible and sat 24h+ past discharged upstreams #8941's ask — that tracking card folds into this charter at claim (five-gate: same mechanism, same file surface, its ask is a strict subset).
3. Diagnose the second defect separately: tooling: check-adr-anchors should verify that a cited ADR-NNNN Dk decision letter is a real heading of the cited ADR #9592 carried a body-visible, strict-spelling line for 5 days and was not discharged — so the scan fails even inside its declared coverage. Whoever claims this must find out WHY (scan not running? predicate subtly failing? repo filter?) before building anything on top; a mechanism repaired without this diagnosis may inherit the same silent failure.
4. Report-only patrol row: pm:blocked with no resolvable Blocked-by: in body or any comment ⇒ flagged with the owning lane named (the objectui#3719 class — a state nothing can legally leave). Rides the same patrol extension finding(pm): pm:queue 半态「已判未转」——两条可机判的 H 规则,加 #11086 的一条输入 #11179 charters; the claiming seat answers fold-or-serial for [finding] Census of all 47 pm:blocked cards: 32 park Blocked-by: outside the body (invisible to the unlock scan), 16 wait on already-closed upstreams, 7 name no blocker at all #11747+finding(pm): pm:queue 半态「已判未转」——两条可机判的 H 规则,加 #11086 的一条输入 #11179 at claim time (likely fold: one patrol PR, two rule families, each with named acceptance).
5. The [finding] AGGREGATION_ROWS has no boolean column, so the cross-driver aggregation conformance family cannot see a boolean aggregand on any face #11152 exemplar becomes doctrine: on discovering a closed upstream, the seat re-derives whether a NEW blocker exists and rewrites the line rather than reflexively discharging — one sentence in the state-machine reference.

Board actions taken NOW by this seat (not waiting for the mechanism): the four genuinely-overdue cards are being released this hour (#9592, #11187, objectui#5831, objectui#3906 — each with a claim-time re-verify note); objectui#3719 is returned to pm:queue per the scan's own 2026-08-19 request, unanswered for 5 days; objectui#4356's blocker (objectstack#7917, per the 2026-08-19 backfill recorded on #7917) is being re-written in canonical spelling where a scan can see it. The 12 closed-today rows are left for the normal sweep, as the census intends. The 2 cloud/hotcrm-parked cards stay recorded-unresolved.

Also noting for the record what the maintainer's census corrected: this seat's earlier pm:blocking sweep cleaned the derived cache that EXISTED, but the cache is starved at the source — 47 blocked cards point at ~30 upstreams and only 3 carried the label, because the derivation greps an index that is 68% invisible or absent. The root cause is this card's, not the sweep's.

---

Generated by Claude Code

[os-zhuang]

Claim: skills seat dispatch (session session_01RMTpSRF5CjMmQBFfPtPCwJ), wave following the #11744/#11748/#11749 landings.

• Branch: claude/issue-11747-unlock-scan-overhaul
• Worktree: objectstack-11747-unlock-scan
• Fold-or-serial for [finding] Census of all 47 pm:blocked cards: 32 park Blocked-by: outside the body (invisible to the unlock scan), 16 wait on already-closed upstreams, 7 name no blocker at all #11747+finding(pm): pm:queue 半态「已判未转」——两条可机判的 H 规则,加 #11086 的一条输入 #11179: FOLD, answering the charter's own deliverable 4 — one patrol PR, two rule families (unlock-scan overhaul here; finding(pm): pm:queue 半态「已判未转」——两条可机判的 H 规则,加 #11086 的一条输入 #11179's half-state H-rules), each with its own named acceptance criteria in the PR body. finding(pm): pm:queue 半态「已判未转」——两条可机判的 H 规则,加 #11086 的一条输入 #11179 carries a twin claim comment this stroke. [finding] the pm:blocked unlock scan greps issue BODIES only, while seats deliberately park Blocked-by: lines in COMMENTS — blocked cards go invisible and sat 24h+ past discharged upstreams #8941 is subsumed (five-gate: same mechanism, same file surface, strict subset) — noted there, it closes when this lands.
• File surface: the unlock-scan/patrol scripts under scripts/pm/**, .claude/skills/pm-dispatch/references/state-machine.md (canonical-spelling ruling, the [finding] AGGREGATION_ROWS has no boolean column, so the cross-driver aggregation conformance family cannot see a boolean aggregand on any face #11152 exemplar sentence, H-rules rows), SKILL.md's unlock section if the charter's ruling 1 requires it — ratchet table entries data-only, ceilings raised only with the arithmetic argued in the PR body. Stop on breach; widenings come back as report, never silent riders.
• Governed face (.claude/** + scripts/pm/** patrol tooling): draft PR + human merge (PD feat: Comprehensive CRM example demonstrating all ObjectStack protocol features #14). Clause-②: no — internal protocol tooling, no published package face.
• Sequencing: [finding] The pm-skill ratchet counts LINES while its header prices a per-session token read — a green 134/134 run grew platform-readings.md ~33% in bytes #11106's ruled legacy re-wrap is SERIAL BEHIND this PR (its sweep touches the same reference files); [finding] H19 cannot resolve a cross-repo Blocked-by: target — the exact shape contract-first dispatch produces, and its UNJUDGED row reads like a clean one #11218/[finding] Blocked-by: can only name an issue, but the two conditions cards actually wait on are "a PR merges" and "a release lands and the pin covers it" — measured on both #11220 stay queued behind — their premise is re-verified against the overhauled scan at their claim time (the overhaul may resolve either outright).
• Charter order honored: deliverable 3 (the tooling: check-adr-anchors should verify that a cited ADR-NNNN Dk decision letter is a real heading of the cited ADR #9592 second-defect diagnosis) runs FIRST — no mechanism is built until the why-did-the-scan-miss-a-body-visible-line question has a measured answer.

---

Generated by Claude Code

[claude]

{
 "issue": 11747,
 "status": "needs_decision",
 "branch": "claude/issue-11747-unlock-scan-overhaul",
 "pr": null,
 "premise_still_valid": false,
 "summary": "Charter deliverable 3 ran first, as ordered, and its measured answer invalidates the charter's assumed mechanism, so nothing was built (the dispatch's own STOP clause). THE SCAN DID NOT MISS #9592. Label timeline (REST /issues/9592/timeline): pm:blocked applied 2026-08-18T12:29:44Z; blocker #9255 closed 2026-08-19T11:28:26Z; pm:blocked REMOVED and pm:queue applied 2026-08-19T15:17:43Z by the unlock scan itself (its comment 5382... is titled 'Unlock scan (triage seat, round of ~14:47Z fire)') — a 3h49m discharge, not 5 days. The card was RE-PARKED 2026-08-24T01:18:02Z by the triage seat, which carded the real prerequisite as #11501 and wrote `Blocked-by:` #11501 into a comment while leaving the stale body line `Blocked-by: #9255` in place. At the census's 14:00-15:00Z read the park was 13h old; '5 days' is the upstream's close date used as a proxy for park duration, and the timeline refutes it. Three further census claims are false against origin/main (c4db3116): (R1) the scan is not body-only — H4/H14/H19 union body + ALL comments (since PR #10075/#10403) and the live anchor #9857 prints 'read from body OR comment' on every H19 row; (R2) the predicate is not strict-plain-only — 3 of the census's 4 spellings parse today (plain, backticked key, whole-directive backticked incl. cross-repo), and the 4th (#11423) is invisible not for its bolding but because it is a MID-SENTENCE prose mention — the same bold at line start parses fine, and widening to the prose form would turn narration into machine state, which the reader deliberately refuses; (R4) #10726, listed as 'names no blocker anywhere', carries a canonical `Blocked-by: #10812` in a NON-LATEST comment since 2026-08-23T14:37:09Z and appears in the live patrol's H19 rows — i.e. the census's own method (body + LATEST comment) is NARROWER than the shipped scan it was measuring. Deliverable 4's 'report-only row for a pm:blocked card with no resolvable Blocked-by' is already shipped as H4 (+H19's unresolved branch), and #8941's ask is already satisfied on main rather than subsumed by a future PR. THE REAL DEFECT RUNS THE OPPOSITE WAY — stale-body-line shadowing: `needsBlockedByComments()` returns false whenever the body carries ANY Blocked-by line, so on a re-park that writes the new blocker into a comment, H19 resolves only the stale body target, finds it closed, and publishes 'the block has outlived its blocker' — a FALSE unlock candidate. Reproduced on #9592's recorded bytes with the shipped predicates: gated (as swept) => '1 of 1 target CLOSED'; ungated => '1 of 2 ... PARTIAL'. The patrol published that false candidate on three successful runs (2026-08-24 02:10/07:59/13:56Z). ⚠️ LIVE BOARD DEFECT, still standing as of this report: #9592 was released to pm:queue at 2026-08-24T15:13:46Z on the census's premise and is dispatchable RIGHT NOW while its real blocker #11501 is OPEN and pm:dispatched, and its body still names the closed #9255 — a dev dispatched onto it walks into exactly the unmet prerequisite that carding #11501 existed to prevent. Re-parking it (with the blocker in the BODY, the canonical home) is a board write owned by the PM seat that made the release, not mine.",
 "tests": "No source file was edited; branch head = origin/main c4db3116, so there is no diff to gate. (1) Shipped-predicate reproduction, offline, over the real bytes of the census's exemplar cards: `node /tmp/.../issue-11747/repro.mjs` importing hasBlockedByLine/directiveValues/blockedByTargets/commentBlockedByTargets/needsBlockedByComments/blockerTargetsFor/h19BlockOutlivedBlocker/h4BlockedNoBlockedBy from scripts/pm/check-half-states.mjs; exit captured with no pipe: EXIT=0. Verbatim rows: 'Blocked-by: #10812' => hasBlockedByLine true, targets [{repo:null,number:10812}]; '`Blocked-by:` #11501' => true, [11501]; '`Blocked-by: objectstack-ai/objectstack#11485`' => true, [{repo:'objectstack-ai/objectstack',number:11485}]; 'PM hold (...): ... **Blocked-by: #9689**.' => FALSE, [] (mid-sentence prose); '**Blocked-by: #9689**' at line start => true, [9689]. #9592 leg: needsBlockedByComments() => false; targets AS SWEPT => [#9255] vs targets if comments read => [#9255,#11501]; H19 AS SWEPT => '`pm:blocked` while 1 of 1 `Blocked-by:` target(s) - read from body OR comment - is CLOSED (`#9255` (closed 2026-08-19T11:28:26Z)): the block has outlived its blocker'; H19 if ungated => '1 of 2 ... PARTIAL'; H4 AS SWEPT => null (line exists). (2) Shipped self-test, under the shared lock: `bash scripts/pm/os-verify-lock.sh -c 'node scripts/pm/check-half-states.mjs --self-test'` => its own verdict lines '✓ check-half-states self-test: 1058 cases pass.' and 'os-verify-lock: VERDICT command-exit 0 · held the lock 0s · waited 100s (1m40s)'; EXIT captured after redirect = 0. (3) Live-board evidence, read-only via REST: /issues/9592/timeline (label events quoted in summary), /issues/9255 (closed 2026-08-19T11:28:26Z), /issues/11501 (OPEN, pm:dispatched), /issues/10726 + its comments (canonical line in a non-latest comment), /issues/11082 (closed 2026-08-23 - so #11187's release was substantively sound even though its stated spelling rationale is not), anchor issue #9857 body (swept 2026-08-24T19:49:54Z, 239 half-states, 'Blocker liveness (H19): targets resolved on 23 of 25 distinct targets'), and the half-state-patrol.yml run list (2026-08-24 02:10:10Z / 07:59:11Z / 13:56:54Z, all schedule/completed/success). No ablation was run: nothing was mutated, so there is no mutation to confirm on disk and no rebuild leg to report.",
 "gates": "`node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack` (no path args), exit captured directly = 2, its own lines: \"gate list derived from the tree of 'objectstack-ai/objectstack' at commit c4db3116\" / \"--repo 'objectstack-ai/objectstack' checked against this checkout's 'origin' remote - it holds.\" / \"this branch changes nothing against 'origin/main' (merge base c4db31161) - nothing to derive.\" No gate family is owed because no file was edited. The one gate exercised anyway is the patrol's own: check:pm-half-states => '1058 cases pass'.",
 "deviations": "No PR was opened. This is the dispatch's own instruction ('If the diagnosis invalidates the charter's assumed mechanism, STOP and report needs_decision instead of building on sand'), taken literally: charter rulings 2 and 3 are the sand - ruling 3 is already shipped, and ruling 2 as written would widen the predicate onto a prose mention. The #11179 family was NOT landed either, because the fold put it in this PR and this PR does not exist; it does not rest on the invalidated premise and should be re-dispatched standalone (open question 4). The branch `claude/issue-11747-unlock-scan-overhaul` was pushed empty (the first-minute write-route probe) and is left in place, zero commits ahead of origin/main, so a re-charter can reuse it; the worktree is removed. No board write, no label write, no comment on #9592, #11179, #8941 or any card other than this report on #11747.",
 "open_questions": [
 {
 "question": "The measured defect: `needsBlockedByComments()` skips the comment channel whenever the body carries any Blocked-by line, so a re-park that parks the NEW blocker in a comment leaves H19 resolving only the stale body target and publishing a false unlock candidate (#9592, three sweeps, acted on). What is the fix?",
 "options": [
 "A. Ungate the comment fetch for the blocker-LIVENESS read only (H19/H26), keeping H4's gate as-is: cost is one extra comment fetch per pm:blocked card that HAS a body line (15 of 33 candidates in the 2026-08-24 sweep - the gate's own complement), bounded and paid once per sweep; plus a patrol row 'body line names a CLOSED target while a comment names an OPEN one => the body line is stale, migrate it' so the canonical-home doctrine is enforced rather than assumed.",
 "B. Ungate entirely (H4 + H19 + the H14 index all read both channels unconditionally): simplest predicate story, no gate to reason about, ~33 extra fetches per sweep today and growing with the blocked inventory.",
 "C. Keep the gate and fix it in the protocol instead: rule that a re-park MUST rewrite the body line (body = single canonical home), and let H4/H19 keep the cheap read. Zero code change, but the failure mode stays silent when a seat does not comply - which is exactly the class this repo keeps re-learning is not closable by prose.",
 "D. Do nothing mechanical; treat #9592 as a one-off."
 ],
 "recommendation": "A. Real business need: the harm is measured, not speculative - a false unlock candidate was published three times and a card was released into an open blocker today; the population that can hit it is every re-park, which is the normal shape of the #11152 doctrine the charter itself wants to encourage. Long-term soundness for THIS project: it removes an asymmetry the code already documents as a known bound ('a bound inherited from the gate, not a decision taken here') rather than adding a new concept, and it keeps H4's cheap question cheap - contract-first, no consumer-side tolerance. Making AI-written work hard to get wrong: the paired patrol row makes the stale body line VISIBLE at the moment it is created, so the canonical-home rule is enforced by a machine at write time instead of trusting a seat to remember it mid-re-park - the exact 'declared = enforced' move, and the reason C is rejected (prose is what just failed). Startup scope discipline: A is the smallest change that closes the measured class - it adds no label, no new state, no new file, and its request cost is bounded by an inventory the sweep already pages; B buys nothing A does not for double the cost, D leaves a live false-candidate generator running."
 },
 {
 "question": "Charter ruling 2 said 'pin ONE canonical marker AND widen the production predicate to accept the four live spellings'. Three of the four already parse, and the fourth is a mid-sentence prose mention. What survives of the ruling?",
 "options": [
 "A. Keep the canonical marker exactly as the charter pins it (line-start `Blocked-by: #N` / `owner/repo#N`, no decoration), DROP the widening as already-done-or-harmful, and record the measurement in references/state-machine.md so the next census does not re-derive it. Optionally add a report-only row flagging non-canonical-but-parsed spellings for migration - note the population is nearly the whole live board, so this row is loud by construction.",
 "B. Widen the predicate to catch mid-sentence mentions too (the literal charter text). This makes every seat's narration ('the stated `Blocked-by: #9255` is discharged' - #9592's own 08-20 and 08-23 comments) into a machine blocker; on #9592 alone it would have manufactured two phantom targets.",
 "C. Go the other way: tighten to line-start-plain-only and make the decorated forms a patrol finding, forcing migration to one spelling."
 ],
 "recommendation": "A. Real business need: the widening was chartered to close a blind spot that measurement says is not there; the only true negative is a case where firing would be wrong. Long-term soundness: the line-anchor + decoration-tolerance split the reader already implements is the correct contract boundary (a directive is a line, a mention is prose), and B would delete it. Making AI-written work hard to get wrong: B is the classic consumer-side tolerance that lets a generated narration silently become state - it is the single most dangerous option on the table. Startup scope discipline: A is doc-only; C is a real migration cost (nearly every live card) bought for a cosmetic uniformity nothing currently needs, so it should not be spent now."
 },
 {
 "question": "Board repair: #9592 is pm:queue and dispatchable while #11501 (its real blocker, carded 2026-08-24T01:18Z) is OPEN and pm:dispatched, and its body still names the closed #9255. objectui#5831 and objectui#3906 were released in the same stroke on the same premise and are outside this session's reach.",
 "options": [
 "A. PM re-parks #9592 now: pm:queue -> pm:blocked, and REWRITES the body line to `Blocked-by: #11501` (canonical home), leaving the comment line as history - this also clears the shadowing input for the next sweep.",
 "B. Leave it queued and let the claiming dev re-verify the premise (os-dev rule 6) - relies on every claimer paying the full read that carding #11501 existed to stop re-charging.",
 "C. Re-park but leave the stale body line, per the current dual-channel contract."
 ],
 "recommendation": "A, and re-verify objectui#5831 / objectui#3906 against their own label timelines before trusting either release - both were justified by the same 'upstream closed on an earlier day' proxy that the #9592 timeline just falsified. C is rejected because the stale body line is the shadowing input itself. This is a board write owned by the seat that made the release; I did not touch it."
 },
 {
 "question": "The fold. #11179's family does not rest on the invalidated premise, but part of it is already shipped: assigned-⊕-pm:queue is H24, queue+dispatched is H3, and pm-state exclusivity is enforced ONLY for the pm:awaiting-maintainer carrier (H25) - so the genuinely unlanded rules are the GENERAL pm-state ONE-OF (covering pm:queue x needs-user-decision and pm:queue x pm:blocked), the pm:queue rot row, the freshness warning (conclusion comment older than the body's last edit), the contract-review paired-carrier row, and H14's strip-when-empty direction.",
 "options": [
 "A. Unfold: re-dispatch #11179 standalone against the corrected inventory above (which of its six proposed rules are new), while #11747 is re-chartered from this diagnosis.",
 "B. Keep the fold and re-charter both together as one PR.",
 "C. Fold #11179's rules into whatever #11747 becomes after the re-ruling."
 ],
 "recommendation": "A. The fold's only rationale was one file surface; with #11747 un-chartered, holding #11179 behind it delays six machine-judgeable rules for a decision they do not depend on. Also note #8941 can close on its own now - H4 has read both channels since PR #10075 and its header names #8941 as the ask it discharges - rather than waiting to be subsumed by a PR that will not exist in that shape."
 }
 ],
 "out_of_scope_findings": [
 "None filed as new issues. The one defect discovered (stale-body-line shadowing in needsBlockedByComments) is squarely INSIDE this card's deliverable 3, so it belongs to #11747's re-charter rather than a second card; filing it separately would split one decision across two cards. Searched first (open issues, keywords needsBlockedByComments / comment channel / H19 stale / shadowing, plus scripts/pm/check-half-states.mjs as a path) - nothing open covers it. The live board state of #9592 is reported above rather than filed: it is a board write owned by the PM seat that made it, and correcting another actor's state write is not this seat's to do."
 ]
}

---

Generated by Claude Code