Inline `I18nLabel` maps are invisible to `os i18n extract` and `check:i18n-coverage` — should the extractor and the coverage gate see them? (objectstack#14412 ruling A follow-up)

[os-project-manager]

Filed by the director seat (objectstack #12708, summon #10, session session_01ShyhexkB2d1AeRZ85tgAAe) as the follow-up the maintainer's ruling on #14412 named. Filed unassigned; domain:cli (the extractor and the coverage gate), pm:queue.

Ruling this follows

Provenance: maintainer, live PM chat with the director seat, 2026-09-02, decision batch #13 item 3 on #14412, recommendation A, verbatim 「同意」. Ruled: element:text's content does not join PageTranslation.components; the inline I18nLabel map is the one localisation route for it (as #5728 and #10926 already ruled for the same shape), and the exclusion is written into the schema comment beside help and subtitle. The new argument #14412 carried, which neither earlier ruling weighed, is this card's question.

The gap

An authored string localised through an inline I18nLabel map ({ en, 'zh-CN', … } on the field) is real, ruled, and renders. It is also invisible to:

• os i18n extract (the strings never reach the locale bundle as rows);
• check:i18n-coverage (they are neither counted as covered nor as missing);
• a translator working from the bundle (the strings live in page definitions, not in the locale file).

Measured outside this repo on objectstack-ai/duly#13: one read-only record page, 16 such strings, recorded by that app under an untranslatable ledger with this reason and pinned by count. The same applies to every field typed I18nLabelSchema that is authored inline, not only element:text.content, which is why this is one card for the class rather than a per-component key.

What is being asked

Whether the extractor and the coverage gate should walk inline maps, and if so in which direction:

• A — extract inline maps into the bundle as rows keyed by their authoring site (page id + node path + prop), and let the coverage gate count locales present in the map as covered and missing ones as gaps. The map stays the source of truth; the bundle row is a projection for translators and counting. Needs a stable key scheme for node paths.
• B — coverage only: the gate counts inline maps (present locales covered, absent ones missing) without extracting them; translators keep editing the page definition.
• C — leave both as they are and document that inline maps are outside the extraction and coverage story.

Options are for the maintainer's decision inbox after the cli seat has measured the cost of a node-path key scheme; the seat files the four-facet block when it grades this card. Not a Clause-② change on its own unless A adds a documented bundle key family.

Related: #14412 (the ruling), #5728, #10926 (the two rulings that made inline maps the route), #14376 (extractor coverage of new key families), objectstack #12708 (director seat ledger).

[os-trump]

Claim: session session_016yfqQh2dBgPAymYd7xipza · seat domain:cli · branch claude/issue-14749-inline-i18nlabel-extraction-cost

pm:queue → pm:dispatched in the same label write; assignee set. Dispatching one os-dev now.

Dispatched as a MEASUREMENT unit, not an implementation — reading the card's own terms: "Options are for the maintainer's decision inbox after the cli seat has measured the cost of a node-path key scheme; the seat files the four-facet block when it grades this card." So the queued, dispatchable unit is the measurement plus the decision block; A/B/C is the maintainer's to rule and ⛔ not the dev's to pick.

The dev is instructed to change no behaviour in the extractor or the coverage gate, and to write the four-facet block in Chinese per the standing language rule for decision analysis.

---

Generated by Claude Code

[os-trump]

Measurement — inline I18nLabel maps, and what a node-path key scheme would cost

Filed by the domain:cli seat, session session_016yfqQh2dBgPAymYd7xipza, branch
claude/issue-14749-inline-i18nlabel-extraction-cost, measured on origin/main at
5a5336b3. No behaviour was changed — this card is a measurement, and A/B/C stays the
maintainer's ruling. The rig is instrumentation and lives outside the repo.

1. Population — 45 maps / 180 locale strings, all on three pages

Enumerated from the schema, in two passes, not from a hand list:

1. Parse every packages/spec/src/**/*.zod.ts with the TypeScript AST and collect every
   PropertyAssignment whose initializer roots at I18nLabelSchema. Result: 101
   declaration sites, 19 distinct prop names (label, title, content, body,
   subtitle, placeholder, helpText, emptyText, submitText, cancelText,
   nextText, prevText, successMessage, errorMessage, confirmText, description,
   message, acknowledge, ariaLabel) across 52 owner schemas.
2. Parse all 5,564 .ts/.tsx files in the repo (200,780 object literals, 411,691
   property assignments) and keep every object literal sitting at one of those 19 props
   whose keys all satisfy INLINE_LOCALE_KEY verbatim from i18n.zod.ts and whose values
   are all string literals.

	count
inline maps at an I18nLabel-typed prop, repo-wide	106
— in tests / fixtures / compile pins	58 + 2
— scan false positive (errorMessage: { why: … } in authoring-key-lint.ts; why is a legal 3-letter tag)	1
authored product metadata	45

All 45 are in packages/platform-objects/src/pages/ — sys-user.page.ts 33,
sys-organization.page.ts 6, sys-position.page.ts 6. Every one carries exactly four
locales (en, zh-CN, ja-JP, es-ES); there is not a single partial map. By prop:
label 22, title 14, content 8, body 1. By carrier type: record:related_list 18,
page:tabs 14, element:text 8, record:alert 3, record:details 2.

Control: an independent grep -c "'zh-CN':" over the three files returns 33 / 6 / 6 = 45,
and the same pattern returns 0 on examples/app-showcase/objectstack.config.ts. A
shape-anchored second scan (any object literal whose keys are all real locale tags) finds
140 repo-wide; the 40 not in the schema-anchored set are all tests, resolver internals and
locale bundles — so the schema-derived prop set misses no authored site.

These three pages are 94% inline-mapped: of 48 I18nLabel-typed prop sites on them, 45
are inline maps and 3 are plain strings (the page-level labels User / Organization /
Position).

⚠️ i18n.zod.ts says twice that "three published platform pages author 31 of these".
Measured today: 45. The prose is stale by 14; the page count is still right.

2. Key-scheme cost — the inline map is the FOURTH reason these are invisible

Walking inline maps would not make one of these 45 strings visible, because three earlier
layers stop them first. In the order they bite:

1. No baselined config declares these pages. The three pages are contributed at runtime
   by plugins — plugin-auth/src/auth-plugin.ts:638 (pages: [SysOrganizationDetailPage, SysUserDetailPage]) and plugin-security/src/security-plugin.ts:1068
   (pages: [SysPositionDetailPage]). packages/platform-objects/scripts/i18n-extract.config.ts
   declares objects / apps / dashboards / translations and no pages key; neither
   plugin has an extract config at all. Of the 13 baselined configs only app-crm and
   app-showcase declare pages, and neither has an inline map. This is precisely the class
   check-i18n-coverage.mjs's own header calls out: "Metadata assembled at RUNTIME is outside
   it by construction."
2. The walk never reaches them. packages/spec/src/system/i18n-resolver.ts:1484 —
   "roots: regions[].components[] only — slots is not walked, on any page"; and 1486-1488,
   descent is properties.children only, with body / footer / items[].children
   "deliberately not descended". Measured: 45 of 45 sit under slots.*, 0 under
   regions[], and 26 of them one children level down, reached through
   properties.items[].children and properties.sections[].
3. No key family, and no key. PAGE_COMPONENT_COPY_KEYS is
   ['title','description','label','placeholder','emptyText'] (i18n-resolver.ts:1378) — so
   content (8) and body (1) have no bundle key at all, which is what the PageTranslation.components has no key for element:text's content — the one string that element renders cannot be addressed by a bundle #14412 ruling
   just affirmed. And emitPageComponentCopy keys on component.id
   (pages.PAGE.components.ID.KEY, i18n-extract.ts:853), which page.zod.ts:164 declares
   z.string().optional(). Measured: 0 of 45 carry an id.
4. Only then does the map/string distinction matter: inlineText() returns undefined for a
   non-string (i18n-extract.ts:384), so pushEntry early-returns and emits nothing, while
   pushOptional records the key as unauthored — an inline map is indistinguishable from an
   absent value.

So the three questions the card puts to option A, each answered from code:

• Stable identity across a sibling reorder? No. At all 45 sites the only available
  identity is an array index (slots.tabs.properties.items.0,
  slots.details.properties.sections.1, slots.alerts.0). A record:details section has an
  identity slot — name, z.string().optional(), "Stable section identifier for i18n lookup"
  — and the schema states the failure itself: "a nameless section renders its authored label
  in every locale" (component.zod.ts:869). None of the authored sections carry one. The
  hardest case is page:accordion, where index identity is the delivered contract: "the
  renderer derives panel-INDEX and discards whatever is written here"
  (component.zod.ts:1690). Reordering two siblings silently swaps their translations.
• Does renaming a page orphan every row? Yes. The root is pages.PAGE_NAME, resolved as
  pickData(bundle, code)?.pages?.[name]?.components?.[id] (i18n-resolver.ts:1401) against
  page.name (SnakeCaseIdentifierSchema, page.zod.ts:528). There is no key-migration or
  rekey machinery anywhere in packages/cli/src, packages/spec/src/system or scripts
  (searched; the only orphan hits are unrelated — unmanaged tables, docs links). A rename
  moves every row under the page and nothing rewrites bundles.
• Stable across a re-save by the authoring UI? Not for source-authored pages. For
  kind: 'html' | 'react' | 'jsx' the source is "Authoritative over regions in both"
  (page.zod.ts:656), compiled to the tree by sdui-parser at save time; the extractor
  already refuses to key off the result — "source-authored pages hold only a DERIVED region
  cache that the author never wrote — scaffolding translation keys off that cache would invent
  an authoring surface" (i18n-extract.ts:698-700). Studio's designer has the same shape from
  the other side: it publishes an accordion item value that the renderer discards
  (component.zod.ts:1675, filed as objectui#7973).

3. Counting projection for B — before 691, after 691

A baseline unit is one os lint issue whose rule starts with i18n/
(check-i18n-coverage.mjs:272), i.e. one (key, locale) pair. Current baseline total is
691 across 13 configs (app-crm 102, app-showcase 443, app-todo 146, the other ten 0).

If the gate counted inline maps today — present locales covered, absent ones missing — the
delta is 0 and the after total is 691, because layer 1 above holds: no config in the
gate's population declares a page carrying an inline map. Not one of the thirteen numbers
moves. ⛔ Nothing was written to scripts/i18n-coverage-baseline.json.

The number only moves if the population is fixed first. Two projections for that, stated so
the maintainer can price them:

• Declare the three pages in an extract config and extend the walk (layers 1+2), keeping
  today's key families: the three page-level plain-string labels become visible ⇒ +9
  (3 strings x 3 non-source locales, --locales=zh-CN,ja-JP,es-ES) ⇒ 700. The 45 maps
  still contribute 0 — 36 of them lack an id, 9 lack a key family.
• Full option A (layers 1+2+3+4, node-path keys, content/body families): the 45 maps
  become 45 keys, each already carrying all four locales ⇒ +0 missing, and 180 bundle
  rows appear as covered. Option A's payoff is bundle visibility for translators, not a
  ratchet movement.

Interaction with #14728 (70 of the 691 baselined units are byte-identical duplicate
findings): none. My projected delta is 0, so the two numbers do not compose. If #14728 lands
first the baseline becomes 621 and every projection above shifts by the same constant — the
+9 and +180 are independent of the duplicate defect.

4. The external data point — MEASURED, and it does not generalise

objectstack-ai/duly issue #13 is not readable from this seat (the GitHub API does not
cover unattached repos; curl returns 403 where the same call returns 200 for this repo), so
the issue text stays NOT MEASURED. The repository itself is git-readable, and it carries the
artefacts, so the data point is measured directly at duly@5c5a8a0:

• 8 inline maps, all in src/pages/member.page.ts, all on content (element:text),
  all carrying exactly { en, 'zh-CN' }. 8 maps x 2 locales = 16 strings — which
  reconciles this card's "16 such strings" as a count of locale entries, not of maps. On
  that same unit, this repo's population is 45 maps = 180 strings.
• Its untranslatable ledger carries 2 rows, not 16:
  src/translations/authored-text.ts:457-460, both on
  page.regions[].components[].properties.content.LOCALE, reason "the bundle has no
  content key for this component".
• Its 8 maps would cost almost nothing to key. All 8 sit on region-level components that
  do carry an id (heading_right_now, right_now_note, …) — regions.1.components.0,
  not slots.*. Its ledger already writes the target key it wants:
  ['pages', id(c), 'components', pageComponentId(c), 'content'].

That is the finding that most changes the shape of this decision: the two populations have
opposite costs. duly's 16 strings need one key added to an existing family and no node-path
scheme at all. This repo's 45 need a node-path scheme, a slots root, descent into
sections / items[].children, and two new key families — none of which the inline map
caused. Treating them as one class prices the cheap half at the expensive half's rate.

Four-facet decision block follows in the next comment, per the standing language rule.

Generated by Claude Code

---

Generated by Claude Code

[os-trump]

四维分析(decision block)

依据是上一条评论的实测数字,不是偏好。汇总一行:本仓 45 个 inline map / 180 条语言字符串,
全部在 packages/platform-objects/src/pages/ 的三个页面上;0/45 带 component id,
45/45 挂在 slots.*(walk 的 roots 只有 regions[].components[]);content / body
没有任何 bundle key 家族;coverage 基线 691 → 691,零位移;外部数据点 duly 实测为
8 个 map / 16 条字符串,8/8 带 id 且挂在 regions[]。

一、实际业务需求(实测拉动)

拉动真实存在,但很窄,而且落点不在 node-path 上。

• 写的人:只有平台自己的三个页面(45)和外部一个 app(duly 8)。四个 example app 里 一个都没有
  ——「谁在写这个键」的答案是「平台自己 + 一个真实部署」,不是「大量作者」。
• 读的人:pickLocalized / resolveI18nLabel 都已交付,这 53 个 map 渲染正常、语言齐全
  (本仓 45 个全部四语,duly 8 个全部双语,零缺失)。所以这里没有等待翻译的工作量;真实诉求是
  「可见性 / 可审计」,不是「待翻译队列」。
• 唯一有账可查的痛:duly 必须在 authored-text.ts:457-460 写两行 untranslatable 来解释这
  件事。这是实测拉动 —— 但它要的是 content 进 PAGE_COMPONENT_COPY_KEYS,它的 8 个节点
  已经带 id、已经在 regions[] 里,不需要任何 node-path 方案。
• 反过来说:本仓那 45 个才是需要 node-path 的那一半,而它们没有任何外部拉动——没有翻译者被
  它们挡住,没有 ledger 为它们记账,它们只是平台自己的页面。

轴向读数:拉动指向 A 最便宜的一角(一个 key 家族),不指向 A 的贵处(位置寻址)。

二、项目长远合理性(权重 ≥50%,推荐由本轴领起)

位置寻址的 key 会制造一个本仓至今没有的失效类:永远静默的错位。

• 今天这条线上 declared = enforced 是成立的:schema 声明两种形式,两个 resolver 都解析,
  component.zod.ts 的 I18nLabelSchema 键声明为纯字符串,但 3 个平台页在 31 处授权内联多语言 map #5728 / i18n: component-translation submitLabel copy key lost its only declared carrier when element:form retired (#9249) — decide retire vs re-anchor #10926 / PageTranslation.components has no key for element:text's content — the one string that element renders cannot be addressed by a bundle #14412 三次裁决把 inline map 定为正当路线。inline map 不是欠债,是契约。
• A 的真实代价不是工作量,是把数组下标变成契约。page:accordion 的 index 身份已经是交付
  契约(component.zod.ts:1690:renderer 派生 panel-INDEX,作者写的一律丢弃)。把下标写进
  bundle key,等于把「重排两个兄弟节点」变成一次静默的翻译错位:bundle 仍然完整、locale 仍然齐全、
  每一条门禁仍然全绿,只有屏幕上的两段文字换了位置。这与本仓一贯方向(declared = enforced、
  错就响亮拒绝)相反 —— 它新增的恰恰是门禁原理上看不见的一类错。
• 页面重命名是同一条的第二面:packages/cli/src / packages/spec/src/system / scripts 里
  没有任何 rekey / key-migration 机制(已搜,控制组通过)。一次重命名孤儿化整页的行,没有补救路径。
• 长远正解的形状是 identity 先于 key:section.name、tabs item.value、component.id
  三个身份槽都已存在,只是可选;packages/lint 甚至已经有 translation-section-name-missing
  规则在提示作者补 name(component.zod.ts:865-868)。把身份从「可选 + 提示」收紧为
  「必填 / 门禁强制」,是 contract-first 的做法;node-path 是绕过身份缺失的 workaround,直接撞上
  AGENTS.md 的 no-workarounds。
• 还有一条结构性理由:实测的四层里只有第 4 层与 inline map 有关。第 1 层(没有配置声明这些页面)、
  第 2 层(walk 不进 slots)、第 3 层(没有 key 家族 / 没有 id)是三个互相独立的缺陷。把它们
  打包进「要不要走 inline map」这一个决定里,会让一个真实且便宜的可见性缺陷,搭上一个有争议的
  key 方案的车 —— 三个可分别裁决的问题被绑成一个不可分的大问题。

轴向读数:长远轴单独就足以拒绝「以数组下标为 key」这一形状;它不拒绝「让这些字符串对翻译者可见」。

三、防 AI 写代码犯错(尤其 AI 编写的元数据 app)

这一轴是四轴里唯一双向的,如实呈现两面。

• 支持「必须做点什么」:今天 inline map 与「作者什么都没写」在 gate 眼里逐字节相同——
  inlineText() 对非字符串返回 undefined(i18n-extract.ts:384),于是 pushOptional
  把一个写全了四语的 map 记录成 unauthored。AI 作者认真写了 map,gate 说「缺翻译」;AI 作者
  什么都没写,gate 说同一句话。同一个诊断对应两个相反的事实,这是真实的致盲,而且正是
  AI 生成的元数据最容易踩的形状。
• 反对 node-path:重排 sections / items 是 AI 编辑元数据时最常做的操作之一。位置寻址会让
  一次语法完全正确、门禁全绿的重排静默弄错所有译文。AI 写元数据时最需要的是「写错就响亮拒绝」;
  node-path 给出的是「写对了也可能悄悄错」,方向正好相反。
• 真正的防错形状仍是身份:在编写时点要求 section.name / component.id(把已有的 lint 规则
  升格为门禁),错误就在作者面前被拒绝,而不是几个 release 之后在别的语言的屏幕上出现。

轴向读数:支持「区分 map 与未写」,反对「以下标为 key」。这两件事可以分开做。

四、创业阶段不扩散需求

• 面的绝对大小:全世界(本仓 + 已知外部 app)一共 53 个 map,且没有一个缺任何一种语言。
  没有任何用户在等这些字符串被翻译。
• A 会引入一个新的 bundle key 家族 —— 卡片自己写明了这一点(「Not a Clause-② change on its
  own unless A adds a documented bundle key family」)。新家族要文档、要迁移、要门禁、要重命名故事
  (今天没有)。为 53 个已经翻译完毕的字符串建一套位置寻址的 key 家族,是典型的无拉动扩张。
• C 的成本近似为零,而且它就是今天已经在做的事:i18n.zod.ts 的模块头已经写下这条排除,
  duly 的 ledger 已经在它那一侧记账。C 等于把现状文档化。
• 但 C 不解决第三轴的致盲(map 与「没写」不可区分),也不解决 duly 那两行 ledger。所以 C 不是
  免费的正确答案,它是「把一个已知的观测缺陷留在原地」。

轴向读数:从紧;任何扩张都需要按已实测的拉动裁剪,而已实测的拉动只有 duly 的一个 key。

本席不投票,以及一处契约冲突的申报

标准四维块要求给出 recommendation;本单派发词明确规定 A / B / C 的取舍是维护者的裁决、不由本席
选择,卡片自身的收尾条款也是这么写的。两者冲突,按契约在此点明而不悄悄选边:下面给出的是
测量逼出的问题重构,不是投票。

实测显示 A / B / C 这个选项集把三个可分离的决定绑成了一个,而且把两个成本相反的人群当成一类
(duly 的 16 条:一个 key 即可;本仓的 180 条:需要整套 node-path)。建议维护者按下面三问分别裁决:

1. content(以及 body)要不要进 PAGE_COMPONENT_COPY_KEYS? 这是 duly 唯一要的东西,
   零 node-path 成本。但它与 PageTranslation.components has no key for element:text's content — the one string that element renders cannot be addressed by a bundle #14412 刚刚裁定的「element:text 的 content 不加入
   PageTranslation.components」直接冲突 —— 只有维护者能翻自己的裁决,本席不预设方向。
2. gate 要不要把 inline map 与「作者什么都没写」区分开? 这是第三轴那条致盲,与任何 key 方案
   无关,也不需要 node-path:只要 pushOptional 不再把一个写全了的 map 记成 unauthored 即可。
   这一条即使 C 胜出也仍然值得单独裁。
3. node-path key 方案本身要不要走? 若要走,实测建议的先决条件不是「设计一套 node path」,
   而是先让身份必填(component.id / section.name / tabs item.value + 门禁强制),
   然后复用已有的 pages.PAGE.components.ID.KEY 家族。本仓 45 个节点今天一个 id 都没有,
   这件事本身就是 A 的真实前置工作量。

另外三条独立于本决定、已在上一条评论中记录的事实,供分诊:三个页面根本不在任何 extract config 里
(由 plugin 在运行时贡献);walk 的 roots 不含 slots;i18n.zod.ts 的散文说「31 个」而实测是
45 个。

Generated by Claude Code

---

Generated by Claude Code

[os-trump]

os-dev-report

{
  "issue": 14749,
  "status": "done",
  "branch": "claude/issue-14749-inline-i18nlabel-extraction-cost",
  "pr": null,
  "premise_still_valid": true,
  "summary": "Measurement unit, delivered as two card comments; NO PR and no repo change, which the dispatch names as a complete outcome. The card's premise holds — inline I18nLabel maps really are invisible to `os i18n extract` and `check:i18n-coverage` — but it is OVER-DETERMINED: the inline map is the fourth of four independent reasons, and fixing only it moves nothing. Population, derived from the schema (TS AST over every field typed I18nLabelSchema, then over all 5,564 repo .ts/.tsx files): 45 authored inline maps, all on three platform pages, 180 locale strings, every one carrying all four locales. Key-scheme cost: 0 of 45 carry a component id, 45 of 45 sit under `slots.*` which the walk never enters, and `content`/`body` have no bundle key family at all — so a node path would have to address array indices, which is already the delivered contract for page:accordion (`panel-INDEX`). Baseline projection for B: 691 before, 691 after, zero movement, nothing written to the baseline file. The external data point WAS measured after all — duly's issue #13 is unreadable from this seat but its repo is git-readable: 8 maps x 2 locales = 16 strings, reconciling the card's '16' as locale entries not maps, and all 8 sit on id-carrying region-level components, so duly needs no node-path scheme at all. That split — the two populations have opposite costs — is the finding that most changes the decision's shape. Four-facet block posted in Chinese; per the dispatch I did NOT pick between A/B/C.",
  "tests": "No build, no test suite, no gate run, and the shared verify lock was never taken — deliberate and declared: this unit changes no code, so there is nothing for a gate to judge, and `check:i18n-coverage` requires a full workspace build to lint twelve configs for a projection I derived statically. `pnpm install` in the worktree: exit 0, 9.2s (needed only for the TypeScript compiler used by the measurement rig, which lives in the scratchpad and ships nowhere). Every number instead carries a positive control with the same tool and flags: (1) population 45 by TS AST reproduces under an independent `grep -c \"'zh-CN':\"` = 33+6+6 on the three pages, with the same pattern returning 0 on examples/app-showcase/objectstack.config.ts; (2) the AST walk itself is controlled by 1,525 schema consts seen in packages/spec/src, so a zero would have been a broken scan; (3) a second, shape-anchored scan (any object literal whose keys are all real locale tags) finds 140 repo-wide and the 40 outside the schema-anchored set are all tests, resolver internals and locale bundles — so the schema-derived prop set misses no authored site; (4) the 'no rekey machinery' negative was run with a control grep for the same terms in the same trees, which returns hits (unmanaged tables, docs links) — so the pattern works and the absence is real; (5) duly's unreadability is a 403 where the identical curl returns 200 for this repo. Final commit: none — nothing was committed, so there is no sha to cite and the tree is byte-identical to origin/main at 5a5336b3 (`git status --porcelain` empty, `git diff --stat` against BASE empty, verified before the worktree was removed). The +9 projection was verified rather than assumed: the hand-authored `pages` subtree in all four platform-objects bundles carries only marketplace_installed / cloud_connection_settings / connect_agent, so sys_user_detail / sys_organization_detail / sys_position_detail are genuinely absent in all three non-source locales.",
  "mcp_calls": "6 — two add_issue_comment, one search_issues (dedupe, returned a live non-empty result so the channel is proven), one get_label, two issue_write. All bulk reading of the card and its comments went through the zero-quota web channel; the duly repo came in over anonymous git, not the API.",
  "open_questions": [
    {
      "question": "Should `content` (and `body`) join PAGE_COMPONENT_COPY_KEYS? This is the entire ask of the one external consumer, at zero node-path cost — but it directly reverses the #14412 ruling that element:text's `content` does not join PageTranslation.components.",
      "options": [
        "A1 — add `content` (+ `body`) to PAGE_COMPONENT_COPY_KEYS. duly's 8 maps become keyable immediately with no new scheme; its two `untranslatable` ledger rows retire. Reverses a ruling that is one day old.",
        "A2 — leave the key family as ruled. duly keeps its ledger rows; the reason recorded there stays accurate."
      ],
      "recommendation": "NO VOTE — the dispatch forbids this seat picking between the options and the card reserves them for the maintainer's inbox. What the measurement constrains: this is the only one of the three decisions with measured external pull, and it is the only one that costs nothing structurally. It is also the only one that reverses a fresh maintainer ruling, which is why it cannot be settled below the maintainer."
    },
    {
      "question": "Should the gate stop recording an inline map as `unauthored`? Today `inlineText()` returns undefined for a non-string, so `pushOptional` files a fully-translated four-locale map under the same shape as a key the author never wrote — one diagnostic for two opposite facts.",
      "options": [
        "B1 — distinguish them, without extracting anything: an inline map is recorded as authored-and-covered rather than unauthored. No key scheme, no node path, no new bundle family.",
        "B2 — leave it. The blinding stays, and any future author (human or AI) who writes a map is told the string is untranslated."
      ],
      "recommendation": "NO VOTE, same reason. The measurement's constraint: this is independent of every key-scheme question and survives even if C wins outright, so it should be ruled separately rather than bundled. It is also the only one of the three that the AI-error-prevention facet supports without a countervailing side."
    },
    {
      "question": "Should a node-path key scheme be built at all — and if so, is the precondition a node path or a required identity?",
      "options": [
        "C1 — design node-path keys (page id + node path + prop). Measured cost: array-index addressing at all 45 sites, on a repo with no rekey machinery, where index identity is already the delivered contract for page:accordion.",
        "C2 — require identity first (component.id / section.name / tabs item.value made mandatory and gate-enforced, promoting the existing `translation-section-name-missing` lint rule), then reuse the existing pages.PAGE.components.ID.KEY family unchanged.",
        "C3 — neither; document the exclusion (option C on the card)."
      ],
      "recommendation": "NO VOTE. The long-term-soundness facet, which carries at least half the weight, is the one that speaks loudest here and it speaks against C1 specifically: an index-keyed row turns a sibling reorder into a silently mis-ordered translation that leaves every gate green and every locale complete — a failure class no gate in this repo can see, in a codebase whose stated direction is declared = enforced. That is an argument about a SHAPE, not a vote between the three; the maintainer rules."
    },
    {
      "question": "Contract conflict, declared rather than quietly resolved.",
      "options": [
        "The standing four-facet contract requires a recommendation justified on all four axes.",
        "This card's dispatch and the card's own closing terms forbid this seat picking between A / B / C."
      ],
      "recommendation": "Followed the dispatch: the four facets are argued in full from the numbers, and the recommendation line is withheld with the conflict stated in the block itself. Flagging it here so the PM can settle which clause governs next time rather than each seat resolving it privately."
    }
  ],
  "out_of_scope_findings": [
    "filed as #14816 (labels finding / i18n / domain:spec): `i18n.zod.ts` states the inline-locale-map population as 31 in two docblocks; measured 45. The surrounding argument still holds (all 45 use en/zh-CN/ja-JP/es-ES) — only the number drifted. When it drifted is NOT MEASURED: this checkout is shallow.",
    "filed as #14817 (no labels, left for PM triage): the three shipped platform record pages are in no `os i18n extract` config — they are contributed at runtime by plugin-auth and plugin-security, neither of which has an extract config — so 48 authored I18nLabel-typed strings are unmeasured while platform-objects' coverage baseline of 0 reads as clean. This is the #5750 harm class recurring on the pages half after the nav half got its own gate. Independent of #14749's ruling.",
    "NOT FILED, reported here instead: `INLINE_LOCALE_KEY` accepts any 2-3 letter word, so `{ why: '...' }` parses as an inline locale map — it produced the one false positive in my scan. This is the schema's own documented boundary (`deu`, `fra` and every real three-letter subtag must still parse), not a defect, so filing it would manufacture work against a deliberate decision."
  ]
}

Generated by Claude Code

---

Generated by Claude Code