diff --git a/CLAUDE.md b/CLAUDE.md
index 4b3786e..3691c8c 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -4,6 +4,8 @@ A writing workspace for long-form creative work: novels, serials, worldbuilding,
 
 The prototype (`scratch/app-design/`) is gitignored, so a fresh clone will not have it. Without it, work from the committed design docs in `scratch/system-design/`, the design system already ported to `src/lib/styles/`, and the patterns in the existing screens; if a step genuinely needs the visual spec and it is absent, say so rather than inventing a layout.
 
+Before building a new page or changing an existing one, read the components sheet at `scratch/system-design/design-system.md`. It names the canonical primitives and shells, the legacy patterns that must not be copied, and the per-page checklist; keep it updated when a primitive is added or changed.
+
 Progress is tracked in `TODO.md` (current step, feedback backlog, review follow-ups); keep it updated as steps complete.
 
 Stack: SvelteKit and TypeScript, Drizzle on Postgres, a pg-boss worker for background jobs, CodeMirror 6 for the editor, Caddy for TLS.
@@ -22,6 +24,7 @@ Stack: SvelteKit and TypeScript, Drizzle on Postgres, a pg-boss worker for backg
 - Authored content stays exportable. Anything holding a user's words is stored as markdown that round-trips through export; do not introduce a format that traps content.
 - Prefer what is already here. Reach for the standard library or an existing dependency before adding a new one, favour stable low-churn packages, and match the patterns and naming already in the file.
 - Keep the in-app help current. When you add or change user-facing functionality, check whether a help article in `src/lib/docs/` covers it and update or add one so the docs stay in step with the features. Admin-only panels do not need help articles.
+- Keep the design docs honest. When a change ships something `scratch/system-design/` describes as future, absent, or an open question, update the relevant doc (`design.md`, `assistant.md`, a status header) in the same branch. A doc that describes shipped work in the future tense misleads every later session that reads it as the spec.
 
 ## Testing
 
diff --git a/TODO.md b/TODO.md
index 6406255..7b242fd 100644
--- a/TODO.md
+++ b/TODO.md
@@ -5,6 +5,31 @@ per line; details live in the roadmap. Cross off as things merge to develop.
 
 ## Open
 
+Visual design pass (2026-07-29, branch `worktree-design-system-sheet`).
+Groundwork for a whole-app cohesion pass with Claude Design: a components
+sheet written from a full audit of `src/lib/styles/` and
+`src/lib/components/` (`scratch/system-design/design-system.md`, now
+referenced from CLAUDE.md as required reading for page work), and four
+session briefs for Claude Design
+(`scratch/system-design/design-pass-prompts.md`): landing page,
+navigation and wayfinding, secondary-surface cohesion, and a primitive
+consolidation sheet. The audit found the drift the briefs target: 20+
+button skins, 9 menu systems, 3 modals, ~400 lines of dead CSS,
+hard-coded colours bypassing tokens, and four pages outside any shell
+(docs, print, guest review, public reader). Also on this branch: a
+reconciliation pass over `design.md` against the shipped app (the AI
+section rewritten for the shipped Assistant, continuous-view editing,
+EPUB/PDF exports, the four sign-up modes, the flat shelf with links and
+commissions, scene-mark preferences, plus a new "Beyond the writing
+surface" section stating what review, insights, goals, notifications,
+print, import, and admin are each for), the stale status header in
+`assistant.md`, and three stale schema comments (`llm_config` twice,
+`cover_asset_id`). Next: build the design kit preview bundle
+(`scratch/design-kit/`, one card per canonical primitive in all three
+themes, DesignSync-ready), run the briefs in Claude Design, port the
+results, then the code-side consolidation refactor the sheet's backlog
+section lists.
+
 Dev environment automation (2026-07-28, branch
 `feat/dev-env-automation`). Setting the project up on a fresh macOS
 machine turned up three things CI never sees, all fixed here.
diff --git a/scratch/system-design/assistant.md b/scratch/system-design/assistant.md
index 9b39add..57141b9 100644
--- a/scratch/system-design/assistant.md
+++ b/scratch/system-design/assistant.md
@@ -1,15 +1,14 @@
 # The Assistant (LLM integration)
 
-Status: Phase 9, in progress. The server-only gateway plumbing is built,
-tested, and merged to `develop` (the `src/lib/server/llm/` module: config,
-egress guard, OpenAI-compatible provider, context assembly, tools, and the
-setup helpers). The first surface is built: the account Assistant settings
-page at `/account/assistant` (PR #325). The remaining surfaces (chat, inline,
-review, the admin egress panel, the per-story mute) and the worker jobs are
-not yet built; the "Frontend wiring map" at the end tracks each one. Parts of
-this document remain deliberately ahead of the code, so treat the numbers and
-prompts as placeholders (marked TODO) until a real prose corpus is available
-to calibrate them against.
+Status: Phase 9, shipped (status reconciled 2026-07-29). The gateway
+(`src/lib/server/llm/`), the account settings page, the chat tab, inline
+co-author and continuation, the reviewer role, the admin egress panel, the
+per-story mute, and the background jobs with their activity cards are all
+merged. The "Frontend wiring map" at the end records where each surface
+landed. The design intent below still holds and the shipped code matches
+its shape; where the text speaks of the work in the future tense, read it
+as the rationale that produced what is now built. Numbers and prompts
+marked TODO remain placeholders to calibrate against a real prose corpus.
 
 The feature is named the Assistant throughout, in the UI and the code. "AI"
 and "LLM" describe the mechanism; the Assistant is the thing the writer
