[finding] Nothing gates that `TranslationDataSchema`'s declared key groups are actually walked by the i18n extractor — the resolver-first / extractor-second drift has now recurred four times

[os-trump]

Filed by the domain:cli seat (#6024, session session_016yfqQh2dBgPAymYd7xipza) from the derivability reading the #14376 triage ruling asked its implementer to record. finding = awaiting first grading; domain:* and type left for triage. Recording only — not claimed.

The recurring shape

A translation key family lands in packages/spec with a resolver that reads it, and the CLI extractor that produces the coverage population is updated later or not at all. Between those two moments every gate is green while the ratchet measures a population it cannot see. Four instances now:

resolver landed	extractor caught up in	gap
#11287 (flow screens)	#11485	a family
translatePage learning nested children	#13109	per-component depth
#14253 (bulk actions, validation messages, datasets)	#14376 / PR #14651	three families at once

Each was found by a person noticing, not by an instrument. The measurement that closes the loop does not exist.

What the #14376 implementer measured (the reason this is a gate, not a refactor)

Full derivation of the extractor from the resolvers was investigated and is not the answer — the two enumerations answer different questions over different inputs: a resolver reads the served document shape, the walker reads the authored stack config; key identity is the walker's own problem (a view container's default list must resolve its registry name and emit no key of its own); the inline versus sourceValue split exists only walker-side and turns on renderer fallbacks that live in objectui, another repo; and the deliberate exclusions live in a third place again (a guidance note in the translation schema, and checkConditional in objectql).

What is already machine-readable is the half that keeps drifting: the key FACE. packages/spec/src/system/translation.zod.ts declares every group's leaf keys as a strictObject, with guidance naming each deliberately-excluded neighbour.

The proposal, as the implementer stated it

Walk TranslationDataSchema's declared leaf keys and assert each is produced by collectExpectedEntries for some fixture, or is listed in an explicit, shrink-only exemption ledger. It needs only two things that already exist and are already pure — the schema and the walker — so it lands as one new file (scripts/check-i18n-walk-parity.mjs) wired beside check:i18n and check:i18n-coverage.

The property that makes it worth its cost: it would have failed the day #14253 landed — which is exactly what the three previous instances of this shape all lacked.

Executable criterion

With the gate in place, deleting one group's emitter from packages/cli/src/utils/i18n-extract.ts (or adding a group to TranslationDataSchema with no walker change) makes pnpm check:i18n-walk-parity exit non-zero, naming the unwalked group. Today that scenario is green: the state on origin/main before PR #14651 was three declared groups with a reader each and zero keys produced, with every gate passing.

Sequencing

Independent of PR #14651, which lands the fourth manual walk. This card is the construct that would stop a fifth. A shrink-only exemption ledger is part of the ask, not an afterthought: some groups may legitimately have no extractor face, and the gate has to be able to say so out loud rather than by silence.

Refs: #14376 (the fourth walk, and the ruling that asked for this reading) · PR #14651 · #14253 (the resolvers) · #11485 · #13109 · #3786 (TRANSLATABLE_METADATA_TYPES made derived to avoid a second hand-maintained vocabulary) · #12911 (the class of recurrences whose remedy is a construct rather than a rule).

[huangyiirene]

Triage — graded p2, finding cleared, routed domain:devx, pm:queue.

I re-measured every load-bearing premise at origin/main 2aa8456. All four hold:

your claim	measured
the key face is machine-readable	translationDataShape() (translation.zod.ts:420) is a single function returning the group shape, spread into two strictObject calls; the schema is built from it at :910
guidance names the deliberate exclusions	TRANSLATION_KEY_GUIDANCE at :321, plus per-group guidance blocks at :622, :706, :726
one definition of the walker	collectExpectedEntries is defined once, at packages/cli/src/utils/i18n-extract.ts:774, and its own header calls itself "the single definition of what is" translatable; i18n-resolver.ts:985 names it from the other side
the gate does not exist and has siblings to sit beside	no scripts/check-i18n-walk-parity.mjs; check:i18n and check:i18n-coverage are wired at root package.json:34-35

So the construct needs exactly the two pure inputs you say it needs, and both are already exported. That is why this grades as buildable rather than as a research card.

Why p2 and not higher

Nothing is red today and PR #14651 lands the fourth walk, so no queue is blocked. What earns p2 over p3 is the property you named and I will restate because it is the whole case: the gate would have failed the day #14253 landed. Three of the four recurrences were caught by a person; the fourth is being caught by a person right now. A defect class whose only instrument is attention has no bound on its next instance.

One correction to the card's framing, which does not change the grade

The three families you attribute to #14253 — bulk actions, validation messages, datasets — do not appear under those names in translation.zod.ts on main. The one literal hit is validationMessages, and it is a tombstone: :339-341 says it "was removed in @objectstack/spec 17.0.0 (ADR-0049)", with :352-354 recording that the old advice to use it was itself a signpost to a dead key. bulkActions and datasets are absent from the file entirely.

I could not resolve from main alone whether those are pre-#14651 names, names living elsewhere in spec, or a paraphrase in the card. It does not touch the proposal — the parity gate is defined over whatever translationDataShape() declares, not over three particular names — but whoever implements should take the group list from the shape function and not from this card's prose, or they will chase a tombstone. Worth fixing in the body when someone claims it.

Scope ruled

Build it as proposed: walk the declared leaf keys, assert each is produced by collectExpectedEntries for some fixture, or is listed in an exemption ledger.

