[zumbrunn]

Behaviour to know about on upgrade: after this PR, holding admin, editor or author in a user's roles[] carries editing rights for any signed-in user, with or without the admin plugin, live and for user_store: db and external-jwt role claims too. (On 0.35 a local-store user with such a role already got it on the next restart on a site that ran the admin.) A site that uses editor or author as a content tier should rename them. Details and the dune doctor --boot note are in the changelog and in #134.

Closes #130. Stacked on #131 (base feat/admin-settings-in-plugin); retarget to main once the stack below it merges.

What

A signed-in site user with an editing role can now edit inline on a site with no admin plugin, and a role granted or revoked while the app runs applies at once.

• The authz system exists whenever something uses it: site.auth is configured, a plugin provides auth.session, or a plugin declares authzActions. mountDuneAuth reuses that one instance. The inline-edit WebSocket checks the public-auth instance (it differs from bootstrap's when site.auth.authz_store is db).
• Roles grant at group level. bootstrapRoleGrants writes group:admin|editor|author → admin|editor|author on app:site once. Site auth already keeps member of group:<role> in sync, so having the role is enough: no per-user tuple, no admin plugin. A content-only role (member, subscriber, ...) grants nothing. Group subjects needed group added to the schema's subjectTypes; spiked first, grants propagate to members.
• app:admin → app:site (SITE_RESOURCE, exported). The resource names what is protected, not the panel. Tuples are derived data and re-seeded at every start; an HMAC-protected store needs dune authz:sign once.
• Membership follows roles[]. It was only seeded at startup, so any runtime role change waited for a restart (page gating has the same gap). syncUserRoles / withRoleSync now keep it equal on every create, roles update and delete, for user stores core creates (site auth, services.users.createLocalStore()). The CLI role commands sync too. The payments webhook checks membership first so a synced store doesn't get the tuple twice.

Behaviour changes to review

• external-jwt: a role claim of admin, editor or author in the IdP's token now carries pages.update. Before, only users the admin plugin registered had it. Easy to guard to dune mode if you'd rather not.
• Breaking for plugins that check the resource themselves: use SITE_RESOURCE. @dune/plugin-admin and @dune/testing already do (companion changes below).
• A plugin that builds its own user store must call syncUserRoles itself.

Tests

• tests/runtime/site_user_editing_test.ts: login-only site, the same with an auth.session provider, every role, and a role granted at runtime through services.users (403 → 204 → 403 without a restart). The first three fail without the fix.
• tests/auth/sync_roles_test.ts and a payments case.
• deno task test 2270 pass, deno task check clean, no deno.lock change. plugin-admin (283) and testing (44) suites pass against this branch.

Companion changes (already pushed to their open drafts)

• feat(admin)!: provide auth.session and scheduler.executor, consume capabilities (#97, step 4) plugin-admin#17: 7225112, permissions on app:site
• feat(conformance)!: read the admin's prefix from the admin.prefix slot (dune#123, step 2) testing#4: 72ce003, stub admin on app:site
• feat: first slice of the plugin contract (app, storage, content API, search engine, forms) plugin-api#1: 1141d11, AuthzService docs
• docs: snake_case config keys, removed deprecations and plugin services (0.36) dune-docs#22: b15caeb, 572cf04, authorization page

Not covered: whether a running server picks up a tuple the CLI writes to the file store from another process without a restart (true of the direct tuples before this too).

🤖 Generated with Claude Code