diff --git a/scratch/system-design/design-pass-prompts.md b/scratch/system-design/design-pass-prompts.md
new file mode 100644
index 0000000..641dd17
--- /dev/null
+++ b/scratch/system-design/design-pass-prompts.md
@@ -0,0 +1,230 @@
+# Visual design pass - briefs for Claude Design
+
+Status: drafted 2026-07-29. Prompts to run in Claude Design, one session per
+brief. Each session should produce an updated prototype in the usual handoff
+format (see "Handoff format" below), which then gets ported to Svelte the same
+way the original design was.
+
+The goal of the pass is cohesion and intuitiveness, not novelty. The app's
+look is settled and liked; the work is tightening the seams: one navigation
+model, one shell family, screens that were built later brought back in line
+with the system, and a landing page that earns its place.
+
+Companion document: `design-system.md`, the components sheet written from a
+full audit of the shipped CSS and components. It lists the canonical
+primitives, the legacy skins, and the known drift; briefs 3 and 4 draw
+directly on it.
+
+## How to use this document
+
+1. Start every Claude Design session with the "Shared context" block below,
+   pasted verbatim, plus the current `tokens.css` and `theme.css` from
+   `src/lib/styles/` so the session works from the real system.
+2. Follow with one brief. Do not run two briefs in one session; each brief is
+   scoped to produce one reviewable handoff.
+3. Screenshots of the current screens help more than descriptions. The list
+   of screens worth capturing is at the end of this document.
+
+## Shared context (paste into every session)
+
+Codex is a self-hosted writing workspace for long-form creative work: novels,
+serials, worldbuilding, TTRPG campaigns. It is calm, text-first, and dense in
+the way a good tool is dense: no marketing gloss inside the app, no decoration
+that does not carry information. The UI font is Hanken Grotesk, prose is set
+in a serif (Spectral/Literata), and the palette is built from CSS custom
+properties with three themes (dark, light, warm) selected by a `data-theme`
+attribute. Category colours (ten tints) mark entity kinds; four status
+colours (draft, revised, final, outline) mark scene state. All colour,
+spacing, and radius values come from tokens; nothing is hardcoded.
+
+The app has four page shells:
+
+- Workspace: a three-column layout (structure left, work centre, reference
+  right) with a top bar carrying breadcrumbs (Library > Universe > Story),
+  save status, command palette button, notifications, help, and user menu.
+  Used by Write, Plan, Notes, and Review at story scope, and Plan and Notes
+  at universe scope. A segmented "mode strip" (Write | Plan | Notes | Review)
+  sits at the top of the left sidebar.
+- Page shell: single-column pages (the library) with a simpler top bar that
+  has a one-level back link instead of breadcrumbs.
+- Settings shell: two-column settings pages (account, admin, story settings,
+  universe settings) with a sectioned sidebar nav.
+- Auth shell: the landing chrome (brand, theme toggle, footer) around a
+  centred card, used by sign-in, sign-up, and every email-flow page.
+
+Constraints that hold for every brief:
+
+- Work within the existing tokens. Propose a new token only if a real gap
+  exists, and say so explicitly; never inline a raw colour or size.
+- All three themes must work. Check dark, light, and warm.
+- Plain ASCII punctuation in all UI text: no em dashes, no curly quotes.
+- Help and instruction text addresses someone who has never seen the app;
+  tell them what to do, and leave the reasoning out.
+- The editor in the prototype is a mock; the real editor is CodeMirror 6.
+  Design editor-adjacent chrome freely, but do not design inside-the-editor
+  behaviour beyond what already exists.
+- Keyboard reachability and visible focus are requirements, not polish.
+
+## Brief 1: Landing page
+
+The current landing page is a hero ("Plan the world. / Write the book."),
+four one-word feature markers (Plan, Write, Remember, Yours) with a sentence
+each, two CTAs (Sign in, Request access), and a one-line footer
+(Self-hosted - Invite-only). No imagery, no product shots.
+
+Redesign it to do three jobs the current page does not:
+
+1. Show the product. The three-column workspace is the pitch; a reader
+   should see it, not read about it. Consider a stylised, token-accurate
+   rendering of the workspace (not a raster screenshot) so it stays crisp
+   in all three themes.
+2. Speak to all three audiences: the novelist, the worldbuilder, and the
+   TTRPG designer or DM. They overlap, and the page should show one tool
+   with three postures rather than three feature lists.
+3. Explain the model honestly: self-hosted or hosted, same code, invite
+   gated, your words exportable as markdown, no AI in the writing loop.
+   These are differentiators for the audience this tool wants; state them
+   plainly rather than burying them in the footer.
+
+Keep: the tone (quiet confidence, no superlatives), the serif hero, the
+existing auth shell chrome so sign-in and sign-up still feel like part of
+the same surface. The page must also respect the signup mode: when sign-up
+is closed the Request access CTA disappears, and the page has to still make
+sense with only Sign in.
+
+Out of scope: pricing (there is none), testimonials, screenshots of real
+user content.
+
+## Brief 2: Navigation and wayfinding
+
+The workspace is liked; getting between its parts is where the seams show.
+A code audit found these concrete problems. Solve them as one system, not
+as sixteen patches:
+
+- Two different top bars (workspace breadcrumbs vs single back link), plus
+  two more one-off bars on the print page and the guest review page, and no
+  bar at all on the help pages and public reader pages.
+- The breadcrumb is ambiguous: the story-title crumb links to story
+  settings (while a gear two icons away goes to the same place), and the
+  universe crumb goes to plan when a story is open but to universe settings
+  when it is not.
+- The mode strip silently changes size: four modes at story scope, two at
+  universe scope, four-with-three-disabled for guest reviewers.
+- Universe insights is nearly unreachable: only a link inside the Session
+  tab and a command palette entry.
+- Dead ends: the print page has no way back, the docs pages drop the user
+  out of the app chrome entirely, and the guest review page has no help or
+  theme control.
+- Help exists in two presentations: a modal (from the ? button) and a bare
+  standalone page (from the palette and footer links), for the same
+  articles.
+
+Deliver:
+
+1. One navigation model: define what the top bar shows on every page type,
+   when breadcrumbs appear, what each crumb links to, and where settings
+   entry points live. The rule should be statable in a sentence or two.
+2. A consistent mode strip: decide how it behaves at universe scope and for
+   guests (fewer items, disabled items, or a different control) and apply
+   it everywhere.
+3. A home for insights, docs, and print inside that model.
+4. The guest review chrome as a deliberate reduced shell rather than an
+   accident: what a guest can see and reach, styled as part of the family.
+
+Constraint: do not merge Write and Review; they stay peer modes (settled
+decision, see write-review-unification.md). Sidebar widths are fixed (240
+left, 280 right); resize is out of scope.
+
+## Brief 3: Shell and secondary-surface cohesion
+
+The core workspace held together; the surfaces added later drifted. Bring
+them back into the system:
+
+- The right-pane tab strip differs per mode: up to four tabs on Write,
+  three or four on Plan, two on Review, and a fake non-interactive
+  "History" pill on Notes. Define the tab strip once: which tabs exist in
+  which mode, what happens when a tab does not apply (hide it), and one
+  label for the Assistant tab (it currently varies by page).
+- The settings family (account, admin, story settings, universe settings,
+  insights) shares a shell but insights uses its sidebar for in-page
+  anchors while every sibling uses it for routes. Decide what insights is:
+  a settings section, or a workspace view with the standard right-pane
+  treatment.
+- The public reader pages (`/@handle` shelf and the story reader) hardcode
+  their own serif and colours instead of using tokens, and carry no brand
+  or footer. Design them as the outward face of the product: reader-first,
+  minimal, but recognisably Codex, honouring the reader's theme preference
+  and WCAG AA.
+- The library screen has three different creation affordances (header
+  button, per-universe card, standalone card) plus a text link for import.
+  Rationalise into one pattern with variants.
+
+Deliver a component-level spec for each: the tab strip, the settings
+sidebar, the reader chrome, and the creation affordance, each shown in all
+three themes.
+
+## Brief 4: Primitive consolidation sheet
+
+A code audit (see `design-system.md`) found the system underneath the
+screens has drifted: 20+ button skins where one system (`.btn`) was
+intended, 13+ badge/pill spellings, 9 menu implementations where 2 use the
+shared popover skin, three hand-rolled modals with three different
+backdrops, and a dozen empty-state styles. The screens look cohesive; the
+vocabulary underneath is not, and every new page risks widening the gap.
+
+Produce a single-page components sheet as a designed artifact: every
+canonical primitive rendered in all its variants and states, in all three
+themes, on one reference page. Specifically:
+
+1. Buttons: `.btn` primary/secondary/ghost/danger, default and `.btn-sm`,
+   plus `.icon-btn`, in rest/hover/active/disabled/focus states. Decide
+   whether the review surface's `.rv-btn` variants become `.btn` variants
+   or stay a scoped family, and show the result.
+2. One modal primitive: backdrop, panel, header, footer with `.btn`
+   actions, close affordance, at two sizes. The palette, review modal, and
+   help modal should all be expressible with it.
+3. One segmented strip (`.seg`) covering the mode strip, the review tabs,
+   and the filter pill rows, including disabled and counted (badge) items.
+4. Badge/chip/pill: confirm the three-way split (identity badge,
+   interactive chip, static pill) and render the full set, including the
+   entity badge at its three sizes with image and initial forms.
+5. Empty states: one pattern with icon/no-icon and action/no-action
+   variants.
+6. Form kit: field, label, hint, input, textarea, select (with a
+   token-driven caret), toggle row, error and success status lines, and
+   the focus ring, shown once as the single source.
+7. A type ramp: today's sizes are ad hoc (13.5px, 12.5px, 11.5px); propose
+   a small named scale that covers the existing screens without visibly
+   changing them.
+
+For each primitive, the sheet should state in a line what it is for and
+when not to use it, in the sheet's own voice, since this page doubles as
+the reference given to coding agents. Nothing on this page should require
+new tokens beyond the type ramp; where a current screen contradicts the
+sheet, the sheet wins and the screen is listed as a migration.
+
+## Handoff format
+
+Same as the original handoff: a no-build React prototype (`codex.html`
+mounting `src/*.jsx` with Babel over fake data on `window.CODEX_DATA`),
+with the design system in `tokens.css`, `theme.css`, and `pages.css`.
+Changed or new CSS goes in those files, not inline. Reference screenshots
+accompany the prototype. The prototype is a visual and behaviour spec; the
+Svelte implementation reimplements it rather than transplanting the JSX.
+
+## Screens to capture before starting
+
+1. Landing page, signed out
+2. Library, signed in
+3. Write view with a scene open (the three-column workspace)
+4. Continuous whole-story view
+5. Plan at story scope with the scene board
+6. Plan at universe scope with an entity open (relationships visible)
+7. Review workspace as the author
+8. Command palette open over the editor
+9. Story settings (stands in for the whole settings family)
+10. Universe insights
+11. Public reader page for a published story
+
+Capture each in dark and light at minimum; warm where colour decisions are
+being made.
diff --git a/scratch/system-design/design-system.md b/scratch/system-design/design-system.md
new file mode 100644
index 0000000..de4ac9d
--- /dev/null
+++ b/scratch/system-design/design-system.md
@@ -0,0 +1,324 @@
+# Codex design system - components sheet
+
+Status: written 2026-07-29 from a full audit of `src/lib/styles/` and
+`src/lib/components/`. This is the canonical reference for anyone (person or
+agent) building a new page or changing an existing one. It says which
+primitives are canon, which are legacy, and which patterns must not be
+copied. When the code and this sheet disagree, fix one of them; do not let
+them drift apart silently.
+
+Companion documents: `design.md` (product intent and page semantics),
+`design-pass-prompts.md` (the visual design pass briefs).
+
+## The one-paragraph version
+
+Use tokens for every colour, radius, and font. Wrap every page in one of the
+four shells. Build controls from the canonical primitives below (`.btn`,
+`.icon-btn`, `.field`/`.input`, `.popover`/`.menu-item`, `.seg`, `.badge`,
+`.chip`, `.pill`, `.empty`, `Icon.svelte`). Check all three themes. Do not
+invent a new button skin, menu system, modal, or empty state; the codebase
+already has too many, and the list of offenders is at the end of this sheet.
+
+## Tokens
+
+Source of truth: `src/lib/styles/tokens.css`. Themes are selected by a
+`data-theme` attribute on `<html>` (`dark`, `light`, `warm`), set before
+first paint by an inline script in `src/app.html`. Density
+(`data-density="compact"`) tightens `--row-h` and `--pane-pad`. The accent
+is a user preference applied as an inline `--accent` on `<html>`.
+
+Fonts:
+
+- `--font-ui` (Hanken Grotesk) for all chrome.
+- `--font-serif` (Spectral) for prose and display headings; the editor's
+  content face is `--font-content`, which the user can switch.
+- `--font-mono` (JetBrains Mono) for code and identifiers.
+
+Surfaces, from back to front:
+
+- `--bg` - the page background.
+- `--bg-elevated` - raised chrome: top bars, dropdowns, popovers.
+- `--bg-panel` - the left and right sidebars.
+- `--bg-card` - cards sitting on a surface.
+- `--bg-canvas` - the prose canvas (editor centre column, reading views).
+- `--bg-inset` - wells and recessed areas inside a surface.
+- `--bg-hover` / `--bg-active` - interactive state fills; translucent so
+  they work on any surface.
+
+Text tiers: `--text` (primary), `--text-muted` (secondary), `--text-faint`
+(tertiary and empty states). Borders: `--border` (default), `--border-strong`
+(emphasis, scrollbar thumbs).
+
+Accent family: `--accent` (fills), `--accent-contrast` (text on accent
+fills; use this, never `#fff`), `--accent-soft` (selection, focus glow,
+soft fills), `--accent-line` (focused borders).
+
+Meaning colours:
+
+- Status: `--status-outline`, `--status-draft`, `--status-revised`,
+  `--status-final`. Scene and story state only.
+- Danger: `--danger`, `--danger-soft`. Destructive actions and errors only.
+- Category tints: `--cat-violet`, `--cat-rose`, `--cat-green`, `--cat-blue`,
+  `--cat-amber`, `--cat-red`, `--cat-lime`, `--cat-teal`, `--cat-cyan`,
+  `--cat-fuchsia`. Entity categories and anything the user colour-codes.
+
+Geometry: `--radius-sm` (6px), `--radius`/`--radius-md` (9px), `--radius-lg`
+(14px); spacing scale `--space-1` through `--space-10` (4 to 44px);
+`--row-h` for list rows; `--content-max` for the prose column.
+
+Rules:
+
+- Never write a raw colour value. If a needed colour does not exist as a
+  token, that is a design decision to raise, not a hex to inline.
+- Do not write `var(--token, #fallback)`. The tokens are always defined;
+  fallbacks rot (the codebase currently has three different fallbacks for
+  `--danger`, all wrong in at least one theme).
+- Do not branch on `[data-theme='...']` in CSS. Tokens carry the theme. The
+  single sanctioned exception is softening a box-shadow that reads too heavy
+  on light backgrounds.
+- Derive transparent tints with `color-mix(in oklab, var(--token) N%,
+  transparent)`, the way `--accent-soft` and `--danger-soft` are built.
+
+## Shells
+
+Every page uses exactly one of these four wrappers. Do not build a fifth.
+
+| Shell | Component(s) | Used by |
+|---|---|---|
+| Workspace | `.app` grid + `TopBar.svelte` | Write, Plan, Notes, Review (story scope); Plan, Notes (universe scope) |
+| Page | `.page-shell` + `PageTopBar.svelte` | Library |
+| Settings | `SettingsShell.svelte` + `PageTopBar.svelte` | Account, admin, story settings, universe settings, insights |
+| Auth | `AuthShell.svelte` | Sign-in, sign-up, and every email-flow page |
+
+The workspace shell is a three-column grid: structure left (fixed 240px),
+work centre, reference right (fixed 280px). Sidebar widths are a settled
+decision; resize is deferred. Focus mode (`.app.focus-mode`) hides both
+sidebars with `visibility: hidden` so the prose column does not shift.
+
+`TopBar` carries breadcrumbs (Library > Universe > Story), save status,
+palette button, notification bell, help, and the user menu. `PageTopBar`
+carries a single back link instead of breadcrumbs. The pages that currently
+escape all shells (docs, print, guest review, public reader) are known
+drift; the fix is scoped in `design-pass-prompts.md`, brief 2. Do not model
+a new page on them.
+
+The right sidebar of the workspace shell has up to four tabs with fixed
+semantics (see `design.md`): Reference (what is in view), History (what was
+in view), Session (how you are working), Assistant (who you are working
+with). A tab that does not apply to a mode is hidden, not faked.
+
+## Canonical primitives
+
+The rule for all of them: if the control you need is close to one of these,
+use or extend the primitive; if it is genuinely new, add it to the shared
+CSS with a considered name and add it to this sheet.
+
+### Buttons
+
+- `.btn` with `.btn-primary`, `.btn-secondary`, `.btn-ghost`, `.btn-danger`,
+  size modifier `.btn-sm`. Defined in `pages.css`. This is the only general
+  button system.
+- `.icon-btn` for icon-only buttons (top bars, panel headers). Defined in
+  `theme.css`; also styles `a.icon-btn`.
+- Scoped exceptions that stay: `.md-tool` (editor toolbar), `.seg-btn`
+  (segmented strips), `.rv-btn` family (review surfaces, pending
+  consolidation).
+- Everything else (`.tool-btn`, `.mini-btn`, `.rb-btn`, `.send-btn`,
+  `.card-add`, `.outline-add`, and the rest of the 20+ skins) is legacy.
+  Do not use them in new code and do not create new ones.
+
+### Forms
+
+- Wrapper: `.field` with a `<label>`, optional `.field-hint`, laid out with
+  `.field-grid` when two-up. Action row: `.settings-actions`.
+- Controls: `.input`, `.textarea`, `.select`, `.toggle` inside `.toggle-row`.
+  The focus ring (accent border plus `--accent-soft` glow) comes from the
+  shared rule; never redefine it.
+- Inline result messages: the `FormStatus.svelte` component. The older
+  `.form-error`/`.form-saved` classes remain in some routes; do not spread
+  them further.
+- Do not hand-roll a text field. The codebase has 15+ one-off inputs that
+  each re-declare the border and focus ring; that list is frozen.
+
+### Menus and popovers
+
+- `.popover` panel with `.menu-item` rows (plus `.danger`, `:disabled`,
+  `.is-current`). Defined in `menus.css`, which documents the intent. Used
+  by the row menu and view menu; every new dropdown uses it.
+- The avatar dropdown (`.avatar-dropdown`) is deliberately its own richer
+  skin. That exception does not license others.
+
+### Modals
+
+There is no shared modal primitive yet; three hand-rolled ones exist. Until
+one is extracted, model a new modal on `ReviewModal.svelte`: token-based
+backdrop (`color-mix` over `--bg-canvas`), panel on `--bg-elevated`, footer
+buttons using `.btn`. Do not copy `HelpModal`'s hard-coded black backdrop.
+
+### Badges, chips, pills
+
+Three words, three meanings; keep them straight:
+
+- `.badge` - an entity identity mark (image or initial), sized `dot`, `sm`,
+  `lg`, rendered by `EntityBadge.svelte`.
+- `.chip` - an interactive token: tags, removable filters, add-affordances
+  (`.muted`, `.dashed`, `.link`).
+- `.pill` - a small static status label (`.pill-accent`).
+
+The dozen other spellings (`.role-tag`, `.nav-badge`, `.rv-type-pill`,
+`.tfa-badge`, ...) are scoped legacy; do not add new ones.
+
+### Segmented strips and filters
+
+- `.seg` container with `.seg-btn` items (`.active`, `:disabled`) - the
+  mode strip and any exclusive-choice strip. `ModeSwitcher.svelte` is the
+  reference use.
+- `.rtabs`/`.rtab` in the review workspace is a duplicate of `.seg` and is
+  marked for consolidation. Known bug to not replicate: `.seg-btn.active`
+  has a light-theme shadow soften; `.rtab.active` lacks it.
+- Filter pill rows also exist twice (`.rv-filters` and `.revision-filters`);
+  prefer extending `.seg` semantics rather than adding a third.
+
+### Lists, rows, tables
+
+- Real tabular data: `.admin-table` (with `.cell-*` helpers, `.num`
+  columns, `.row-actions`).
+- Icon-led row lists: `.list-row` with `.list-ic`, `.list-main`,
+  `.list-title`, `.list-sub`, `.list-actions`.
+- Destructive settings rows: `.danger-group`/`.danger-row`.
+- Outline rows (chapters, scenes, entities) share the row CSS in
+  `theme.css` (`.chapter-row`, `.scene-row`, `.ent-row`) at `--row-h`.
+
+### Cards
+
+`.story-card` (library), `.admin-card` (settings/admin sections, also used
+well outside admin), `.r-card` (right-pane reference blocks), `.rv-card`
+(review threads). New reference-pane content should compose `.r-card`;
+new settings content composes `.admin-card`.
+
+### Empty states
+
+`.empty` (centred, `--text-faint`, 13px) is the primitive. The other eleven
+spellings are legacy. An empty state is one short sentence telling the user
+what to do, per the writing rules.
+
+### Icons
+
+`Icon.svelte`: a typed name registry (`IconName`), 24px viewBox, 1.8 stroke,
+`currentColor`. Colour always comes from the parent's CSS `color`; size
+comes from the `size` prop or an ancestor rule (`.btn svg`, `.icon-btn
+svg`). Add new icons to the `PATHS` registry in the same style; do not
+inline ad-hoc SVG in components.
+
+### Status and feedback
+
+- Save state: the top-bar save pill (`Saving...` / `Saved just now` /
+  retry on error).
+- Keyboard hints: the `kbd` element (styled globally in `pages.css`).
+- Tooltips: native `title` attributes plus `aria-label` for icon-only
+  controls. There is no custom tooltip primitive; do not build one ad hoc.
+- Banners: `.revision-banner` for the past-revision state is the reference
+  pattern for a centre-column banner.
+
+## Writing in the UI
+
+From CLAUDE.md, repeated here because every screen touches it:
+
+- Plain ASCII punctuation everywhere: no em dashes, no curly quotes.
+- Help and instruction text tells a first-time user what to do, without
+  explaining why the app is built the way it is.
+- No jargon or slang in user-facing text.
+- User-facing functionality changes come with a check of the help articles
+  in `src/lib/docs/`.
+
+## CSS file map
+
+Load order in `src/routes/+layout.svelte`: `tokens.css`, `theme.css`,
+`pages.css`, `admin.css`, `editor.css`, `review.css`, `menus.css`. All
+global and unscoped, so a later file silently wins a specificity tie; check
+for an existing definition before adding a class.
+
+- `tokens.css` - tokens and base element rules only. No components.
+- `theme.css` - the workspace shell and its components (outline rows,
+  panels, editor chrome, entity UI).
+- `pages.css` - the page/settings shells, buttons, forms, cards, landing.
+- `admin.css` - settings and admin surfaces (used by account pages too).
+- `editor.css` - CodeMirror-specific rules (mention underlines, hover
+  cards, autocomplete popup).
+- `review.css` - review surfaces.
+- `menus.css` - the shared popover/menu skin.
+
+Component `<style>` blocks are for genuinely local layout only. If a rule
+could apply anywhere else, it belongs in the shared files. Never redefine a
+shared class inside a component (this currently happens for `.btn-sm`,
+`.mini-btn`, `.field-hint`, and two entire blocks; see below).
+
+## New page checklist
+
+1. Pick the shell; wire the top bar (breadcrumbs or back link) and the
+   palette/bell/help/user cluster that shell provides.
+2. Compose from the canonical primitives above; extend shared CSS if a
+   variant is genuinely missing.
+3. Tokens only; no raw colours, no `[data-theme]` branches, no token
+   fallbacks.
+4. Check dark, light, and warm, plus compact density if the page has rows.
+5. Keyboard: everything reachable, visible focus, `aria-label` on icon-only
+   controls, Escape closes any overlay.
+6. Empty, loading, and error states use the shared patterns.
+7. UI text follows the writing rules; help articles updated if behaviour
+   changed.
+8. Update this sheet if you added or changed a primitive.
+
+## Known drift - do not copy, consolidation backlog
+
+Found in the 2026-07 audit. Copying any of these into new code makes the
+problem worse; fixing them is scheduled work, not drive-by refactoring.
+
+Dead CSS (defined, zero call sites, ~400 lines): `.icon-button`,
+`.btn-mini`, `.add-mini`, the whole `.ctx-menu` system, `.settings-nav`,
+`.note-card` block, `.storage-bar`/`.usage-bar` blocks, `.goal-bar`,
+`.ac-menu`/`.ac-item`, `.entity-pop`, `.quick-select` block, the `.kbd`
+class.
+
+Duplicated definitions (later file or component style wins): the assistant
+chat block (`theme.css` and `AssistantPanel.svelte`), the `.insp-*`
+inspector (`theme.css` and `EntityCard.svelte`), the kanban CSS
+(`SceneBoard.svelte` and `StoryBoard.svelte` are copy-pasted),
+`.revision-dot`, `.brand-name`, `.mini-btn`, `.rb-btn`, `.btn-sm`,
+`.field-hint`, `.ent-row`, `.chapter-row`/`.scene-row`.
+
+Hard-coded colours that bypass tokens: the `.select` caret SVG stroke, the
+`.swatch-custom` gradient hexes, the `color-mix(... #1b2a55)` navy in three
+places, the QR block's fixed light/dark backgrounds, `.toggle-track`'s
+`#fff` knob, a dozen bare `color: #fff` where `--accent-contrast` exists,
+inline `style="color: #fff"` on both top-bar brand marks, and the
+mismatched `var(--token, #hex)` fallbacks.
+
+Parallel systems pending a decision: `.seg` vs `.rtabs`; `.rv-filters` vs
+`.revision-filters`; `.saved` vs `.save-status`; `FormStatus.svelte` vs
+`.form-error`/`.form-saved`; three modal implementations; twelve empty
+states; six avatar classes.
+
+The visual side of consolidating these is brief 4 in
+`design-pass-prompts.md`; the code side is a follow-up refactor once that
+brief lands.
+
+## Component index
+
+Reusable primitives: `Icon`, `EntityBadge`, `EntityQuickCard`, `TagInput`,
+`ModeSwitcher`, `ThemeToggle`, `PaletteButton`, `SidebarSearch`,
+`HelpLink`, `FormStatus`, `ReviewAvatar`, `ReviewReplyForm`,
+`ReviewReplyRow`, `ReviewMarginRail`, `ReviewSelectionToolbar`.
+
+Shared composites: `TopBar`, `PageTopBar`, `SettingsShell`, `AuthShell`,
+`UserMenu`, `NotificationBell`, `ActivityCenter`, `ViewMenu`,
+`EditorToolbar`, `SelectionMenu`, `NotesSidebar`, `PlanSidebar`,
+`StoryOutline`, `StoryRowMenu`, `RevisionHistory`, `EntityBadgePicker`,
+`EntityRelationships`, `ReviewSurface`, `ReviewPanel`, `ReviewCommentCard`,
+`ReviewSuggestionCard`, `ReviewSceneHead`, `AssistantProposal`.
+
+Single-purpose surfaces: `Landing`, `CommandPalette`, `HelpModal`,
+`SceneEditor`, `StoryPreview`, `NoteEditor`, `RevisionPreview`,
+`SessionPanel`, `ExportPanel`, `AssistantPanel`, `CoauthorPanel`,
+`ReviewWorkspace`, `ReviewEditor`, `ReviewModal`, `EntityEditor`,
+`EntityCard`, `RelationshipWeb`, `SceneBoard`, `StoryBoard`.
diff --git a/scratch/system-design/design.md b/scratch/system-design/design.md
index d79a1c6..d182451 100644
--- a/scratch/system-design/design.md
+++ b/scratch/system-design/design.md
@@ -46,7 +46,7 @@ A year later you start *The northern march*, book two in the same universe. You
 
 ### Just writing
 
