feat(approvals): point the account app's Approvals nav at the inbox component (#7234)

[os-zhuang]

Fixes #7234

Entry C of #7213: the account app's Approvals entry opened the raw sys_approval_request grid. That surface cannot show an approver a single decision button — all eight actions on the object gate on record.viewer.can_act || record.viewer.can_override, and the viewer block is computed and attached only by the approvals REST path (approval-service.ts, attachViewers()), never by the generic data API an object route reads. The result was a correct-looking, completely inert list of rows nobody could act on.

The entry point does not move. Same id, same label, same icon, in every locale — which is also what keeps #7271's cross-package parity pin (my_pending view label === nav_account_approvals label, zh/ja/es) green. Only the destination changes.

What changed

• account.app.ts — nav_account_approvals becomes { type: 'component', componentRef: 'approvals:inbox' }, gated by requiresService: 'approvals'.
  • requiresObject was the right gate for an object route and is not a gate at all for a component one — it names the object the entry routes to. The capability that must actually be present is the approvals service (ctx.registerService('approvals', …)), which is also what backs the REST path the inbox reads. Verified rather than assumed: requiresService lives on BaseNavItemSchema, which ComponentNavItemSchema spreads, and filterAppForUser/filterNav reads e.requiresService variant-agnostically (rest-server.ts:2731/:2744, ADR-0057 D10) — packages/rest/src/meta-app-area-nav-gate.test.ts:34 already pins that a type: 'component' item is stripped this way. Without the gate the entry would render a dead component route wherever plugin-approvals is absent.
  • No requiredPermissions added anywhere — the account app deliberately has none, and the inbox enforces its own data access through the approvals REST path.
• approvals-plugin.ts — a new nav_approvals_inbox component entry at the top of group_approvals. Order is array order (applyNavContributions does group.children.push(...c.items)), so its position in the array is the assertion, not a by-product. The three raw tables are untouched and stay behind group_approvals' manage_platform_settings gate as the admin/diagnostic surface.
• Translations — nav_approvals_inbox in all four locales (en Approvals Inbox, zh-CN 审批中心, ja-JP 承認センター, es-ES Centro de aprobaciones). nav_account_approvals deliberately untouched.
• Docs — content/docs/automation/approvals.mdx: "The approver finds it in their queue" now names the Approvals Inbox as the canonical approver surface and explains, in a callout, why the raw table is not it; plus a new "Mount the approvals inbox in your app" section with the one-entry snippet. content/docs/ui/setup-app.mdx's group_approvals row now enumerates the entries.
• Changeset — .changeset/approvals-nav-points-at-inbox.md (minor, both packages; user-visible navigation change).

Tests

• New packages/platform-objects/src/apps/account-approvals-nav.test.ts (7 cases). The two shapes are one keyword apart and both parse AppSchema cleanly, so nothing else in the repo could see a regression back to type: 'object'.
• Extended nav-contribution.test.ts. The old case opened with a .map(…).sort() over objectName — a set-shaped assertion that cannot see ordering, and putting the working surface below three raw tables is most of what [approvals][console] 「待我审批」有三个并存入口、三套不同 UI —— 其中 sys_approval_request 原生视图是无决策动作的开发者原始表 #7213 reported. It now pins the id order, the inbox's component shape, that it carries no object gate, and that the raw tables are unchanged and still gated.

Reverse verification

Both new gates were taken out and confirmed red, in the predicted direction:

• Reverted account.app.ts to origin/main → 5 of the 7 new cases fail (expected 'sys_approval_request' to be undefined, expected undefined to be 'approvals', …). The 2 that stay green are the deliberate ones: the label/icon pin (unchanged by design) and the AppSchema.parse case — both shapes are valid metadata, which is precisely why the rest of the file exists.
• Dropped the zh-CN nav_approvals_inbox label → check:app-nav-i18n goes red naming exactly that id: apps.setup.navigation — locale 'zh-CN' has no label for 1 runtime-merged nav id(s): nav_approvals_inbox contributed by @objectstack/plugin-approvals. This proves the new Setup entry really is merged and judged by the gate, not merely declared.

Local results

pnpm --filter @objectstack/platform-objects --filter @objectstack/plugin-approvals typecheck   Done (both)
platform-objects  test:  Test Files 12 passed (12) | Tests 296 passed (296)
plugin-approvals  test:  Test Files 20 passed (20) | Tests 452 passed (452)
check:app-nav-i18n:  OK (10 contributors, 54 merged `setup` nav ids, 4 locales, every id labelled in every locale)
check:doc-authoring: 374 files clean
check-nul-bytes:     OK (6650 text files)

plugin-approvals' approval-status-vocabulary.test.ts — including the cross-package parity case #7271 added today — is inside that green 452 and was run explicitly against this change.

Not in this PR

• The console pin bump (.objectui-sha) is tracked separately as chore: bump the console pin to pick up objectui#4071 (approvals:inbox component ref) #7268. approvals:inbox resolves in the console registry as of objectui#4071 (objectui main 28c38567b), but end-to-end browser behavior needs that pin bump — deliberately not ridden here.
• Attaching viewer on the generic data API (objectui#2763 A1) and the vocabulary alignment ([approvals] Unify the approval-status vocabulary across i18n bundles (zh "待处理"→"待审批", my_pending view label; humanize the en status options) #7232, merged as fix(plugin-approvals): unify the approval-status vocabulary across the i18n bundles #7271) stay out of scope.

---

Generated by Claude Code

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectstack	Ignored		Aug 10, 2026 5:25am

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/platform-objects, @objectstack/plugin-approvals.

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

• content/docs/automation/approvals.mdx (via @objectstack/plugin-approvals)
• content/docs/kernel/services-checklist.mdx (via @objectstack/plugin-approvals)
• content/docs/plugins/packages.mdx (via @objectstack/platform-objects, @objectstack/plugin-approvals)
• content/docs/ui/setup-app.mdx (via @objectstack/platform-objects)

⛔ 2 release-owned page(s) also reference the affected code. These are read-only:

• content/docs/releases/implementation-status.mdx (via @objectstack/plugin-approvals)
• content/docs/releases/v9.mdx (via @objectstack/plugin-approvals)

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.

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.