feat(permissions): delegated dashboard access + route-derived permission registry

[Abdulkhalek-1]

Lets a guild member holding an explicit dashboard grant use the dashboard without Discord MANAGE_GUILD, and replaces the hand-maintained permission registry with one derived from the route table.

Supersedes the original gate model in docs/features/dashboard-permissions.md ("Non-MANAGE_GUILD access: No"). Design: docs/superpowers/specs/2026-07-28-delegated-dashboard-access-design.md.

Access model

Authority now comes from three sources: guild ownership, live Discord admin rights (checked against the bot's view, never the cached OAuth snapshot), or an explicit grant (DashboardRoleAssignment / DashboardUserPermission).

User	requirePermissions: false	requirePermissions: true
Owner	*	*
Live guild admin	*	assignments ∪ isDefault roles ∪ overrides
Member with grants	their grants	their grants
Member without grants / non-member	∅	∅

Two rules carry the safety of this change:

• requirePermissions constrains admins only — it never gates explicit grants.
• isDefault roles apply to admins only. If they applied to members, enabling the toggle would hand every member of the server whatever the default role holds. That is one line (includeDefaultRoles: authority.isAdmin) with a test asserting the negative directly.

requireGuildAdmin → requireGuildAccess (authorizes on a non-empty resolved permission set), renamed across 21 route files. The four Discord lookup routes that backed the pickers now sit behind dashboard.lookups.view.

Two escalation holes closed

Both were reachable only by MANAGE_GUILD admins before this branch, which is why they survived — delegated access turns them into real paths.

1. Role assignment (POST .../members) checked nothing: a dashboard.roles.manage holder could assign themselves an existing Full Admin role.
2. isDefault promotion ran its escalation check inside if (body.permissions) while applying isDefault unconditionally — so PUT {"isDefault": true} alone promoted a * role to guild default, granting every admin *.

Both now validate against the role's existing persisted permissions. Demotion stays unguarded (it cannot escalate).

Permission registry

requirePermission() self-registers every key it enforces at route-registration time, so the route table is the registry — a key cannot appear in the UI without a route behind it. The 305-line static list is deleted; expandWildcard / resolveEffectivePermissions take the vocabulary as a parameter.

Boot validation runs in createApp(); since nothing in the suite boots the app, scanDeclaredPermissionKeys scans the route sources so CI catches an unknown module or bad action verb.

Also

• The permission grid was the last untranslated surface — now fully translated across all 48 locales.
• Overview no longer spins forever for users without actions.analytics.view (a pre-existing bug for restricted admins), and shows them what they can reach instead.
• The role editor disables permissions the editor cannot themselves grant, and warns when a role can configure modules but not use pickers.

Verification

typecheck 14/14 · unit 9/9 tasks (dashboard 114 files / 1532 tests, bot 428, systems 346) · integration 9 files / 77 tests · pnpm install --frozen-lockfile clean · dashboard boots with registry validation passing.

Not covered by automation: the live-authority path needs a manual check with two real Discord accounts — assign a dashboard role to a non-admin and confirm the server appears with the delegated badge, the sidebar filters, and a non-permitted route shows the denied page.

🤖 Generated with Claude Code

[Abdulkhalek-1]

Added: role member assignment UI

The branch as first pushed had a gap — there was no way to actually give someone a dashboard role. The API, hooks, and member-search endpoint all existed, and the role editor even showed a member count, but nothing rendered an add/remove control. The only activation path was a hand-written SQL INSERT, which made the feature unusable as shipped.

The role editor now has a Members section:

• Search-and-add with avatars, over the existing debounced member-search endpoint.
• Provenance on every row — who granted the access and when, since this is a permission-granting surface.
• Applies immediately. Adding grants access at that moment; removing revokes it. Not deferred to the Save button, which owns name/colour/permissions — an access grant shouldn't be a side effect of a form save, and each action gets its own audit-log entry.
• Undo on removal, matching the automation UI's delete→Undo toast, so one misclick doesn't silently revoke someone's access.
• Gated to mirror the server. The add control is disabled with an explanatory tooltip when you don't hold everything the role grants, and you can't select yourself — so you learn before the request rather than via a raw 403.

Two review rounds went into that last point. The self-exclusion first depended on useAuth() having resolved, and the page's loading gate doesn't wait for it — so on a hard reload a non-owner could briefly select themselves. Gating on isLoading fixed the loading race but not the errored one: useAuth uses retry: false, so a failed fetch settles at isLoading: false, data: undefined and sailed straight through. Both call sites now share one callerIdKnown flag and fail closed on loading, errored, and null-body alike.

Also extracted the duplicated member-search UI into a shared member-search-list consumed by both this picker and the existing MemberMultiSelect, whose rendered output is unchanged (the automation trigger-filter suite passes untouched).

Verification: typecheck 14/14 · unit 9/9 tasks (dashboard 1551, bot 428, systems 346) · integration 77 · --frozen-lockfile clean · no new dependency · new strings translated across all 48 locales.

🤖 Generated with Claude Code