-Codex has no AI features in v1. You sit down to write and the tool gives you a focused editor with your worldbuilding within arm's reach. No suggestions appear unbidden. No chat panel sits in the corner waiting. The Session tab in the right sidebar holds your quick preferences — entity-autocomplete style (the local, lookup-based kind), whether entity underlines show, theme, focus mode — and that's all that lives there. LLM assistance is on the roadmap but deliberately deferred: the writing experience has to be good on its own merits first, and the prose corpus that emerges from real use is the best calibration material for whatever assistance eventually arrives. When that day comes, AI will be opt-in per account and per story; a user who keeps it off will continue to see no AI UI anywhere.
+The writing experience stands on its own. You sit down to write and the tool gives you a focused editor with your worldbuilding within arm's reach. Nothing appears unbidden: entity autocomplete is local and lookup-based, and the Assistant (the LLM layer, see "AI: the Assistant" below) is off by default, opt-in per account with a per-story mute. A user who keeps it off sees no AI UI anywhere. The ordering was deliberate: v1 shipped with no AI at all, the editor had to be good on its own merits first, and the prose corpus from real use became the calibration material for the assistance that arrived later.
 
 ### Turning over a universe
 
@@ -90,15 +90,15 @@ The editor exists at two scopes: **story** and **universe**. Both use the same t
 
 This structure — universes as first-class editable surfaces, not just settings containers — is important for worldbuilders and TTRPG designers who may never write a prose "story" but need a full editor for characters, places, and lore. It's also important for novelists adding a character who'll cross multiple books: the natural home for such a character is the universe, not whichever book they happened to appear in first.
 
