Found while implementing #13194 as its dev seat. That card is not widened by this: its PR touches none of the sites below, and its own triage explicitly asked for exactly this re-evaluation rather than a fourth sweep card. Filed unassigned for triage.
The card family predicted this, and named the right response
#13194's triage closes with:
这是同族第三张卡(#13089 四处 → #13168 十三处 → 本卡二十四处),每次都是"上一张的分诊边界之外还有更多"。⇒ 本卡把 48 的分母补齐了,理论上不该有第四张。若还有第四张,那说明分母算法本身有问题,⛔ 届时不要再扩范围,回来重估。
There is more. It is not a fourth sweep, and the scope should not be widened to chase it — the triage is right that the finding is about the denominator ALGORITHM, not about a missed count.
What the denominator actually measured
All three cards in the family used the same population:
grep -rn 5499 packages --include=*.ts
That count is CORRECT and I reproduced it exactly (53 raw, minus the 5 generated hits in packages/spec/src/migrations/registry.ts = 48, stable at three refs). The problem is not the arithmetic — it is that the population is packages/**/*.ts and nothing else. Measured on the same tree, tracked files only, the same generated file excluded:
| population |
hits |
| repo-wide |
143 |
packages/**/*.ts — what all three cards measured |
47 |
| outside every card's denominator |
96 |
Of those 96, the CHANGELOG entries (about 50) are historical records and correctly out of scope, the same way the earlier card excluded them. What is left is a live population no card has ever looked at:
| file |
hits |
scripts/check-driver-memory-census.mjs |
9 |
scripts/check-driver-conformance.mjs |
7 |
packages/spec/spec-changes.json |
6 |
docs/protocol-upgrade-guide.md |
5 |
scripts/driver-memory-census.ledger.json |
3 |
docs/adr/0053-date-and-datetime-semantics.md |
3 |
scripts/pm/check-half-states.mjs |
2 |
.github/workflows/lint.yml |
2 |
scripts/check-tenant-chokepoint.mjs |
1 |
Two extensions were invisible to --include=*.ts by construction: .mjs (every gate script) and .yml (the workflows). A third, .json, carries the census ledger.
Three that are worse than anything the sweep cards found
1. A false statement printed by a GREEN gate, on every run. scripts/check-driver-memory-census.mjs:511 builds the gate's own success line:
ruled file states "..." Nothing here invests in the driver (#5499 freeze).
This is the same class as the describe() titles #13194 singled out — a false claim that reaches OUTPUT rather than only a comment — except this one prints on every successful CI run of check:driver-memory-census, not only when a test list is rendered.
2. A mirrored pair, so a one-sided repair may trip a mirror check. scripts/check-driver-memory-census.mjs:36 and .github/workflows/lint.yml:3057 carry the same sentence:
the driver, which stays frozen under #5499.
Whoever repairs these should check whether a published-list/mirror gate holds the two equal before editing either.
3. ⭐ A PM restart latch keyed on an issue that never closed. scripts/pm/check-half-states.mjs:11127:
Restart-when: closed objectstack-ai/objectstack#5499
(Earlier restart is legitimate only if the freeze ruling is narrowed on #5499 to exclude ...)
#5499 is still OPEN. Its freeze was lifted on 2026-08-11 (evidence: head note of packages/spec/src/data/aggregation-conformance.ts — the maintainer lifted it for driver-mongodb on 2026-08-11 and for driver-memory later the same day), but the anchor issue itself was never closed. So this latch's condition has not fired and, on the current state, will not: the ruling dissolved without the event the latch waits for. This one is not prose staleness — it is a live PM-machinery condition resting on a state that no longer matches reality, and it is the reason this is filed rather than mentioned.
Others in the same population, for completeness: check-driver-conformance.mjs:384 ("investment is frozen (#5499). Un-freezing it is what should re-run these cells") and :408 ("still in the #5499 frozen family"). Note that the SAME file also contains correctly dated past-tense lines (:397, :490, :501 all say "unfroze this package on 2026-08-11"), so it is internally inconsistent — a reader gets both answers from one file.
Why this is a re-evaluation and not a sweep
Per #13194's triage, do NOT open this as "24 more sites". The finding is that a three-card family measured its completeness against a population that structurally could not contain gate scripts, workflows, ledgers or docs — and the sharpest instances of the defect live exactly there. Anyone taking this should decide the POPULATION first and say what it is, rather than re-running the same grep with more extensions and discovering a fifth card later.
⚠️ Note also that a repair here is NOT pure prose: item 3 is a behavioural condition in PM machinery, and items 1-2 are gate/workflow text where a mirror check may apply. That is a different risk profile from #13168 / #13194, both of which were comment-only.
Related
Generated by Claude Code
Found while implementing #13194 as its dev seat. That card is not widened by this: its PR touches none of the sites below, and its own triage explicitly asked for exactly this re-evaluation rather than a fourth sweep card. Filed unassigned for triage.
The card family predicted this, and named the right response
#13194's triage closes with:
There is more. It is not a fourth sweep, and the scope should not be widened to chase it — the triage is right that the finding is about the denominator ALGORITHM, not about a missed count.
What the denominator actually measured
All three cards in the family used the same population:
That count is CORRECT and I reproduced it exactly (53 raw, minus the 5 generated hits in
packages/spec/src/migrations/registry.ts= 48, stable at three refs). The problem is not the arithmetic — it is that the population ispackages/**/*.tsand nothing else. Measured on the same tree, tracked files only, the same generated file excluded:packages/**/*.ts— what all three cards measuredOf those 96, the CHANGELOG entries (about 50) are historical records and correctly out of scope, the same way the earlier card excluded them. What is left is a live population no card has ever looked at:
scripts/check-driver-memory-census.mjsscripts/check-driver-conformance.mjspackages/spec/spec-changes.jsondocs/protocol-upgrade-guide.mdscripts/driver-memory-census.ledger.jsondocs/adr/0053-date-and-datetime-semantics.mdscripts/pm/check-half-states.mjs.github/workflows/lint.ymlscripts/check-tenant-chokepoint.mjsTwo extensions were invisible to
--include=*.tsby construction:.mjs(every gate script) and.yml(the workflows). A third,.json, carries the census ledger.Three that are worse than anything the sweep cards found
1. A false statement printed by a GREEN gate, on every run.
scripts/check-driver-memory-census.mjs:511builds the gate's own success line:This is the same class as the
describe()titles #13194 singled out — a false claim that reaches OUTPUT rather than only a comment — except this one prints on every successful CI run ofcheck:driver-memory-census, not only when a test list is rendered.2. A mirrored pair, so a one-sided repair may trip a mirror check.
scripts/check-driver-memory-census.mjs:36and.github/workflows/lint.yml:3057carry the same sentence:Whoever repairs these should check whether a published-list/mirror gate holds the two equal before editing either.
3. ⭐ A PM restart latch keyed on an issue that never closed.
scripts/pm/check-half-states.mjs:11127:#5499 is still OPEN. Its freeze was lifted on 2026-08-11 (evidence: head note of
packages/spec/src/data/aggregation-conformance.ts— the maintainer lifted it fordriver-mongodbon 2026-08-11 and fordriver-memorylater the same day), but the anchor issue itself was never closed. So this latch's condition has not fired and, on the current state, will not: the ruling dissolved without the event the latch waits for. This one is not prose staleness — it is a live PM-machinery condition resting on a state that no longer matches reality, and it is the reason this is filed rather than mentioned.Others in the same population, for completeness:
check-driver-conformance.mjs:384("investment is frozen (#5499). Un-freezing it is what should re-run these cells") and:408("still in the #5499 frozen family"). Note that the SAME file also contains correctly dated past-tense lines (:397,:490,:501all say "unfroze this package on 2026-08-11"), so it is internally inconsistent — a reader gets both answers from one file.Why this is a re-evaluation and not a sweep
Per #13194's triage, do NOT open this as "24 more sites". The finding is that a three-card family measured its completeness against a population that structurally could not contain gate scripts, workflows, ledgers or docs — and the sharpest instances of the defect live exactly there. Anyone taking this should decide the POPULATION first and say what it is, rather than re-running the same grep with more extensions and discovering a fifth card later.
Related
undeclared-field-write-driver-split.integration.test.tsis stale — a secondpackages/runtimetest consumer (#6468) is outside #5704's "in this one place" ruling #6664 — owns thecheck:driver-memory-censusledger whose script carries 9 of these hits.Generated by Claude Code