[finding] The unlock scan's enumeration reports completion over a list it did not finish reading — perPage 50 against 51 blocked cards, and the output cannot tell the two apart

[huangyiirene]

Filed unassigned by the triage seat, session session_01Aujz2zykf5LXt3T98gRsGe. ⛔ Not claimed, not graded.

⚠️ This card was filed with the wrong claim and has been rewritten down. Read this section first.

As originally filed, this card claimed the unlock scan's body-only Blocked-by: read was a defect, and proposed that the scan read comments as well. That claim is retracted. Two things were missed at filing:

1. [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 exists and is the same card — "the pm:blocked unlock scan greps issue BODIES only, while seats deliberately park Blocked-by: lines in COMMENTS" — filed 2026-08-16, closed completed 2026-08-24.

2. It was resolved the other way, and the ruling is in .claude/skills/pm-dispatch/references/platform-readings.md:

   Blocked-by: 行归 BODY(单通道反向索引):追加按上条「解码后写回」执行;历史上寄放在评论里的行按同程序增量回填(⛔ 不搞批量突击 —— 限流压力);解锁扫描只 grep body,⛔ 不加常设评论读;旧「连评论一起扫(in:comments)」提示作废。

⇒ The body-only read is correct. The proposed "read comments too" fix is the rejected direction. The 69% of blocked cards without a body-level line is outstanding incremental backfill, deliberately not done as a batch — expected progress, not a defect.

⛔ Also retracted: the argument that a well-reasoned comment placement means the scan should follow it. That argument was considered by #8941 and decided against.

What survives is one defect that #8941 does not cover, and it is the whole of this card now.

---

The defect: an enumeration that cannot say it was truncated

The unlock scan enumerates open pm:blocked cards and reads their blockers. On 2026-08-27 it ran with:

list_issues(state=OPEN, labels=[pm:blocked], perPage=50, ...)
  -> issues: 50 returned
  -> totalCount: 51

One card was never examined. Nothing in the scan's own output distinguishes "read all 51" from "read 50 of 51" — the caller sees a list and proceeds. It was caught only because the count mismatch happened to be noticed by hand.

The missed card was #9709. Reading it produced a real finding: its body stated "blocked until PR #9706 lands", and PR #9706 merged 2026-08-19, nine days earlier. Its live blocker is the still-open epic #9465 — a different card the body never named in a machine-readable field.

⛔ Note carefully: nothing was lost. #9709 was still blocked, on the fence, so the discharged blocker would not have released it. The defect is not the outcome — it is that a scan reported completion over a list it had not finished reading, and no reader could have told.

Why this is the same class as #12411 / #12815

Those two cards are about dispatch-gates rendering "staleness could not be measured" identically to "this tree is current". This is the same collapse in a different instrument: an incomplete reading and a complete reading print the same thing. #12411 landed the fix for one half of its case (PR #12816); #12815 holds the other half. This card is that shape in the triage seat's own enumeration.

Shape of the fix — constraints, not a design

• Compare the returned count against totalCount on every enumeration, and say so when they differ. Proceeding silently is the defect; paginating is only half the answer, because the next list that outgrows the page size reintroduces it.
• A truncated read must not be reportable as a clean scan. Same standard check-governed-merges.mjs already applies to unaudited repos: "nothing was found there because nothing was looked at." That script prints ⛔ sweep INCOMPLETE and refuses to read as clean; the unlock scan has no equivalent.
• Prefer one predicate over a second code path, for the reason dispatch-gates: baseDrift can resolve the base ref and STILL fail to read the distance — that second unmeasured state is printed as nothing #12815 gives on its own file: a second hand-written branch is a second thing to keep in sync.
• ⛔ Not proposed: any change to where Blocked-by: lives, or to the body-only read. That is settled by [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 and is not reopened here.

Backfill progress, recorded as a reading rather than a claim

Since the ruling's incremental backfill has no progress meter, this is one, measured 2026-08-27 across both authorized repos:

repo	open pm:blocked	body-level Blocked-by:	outstanding
objectstack	50	19	31
objectui	38	8	30
total	88	27 (31%)	61 (69%)

Control run: a loose /Blocked[-\s]?by/i sweep found exactly one card matching loosely but not strictly (#6182), and it is a negation in prose ("is not blocked by this"), not a missed blocker ⇒ the strict extractor does not under-match on the bodies it reads.

⚠️ Two increments have since been performed by this seat, so the number above is already stale by two: #9709 (Blocked-by: #9465, backfilled 2026-08-28 with byte-level read-back) and #8103 (Blocked-by: #12804 — pending; deferred deliberately, see below).

One measured caveat for whoever does the next increment

The decode-then-write-back round trip was validated on #9709 and preserved everything checked — <-- inside a code fence, every escaped apostrophe, both code fences — except the trailing _Generated by [Claude Code]_ attribution footer, which was stripped. Bodies carrying that footer lose it on a backfill. Bodies without one (#8103 among them) are unaffected.

⛔ #8103's backfill was deliberately deferred one round rather than done opportunistically: it is a maintainer-ruled destructive sweep over a secrets table, its body carries the safety constraints on that deletion, and a full-body rewrite means retyping them. The procedure was proven on a low-stakes card first. That is the intended reading of "⛔ 不搞批量突击".

Duplicate check

#8941 is the parent of the retracted half and is closed; this card is deliberately not a duplicate of it after the rewrite — the enumeration-completeness defect is not mentioned there. Nearest live neighbours: #12813 (the ⑦ reader-count method, also a seat-procedure finding, also domain:skills) and #12815 (the same collapse class in dispatch-gates).

[huangyiirene]

Calibration control: which inline-backtick <…> shapes survive the MCP read path

Triage seat, session session_01Aujz2zykf5LXt3T98gRsGe. ⛔ Not a grading change to this card — a deliberate instrument control, posted here because this card is about instruments that cannot say what they failed to read.

Why: platform-readings.md records that the MCP read path eats inline-backtick angle-bracket fragments, and that this makes read-then-write-back a permanent storage loss. It does not say which fragments. Two accidental samples from this session's own authored text disagreed with each other — `git -C <path>` came back with <path> gone, while `<…>` came back merely escaped. n=2 is a hypothesis, not a rule. This is the control.

Each row below is authored deliberately. Whatever comes back on read-back is the measurement.

#	authored inside backticks	first char after <
1	<path>	letter (lower)
2	<Name>	letter (upper)
3	<script>	letter — the documented trigger word
4	<10 files>	digit
5	<…>	ellipsis
6	<-- unguarded	hyphen
7	<_under>	underscore
8	<owner/repo>#N	letter
9	< spaced>	space
10	a < b && c > d	space (comparison, not tag-shaped)

Same ten shapes outside backticks, as the paired arm — if these behave differently, the "inline backtick" part of the recorded rule is load-bearing; if identically, it is not:

1. <path> → written here escaped deliberately; the raw arm follows
4. <10 files>
5. <…>
6. <-- unguarded
7. <owner/repo>#N

Negative control: zzz_no_angle_bracket_here_xyz — must come back intact; if it does not, the whole experiment is invalid rather than informative.

Positive control that the comment stored at all: this sentence contains the token CALIB-MARKER-8117 and read-back must find it.

⚠️ What this control cannot establish: whether the storage bytes are intact. raw REST is 403 for this session (positive control: api.github.com/ → 200), so only the read path is observable. A fragment absent on read-back is therefore either eaten-on-read with storage intact (what the recorded reading claims) or never stored. ⛔ The two are indistinguishable from here, and the safe handling is identical: never write back a body containing a shape this control shows as absent.

Result will be appended as a reply to this comment.

---

Generated by Claude Code

[huangyiirene]

Calibration result — and the control destroyed itself, which is the most useful thing it did

Triage seat, session session_01Aujz2zykf5LXt3T98gRsGe. Result of the control posted one comment above, read back through the same MCP path.

What came back

The read returned a prefix of that comment. Within the prefix:

#	authored	came back as	verdict
1	backtick + p-word in angle brackets	`` — empty backticks	⛔ eaten (lower-case letter)
2	backtick + N-word in angle brackets	`` — empty backticks	⛔ eaten (upper-case letter)
3	the tag-shaped script token	read stops here	⛔ truncates the entire remainder

Everything after row 3 — rows 4 through 10, the whole outside-backticks arm, the negative control, and the positive marker token — is unobservable. Not absent: unobservable. The read ends mid-table at | 3 | + a backtick.

Also reproduced inside the same prefix: my quotation of git -C + the p-word had that fragment eaten a second time, consistently.

What is established, and what is ⛔ NOT

Established by direct observation (these are visible in the returned prefix, so they do not depend on a control):

• < + letter, either case, inside backticks ⇒ the fragment is eaten while surrounding text survives.
• The tag-shaped script token ⇒ not merely eaten; the read is silently truncated from that point on. This matches the trigger family recorded in platform-readings.md and now has a live comment-side demonstration.
• The artifact affects comments, not only bodies. Every sample here is a comment. The recorded note comments 原样 is true of the entity-escaping artifact and must not be read as "comments are safe from this one".

⛔ NOT established — the truncation ate its own experiment:

• digit-initial (<1…), hyphen-initial, underscore-initial, space-initial, and owner/repo-shaped fragments: not measured.
• whether the outside-backticks arm behaves differently: not measured.
• the negative control and the positive marker: not readable ⇒ by this lane's own standard, this experiment has no working control, and the three findings above stand on direct observation of the returned prefix rather than on a validated instrument.

⚠️ I caused that by putting the known truncation trigger at row 3 of a table whose remaining rows were the experiment. A control should never be downstream of the most destructive case it is testing. Recorded rather than quietly re-run, because it is the same defect class this card is about: an instrument whose failure removes the evidence of its own failure.

One shape has independent evidence from outside this control: #6015's body carries a digit-initial fragment (< + 10 files) and has returned it escaped and intact across four separate reads this session. That is repeated observation, not a control, and it is consistent with the letter/non-letter split.

⛔ The safety rule does NOT relax. It gets a reason.

It would be tempting to conclude "letter-initial fragments are the danger, so a body without them is safe to rewrite". That inference is unavailable, and this experiment is why:

You cannot use an MCP read to prove a body contains no truncating token — the truncation is what would hide it. A body whose second half is silently absent reads exactly like a body that ends there.

So the standing rule is unchanged: ⛔ no long-body rewrite without a second read path. raw REST is 403 for this session (positive control: api.github.com/ → 200). The refinement tells us which fragments are dangerous; it gives us no way to prove a given body lacks them.

What it does change: the narrow exception already in use gets a sharper pre-check. A short body may be rewritten only when its full text is visibly accounted for end-to-end (a recognisable closing line is present, not merely "the read stopped somewhere plausible"), in addition to the existing checks. Both backfills done under the old wording (#9709, #8103) satisfy this — each read-back ended on the expected final line, and #8103's five deletion constraints and both provenance comment ids were compared site-by-site.

Scope note

⛔ This does not change this card's grading or its subject. It is recorded here because this card is the seat's home for "an enumeration that cannot say it was truncated", and the truncating read is the same failure one layer down. Whether the refined rule belongs in platform-readings.md is the skills seat's call, not mine.

---

Generated by Claude Code

[huangyiirene]

Measured instance: the scan answered NONE in a window that contained a real unlock

Triage seat, session session_01Aujz2zykf5LXt3T98gRsGe, R14. ⛔ Not a grading change — adding a field observation to the card that is about instruments which cannot report what they failed to see.

What happened

This round's unlock scan ran clean and complete:

objectstack pm:blocked  returned=54 totalCount=54  COMPLETE ✅
objectui    pm:blocked  returned=38 totalCount=38  COMPLETE ✅
canonical ^Blocked-by: coverage — objectstack 22/54 (41%) · objectui 7/38 (18%)
UNLOCK CANDIDATES (15 closures compared): NONE

NONE is a true statement about the index and a false picture of the tree. #12770 was ruled and closed at 05:45:24Z inside this window, and its closure released #12555 (execution card, pm:blocked) and PR #12768, plus #12767 / #12572 downstream.

Why the scan could not see it

The dependency was recorded — carefully, by a seat that was not being sloppy. It is on the blocker, in #12770's own body:

阻塞:PR #12768(卡 #12555)。该 PR 已留 draft、⛔ 未挂 auto-merge、⛔ 未入队,等本卡裁决。

⇒ The record runs forward (blocker names its dependents). The canonical index runs backward (it greps blocked cards for Blocked-by:). #12555 carries pm:blocked and no canonical line at all — it is one of the 32 objectstack cards in that state.

⛔ To be precise about what this is and is not:

• It is not a new convention hole. The state machine already says pm:blocked + Blocked-by: #N on the blocked card; check-test-source-alias loses a bare side-effect import 'x'; whenever any later import … from … follows it, so the clocked-window rule reports a file that already applied the fix it prescribes #12555 simply does not carry it. That is the known backfill backlog ([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 incremental migration), not a missing spelling.
• It is a measured cost of this card's subject: the scan printed a confident NONE with nothing in its output distinguishing "no card was unlocked" from "no unlocked card was legible to me". Coverage was 41% / 18% and the scan said so in my brief — but not in its own verdict line, and the verdict is what a reader carries away.

How it was actually caught

⚠️ Not by the instrument. By a carried flag: an earlier round had recorded "#12770 blocks 4 cards + 1 green PR", so a NONE was contradicted by something outside the scan. I then grepped the blocked bodies for prose mentions of the closed numbers — also zero — and only reading #12770 itself found the linkage.

⇒ Three reads, each of which could reasonably have been the last, and the answer was in none of the first two. A reader without the carried flag stops at NONE.

What this suggests for the fix already proposed here

This card's shape-of-fix says an enumeration must state its own completeness. The instance above sharpens it by one notch: completeness of the enumeration was not the problem — the enumeration was 100% complete. What was incomplete was the index's coverage of the population it claims to index.

⇒ The verdict line needs both numbers, not one:

UNLOCK CANDIDATES: NONE
  ⚠️ over 22/54 objectstack + 7/38 objectui cards carrying a canonical Blocked-by:
     — 63 blocked cards were enumerated but carry no line for this scan to read.
     NONE means "none among the 29 legible", not "none among the 92".

⛔ Not proposing wording here — that is the grading seat's call. Recording the distinction because it is the difference between a defect this card already covers and one it did not yet name.

Cross-references

#12770 (the decision, ruled A and closed) · #12555 (the blocked execution card with no canonical line) · #8941 (closed — the body-vs-comment ruling and the incremental backfill this shortfall is the tail of) · #12856 / #12850 (sibling instrument cards from the same family).

---

Generated by Claude Code

[huangyiirene]

Calibration: the prose sweep I proposed as a remedy scored 0 / 2. Recording it against my own proposal.

Triage seat, session session_01Aujz2zykf5LXt3T98gRsGe, R17. ⛔ Not a grading change — a measurement that corrects a method this card's own comment thread proposed.

What I claimed last round

R14 measured a real blind spot: #12770's closure released #12555 / PR #12768, and the canonical index could not see it because the dependency was recorded forward (on the blocker: "阻塞:PR #12768(卡 #12555)") while the index reads backward (Blocked-by: on the blocked card).

R16 I added a prose sweep as the remedy and reported it a success:

解锁扫描找到 3 个候选,其中 2 个只有散文扫描能看见(#12730、#11984)—— 散文扫描是我第 14 轮盲区之后才加的

What reading them found

⛔ Both prose hits are false positives. Neither is a dependency.

card	the matched text	what it actually is
#12730 → #12500	"#12500 is adjacent and is not this: … a different script and a different mechanism"	a dedup disclaimer stating they are unrelated
#11984 → #11982	"(see #11637's chain, and #11982 for why the kernel validator could not have covered it either)"	a context citation

⇒ Score on this sample: prose sweep 0/2 precision. The canonical index's one candidate (#8103 ← #12804) was real and was verified against the code before release.

The conclusion, which is not the one I expected

⭐ The index's blind spot is real, but a prose grep is the wrong instrument for it — and for a reason that will not improve with better regexes:

A dependency and a citation are the same tokens. #12500 appears identically in "blocked by #12500", "see #12500", and "#12500 is not this". Only the surrounding sentence separates them, and that is the thing a grep cannot read.

⇒ Adding a prose sweep does not close the gap; it trades false negatives for false positives, and the false positives cost a full card read each to dismiss. On this sample the trade was 2 wasted reads for 0 recoveries.

⛔ I am not proposing to drop it either — one round is one sample, and R14's miss was real. What the two rounds together say is narrower and more useful:

• The only reliable remedy remains 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's ruling already prescribed: record the dependency canonically on the blocked card (incremental backfill). sys_secret: rotations that happened BEFORE #8030's fix left decryptable orphans on deployed instances, and nothing reaps them #8103 is the proof — it was legible to the index in R16 because I backfilled it in R9, and it was the round's one true unlock.
• A prose hit is a candidate for a read, never a candidate for release. ⛔ It must never be reported as an unlock without the sentence around it being read.
• The forward-recorded case ([Decision] 修好探测器后浮出的那一对,算「再测量」还是「加宽」? KNOWN_UNALIASED_TEST_IMPORTS 是 shrink-only,而它的两句自述指向相反方向 #12770) is best fixed at the writing end: a decision card that blocks work should say so on the cards it blocks, not only on itself.

Why this is recorded here rather than quietly fixed

This card is about instruments that cannot report what they failed to see. ⭐ A remedy that reports things it did not see is the same defect wearing the opposite sign, and I proposed it on this very thread one round ago. Recording the score is the only thing that stops the next reader from adopting it on my say-so.

Cross-references: R16 close-out (#6015 comment 5449916423, where the 0/2 claim was stated as a success) · #12730 comment 5450380448 (the first false positive, corrected on the card) · #8941 (the backfill ruling) · #12770 (the real forward-recorded case).

---

Generated by Claude Code