-Across every view at either scope, the right sidebar has four tabs: **Reference** (panels for what's in view), **History** (the revision timeline for whatever is currently being edited), **Session** (quick settings that govern how you're working in this moment), and **Assistant** (the LLM chat surface). Each tab has a distinct semantic axis: *what's in view*, *what was in view*, *how you're working with it*, and *who you're working with*. The Assistant is deferred LLM work, not in v1 (see `assistant.md` and "AI: deferred" below); the tab is its reserved home, so the chat is a peer of the other three rather than nested inside Session. A command palette (Ctrl+K), which absorbs search and cross-view navigation into one surface, was added later in Phase 7.
+Across every view at either scope, the right sidebar has four tabs: **Reference** (panels for what's in view), **History** (the revision timeline for whatever is currently being edited), **Session** (quick settings that govern how you're working in this moment), and **Assistant** (the LLM chat surface). Each tab has a distinct semantic axis: *what's in view*, *what was in view*, *how you're working with it*, and *who you're working with*. The Assistant tab shows only when the account has the Assistant configured and enabled and the story has not muted it (see `assistant.md` and "AI: the Assistant" below); it is a peer of the other three rather than nested inside Session. A command palette (Ctrl+K), which absorbs search and cross-view navigation into one surface, was added later in Phase 7.
 
 ### The Session tab
 
 The Session tab is where the preferences that actually change mid-session live — the ones too fussy to justify walking through full settings for, but too important not to be reachable in one click.
 
