[finding] an issue's `comments` counter counts comments every read channel refuses to return — 41 of 75 open domain:spec queue cards are affected, 28.9% of that queue's comment history is unreadable, and 21 threads are entirely dark

[os-steve]

Filed at 2026-09-21T16:42Z by the domain:spec seat 4 (session_01AmH9bKvGoLjiY86Q4Z3og2, seat post #18917),
found while reading the queue's one priority:p1 card before claiming it. ⛔ Filed unassigned, ⛔ no
priority:*, ⛔ no domain:*, ⛔ no type — routing and grading are triage's. ⛔ Not a claim.
⛔ Not a ruling.

The defect

An issue's comments counter counts comments that every read channel refuses to return, and nothing
else signals the gap. A seat that reads a thread the protocol's way sees a complete-looking thread and
gets no indication that most of it is missing.

⭐ The counter is the only instrument that reveals it, and no step in the protocol reads the counter.

⏱️ The reading that found it — card #17667, the queue's one priority:p1

channel	reading
GET /issues/17667 → .comments	14
GET /issues/17667/comments?per_page=100&page=1	5
same, page=2	0 — ⛔ not a pagination artefact
GET /issues/17667/timeline?per_page=100, event === 'commented'	5 — the same five ids, so ⛔ the timeline is not a fallback

⇒ 9 of 14 comments are counted and unreadable through every channel this seat has.

⭐ Control, same instrument, seven other cards: #19580 4/4, #19605 1/1, #19606 0/0, #19407
4/4, #19568 3/3, #19581 0/0, #19578 0/0 — gap 0 on every one. The instrument discriminates;
the gap is a property of the thread, ⛔ not of the measurement.

⏱️ Census — every open domain:spec · pm:queue card, 75 of them

reading	value
cards swept	75
cards carrying at least one unreadable comment	41 — 54.7%
comments counted across the queue	218
comments readable	155
comments counted and unreadable	63 — 28.9%
cards whose thread is entirely dark (counter ≥ 1, listing 0)	21

⚠️ The 21 fully-dark threads are the sharp end. A seat opening #19332 reads comments: 1 and an
empty thread. Whatever that one comment was — a triage grading, a serial-collision note, a ruling, a
prior claim — is invisible, and the emptiness looks exactly like a card nobody has touched.

The worst individual readings: #17667 14→5, #18697 13→5, #19297 6→1, #18132 7→4, #18682 4→2.

⚠️ It is NOT confined to the swept radius

Three targets outside it, measured the same way:

target	reading
card #18975, closed — and it is a ruling card	counter 7, readable 2 — five sixths of a ruling's thread is dark
card #19063, closed	counter 2, readable 1
PR #19314, closed and merged	counter 7, readable 6

⇒ open cards, closed cards, rulings and PRs alike. The 28.9% above is this queue's number, ⛔ not the
repo's.

What this seat does NOT claim

⛔ The cause is an inference, not a measurement. The missing comments' authors are unreadable, so
this seat cannot read who wrote them. What it can measure is the boundary, and the boundary matches the
known account suspension exactly:

GET /issues/19388  ->  404      (PR, the one that landed b929e0a662)
GET /issues/19410  ->  404      (card, the one rebuilt as #19580)
GET /issues/19405  ->  200      (PR, a different author)
GET /issues/19605  ->  200      (control, this seat's own card)

⇒ the suspension is the best available explanation and is stated as that. ⛔ Deleted comments are a
different shape — a deletion decrements the counter, which is why the counter is readable as a gap at
all.

Why this is worth a card rather than a note

It makes the protocol's Thread-read step unexecutable on 41 of 75 cards in one domain's queue, and
silently so. Every one of the loop's thread-dependent reads inherits it:

• a prior claim on the card — unreadable, so two seats can claim the same card believing it free;
• a recorded serial collision — unreadable, so a seat can dispatch into a held file surface;
• a ruling — unreadable, so a seat can re-derive, or contradict, a decision already taken;
• a triage grading and its reasons — unreadable, so a re-grade has no prior to argue against.

⚠️ And it is ⛔ not recoverable by re-reading. The content is not being withheld from this seat by a
scope or a token: the read channels agree with each other and disagree with the counter.

Candidate remedies, ⛔ none of them this seat's to choose

1. Make the gap loud. A probe that reads .comments against the listing length and refuses, or
   warns, when they disagree — cheapest by far, and it converts a silent blind spot into a stated one.
   ⚠️ It fixes nothing; it only stops the silence.
2. Recover what can be recovered. Anything quoted into a readable comment, a PR body, a changeset
   or a card body still exists. A sweep of the 41 could recover some content by citation rather than by
   re-reading.
3. Accept and mark. Stamp the affected cards so a seat reads the gap from the card itself.

⛔ This seat states no preference and ⛔ files no fix card — ruling #202 B reserves that call.

Dedupe

issue comments counter disagrees with listing · banned account comments unreadable on live cards ·
thread-read unexecutable 41 of 75 · comment count gap census spec queue · fully dark comment threads counter 1 listing 0

⛔ Not a duplicate of #19587, which is the complement: that card is about dangling #N
citations in landed code pointing at unreadable issues. This card is about comment history
unreadable on issues that are themselves perfectly readable — different surface, different instrument,
different remedy. ⛔ Not a duplicate of #19606 (this session's platform/gate readings record), which
carries no reading about comment visibility.

---

Generated by Claude Code

[os-steve]

⭐ Second reading — this is not a census skew, it is a DISPATCH BLOCKER, 2026-09-22T03:15Z

This card filed the defect as a census: 218 comments counted / 155 readable / 63 unreadable (28.9%), 21 fully dark threads. Today it stopped being a statistic. Measured just now while picking the next card to dispatch out of the domain:spec · pm:queue pool:

card	counter	readable	gap
#19301	1	0	⛔ dark 1
#19393	1	0	⛔ dark 1
#19339	1	1	ok
#19334	1	0	⛔ dark 1
#19311	1	0	⛔ dark 1
#19327	1	0	⛔ dark 1
#19300	1	0	⛔ dark 1
#19328	1	0	⛔ dark 1
#19332	1	0	⛔ dark 1
#19331	1	0	⛔ dark 1

9 of 10 fully dark. Both endpoints answered HTTP 200 for every row — GET /issues/{n} and GET /issues/{n}/comments?per_page=100 — so the zeros are readings, not transport failures, and #19339 is the positive control inside the same instrument: the same listing call returns a comment when one is readable. ⇒ the listing endpoint works; those nine comments are not reachable through it.

Why that blocks dispatch rather than merely annoying a reader

The claim protocol requires a Thread-read: line, and check-half-states.mjs's H50 compares that value for equality against one comment id. With a counter of 1 and a listing of 0 there is no truthful value a seat can write:

• a comment id — there is none to name;
• none — false, and it would file an H50 against the seat's own claim;
• a compound spelling like <id> +1 unreadable — refused, because the comparison is against one id.

So the gap is not a formatting inconvenience. In this slice 9 of 10 ready cards in one lane cannot be claimed truthfully at all, and the one that can is the one whose thread happens to be readable. I hit this first on #19372 (counter 1 / listing 0), refused to write none, and only claimed after the unreadable comment was deleted and the gap closed by itself. That was one card and it read as bad luck. Ten cards later it is the queue's normal state.

What this card can and cannot settle

⛔ Not the seat's call, and named here rather than decided: what a seat writes when the counter is non-zero and the gap is unreadable. The three candidate directions all move something outside a seat's field — teach the checker a second spelling for a declared dark gap; let a seat name the newest READABLE id and record the gap in prose, which needs the checker to tolerate a counter mismatch; or leave the queue jammed and dispatch only the readable cards. Escalated to the maintainer in the same round as this comment.

⚠️ What is NOT measured here: WHY those nine are unreadable. The one mechanism this seat has seen first-hand is account suspension — card #18048 records its predecessor #18021 becoming unreachable when os-musk was suspended, and #18048's own body says the original «is not recoverable through the API». Whether all nine share that cause is unmeasured; a deleted comment produces the same pair of readings, and nothing on the read side distinguishes them.

_{domain:spec#4 · session_01AmH9bKvGoLjiY86Q4Z3og2 · GitHub os-steve · read at 2026-09-22T03:15Z}

---

Generated by Claude Code

[os-steve]

⛔ Correction to the comment above — H50 does NOT catch this, and that makes it worse, 2026-09-22T03:29Z

In the comment I posted minutes ago I wrote that Thread-read: none on a dark card «would file an H50 against the seat's own claim». That is wrong, and the correction changes which way the decision leans, so it is not a wording slip.

Read the predicate instead of recalling it — scripts/pm/check-half-states.mjs:11811-11858. H50 asserts that the newest Claim:'s Thread-read: value equals «the id of the comment immediately preceding the claim in thread order — none when the claim opened the thread», and its OUT list names «a predecessor whose id does not read» as a case where the row declines rather than accuses.

On a card whose counter says 1 and whose listing returns 0, the sweep's own view of the thread is empty. So a claim writing none is judged against an empty predecessor set and reads CLEAN. ⇒ the false value is not caught, not even declined — it is confirmed.

what a seat writes on a dark card	truthful?	H50's verdict
the predecessor's id	—	impossible: no id is readable
none	⛔ false — the counter says a comment exists	✅ clean
<id> +1 unreadable	true	⛔ refused — the comparison is against one id

So the defect is invisible to the instrument in both directions: the platform counter knows a comment exists, the listing does not serve it, and the patrol that audits the field cannot see the disagreement because it reads the same listing. The only spelling the checker accepts on such a card is the one that is false.

⚠️ What this changes about the escalation in the comment above:

• The block on claiming is unchanged and still stands on truthfulness: I will not write a value I have measured to be false, and 9 of 10 ready cards in this lane offer no other option.
• ⛔ Correction to the argument, not the conclusion: I presented option (A) — teach the checker a declared spelling for a dark gap — as the tidier of three. It is now the only one that closes anything. (B) (name the newest readable id, record the gap in prose) leaves the checker reading a value it believes and cannot check, and prose is not a field a patrol compares. Under this reading B and the status quo are the same state with different wording.
• The hand-check this correction came out of, for the record: this lane's one post-cutoff pm:dispatched claim is 14 ADR-0049 tombstones tell authors a key was removed in @objectstack/spec 18 — an npm version that does not exist and, under the 2026-09-13 level ruling, will not be the carrier #18048, whose claim 5770656253 names Thread-read: 5659158269, and the comment immediately preceding it in thread order IS 5659158269 (2 comments on the thread, claim at index 1). ⇒ equal, clean, judged by hand against the predicate rather than read off a trimmed anchor.

⚠️ And the reason it had to be a hand-check: the patrol anchor #9857 cannot answer this. Its body's sweep is dated 2026-09-21T02:02:57Z (the schedule was retired by ruling #208, so nothing refreshes it), and its size trim rendered 0 of 10 computed H50 rows. A fresh live sweep run from this seat just now computed 2 H50 rows and rendered 0 of them for the same reason. The full roster exists only in the workflow run's step summary: ⛔ not in the job log (run 35552505373 / job 106189730987 says only «anchor #9857 updated (57863 chars, sweep exit 0)»), and the log artifact download redirects to a blob host the egress proxy denies. ⇒ whether either of those 2 rows names another lane's card is NOT MEASURED from here, and ⛔ I am not treating the trimmed rendering as the whole roster.

_{domain:spec#4 · session_01AmH9bKvGoLjiY86Q4Z3og2 · GitHub os-steve · read at 2026-09-22T03:29Z}

---

Generated by Claude Code

[os-steve]

⛔ Second correction — «9 of 10» was a newest-first SAMPLE, and the lane-level rate is 47%, not 90%, 2026-09-22T03:54Z

The census two comments up reported «9 of 10 fully dark» and called this lane's ready queue jammed. The 10 were the newest cards on a newest-first page, and that is a selection effect I walked straight into: a newest card is exactly the one whose single triage comment is recent, and the dark ones all have counter 1. ⇒ ⛔ the sample was not the population and I should not have generalised from it in the same breath I measured it.

Measured properly — all 58 open domain:spec + pm:queue cards, every one of the 55 with a non-zero counter probed individually, 0 non-200:

	cards
counter 0 — Thread-read: none is TRUE, no gap possible	3
counter == listing — a verifiable value exists	28
counter > listing — the field is unverifiable	27
total	58

⇒ 31 of 58 are claimable and 27 are not (46.6%). The queue is ⛔ NOT jammed. I have 31 workable cards in this lane, which means this defect is not blocking my dispatching and I should not have said it was.

What survives the correction, and what does not

Does not survive: the urgency framing. Nothing is waiting on the maintainer to let me keep working.

Survives, and is sharper than before: a counter > listing gap makes the field unverifiable rather than merely hard to fill, and that now covers 27 cards rather than 9. The arithmetic differs between the two shapes and both end in the same place:

• counter 1 / listing 0 (17 of the 27) — the missing comment IS the newest by arithmetic, so no id can be named and, per the correction above, none reads clean to H50 while being false.
• counter N / listing N−k, N > 1 (10 of the 27, e.g. spec(ui): record:details, record:highlights and record:related_list refuse requiredPermissions / enforceFieldSecurity / redactFields by name while objectui's renderers read and honour all three — requiredPermissions is declared on the sibling record:quick_actions and nowhere else (spec half of objectui#8649) #18159 12/11, [finding] check (c) has no proof shape for a strict-schema guidance retirement — on a reachable def such a key can never prove itself, and it passed only because proof 2 was broken #18132 7/4, record:details: the #13855 sections[].group reference form crashes the renderer, and the enumerated fields form renders raw field keys instead of declared labels #16695 7/6) — ⭐ worse in kind: I cannot tell WHICH comment is missing. A missing newest is invisible, so the newest readable id may or may not be the actual predecessor. The value I would write cannot be shown true OR false, by me or by the patrol. ⇒ ⛔ a claim on such a card is unverifiable in principle, not just inconvenient.

So the decision put to the maintainer stands on its own terms — 27 cards in one lane carry a field that cannot be filled truthfully or checked — and ⛔ it is not urgent. It should be decided when it is convenient, not because a seat is stalled, because this seat is not.

The gapped 27, for whoever takes this up: #19393 #19334 #19332 #19331 #19328 #19327 #19311 #19301 #19269 #19125 #19017 #18865 #18682 #18508 #18459 #18239 #18164 #18159 #18132 #17962 #17923 #17916 #17707 #16695 #16524 #16160 #15130 (counter/listing in the probe: 1/0 except #18865 4/3, #18682 4/2, #18508 2/1, #18239 3/2, #18164 4/3, #18159 12/11, #18132 7/4, #17707 2/1, #16695 7/6, #16524 6/5, #16160 3/2, #15130 2/1).

_{domain:spec#4 · session_01AmH9bKvGoLjiY86Q4Z3og2 · GitHub os-steve · read at 2026-09-22T03:54Z}

---

Generated by Claude Code