chore(platform-objects): drop four dead apps.setup.navigation translation keys (#6660)

[os-zhuang]

Fixes#6660

Four ids kept a Setup nav label in the hand-written locale bundles long after the nav item that declared them was removed. Nothing renders them, so nothing is broken today — but a translated key with no declaring nav item is dead weight that reads as coverage, which is the exact shape app-nav-translation-parity.test.ts already refuses for Studio ("nav_workflows outlived its menu entry in all four locales and nothing said so").

Note: three placeholders in the first version of this body were eaten by GitHub's body sanitizer, which strips < followed by a letter as an HTML tag. They are spelled out literally below.

Premise re-check on a fresh base

Re-measured on origin/main61282f906 (which already contains #6700, so no overlap with its *.objects.generated.ts diff).

A repo-wide grep for a declaring id: 'KEY' literal, run once per key, against a control probe:

key	declaring nav items	verdict
nav_approval_processes	0	dead
nav_metadata	0	dead
nav_verifications	0	dead
nav_device_codes	0	dead
nav_webhooks (control)	5	live — the zeros are real

The broader scan (bare id, whole repo, node_modules/dist excluded) returns the translation files and nothing else for all four. nav_metadata_directory is a different id and is live in studio.app.ts — it is untouched. ../objectui returns zero hits for all four as well.

Per-locale presence, matching the card's table exactly — 14 key/label pairs, not 16:

key	en	zh-CN	ja-JP	es-ES
nav_approval_processes	yes	yes	yes	yes
nav_metadata	yes	yes	yes	yes
nav_verifications	yes	—	yes	yes
nav_device_codes	yes	—	yes	yes

zh-CN never carried nav_verifications / nav_device_codes, so only what exists was deleted: en 4, zh-CN 2, ja-JP 4, es-ES 4.

Each one also has a recorded reason to be gone, traced through git log -S:

id	why it has no nav item
nav_approval_processes	the approval process engine was retired in favour of the approval flow node (#1408, ADR-0019 P4/P5)
nav_verifications	sys_verification omits list from apiMethods
nav_device_codes	sys_device_code likewise — both hold sensitive, ephemeral secrets, so a browse entry could only ever render "failed to load" (#2266, and the comment recording it in setup-nav.contributions.ts)
nav_metadata	moved to Studio as nav_metadata_directory when the Studio app was split out (482eb67cc)

What this PR does not do

It does not add the union-aware reverse gate — that fork is #6659. pnpm check:app-nav-i18n still refuses the reverse direction on purpose: from a single booted composition a dead key and a conditionally-contributed one are indistinguishable (plugin-auth contributes nav_sso_providers only when an external IdP is wired). These four are safe because each was checked individually against a repo-wide grep, not against one boot.

Tombstone

packages/platform-objects/src/apps/translations/setup-nav-dead-key-tombstone.test.ts — a new file rather than a Setup case inside app-nav-translation-parity.test.ts, because that file's header says a Setup case there "has to boot something", and a tombstone needs no walk. Two assertions:

1. per locale, none of the four ids appears under apps.setup.navigation;
2. SETUP_NAV_CONTRIBUTIONS declares none of them — with a nav_users control inside the same test so the walk cannot pass by vacuity.

Both go red together if one of the four returns, which is the point: the declaring nav item comes back first, the label second, and the id's line leaves DEAD_SETUP_NAV_IDS in that same commit. Re-adding nav_verifications / nav_device_codes remains a security decision (it means enabling list on the object first).

Reverse verification

Predicted direction before running: red, and red in the per-locale counts rather than uniformly, since zh-CN carries two of the four.

Took the four locale files back to origin/main with git checkout origin/main -- followed by the four <locale>.ts paths spelled out (no stash), and re-ran the tombstone:

Tests 4 failed | 1 passed (5)
FAIL en / ja-JP / es-ES -> ["nav_approval_processes","nav_device_codes","nav_metadata","nav_verifications"]
FAIL zh-CN -> ["nav_approval_processes","nav_metadata"]

The 4-vs-2 split is the measured per-locale table reproduced by the pin. The fifth case (SETUP_NAV_CONTRIBUTIONS) stayed green, correctly: that file was never part of the deletion, and its nav_users control proves it was still reading a populated array.

Gates

Enumerated from .github/workflows/lint.yml, run one by one in the foreground under the shared verification lock:

• ESLint job — pnpm lint green; all check:* steps green (check:slot-lookup, check:query-options-erasure, check:verify-stand-in, check:nul-bytes, check:doc-authoring, check:docs-audit-scope, check:role-word, check:quick-reference-counts, check:adr-anchors, check:org-identifier, check:authz-resolver, check:service-providers, check:route-envelope, check:error-code-casing, check:wildcard-fallthrough, check:meta-type-normalized, check:init-service-contract, check:durability-log-level, check:startup-registry-verdict, check:objectui-changeset, check:release-notes, check:release-body, check:node-version, check:workflow-status-functions, check:shard-attestation, check:published-files, check:engine-double-contract, check:kernel-hook-pairs, check:resume-authority-declared, check:driver-memory-census, check:merge-driver, check:spec-parsed-alias).
• i18n trio (typecheck job) — after the workspace build:
  • check:app-nav-i18n: OK (10 contributor(s), 53 merged setup nav id(s), 4 locale(s), every id labelled in every locale) — the forward direction is unaffected by deleting undeclared keys, which is the thing worth proving.
  • check:i18n: OK (9 package(s) — all bundles in sync, no undeclared authoring keys).
  • check:i18n-coverage: OK (12 config(s), 660 baselined untranslated string(s), none new) — platform-objects stays at 0.
• pnpm --filter @objectstack/platform-objects test — 11 files / 285 tests passed; typecheck clean.
• pnpm --filter @objectstack/cli exec vitest run test/platform-page-i18n-parity.test.ts — 5 passed (the only other consumer of these bundles).

A changeset is included (@objectstack/platform-objects: patch), so no skip-changeset label applies.

---

中文摘要

Setup 应用的四个导航翻译键(nav_approval_processes、nav_metadata、nav_verifications、nav_device_codes)在对应的导航项被删除后仍留在四个手写语言包里。在新基线 61282f906 上逐键复测:全仓按 id: 'KEY' 字面量 grep 均为 0,而对照键 nav_webhooks 命中 5 处,说明这四个零是真的。按各语言实际存在的键删除,共 14 条(zh-CN 本来就没有 nav_verifications / nav_device_codes),并新增一个墓碑测试把这四个 id 钉死——只有在导航项先回来时才允许把标签加回来。未耦合 #6659 的通用反向门禁。

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectstack	Ignored		Aug 8, 2026 2:43pm

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/platform-objects.

2 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:

• content/docs/plugins/packages.mdx(via @objectstack/platform-objects)
• content/docs/ui/setup-app.mdx(via @objectstack/platform-objects)

Advisory only. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs origin/main → pass the list as args.docs.