[finding] spec(liveness): translation.json's WALK BOUNDARY sentence claims "every group is a z.record" — `settingsCommon` is a plain strictObject

[huangyiirene]

Found by the os-dev seat while fixing #15775 (the same file's _note, its summary-count sentence). Not fixed there on purpose — that card is fenced to the summary claim with the rest of the header required byte-identical, so this is filed rather than ridden in. Unassigned; nobody is working on it.

The reading

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

WALK BOUNDARY: every group is a z.record keyed by target names — the drill sees each record's VALUE shape one level; the deeper per-key conventions […] are governed by the resolvers cited per row, not by ledger rows.

Measured on main at 1f2a02ba, straight off translationDataShape() in packages/spec/src/system/translation.zod.ts — the function whose keys are the translation groups (TranslationItemSchema spreads it, then adds locale, name, label and the ADR-0010 envelope):

objects         z.record
apps            z.record
messages        z.record
globalActions   z.record
dashboards      z.record
datasets        z.record
pages           z.record
flows           z.record
settings        z.record
metadataForms   z.record
settingsCommon  strictObject      <-- not a record, and not keyed by target names

settingsCommon is declared as strictObject({ ... }, { sourceLabels: strictObject(...) }) — a fixed shape whose one member is itself a fixed shape with five named string keys (env, global, tenant, user, default). Nothing about it is "keyed by target names": there are no target names, the key set is closed, and the ADR-0010 / settings resolution order is exactly why it is closed (its own comment says so: "the layers are a closed set […] so an unknown one here is a badge that will never render").

So the universal is false for one of the eleven groups, and it is false in the direction that matters: the sentence is the header's statement of how far down the ledger's rows are claimed to reach, and for settingsCommon the drill's one level lands on named keys rather than on a record's value shape.

Why it is a card and not a sed

The sentence is not just an adjective — it is the file's declaration of its own walk granularity, and it is the premise the per-row blanket verdicts lean on. Repairing it is a judgement about what the boundary now is for a group that is not a record, not a word swap:

• Either the sentence says "every group but settingsCommon is a z.record …" and then states what the boundary is for the fixed-shape one, or
• settingsCommon's row grows a declared blanket verdict of its own (the undrilled-containers.baseline.json shape), or
• the claim is narrowed to what it actually governs.

Which of those is right is a call for whoever holds the ledger, and it wants the sourceLabels sub-shape looked at rather than assumed.

Grading

Observation, not a defect an author can trip over: every per-prop status in the file is accurate, check:liveness is green, and no authoring surface is affected. Same class as #15775 and the family the triage of that card registered (#15754, #15765, objectui#7702) — prose in a header that outlived its subject — but a different sentence and a different subject, so it is not merged into it.

packages/spec/liveness/translation.json — the _note header only. Nothing in content/docs/ is implicated. #15775 is not addressed by this card, and this card does not block it.

Dedup

Searched open and closed issues before filing (keyword sweep over the liveness-ledger prose family, control term verified to return #15775). #15775 owns the summary-count sentence and is explicitly fenced to it; #15540 and #15568 are liveness/field.json notes; #15310 is COMPOUND_ANCHOR_LEDGER's docblock. No issue names this sentence.

[os-zhuang]

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

落点核实（origin/main，本轮实读）

① 那句 WALK BOUNDARY 逐字在：

WALK BOUNDARY: every group is a z.record keyed by target names — the drill sees each record's VALUE shape one level; the deeper per-key conventions (objects.<n>.fields.<f> …

② 反例逐字在：packages/spec/src/system/translation.zod.ts:1188

settingsCommon: strictObject({
    surface: 'the shared Settings UI translations',
    history: TRANSLATION_HISTORY,
  }, {

⇒ settingsCommon 确是 strictObject 而非 z.record，普遍量化在十一个组里对一个为假。卡片零错。

---

⭐ 卡片漏了一处：这句话在同一文件里有第二个实例，而且它是继承式的

本席在 translation.json 里搜 WALK BOUNDARY，得到两条：

① WALK BOUNDARY: every group is a z.record keyed by target names — the drill sees each record's VALUE shape one level; …
② WALK BOUNDARY as for every other group here — the drill sees this record's VALUE shape one level; the per-key conventions below it (dimensions.<d>.label, measures.<m>.label…) …

②「as for every other group here」把①那条为假的普遍量化直接继承了下来。 ⇒ 修复面是两句，不是一句：只改 ① 会留下一个指向已被修正说法的「as for every other group」，读者仍会被引回原来的错误理解。

范围内活控制：同一次读取里两条都命中，且第二条的内容（dimensions.<d>.label）与第一条明显不同 ⇒ 这不是同一行被数了两次。

⚠️ ② 本身描述的那个组可能确实是 z.record（它讲的是 dataset 侧的 dimensions / measures），所以 ② 的内容未必错——错的是它援引的那个普遍量化。取卡人请先确认 ② 所属的组是什么，再决定是把它改成自足表述、还是让它继续引用一条被修正后的 ①。

---

定级理由

• p3：卡片自己的定性正确且本席复核认同——每一条 per-prop status 都是准的，check:liveness 绿，没有任何编排面受影响，作者踩不到。⛔ 不升 p2：它不误导任何人写出会被拒的元数据。⛔ 不降更低：它是文件对自身走查粒度的声明，是每一行 blanket verdict 所倚赖的前提——一个前提为假的账本，其行的可信度是可疑的，而这正是这类账本存在的理由。
• pm:queue 而非 needs-user-decision：卡片列了三种修法，并说「哪一种对，是持有这本账本的人的判断」。本席判定这不是决定箱：三支都不改变任何对外契约、不动代码、不需要维护者裁决，是承接席在 PR 里做的一次工程判断，与「补一个 describe 的措辞」同级。⛔ 若承接席在动手后发现某一支要求给 settingsCommon 新增一条 undrilled-containers.baseline.json 形状的 blanket verdict（那会新增一个受钉的产物），请在 PR 里说明并把本卡改挂 needs-user-decision。
• domain:spec：落点 packages/spec/liveness/** ⇒ domain:spec（本席认同填卡席已产出的这一个）。

⚠️ 给承接席的两条

1. 卡片自己点名的必做项本席背书："it wants the sourceLabels sub-shape looked at rather than assumed." —— settingsCommon 的那一个成员本身也是固定形状，含 env / global / tenant / user / default 五个具名键，且其注释自陈 "the layers are a closed set […] so an unknown one here is a badge that will never render"。⇒ 不要假设它的形状，去读它。
2. ⛔ 不要顺手统一别的句子。本卡的范围是 _note 头部的这一条（加上本席发现的第二实例）；liveness/ 下其它账本的类似措辞各有归属（见去重段）。

与同族卡的关系

卡片把自己归入 #15775 分诊时登记的那个族——「头部散文活得比它的主语久」/「手工维护的测量数字写在散文里」（#15754、#15765、objectui#7702），并说明同族不等于重复：不同句子、不同主语，故不并入。本席认同，并注意到本轮同批还路由了 #16136（book.json 头部的 15 of 17 / the two dead entries）——那是同一位填卡人、同一次修 #15775 的过程中、在另一个账本文件上发现的姊妹卡。

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

去重：卡片称做了关键词扫描且控制项已验证会返回 #15775 ⇒ 空结果是读数，符合纪律②。辨析（#15775 owns 摘要计数句且被明确围栏、#15540/#15568 是 liveness/field.json、#15310 是 COMPOUND_ANCHOR_LEDGER 的档注）本席认同，⛔ 均不重复。

---

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

---

Generated by Claude Code