fix(platform-objects): Setup → Users opens on the All Users list view

[objectstack-fleet]

Fixes #21960
Clause-②: no

What changes

Setup → Users now opens on the All Users list view (all_users). Before this, it opened My Profile (me): one row, the administrator, with a page size of 1.

• packages/platform-objects/src/apps/setup-nav.contributions.ts: nav_users gains viewName: 'all_users'. That key is the one ObjectNavItemSchema already declares on an object navigation item ("Default list view to open"). No new key.
• packages/platform-objects/src/identity/sys-user.object.ts: a comment only. The me view's comment said the Account App surfaces it. At main it does not (see the readers below), and the comment now names what does reach it.
• packages/platform-objects/src/apps/setup-users-nav-view.test.ts: the pins.
• .changeset/21960-setup-users-all-users.md: @objectstack/platform-objects patch.

⛔ No listViews reorder, no view removed, no packages/spec edit, no governed surface.

Implemented by the os-dev run of session session_017ErfyP2Rx7XWHJA27QjyUi on branch claude/issue-21960-setup-users-all-users.

The console honours viewName (measured, H1)

Read in objectui at the commit .objectui-sha pins, 0abd4f9f8769fc4c19ad2f96707684876f74c09f:

• packages/layout/src/NavigationRenderer.tsx, resolveHref, case object. The precedence is recordId, then filters, then viewName. With viewName the href is OBJECT/view/VIEWNAME; without it, the bare OBJECT path.
• packages/app-shell/src/views/ObjectView.tsx. The active view is the URL view id, then ?view=, then a view marked isDefault, then views[0]. Only the object's primary list is marked isDefault (buildViewTabs), and sys_user declares none, so views[0] is the first declared list view: me. That is what the card observed.
• packages/core/src/utils/resolve-view-id.ts matches the short name all_users against the qualified id sys_user.all_users.
• "Defaults to "all"" in the spec's viewName describe does not hold for an object that declares list views. all is only the id of the fallback tab the console builds for an object with no list views. This is reported on the card; it is not edited here, because it is spec text.

The served path keeps the key as authored. applyNavContributions (packages/objectql/src/registry.ts) pushes contributed items into a structured clone of the app, and filterNav (packages/rest/src/meta-item-read-gate.ts) pushes a passing leaf item unchanged. nav_notifications already ships viewName: 'recent' through the same contribution path.

Who reads me (measured, H2)

• Navigation items: none. The Account app's profile entry is nav_account_profile: type: 'component', componentRef: 'account:profile_card'. No Account entry routes to sys_user.
• objectui at the pin: none by name. account:profile_card is registered in apps/console/src/registerAccountComponents.tsx and renders ProfilePage, which reads the signed-in user from useAuth() and writes through updateUser.
• Pages: none. pages/sys-user.page.ts names no list view.
• Tests: none.
• Other references: the four generated translation bundles carry the tab's label, and the spec's ObjectNavItemSchema docblock cites sys_user.me as an example of the {current_user_id} filter vocabulary.

So me is reached only as a tab, and as the default tab when a route names no view. Triage's second pin ("the Account app's My Profile still opens on the caller's own row") is held by the profile component, and it is pinned there.

Pins

setup-users-nav-view.test.ts, 7 cases:

• nav_users sits in group_people_org with type: 'object', objectName: 'sys_user' and viewName: 'all_users';
• it carries neither recordId nor filters, both of which resolveHref honours ahead of viewName;
• sys_user.listViews.all_users exists under that same name;
• that view is not scoped to the caller: no filter, no {current_user_id} anywhere in it, and a page size above 1;
• the contribution passes a full NavigationContributionSchema.safeParse, and the parsed item keeps viewName: 'all_users';
• the Account app's first entry is nav_account_profile, the account:profile_card component;
• no Account entry routes to sys_user.

No dogfood door pin. The framework half of the door is the served Setup nav, and both sites on that path pass the item through as authored (above). The data half is unchanged by this diff: all_users carries no filter. A door case would assert what the metadata pin already holds.

Reverse verification

On committed 6639eb4a52:

node scripts/ablation-replace.mjs --file packages/platform-objects/src/apps/setup-nav.contributions.ts \
  --anchor "viewName: 'all_users', " --delete -- \
  pnpm --filter @objectstack/platform-objects exec vitest run --maxWorkers=2 src/apps/setup-users-nav-view.test.ts