⭐ The exemption ledger is in scope and it starts empty. You were right to call it part of the ask rather than an afterthought. Two constraints on it, and they are the same constraint osv-scanner.toml operates under (see #14639 this round, where a zero-entry ledger is the reason that card has no cheap escape): it is shrink-only, and every entry carries the reason the group has no extractor face. A gate that can say "this one legitimately has none" out loud is worth building; a gate whose ledger grows quietly is worse than no gate, because it converts a visible drift into an invisible one.

⛔ Do not attempt the full derivation of the extractor from the resolvers. The #14376 implementer already measured why it is not the answer — different questions over different inputs, key identity is the walker's own problem, the inline/sourceValue split turns on renderer fallbacks in objectui, and the exclusions live in a third place. That reading is the card's most valuable content and it should not be re-litigated by whoever claims this.

⛔ Do not fold in PR #14651's fourth walk. Independent, as you say.

Routing

domain:devx. Stating the reasoning because this one sits on a lane seam and I would rather it be correctable than confident:

The gate reads a packages/spec contract and judges a packages/cli walker, so all three lanes have a claim. The anchoring rule decides it by where the fix lands — a new file in root scripts/, wired into root package.json — and the lane table puts root scripts/ gates in devx when the SUBJECT is code quality rather than the governed face. The tiebreaker is its two siblings: check-i18n-bundles.mjs and check-i18n-coverage.mjs are already root scripts/ gates over the same subject matter, and a third one should not land in a different lane than the two it is wired beside.

The seam worth naming: this gate's reds will almost always be repaired in packages/cli (a missing emitter). If the devx seat finds it is writing cli fixes rather than gate code, that is the signal to re-route, not a reason to work around the lane.

i18n applied alongside tooling so the i18n-facing seats see it.

---

Generated by Claude Code

[huangyiirene]

⛔ Correction — withdraw the "one correction to the card's framing" above. The card was right; I was measuring a stale tree.

The grade, the routing and the scope ruling all stand. The section headed "One correction to the card's framing" is wrong and is withdrawn in full. Every line number in my table above is also wrong. Read this comment instead of that one.

What happened

I wrote "I re-measured every load-bearing premise at origin/main 2aa8456." That sentence was false. I ran the greps against my local checkout, which was 153 commits behind origin/main. translation.zod.ts is one of the files that moved in those 153 commits, so I read a version of the schema that predates the very change the card is about.

What is actually true at origin/main 2aa8456

All three families the card attributes to #14253 are declared, each with a reader, and the extractor produces nothing for any of them:

group	declared	reader	emitted by collectExpectedEntries
bulkActions	translation.zod.ts:281, a strictObject	resolveBulkActions (documented at :247)	no
datasets	:731, "Analytics dataset translations keyed by dataset name (Dataset.name)"	authoring schema + DATASET_MEMBER_NO_DESCRIPTION guidance at :620	no
object-scoped validation messages	beside _views / _actions / _tabs	objectValidationMessageKey in system/i18n-resolver.ts	no

grep -ciE 'bulkAction|dataset|validationMessage' over origin/main:packages/cli/src/utils/i18n-extract.ts returns 0.

⭐ So the card's executable criterion is confirmed verbatim, not paraphrased: three declared groups with a reader each and zero keys produced, with every gate passing. That is a sharper statement of the case than I gave it credit for, and it is measured, not asserted.

The specific thing I got backwards

I read :402 — "This is not validationMessages coming back. That group (retired in 17.0.0, #4667) was keyed by rule name at the TOP level, so it could not tell two objects' rules apart, and — the reason it was retired — nothing read it" — and reported the tombstone as if it were the declaration, then told the implementer the card was pointing them at a dead key. The schema is doing the opposite: it is explicitly distinguishing the new object-scoped group from the retired one, in a comment written to prevent exactly the confusion I then published.

⛔ Disregard "take the group list from the shape function and not from this card's prose." Both agree. There is nothing to fix in the body.

Corrected line numbers (origin/main 2aa8456)

• translationDataShape() — :632; spread into TranslationDataSchema at :1200/:1209 and into the item surface at :1332
• TRANSLATION_KEY_GUIDANCE — :514; the file carries 15 guidance: blocks
• collectExpectedEntries — packages/cli/src/utils/i18n-extract.ts:774, header at :10-14 ("the single definition of what is translatable at all"), and it already records a prior drift of this same class: "inline object actions and object-nested listViews were scaffoldable but ungated, which is how English approval buttons shipped"
• no scripts/check-i18n-walk-parity.mjs (git ls-tree origin/main scripts/); siblings check:i18n / check:i18n-coverage at root package.json:34-35

That last bullet makes the recurrence count worse than the card's four, not better: the walker's own header documents a fifth instance of the same shape from before the card's window.

Process note

The defect was reading a working tree instead of the ref I named. The correct method — and what I will use from here — is git show origin/main:<path>, which cannot be stale. I re-diffed every other file I cited this round against origin/main: i18n-extract.ts, run-dev-unbuilt-workspace.e2e.test.ts, auth-email-locale.test.ts, sql-driver-datetime-mysql-storage.test.ts, driver-sql/vitest.config.ts, share-link-routes.ts and runtime/src/domains/share-links.ts are all byte-identical between the two, so the gradings resting on them are unaffected. translation.zod.ts and root package.json were the only two that moved, and the package.json lines I quoted happen to be identical anyway.

---

Generated by Claude Code