plutonium 0.65.0 → 0.66.0

data/docs/reference/app/index.md

@@ -4,9 +4,9 @@ How a Plutonium app is assembled: installation, the package system (feature vs p
 
 ## Sub-pages
 
-- [Packages](./packages) — feature vs portal packages, structure, namespacing, package loading
-- [Portals](./portals) — portal engines, mounting, controller concerns, `register_resource` (including singular and custom routes), connecting resources via `pu:res:conn`
-- [Generators](./generators) — full `pu:*` generator catalog
+- [Packages](./packages): feature vs portal packages, structure, namespacing, package loading
+- [Portals](./portals): portal engines, mounting, controller concerns, `register_resource` (including singular and custom routes), connecting resources via `pu:res:conn`
+- [Generators](./generators): full `pu:*` generator catalog
 
 ## Installation
 
@@ -30,7 +30,7 @@ The `plutonium.rb` template re-runs the full app bootstrap (dotenv, annotate, so
 bin/rails app:template \
   LOCATION=https://radioactive-labs.github.io/plutonium-core/templates/base.rb
 
-# Or manual — add `gem "plutonium"` to Gemfile, then:
+# Or manual: add `gem "plutonium"` to Gemfile, then:
 bundle install
 rails generate pu:core:install
 ```
@@ -38,7 +38,7 @@ rails generate pu:core:install
 ## Full setup workflow
 
 ```bash
-# 1. Core install — base controllers, policies, definitions, layouts
+# 1. Core install: base controllers, policies, definitions, layouts
 rails generate pu:core:install
 
 # 2. Auth (if needed)
@@ -55,10 +55,7 @@ rails db:prepare
 # 5. Connect resource to portal
 rails generate pu:res:conn Post --dest=admin_portal
 
-# 6. Mount portal in config/routes.rb
-#    mount AdminPortal::Engine, at: "/admin"
-
-# 7. Start
+# 6. Start (step 3 already mounted the portal at /admin)
 bin/dev   # uses Procfile to run Rails + CSS watcher
 ```
 
@@ -70,10 +67,10 @@ Visit `http://localhost:3000/admin`.
 app/
 ├── controllers/
 │   ├── plutonium_controller.rb     # non-resource base
-│   └── resource_controller.rb      # CRUD base — see Behavior › Controllers
+│   └── resource_controller.rb      # CRUD base; see Behavior › Controllers
 ├── definitions/resource_definition.rb
 ├── interactions/resource_interaction.rb
-├── models/resource_record.rb       # abstract model — includes Plutonium::Resource::Record
+├── models/resource_record.rb       # abstract model: includes Plutonium::Resource::Record
 ├── policies/resource_policy.rb
 └── views/layouts/resource.html.erb
 
@@ -103,7 +100,7 @@ Plutonium.configure do |config|
   # :classic preserves the legacy header + sidebar (only when upgrading).
   # config.shell = :classic
 
-  # Custom assets — see UI › Assets
+  # Custom assets; see UI › Assets
   # config.assets.stylesheet = "custom_stylesheet"
   # config.assets.script     = "custom_script"
   # config.assets.logo       = "custom_logo.png"
@@ -150,9 +147,9 @@ Meta-generators (`pu:saas:setup`) propagate these flags to the generators they c
 
 ## Related
 
-- [Packages](./packages) — feature vs portal package structure
-- [Portals](./portals) — portal engines, routing, resource connection
-- [Generators](./generators) — full generator reference
-- [Auth](/reference/auth/) — Rodauth setup and account types
-- [UI › Assets](/reference/ui/assets) — Tailwind, Stimulus, design tokens
-- [Tutorial](/getting-started/tutorial/) — step-by-step walkthrough
+- [Packages](./packages): feature vs portal package structure
+- [Portals](./portals): portal engines, routing, resource connection
+- [Generators](./generators): full generator reference
+- [Auth](/reference/auth/): Rodauth setup and account types
+- [UI › Assets](/reference/ui/assets): Tailwind, Stimulus, design tokens
+- [Tutorial](/getting-started/tutorial/): step-by-step walkthrough

data/docs/reference/app/packages.md

@@ -1,6 +1,6 @@
 # Packages
 
-Plutonium apps are organized into **packages** — Rails engines with stricter conventions. Two flavors, hard split:
+Plutonium apps are organized into **packages**: Rails engines with stricter conventions. Two flavors, hard split:
 
 | Type | Purpose | Generator | Examples |
 |---|---|---|---|
@@ -60,7 +60,7 @@ Each feature package gets its own base classes:
 - `Blogging::ResourceDefinition`
 - `Blogging::ResourceInteraction`
 
-These inherit from the main app's base classes — extend them for package-wide defaults.
+These inherit from the main app's base classes; extend them for package-wide defaults.
 
 ### Creating resources inside a feature package
 
@@ -111,13 +111,13 @@ This is loaded from `config/application.rb`. Migrations from all packages are pi
 
 ## When to use which
 
-**Feature packages** — domain logic that:
+**Feature packages**: domain logic that:
 
 - Could be reused across multiple portals (admin and customer both edit `Blogging::Post`).
 - Has no inherent UI / auth (it's just behavior).
 - You want isolated from other domains (`billing` should not depend on `blogging`).
 
-**Portal packages** — user-facing surfaces that:
+**Portal packages**: user-facing surfaces that:
 
 - Have a specific auth flow (admin vs customer vs public).
 - Render different views of the same underlying resources.
@@ -137,10 +137,10 @@ packages/
     └── controllers, views, routes
 ```
 
-The portals expose the features. A single feature can be exposed by multiple portals — usually with different policies and definitions per portal.
+The portals expose the features. A single feature can be exposed by multiple portals, usually with different policies and definitions per portal.
 
 ## Related
 
-- [Portals](./portals) — portal-specific configuration (mounting, auth, route registration)
-- [Generators](./generators) — `pu:pkg:package` and `pu:pkg:portal` flags
-- [Guide: Creating Packages](/guides/creating-packages) — task-oriented walkthrough
+- [Portals](./portals): portal-specific configuration (mounting, auth, route registration)
+- [Generators](./generators): `pu:pkg:package` and `pu:pkg:portal` flags
+- [Guide: Creating Packages](/guides/creating-packages): task-oriented walkthrough

data/docs/reference/app/portals.md

@@ -5,7 +5,7 @@ A portal is a Rails engine mixing in `Plutonium::Portal::Engine`. It defines its
 ## 🚨 Critical
 
 - **Use `pu:pkg:portal` for everything.** Never hand-write the engine file, controller concern, or layout.
-- **Pass `--auth=<name>`, `--public`, or `--byo`** for unattended runs — without one of these flags, the generator prompts.
+- **Pass `--auth=<name>`, `--public`, or `--byo`** for unattended runs; without one of these flags, the generator prompts.
 - **Always connect resources with `pu:res:conn`.** Until connected, a resource has no portal routes and is invisible.
 - **For custom routes on a registered resource, pass `as:`.** Without it, `resource_url_for` can't build URLs.
 
@@ -20,7 +20,7 @@ rails g pu:pkg:portal <name>
 | Option | Description |
 |---|---|
 | `--auth=NAME` | Rodauth account to authenticate with (e.g. `--auth=user`) |
-| `--public` | Public access — no authentication |
+| `--public` | Public access, no authentication |
 | `--byo` | Bring your own authentication |
 | `--scope=CLASS` | Entity class for multi-tenancy (e.g. `--scope=Organization`) |
 
@@ -51,7 +51,9 @@ end
 
 ## Controller concern (auth)
 
-Every portal has a `Concerns::Controller` mixed into its `ResourceController`. The generator wires this up; you customize for auth flow and shared before_action hooks.
+Every portal has a `Concerns::Controller`, included by both its `ResourceController` (resource pages) and its `PlutoniumController` (dashboard and other non-resource pages). The generator wires this up; you customize for auth flow and shared before_action hooks.
+
+Portal-wide helpers the layout calls belong here, declared with `helper_method`, so they work on the dashboard as well as resource pages. The common case is `profile_url`: `Plutonium::Auth::Rodauth` defines it as `nil`, and the avatar menu only shows a Profile link when it returns a URL. `pu:profile:conn --dest=<portal>` writes the override into this concern (see [Auth › Profile](/reference/auth/profile)).
 
 ### Rodauth
 
@@ -89,19 +91,63 @@ end
 
 ## Mounting
 
+`pu:pkg:portal` writes the mount at the bottom of the portal's own `packages/<name>_portal/config/routes.rb`, at `/<name>`, wrapped in an auth constraint when `--auth` is given:
+
 ```ruby
-# config/routes.rb
+# packages/admin_portal/config/routes.rb (after the engine's routes.draw block)
 Rails.application.routes.draw do
-  # Authenticated mount
   constraints Rodauth::Rails.authenticate(:user) do
     mount AdminPortal::Engine, at: "/admin"
   end
+end
+```
+
+With `--public` or `--byo` the mount is unconstrained and the portal handles its own auth.
+
+To change the path, edit `at:` in place. Don't mount the engine again in `config/routes.rb`: the second `mount` reuses the route name (`admin_portal`) and Rails raises `ArgumentError: Invalid route name, already in use`.
+
+Route order matters: the app's `config/routes.rb` is drawn first, then each package's routes file, then gem engines (Active Storage, Turbo).
+
+### Mounting a portal at `/`
+
+Two things change when a portal is mounted at `"/"`.
+
+**Drop the `Rodauth::Rails.authenticate` constraint and authenticate in the controller concern instead.** The constraint does not fail the match for an anonymous visitor; it calls `rodauth.require_account`, which redirects to login. A constrained mount at `/` matches every path the app's own routes did not claim, so it redirects anonymous requests meant for routes drawn after it (other portals, Active Storage) and turns unknown URLs into login redirects.
+
+```ruby
+# packages/desk_portal/config/routes.rb
+Rails.application.routes.draw do
+  mount DeskPortal::Engine, at: "/"
+end
+
+# packages/desk_portal/app/controllers/desk_portal/concerns/controller.rb
+module DeskPortal
+  module Concerns
+    module Controller
+      extend ActiveSupport::Concern
+      include Plutonium::Portal::Controller
+      include Plutonium::Auth::Rodauth(:user)
+
+      included do
+        before_action { rodauth.require_account }
+      end
+    end
+  end
+end
+```
+
+**Move the engine's root off `/` but keep the name.** The app's `root` is drawn first, so the generated `root to: "dashboard#index"` is unreachable and the portal's `root_path` points at the app's home page. Plutonium's header, icon rail, breadcrumbs and wizard exits all link to `root_path`, so the portal still needs a route named `root`:
 
-  # Unconstrained — the portal handles its own auth
-  mount PublicPortal::Engine, at: "/public"
+```ruby
+DeskPortal::Engine.routes.draw do
+  get "dashboard", to: "dashboard#index", as: :root
+  register_resource ::Comment
+  # register resources above.
 end
 ```
 
+The same applies to `register_dashboard ..., at: "/"`. Confirm with `Rails.application.routes.recognize_path("/")` (still the app's home) and `recognize_path("/dashboard")`.
+
 ## Routes & `register_resource`
 
 Portal routes live in `packages/<name>_portal/config/routes.rb`:
@@ -126,7 +172,7 @@ For each call, Plutonium auto-generates:
 - Nested routes for every registered `has_many` / `has_one` parent (prefixed `nested_`)
 - Route names that `resource_url_for` can resolve
 
-You list every resource the portal exposes. If a resource isn't registered, it has no URLs in that portal — `resource_url_for` will fail.
+You list every resource the portal exposes. If a resource isn't registered, it has no URLs in that portal, so `resource_url_for` will fail.
 
 ### Choosing nested associations
 
@@ -136,11 +182,11 @@ Name the associations that get nested routes, and the rest are not drawn:
 register_resource ::Post, associations: %i[comments post_detail]
 ```
 
-`associations: []` draws none, and a name that is not a routable association fails the boot. Set `config.nested_association_routes = :declared` to make naming them the rule — see [Tenancy › Nested resources](../tenancy/nested-resources#declaring-which-associations-get-routes).
+`associations: []` draws none, and a name that is not a routable association fails the boot. Set `config.nested_association_routes = :declared` to make naming them the rule; see [Tenancy › Nested resources](../tenancy/nested-resources#declaring-which-associations-get-routes).
 
 ### Singular (singleton) resources
 
-For resources with no collection — a single per-user `Profile`, app-wide `Settings`, etc.:
+For resources with no collection: a single per-user `Profile`, app-wide `Settings`, etc.:
 
 ```ruby
 register_resource ::Profile, singular: true
@@ -178,12 +224,12 @@ end
 ```
 
 ::: warning Always pass `as:`
-Without `as:`, `resource_url_for(@post, action: :preview)` fails because there's no named route — especially critical for nested resources.
+Without `as:`, `resource_url_for(@post, action: :preview)` fails because there's no named route, which is especially critical for nested resources.
 :::
 
-For most operations with business logic, prefer **interactive actions** (definition + interaction — see [Resource › Actions](/reference/resource/actions)) over custom controller routes. Action routes wire automatically with no `register_resource` block needed.
+For most operations with business logic, prefer **interactive actions** (definition + interaction; see [Resource › Actions](/reference/resource/actions)) over custom controller routes. Action routes wire automatically with no `register_resource` block needed.
 
-## Connecting resources — `pu:res:conn`
+## Connecting resources: `pu:res:conn`
 
 A resource is invisible until connected to at least one portal. The generator wires up the portal-specific controller, policy, definition, and route registration.
 
@@ -191,7 +237,7 @@ A resource is invisible until connected to at least one portal. The generator wi
 rails g pu:res:conn RESOURCE [RESOURCE...] --dest=PORTAL_NAME [--singular]
 ```
 
-Pass resources directly — avoids interactive prompts. No `--src` needed.
+Pass resources directly to avoid interactive prompts. No `--src` needed.
 
 ```bash
 # Main app resources
@@ -286,13 +332,13 @@ end
 ## Per-portal overrides
 
 ```ruby
-# Definition — how fields render per portal
+# Definition: how fields render per portal
 class AdminPortal::PostDefinition < ::PostDefinition
   scope :pending_review
   input :internal_notes, hint: "Not shown to the author"
 end
 
-# Policy — which fields exist, and who may act
+# Policy: which fields exist, and who may act
 #          `internal_notes` appears for admins because THIS permits it,
 #          not because the definition above mentions it.
 class AdminPortal::PostPolicy < ::PostPolicy
@@ -302,7 +348,7 @@ class AdminPortal::PostPolicy < ::PostPolicy
   def permitted_attributes_for_create = %i[title content featured internal_notes]
 end
 
-# Controller — different redirect after submit
+# Controller: different redirect after submit
 module AdminPortal
   class PostsController < ResourceController
     private
@@ -321,7 +367,7 @@ config.after_initialize do
 end
 ```
 
-Strategies: `:path` (entity id in URL — default) or a custom method name on the portal controller concern.
+Strategies: `:path` (entity id in URL, the default) or a custom method name on the portal controller concern.
 
 For the full multi-tenancy story, see [Tenancy › Entity scoping](/reference/tenancy/entity-scoping).
 
@@ -330,13 +376,13 @@ For the full multi-tenancy story, see [Tenancy › Entity scoping](/reference/te
 The generated `dashboard#index` is a plain page listing the registered resources. To replace it with a [dashboard](/guides/dashboards) of metric and chart cards, run `rails g pu:dashboard Home --dest=<portal> --at=/`, which swaps the `root to:` line for a `register_dashboard ... at: "/"` registration.
 
 ```ruby
-# config/routes.rb
+# packages/admin_portal/config/routes.rb
 AdminPortal::Engine.routes.draw do
   root to: "dashboard#index"
   get "settings", to: "settings#index"
 end
 
-# Controller — inherit from PlutoniumController, NOT ResourceController
+# Controller: inherit from PlutoniumController, NOT ResourceController
 module AdminPortal
   class DashboardController < PlutoniumController
     def index
@@ -351,7 +397,7 @@ See [UI › Pages](/reference/ui/pages) for custom Phlex page classes.
 ## Multiple portals
 
 ```ruby
-# Admin — full access, entity-scoped
+# Admin: full access, entity-scoped
 module AdminPortal
   class Engine < Rails::Engine
     include Plutonium::Portal::Engine
@@ -362,7 +408,7 @@ module AdminPortal
   end
 end
 
-# Customer dashboard — entity-scoped to the customer's organization
+# Customer dashboard: entity-scoped to the customer's organization
 module DashboardPortal
   class Engine < Rails::Engine
     include Plutonium::Portal::Engine
@@ -373,7 +419,7 @@ module DashboardPortal
   end
 end
 
-# Public — no auth, no entity scoping
+# Public: no auth, no entity scoping
 module PublicPortal
   class Engine < Rails::Engine
     include Plutonium::Portal::Engine
@@ -383,9 +429,9 @@ end
 
 ## Related
 
-- [Packages](./packages) — feature vs portal split, structure, namespacing
-- [Generators](./generators) — full `pu:pkg:portal` / `pu:res:conn` option reference
-- [Behavior › Controllers](/reference/behavior/controllers) — controller key methods, hooks, customizations
-- [Tenancy › Entity scoping](/reference/tenancy/entity-scoping) — multi-tenancy mechanics
-- [Auth](/reference/auth/) — Rodauth account types referenced by `--auth=`
-- [UI › Layouts](/reference/ui/layouts) — customizing portal chrome
+- [Packages](./packages): feature vs portal split, structure, namespacing
+- [Generators](./generators): full `pu:pkg:portal` / `pu:res:conn` option reference
+- [Behavior › Controllers](/reference/behavior/controllers): controller key methods, hooks, customizations
+- [Tenancy › Entity scoping](/reference/tenancy/entity-scoping): multi-tenancy mechanics
+- [Auth](/reference/auth/): Rodauth account types referenced by `--auth=`
+- [UI › Layouts](/reference/ui/layouts): customizing portal chrome

data/docs/reference/auth/accounts.md

@@ -1,8 +1,8 @@
 # Accounts
 
-Rodauth account types. Pick one (or several — apps can have multiple side-by-side).
+Rodauth account types. Pick one (or several; apps can have multiple side-by-side).
 
-## Basic account — `pu:rodauth:account`
+## Basic account: `pu:rodauth:account`
 
 ```bash
 rails generate pu:rodauth:account user [options]
@@ -59,7 +59,7 @@ rails g pu:rodauth:account api_user --api_only --jwt --jwt_refresh
 rails g pu:rodauth:account user --kitchen_sink
 ```
 
-## Admin account — `pu:rodauth:admin`
+## Admin account: `pu:rodauth:admin`
 
 Pre-configured secure admin with multi-phase login, **required** TOTP, recovery codes, lockout, active session tracking, audit logging, role-based access, invite interaction, and **no public signup**.
 
@@ -74,7 +74,7 @@ rails g pu:rodauth:admin admin --extra-attributes=name:string,department:string
 | `--roles` | `super_admin,admin` | Comma-separated roles (positional enum) |
 | `--extra_attributes` | | Additional model attributes (e.g. `name:string`) |
 
-**Role-ordering convention:** index 0 is the most privileged. Generated invite interaction defaults new invitees to `roles[1]` — the order in `--roles=` matters.
+**Role-ordering convention:** index 0 is the most privileged. Generated invite interaction defaults new invitees to `roles[1]`, so the order in `--roles=` matters.
 
 ```ruby
 enum :role, super_admin: 0, admin: 1
@@ -82,12 +82,12 @@ enum :role, super_admin: 0, admin: 1
 
 **Invite + resend.** The admin resource gets two actions:
 
-- **Invite** — invite a new admin by email; Rodauth sends a verification link and the invitee sets their own password through the verify flow.
-- **Resend invitation** — re-send the verification email. Only shown for admins who haven't verified yet.
+- **Invite**: invite a new admin by email; Rodauth sends a verification link and the invitee sets their own password through the verify flow.
+- **Resend invitation**: re-send the verification email. Only shown for admins who haven't verified yet.
 
 This uses Rodauth account verification, separate from the [Tenancy › Invites](/reference/tenancy/invites) system.
 
-Rake task for direct admin creation (generated alongside the account — namespace is `rodauth`, task name is the account name):
+Rake task for direct admin creation (generated alongside the account; namespace is `rodauth`, task name is the account name):
 
 ```bash
 EMAIL=admin@example.com rails rodauth:admin
@@ -96,7 +96,7 @@ EMAIL=admin@example.com rails rodauth:admin
 
 The task creates the account and triggers a verification email; the admin sets their own password via that flow. No password is passed on the command line.
 
-## SaaS setup — `pu:saas:setup` (meta-generator) {#saas-setup}
+## SaaS setup: `pu:saas:setup` (meta-generator) {#saas-setup}
 
 Creates the User + Entity + Membership trio AND runs:
 
@@ -152,7 +152,7 @@ class OrganizationCustomer < ApplicationRecord
 end
 ```
 
-## API client — `pu:saas:api_client`
+## API client: `pu:saas:api_client`
 
 For machine-to-machine authentication. HTTP Basic Auth with auto-generated password.
 
@@ -233,12 +233,12 @@ end
 Emitted by the generators; both parts are required for concurrent portal logins.
 
 ```ruby
-# app/rodauth/rodauth_plugin.rb — the shared base, once
+# app/rodauth/rodauth_plugin.rb: the shared base, once
 enable :session_isolation
 ```
 
 ```ruby
-# app/rodauth/<name>_rodauth_plugin.rb — once per account type
+# app/rodauth/<name>_rodauth_plugin.rb: once per account type
 session_key_prefix "admin_"           # namespaces EVERY key, account id included
 remember_cookie_key "_admin_remember"
 ```
@@ -249,7 +249,7 @@ Do **not** also set `session_key`: explicit values bypass `convert_session_key`
 
 ## Related
 
-- [Profile](./profile) — profile resource + SecuritySection component
-- [App › Portals › Controller concern (auth)](/reference/app/portals#controller-concern-auth) — wiring accounts into portal controllers
-- [Tenancy › Invites](/reference/tenancy/invites) — invitation system on top of Rodauth signup
-- [App › Generators › Authentication generators](/reference/app/generators#authentication-generators) — full generator catalog
+- [Profile](./profile): profile resource + SecuritySection component
+- [App › Portals › Controller concern (auth)](/reference/app/portals#controller-concern-auth): wiring accounts into portal controllers
+- [Tenancy › Invites](/reference/tenancy/invites): invitation system on top of Rodauth signup
+- [App › Generators › Authentication generators](/reference/app/generators#authentication-generators): full generator catalog

data/docs/reference/auth/index.md

@@ -4,18 +4,18 @@ Plutonium uses [Rodauth](http://rodauth.jeremyevans.net/) via [rodauth-rails](ht
 
 ## Sub-pages
 
-- [Accounts](./accounts) — Rodauth install, basic accounts, admin accounts, SaaS setup, account customization
-- [Profile](./profile) — profile resource generator, the SecuritySection component
+- [Accounts](./accounts): Rodauth install, basic accounts, admin accounts, SaaS setup, account customization
+- [Profile](./profile): profile resource generator, the SecuritySection component
 
 ## 🚨 Critical
 
 - **Use the generators.** `pu:rodauth:install`, `pu:rodauth:account`, `pu:rodauth:admin`, `pu:saas:setup`, `pu:profile:install`, `pu:profile:conn`. Never hand-write Rodauth plugin files, account models, or profile resources.
-- **Role index 0 is the most privileged** (`owner`, `super_admin`). Invite interactions default new invitees to **index 1** — the order in `--roles=` matters.
+- **Role index 0 is the most privileged** (`owner`, `super_admin`). Invite interactions default new invitees to **index 1**, so the order in `--roles=` matters.
 - **`pu:saas:setup --roles=...` always prepends `owner` as index 0.** Don't include `owner` in the option.
 - **`pu:saas:setup` is a meta-generator.** It also runs `pu:saas:portal`, `pu:profile:setup`, `pu:saas:welcome`, and `pu:invites:install`. Don't re-run those manually.
-- **Profile association is always `:profile`** regardless of the model class — `current_user.profile`, `build_profile`, `params.require(:profile)`.
-- **Profile needs `pu:profile:conn` to be visible** — without it, the singular `/profile` route and `profile_url` helper don't exist.
-- **Every user needs a profile row.** Add an `after_create` callback or `find_or_create_by` — otherwise `current_user.profile` is nil.
+- **Profile association is always `:profile`** regardless of the model class: `current_user.profile`, `build_profile`, `params.require(:profile)`. `pu:profile:conn` hardcodes `current_user.profile`.
+- **Profile needs `pu:profile:conn` to be visible.** Without it, there is no singular `/profile` route and `profile_url` stays `nil` (no menu link).
+- **Check an existing profile policy for `update?`.** Older `pu:profile:conn` output lacks `def update? = true`, so the profile can't be edited once it exists. See [Profile](./profile#what-pu-profile-conn-generates).
 
 ## Install Rodauth
 
@@ -34,7 +34,7 @@ class ResourceController < PlutoniumController
 end
 ```
 
-Multiple account types — include the matching `:name`:
+Multiple account types: include the matching `:name`:
 
 ```ruby
 class AdminController < PlutoniumController
@@ -80,9 +80,9 @@ Authorization: Bearer <access_token>
 
 ## Related
 
-- [Accounts](./accounts) — account types and feature flags
-- [Profile](./profile) — profile resource + SecuritySection
-- [Tenancy › Invites](/reference/tenancy/invites) — invitation system on top of Rodauth signup
-- [App › Portals › Controller concern (auth)](/reference/app/portals#controller-concern-auth) — portal-side wiring
-- [Guides › Authentication](/guides/authentication) — task-oriented walkthrough
+- [Accounts](./accounts): account types and feature flags
+- [Profile](./profile): profile resource + SecuritySection
+- [Tenancy › Invites](/reference/tenancy/invites): invitation system on top of Rodauth signup
+- [App › Portals › Controller concern (auth)](/reference/app/portals#controller-concern-auth): portal-side wiring
+- [Guides › Authentication](/guides/authentication): task-oriented walkthrough
 - [Guides › User profile](/guides/user-profile)