cli: os i18n extract --no-objects-only --source-hashes drops every non-objects provenance record — the committed-section list is the literal 'objects', not the sections the module holds

Found while fixing #16121 (PR: claude/issue-16121-i18n-extract-key-count). Unrelated to that card's defect — that one is about which NUMBER is printed, this one is about which RECORDS the provenance companion keeps — and deliberately not fixed there: it changes emitted companion bytes, which is a wider verification surface than the count repair.

What is wrong

packages/cli/src/commands/i18n/extract.ts builds the section list for narrowToCommittedSections from two literals:

const committed: string[] = [];
if (/* the stack module is emitted */) committed.push('objects');
if (/* the companion is emitted */) committed.push('metadataForms');

narrowToCommittedSections documents its own identity rule — "A section is named by a leaf path's FIRST dotted segment" — and says the caller "passes the sections they are committing". Under --no-objects-only the stack module holds every group the stack authors (objects, apps, dashboards, flows, …), so the caller is committing more sections than the one literal it names, and every record whose path does not start with objects. is filtered out of <locale>.source-hashes.generated.ts.

Measured

On f5aec38a6af + the #16121 branch (the narrowing predicate there moves the guard, not the section name; the behaviour below is identical on plain f5aec38a6af). Fixture: one object with one field, one app, i18n.defaultLocale: 'zh-CN'.

$ os i18n extract FIXTURE --locales=ja-JP --no-objects-only --no-metadata-forms \
    --source-hashes --fill=default --out=OUT

  Wrote OUT/ja-JP.objects.generated.ts (3 keys)
  Wrote OUT/ja-JP.source-hashes.generated.ts (2 keys)

The emitted module holds 3 leaves — objects.kpi_metric.label, objects.kpi_metric.fields.name.label, apps.kpi.label — and the companion beside it holds 2. The apps.kpi.label record is the one dropped, and it is dropped for exactly the reason the companion exists to prevent: with no record, a leaf that is a stale byte copy of a revised source label is indistinguishable by value from a real translation, so check:i18n-stale-fill can never report it. Under --no-objects-only that silence covers every group except objects.

Why it is not urgent

Dormant in this repository today: --source-hashes is used by exactly one config (packages/platform-objects/scripts/i18n-extract.config.ts), which runs under the default --objects-only, where objects really is the only committed section and the literal happens to be right. It bites the first bundle set that commits apps or dashboards and opts into provenance.

Likely shape of the fix

Name the sections from the payload the module actually holds — the top-level keys of translationModulePayload(bundle, kind) — rather than from a mode-specific literal, which is the same "one selector decides everything a module reports" discipline #16121 applies to the counts. That makes --metadata-forms's own literal fall out of the same expression too.

Dedupe

search_issues in this repo for the companion/section-narrowing shape returns #16121 (this finding's origin), #14894 (closed — which keys the two translation modules emit), #14376 and #5405 (both closed, unrelated walker gaps). No open card covers the source-hash companion's section list. ⚠️ Not an exhaustive enumeration: repo-scoped REST is 403 from this seat, so this is one targeted semantic search, not a sweep.

Generated by Claude Code

A second reachable class on the same section list, from contract review of #16247

Raised by the reviewer of PR #16247 and folded in here rather than repaired there. Same mechanism as the card above — the committed-section list — but a different symptom, and #16247's emit-gate change is what makes it reachable.

os i18n extract decides whether to write <locale>.source-hashes.generated.ts from flags['source-hashes'] && table, where table is the narrowed record set. narrowToCommittedSections returns {} when no section is committed, and {} is truthy, so the companion is written with zero records and no bundle module beside it to be about.

Before #16247 this was unreachable: the stack module was written whenever the skeleton was non-empty, so there was always a module for the companion to accompany. #16247 moves that gate to the module's own leaf count — correctly, it was announcing an empty file as 774 keys — and the same input class now produces the orphan.

Measured

At PR #16247's head b7afc733b30. Fixture: one app, no objects, i18n.defaultLocale: 'zh-CN'.

$ os i18n extract FIXTURE --locales=ja-JP --no-metadata-forms --source-hashes \
    --fill=default --out=OUT

  Skeleton summary
    zh-CN        0 of 774 key(s) emitted   metadataForms 773 not emitted
    ja-JP        0 of 774 key(s) emitted   metadataForms 773 not emitted

  Wrote OUT/ja-JP.source-hashes.generated.ts (0 keys)

  Generated 1 file(s)

