[approvals][qa] Browser-verify the #7213 entry convergence end to end, and refresh the approvals checklist's entry paths

[os-zhuang]

Follow-up to the #7213 epic (closed 2026-08-10, five sub-issues merged: #7231 #7232 #7233 #7234 #7268). Everything there was verified by unit tests, gates and CI. Nothing in it was ever driven in a browser, and parts of it are structurally invisible to the tests that shipped. This card closes that gap.

The blocker is gone: main now pins the console at 8aad9fd50b16 (#7308), which carries the approvals:inbox registration (objectui#4071), the bell-badge breakdown (objectui#4073), and the retirement of the record page's hard-coded approve/reject path (objectui#3055).

Why a browser, specifically

Three things the shipped tests deliberately do not cover:

1. Does the registration survive bundling? [approvals][console] Register an approvals:inbox component-registry key and de-hardcode the Approvals Inbox entry links #7231's test imports the registration module directly and stubs the page at its module boundary. Its own docblock states it does not assert that main.tsx performs the side-effect import — "the one remaining way the key could be missing at runtime". Unit tests run source; users run packages/console/dist. Only a real load closes this.
2. Can a non-admin actually reach it? That is the premise of the whole epic — business roles have no setup access. No test ran a real session through filterAppForUser's nav gating; they asserted metadata shape and URL strings.
3. Do the decision actions render under the component mount? The component-route case used a stub page echoing two router inputs. The real page's data fetching, DeclaredActionsBar driven by server-computed viewer.can_act, the drawer, node progress — none of that has been exercised on that path.

Scope

Boot a real example app (examples/app-showcase or app-crm) against a real backend with seeded approval requests, and drive it. packages/console/dist is not built in a fresh checkout — build it first (pnpm objectui:build, which clones objectui at the pin).

Verify, as a non-admin business user unless noted:

• The account app's Approvals entry appears and opens the full inbox (tabs, list, drawer) — not a component-not-found empty state.
• Decision actions (approve / reject / reassign / …) render in the drawer for a request where the user is a pending approver, and at least one decision actually executes and moves the request.
• ?request=<id> deep-links straight into that request's drawer, on both the component route and /system/approvals (notification and email links carry the latter — it must still work).
• Record deep links from the inbox land on the right business record under the current app.
• Home's "pending approvals" card navigates within an app the user can open (no /apps/setup/...).
• The bell popover shows total · N notifications + M pending approvals, unclamped, with M matching Home's card. Seed enough to exceed 9 so the clamp case is the one exercised.
• zh-CN wording reads 待审批 / 待我审批 consistently across the inbox, the nav entry and any Setup-side view.
• As an admin: Setup → Approvals lists Approvals Inbox above Requests / Action History / Delegations, and it opens the same inbox.
• Record page (entry B): the approve/reject buttons come from the server-declared actions (objectui#3055), not the retired hard-coded pair.
• Confirm or refute [console] Four remaining inbox/activity entries still hardcode /apps/setup/..., so a business user without setup access has no working "all notifications" or "all activity" link #7266 — it was filed as routing-level inference and explicitly not browser-verified. The bell's and Home's "see all notifications / activity" links are the subject; a non-admin session answers it for free while you are here.

Also in scope: the checklist has drifted

docs/qa/platform-checklist/areas/approvals.json drives every case through /system/approvals (lines 29, 182, 257 among others). That route deliberately still works, so nothing goes red — but the checklist now exercises the deep-link route rather than the path a real user takes, and the two new nav entries have no coverage at all. Refresh the entry paths and add cases for the account-app and Setup entries. Follow RUNNER.md and the checklist's own authoring conventions.

Reporting

Findings get filed per the standing discipline (search first, finding label, unassigned). Fix in place only what is small and unambiguously in scope; anything architectural or cross-repo gets an issue, not a patch. A run that finds nothing is a valid outcome — record the run.

[os-zhuang]

Claim: PM loop round 5 (follow-up to the closed #7213 epic)
Session: session_01L9U1G2piXmYrhYQX96XUyv
Branch: claude/issue-7331-approvals-browser-verify
Worktree: objectstack-issue-7331
Domain: qa / verification — no domain:* applied; routing labels are the triage seat's territory, and this card's landing surface is docs/qa/platform-checklist/** plus whatever findings it produces.
File surface: docs/qa/platform-checklist/areas/approvals.json (+ any run record the runner prescribes). Product-code edits are NOT expected — anything found gets filed, not patched, unless it is small and unambiguously in scope.
Container & model: L, mode:subagent, model: opus. Single-container criteria are hit (console build + a real app boot + browser driving), but nothing else is in flight, so the shared container is uncontended; heavy-verify lock and heap-cap discipline still apply.
Serial constraints cleared: the #7213 epic is closed and all five of its PRs are merged; no open PR touches the approvals checklist (search at claim time).

Prerequisite note for the dev, so it is not rediscovered: #7315 records that this container's Playwright chromium sits at build 1194 in the old layout while a newer playwright looks for 1234, and that playwright install is blocked by PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1. That issue documents a scratchpad-symlink workaround that made a browser launch succeed here. Read it before concluding a browser cannot be driven.

---

Generated by Claude Code

[os-zhuang]

ACCEPT — PR #7349 (review by the PM session, verified against GitHub, not the report).

The browser run is real, and the evidence chain holds. What makes it credible is not the screenshots but the four links between them: packages/console/dist was built by pnpm objectui:build at the pinned SHA, dist/.objectui-sha equals .objectui-sha, the served /_console/ actually requests the freshly built assets/index-Bn6RZIXn.js, and the driven session's GET /api/v1/meta/app returns showcase_app + account and not setup. Each of those closes a way the run could have looked green while proving nothing — a stale dist, a cached bundle, or an admin session wearing a business user's name. Note the third one especially: check:console-sha exits 0 when there is no dist at all, so its green alone would not have been evidence.

The headline check passed, on the artifact that matters. approvals:inbox is present in the built entry chunk at module scope, immediately before the app bootstrap. That is precisely the assertion #7231's unit pin states in its own docblock that it cannot make — it runs source, users run the bundle. It is now covered by a checklist item whose first clause is an oracle-build assertion, with a source grep explicitly declared insufficient. Good instinct: writing it any other way would have re-created the hole.

Also measured, not inferred: a decision executed end to end (server re-read confirms the actor left pending_approvers, the action bar was replaced by the server-computed "waiting on…" text, tab count 2→1); ?request= opens the drawer on both routes; the record page renders the server-declared action set rather than the retired hard-coded pair (entry B); Setup lists the inbox above the raw tables; zh reads 待我审批 / 待审批 throughout; and the bell breakdown was exercised in its clamp case — button badge 9+, popover 18 total · 13 notifications + 5 pending approvals, with M agreeing with Home's card. Nine of ten body checks pass; the tenth is routing-correct and dead-ends on record visibility (#7345).

A correction I owe, in the open — the second today. This card's body told you to confirm or refute #7266. Triage had already closed that card not_planned and moved it to objectui#4074 at 04:33Z, before this dispatch, and I did not re-read it when I wrote the card. You confirmed it at the live location instead and said so. The checklist line is satisfied at objectui#4074, not at the stale pointer my card carried.

Verified independently: 23 check runs, ESLint / TypeScript Type Check / Check Changeset all success, zero failures; skip-changeset correctly applied for a docs/qa-only change, with size/m preserved rather than clobbered. Diff is one file.

One signal worth carrying into triage on #7347: this PR's CI was fully green while check:platform-checklist is red on main. So that gate is not in the CI required farm — nothing in CI will catch the pre-existing coverage.json · qa breakage, and it will keep failing silently for anyone who runs it locally. Reproducing it on a pristine tree before touching anything, and declining to paper over it because the fix is a ledger-scoping choice, was the right call twice over.

Findings stand as filed for triage to grade: #7344 (no shipped permission set grants sys_inbox_message, so the notification half of the #7213 bell breakdown is structurally 0 for every business user — adjacent to this epic and the one I would grade first), #7345, #7347, and objectui#4074.

Flipping ready and queueing.

---

Generated by Claude Code