-Four quick-settings controls sit at the top: **entity autocomplete** (off / inline ghost-text / popup menu), **underline known entities** (toggle), **theme** (auto / light / dark), and **focus mode** (toggle). Each has a canonical home in full settings; Session just surfaces the commonly-flipped ones. Changes apply forward, not retroactively — switching autocomplete style mid-sentence affects the next suggestion, not the one currently on screen.
+Four quick-settings controls sit at the top: **entity autocomplete** (off / inline ghost-text / popup menu), **underline known entities** (toggle), **theme** (auto / light / dark), and **focus mode** (toggle). Each has a canonical home in full settings; Session just surfaces the commonly-flipped ones. Changes apply forward, not retroactively — switching autocomplete style mid-sentence affects the next suggestion, not the one currently on screen. Below the quick settings sit the day's word count, the daily goal bar, and the streak card (see Goals under "Beyond the writing surface"; the streak is hideable for anyone who does not want scorekeeping).
 
-The Session tab is for the working preferences above, not the Assistant. When the deferred LLM work is taken on, its chat surface (rubber duck, world Q&A) lives in its own **Assistant** tab in the right sidebar, a peer of Reference, History, and Session, not nested here, with the co-author, continuation, and review roles on the editor and review surfaces (see `assistant.md`). The per-story "Assistant for this story" on/off lives with that tab.
+The Session tab is for the working preferences above, not the Assistant. The chat surface (rubber duck, world Q&A) lives in its own **Assistant** tab in the right sidebar, a peer of Reference, History, and Session, with the co-author, continuation, and reviewer roles on the editor and review surfaces (see `assistant.md`). The per-story mute lives with that tab.
 
 ### Entity mentions
 