• Mutation landed: anchor 1 → 0, blob 72a3adcc1066 → 7c70ade946a9.
• Result: 4 failed | 3 passed (7). The four cases that read nav_users.viewName went red. The recordId / filters case and both Account cases stayed green, as expected, because none of them reads viewName.
• Restored: the blob after restore, 72a3adcc1066, equals the HEAD blob, and git diff HEAD is empty. git status --porcelain was empty afterwards.
• Resolution path: the test imports its subject by relative path from src/, not through the package exports, so no dist/ sits between the mutation and the run.
• First attempt: it was refused by the tool before anything ran, because its replacement text already appeared inside the anchor. It ran nothing and restored.

Tests and gates, at eb9b315b28

That is the merge of origin/main at 2a22177ae7. packages/spec was rebuilt after the merge, then the whole workspace (turbo run build --concurrency=2, 72 tasks).

• pnpm --filter @objectstack/platform-objects exec vitest run --maxWorkers=2: Test Files 61 passed (61), Tests 967 passed (967).
• pnpm --filter @objectstack/platform-objects typecheck: exit 0, with check:test-typecheck: OK.
  • The new test file is in the tsconfig.test.json program, counted with --listFiles.
  • The three errors that program reports are the ledgered feature-gate-guard.test.ts debt.
• node scripts/pm/dispatch-gates.mjs --commands derived 63 commands, and all 63 exited 0.
  • The --ran reconciliation reads 63 derived, 63 run, 0 NOT-MEASURED, 0 UNRUN. That is a derived zero: every line carried its exit code.
  • 14 are new against the dispatch-time list: check-adr-0087-registration (base and self-test), check-empty-changeset (base and self-test), release-rehearsal-clone --self-test, release-pending-publish --self-test, check:engine-double-contract, check:objectql-double-limit, check:objectui-changeset, check:pm-changeset-deadline-census, check:query-options-erasure, check:type-check-coverage, check:type-check-debt and check:where-matcher.
• Artifact-roster block (55 families, all run): 52 exited 0.
  • check-closing-target-claim.mjs, check-partof-closing-keyword.mjs and check-single-claim-paths.mjs answer NOT WIRED without a PR context. CI runs them with one.
  • check-partof-closing-keyword.mjs also exits 0 on this body when PR_BODY is set locally. The other two need the PR number.
• Symbol-anchor sweeps: check:adr-symbol-anchors, check:scripts-symbol-anchors, check:spec-docblock-symbol-anchors and check:adr-anchors all exited 0.
• Prerequisite refusals, then reruns:
  • check:dual-build-cjs-loads, check:i18n, check:lean-entry-closure and check:published-readme-exports first refused with exit 3 (no dist/). After the full build all four exited 0, and check:i18n reads "all bundles in sync".
  • check:type-check-debt first hit the runner's 420 s cap while it refreshed its closure. The rerun exited 0, with "1 ledger entr(ies) re-measured ... none above its recorded number".
• ESLint, narrowed to the three touched TypeScript files: 3 files, 0 errors, 0 warnings.
  • The population is read from eslint.config.mjs: its packages/**/*.{ts,tsx,mts,cts} blocks match all three, and none was reported as ignored.
  • The count comes from --format json.
  • The config enables no type-aware linting (no parserOptions.project), so this diff cannot move a verdict on an untouched file.
  • The repo-wide pnpm lint is CI's.

Acceptance notes

• Other doors still open on me. objectui's AppHeader links the object breadcrumb segment and the object switcher to the bare object path, and a bare path opens views[0]. So from a user's record page, the "Users" breadcrumb still lands on My Profile. This PR closes the Setup nav door, as dispatched. Changing which view sys_user opens by default is the declaration-order route, which the dispatch reserved. It is reported on the card.
• Sidebar highlight. objectui's resolveActiveNavItem scores a viewName item only on its own view. So nav_users no longer lights up on a user's record page or on the other tabs, where the bare item used to claim every sys_user sub-route. Every viewName entry behaves this way today (nav_notifications, and the Account mine entries). This was read from source at the pin, not measured in a browser.
• Six other Setup entries land an admin on a caller-scoped first view. nav_api_keys, nav_sessions, nav_oauth_apps, nav_accounts and nav_user_preferences each open a mine view first, and plugin-sharing's nav_record_shares opens granted_to_me first. Their page sizes are 50 to 100, so these are not one-row views. They are reported on the card, not fixed here.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/platform-objects, touching 4 documentable anchor(s).

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

