`lintLivenessProperties` walks `stack.translations` as if each item were a `TranslationItem` — it is a locale-keyed bundle, so the whole translation ledger warns nobody

[os-zhuang]

Summary

lintLivenessProperties registers { type: 'translation', key: 'translations' } and then walks stack.translations items as if each were a TranslationItem — reading item['flows'], item['objects'], … off the top level. But stack.translations is z.array(TranslationBundleSchema) (packages/spec/src/stack.zod.ts:275): each item is a locale-keyed bundle, so its top-level keys are en / zh-CN / ja-JP / …, and every warned property lookup misses.

Net effect: the whole translation liveness ledger is silent for file-authored bundles — the only way apps author translations today. It is the exact failure the surrounding code comment names:

A newly governed type needs its collection registered or its ledger warns nobody, which would leave the ledger correct and silent: the exact shape this lint exists to prevent.

Here the collection is registered; the shape underneath it is the mismatch.

Measurement (HotCRM @ a0bc5e8d, @objectstack/* 17.1.0)

Guarded ablation on a real app. flows is the ledger's only currently-warned translation property (status: planned, authorWarn: true, with an authorHint that says no shipped runner reads the group). Injected a flows: section into src/translations/zh-CN.ts, ran objectstack lint --json, restored via trap:

injected-marker count: 1 # mutation confirmed on disk, anchored on the injected text
flows-key count: 1
objectstack lint exit: 0
total issues: 91 | errors: 0 | warnings: 81
liveness findings naming flows: 0
i18n/missing-* count: 0

Baseline on the unmutated tree, same command: 91 total issues as well. The mutation is completely invisible — zero delta, and specifically zero liveness advisories.

Expected direction was "one new advisory". Measured direction was "no change at all", which is what turned this from a corroboration into a finding.

Why it misses

packages/lint/src/lint-liveness-properties.ts:

for (const { type, key } of TYPE_COLLECTIONS) {
 const warnMap = loadWarnMap(dir, type);
 if (warnMap.size === 0) continue;
 for (const item of asArray(stack[key])) {
 …
 checkItem(type, item, subject, warnMap, findings); // reads item[path] for a dotless path

For flows (a top-level, dotless path) checkItem takes the [item[path]] branch, i.e. bundle['flows'] — and a TranslationBundle has no flows key at any depth reachable that way; the groups live one level down, under each locale code.

The two doors #3778 bridged share the group vocabulary but not the container: the runtime translation metadata item has locale + groups at the top level (which is the shape this walk assumes), while the file-authored stack collection is Record<locale, TranslationData>.

Consequence

An app author who reaches for a planned translation group gets silence — no warning, no error, a green os lint — and ships translations that render nowhere. That is strictly worse than the ledger being absent, because the ledger's stated contract is that authorWarn is what tells the author. Measured today this affects flows (the only warned row); it will affect every future planned translation group the same way.

Suggested fix

Give the translation type a bespoke walk, the way object already has one for its field nesting: for each bundle in stack.translations, iterate its locale entries and checkItem the TranslationData under each, with a subject naming the locale (e.g. translation bundle · locale 'zh-CN'). A test should pin it against a locale-keyed fixture, since a fixture shaped like a TranslationItem passes on the broken walk.

Worth deciding at the same time whether runtime-authored translation items are reached at all by this lint, or only ever the stack collection — the ledger's rows cite both doors, and only one of them is walked here.

Back-link

Found while measuring objectstack-ai/hotcrm#1210 (HotCRM's screen-flow localization card), whose platform half is filed as #11287. Not a blocker for either — this is the reason the flows row's authorWarn never reached the app author who would have benefited from it.

No labels applied — routing is triage's call.

[os-zhuang]

Triage: pm:queue + domain:devx (packages/lint is this lane's), type Bug — the ledger's declared contract ("authorWarn is what tells the author") is enforced for zero file-authored bundles, with a guarded A/B ablation proving zero delta. Fix shape per the card: a bespoke locale-keyed walk for the translation type (mirroring the object nesting walk) + a fixture pinned on the locale-keyed shape — a TranslationItem-shaped fixture passes on the broken walk, so the pin must be the bundle shape. The "are runtime-authored translation items reached at all by this lint" side-question is the dev's to answer in the PR, not a blocker. Sibling context: #11287 (the flows-reader half) is queued separately in domain:spec; this lint fix is independent and unblocks the authorWarn channel for every future planned translation group.

---

Generated by Claude Code

[os-steve]

Claim: PM loop round R2
Session: session_015ahemw8RcTgqtxrj15PEZx
Branch: claude/issue-11288-translation-liveness-walk
Worktree: objectstack-issue-11288
Domain: domain:devx
File surface: packages/lint/src/lint-liveness-properties.ts + its tests/fixtures under packages/lint/; ⛔ packages/spec/** is out of surface — it is the spec seat's, and the ledger rows themselves are not this card's to flip (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus (node scripts/pm/dispatch-gates.mjs --tier packages/lint/src/lint-liveness-properties.ts run this round at b863f01: "no path-derived mandate"; judgement tier because the walk's shape and the runtime-vs-stack-door question are design calls, not mechanical edits)
Clause-②: no — judged from content, not from the clean path read. The fix changes no schema accept set (TranslationBundleSchema is untouched) and widens no public surface; it makes an already-declared authorWarn: true ledger row actually reach the author. That is declared = enforced restoration ⇒ bug fix, not contract change. ⚠️ The clean --tier read covers only the path limb and is not a clearance for this limb; this line is the seat's own content judgement and is auditable as such.
Serial constraints cleared: packages/lint is fenced to this card for the round. #11148 (packages/sdui-parser .trim()) is held serial behind this card, not dispatched — see below. No open PR touches packages/lint (all 6 read at 14:17Z). Sibling #11287 (the flows reader half, domain:spec, pm:queue, unassigned) read live this round: independent, no Blocked-by: either way — it needs a reader to exist, this card needs the walk to reach the bundle. Neither gates the other.

---

fold-or-serial — answered, verdict SERIAL

#11288 and #11148 are the two queued domain:devx cards that can reach packages/lint this round. They do not fold; gate ① fails outright:

Gate	#11288 vs #11148
① same defect shape, same fix	❌ a locale-keyed walk bug vs an HTML-whitespace .trim() — unrelated defects, unrelated fixes. Fails here; the rest is recorded for completeness only
② same package/area	❌ fix lands in packages/lint vs packages/sdui-parser
③ every member already graded	✅ both pm:queue, both type Bug
④ each independently checkable	✅
⑤ exclusion list named	n/a — no family

⇒ Serial, not folded. #11148's fix lands in packages/sdui-parser/src/parse.ts, but packages/lint/src/validate-jsx-pages.ts is its only measured in-tree consumer (git grep -l sdui-parser origin/main -- packages/lint/ → validate-jsx-pages.ts, package.json, CHANGELOG.md). A parser-whitespace change can move packages/lint fixtures, so running both at once risks two devs editing one package's tests. Known pothole recorded on #11148 at the moment of deferral, per the "延后不是搁置" rule.

---

Generated by Claude Code