@@ -138,21 +138,33 @@ A button in the top bar hides both sidebars using `visibility: hidden` rather th
 
 ### Continuous view
 
-The Write view can also show the whole story as one continuous document: scenes flow together in story order, chapter titles act as section headings, and the sidebar becomes navigation, scrolling to whatever it names. The point is reading a draft the way a reader will meet it; editing stays in the scene-at-a-time view, one click away from any scene, and toggling back returns to the scene that was open. Whether scene marks render inside the flow is a display preference: some authors treat scenes as atomic splits that should not interrupt the reading flow. The rendering is driven by `global_position`, so reordering scenes reorders the reading flow. Editing inside the continuous view (stitched per-scene editors, each autosaving separately) is scheduled as roadmap step 23b.
+The Write view can also show the whole story as one continuous document: scenes flow together in story order, chapter titles act as section headings, and the sidebar becomes navigation, scrolling to whatever it names. The point is reading and revising a draft the way a reader will meet it. The flow is editable in place (shipped as step 23b): each scene is its own stitched editor autosaving separately, one formatting bar acts on whichever editor is focused, and the caret crosses scene boundaries with the arrow keys. Whether scene marks render inside the flow is a preference, set at the account level with a per-story override and defaulting to shown; some authors treat scenes as atomic splits that should not interrupt the reading flow. The rendering is driven by `global_position`, so reordering scenes reorders the reading flow.
 
 ### Images
 
-Codex is a markdown editor, so an image is just a markdown image. What Codex adds is storage: an image dropped or pasted into the editor is uploaded and kept as an asset, and the markdown points at a path Codex serves rather than at someone else's server. This keeps a universe self-contained, lets images show up in exports, and stops links from rotting. Pasting an external image URL still works when that is what you want; it simply is not stored. Each story can also carry a cover image, and a book without one is shown with a default cover built from its title and author so a shelf never looks broken. Image files live on disk for self-host and in object storage for the hosted service; only their metadata is in the database. See `schema.md` for the `assets` table.
+Codex is a markdown editor, so an image is just a markdown image. What Codex adds is storage: an image dropped or pasted into the editor is uploaded and kept as an asset, and the markdown points at a path Codex serves rather than at someone else's server. This keeps a universe self-contained, lets images show up in exports, and stops links from rotting. Pasting an external image URL still works when that is what you want; it simply is not stored. Each story can also carry a cover image; on the public shelf a book without one gets a generated default cover built from its title, so the shelf never looks broken. Image files live on disk for self-host and in object storage for the hosted service; only their metadata is in the database. See `schema.md` for the `assets` table.
 
 ### TODO markers
 
 While drafting you can mark a spot to come back to. Selecting text and flagging it, or typing a line that begins `TODO:`, records a marker that shows as a highlight in the prose and as an entry in a per-story TODO list you can scan at a glance. A marker can carry a short note and be checked off when done. Because the plain-text form is just text, markers survive a markdown export; the structured form (see `schema.md`, `scene_markers`) adds the checkable list and the highlight.
 
