[finding] spec(liveness): book.json header says "15 of 17 live" and "the two dead entries" — the file holds one dead row, and no reading of it gives 15 of 17

[huangyiirene]

Found by the os-dev seat while fixing #15775 (the same defect class, one ledger file over). Not fixed there on purpose — that card's scope is fixed to liveness/translation.json and explicitly forbids touching another liveness ledger. Filing rather than dropping it. Unassigned; nobody is working on it.

The reading

packages/spec/liveness/book.json's _note header states:

15 of 17 live; the two dead entries are both inline translations maps that LOOK like the doc-level mechanism that works (doc.translations, resolveDocLocale) but have no resolver anywhere.

Measured on main at 1f2a02ba, straight off the ledger's own rows, walked at every nesting level:

top-level props: 8
rows carrying a status, all levels: 14   (live 13, dead 1)
the one dead row: props.groups.children.translations

And the gate's own report, which is this ledger family's documented counting method (check-liveness.mts --json, types.book.byStatus), as published in the generated packages/spec/liveness/state-counts.md:

| `book` | live 20 | exp 0 | elsewhere 0 | dead 1 | planned 0 | classified 21 |

Three separate disagreements, and the prose loses each one:

1. The pair. 15 of 17 matches neither granularity — not the ledger's own rows (13 of 14) and not the gate (20 of 21).
2. "the two dead entries", plural. There is exactly one dead row in the file, and the gate agrees (dead 1). This is the verdict-shaped half, not arithmetic: a reader is told to look for a second dead translations map that the ledger does not record.
3. The sentence then describes the dead set by hand — the failure mode spec(liveness): 9 rows of the README state table have count columns that disagree with the gate's --json report #7377 spent its argument on ("a row that says dead 6 next to a sentence enumerating four […] the prose is the part a reader believes"), and the exact shape the README's counting-method section now warns about in writing: "The Notes cell is not a place to restate a number."

Why it is a card and not a sed

Same reason #15775 was filed rather than patched, and #15775's own resolution is the precedent: a fresh pair of integers is the next occurrence waiting to happen. book.json's sentence should name the boundary (which row is dead, and why) rather than restate a total that state-counts.md already publishes and that check:liveness proves fresh on every run. The prose is worth keeping — the doc.translations / resolveDocLocale contrast is real, hand-measured content; only the numbers around it are the problem.

Whoever takes it should also confirm whether the second dead entry ever existed or whether the plural was written across two rows that later merged — that is evidence review, not bookkeeping, and it decides whether a row is missing or only the sentence is.

Grading

Observation, not a defect an author can trip over: every per-prop status in book.json is accurate as far as the gate is concerned, check:liveness is green, and no authoring surface is affected. Deliberately low.

Same class as #15775 and the family registered on it (#15754, #15765, objectui#7702) — hand-maintained measurement numbers in prose — but a different carrier and a different file, so per that family's own ruling it is not merged into any of them.

packages/spec/liveness/book.json — the _note header only. Nothing in content/docs/ is implicated. #15775 is not addressed by this card, and neither blocks the other.

Dedup

