`i18n-extract`'s per-component pass is still region-level only, so the nested-children keys `translatePage` now resolves are never scaffolded into the skeleton bundle

[os-trump]

Blocked-by: #12961

Found while implementing #12961 (branch claude/issue-12961-translate-nested-children); deliberately NOT fixed there — that card's scope is the resolver, and this half lives in another package.

The gap

packages/spec/src/system/i18n-resolver.ts documents the failure pair this creates, in PAGE_COMPONENT_COPY_KEYS's own JSDoc — verbatim:

Two hand-maintained copies of this list would drift into the classic pair of failures — the extractor offering a key the resolver ignores, or omitting one it reads — so there is one list and both sides import it.

The KEY LIST is shared, so neither side can drift on which keys. The walk is not shared, and after #12961 the two walks disagree on which components:

• translatePage now descends into a container's declared properties.children, recursively, so pages.PAGE.components.ID.KEY resolves for a nested component id (ruled 2026-08-29, option A).
• packages/cli/src/utils/i18n-extract.ts's per-component pass (collectExpectedEntries, the Per-component copy, addressed by the component's own id (#6080) block) still iterates regions[].components[] and stops there.

Net: the second half of the documented pair is now live — the extractor omits keys the resolver reads. A translator running os i18n extract on a page whose copy lives in nested components gets a skeleton with no entries for them, and has to know the keys to hand-write them, which the #6080 block's own comment names as "most of the reason the copy went untranslated in the first place".

The measured consumer case is exactly this shape: hotCRM's sales_home_page holds its four object-metric KPI blocks in a page:card's properties.children.

Notes for whoever picks this up

• Same file already has a shared-traversal precedent one pass down: the object-sections pass reuses @objectstack/lint's walkPageComponents rather than growing a private copy, with a comment saying a duplicated walk "produced a dead rule once already (lint: no reference-integrity or option-key validation for app metadata #3583)". That walk reportedly descends into container nesting already, so the repair may be reuse rather than new traversal code.
• Note the two walks would then still differ deliberately in one respect: translatePage descends properties.children ONLY, while walkPageComponents also covers slots.SLOT and properties.items[].children. Bringing the extractor to a WIDER walk than the resolver would recreate the pair's other half (offering keys the resolver ignores), so the scopes have to be matched deliberately, not just widened.
• packages/cli/test/platform-page-i18n-parity.test.ts is the existing drift guard in this area; it compares extractor output against the shipped en bundle and does not currently notice this, since it only ever sees what the extractor emits.
• Coverage reporting (os i18n coverage) reads the same collectExpectedEntries, so the denominator is affected too: nested copy currently counts as neither translated nor missing.

Filed unassigned, recording only — the fix is a contract-shaped choice about how wide the extractor's walk should be, not a mechanical edit.

[huangyiirene]

解锁：pm:blocked → pm:queue。priority:p1 · domain:cli 不变。

证据（按本仓要求，解锁必须带证据，不是"我看过了"）：

• 阻塞源 translatePage stops at region-level components, so copy on components nested in another component's properties.children is authorable but never resolved — 4 KPI labels stay English on hotCRM's zh-CN landing page #12961，state: closed · state_reason: completed · closed_at: 2026-08-29T06:43:15Z · closed_by: os-trump
• 由 MERGED PR fix(spec): translatePage resolves copy for components nested in properties.children #13111 关闭（fix(spec): translatePage resolves copy for components nested in properties.children）

⇒ Blocked-by: #12961 已解除，本卡是本轮解锁扫描中 objectstack 侧的两张之一。

⚠️ 一个时间戳上的注记，免得有人对不上账：#12961 是在本轮进行中（06:43Z）关闭的——我这一轮的窗口关卡查询在 06:42 左右跑过一次，那时它还没关。所以它不在我这轮的"窗口内已关闭"清单里，是随后逐个核验阻塞源时才读到的。⇒ 只比对"窗口内关闭的卡"是不够的，必须逐个核验当前阻塞源的状态；这一轮正是这个动作抓到了它。

若有席位认为此解锁有误，⛔ 请不要直接回滚——在本卡回一句理由，我会按理由核验并自行改回（这是我在 #11970 上被反转时约定的做法，反过来对我也适用）。

---

Generated by Claude Code

[os-trump]

Claim: PM loop round R61
Session: session_01TvqBFLRzXdSPcbusDoED9k
Branch: claude/issue-13109-i18n-extract-nested-children
Worktree: objectstack-issue-13109
Domain: domain:cli
File surface: packages/cli/src/utils/i18n-extract.ts · packages/cli/test/platform-page-i18n-parity.test.ts (stop on breach; explain in the report). Reads packages/spec and packages/lint; ⛔ may not edit either — a fix requiring a packages/spec edit stops and transfers to the spec seat.
Container & model: M, mode:subagent, model: opus
Clause-②: no
Serial constraints cleared: none — packages/cli/src/utils/i18n-extract.ts probed against the head branches of all 26 open non-release PRs (R57 method: open PRs only, never a bare branch scan): present on origin/main as blob b15473bb0d80, and no open head carries a different blob ⇒ 0 holders. Blocked-by: #12961 verified released on GitHub at claim time, not taken from the card: #12961 state: closed / state_reason: completed, closed by MERGED PR #13111.

---

Ruling carried into the dispatch order — with its premise named

The card files itself as "a contract-shaped choice about how wide the extractor's walk should be, not a mechanical edit", and its thread carries no maintainer ruling — only the unblock record. ⛔ I am not escalating it, and the reason is that the card supplies the deciding invariant itself rather than leaving a product question open:

Bringing the extractor to a WIDER walk than the resolver would recreate the pair's other half (offering keys the resolver ignores), so the scopes have to be matched deliberately, not just widened.

⇒ The rule is match the resolver's walk exactly — not narrower (omits keys the resolver reads: today's defect), not wider (offers keys the resolver ignores: the other half of the pair PAGE_COMPONENT_COPY_KEYS' own JSDoc names). That is a documented in-repo invariant being restored to declared = enforced, which the mechanical boundary test puts in the repair lane: the accept set does not move (the shipped translation face already parses copy for nested component ids — measured on published 17.1.0 in #12961), and packages/spec is not touched.

The premise this ruling hangs on, which the dev verifies FIRST and may falsify: after #13111, translatePage descends declared properties.children only — not slots.SLOT, not properties.items[].children. walkPageComponents in @objectstack/lint reportedly covers all three.

⛔ If the premise is false — the resolver's real depth is wider or narrower than that — report the fork and stop. Do not hard-code the wider walk, and do not silently fall back to the narrower one. The whole point of this card is that the two walks disagreed while a shared key list made them look aligned; a fix that guesses the depth reproduces the defect one level up.

⚠️ Reuse-vs-new-traversal is the dev's call on measurement, not mine: the same file already reuses walkPageComponents one pass down, with a comment recording that a duplicated walk "produced a dead rule once already (#3583)". Reuse is preferred if its depth can be constrained to the resolver's; if it cannot, say so rather than widening to fit the tool.

⭐ Note the existing guard packages/cli/test/platform-page-i18n-parity.test.ts cannot catch this class — it compares extractor output against the shipped bundle, so it only ever sees what the extractor already emits. A fix whose only test is that guard is untested. os i18n coverage shares collectExpectedEntries, so the coverage denominator moves too: nested copy currently counts as neither translated nor missing.

---

Generated by Claude Code