+## Beyond the writing surface
+
+Later phases grew surfaces the narrative above predates. What each one is for, and what good looks like for it:
+
+- **Review.** Async feedback on a manuscript without write access: an invited guest (or the Assistant) leaves threaded comments and suggested edits on a dedicated review view, and the author accepts, rejects, or resolves them in their own time. Good means a reviewer needs no account and no manual, and nothing a reviewer does can change the prose without the author's say-so.
+- **Insights.** One page per universe answering "how is it going": progress against each story's target and deadline, activity over time, coverage of the world, and the relationship web. Good means the numbers prompt the next writing session rather than gamify it.
+- **Goals.** A per-story target word count and deadline, an account-level daily word goal, and an optional streak, surfaced in the Session tab and on Insights. Deliberately hideable; not everyone wants scorekeeping.
+- **Notifications.** An in-app bell plus an email digest, with a per-kind channel matrix in account settings. The Assistant's long-running jobs surface separately as activity cards, so progress and news do not mix.
+- **Print and page setup.** Page geometry and paragraph style set once at the account level, overridable per story, and honoured the same way by the print view, the PDF, and the EPUB. Good means what the writer proofs is what a reader downloads.
+- **Import.** A document import, plus re-import of Codex's own story export, so an existing manuscript moves in without retyping. Entity matching stays conservative: no match creates a minimal entity, ambiguity is flagged rather than guessed.
+- **Admin.** The operator console: accounts and the sign-up mode, the Assistant egress policy, usage and cost, published-edition takedown, backups, and an audit log. Sized for one operator and their friends, not a fleet.
+
 ## Accounts and access
 
 Codex assumes accounts. The same surfaces serve self-host users and hosted-instance users; only the operator differs.
 
-**Sign-up.** A public sign-up page captures email, password, and display name. The account is created but unapproved: a row with `approved_at = null`. Until the operator approves, sign-in is blocked with a "your account is pending review" message. Email verification runs in parallel: a confirmation link is sent on sign-up, clicking it sets `email_verified_at`. Both gates have to pass before sign-in succeeds. The current `users.role` and `users.approved_at` columns already model this; the work is the UI, not the schema.
+**Sign-up.** An instance-wide setting controls who can create an account: closed, invite only, require approval (the default), or open. A public sign-up page captures email, password, and display name. Under the approval mode the account is created but unapproved: a row with `approved_at = null`, and sign-in is blocked with a "your account is pending review" message until the operator approves; an invited or open sign-up starts approved. Email verification runs in parallel: a confirmation link is sent on sign-up, clicking it sets `email_verified_at`. Both gates have to pass before sign-in succeeds. When sign-up is closed, the landing and login pages hide the request-access link.
 
 **Approval.** A small admin page lists pending accounts with name, email, sign-up time, and approve/reject buttons. For an operator running an instance for friends, "I get a notification when someone signs up, I look at the email, I click approve" is the whole workflow. Self-rejection on the admin's part also exists for clearing out spam attempts. Invite codes are an alternative, added later (Phase 6, migration 0026): an `invite_codes` table short-circuits the approval gate when a valid code is presented on sign-up.
 
@@ -170,7 +182,7 @@ Codex assumes private writing, but a writer can choose to share finished work as
 
 **Publishing is gated.** A user cannot publish to the public web until an admin enables a public archive for their account. This gives the operator a chance to look over what someone intends to share before it is reachable at a public URL, which is the main lever for keeping material that should not be there (someone uploading a novel that is not theirs, for instance) off the instance. The gate applies to every public page, independent of adult content. The operator also keeps a takedown: an admin can remove a published edition, which hides it without destroying the author's own copy.
 
-**The shelf.** An author can claim a handle and turn on a public profile at `/@handle`. The profile is a simple shelf: an optional short bio, then the universes that contain at least one shared story, and under each the stories the author has chosen to make public. A reader picks a story and reads it: chapters in order, scenes flowed together, set in the same Literata prose face as the editor, with none of the sidebars or worldbuilding around it.
+**The shelf.** An author can claim a handle and turn on a public profile at `/@handle`. The profile is a simple shelf: an optional short bio, the author's links (http links only, marked nofollow), an optional open-for-commissions line, then the published books as a flat list, newest first, each with its cover. (An earlier sketch grouped the shelf by universe; the flat list is what shipped and reads better for a small shelf.) A reader picks a story and reads it: chapters in order, scenes flowed together in the prose face, with none of the sidebars or worldbuilding around it, and with EPUB and PDF downloads when the edition carries them.
 
 **Publishing is a snapshot, not a live view.** Making a story public does not expose whatever is currently on the editing screen. Publishing freezes the present text into a read-only edition; the author re-publishes to push a new edition, which is how a serial author releases the next chapter. Readers only ever see what was deliberately released, in-progress drafts never leak, and the reading path reads only from the frozen editions rather than the live editing tables. A frozen edition is small (markdown plus a little metadata), so it is cheap to cache and serve.
 
@@ -186,25 +198,21 @@ A few smaller rules round this out. Handles come from a reserved list so applica
 
 The instance serves these `/@handle` pages directly for its own users, the same way whether self-hosted or hosted. They render only the frozen, published editions, never a draft, and handles are unique within the instance. (A central cross-instance handle registry would only matter if there were ever many separate instances sharing one public namespace, which the single-instance model does not need; see `roadmap.md`.)
 
-## AI: deferred
-
-Codex has no AI features in v1. The decision to defer is deliberate, not incidental. The editor and the planning surface have to be good on their own merits first; the prose corpus that emerges from real use is the best calibration material for whatever assistance eventually arrives; and the temptation to build the LLM gateway early is exactly the kind of interesting tangent that wrecks solo projects.
-
-The full design for this work (named the Assistant) lives in `assistant.md`: the bring-your-own-key configuration, the admin egress policy, the gateway module, the chat/inline/review surfaces, and how it reuses the existing review framework. The sketch below is the shape; `assistant.md` is the spec.
+## AI: the Assistant
 
-The planned shape, in brief (full detail in `assistant.md`): an opt-in Assistant, off by default and dark until the writer configures an endpoint and turns it on, offering a small set of roles across three surfaces. A rubber-duck chat and grounded world Q&A live in their own **Assistant** tab (a peer of Reference, History, and Session); inline **co-author** and **continuation** live in the editor; and an **editor/reviewer** role leaves comments and suggested edits through the existing review framework. Everything the Assistant writes is a suggestion the author accepts or rejects, never a silent change.
+Codex shipped v1 with no AI features, deliberately: the editor and the planning surface had to be good on their own merits first, and the prose corpus that emerged from real use became the calibration material for the assistance that followed. That assistance, the Assistant, has since shipped as Phase 9. `assistant.md` is the full design; this is the shape:
 
-**BYO key.** Codex will not ship bundled AI when this lands. Users configure their own OpenAI-compatible endpoint — Ollama on a local machine, a hosted API provider, a self-hosted vLLM — with the endpoint and key stored encrypted in their account settings and per-story overrides for model selection. (A Claude Pro or Max subscription is not an API credential; that and the egress and kill-switch details are in `assistant.md`.)
+An opt-in Assistant, off by default and dark until the writer configures an endpoint and turns it on. Enablement is per account (a master toggle; while it is off Codex never contacts a model) with a per-story mute layered on top: a story can silence the Assistant but never enable what the account has not. The roles span three surfaces. A rubber-duck chat and grounded world Q&A live in the right sidebar's **Assistant** tab, with slash commands for drafting and copyedit passes; inline **co-author** and **continuation** (ghost-text at the cursor, Tab to accept) live in the editor; and a **reviewer** role leaves threaded comments and suggested edits through the same review framework a human guest uses. Around the roles sit smaller graces: scene-split proposals, recaps, scene summaries, and entity enrichment. Everything the Assistant writes is a suggestion the author accepts or rejects, never a silent change, and its long-running jobs surface as activity cards in the corner, distinct from notifications.
 