• content/docs/data-modeling/object-extensions.mdx (via listViews (symbol, a field of const object SysUser))
• content/docs/getting-started/build-with-claude-code.mdx (via listViews (symbol, a field of const object SysUser))
• content/docs/kernel/contracts/metadata-service.mdx (via listViews (symbol, a field of const object SysUser))
• content/docs/kernel/services-checklist.mdx (via listViews (symbol, a field of const object SysUser))
• content/docs/protocol/kernel/i18n-standard.mdx (via listViews (symbol, a field of const object SysUser))
• content/docs/protocol/kernel/plugin-spec.mdx (via listViews (symbol, a field of const object SysUser))
• content/docs/protocol/objectui/layout-dsl.mdx (via listViews (symbol, a field of const object SysUser))
• content/docs/ui/actions.mdx (via listViews (symbol, a field of const object SysUser))
• content/docs/ui/forms.mdx (via listViews (symbol, a field of const object SysUser))
• content/docs/ui/setup-app.mdx (via SETUP_NAV_CONTRIBUTIONS (symbol, a top-level const object))
• content/docs/ui/views.mdx (via listViews (symbol, a field of const object SysUser))

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

• content/docs/releases/v17/17-5.mdx (via listViews (symbol, a field of const object SysUser))
• content/docs/releases/v17/17-6.mdx (via listViews (symbol, a field of const object SysUser))

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 anchor(s) matched too much of the corpus to be a work list: sys_user (literal, 37 pages)
• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: 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.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 3 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 787104baa9ecca77ff13a8e83a4b7349728feadc → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 070347c82aa320e21b4e1d96c18ba68805c525a6 — the merge of head eb9b315b285665aeb9c950758c74220e806c9d50 into base 787104baa9ecca77ff13a8e83a4b7349728feadc, 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 070347c82aa320e21b4e1d96c18ba68805c525a6 && git checkout 070347c82aa320e21b4e1d96c18ba68805c525a6
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 787104baa9ecca77ff13a8e83a4b7349728feadc eb9b315b285665aeb9c950758c74220e806c9d50 && git checkout -B drift-repro 787104baa9ecca77ff13a8e83a4b7349728feadc && git merge --no-ff eb9b315b285665aeb9c950758c74220e806c9d50

node scripts/docs-audit/affected-docs.mjs --json 787104baa9ecca77ff13a8e83a4b7349728feadc

⚠️ 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 787104baa9ecca77ff13a8e83a4b7349728feadc → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

ACCEPT (seat review) — PR #21971 at head eb9b315b28

domain:engine#1 · session_017ErfyP2Rx7XWHJA27QjyUi · read at 2026-10-06T08:48Z. The dev's report is os-dev-report on #21960.

• The change:
  • setup-nav.contributions.ts's nav_users sets viewName: 'all_users', the key ObjectNavItemSchema already declares (packages/spec/src/ui/app.zod.ts:432).
  • The me view's comment in sys-user.object.ts now says what is true at main: no navigation item names me, and the Account app's profile entry is the account:profile_card component.
  • ⛔ No listViews reorder, no view removed, and no spec edit.
• H1 (console): the dev read the pinned objectui source at 0abd4f9f87, not in a browser:
  • NavigationRenderer.tsx's resolveHref routes a viewName item to OBJECT/view/VIEWNAME.
  • ObjectView.tsx:2151 opens resolvedViewId || defaultViewId || views[0].
  • The served nav path passes the key through unchanged (registry.ts:4635, meta-item-read-gate.ts:774). nav_notifications already ships a viewName on the same path.
• Pins: setup-users-nav-view.test.ts has 7 cases.
  • Reverse verification on 6639eb4a52 deleted the key: the 4 viewName cases went red, and the 3 controls stayed green. The restore was proven by blob equality and an empty git diff HEAD.
  • The platform-objects suite passes, 967 tests.
• CI on eb9b315b28: 31 success, and the 3 skips are all in the roster. Readings against main at 230e4944b0: NOT governed (0 of 4 paths), and git merge-tree is clean.
• Clause-②: no, at patch. No contract review is owed: there is no spec or governed path, and no exported type moves.
• The dev's open question (bare-object doors and six more Setup entries): the seat takes option A. This PR stays as is, and the family is filed as finding(platform-objects): six more Setup object entries open their object's caller-scoped first list view (mine / granted_to_me), and sys_user's bare-object doors still open me (#21960's family, from PR #21971) #21972 for triage to decide per object. That card includes the warning that nav_account_linked relies on declaration order.
• Filed from the report: finding(spec): ObjectNavItemSchema.viewName says the default is "all", but the console opens the object's primary list view, else its FIRST declared list view; "all" exists only for an object with no listViews #21973. viewName's describe text says the default is "all", while the runtime opens the default list view, else the first declared one.
• Not filed: objectui's active-nav scoring for a lone viewName item, which is not highlighted on the object's other sub-routes. It is read from source only and has no carrier here.

---

Generated by Claude Code