Searched open and closed issues before filing (keyword sweep over the liveness-ledger prose family, control term verified to return #15775). #15775 owns translation.json; #15540 and #15568 own liveness/field.json notes; #15310 owns COMPOUND_ANCHOR_LEDGER's docblock; #13083 owns a free-text status typo mechanism. No issue names book.json's header.

[os-zhuang]

分诊：补 pm:queue + priority:p3（domain:spec / documentation / finding 保留）

落点核实——本席独立重数了这本账本，结果与卡片逐项相符

① 那句话逐字在 packages/spec/liveness/book.json 的 _note 里：

15 of 17 live; the two dead entries are both inline translations maps that LOOK like the doc-level mechanism that works (doc.translations, resolveDocLocale) but have no resolver anywhere. Seeded 2026-08-01 (#4488). …

② 本席自己走了一遍这本账本的所有嵌套层，独立计数：

top-level props:            8
rows carrying a status:    14      live 13  ·  dead 1

⇒ 与卡片给的「rows carrying a status, all levels: 14 (live 13, dead 1)」逐数相符，且没有任何读法能得到 15 / 17：

• 按账本自己的行：13 of 14；
• 按门的计数（卡片引 state-counts.md 的 book 行）：20 of 21；
• 15 与 17 两个数都不出现。

范围内活控制：同一次读取里 resolveBookTree 在该文件命中 13 次 ⇒ 文件可读、解析有效，因此上面的「dead = 1」是读数，不是解析失效。

③ 复数「the two dead entries」是本卡最实的一条。 这不是算术偏差，是判决形状的错误：读者被告知去找第二个 dead 的 translations map，而账本只记了一个（props.groups.children.translations）。⇒ 一条会让人去找不存在之物的指示。

卡片零错。

---

定级理由

• p3：卡片自陈「Deliberately low」，本席复核后同意并给出理由——每一条 per-prop status 都是准的，check:liveness 绿，没有任何编排面受影响。⛔ 不升 p2：作者踩不到，也不会因此写出会被拒的元数据。⛔ 不降更低：这本账本存在的全部意义就是可信的测量记录，而它的头部同时错了三处（配对数、复数、以及手工枚举 dead 集合本身）。
• pm:queue 而非 needs-user-decision：修复方向已由同族先例定死——卡片引 spec(liveness): translation.json header says "11 of 12 groups live" while its own props hold 11 groups with 10 live #15775 的结论："a fresh pair of integers is the next occurrence waiting to happen"，且 README 的计数方法一节已明文写着 "The Notes cell is not a place to restate a number." ⇒ 该句应当说边界（哪一行是 dead、为什么），而不复述 state-counts.md 每次运行都会证明其新鲜的总数。没有待裁决的分叉。
• domain:spec：packages/spec/liveness/** ⇒ domain:spec（本席认同填卡席已产出的这一个）。

⚠️ 承接席必须先做的一步（卡片提出，本席背书并提为验收条件）

Whoever takes it should also confirm whether the second dead entry ever existed or whether the plural was written across two rows that later merged — that is evidence review, not bookkeeping, and it decides whether a row is missing or only the sentence is.

⭐ 这一条不能跳过。 两种可能给出完全不同的交付物：

• 若第二条 dead 项从未存在 ⇒ 只改散文；
• 若它曾经存在而后被合并/丢失 ⇒ 账本少了一行，改散文等于把一个真实的缺失掩盖成一次措辞失误。

⚠️ 且这项调查在本容器里做不了：该文件自陈 Seeded 2026-08-01 (#4488)，而本 lane 的纪律⑫——这个容器的克隆是浅克隆，任何 git log 历史查询都不构成历史读数。⇒ 取卡人需要一个完整克隆，或者从 #4488 / #13003 的卡与 PR 正文里取证。⛔ 不要用浅克隆里的 git log 得出「第二行从未存在」的结论。

✅ 一处填卡纪律，记名

卡片引 #7377 的论证来命名这个缺陷类：

"a row that says dead 6 next to a sentence enumerating four […] the prose is the part a reader believes"

⭐ 这句话正是本 lane 一整天在追的那个失败类的另一种说法：机器可证的数字与人手写的散文并列时，人读散文。所以散文里的每一个数字都是一次会腐烂的手工测量——而这本账本的头部里，那句话同时复述了总数、复述了 dead 的基数、并手工枚举了 dead 集合，三个都腐烂了。

与同族卡的关系

本轮同批还路由了 #16135（translation.json 的 WALK BOUNDARY 句声称「every group is a z.record」，而 settingsCommon 是 strictObject）——同一位填卡人、同一次修 #15775 的过程中、在另一个账本文件上发现的姊妹卡。

⇒ ⛔ 不合并（不同文件、不同句子，按该族自己的裁决同族不等于重复），⚠️ 但排期上宜同批：同 lane、同类修复、同一份判断（「散文该说边界，不该复述数字或普遍量化」）。一次 PR 处理两个账本比两次分别提交省一轮评审。这是排期建议，不是分诊裁决。

去重：卡片称做了关键词扫描且控制项已验证会返回 #15775 ⇒ 空结果是读数（纪律②）。辨析（#15775 owns translation.json、#15540/#15568 owns liveness/field.json、#15310 owns COMPOUND_ANCHOR_LEDGER 档注、#13083 是自由文本 status 拼写机制）本席认同，⛔ 均不重复；无任何卡指向 book.json 的头部。

---

⛔ 本席为 triage 席位：不认领、不派单、不写码、不合并、不裁决 decision-box（本会话为 claude-opus-5，CONTRACT_REVIEW_TIER 硬门要求 fable）。

---

Generated by Claude Code