-**The schema already reserves space** for the configuration (`users.llm_config`, `stories.llm_config`) and for lore activation behaviour (`lore_entries.activation_mode`). Those columns exist now so the eventual feature doesn't require migrating live data; in v1 they're inert. See `schema.md`.
+**BYO key.** Codex ships no bundled AI. Users configure their own endpoint - a preset provider or any OpenAI-compatible URL - with the key encrypted at rest, never re-shown by the UI, and per-role model selection with cost display. The operator's lever is the egress policy: block private networks (the default), an allowlist, or open, enforced server-side with a DNS-validating guard. There is no separate instance-wide Assistant switch; an allowlist with no reachable hosts is the shut-off.
 
-Two things to keep separate even in writing about the deferred feature: **entity autocomplete** (the ghost-text that completes known names) is local and lookup-based, has nothing to do with an LLM, and is in v1. **Continuation** is the LLM role that produces inline ghost-text and does not yet exist. The two share a UX pattern, not a backend.
+Two things to keep separate: **entity autocomplete** (the ghost-text that completes known names) is local and lookup-based, has nothing to do with an LLM, and works with the Assistant fully off. **Continuation** is the LLM role. The two now coexist in the editor and share a UX pattern, not a backend.
 
 ## What Codex is not
 
-- **Not a chat tool.** When AI eventually arrives, the rubber-duck role will be a writing aid, not a general-purpose chat. Users wanting a chat interface have better options.
+- **Not a chat tool.** The Assistant's rubber-duck role is a writing aid, not a general-purpose chat. Users wanting a chat interface have better options.
 - **Not a role-play tool.** Character dialogue belongs in the prose; no UI or schema supports character impersonation.
-- **Not a book-distribution platform.** Codex can publish reading pages to the web (see Public reading pages) and export a markdown archive, but it does not push your book into stores or produce publisher-ready files. Export to formats like DOCX with manuscript standards or a properly formatted EPUB is a someday-maybe; the primary export path is the markdown archive.
+- **Not a book-distribution platform.** Codex can publish reading pages to the web (see Public reading pages), and a story exports as a markdown archive or an EPUB, with published editions also carrying a page-setup-faithful PDF. It does not push your book into stores; DOCX with manuscript standards remains a someday-maybe, and the markdown archive stays the canonical full-fidelity export.
 - **Not a real-time collaboration tool.** Single-author-per-session is assumed. Review is async, not live: the guest-review role lets an invited reviewer leave threaded comments and suggested edits that the author resolves in their own time. There is no simultaneous multi-author editing.
 - **Not a feature-gated SaaS.** The hosted instance runs the same code anyone can install themselves, under the same MIT licence. There is no paid edition with extra features; if a difference between self-host and hosted ever appears, it will be operational (someone else runs the box) rather than functional (you get more features by paying).
 - **Not a mobile editing app.** Phones are too small to draft on meaningfully. Tablets in desktop mode work for review but aren't prioritised for authoring in v1.
@@ -235,10 +243,10 @@ Portability is achieved through export, not through storage format. The database
 
 ## Open questions
 
-- **Editing in the continuous view.** Resolved: the read-only continuous view shipped with the core writing loop, and author feedback confirmed editing in place is needed, scheduled as roadmap step 23b. What remains open is the default for scene marks inside the flow (shown or hidden) until the preferences UI exists to make it a choice.
+- **Editing in the continuous view.** Resolved: shipped as stitched per-scene editors (step 23b). Scene marks inside the flow are now a preference, account-level with a per-story override, defaulting to shown.
 - **Plotlines or arcs as first-class entities.** Currently modelled through scene tags and metadata `jsonb`. May be promoted to their own table if usage shows it's needed.
 - **Command palette (Ctrl+K).** Resolved: shipped in Phase 7, absorbing search and cross-view navigation into one surface.
-- **Assistant tab refinements (deferred with AI).** When the Assistant chat tab exists, it will need persistence, resumption, and browsing of past conversations. None of this matters until the chat exists. See `assistant.md`.
+- **Assistant tab refinements.** The chat tab is shipped and keeps its history; how far resumption and browsing of past conversations should go remains open. See `assistant.md`.
 - **Entity colours with meaning.** Resolved: shipped in v1.2. Characters and places can join a universe-defined category that carries a colour (nullable `category_id`), grouping the cast by whatever meaning the author gives it (factions, families, POV tiers). Per-entity badge colours and images followed later (issue #305).
 - **How much markdown the editor should show.** Resolved: an `editingMode` preference (markdown or rich) shipped in Phase 7, where rich is CodeMirror live-preview (syntax marks hide except on the line being edited). The default flipped to rich in v2.25.0. The formatting toolbar and the shared renderer (exports, reading pages) shipped alongside.
 - **Preference layering.** Resolved: shipped in Phase 7 (migration 0032). `stories.preferences` jsonb holds per-story overrides merged over the user's `users.preferences` at load time, for the editor-behaviour keys; "use my account setting" clears the override.
diff --git a/src/lib/server/db/schema.ts b/src/lib/server/db/schema.ts
index 685d7e5..947af8d 100644
--- a/src/lib/server/db/schema.ts
+++ b/src/lib/server/db/schema.ts
@@ -58,7 +58,8 @@ export const users = pgTable('users', {
 	publicArchiveEnabled: boolean('public_archive_enabled').notNull().default(false),
 	passwordHash: text('password_hash').notNull(),
 	role: text('role', { enum: ['admin', 'user'] }).notNull(),
-	// Reserved for future LLM integration; inert in v1.
+	// The Assistant's BYO endpoint, key (encrypted at rest), and per-role
+	// models; see $lib/server/llm/config.ts.
 	llmConfig: jsonb('llm_config').notNull().default({}),
 	// Theme, content width, autocomplete mode, entity underline toggle, etc.
 	preferences: jsonb('preferences').notNull().default({}),
@@ -178,10 +179,11 @@ export const stories = pgTable(
 			.default('private'),
 		// Author-flagged adult content; readers avoid it by default.
 		isAdult: boolean('is_adult').notNull().default(false),
-		// References assets(id) once that table exists (phase 4); null renders a
-		// default cover from title and author.
+		// References assets(id); null renders a generated default cover on the
+		// public shelf.
 		coverAssetId: uuid('cover_asset_id'),
-		// Reserved for future LLM integration; inert in v1.
+		// Per-story Assistant overrides (the mute, model choices); merged over
+		// users.llm_config in $lib/server/llm/config.ts.
 		llmConfig: jsonb('llm_config').notNull().default({}),
 		// Per-story overrides of the owner's editor preferences; keys absent
 		// here fall back to users.preferences at load time.