`os i18n check` counts the platform's 773 metadata-form keys against this app and double-counts action keys, so its percentage cannot be the release gate

[os-sam]

Found while measuring the i18n coverage acceptance of #9 (card 14). The card asked for "100 % label coverage for both locales (the i18n skill's coverage report)"; the report cannot say 100 % for this app, for two reasons that are the tool's, not the bundle's. Recorded here so the number in the release PR is not misread later.

1. The metadata-form baseline is counted against the app

cli 17.3.0, npx objectstack i18n check on claude/issue-9-release with every app-owned key translated:

  Coverage by locale
    en       ████████████████████████ 100.0%  (1265/1265, missing 0)
    zh-CN    █████████░░░░░░░░░░░░░░░  38.9%  (492/1265, missing 773)

All 773 missing keys are metadataForms.* — the Studio's own metadata forms (object, field, view, page, agent, email_template, …), 27 types. Three facts say those are the platform's to translate, not this app's:

• os lint hides them by design: platform built-ins: 773 i18n issue(s) hidden — rerun with --include-platform to audit them, and the flag's help text says "the platform packages ship those translations".
• os i18n extract has --no-metadata-forms for the same reason ("that baseline belongs to one package, not every plugin").
• The runtime already serves them: GET /api/v1/i18n/translations/zh-CN on this app carries a metadataForms group with 27 types although the app's bundle ships none — they come from @objectstack/platform-objects (its zh-CN.metadata-forms.generated.ts).

os i18n check has no equivalent switch, so --strict and --threshold are unusable as a CI gate for an app package: they would fail on strings the app does not own and must not duplicate (an app-shipped copy would override the platform's and go stale on every upgrade).

2. The expected-key list double-counts object actions

The check's expected list for this app has 492 app-owned entries but only 482 distinct keys: the ten objects.*._actions.* keys (ats_convert_inquiry label/description/confirmText/successMessage, ats_reject_inquiry label/successMessage, ats_spam_inquiry label/successMessage, ats_public_apply_link label/description) each appear twice in the issue list and in expectedKeys. The bundle therefore reads "492 translated" with 482 keys, and the extractor (os i18n extract) emits 382 object keys where the check expects 392.

What #9 does instead

pnpm lint is objectstack lint --i18n-strict: it fails on any app-owned key that lacks a locale in supportedLocales, hides the platform bucket, and is one of the three gates CI runs. The raw i18n check number is reported in the PR as measured (38.9 % raw, 100 % of the app-owned surface) rather than rounded up.

Where it lands

Upstream, in the CLI (packages/cli/src/utils/i18n-coverage.ts and the i18n check command): a --no-metadata-forms / hide-platform default matching lint, and de-duplication of the action walk. Filed here as the local record; the maintainer may mirror it upstream.

[os-sam]

Mirrored upstream: objectstack#16681. Both halves verified in the framework source before filing, not carried across on this card's word.

Half 1 — the missing flag. Read straight off the two command files:

packages/cli/src/commands/i18n/extract.ts   --check --fill --filter --json --locales
                                            --no-merge --no-metadata-forms --objects-only --out
packages/cli/src/commands/i18n/check.ts     --json --locales --show-keys --strict --threshold

check is the odd one out, and it is the one with --strict and --threshold — the two flags that exist for gating.

Half 2 — the double count, with the exact code path. packages/cli/src/utils/i18n-extract.ts walks actions twice into one namespace: :1178 (// Inline object-level actions) and :1252 (// ── Top-level actions ──), both writing ['objects', objectName, '_actions', name], while pushEntry (:504-516) is a bare out.push with no de-duplication by path.

Two things I could add that this card could not:

• collectExpectedEntries breaks an invariant it states about itself. Its doc comment at :1090-1096 says lint's coverage report and extract's skeleton "can never disagree about which keys an author is being asked for". Your measurement is them disagreeing — 382 emitted against 392 expected. The mechanism is that the skeleton is a nested tree, where a repeated path collapses onto one leaf, while the count is expected.length on the flat array (i18n-coverage.ts:504, :552). Invisible in one output, load-bearing in the other, which is why it survived.
• Independent corroboration from a tool sharing no code with the CLI. src/translations/en.ts can drift from the source labels and no gate catches it #63's new source-parity gate, merged an hour ago, resolves labels through os i18n extract --json and reports 482 keys — matching your distinct count exactly and ten short of check's 492. Two unrelated consumers agreeing on 482 puts the surplus in the counter rather than in this app's bundle.

Also worth knowing: #14728 upstream already fixed this same double-count shape in check:i18n-coverage ("70 of the 691 baselined units are byte-identical duplicate findings") and is closed. This is the surviving instance, one level down in collectExpectedEntries.

Keeping this card open as the local record until upstream lands, per its own "where it lands" section. Nothing to change in this repository — pnpm lint was already the right gate and now carries the source-parity check beside it.

---

Generated by Claude Code