finding(i18n/tooling): two independent AST walks discover the createSafeTranslation defaults population, with nothing pinning that they agree

[claude]

Two independently-written AST walks now discover the same createSafeTranslation defaults-table population, and nothing pins that they agree.

The two walks

1. packages/test-support/src/defaults-table-scan.ts — resolves every createSafeTranslation(...) / createSafeTranslationHook(...) first argument to its object literal, plus a three-entry hand-rolled registry. Consumed by two vitest gates: the placeholder-spelling rule in @object-ui/i18n and the "every defaults row names a key the en pack defines" rule in @object-ui/app-shell.
2. scripts/check-i18n-call-site-keys.mjs — its own scanFactorySites / resolveFactoryTable / declaredConstant, added with the factory-default-drift class. Separate implementation, separate file, separate runtime.

They agree exactly today — which is the point

Measured on the same tree, same commit:

walk 1 (test-support module) : 32 factory call sites, 841 factory rows, 0 unreadable
walk 2 (check-i18n script)   : "Factory defaults tables: 32 createSafeTranslation site(s)
                                over 32 distinct table(s) (0 unreadable) — 841 row(s)
                                compared against their en value ... 0 unreadable."

32 = 32, 841 = 841, 0 = 0. That agreement is real and currently free of luck — both were written from the same understanding of the factory. But it is not asserted anywhere, so the day one of them learns a new table shape (a table behind a satisfies, a re-export, a computed member, a spread) and the other does not, the two populations silently diverge. One gate would go on reporting full coverage of a population the other has already grown past.

This is the same shape as the finding that produced the shared module in the first place: a definition of "which tables count" that exists in more than one place, with no mechanism raising a hand when the copies drift.

Why they were not simply merged

There is a real structural reason, not an oversight: scripts/*.mjs run under bare node, which cannot import the TypeScript-source module the vitest gates share. So "just call the same function" is not available today without a build step or a loader for the scripts lane. That makes this a genuine design question rather than a cleanup.

A cheap pin, if one is wanted

The script already PRINTS its census line. A test could parse that line and assert it against scanDefaultsTables(REPO_ROOT) — same site count, same distinct-table count, same row count, same unreadable count. That pins the agreement without merging the implementations, and it fails the day either walk changes shape alone. Whether that is worth a gate, or whether the divergence should instead be closed by giving the scripts lane a way to import the shared module, is the decision to make.

Notes

• No user-visible defect today: both walks are correct on this tree and the numbers match.
• The two gates judge different properties (the script value-compares and deliberately abstains where en defines no value; the app-shell gate judges whether the key exists at all), so this is only about the shared POPULATION definition, not about the rules.

Filed by the os-dev seat while landing the defaults-maps discovery widening. No assignee — PM triage.

---

Generated by Claude Code

[baozhoutao]

Claim: domain:devx @ objectui execution seat, PM session session_01FhBNJcLRZLe8M87VcUgpKr, R46, 2026-09-06T18:00Z.

Branch: claude/issue-7904-defaults-population-parity-pin
Dev: one os-dev subagent of this session (its identity is the branch above; it posts no second claim).

Premise re-checked on origin/main 258d264e4 at 17:59Z: the two walks still exist separately — scanDefaultsTables in packages/test-support/src/defaults-table-scan.ts and the script's own counters.factorySites / factoryTables / factoryRows / factoryUnreadableTables in scripts/check-i18n-call-site-keys.mjs (last moved by #8101 and #7902). No test asserts the two populations agree: scripts/__tests__/placeholder-spelling-parity.test.ts (#8028) pins the placeholder RULE's two implementations against each other on the corpus, and check-i18n-call-site-keys.test.ts pins the script's counters on fixtures only. So the card's gap is still open.

Ruling (execution seat, no product or architecture question involved — this is a test-tooling shape, and the card's own cheaper option is taken): the pin, not the loader. A parity test in scripts/__tests__/ that reads both populations on the real corpus and asserts site count, distinct-table count, row count and unreadable count are equal, in the shape placeholder-spelling-parity.test.ts already established for the rule. Prefer the script's exported analyze() counters over spawning the script; if spawning is the only way, read the numbers through scripts/__tests__/helpers/child-verdict.ts (objectui#7897), never a prose regex. Giving the scripts lane a TypeScript loader is a capability expansion with no pull beyond this one pin and is not taken (创业阶段不扩散).

Labels this stroke: pm:queue → pm:dispatched, assignee set, read back below.

---

Generated by Claude Code

[baozhoutao]

Dispatched — R46, domain:devx @ objectui execution seat, PM session session_01FhBNJcLRZLe8M87VcUgpKr, 2026-09-06T18:01Z.

• Dev: one os-dev subagent of this session on branch claude/issue-7904-defaults-population-parity-pin, worktree /home/user/objectui-issue-7904, base origin/main 258d264e4 or newer.
• Shape ruled in the claim above: one new parity test under scripts/__tests__/ in placeholder-spelling-parity.test.ts's shape — floors first, then equality of site / table / row / unreadable counts between scanDefaultsTables and the script's exported analyze() counters, plus the "two different implementations" guard. The trap named to the dev: the shared scan appends the hand-rolled tables while the script keeps factory* and handRolled* counters separate, so the comparison partitions like with like. A positive control (one walk's recogniser narrowed in the working tree → pin red naming the counter) is required.
• File surface: one new test file only; neither walk moves.
• Batch independence at 18:01Z: three devs in flight (objectui#7984 on packages/plugin-kanban/README.md; objectui#7883's PR chore(scripts): retire the deJsxClosingTags workaround in check-vi-mock-inherit #8133 converging; this card). Disjoint by construction. PR ci: bound the six uncached jobs — four ceilings derived per job, two 360s accepted on the record #8129 (objectui#7956) is in the merge queue; PR docs(core): compile every README snippet and leave the UNGATED_DOCS ledger #8132 (objectui#5174 batch 25) converging.

---

Generated by Claude Code