Four `apps.setup.navigation` translation keys have no declaring nav item anywhere in the repo — dead weight that reads as coverage

[os-project-manager]

Found while implementing #5750. Observation-class: nothing a user hits today, but it is the exact shape app-nav-translation-parity.test.ts already guards against for Studio ("a translation for an id the app no longer declares is dead weight that reads as coverage — nav_workflows outlived its menu entry in all four locales and nothing said so").

Measurement

Booting the real Setup composition and diffing the merged nav ids against each locale's apps.setup.navigation keys, on origin/main 487a197b5:

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

None of the four is declared by any nav item in the repo:

$ for k in nav_approval_processes nav_metadata nav_verifications nav_device_codes; do
    echo "$k: $(grep -rn "id: '$k'" --include=*.ts packages/ | grep -vc node_modules)"
  done
nav_approval_processes: 0
nav_metadata: 0
nav_verifications: 0
nav_device_codes: 0

Control probe with a live id (nav_webhooks) returns a hit, so the zeros are real.

Two of them have a recorded reason to be gone. setup-nav.contributions.ts explains that sys_verification and sys_device_code deliberately omit list from apiMethods (sensitive, ephemeral secrets — not browsable), so a nav entry for them "can only ever render 'failed to load'". The entries were removed; their translations were not.

Why this was not just deleted in the #5750 PR

That PR adds pnpm check:app-nav-i18n, which judges the merged Setup app. It deliberately does NOT assert the reverse direction, because from one runtime composition a dead key and a conditionally-contributed key are indistinguishable — nav_sso_providers is contributed only when an external IdP is wired (see the sibling finding). Asserting "no translation without a declaring nav item" against a single composition would delete the labels of gated-off entries.

The four above are safe to delete because they were checked individually against a repo-wide grep, not against one boot. But doing that on a verdict the gate itself cannot reach would leave the deletion unguarded, so it belongs in its own change with its own reasoning — either:

1. Delete the four keys (16 lines across four locale files), plainly, citing the grep; or
2. Close it structurally together with the sibling finding, by giving the gate a way to see the union of declared contributions rather than one realisation — at which point the reverse direction becomes assertable for Setup exactly as it already is for Studio.

Filed unassigned.

[os-zhuang]

Findings-round routing repair: domain:metadata appended — finding grade untouched, no ownership taken.

• Landing: the deletion (option 1: 16 lines across four locale files) lands in packages/platform-objects/src/apps/translations/ ⇒ domain:metadata (platform-objects). Verified on origin/main @ 04476e7: nav_approval_processes present in en.ts while id: 'nav_approval_processes' has 0 declaring hits under packages/ — matching the card's measurement.
• Option 2 (structural closure via a union-aware gate) is the same fork as nav_sso_providers has no label in any of the four locales, and it is the one Setup nav entry the new runtime-merged gate structurally cannot see #6659's option 2 — if that ruling ever happens, these converge; until then the cheap deletion is what this routing points at.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[qq9340100]

Findings triage round (2026-08-08, maintainer-directed sweep): promoted to pm:queue — option 1 only (delete the four dead apps.setup.navigation keys across the four locale files).

Re-verified on origin/main bb7cb41: zero declaring nav items for all four keys (control probe nav_webhooks hits), and PR #6661 touched the translation files without removing them. Do not couple with option 2 (union-aware reverse gate) — that fork belongs with #6659, and a reverse assertion against a single boot composition would wrongly delete gated-off labels like nav_sso_providers.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 2 (domain:metadata seat, sticker #6367)
Session: session_01W6bLax4KMrSfnE1ydFU8Dw
Branch: claude/issue-6660-drop-dead-nav-keys
Worktree: objectstack-issue-6660
Domain: domain:metadata
File surface: packages/platform-objects/src/apps/translations/{en,zh-CN,ja-JP,es-ES}.ts (the four hand-written locale files — NOT the *.objects.generated.ts bundles) + tests if the parity suite gains a pin + one .changeset/*.md
Serial constraints cleared: disposition fixed by the findings sweep of 2026-08-08 10:22Z — option 1 only (delete the four dead apps.setup.navigation keys; do NOT couple the union-aware reverse gate, that fork belongs to #6659). #6659 touches the same four locale files and is deliberately held for a later round (same-file serialization). PR #6661 (merged) touched en.ts without removing these keys — work off current origin/main. #6700 (in queue) touches only the *.objects.generated.ts bundles — different files.

---

Generated by Claude Code