fix(i18n): re-translate the five leaves serving a superseded source revision

[os-trump]

Fixes#12065

os i18n extract merges gaps only, so revising a source string leaves the previous revision standing in every translated locale — in sync by key, green under check:i18n, counted as translated by check:i18n-coverage. The five leaves check:i18n-stale-fill froze in its baseline are re-translated here from the currenten source, and the baseline is ratcheted to empty in the same change, so the repair cannot land half-done.

Translated-locale leaf values only (the designed repair path: the bundle header says "Edit translations in place … a present-but-stale string is not a gap … Re-translate it by hand when its source changes", and AGENTS.md's auto-gen table says the same). No structure, key, schema, export or runtime change.

Premise re-verified on origin/main before repairing

All five leaves were still stale at the branch point (2ba4329e4): node scripts/check-i18n-stale-fill.mjs reported scanned 10 bundle set(s), 5 stale-fill leaf/leaves, 5 baselined, and each leaf was read out of the committed bundles by module evaluation (not regex) across every locale of its set. None had been repaired by someone else; none dropped out.

The five leaves

leaf	before	after
dataset.fields.measures.helpText (metadata forms)	es-ES / ja-JP / zh-CN byte-identical, promising a "certified" governance flag the declaration dropped in 16.0	three real translations of the current source
sys_webhook.fields.method.help	es-ES / ja-JP / zh-CN byte-identical GET / POST / PUT / PATCH / DELETE, after the source became prose	three real translations of "HTTP method used for the callback request"
sys_webhook.pluralLabel	ja-JP and zh-CN both the Latin fill Webhook	ja-JP now ウェブフック, the term this bundle's own Japanese prose already uses; zh-CN keeps Webhook (see below)
sys_http_delivery.fields.attempts.help	es-ES / ja-JP an English fill; zh-CN a real translation of the same superseded source	all three carry the PARKED / terminal-row clause and the error pointer
sys_notification_subscription.fields.principal.help	all three missing the owner_of:object:id and bare-email selector forms	all three carry the full current selector list

Two judgement calls, stated rather than buried:

• zh-CN was repaired on leaves 4 and 5 as well, not only the locale pair the gate can see. The card records that the zh-CN arms are translations of the same superseded source and are invisible to cross-locale agreement; leaving them would have left confidently-wrong text behind a green gate. Both are inside the declared file surface and the same leaf.
• zh-CN sys_webhook.pluralLabel is deliberately unchanged. There is no Chinese rendering of the term anywhere in this repo (zero hits for 网络钩子 / Web 钩子 / 网页钩子), the zh-CN bundle's own prose uses Webhook throughout, and Chinese marks no plural — so the value is already correct and inventing a calque to satisfy a value comparison would be a worse translation. The leaf leaves the gate's detection anyway, because the ja-JP arm is no longer identical to it.

Each locale's punctuation follows its own file's convention (measured per file, not assumed): full-width （）：、 in the metadata-forms bundles and the plugin-webhooks zh-CN bundle, ASCII parens/comma/semicolon with full-width 。 and —— in the service-messaging zh-CN and ja-JP bundles.

Verification

Everything below was run in a dedicated worktree, and the gate union was re-derived and re-run on the final commit 890da9ba7 with a clean working tree. Verdicts are quoted from each gate's own line; exit codes were captured before any pipe.

Gate union — derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (repo assertion confirmed against this checkout's origin; change set taken from git, 11 paths vs merge base 2ba4329e4), not hand-picked. All 21 matched families plus both convention-triggered ones ran green:

• check:i18n-stale-fill — "OK (10 bundle set(s) — no new stale fills, 0 baselined)"
• check:i18n — "OK (9 package(s) — all bundles in sync, no undeclared authoring keys)"; every package reported in sync, including all three touched ones. This is the load-bearing one: a merge-mode re-extract reproduces the hand-written values byte-for-byte, which is exactly what makes hand-editing the sanctioned repair
• check:nul-bytes — "OK (scanned 6720 text file(s) … no raw ASCII control bytes)"
• check:slot-lookup — "ratchet holds: 107 unswept site(s) in 25 file(s), none new"
• check:published-files — "69 publishable package(s) of 78 workspace member(s) …"
• check:entry-guard, check:parse-guard, check:agent-test-spelling, check:pnpm-filter-targets, check:cross-package-test-inputs, check:test-source-alias, check:type-source-resolution, check:changeset-gate-self-tests, check:objectui-changeset — all exit 0
• check-ci-filter-parity, check-cross-package-test-inputs, check-plugin-teardown-shape, docs-audit/check-affected-docs, docs-audit/check-drift-comment, release-rehearsal-clone --self-test — all exit 0
• changeset family re-run after the commit so it reads the real diff: check-empty-changeset "No empty-frontmatter changeset introduced by this diff (1 declaring changeset(s) added)", check-adr-0087-registration "this PR adds no declared-breaking changeset (1 non-breaking changeset(s) seen)", check-changeset-no-major "This diff introduces no major bump"

The pairing the card describes was observed, not assumed. With the leaves repaired and the baseline untouched, the gate went red on purpose: exit 1, "5 baselined leaf/leaves are no longer stale (improvement!)", naming all five. node scripts/check-i18n-stale-fill.mjs --update then reported "+0 / -5" and the baseline is now {}.

Tests — pnpm --filter @objectstack/platform-objects exec vitest run --maxWorkers=2 src/apps/translations → "Test Files 7 passed (7) / Tests 67 passed (67)"; the bundle-ownership suites in plugin-webhooks and service-messaging → 2 passed each.

Typecheck — pnpm --workspace-concurrency=2 --filter @objectstack/platform-objects --filter @objectstack/plugin-webhooks --filter @objectstack/service-messaging typecheck → each echoed tsc --noEmit && tsc --noEmit -p tsconfig.scripts.json and reported Done, exit 0.

Lint — the full repo scan, not a narrowed one: pnpm lint (eslint . --no-inline-config) exit 0 in 92s. The narrowed run over the diff paths is also recorded: 11 entries, 9 TypeScript files linted, 0 errors and 0 warnings, with the changeset .md and the baseline .json reported as "File ignored because no matching configuration was supplied" — ESLint's own config deciding the population.

Not measured, declared:check:i18n-coverage refused to run in this worktree — "COULD NOT MEASURE — 1 of 12 config(s) failed to lint", because @objectstack/connector-mcp has no build output here. That is an environment verdict, not a finding about this diff; the gate is not in this card's derived union, and its own output states the baseline was left exactly as committed.

All heavy commands ran through scripts/pm/os-verify-lock.sh; the longest wait was 4m26s behind a sibling worktree's build.

Changeset

One patch changeset for the three published packages (@objectstack/platform-objects, @objectstack/plugin-webhooks, @objectstack/service-messaging, all private: false) — the change is user-visible admin/Setup help text in three locales. Not breaking, so no ADR-0087 marker applies.

Filed, not fixed here

Filed as #12128: after this repair the ja-JP sys_webhook object renders its name two ways in one locale — label is still the equal-to-en Latin fill while pluralLabel is now Japanese. Which of the two renderings should win is a decision, and label is an equal-to-en gap leaf that check:i18n-stale-fill excludes by construction, so it is out of this card's five-leaf scope. The card also records why zh-CN keeps Webhook, so a later sweep does not "fix" it by inventing a calque.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 3 package(s): @objectstack/platform-objects, @objectstack/plugin-webhooks, @objectstack/service-messaging, touching 3 documentable anchor(s).

2 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/automation/flows.mdx(via sys_http_delivery (symbol))
• content/docs/automation/webhooks.mdx(via sys_http_delivery (symbol), sys_webhook (symbol))

⛔ 2 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v16.mdx(via sys_webhook (symbol))
• content/docs/releases/v17.mdx(via sys_http_delivery (symbol), sys_webhook (symbol))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 45 of 222 client-bound route-ledger rows — the other 177 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 5 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 8619f9513221e59f84d4cc61a4d41f018eba4958 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 14c5dd8c81833e1725f017fe7cca2f5d2b193155 — the merge of head 890da9ba7b4b4ffa127e227871d94abf29f75267 into base 8619f9513221e59f84d4cc61a4d41f018eba4958, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 14c5dd8c81833e1725f017fe7cca2f5d2b193155 && git checkout 14c5dd8c81833e1725f017fe7cca2f5d2b193155
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 8619f9513221e59f84d4cc61a4d41f018eba4958 890da9ba7b4b4ffa127e227871d94abf29f75267 && git checkout -B drift-repro 8619f9513221e59f84d4cc61a4d41f018eba4958 && git merge --no-ff 890da9ba7b4b4ffa127e227871d94abf29f75267
node scripts/docs-audit/affected-docs.mjs --json 8619f9513221e59f84d4cc61a4d41f018eba4958

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 8619f9513221e59f84d4cc61a4d41f018eba4958 → pass the list as
args.docs, on the commit named under Which tree this was computed on.