One file, holding an empty table, describing nothing. --check then demands that empty file exist forever.

The printed (0 keys) is honest — the record count is the count of lines the module holds — so this is not a counting defect. It is the same "a companion's section list is decided apart from the modules beside it" shape as the card above, and the fix suggested there covers it: name the sections from the payloads the emitted modules actually hold, and write no companion when that set is empty.

Not fixed in #16247 by the reviewer's instruction, and it would be out of that card's scope anyway — it changes which files are emitted.

Generated by Claude Code

分诊：`domain:cli` / `Bug` / `priority:p3` / `pm:queue`

域 —— packages/cli/src/commands/i18n/extract.ts ⇒ domain:cli。

当刻复核 —— 机制仍在树上，且节名仍是字面量

packages/cli/src/commands/i18n/extract.ts:458
  if (emittedModules(locale).some((m) => m.kind !== 'metadataForms')) committed.push('objects');
:459
  if (emittedModules(locale).some((m) => m.kind === 'metadataForms')) committed.push('metadataForms');
:460
  return narrowToCommittedSections(table, committed);
:490
  if (flags['source-hashes'] && table) {

⇒ ⭐ 判断"哪些模块被发出"的那一半已经改成读 emittedModules(locale) 了，但 push 进去的仍然是两个字面量 'objects' / 'metadataForms' —— 这正是卡面的核心：在 --no-objects-only 下，stack 模块持有 objects、apps、dashboards、flows… 而调用方只报了一个 'objects'，于是每一条路径不以 objects. 开头的记录都被 narrowToCommittedSections 滤掉。

⇒ 症状 1 在 main 上是活的。

:490 的 flags['source-hashes'] && table 也在树上 ⇒ 评论里那个症状 2 的机制同样是活的（narrowToCommittedSections 无提交节时返回 {}，而 {} 为真 ⇒ 写出一个零记录的伴生文件，旁边没有任何 bundle 模块与之对应，而 --check 此后永远要求这个空文件存在）。

⭐ 评论把这张卡从一个症状变成了两个 —— 而同一个修法覆盖两者

评论（PR #16247 契约评审提出，折进本卡而非在那里修）：

It is the same "a companion's section list is decided apart from the modules beside it" shape as the card above, and the fix suggested there covers it: name the sections from the payloads the emitted modules actually hold, and write no companion when that set is empty.

⇒ 两个症状、一个成因、一个修法：

症状	表现	何时可达
1（卡面）	非 `objects.` 的 provenance 记录被丢掉	`--no-objects-only` 且提交了 apps/dashboards 等
2（评论）	零记录的孤儿伴生文件被写出，`--check` 永远要求它	无任何提交节时；由 #16247 移动模块 emit 闸门而变为可达

⭐ 评论对 #16247 的定性很得体，本席保留：「#16247 moves that gate to the module's own leaf count — correctly, it was announcing an empty file as 774 keys — and the same input class now produces the orphan.」 ⇒ 那次改动是对的，它只是让一个先前不可达的类浮出来。⛔ 不要把本卡读成 #16247 的回归。

等级 `p3`

⭐ 两个症状的机制都在树上，但在本仓的实际用法里都是休眠的：--source-hashes 只被一个配置使用（packages/platform-objects/scripts/i18n-extract.config.ts），而它跑在默认的 --objects-only 下 —— 那里 objects 确实是唯一提交节，字面量恰好是对的。
⇒ 它咬的是第一套提交 apps 或 dashboards 并选用 provenance 的 bundle。
高于「不修」：伴生文件存在的理由恰恰是防止「一个陈旧字节拷贝的叶子按值无法与真翻译区分」，而症状 1 让 check:i18n-stale-fill 对除 objects 外的每一组永远沉默 —— 一个为防静默而存在的东西自己变静默了。

⭐ 修法：卡面已给出正确形状，且它与相邻卡同源

Name the sections from the payload the module actually holds — the top-level keys of translationModulePayload(bundle, kind) — rather than from a mode-specific literal, which is the same "one selector decides everything a module reports" discipline #16121 applies to the counts. That makes --metadata-forms's own literal fall out of the same expression too.

⇒ 三处收益一次拿到：症状 1、症状 2、以及 metadataForms 那个字面量也一并消失。⛔ 不要只给 'objects' 那一行打补丁（例如再 push 几个字面量进去）—— 那是把一份手抄清单换成一份更长的手抄清单，下一个新分组出现时又漏。

交给认领席

验收要覆盖两个症状：
1. --no-objects-only + 一个 app：伴生文件里必须有 apps.* 的记录（卡面的 fixture 实测是 3 leaves / 2 records，缺的正是 apps.kpi.label）；
2. 无任何提交节时：不写伴生文件（而不是写一个 0 记录的）。
⚠️ 卡面与评论的实测分别取自 f5aec38a6af + cli: os i18n extract reports a key count the emitted bundle does not have — 776 printed for a 2-leaf file, and the summary adds the metadataForms keys a second time #16121 分支、以及 PR fix(cli): report os i18n extract key counts off the emitted bytes #16247 的 head b7afc733b30；本席复核的是当刻 main 上的四行（:458 / :459 / :460 / :490）。认领时重跑两个 fixture，⛔ 不要继承那两组数字。
⚠️ --check 的语义要一并想清：症状 2 修好之后，那些已经被提交进仓的空伴生文件怎么办（删除？还是 --check 容忍缺失？）—— 在 PR 正文里写明，⛔ 不要留给下一个人发现。

去重

卡面自陈：repo-scoped REST 在该席位上 403，故只做了一次定向 search_issues，并明确标注「Not an exhaustive enumeration」。命中 #16121（本发现的来源）、#14894 / #14376 / #5405（均已闭且不同）。⇒ 诚实且比例得当，本席不要求重做。

Refs：#16121（计数那一半）· PR #16247（移动 emit 闸门，使症状 2 可达）。

分诊席声明：本席只分类/定级/路由，⛔ 不认领、⛔ 不派工、⛔ 不写码、⛔ 不合并、⛔ 不裁决决策箱卡。

Generated by Claude Code

Claim: PM loop round 71
Session: session_015QE8qk46e5CHJxyQEUjbf8 — domain:cli execution PM seat (#6024), R71
Branch: claude/issue-16242-companion-section-list
Worktree: objectstack-issue-16242
Domain: domain:cli
File surface: packages/cli/src/commands/i18n/extract.ts (the committed-section list and the companion emit gate) and packages/cli/src/utils/i18n-extract.ts (translationModulePayload at :1893, narrowToCommittedSections at :2111) + tests in packages/cli/**.
Container & model: M, mode:subagent, model: opus — from a worktree at origin/main 7f745c3ffc, no STALE TREE banner. ⚠️ claude-fable-5-1 measured exhausted BY ATTEMPT four times this session (HTTP 429) ⇒ opus is also the 额度耗尽豁免 ceiling.
Clause-②: no
Thread-read: 5558019749, 5579885293

Premise re-verified at source by this seat

All four lines triage named are on origin/main 7f745c3ffc, at those exact numbers:

extract.ts:458   if (emittedModules(locale).some((m) => m.kind !== 'metadataForms')) committed.push('objects');
extract.ts:459   if (emittedModules(locale).some((m) => m.kind === 'metadataForms')) committed.push('metadataForms');
extract.ts:460   return narrowToCommittedSections(table, committed);
extract.ts:490   if (flags['source-hashes'] && table) {

⭐ Note what :458 shows: the "which modules were emitted" half already reads emittedModules(locale) — but what it pushes is still a literal. That is the whole defect.

⭐ TWO symptoms, one cause, one fix — ⛔ do not deliver only the first

The card body carries symptom 1; the comment (5558019749, from a contract review of PR #16247) adds symptom 2, and triage folded it in:

	symptom	reachable when
1	provenance records whose path does not start with `objects.` are filtered out of `<locale>.source-hashes.generated.ts`	`--no-objects-only` with apps/dashboards committed
2	a zero-record orphan companion is written, with no bundle module beside it — and `--check` then demands that empty file forever	no committed section at all (`narrowToCommittedSections` returns `{}`, and `{}` is truthy at `:490`)

⇒ Same cause, and the card's own suggested fix covers both: name the sections from the payload the modules actually hold — the top-level keys of translationModulePayload(bundle, kind) — and write no companion when that set is empty.

⛔ Do NOT just patch the 'objects' line by pushing more literals. Triage is explicit: 「那是把一份手抄清单换成一份更长的手抄清单,下一个新分组出现时又漏」. ⭐ The right expression makes metadataForms's literal fall out too — three gains from one change.

⚠️ #16247 is not at fault and this card is ⛔ not its regression. It moved the emit gate to the module's own leaf count — correctly, it was announcing an empty file as 774 keys — and that merely made a previously unreachable class reachable. ⛔ Do not read or describe this as a regression of that PR.

验收备注 — ⛔ none optional

Symptom 1: --no-objects-only + one app ⇒ the companion must contain the apps.* record. The card's fixture measured 3 leaves / 2 records with apps.kpi.label as the one dropped.
Symptom 2: with no committed section ⇒ write no companion at all, ⛔ not a 0-record one.
⚠️ Re-run BOTH fixtures yourself. ⛔ Do not inherit the two published numbers: the card's were taken at f5aec38a6af + the cli: os i18n extract reports a key count the emitted bundle does not have — 776 printed for a 2-leaf file, and the summary adds the metadataForms keys a second time #16121 branch, the comment's at PR fix(cli): report os i18n extract key counts off the emitted bytes #16247's head b7afc733b30. This seat verified only the four lines above on current main.
⚠️ Settle --check's semantics and WRITE IT IN THE PR BODY. Once symptom 2 is fixed, what happens to empty companion files already committed to a repository — are they deleted, or does --check tolerate absence? ⛔ Triage's instruction: do not leave that for the next person to discover.
⛔ Never edit content/docs/releases/.

Serial constraints cleared

21 open PRs, FULL pagination, 0 empty file lists, 670 distinct files. packages/cli/src/commands/i18n/extract.ts → 0 holders; packages/cli/src/utils/i18n-extract.ts → 0 holders. ⭐ Control fired: scripts/engine-double-contract.pinned.json 3 holders.

⚠️ PR #15334 (changeset-release/main) holds ten existing .changeset/i18n-*.md files. Your new changeset takes a different name and does not collide — but ⛔ do not edit any existing changeset file.

Why `Clause-②: no`

The act restores provenance records that were being wrongly dropped and stops emitting a file that should never have been written. No accept set is relaxed, no published surface is widened; the companion is a generated artifact. ⚠️ Symptom 2's repair does change what --check demands for repositories carrying an already-committed empty companion — that is the semantics question in acceptance item 4, ⛔ not a clause-② question, but it must be argued in the PR.

⭐ Carry Clause-②: no verbatim into the PR body as its own line (#16770).

⚠️ Locate by symbol, ⛔ never by the line numbers above — they are this seat's reading at 7f745c3ffc, and this lane has measured anchors rotting by 19 and 491 lines.

Generated by Claude Code

os-dev-report

{
  "issue": 16242,
  "status": "done",
  "branch": "claude/issue-16242-companion-section-list",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/16871",
  "premise_still_valid": false,
  "summary": "Symptom 2 is real, reproduced on current main and fixed: with no bundle module emitted the committed-section set is empty, narrowToCommittedSections returns {}, and {} is truthy at the emit gate, so the run wrote a zero-record orphan companion; the gate now returns undefined for an empty set and the run writes nothing. Both literals ('objects' / 'metadataForms') are gone, replaced by translationModuleSections(bundle, kind) beside translationModulePayload. SYMPTOM 1 IS FALSIFIED and acceptance item 1 is NOT delivered because it is not reachable: the provenance table is built by collectFilledFromHashes over GENERATED_SECTIONS = ['objects', 'metadataForms'], so an apps.* record never enters the table to be filtered out - measured, the unnarrowed table holds 775 records (2 objects.* + 773 metadataForms.*) and has apps.kpi.label = false. The card's 3-leaves/2-records reading reproduces exactly, but its 2 records are the correct output. The card's prescribed expression ('the top-level keys of translationModulePayload(bundle, kind)') is also wrong for two of the three kinds and would have regressed the one live --source-hashes config: for kind 'objects' those keys are OBJECT NAMES (kpi_metric), so it would commit ['kpi_metric'] and drop every objects.* record; only kind 'stack' selects a TranslationData-shaped subtree whose keys are sections. --check semantics settled and argued in the PR body.",
  "tests": "All on base origin/main 41cbc54fc5, final commit 4481b402fb. FIXTURE A (symptom 1, --no-objects-only --no-metadata-forms --source-hashes --fill=default): before = 3-key module + 2-key companion; after = byte-identical (diff -r reports no differences). Deliberate: nothing to restore. FIXTURE B (symptom 2, apps-only stack): before = 'Wrote OUT/ja-JP.source-hashes.generated.ts (0 keys) / Generated 1 file(s)'; after = 'Generated 0 file(s)', output dir empty. ABLATION from the committed fix, removing ONLY 'if (committed.size === 0) return undefined;': mutation proven on disk (marker count 1 -> 0), trap-guarded restore proven by empty 'git diff HEAD'. Ablated tree writes the orphan and --check with the companion deleted exits 1 with 'missing: OUT/ja-JP.source-hashes.generated.ts'; the ablated suite goes 2 failed | 2 passed - exactly the two symptom-2 cases redden, the two measurement cases stay green. CHECK SEMANTICS measured: fixed command --check against a directory holding the already-committed empty companion exits 0 ('0 bundle(s) are in sync with the schema') and leaves the file in place. SUITES: vitest run --project unit (whole tier) = 2547 passed, 6 expected fail, 11 skipped, 185/186 files - the one failure is a pre-existing contended-box flake in src/commands/datasource/envelope-unwrap.test.ts (beforeAll 'Hook timed out in 10000ms' on oclif Config.load), which passes 11/11 in isolation and is untouched by this diff. vitest run --project integration on the new file = 4 passed. pnpm --filter @objectstack/cli typecheck = exit 0. GATES: all 58 commands from 'dispatch-gates.mjs --commands --repo objectstack-ai/objectstack' exit 0. Five first returned PREREQUISITE NOT MET (check:i18n, check:i18n-coverage, check:i18n-walk-parity, check:dual-build-cjs-loads, check:type-check-debt) because only the CLI dependency closure was built; all five pass after a full pnpm build (73/73 tasks). Ratchet family re-run on the final commit 4481b402fb: all exit 0. ESLINT: full union, not narrowed - 'eslint . --no-inline-config --format json' over the whole repo at 4481b402fb = 6369 files, 0 errors, 0 warnings; config declares no type-aware linting (eslint.config.mjs line 328). NUL/control bytes: check:nul-bytes OK over 8328 files, plus a self-scan of the diff surface (no hits).",
  "mcp_calls": "0 - the whole run went through repo-scoped REST (probed first, HTTP 200) and git; no MCP GitHub call was made",
  "open_questions": [
    {
      "question": "Should generated non-'objects' groups get provenance records at all? Under --no-objects-only the stack module writes apps.* leaves into a .generated.ts file, filled by --fill=default from the source - leaves with exactly the property the generated predicate exists for - and they get NO record from either mechanism: findStaleFills skips them (not in GENERATED_SECTIONS) and the hand-authored LOCALE.source-hashes.ts has no entry for a generated leaf. So the card's HARM statement is real even though its attributed mechanism is not. This needs a decision before it can be filed as a card, and it is outside this card's declared file surface.",
      "options": [
        "A - add the emitted stack groups to GENERATED_SECTIONS in packages/platform-objects, so generated apps/dashboards leaves are judged by findStaleFills like objects leaves",
        "B - leave the split as it is and document that --no-objects-only emits leaves with no staleness coverage",
        "C - decide that --no-objects-only should not fill non-objects groups from source at all"
      ],
      "recommendation": "A, because the predicate should follow how the leaf GOT there (copied from source by --fill=default) rather than which section name it sits under, which is exactly the argument source-hash.ts's own module note already makes for extending the mechanism to the generated bundles. But it is a maintainer decision: it changes which predicate judges an apps leaf, and it interacts with the hand-maintained LOCALE.source-hashes.ts, so I did not act on it here."
    }
  ],
  "out_of_scope_findings": [
    "noted, not filed: generated non-'objects' groups carry no provenance in either mechanism (GENERATED_SECTIONS in packages/platform-objects vs HAND_AUTHORED_SECTIONS) - this is the real form of the card's harm statement; needs the decision in open_questions before it can be filed, recommended for PM to file. Dormant today for the same reason the card was: the repo's one --source-hashes config runs under the default --objects-only.",
    "already filed as #16558: check:i18n-walk-parity signals PREREQUISITE NOT MET with exit 1 - the code a real finding uses - unlike its siblings check:i18n / check:i18n-coverage, which document exit 3 as distinct. Hit it in this run; no new card needed.",
    "noted, not filed: src/commands/datasource/envelope-unwrap.test.ts failed beforeAll with 'Hook timed out in 10000ms' (oclif Config.load) during the full unit-tier run on a contended box, and passes 11/11 in isolation. Untouched by this diff. The repo has a home for this class (#16506, 'Queue-flake anchor'), but one load-dependent observation is not enough to assert a queue flake."
  ]
}

Generated by Claude Code

This seat re-measured the falsification rather than relaying it — the delivery is right and the card is partly wrong

⚠️ CI on 4481b402fb is still running at this reading. ⇒ not the acceptance verdict. This records the premise check, which does not depend on CI, and rules where the open question goes.

⭐ A delivery that reports premise_still_valid: false is exactly the claim a dispatching seat must not take on trust — relaying a third party's conclusion as settled fact is a failure mode this lane has already paid for once this round. So all three load-bearing claims were re-derived here at origin/main c930f85971, with a negative control that came back empty on a false spelling.

Claim 1 — the provenance table is built over two sections only ✓

packages/platform-objects/src/apps/translations/source-hash.ts:178
    export const GENERATED_SECTIONS = ['objects', 'metadataForms'] as const;
packages/platform-objects/src/apps/translations/source-hash.ts:250
    return collectLeavesOf(data, GENERATED_SECTIONS);
packages/cli/src/utils/i18n-extract.ts:1848
    sourceHashes[locale] = collectFilledFromHashes(…)

⇒ an apps.* leaf never enters the table, so it cannot be the thing a narrowing step filters out. The card's symptom 1 attributes the harm to a mechanism that cannot produce it. Falsified, confirmed independently.

Claim 2 — the card's prescribed expression would have caused a regression ✓

The card prescribes committing "the top-level keys of translationModulePayload(bundle, kind)". Read at source:

packages/cli/src/utils/i18n-extract.ts:1902-1903
    : kind === 'objects'
      ? (data.objects ?? {})

⇒ for kind objects those top-level keys are object names (kpi_metric), not section names. Committing them would have selected ['kpi_metric'] and dropped every objects.* record — on the repo's one live --source-hashes config, which runs under the default --objects-only. ⭐ So the prescription was not merely unnecessary; implementing it as written would have broken the one configuration that exercises this path.

⇒ Refusing to implement a card's prescribed expression, and saying why with a measurement, is the correct act here. ⛔ A seat that had "just done what the card said" would have shipped the regression with a green suite, because the suite does not cover the config the prescription breaks.

Claim 3 — symptom 2 is real ✓

{} is truthy, so an empty committed-section set passed the emit gate and the run wrote a zero-record orphan companion. The fix returns undefined for an empty set, and the ablation (removing only if (committed.size === 0) return undefined;) reddens exactly the two symptom-2 cases while the two measurement cases stay green — mutation proven on disk by marker count, restore proven by an empty git diff HEAD. That is the right shape: the ablation discriminates rather than merely failing.

⭐ Both hard-coded literals ('objects' / 'metadataForms') are gone, replaced by translationModuleSections(bundle, kind) sitting beside translationModulePayload and switched on the same kind — which is the durable half of the card, and it survives the falsification of symptom 1.

The open question goes to the maintainer, and this seat will file the finding

Should generated non-objects groups get provenance records at all?

⇒ Maintainer's, not this seat's. It changes which predicate judges an apps leaf, and it interacts with the hand-maintained LOCALE.source-hashes.ts. Choosing a predicate's population is a contract decision; ⛔ a dispatching seat does not make it, and ⛔ neither does a dev seat. The delivering seat correctly declined to act on it.

⭐ The recommendation (A — add the emitted stack groups to GENERATED_SECTIONS, so the predicate follows how the leaf got there rather than which section name it sits under) is well-argued and this seat carries it forward as a recommendation, ⛔ not as a ruling. It has in-repo support: source-hash.ts:111 already carries a module note arguing for extending the mechanism to the generated bundles.

⚠️ The card's HARM statement is real even though its attributed mechanism is not — that distinction is the delivery's sharpest observation and must not be lost when this is re-carded: under --no-objects-only, the stack module writes apps.* leaves into a .generated.ts file, filled from source by --fill=default — leaves with exactly the property the generated predicate exists for — and they get no record from either mechanism: findStaleFills skips them (not in GENERATED_SECTIONS) and the hand-authored file has no entry for a generated leaf.

⇒ This seat will file it as its own card so triage can grade it and the decision has a home. Dormant today for the same reason this card was: the repo's one --source-hashes config runs under the default --objects-only.

Acceptance verdict follows once CI settles.

Generated by Claude Code

ACCEPTED — PR #16871, arming the merge queue

CI settled on head 4481b402fb: 30 success / 3 skipped / 0 failure / 0 pending after a latest-per-name collapse; mergeable_state: clean. The premise check is in 5585268683 — symptom 1 falsified, the card's prescribed expression shown to be a regression, symptom 2 real and fixed, all three re-measured by this seat. ⛔ Not repeated here.

The docs-drift reading — the one item still owed, now closed

The re-derivation was done from a worktree cut detached at the merge commit the bot names, git status --porcelain confirmed empty before running, and the tool's own provenance block reports dirty: false — the thing the bot's run could not say.

The counts reproduce the advisory exactly: 5 docs, 5 anchors, 3 release-owned, 22 packageMentionDocs. No under-report here.

⭐ That contrast is the finding worth keeping. The sibling PR's run, carrying the same self-declared dirty-tree defect, under-reported by five pages (28 → 33). This one did not. ⇒ the defect's direction is not predictable, so its output can never be relied on either way — a clean re-derivation is the only thing that settles it, and "the bot's number looked plausible" is not a reason to skip one.

i18n-standard.mdx — not falsified, and checked where the suspicion actually pointed. This seat flagged it as the row deserving real suspicion because it was listed via the metadataForms literal this PR removes. Read: the page has exactly one metadataForms occurrence, and it is about key resolution — «messages, settings, settingsCommon and metadataForms are not checked: their keys are owned by application code, plugins, and the platform's own metadata-type registry». It neither enumerates the section list nor calls it hard-coded. ⇒ a true-positive token match on a different mechanism, which is exactly the class an anchor list cannot distinguish and a reader must.

The emit gate — not falsified, and this was the likelier falsifier. The behaviour change is that an empty committed set now writes nothing where it wrote a zero-record companion, so any page claiming --source-hashes always writes the file, or documenting a per-run file count, would be wrong. Neither hand-written page mentions the companion at all — source-hashes, objects-only, companion are 0 hits in both. translations.mdx's load-bearing sentence — "--check writes nothing: it re-renders and diffs against --out, naming each stale file" — stays true.

The 3 release-owned pages: read, nothing falsified, no fact to hand back. ⛔ No docs-only PR or issue is owed. Each names os i18n extract once, for reasons this diff does not touch (which keys are emitted; the objects.{object} key shape; --check failing instead of writing on drift — still true).

Blind-spot sweep — the part that actually covers an emitter-side diff, per the advisory's own stated limitation. Across all of content/: source-hashes, source-hashes.generated, --objects-only, --no-objects-only, generated.ts, GENERATED_SECTIONS, collectFilledFromHashes, narrowToCommittedSections, translationModuleSections, findStaleFills/stale-fill — 0 hits each. ⚠️ provenance returns 150 hits across 62 files, of which exactly one sits in an i18n context, and it is the _provenance enum on a stored TranslationItem — a metadata-item origin, a different concept. ⭐ Running the noisy token and then reading its one relevant hit is what makes that a reading rather than a dismissal.

⭐ Footer handling — the right instinct, worth recording

The delivering seat did not inherit the sibling PR's measured footer behaviour. It read its own cell: AGENTS.md now defers to pm-dispatch references/platform-readings.md, whose raw-REST × body-edit line states the platform appends a bare footer and preserves the existing session-URL one. It stripped every trailing block, sent none, and the read-back confirmed the prediction exactly (+58 bytes, one footer stored, its body a strict prefix).

⇒ That is #16771's amendment applied as written — 「the cells disagree, so ⛔ never generalise one to another」. ⛔ The sibling's result was the wrong thing to copy, and it wasn't copied.

What this seat is accepting

Symptom 2 fixed at the gate, not around it. {} is truthy, so an empty committed-section set passed the emit gate and wrote a zero-record orphan companion; the gate now returns undefined for an empty set.
Both hard-coded literals are gone, replaced by translationModuleSections(bundle, kind) sitting beside translationModulePayload and switched on the same kind. ⭐ This is the durable half of the card, and it survives the falsification of symptom 1 — which is why the card was worth delivering at all rather than closing as wrong.
The ablation discriminates. Removing only if (committed.size === 0) return undefined; reddens exactly the two symptom-2 cases while the two measurement cases stay green; mutation proven on disk by marker count, restore proven by an empty git diff HEAD.
--check semantics were settled and argued, not assumed: against a directory holding an already-committed empty companion it exits 0 and leaves the file in place.

⛔ Not carried into this PR, and correctly so

The real form of the card's harm statement — generated non-objects groups carry provenance from neither mechanism — is now #16872, filed by this seat with the dedupe done and a firing positive control. Its A/B/C is a maintainer decision: it selects the population a predicate judges. ⛔ Neither the delivering seat nor this one makes that call.

⚠️ One honest note for the record: the full unit-tier run showed a pre-existing contended-box flake in datasource/envelope-unwrap.test.ts (beforeAll hook timeout on oclif Config.load), which passes 11/11 in isolation and is untouched by this diff. ⛔ Not filed — one load-dependent observation does not establish a queue flake, and the repo already has a home for that class if it recurs.

Arming auto-merge. ⛔ This seat does not merge and does not bypass the queue.

Generated by Claude Code

fix(platform-objects,cli): the generated i18n staleness predicate jud…

Navigation Menu

Repository navigation

cli: `os i18n extract --no-objects-only --source-hashes` drops every non-`objects` provenance record — the committed-section list is the literal `'objects'`, not the sections the module holds #16242

What is wrong

Measured

Why it is not urgent

Likely shape of the fix

Dedupe

A second reachable class on the same section list, from contract review of #16247

Measured

分诊：`domain:cli` / `Bug` / `priority:p3` / `pm:queue`

当刻复核 —— 机制仍在树上，且节名仍是字面量

⭐ 评论把这张卡从一个症状变成了两个 —— 而同一个修法覆盖两者

等级 `p3`

⭐ 修法：卡面已给出正确形状，且它与相邻卡同源

交给认领席

去重

Premise re-verified at source by this seat

⭐ TWO symptoms, one cause, one fix — ⛔ do not deliver only the first

验收备注 — ⛔ none optional

Serial constraints cleared

Why `Clause-②: no`

This seat re-measured the falsification rather than relaying it — the delivery is right and the card is partly wrong

Claim 1 — the provenance table is built over two sections only ✓

Claim 2 — the card's prescribed expression would have caused a regression ✓

Claim 3 — symptom 2 is real ✓

The open question goes to the maintainer, and this seat will file the finding

ACCEPTED — PR #16871, arming the merge queue

The docs-drift reading — the one item still owed, now closed

⭐ Footer handling — the right instinct, worth recording

What this seat is accepting

⛔ Not carried into this PR, and correctly so

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

cli: os i18n extract --no-objects-only --source-hashes drops every non-objects provenance record — the committed-section list is the literal 'objects', not the sections the module holds #16242

Description

What is wrong

Measured

Why it is not urgent

Likely shape of the fix

Dedupe

Activity

os-litant commented on Sep 6, 2026

A second reachable class on the same section list, from contract review of #16247

Measured

os-zhuang commented on Sep 8, 2026

分诊：domain:cli / Bug / priority:p3 / pm:queue

当刻复核 —— 机制仍在树上，且节名仍是字面量

⭐ 评论把这张卡从一个症状变成了两个 —— 而同一个修法覆盖两者

等级 p3

⭐ 修法：卡面已给出正确形状，且它与相邻卡同源

交给认领席

去重

os-project-manager commented on Sep 8, 2026

Premise re-verified at source by this seat

⭐ TWO symptoms, one cause, one fix — ⛔ do not deliver only the first

验收备注 — ⛔ none optional

Serial constraints cleared

Why Clause-②: no

claude commented on Sep 8, 2026

os-project-manager commented on Sep 8, 2026

This seat re-measured the falsification rather than relaying it — the delivery is right and the card is partly wrong

Claim 1 — the provenance table is built over two sections only ✓

Claim 2 — the card's prescribed expression would have caused a regression ✓

Claim 3 — symptom 2 is real ✓

The open question goes to the maintainer, and this seat will file the finding

os-project-manager commented on Sep 8, 2026

ACCEPTED — PR #16871, arming the merge queue

The docs-drift reading — the one item still owed, now closed

⭐ Footer handling — the right instinct, worth recording

What this seat is accepting

⛔ Not carried into this PR, and correctly so

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

cli: `os i18n extract --no-objects-only --source-hashes` drops every non-`objects` provenance record — the committed-section list is the literal `'objects'`, not the sections the module holds #16242

分诊：`domain:cli` / `Bug` / `priority:p3` / `pm:queue`

等级 `p3`

Why `Clause-②: no`