fix(pm): make check:i18n derivable from a metadata form module edit

[os-project-manager]

Fixes#9116

A .form.ts change in packages/spec moves platform-objects' committed metadata-form bundles, but no derived gate list could name check:i18n for it. PR #9113 paid one CI round trip plus a patch commit for that edge.

Why the derivation could not see it

A bundle has two producers, and only one lives in the package that owns the bundle:

• objects — enumerated by the config's own package, so the owning package IS the trigger surface. This is what the existing convention entry covers.
• metadataForms — registry-driven and identical for every stack, so exactly one package commits that baseline (platform-objects; every other config passes --no-metadata-forms) while its source sits in packages/spec, which owns no extract config and which the gate's walk never reaches.

So the family scored neither matched nor undetermined — printed nowhere at all.

What changed

scripts/i18n-bundle-surface.mjs (new) — the config walk and the docstring-flag parse move here and BOTH readers import them. dispatch-gates.mjs used to carry a hand-written mirror of the gate's walk, described in its own comment as mirroring findConfigs "exactly": a second contract that agrees until one side moves, with nothing to report the day it stops. Same shape scripts/cli-build-prerequisite.mjs already has for the classifiers this gate shares with check-i18n-coverage.mjs.

A second CHANGE_KIND_GATES entry for a metadata form module. The KIND is written down; the POPULATION is walked at runtime; and applicability is read from the configs' own documented flags (anyConfigExtractsMetadataForms) rather than assumed — the day every config passes --no-metadata-forms, no form module can move a committed bundle and the entry stops firing by itself. That is its stated deletion criterion.

The one convention written down is the suffix .form.ts, which is the producer's own — stated by the registry it feeds (packages/spec/src/system/metadata-form-registry.ts: "the FormView produced by defineForm({ schemaId }) in the corresponding *.form.ts"). Measured: 17 files in the repo carry that suffix, all under packages/spec/src, and the registry has exactly 17 form entries — the convention and the population coincide with nothing left over on either side.

A declared coupling in both consumers. An import specifier is not a discoverable watch hint (../i18n-bundle-surface.mjs strips to a bare filename the extractor rejects), so without it a card editing the shared enumeration would move two gates while deriving neither — the same blind spot one layer down. Both declare it as a bare module-body constant, the shape check-type-check-coverage.mjs already uses, pinned live in the tool's self-test.

The before/after that is the deliverable

Reproducing PR #9113's shape (object.form.ts + field.form.ts), counting mentions of check:i18n in the whole output:

surface	before (origin/main @ 24206416a)	after (d1945d278)
object.form.ts + field.form.ts	0 — neither matched nor undetermined	1, under its own convention heading, runnable
packages/spec/src/data/filter.zod.ts (a schema next door to a real form module)	0	0 — no over-trigger
packages/rest/src/rest-server.ts	0	0 — no over-trigger

After:

Convention-triggered gates (this change KIND moves them; no path derivation can name them):
edits a metadata form module (a *.form.ts the Studio form registry collects):
packages/spec/src/data/object.form.ts, packages/spec/src/data/field.form.ts
- pnpm check:i18n — the metadataForms half of the bundles is registry-driven, ...

A card editing the new shared module now derives both gates it can move (check:i18n, check:pm-dispatch-gates).

Verification at d1945d278

• pnpm check:i18n — green, full run on a built closure: 9 packages, all bundles in sync (platform-objects in sync (8 bundle(s)), the other eight 4 each). The refactored walk returns the same 9 configs in the same sorted order as the pre-change one, and each resolves the same documented --out directory.
• pnpm check:pm-dispatch-gates — green, 183 self-test cases (up from 179; the new cases are the metadata-form edge in both directions plus the two live coupling pins).
• node scripts/check-nul-bytes.mjs — green.
• Gate families re-derived from the actual changed paths, not the dispatch prompt's list: check:i18n and check:pm-dispatch-gates, both run above.

Reverse verification (direction decided first: ablating the applicability read, not the entry, should stop the entry firing). Adding --no-metadata-forms to platform-objects' config docstring made anyConfigExtractsMetadataForms go false, the incident paths derive 0 mentions of check:i18n, and exactly 5 named self-test cases went red — all of them the new claims, nothing else. Restored byte-identical (cmp against a pre-ablation copy), green again.

That ablation also caught a real defect in the first draft of the self-test: an empty rendering crashed it on a TypeError, replacing 183 named verdicts with one stack. Fixed in its own commit — a case that stops holding must fail by name, the discipline check-i18n-bundles.mjs states for its own classifiers.

Scope note — an edge this deliberately does NOT close

Measured while enumerating the trigger surface: walkMetadataForms (packages/cli/src/utils/i18n-extract.ts) emits metadataForms.TYPE.label / .description for every entry of DEFAULT_METADATA_TYPE_REGISTRY (packages/spec/src/kernel/metadata-plugin.zod.ts), and metadata-form-registry.ts decides which forms are walked at all. Editing either moves the same four bundles and matches no convention here, because neither carries a filename that distinguishes it. Closing it needs an anchor this change does not have, and the candidates trade off against each other rather than being one obvious shape, so it is filed rather than guessed at: #9144 (which stays open — it is not addressed here). The shared module's header states the same gap at the source, so the omission is visible there and not only in this description.

Tooling-only (scripts/), no user-visible change — skip-changeset.

---

Generated by Claude Code