diff --git a/docs/plans/2026-07-07-001-fix-remove-page-break-guide-lines-plan.md b/docs/plans/2026-07-07-001-fix-remove-page-break-guide-lines-plan.md
deleted file mode 100644
index 1689cc8..0000000
--- a/docs/plans/2026-07-07-001-fix-remove-page-break-guide-lines-plan.md
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: 'fix: Remove page-break guide lines that cross through text'
-type: fix
-date: 2026-07-07
-depth: lightweight
-status: ready
----
-
-# fix: Remove page-break guide lines that cross through text
-
-## Summary
-
-Quill's editor paints a horizontal guide line every 912px down the page via a CSS `repeating-linear-gradient` on `.ProseMirror`. Because it's a background image behind the text (not between blocks), the line draws **through** any text that happens to sit at the 912px boundary, which looks broken. This plan removes the guide-line rendering entirely. The change is CSS-only in `src/App.css`; there is no ProseMirror node, extension, or Rust code backing the feature.
-
-## Problem Frame
-
-The "page break" attempt was implemented as a decorative background gradient rather than as real pagination (which a continuous ProseMirror editor can't do without a layout engine). The gradient has no awareness of text position, so at each 912px interval it strikes a line across whatever line of text is there. Users read it as a horizontal rule slashing through their words. The feature adds no real value — Quill is a continuous-scroll editor, not a paginated one — so the fix is removal, not repair.
-
-## Requirements
-
-- **R1.** The editor must never render a horizontal line across or between document text on screen. (Removes the visual defect.)
-- **R2.** Editor layout (page card, top/inter-page spacing, min-height feel) must not visibly regress for a normal single- or multi-screen document.
-- **R3.** The Export-to-PDF / print path must continue to produce a clean copy — no page-break artifacts, no new regressions. (The print block already sets `background-image: none !important`; removal must keep that path correct.)
-- **R4.** No dead CSS or misleadingly-named variables left referencing the removed feature.
-
-## Key Technical Decisions
-
-- **Remove the gradient, keep the page surface.** The `.editor-page` card, its border, and the `--page-max-width` / padding system are the document's visual frame and are unrelated to the guide lines — they stay. Only the `repeating-linear-gradient` background and the now-pointless `min-height: 912px` tied to the "one page" metaphor are in question.
-- **`min-height: 912px` — reduce, don't necessarily zero.** The 912px min-height gave an empty document a full-page feel. Dropping it entirely would make a blank editor collapse to a few lines. Keep a sensible min-height (retain 912px or a comparable value) purely as a layout minimum, decoupled from any page-break meaning, and update the comment so it no longer claims to mark page boundaries.
-- **`--page-break-gap` variable — rename or repurpose, don't blindly delete.** It's consumed by `.editor-scroll-area` `padding` and `gap` (lines 626/629) as ordinary spacing. Deleting the variable would break that spacing. Rename it to a neutral spacing name (e.g. `--editor-scroll-gap`) so nothing references a removed feature, OR leave the value and just update naming/comments. Behavior must be unchanged.
-- **Leave `.pending-comment`'s dashed border alone.** The dashed `border-bottom` at ~line 858 belongs to the comment-composer highlight, not page breaks. Out of scope — do not touch.
-
-## Implementation Units
-
-### U1. Remove the page-break gradient from `.ProseMirror`
-
-**Goal:** Delete the `repeating-linear-gradient` background so no horizontal line is ever painted through text (R1).
-
-**Files:** `src/App.css`
-
-**Approach:** In the `.ProseMirror` rule (~lines 647–665), remove the `background-image: repeating-linear-gradient(...)` declaration and its `/* Page break lines: dashed rule every 912px */` comment. Re-evaluate `min-height: 912px`: keep it as a plain layout minimum (updating the adjacent comment so it no longer describes "one page per 912px"), since removing it would collapse an empty editor. Do not alter font, color, or line-height declarations in the same rule.
-
-**Patterns to follow:** Match the surrounding CSS comment style in `src/App.css`.
-
-**Test scenarios:** Test expectation: none — pure presentational CSS with no behavioral surface. Verification is visual (see U3) and via the existing `format:check`/lint gates. The round-trip and component test suites already cover editor behavior and must stay green.
-
-**Verification:** Grep confirms no `repeating-linear-gradient` (or any page-break gradient) remains on `.ProseMirror`. In the running app, a document long enough to cross 912px shows no line through or between text.
-
----
-
-### U2. Retire the `--page-break-gap` naming and stale print comment
-
-**Goal:** Remove the last references to the deleted feature so no misleadingly-named token or comment survives (R4), with zero behavior change (R2).
-
-**Files:** `src/App.css`
-
-**Approach:** Rename `--page-break-gap` (declared ~line 169) to a neutral spacing name such as `--editor-scroll-gap`, updating both consumers in `.editor-scroll-area` (`padding` ~line 626, `gap` ~line 629) to the new name with the **same value** (40px). Update the print-media comment (~line 1895) that says "Drop … the dashed page-break guide lines" to reflect that there are no longer guide lines to drop (the `background-image: none !important` on `.ProseMirror` in the print block may stay as a harmless safety net, or be removed if it's now redundant — keep it if in doubt).
-
-**Dependencies:** Independent of U1, but land together (same file, same theme).
-
-**Test scenarios:** Test expectation: none — rename + comment edit with no behavioral change. Verification is that computed spacing is identical (same 40px) and no other rule references the old variable name.
-
-**Verification:** `grep -rn "page-break-gap\|page-break\|page break" src/` returns no CSS matches (comments included). Editor top/inter-page spacing is visually unchanged from before.
-
----
-
-### U3. Visual verification in the running app
-
-**Goal:** Confirm on screen that text is never crossed and layout is intact (R1, R2), and that Export-to-PDF is still clean (R3).
-
-**Files:** none (verification only)
-
-**Approach:** Run the app (`npm run tauri dev`, or `npm run dev` for a browser-only visual check), open/create a document long enough to span past 912px, and confirm: no horizontal line through or between text; the page card, spacing, and empty-doc min-height look right; toggling suggesting mode and comments still renders normally. Trigger Export to PDF (Cmd/Ctrl+P) and confirm the output has no page-break artifacts.
-
-**Test scenarios:** Manual visual check per the above — this is the acceptance gate for a presentational change (`/verify`-style end-to-end observation, not a unit test).
-
-**Verification:** Screenshot or direct observation shows clean text with the guide lines gone and no layout/PDF regression.
-
----
-
-## Scope Boundaries
-
-**In scope:** Removing the CSS guide-line gradient and cleaning up its naming/comments in `src/App.css`.
-
-**Out of scope / non-goals:**
-
-- The `.pending-comment` dashed border (~line 858) — belongs to the comment composer, unrelated.
-- The `.editor-page` card, border, radius, and `--page-max-width`/padding system — that's the document frame, staying.
-- Real pagination / page-numbering — Quill is a continuous-scroll editor; not attempting it.
-
-## Verification Strategy
-
-CI gates (`typecheck`, `eslint`, `prettier --check`, `vitest`, and the Rust suite) must stay green — none should be affected by a CSS-only change, but running them confirms nothing regressed. The decisive check is visual (U3): the guide lines are gone, text is uncrossed, and the PDF export is clean.
-
-## Compounding Note
-
-After the fix lands, capture a short learning (via `ce-compound` / `docs/solutions/`) recording **why the page-break attempt failed**: a `repeating-linear-gradient` background on a continuous ProseMirror editor paints lines by pixel offset with no awareness of text position, so any "page break every N px" approach will strike through text at the boundary. The general lesson — _don't fake pagination with a fixed-interval background on a reflowing text surface_ — is the reusable takeaway.
diff --git a/docs/plans/2026-07-08-001-fix-claude-cli-resolution-path-plan.md b/docs/plans/2026-07-08-001-fix-claude-cli-resolution-path-plan.md
deleted file mode 100644
index a887853..0000000
--- a/docs/plans/2026-07-08-001-fix-claude-cli-resolution-path-plan.md
+++ /dev/null
@@ -1,243 +0,0 @@
----
-title: 'Fix claude CLI resolution & child PATH (specs 01–03)'
-date: 2026-07-08
-status: ready
-branch: fix/claude-cli-resolution-path
-area: Rust backend (src-tauri/src/lib.rs)
-origin: docs/to-improve/01-claude-spawn-path.md, docs/to-improve/02-claude-resolve-configured-binary.md, docs/to-improve/03-claude-interactive-login-shell.md
----
-
-# Fix claude CLI resolution & child PATH (specs 01–03)
-
-## Problem
-
-When Quill runs as a packaged macOS `.app` launched from Finder, launchd hands the
-process a **minimal PATH** (`/usr/bin:/bin:/usr/sbin:/sbin`) that lacks Node and
-the user's toolchain dirs. Three related defects follow, all in
-`src-tauri/src/lib.rs`:
-
-1. **(Spec 01)** `spawn_claude_resume` spawns the resolved `claude` binary but
-   never sets the child's `PATH`. `claude` is a Node script (`#!/usr/bin/env
-node`); with a minimal PATH it dies with `env: node: No such file or
-directory`. Reproduces only in a packaged `.app` from Finder, never from
-   `tauri dev` in a terminal — but a real bug for every installed user.
-
-2. **(Spec 02)** `resolve_claude_binary` runs its hardcoded install-dir scan
-   **before** it asks the login shell. The scan can pick a stale global install
-   (e.g. an old `claude` under an old Node version) that emits a deprecated
-   request shape and gets a `400 "thinking.type.enabled" is not supported for
-this model` from the API. The user's _configured_ CLI should win.
-
-3. **(Spec 03)** The one shell site uses a **non-interactive** login shell
-   (`-lc`). Toolchain PATH lines (nvm/fnm/Homebrew/Volta) very commonly live in
-   `.zshrc` / `.bashrc`, which a login-but-non-interactive shell does **not**
-   source — so `-lc` misses them. `env -i HOME=$HOME /bin/zsh -lc 'command -v
-claude'` returns empty where `-ilc` returns the real path.
-
-## Scope
-
-**In scope:** `src-tauri/src/lib.rs` only — the `resolve_claude_binary` resolution
-order, a new pure PATH-builder, its wiring into `spawn_claude_resume`, and the
-shell invocation flag. Unit tests for the pure builder.
-
-**Out of scope / do NOT do:**
-
-- Do **not** duplicate `.env_remove("ANTHROPIC_API_KEY")` — already present at the
-  spawn site (`src-tauri/src/lib.rs:1260`).
-- Do **not** delete or modify the user's stale `claude` install — spec 02 only
-  changes _preference order_, never the filesystem.
-- Do **not** paste code from the specs verbatim — they are behavior descriptions;
-  match this file's existing conventions (it already has pure, unit-tested
-  helpers like `classify_claude_outcome`).
-- Automated verification of the real `.app`-from-Finder behavior is **manual and
-  out of scope** for tests — the packaged-launchd environment can't be
-  reconstructed in `cargo test`.
-
-## Current ground truth (verified in `src-tauri/src/lib.rs`)
-
-- `resolve_claude_binary()` at `:1097` resolves in order: (1) `which claude`
-  (`:1099`, only trusts a result that `is_file()`); (2) hardcoded install-dir
-  scan (`:1111`, incl. `~/.nvm/versions/node/*/bin/claude` sorted newest-first);
-  (3) login shell `$SHELL -lc 'command -v claude'` (`:1140`), last non-empty
-  stdout line, guarded by `is_file()`. Doc comment describing the order is at
-  `:1090–1096`; the comment defending `-lc` is at `:1136–1138`.
-- `spawn_claude_resume()` at `:1223` builds `Command::new(&claude_bin)` with
-  `--resume`/`--session-id`, `--print`, `--output-format stream-json`,
-  `--include-partial-messages`, `--verbose`, optional `--add-dir`; already calls
-  `.env_remove("ANTHROPIC_API_KEY")` at `:1260`; **does not** set `.env("PATH",
-…)`.
-- Existing test `resolve_claude_binary_returns_path_or_actionable_error` at
-  `:513` (in the `#[cfg(test)] mod tests` block). Pure helpers like
-  `classify_claude_outcome` are unit-tested there — mirror that convention.
-
-## Approach
-
-Three units, sequenced so the shared shell helper exists before its callers use
-it. All shell reads move to an **interactive** login shell (`-ilc`) with a
-sentinel-prefixed protocol so banners/rc noise can't be mistaken for the payload.
-
-### U2 — Reorder resolution: shell wins over dir scan
-
-**File:** `src-tauri/src/lib.rs` (`resolve_claude_binary`, `:1097–1169`).
-
-Swap the order so the user's configured CLI is preferred over a hardcoded scan:
-
-1. `which claude` (unchanged — only trust an existing file).
-2. **Login shell** `command -v claude` (moved up from step 3).
-3. **Hardcoded install-dir scan** (moved down to last).
-
-Rationale: the dir scan is a _fallback_, not an authority. The shell reflects what
-the user actually configured (nvm default, Homebrew, a `local/claude`); letting
-the scan preempt it is what selects the stale binary in spec 02. The scan must
-never preempt the shell's choice.
-
-Update the doc comment at `:1090–1096` so the described order matches (try order:
-existing PATH → login shell → common install locations).
-
-### U3 — Interactive login shell + sentinel protocol (shared helper)
-
-**File:** `src-tauri/src/lib.rs`.
-
-The shell is read for two distinct purposes now (resolve the binary; read the
-login PATH for U1), so extract a small **shell-read helper** rather than
-duplicating the invocation. Directional sketch (not implementation spec):
-
-- A helper that runs `$SHELL -ilc <script>` (SHELL from env, fallback `/bin/sh`)
-  and returns captured stdout on success. `-ilc`, **not** `-lc`: interactive so
-  `.zshrc`/`.bashrc` toolchain lines are sourced; login so profile files are too;
-  `-c` to run the one script we pass.
-- **Binary resolution** runs `command -v claude` and takes the **last non-empty
-  stdout line** (banner-proof — an interactive shell may print rc/profile
-  chatter before the answer), then guards with `is_file()` exactly as today.
-- **PATH read** (new, feeds U1) runs `printf '<SENTINEL>%s\n' "$PATH"` and returns
-  the text **after the sentinel on the sentinel-bearing line**. A unique sentinel
-  (e.g. `___QUILL_PATH___`) survives interleaved rc output where "last line"
-  alone would not, since a trailing banner could otherwise clobber a plain PATH
-  echo.
-
-Update the comment at `:1136–1138` that currently defends `-lc` to explain why an
-**interactive** login shell is required (toolchain PATH lines commonly live in
-interactive-only rc files).
-
-Keep both reads resilient: a shell that errors, prints nothing, or omits the
-sentinel yields `None`/empty and the caller falls through to its next source —
-never a panic, never a bogus path handed to `Command::new`.
-
-### U1 — Pure child-PATH builder + wire into spawn
-
-**File:** `src-tauri/src/lib.rs`.
-
-Add a **pure** function so it is unit-testable without touching the process
-environment:
-
-```
-fn build_child_path(
-    claude_bin: &Path,          // the resolved claude binary
-    login_shell_path: Option<&str>, // U3 sentinel PATH read, may be None
-    inherited_path: Option<&str>,   // std::env::var("PATH"), may be None
-    home: &str,                 // std::env::var("HOME")
-) -> String
-```
-
-Assembly — **highest priority first, de-duplicated preserving first occurrence,
-colon-joined**:
-
-1. **(a)** The directory the resolved `claude` binary lives in
-   (`claude_bin.parent()`). This is the single most reliable entry: it is exactly
-   where the working `claude` (and its sibling `node`, for nvm/Homebrew layouts)
-   resides.
-2. **(b)** The login-shell PATH entries (from U3's sentinel read), split on `:`,
-   in order.
-3. **(c)** The already-inherited PATH entries (`inherited_path`), split on `:`.
-4. **(d)** Well-known fallback dirs, in this order: every
-   `~/.nvm/versions/node/*/bin` **newest-first** (same discovery + sort as the
-   existing dir scan — reuse or mirror it), then `~/.local/bin`,
-   `/opt/homebrew/bin`, `/usr/local/bin`, then the standard system dirs
-   (`/usr/bin`, `/bin`, `/usr/sbin`, `/sbin`). (d) guarantees a usable PATH even
-   when both (b) and (c) are absent — the packaged-`.app` worst case.
-
-De-dup rule: an entry already emitted by an earlier source is skipped when it
-recurs later (first occurrence wins, preserving priority). Empty segments are
-dropped.
-
-**Wire into `spawn_claude_resume` (`:1223+`):** after `resolve_claude_binary`
-returns `claude_bin`, read the login-shell PATH via U3's helper, call
-`build_child_path(&claude_bin, login_path.as_deref(), std::env::var("PATH").ok().as_deref(), &home)`,
-and set `.env("PATH", &computed)` on the command — alongside the existing
-`.env_remove("ANTHROPIC_API_KEY")` at `:1260` (do not remove or duplicate that
-line).
-
-## Implementation units
-
-| Unit | File                   | Summary                                                                                                           | Depends on                       |
-| ---- | ---------------------- | ----------------------------------------------------------------------------------------------------------------- | -------------------------------- |
-| U2   | `src-tauri/src/lib.rs` | Reorder `resolve_claude_binary`: which → login shell → dir scan last; update doc comment `:1090–1096`             | —                                |
-| U3   | `src-tauri/src/lib.rs` | Shell-read helper: `-ilc`, last-non-empty-line binary resolution, sentinel PATH read; update `:1136–1138` comment | — (used by U2's shell step & U1) |
-| U1   | `src-tauri/src/lib.rs` | Pure `build_child_path`; wire `.env("PATH", …)` into `spawn_claude_resume`                                        | U3 (login-PATH source)           |
-
-Recommended build order: **U3 → U2 → U1** (helper first, then the resolver that
-uses it, then the builder that consumes both the resolved binary and the login
-PATH).
-
-## Test scenarios
-
-Tests live in the existing `#[cfg(test)] mod tests` block in
-`src-tauri/src/lib.rs` (alongside `resolve_claude_binary_returns_path_or_actionable_error`
-at `:513` and the `classify_claude_outcome` tests). Only the **pure** builder is
-unit-tested; shell-dependent and packaged-`.app` behavior is manual.
-
-**`build_child_path` (U1) — required unit tests:**
-
-1. **Includes the claude binary's own dir.** Given `claude_bin =
-/Users/x/.nvm/versions/node/v20/bin/claude`, the result contains
-   `/Users/x/.nvm/versions/node/v20/bin`.
-2. **Claude dir comes first.** With a non-empty login PATH and inherited PATH
-   supplied, the claude binary's dir is the **first** colon-segment of the
-   result (priority (a) beats (b)/(c)/(d)).
-3. **De-dups preserving first occurrence.** When the same dir appears in the
-   claude dir, the login PATH, and the inherited PATH, it appears **exactly once**
-   in the result, at its earliest (highest-priority) position.
-4. **Well-known dirs present when login+inherited both absent.** With
-   `login_shell_path = None` and `inherited_path = None`, the result still
-   contains the fallback dirs (`/opt/homebrew/bin`, `/usr/local/bin`,
-   `~/.local/bin` expanded against `home`, and the standard system dirs) — the
-   packaged-`.app` worst case still yields a usable PATH.
-
-Add assertions as natural: no empty segments in the output; nvm bin dirs (when
-present under the test `home`) are ordered newest-first, mirroring the existing
-scan.
-
-**`resolve_claude_binary` (U2/U3):** keep the existing
-`resolve_claude_binary_returns_path_or_actionable_error` test green (environment-
-dependent: an absolute path on a dev machine, an actionable error in bare CI —
-never a panic). No new deterministic unit test is added for the reordered
-resolver because it shells out; the ordering change is covered by review + the
-existing non-panic guarantee.
-
-## Verification
-
-- `cd src-tauri && cargo test` — all green, including the four new
-  `build_child_path` tests and the existing resolver test.
-- `cd src-tauri && cargo clippy -- -D warnings` — clean (no new warnings from the
-  helper or builder).
-- `cd src-tauri && cargo fmt --check` — clean.
-- Frontend checks unaffected (Rust-only change) but run the full bar before PR:
-  `npm run typecheck && npm run lint && npm run format:check && npm test`.
-- **Manual (out of automated scope):** build the `.app` (`npm run tauri build`),
-  launch from Finder, trigger an `@claude` reply, and confirm it streams a
-  response instead of `env: node: No such file or directory` — and that the reply
-  does not 400 on a deprecated request shape (confirming the configured, not
-  stale, binary was used).
-
-## Risks & notes
-
-- **Interactive shell side effects.** `-ilc` sources rc files, which may print
-  banners or run slow init. Mitigated by the sentinel protocol (payload is
-  unambiguous regardless of surrounding chatter) and by the existing pattern of
-  taking the last/marked line. Cost is one extra shell spawn per `@claude` reply
-  (the new PATH read); acceptable for a user-initiated action.
-- **de-dup correctness is the load-bearing invariant** for U1 — test 3 locks it.
-  A regression here would either bloat PATH harmlessly or (worse) reorder
-  priority; the "first occurrence wins" rule keeps priority intact.
-- This is **LFG Group 1** of a multi-group port (specs 01–03). Groups 2–5 follow
-  in separate LFG cycles.
diff --git a/docs/plans/2026-07-09-001-fix-menu-stale-closure-window-surfacing-plan.md b/docs/plans/2026-07-09-001-fix-menu-stale-closure-window-surfacing-plan.md
deleted file mode 100644
index add1bc4..0000000
--- a/docs/plans/2026-07-09-001-fix-menu-stale-closure-window-surfacing-plan.md
+++ /dev/null
@@ -1,282 +0,0 @@
----
-title: 'fix: menu stale-closure, window-close capability, and deep-link window surfacing'
-date: 2026-07-09
-type: fix
-status: planned
-plan_depth: lightweight
----
-
-# fix: Menu stale-closure, window-close capability, and deep-link window surfacing
-
-Group 2 of a multi-group port from a downstream fork. Three small, independent
-defects ported as **behavior specs** (not patches) from `docs/to-improve/`:
-
-- `docs/to-improve/04-window-close-capability.md`
-- `docs/to-improve/05-deep-link-surface-window.md`
-- `docs/to-improve/06-menu-handler-stale-closure.md`
-
-Each is applied to match this repo's existing conventions. The specs' own code is
-reference only — the ground truth below reflects the current state of this repo,
-verified before planning.
-
----
-
-## Problem Frame
-
-Three latent defects, all reachable in the shipped desktop app:
-
-1. **Window won't close from the unsaved-changes dialog (spec 04).** The
-   `onCloseRequested` guard in `src/App.tsx` correctly calls `win.destroy()` on
-   both the guard-resolved ("Don't Save") path and the catch path — but the
-   Tauri capability set does not grant `core:window:allow-destroy`. A
-   frontend-initiated `destroy()` is blocked by the ACL, so choosing "Don't
-   Save" (or hitting the catch) silently fails to close the window. This is a
-   real present bug in the built app, not a theoretical one.
-
-2. **Deep link opens the doc but leaves the window hidden/behind (spec 05).**
-   The `on_open_url` deep-link handler in `src-tauri/src/lib.rs` emits
-   `deep-link-open` so the frontend loads the file, but never surfaces the main
-   window. If Quill is running hidden, minimized, or in the background, a
-   `quill://open?file=…` link loads the document invisibly — the user sees
-   nothing happen.
-
-3. **Cmd+S and other native-menu shortcuts fire stale handlers (spec 06).** The
-   menu-event effect in `src/App.tsx` registers Tauri listeners exactly once on
-   mount, reading handlers through a ref that is refreshed every render. But the
-   wiring aliases `const h = menuHandlersRef.current` at registration time and
-   dereferences `h.` inside each callback — snapshotting the **first render's**
-   handlers. Symptom: Cmd+S always routes to Save-As because `handleSave` closes
-   over the initial `openFilePath = null`. Every menu action except Open Recent
-   (which already reads the ref at fire time) and Clear Recent (which calls
-   module functions directly) is affected. The effect's own trailing comment
-   claims "handlers are read live through menuHandlersRef" — which is exactly
-   what the buggy alias breaks.
-
-## Scope Boundaries
-
-**In scope:** the three fixes above, plus one unit test for the menu
-stale-closure (the only automated-testable piece).
-
-**Out of scope / explicitly excluded:**
-
-- Any other change to `src/App.tsx` beyond the menu-wiring fix. The
-  `onCloseRequested` guard already calls `win.destroy()` correctly on both paths
-  — do **not** re-touch it.
-- The asset-protocol `$HOME` scope in `tauri.conf.json` — leave untouched.
-- Broad window capabilities. Grant **only** `core:window:allow-destroy`, not a
-  blanket window permission set.
-- The cold-start pending-deep-link path (`take_pending_deep_link` /
-  `PendingDeepLink`). Surfacing belongs on the warm `on_open_url` emit path where
-  a running window exists; cold start already launches and surfaces the app
-  through normal startup.
-- Internal Amazon/Brazil fork adaptations (build wiring, dependency mirror, CSP
-  scrubbing, font vendoring, plugin repointing, update-checker removal) — never
-  ported.
-
-## Requirements
-
-- **R1** — Choosing "Don't Save" (or the catch path) in the unsaved-changes
-  dialog on window close actually closes the window. (spec 04)
-- **R2** — A `quill://open?file=…` deep link received while the app is running
-  brings the main window to the foreground (shown, unminimized, focused) in
-  addition to loading the document. (spec 05)
-- **R3** — Native-menu shortcuts (Cmd+S in particular) invoke the current
-  render's handlers, so Save saves to the open file rather than always prompting
-  Save-As. (spec 06)
-- **R4** — The menu-handler-ref contract is protected by a unit test that fails
-  if wiring reverts to a registration-time snapshot.
-
-## Key Technical Decisions
-
-- **Grant exactly `core:window:allow-destroy` (spec 04).** Verified against
-  `src-tauri/gen/schemas/acl-manifests.json`: `core:default` bundles
-  `core:window:default`, which is read-only window commands and does **not**
-  include `allow-destroy`. `allow-destroy` is a valid grantable permission.
-  Adding just that one permission is the minimal grant that unblocks the
-  existing `win.destroy()` calls — no App.tsx change needed. Frontend-initiated
-  window operations are the only ones gated by capabilities; this is why the
-  Rust-side surfacing in spec 05 needs no capability change.
-
-- **Surface the window in Rust, best-effort (spec 05).** After the existing
-  `handle.emit("deep-link-open", path)`, resolve the main window via
-  `handle.get_webview_window("main")` (the `Manager` trait is already imported at
-  `src-tauri/src/lib.rs:10`; window label `"main"` matches the capability scope)
-  and call `show()`, `unminimize()`, `set_focus()`, ignoring each `Result` with
-  `let _ =` — the same best-effort style the surrounding closure already uses for
-  `emit`. Rust-initiated window ops are not capability-gated, so no
-  `default.json` change accompanies this. Additive only: a few lines inside the
-  existing `if let Some(path) = …` branch, after the emit.
-
-- **Read the ref at fire time, per callback (spec 06).** Delete the
-  `const h = menuHandlersRef.current` alias and make each wired callback
-  dereference `menuHandlersRef.current` when it runs, mirroring the Open-Recent
-  block that already does this correctly (`const cur = menuHandlersRef.current`
-  inside the callback). This keeps the register-once / read-live design the
-  effect's comment already documents — the fix makes the code match its stated
-  contract. `menu-clear-recent` already calls module functions directly (not via
-  `h`); leave it as-is.
-
-- **Unit-test the ref contract, not the whole effect (spec 06).** The failing
-  behavior is purely "does the wired callback read the latest ref value or a
-  snapshot?" A focused unit test that simulates a ref reassigned across renders
-  and asserts the wired callback invokes the latest handler pins the contract
-  without standing up Tauri's `listen`. Deep-link surfacing and the capability
-  grant are verified manually in a built `.app` (out of automated-test scope).
-
-## Implementation Units
-
-### U1. Grant `core:window:allow-destroy` capability
-
-**Goal:** Unblock the frontend-initiated `win.destroy()` so the unsaved-changes
-dialog can actually close the window. (R1)
-
-**Requirements:** R1
-
-**Dependencies:** none
-
-**Files:**
-
-- `src-tauri/capabilities/default.json` (modify)
-
-**Approach:** Add `"core:window:allow-destroy"` to the `permissions` array.
-Grant only that one permission — do not add blanket window perms. The App.tsx
-`onCloseRequested` guard already calls `win.destroy()` on both the
-guard-resolved and catch paths; this is the only missing piece.
-
-**Patterns to follow:** the existing flat string-array entries in
-`permissions` (e.g. `"dialog:allow-open"`).
-
-**Test scenarios:** `Test expectation: none — capability-manifest JSON change;
-verified manually in a built .app by choosing "Don't Save" on window close and
-confirming the window closes. No automated harness exercises the Tauri ACL.`
-
-**Verification:** `cargo test` and `cargo clippy -- -D warnings` still pass (the
-capability file is validated at build time); the JSON remains well-formed and
-`prettier`-clean.
-
-### U2. Surface the main window on warm deep-link open
-
-**Goal:** Bring the main window to the foreground when a `quill://open` link
-arrives while the app is running. (R2)
-
-**Requirements:** R2
-
-**Dependencies:** none
-
-**Files:**
-
-- `src-tauri/src/lib.rs` (modify — the `on_open_url` closure, ~`:1527`)
-
-**Approach:** Immediately after the existing
-`let _ = handle.emit("deep-link-open", path);` (currently `src-tauri/src/lib.rs:1535`),
-add a best-effort surfacing block: resolve `handle.get_webview_window("main")`
-and, when present, call `.show()`, `.unminimize()`, `.set_focus()`, discarding
-each `Result` with `let _ =`. `Manager` (providing `get_webview_window`) is
-already imported at `src-tauri/src/lib.rs:10`; `handle` is already cloned before
-the closure. Keep it inside the existing `if let Some(path) = parse_quill_open(…)`
-branch. Do **not** touch the cold-start `PendingDeepLink` buffering — that path
-surfaces via normal startup.
-
-**Patterns to follow:** the surrounding closure's own best-effort style —
-`let _ = handle.emit(...)` and `let _ = app.emit(id, ())` elsewhere in `setup`.
-
-**Test scenarios:** `Test expectation: none — Tauri window surfacing has no
-headless-testable seam here; verified manually in a built .app by minimizing the
-window, opening a quill://open?file=… link, and confirming the window comes
-forward with the document loaded.`
-
-**Verification:** `cargo test`, `cargo clippy -- -D warnings`, and
-`cargo fmt --check` pass; the added lines compile with no unused-import or
-unused-result warnings.
-
-### U3. Fix menu-handler stale closure + add ref-contract unit test
-
-**Goal:** Make native-menu callbacks invoke the current render's handlers, and
-protect that with a unit test. (R3, R4)
-
-**Requirements:** R3, R4
-
-**Dependencies:** none
-
-**Files:**
-
-- `src/App.tsx` (modify — the menu-event `useEffect`, ~`:626`–`:643`)
-- `src/test/utils/menuHandlerRef.test.ts` (create)
-
-**Approach:** In the menu-event effect, remove the
-`const h = menuHandlersRef.current` alias and rewrite each `wire(...)` callback
-to read `menuHandlersRef.current` at fire time — e.g.
-`await wire('menu-save', () => void menuHandlersRef.current.handleSave())` — for
-all of: `menu-new`, `menu-open`, `menu-save`, `menu-save-as`,
-`menu-export-pdf`, `menu-quit`, `menu-copy-diagnostics`, `menu-reveal-logs`.
-Preserve the existing `void`/no-`void` shape per handler (the async ones keep
-`void`). Leave `menu-clear-recent` (calls module functions directly) and the
-Open-Recent block (already reads `menuHandlersRef.current` at fire time)
-untouched. This makes the code match the effect's existing trailing comment,
-"handlers are read live through menuHandlersRef."
-
-For the test: model the ref-read pattern in isolation. Build a small harness that
-mirrors the wiring — a mutable ref object whose `.current` is reassigned to
-simulate a later render, and a `wire(event, fn)` that stores `fn`. Fire the
-stored callback **after** reassigning the ref, and assert it invokes the latest
-handler, not the one present at registration. A registration-time snapshot
-(`const h = ref.current`) must make the test fail; a fire-time read
-(`ref.current.handler()`) must make it pass.
-
-**Patterns to follow:** the Open-Recent handler in the same effect
-(`src/App.tsx:650`, `const cur = menuHandlersRef.current` inside the callback) is
-the correct reference model. For the test file, mirror the structure and imports
-of existing specs under `src/test/utils/` (Vitest `describe`/`it`/`expect`).
-
-**Test scenarios** (`src/test/utils/menuHandlerRef.test.ts`):
-
-- **Covers R4.** Fire-time read invokes the latest handler: given a ref whose
-  `.current.handleSave` is `fnA` at wiring time, wire a callback that reads
-  `ref.current.handleSave()`, then reassign `ref.current` so `handleSave` is
-  `fnB`, fire the callback, and assert `fnB` was called and `fnA` was not.
-- **Guard against snapshot regression:** demonstrate that the fire-time pattern
-  survives multiple reassignments — reassign the ref twice and confirm the
-  callback always calls the newest handler. (This is the assertion a
-  registration-time alias would fail.)
-- **Multiple events, independent handlers:** wire two events reading different
-  keys off the ref (`handleSave`, `handleNew`); reassign both; fire each; assert
-  each invokes its own latest handler. Confirms the pattern is per-callback, not
-  shared state.
-
-**Verification:** `npm run typecheck`, `npm run lint`, `npm run format:check`,
-and `npm test` all pass; the new test fails if the wiring is reverted to a
-`const h = menuHandlersRef.current` snapshot (sanity-check by temporarily
-reintroducing the alias locally, confirming red, then reverting).
-
----
-
-## Risks & Dependencies
-
-- **Low blast radius.** All three changes are additive or localized. Spec 04 is a
-  one-line capability addition; spec 05 is a few additive Rust lines on an
-  existing branch; spec 06 removes an alias and inlines a ref read that the
-  Open-Recent path already proves works.
-- **The two runtime-only fixes (U1, U2) have no automated coverage** — this is
-  inherent to Tauri capability ACLs and native window surfacing. Both are
-  verified manually in a built `.app`. The plan does not pretend otherwise; the
-  menu fix (U3), which _is_ testable, carries the unit test.
-- **No cross-unit dependencies.** U1, U2, U3 are independent and can land in any
-  order; they ship together as one PR for the Group 2 theme.
-
-## Verification (whole change)
-
-Match the CI bar before opening the PR:
-
-- Frontend: `npm run typecheck`, `npm run lint`, `npm run format:check`,
-  `npm test`.
-- Rust: `cargo test`, `cargo clippy -- -D warnings`, `cargo fmt --check` (run in
-  `src-tauri/`).
-
-Manual (built `.app`, out of automated scope, for the record):
-
-- Spec 04: open a dirty doc, close the window, choose "Don't Save" → window
-  closes.
-- Spec 05: minimize/background the app, trigger a `quill://open?file=…` deep
-  link → window comes forward with the doc loaded.
-- Spec 06: open a saved file, edit, press Cmd+S → saves in place (no Save-As
-  dialog).
diff --git a/docs/release-notes/v1.1.2.md b/docs/release-notes/v1.1.2.md
new file mode 100644
index 0000000..6dbaff6
--- /dev/null
+++ b/docs/release-notes/v1.1.2.md
@@ -0,0 +1,31 @@
+# Quill v1.1.2
+
+**A round of fixes from real use, plus a couple of quality-of-life touches.**
+
+This patch is all polish on top of 1.1.0/1.1.1 — nothing changes on disk, and documents and sidecars remain fully compatible with every previous release in both directions. The theme is making the `@claude` integration and the reading surface behave the way you'd expect.
+
+## Fixes
+
+- **`@claude` finds the Claude CLI reliably.** Spawning a reply now resolves the `claude` binary the same way your shell would — including a configured/installed path and a login shell's `PATH` — instead of assuming one fixed location, so `@claude` works even when Claude Code lives somewhere non-standard.
+- **Closing, deep-linking, and the desktop menu are steadier.** Hardened the window-close capability, brought the app window to the front when opened via a `quill://` deep link, and fixed a stale-closure bug in the native menu so menu actions always act on the current document.
+- **Retry a failed `@claude` reply in place.** If a reply errors out, you can retry it directly from the comment without retyping — no need to delete and re-add the `@claude` mention.
+- **Re-run a cancelled `@claude` call.** Cancelling a reply now leaves a **Re-run** button on the comment so you can kick the call off again, rather than being stuck with a dead reply. (The rarely-working "Start new session" button was removed in the same pass.)
+- **Comment placeholders hint at `@claude`.** The comment and reply composers now say _"@claude to get an AI response"_ so the AI trigger is discoverable instead of hidden.
+- **Wider, calmer reading surface.** Reduced the page's horizontal padding to open the measure to ~85 characters, and removed a leftover page-break background that could draw faint lines through text.
+
+## Install
+
+| Platform              | Asset           |
+| --------------------- | --------------- |
+| macOS (Apple Silicon) | `…_aarch64.dmg` |
+| macOS (Intel)         | `…_x64.dmg`     |
+
+Builds are **unsigned**. On first launch, double-click **Quill**, click **Done**, then go to **System Settings → Privacy & Security → Open Anyway** (or run `xattr -dr com.apple.quarantine /Applications/Quill.app`). The old right-click → Open shortcut was removed in macOS Sequoia.
+
+The `@claude` features require the [Claude Code](https://claude.com/claude-code) CLI on the same machine. See the [User Guide](https://github.com/sam-powers/quill/blob/main/docs/USER_GUIDE.md) for a walkthrough.
+
+## Known limitations
+
+- macOS only for now. The `@claude` integration finds the Claude CLI via Unix paths; rather than ship a partial experience, Windows and Linux installers are deferred (both platforms can [build from source](https://github.com/sam-powers/quill#building-from-source)).
+- No code signing yet (Gatekeeper warning above).
+- Single document per window; no multi-user collaboration or cloud sync.
diff --git a/docs/to-improve/01-claude-spawn-path.md b/docs/to-improve/01-claude-spawn-path.md
deleted file mode 100644
index ccced04..0000000
--- a/docs/to-improve/01-claude-spawn-path.md
+++ /dev/null
@@ -1,66 +0,0 @@
-# 01 — claude CLI: give the spawned process a working PATH
-
-**Area:** Rust backend (`src-tauri/src/lib.rs`) · **Type:** bug · **Related:** 02, 03
-
-## Problem
-
-When Quill is launched as a packaged macOS `.app` (Finder/Dock/Spotlight) rather
-than from a terminal, `@claude` replies fail immediately. The spawned `claude`
-CLI is a Node script (`#!/usr/bin/env node`, or a shim that re-execs one), and it
-dies with:
-
-```
-env: node: No such file or directory
-```
-
-## Root cause
-
-A GUI app launched by macOS `launchd` inherits a **minimal PATH** (roughly
-`/usr/bin:/bin:/usr/sbin:/sbin`) — none of nvm/fnm/Homebrew/Volta dirs where
-`node` lives. A terminal launch (`npm run tauri dev`) inherits the shell's full
-PATH, so this never reproduces in dev. When Quill spawns `claude` with the
-inherited (minimal) environment, `claude`'s `env node` lookup finds no `node`.
-
-## The change
-
-When spawning the `claude` CLI (the command backing `@claude` replies and
-full-document review), set the child process's `PATH` env var to a computed PATH
-that includes `node`, instead of letting it inherit the minimal launchd PATH.
-
-Build that PATH from these sources, highest priority first, de-duplicated
-(preserve first occurrence), colon-joined:
-
-1. **The directory the resolved `claude` binary lives in.** `node` is very often
-   its sibling (same nvm/fnm version dir, same Homebrew `bin`). This single entry
-   fixes the common case even if everything else fails.
-2. **The login shell's PATH** — the authoritative source for whatever the user
-   configured (nvm/fnm/Homebrew/Volta). See spec 03 for how to read this
-   correctly (it must source the interactive rc file).
-3. **The already-inherited PATH** — covers the `tauri dev` / terminal case.
-4. **Well-known fallback dirs** as a backstop: every `~/.nvm/versions/node/*/bin`
-   (newest version first), `~/.local/bin`, `/opt/homebrew/bin`, `/usr/local/bin`,
-   and the standard system dirs.
-
-Implement the PATH assembly as a **pure function** taking `(claude_bin_path,
-login_shell_path, inherited_path, home)` so it can be unit-tested without
-touching the environment. Then in the spawn command, `.env("PATH", &computed)`.
-
-Also `.env_remove("ANTHROPIC_API_KEY")` on the spawned command if the public repo
-doesn't already — Quill drives `claude` as the user's own CLI session, and a stray
-API-key env var can change which credentials/endpoint the CLI uses.
-
-## Verify
-
-- Unit tests for the pure PATH builder: (a) includes the claude binary's own dir;
-  (b) claude dir comes first; (c) de-dups preserving first occurrence; (d) still
-  produces the well-known dirs when login+inherited PATH are both absent.
-- Real-app check: build the `.app`, launch it from Finder (not a terminal),
-  trigger an `@claude` reply, confirm it runs instead of `env: node` failing.
-
-## Notes for the porter
-
-- The public repo may resolve/spawn `claude` slightly differently — apply the
-  _intent_ (spawned child gets a node-containing PATH), matching the repo's
-  existing spawn code.
-- This is the same `spawn_claude_resume` path used by both single-comment replies
-  and full-document review, so fixing it once covers both.
diff --git a/docs/to-improve/02-claude-resolve-configured-binary.md b/docs/to-improve/02-claude-resolve-configured-binary.md
deleted file mode 100644
index 882f5f3..0000000
--- a/docs/to-improve/02-claude-resolve-configured-binary.md
+++ /dev/null
@@ -1,63 +0,0 @@
-# 02 — claude CLI: resolve the user's configured binary, not a stale copy
-
-**Area:** Rust backend (`src-tauri/src/lib.rs`) · **Type:** bug · **Related:** 01, 03
-
-## Problem
-
-`@claude` replies fail deterministically with an API error like:
-
-```
-API Error: 400 "thinking.type.enabled" is not supported for this model.
-Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior.
-```
-
-Retrying just re-hits the same error. The user has a current, working `claude`
-CLI — but Quill is invoking a **different, stale** one.
-
-## Root cause
-
-Quill resolves the `claude` binary by scanning a hardcoded list of install
-directories (including every `~/.nvm/versions/node/*/bin/claude`). If an old
-global install exists there (e.g. a months-old `npm i -g @anthropic-ai/claude-code`
-under an old Node version), the dir scan finds **that** one first — not the
-current `claude` the user's shell actually resolves. The stale CLI emits a
-deprecated request shape that the current model rejects with a 400.
-
-The tell: the failing session's transcript entries are tagged with the **old**
-CLI version (e.g. `version: 2.1.104`) while the user's real `claude --version`
-reports something newer. Picking the wrong-version binary is a silent
-**correctness** bug, not a "not found" error.
-
-## The change
-
-Reorder `claude` binary resolution so the **user's configured CLI wins**:
-
-1. **Bare `which claude`** first (works under `tauri dev` / terminal launch where
-   PATH is already good). Only trust the result if it names an existing file.
-2. **Ask the user's shell**: run `command -v claude` through their login shell
-   (see spec 03 for why it must be an _interactive_ login shell) — this resolves
-   the `claude` the user actually uses. Take the last non-empty stdout line (so an
-   rc banner can't be mistaken for the path) and verify it's a real file.
-3. **Only then**, as a last-ditch fallback, scan the hardcoded install dirs. A
-   stale install here is strictly better than failing outright — but it must
-   **never preempt** the user's shell choice above.
-
-The principle: **when resolving a user's installed CLI from a GUI app, the tool
-their shell resolves is authoritative.** Consult the shell before scanning
-install dirs; a machine may have several `claude` installs of different ages, and
-the dir scan must not silently shadow the current one.
-
-## Verify
-
-- Confirm resolution returns the shell-resolved `claude` even when a stale copy
-  exists in one of the scanned dirs (leave the stale copy in place; the new logic
-  should skip past it via the shell step).
-- Real-app check: `@claude` reply succeeds in the built `.app` where it previously
-  400'd.
-
-## Notes for the porter
-
-- This pairs with spec 01: 01 makes the spawned CLI _run_; 02 makes sure it's the
-  _right_ CLI. Do them together.
-- Do not delete or modify the user's stale install — just make resolution prefer
-  the configured one.
diff --git a/docs/to-improve/03-claude-interactive-login-shell.md b/docs/to-improve/03-claude-interactive-login-shell.md
deleted file mode 100644
index c50aaf2..0000000
--- a/docs/to-improve/03-claude-interactive-login-shell.md
+++ /dev/null
@@ -1,67 +0,0 @@
-# 03 — claude CLI: use an interactive login shell to read PATH
-
-**Area:** Rust backend (`src-tauri/src/lib.rs`) · **Type:** bug · **Related:** 01, 02
-
-## Problem
-
-Specs 01 and 02 both need to "ask the user's shell" — for the resolved `claude`
-path (02) and for the login-shell PATH handed to the spawned child (01). If that
-shell is invoked as a **non-interactive** login shell (`$SHELL -lc '…'`), it
-comes back empty or wrong under launchd's minimal environment, and both fixes
-silently fail: `claude` still isn't found and `node` still isn't on the child's
-PATH.
-
-## Root cause
-
-macOS shell-sourcing rules:
-
-- A **login** shell (`-l`) sources `.zprofile` / `.zshenv` (zsh) or `.bash_profile`.
-- An **interactive** shell (`-i`) sources `.zshrc` / `.bashrc`.
-
-Toolchain PATH lines (nvm/fnm init, Homebrew `shellenv`, Volta, corporate
-toolbox dirs) are **very commonly placed in `.zshrc` / `.bashrc`**, which a
-`-lc` (login, non-interactive) shell does **not** source. So under launchd's
-minimal env, `$SHELL -lc 'command -v claude'` resolves nothing and
-`$SHELL -lc 'printf %s "$PATH"'` returns a PATH missing node.
-
-Proof pattern (scrubbed env):
-
-```
-env -i HOME=$HOME /bin/zsh -lc  'command -v claude'   # → empty
-env -i HOME=$HOME /bin/zsh -ilc 'command -v claude'   # → /path/to/the/real/claude
-```
-
-## The change
-
-Use an **interactive login shell** — `$SHELL -ilc '…'` — everywhere Quill reads
-the user's shell to discover `claude` or PATH. Both the binary-resolution step
-(spec 02) and the child-PATH login-shell read (spec 01).
-
-Two robustness details, because interactive shells may print rc banners/MOTD to
-stdout:
-
-- **Resolving the binary:** take the **last non-empty line** of stdout as the
-  path (a banner printed before `command -v` output can't be mistaken for it).
-- **Reading PATH:** print it with a **sentinel prefix** and parse the sentinel
-  line, e.g. `printf '___QUILL_PATH___%s\n' "$PATH"` then find the line starting
-  with `___QUILL_PATH___`. This isolates the PATH from any rc chatter.
-
-## Trade-off (accept it)
-
-Interactive shells are slightly slower and may run rc side effects. That's an
-acceptable cost for correct resolution; the sentinel / last-line parsing contains
-the banner-noise downside.
-
-## Verify
-
-- With a PATH-setting line in `.zshrc` (not `.zprofile`), confirm the resolver
-  finds `claude` and the child PATH contains node — where a `-lc` variant would
-  have failed.
-- Real-app check (built `.app` from Finder): `@claude` works end-to-end.
-
-## Notes for the porter
-
-- This is a one-flag change (`-lc` → `-ilc`) plus the sentinel/last-line parsing,
-  applied at **both** shell-invocation sites. Grep for `-lc` in the Rust backend.
-- If the public repo has only one such site today, the same `-ilc` + parsing
-  discipline applies there.
diff --git a/docs/to-improve/04-window-close-capability.md b/docs/to-improve/04-window-close-capability.md
deleted file mode 100644
index 3838ef0..0000000
--- a/docs/to-improve/04-window-close-capability.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# 04 — Window won't close from the unsaved-changes dialog
-
-**Area:** Rust capability grant + `src/App.tsx` · **Type:** bug
-
-## Problem
-
-The unsaved-changes guard (the Save / Don't Save / Cancel dialog that intercepts
-window close, New, Open, etc.) can't actually close the window when the user
-chooses "Don't Save" (or after saving). The window-close is intercepted by the
-frontend guard, but the frontend's attempt to then destroy/close the window is
-denied by Tauri's capability ACL, so the window stays open.
-
-## Root cause
-
-Tauri 2 gates frontend-initiated window operations behind explicit **capability
-permissions**. The app intercepts the OS close request (to run the dirty-check
-first) but was never granted the permission to programmatically destroy the
-window afterward, so the follow-through close is silently blocked.
-
-## The change
-
-1. **Grant the window-destroy capability.** Add `core:window:allow-destroy` (the
-   Tauri 2 permission for `Window.destroy()`) to the app's capability file
-   (whatever the public repo uses — commonly `src-tauri/capabilities/default.json`,
-   scoped to the `"main"` window).
-2. **Call it on the confirmed-close path** in `App.tsx`: after the dirty check
-   resolves (user picked Don't Save, or Save completed), destroy the window. Wrap
-   the guard logic so that if anything in the save path throws, the `catch`
-   destroys the window anyway rather than trapping the user in an un-closable
-   window.
-
-## Verify
-
-- Open a doc, make an edit (dirty), hit the window close button → dialog appears →
-  "Don't Save" → window actually closes.
-- Same with "Save" → saves, then closes.
-- Force an error in the save path (e.g. cancel the save dialog) → the window still
-  closes via the catch, not trapped open.
-
-## Notes for the porter
-
-- The exact permission string is Tauri-version-specific; `core:window:allow-destroy`
-  is correct for Tauri 2. If the public repo already grants broader window perms,
-  this may be a no-op on the capability side and only need the `App.tsx` follow-through.
-- Only grant what's needed (destroy), not blanket window permissions.
diff --git a/docs/to-improve/05-deep-link-surface-window.md b/docs/to-improve/05-deep-link-surface-window.md
deleted file mode 100644
index 60ca0b7..0000000
--- a/docs/to-improve/05-deep-link-surface-window.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# 05 — Deep link opens a doc but leaves the window hidden
-
-**Area:** Rust backend (`src-tauri/src/lib.rs`, deep-link handler) · **Type:** bug
-
-## Problem
-
-Opening a document via a `quill://open?file=…` deep link (e.g. from the
-`open-in-quill` integration, or `open quill://…` on macOS) loads the document
-into the editor — but if Quill's window is backgrounded, minimized, or hidden,
-the window doesn't come forward. The editor updates invisibly and the deep link
-looks like a no-op: the user clicked a link and apparently nothing happened.
-
-## Root cause
-
-The deep-link handler emits the `deep-link-open` event (frontend loads the doc)
-but never surfaces the main window. The document genuinely loads into the
-existing window; it's just not shown.
-
-## The change
-
-In the deep-link handler, after emitting the open event, surface the main window.
-Cover all three background states:
-
-```rust
-if let Some(win) = handle.get_webview_window("main") {
-    let _ = win.show();        // hidden
-    let _ = win.unminimize();  // minimized
-    let _ = win.set_focus();   // backgrounded
-}
-```
-
-All three calls together handle hidden, minimized, and merely-backgrounded
-windows. Ignore the individual `Result`s (best-effort surfacing).
-
-## Verify
-
-- Minimize Quill, fire a `quill://open?file=…` deep link → window restores and
-  comes to the front showing the opened doc.
-- Same with the window merely behind another app, and with a hidden window.
-
-## Notes for the porter
-
-- Match the public repo's window label (`"main"` in the fork; confirm the repo's).
-- This is additive — a few lines in the existing deep-link branch.
diff --git a/docs/to-improve/06-menu-handler-stale-closure.md b/docs/to-improve/06-menu-handler-stale-closure.md
deleted file mode 100644
index b11fd15..0000000
--- a/docs/to-improve/06-menu-handler-stale-closure.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# 06 — Cmd+S (and other native-menu shortcuts) use stale handlers
-
-**Area:** `src/App.tsx` (native menu event wiring) · **Type:** bug (stale closure)
-
-## Problem
-
-Native menu actions (File → Save, New, Open, Save As, Export PDF, Quit, Copy
-Diagnostics, Show Logs) behave as if the app is stuck on its initial state. The
-clearest symptom: **Cmd+S / File → Save always routes to "Save As"** (shows a save
-dialog) even for an already-saved file, because it sees `filePath = null` — the
-value from first render — instead of the current file path.
-
-## Root cause
-
-The menu-event listeners are registered once (in a mount effect). The handlers
-live in a ref (`menuHandlersRef`) that is **reassigned to a fresh object every
-render**, because the handlers close over changing state (`filePath`, `comments`,
-etc.). The buggy wiring aliased `menuHandlersRef.current` into a local variable
-**at registration time**:
-
-```ts
-const h = menuHandlersRef.current; // ← snapshot of the FIRST render's handlers
-await wire('menu-save', () => void h.handleSave()); // frozen forever
-```
-
-That local `h` captures only the first render's closures. Every menu action then
-runs against first-render state.
-
-## The change
-
-Read `menuHandlersRef.current` **inside each callback (at fire time)**, never
-aliased into a local at registration:
-
-```ts
-await wire('menu-save', () => void menuHandlersRef.current.handleSave());
-await wire('menu-new', () => menuHandlersRef.current.handleNew());
-// …same for save-as, export-pdf, quit, copy-diagnostics, reveal-logs
-```
-
-The ref is the whole point — it exists so the once-registered listener can reach
-the _latest_ handlers. Dereference it late.
-
-## Verify
-
-- Add a unit test (mirror the fork's `src/test/utils/menuHandlerRef.test.ts`):
-  simulate the ref being reassigned across renders, fire a wired callback, assert
-  it invokes the **latest** handler, not the one present at registration.
-- Real-app check: open and save a file, edit, Cmd+S → saves in place (no Save-As
-  dialog).
-
-## Notes for the porter
-
-- General principle: when a long-lived listener needs current state, keep the
-  state in a ref and read `ref.current` at call time — do **not** copy `.current`
-  into a local at registration. The fork's Open-Recent handler already did this
-  correctly and was the reference for the fix.
-- The exact set of `menu-*` events depends on which menu items the public repo
-  exposes; apply the read-at-fire-time pattern to all of them.
diff --git a/docs/to-improve/07-claude-reply-retry-ux.md b/docs/to-improve/07-claude-reply-retry-ux.md
deleted file mode 100644
index b32d421..0000000
--- a/docs/to-improve/07-claude-reply-retry-ux.md
+++ /dev/null
@@ -1,101 +0,0 @@
-# 07 — Retry failed @claude replies; gate "Re-link session" to real session errors
-
-**Area:** Frontend (`useClaudeReply`, `useComments`, `CommentCard`, `App.tsx`,
-`annotationValidation`) · **Type:** feature
-
-## Problem
-
-When an `@claude` reply fails, the only affordance is a single "Re-link session…"
-button, shown **unconditionally for every error**. For a transient/API error
-(400/429/5xx, network blip, a passing server condition) that button is useless and
-misleading — it implies the session link is broken, and re-linking just re-runs
-the same call. There's no way to simply **retry**.
-
-## The change
-
-Four parts:
-
-### 1. A pure error classifier
-
-Add `classifyReplyError(message: string): { retryable: boolean; kind: 'transient'
-| 'session' | 'auth' | 'unknown' }` (co-locate with the other exported pure
-helpers in the `@claude` reply hook; unit-test it).
-
-Matching rules, **ordered — specific before broad**:
-
-- `session` — matches "No conversation found", "session ID", "session not found".
-  → retryable, but session-recovery is primary.
-- `auth` — matches "authentication", "unauthorized", "401", "login", "API key",
-  "credentials". → **not** retryable. (Deliberately do **not** match a bare word
-  "auth" — infra/transient messages often contain it incidentally.)
-- `transient` — matches "API Error", HTTP 4xx/5xx codes (429/500/502/503/529),
-  "overloaded", "timeout", "network", "rate limit", "ECONN", and the
-  model-parameter family (e.g. "thinking.type"). → retryable.
-- `unknown` — anything unmatched → retryable.
-
-**Default-to-retryable is deliberate:** the bug being fixed is that errors
-dead-end. A wrong "Retry" costs one re-run; a wrong "Re-link" misdirects the user.
-Include a negative-control test (a clearly-transient message must NOT classify as
-`session`).
-
-### 2. Retry re-issues in place (no duplicate reply)
-
-- Add a state helper `retryAIReply(commentId, replyId)` (mirror the existing
-  `startAIReply`/`failAIReply` shape) that resets the **same** errored reply to
-  `{ pending: true, error: undefined, text: '' }` — it must reuse the existing
-  reply entry, never append a new one.
-- Retry must re-issue the identical request (same comment, original user text,
-  session binding, context folder). The original user text isn't stored on the
-  reply, so stash the inputs needed to re-issue in a transient in-memory map
-  keyed by reply id (`replyId → { commentId, userText, binding }`), populated when
-  a reply is first requested. **In-memory only — never persisted** (see part 4).
-
-### 3. Guard the reused-replyId against races
-
-Because Retry reuses the same `replyId`, a late event from the original (failed)
-spawn could corrupt the retried reply. Add a **generation guard**: a per-reply
-counter (`genRef` map) incremented on each ask/retry; the spawn captures its
-generation and an `isCurrent()` check drops late events and orphan-cancels a spawn
-that resolves after being superseded. Also guard against double-fire (a
-`retryingRef` set) so a fast double-click can't launch two retries. (This is the
-same generation-guard pattern used in spec 08 — share the approach.)
-
-### 4. Never persist transient error/pending state to the sidecar
-
-Error and pending state are transient UI state. The `.comments.json` sidecar is
-the saved-document contract — a failed/pending reply must **not** be written to
-disk, or on reload the user sees a stale error with a Retry button that re-runs a
-long-gone request. Add `stripTransientReplyState(comments)` and call it on the
-save path so errored/pending AI replies are dropped before serialization. No
-schema change.
-
-### 5. Wire the UI
-
-In the reply view (`CommentCard` / `CommentLayer`), call `classifyReplyError` on
-a failed reply and render per kind:
-
-- `transient` / `unknown` → **Retry** button (no Re-link).
-- `session` → **Re-link session…** (Retry may also show as secondary).
-- `auth` → **Re-link session…** only (no Retry).
-
-Thread the new `onRetry` / `onRetryAIReply` callback from `App.tsx` down through
-`CommentLayer` to `CommentCard`. Style the Retry button to match the existing
-error affordance across all themes (reuse existing classes; no new color literals).
-
-## Verify
-
-- Unit tests for the classifier (each kind + the negative control + empty/whitespace
-  → `unknown`, no throw).
-- Unit tests for `retryAIReply`: clears error, sets pending, resets text, reply
-  count unchanged, reply id stable, unknown replyId is a no-op.
-- Test that a saved sidecar contains no errored/pending AI reply.
-- e2e: a reply that errors with a transient message shows **Retry** and no
-  Re-link; clicking Retry clears the error, re-enters "thinking", and on success
-  renders the reply with **no duplicate**; a "No conversation found" error shows
-  Re-link.
-
-## Notes for the porter
-
-- This is the largest spec — ~12 files in the fork. Land it as one coherent change.
-- The generation-guard machinery (part 3) is the same shape spec 08 needs; if you
-  do both, factor the pattern consistently.
diff --git a/docs/to-improve/08-review-cancel-fix.md b/docs/to-improve/08-review-cancel-fix.md
deleted file mode 100644
index 73f2870..0000000
--- a/docs/to-improve/08-review-cancel-fix.md
+++ /dev/null
@@ -1,75 +0,0 @@
-# 08 — Cancel during full-document review is a no-op
-
-**Area:** Frontend (`src/hooks/useDocumentReview.ts`) · **Type:** bug
-
-## Problem
-
-While a "Review full document" is streaming — the modal shows "Claude is reading
-the document…" — clicking **Cancel** does nothing. The review doesn't stop and the
-modal stays stuck in the reading state.
-
-## Root cause
-
-Two stacked issues:
-
-1. **Pre-token window.** The cancel handler early-returns when there's no cancel
-   token (`const token = tokenRef.current; if (!token) return;`). But the token is
-   only assigned **after** `await spawn_claude_resume(…)` resolves, while the modal
-   enters the streaming state **synchronously** on submit. So during the exact
-   "Claude is reading…" window — after submit, before the spawn resolves — there is
-   no token and Cancel is a no-op.
-2. **Event-dependent reset.** Even once a token exists, the modal only leaves the
-   streaming state when a `cancelled` event arrives back from the backend. If the
-   backend cancel doesn't emit one, the modal stays stuck. A user-initiated cancel
-   should reset the UI immediately, not depend on a round-trip event.
-
-## The change
-
-Adopt a **generation guard** in the review hook (the same pattern the single-reply
-path uses — see spec 07). Concretely:
-
-- Add `const genRef = useRef(0)`. At the top of `start`, claim a generation:
-  `const generation = ++genRef.current` and define `const isCurrent = () =>
-genRef.current === generation`.
-- After **each** async gap in `start`, if `!isCurrent()` bail / orphan-cancel:
-  - After `spawn_claude_resume` resolves: `if (isCurrent()) tokenRef.current =
-token; else invoke('cancel_claude_resume', { cancelToken: token })` — cancel
-    the now-orphaned child instead of registering its token.
-  - **Also** after any earlier await in `start` (e.g. a context-folder scan): if
-    `!isCurrent()` return before spawning, so a cancel during that earlier gap
-    doesn't still launch a review the user backed out of.
-- In the stream `dispatch`, first line: `if (!isCurrent()) return;` — drop late
-  delta/done/error events from a superseded run.
-- In `cancel()`: **bump the generation first** (`genRef.current += 1`), **reset the
-  phase to idle immediately** (don't wait for a `cancelled` event), then read and
-  null the token and fire `cancel_claude_resume` if a token existed. Capture the
-  token value before nulling it.
-- Guard `finalize()` (which applies irreversible document mutations) with
-  `if (!isCurrent()) return;` as defense-in-depth, even though it's only reached
-  via the already-guarded dispatch.
-
-The principle: **user cancel resets the UI synchronously and supersedes any
-in-flight spawn**, regardless of backend event timing.
-
-## Verify
-
-- e2e (extend the review spec): with the mock scripted to stay "reading" (a
-  `pause` step) and configured to **emit no `cancelled` event on cancel**, click
-  Cancel → the modal returns to the compose form (guidance textarea visible) and
-  no comments/suggestions are applied.
-- e2e: after cancel, inject a late `delta` straight into the stream callback and
-  assert the modal does **not** flip back to streaming (the generation guard drops
-  it).
-- The existing mid-stream cancel test (token already exists) still passes.
-
-## Notes for the porter
-
-- The fork verified both new tests **fail before** the fix and **pass after** —
-  do the same (characterize first).
-- If the mock's `spawn` returns its token synchronously, the true pre-token
-  `await` gap isn't reproducible via e2e; the injected-late-event test + the
-  no-`cancelled`-event test cover the observable behavior. A `renderHook` unit
-  test can cover the orphan-cancel-after-await branch directly if desired.
-- Do **not** change the Rust backend for this. The frontend fix makes the UI
-  correct regardless of whether `cancel_claude_resume` emits `cancelled`. Whether
-  the backend reliably terminates the child is a separate, optional follow-up.
diff --git a/docs/to-improve/09-below-fold-comment-scroll.md b/docs/to-improve/09-below-fold-comment-scroll.md
deleted file mode 100644
index 2f530e9..0000000
--- a/docs/to-improve/09-below-fold-comment-scroll.md
+++ /dev/null
@@ -1,82 +0,0 @@
-# 09 — Comments below the document's end can't be scrolled into view
-
-**Area:** Frontend (`CommentLayer.tsx`, `App.tsx`, `App.css`) · **Type:** bug
-
-## Problem
-
-A comment anchored low in the document — near or past the last line — renders a
-card that sits below the visible/scrollable area. You **can't scroll or click it
-into view**. The only workaround is to add blank lines to the document until the
-page grows tall enough to reveal the card.
-
-## Root cause
-
-Comment cards live in an `overflow: hidden` margin column. They're positioned in
-**document space** (anchor offset within the scroll area) and translated by the
-editor's `-scrollTop`, so a card paints at `nudgedTop − scrollTop`. The editor's
-maximum `scrollTop` is bounded by document content height. When a card's
-`nudgedTop + cardHeight` exceeds `maxScrollTop + viewportHeight`, **no scroll
-position can bring the card fully on-screen** — there simply isn't enough
-scrollable content below the anchor, and the column can't scroll on its own.
-Adding blank lines "works" only because it raises `maxScrollTop`.
-
-## The change
-
-Two coordinated pieces:
-
-### 1. Dynamic bottom spacer (extends the scroll range)
-
-- Have the comment layer compute the **lowest card bottom** (`max(nudgedTop +
-measuredCardHeight)` across all cards — comments _and_ suggestions; the layer
-  already tracks card positions and measured heights) and report it up to `App`
-  via a callback prop.
-- Expose a pure helper `computeBottomSpacer(maxCardBottom, baseContentHeight,
-margin) → max(0, round(maxCardBottom + margin − baseContentHeight))` (unit-test
-  it).
-- In `App`, an effect measures the scroll area's natural content height
-  (`scrollHeight − currentSpacer`, so the spacer's own height doesn't feed back),
-  computes the spacer, and renders a `<div className="editor-bottom-spacer"
-style={{ height }}>` inside the scroll content when height > 0. Guard the state
-  update with `prev === next` to avoid a feedback loop.
-- This adds scroll range **only when a low-anchored card needs it** — normal docs
-  get spacer 0 (no trailing dead space). The spacer must live on the **scrollable
-  content** (so it raises `maxScrollTop`), not on the overflow-hidden column.
-- Suppress the spacer in the print stylesheet (`@media print { .editor-bottom-spacer
-{ display: none } }`) so it never affects PDF/print output.
-
-### 2. Card-aware activation scroll
-
-The activation handlers (clicking a comment/suggestion, or its in-text highlight)
-currently scroll the **anchor** into view, which doesn't guarantee the (taller,
-possibly nudged-down) **card** is visible. Add a `scrollCardIntoView(cardId)` that
-reads the card's document-space top and scrolls the editor scroll area so the full
-card is on-screen with a small `CARD_SCROLL_MARGIN` of breathing room (the spacer
-guarantees the room exists). Call it from both activation handlers.
-
-**One timing detail:** the spacer is applied by a React effect that commits
-_after_ the click handler returns, so scrolling synchronously would clamp against
-the pre-spacer range. Defer the actual scroll by one `requestAnimationFrame` so
-the spacer effect has flushed. Also, if the activation also fires an anchor
-`scrollIntoView`, make that one `behavior: 'instant'` so it doesn't fight the
-card's smooth scroll on the same container (two concurrent smooth scrolls cancel
-each other).
-
-## Verify
-
-- Unit tests for `computeBottomSpacer`: 0 when all cards fit; overflow + margin
-  when a card runs past; never negative; honors custom margin; integer output.
-- e2e (real layout): put a comment on the last line of a **viewport-filling**
-  document (short docs won't reproduce — there's empty viewport below the card
-  already), click it, assert the card sits fully within the scroll area's viewport
-  with a positive bottom gap — **without** adding content to the doc. Verify it
-  fails without the fix and passes with it.
-- Regression: a normal mid-document comment shows no extra trailing whitespace
-  (spacer 0).
-
-## Notes for the porter
-
-- Watch for the feedback loop: derive the spacer from document-space
-  (`nudgedTop + measuredHeight`), which is scroll-independent, and clamp ≥ 0.
-- The card's `offsetTop` within the translated column equals its document-space
-  `nudgedTop` (same coordinate space as `scrollTop`) — that's what makes the
-  activation-scroll math line up.
diff --git a/docs/to-improve/10-remove-page-break-indicator.md b/docs/to-improve/10-remove-page-break-indicator.md
deleted file mode 100644
index 8502e95..0000000
--- a/docs/to-improve/10-remove-page-break-indicator.md
+++ /dev/null
@@ -1,56 +0,0 @@
-# 10 — Remove the faux page-break indicator
-
-**Area:** Frontend/CSS (`src/App.css`, guard test) · **Type:** fix
-
-## Problem
-
-Quill paints faux US-Letter page-break lines — a `repeating-linear-gradient`
-background drawing a horizontal rule every "page height" (≈912px) down the
-`.ProseMirror` content box. Because ProseMirror is a continuous-flow editor, that
-rule lands wherever it falls — usually **through the middle of a paragraph**. Users
-read it as a stray horizontal line that can't be selected, can't be deleted,
-doesn't move with the text, and isn't in the saved `.md`. It looks like a glitch.
-
-## What was tried and rejected
-
-Moving the rule out of the text column into **gutter ticks** on the page card was
-attempted first. In the real macOS WKWebView runtime the ticks **still rendered as
-stray lines** (WKWebView rasterizes tiled/positioned gradient backgrounds
-differently than Chromium — sub-pixel seams under CSS `zoom`). A headless-Chromium
-preview said it looked fine; the real app disagreed. So the gutter-tick approach
-was also removed.
-
-## The change
-
-**Remove the page-break indicator entirely.** The document is a continuous
-surface with no page lines.
-
-- Delete the `repeating-linear-gradient` (and any gutter-tick variant) from
-  `.ProseMirror` **and** `.editor-page`. Remove any `:root` tick variables
-  (`--page-tick-*`, `--page-content-height`) that only existed for it.
-- Keep `.ProseMirror { min-height: … }` (≈912px) so a near-empty doc still fills
-  the page card.
-- Remove the now-dead print-suppression rule for the indicator.
-
-## Guard test (lock in the robust end-state)
-
-Add/repoint a CSS-reading guard test asserting **neither** `.ProseMirror` nor
-`.editor-page` carries a `background-image` / `linear-gradient`, with a negative
-control proving the assertion can fail. Guard the conclusion you trust (nothing
-painted), not the clever thing that couldn't be verified.
-
-## Verify
-
-- Guard test green.
-- Real-app check: open a multi-paragraph doc in the built `.app` — no horizontal
-  lines through text, clean continuous surface, near-empty doc still shows a full
-  page card.
-
-## Notes for the porter
-
-- If the public repo wants to _keep_ a page metaphor, the only reliable path is
-  **true pagination** (discrete page elements) — a large architectural change,
-  out of scope here. Short of that, no indicator is the safe default: a CSS
-  background on a continuous editor is glitch-prone in WKWebView wherever it's put.
-- Lesson worth carrying: verify visual/CSS changes in the **real WKWebView
-  runtime**, not a headless-Chromium proxy — the proxy passed both rejected designs.
diff --git a/docs/to-improve/11-comment-placeholder-hint.md b/docs/to-improve/11-comment-placeholder-hint.md
deleted file mode 100644
index 3b219ec..0000000
--- a/docs/to-improve/11-comment-placeholder-hint.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# 11 — Comment composer placeholders should mention @claude
-
-**Area:** Frontend (`AddCommentButton.tsx`, `CommentCard.tsx`) · **Type:** copy / discoverability
-
-## Problem
-
-Typing `@claude` in a comment or reply triggers an AI response, but that's
-invisible from the empty composer. The new-comment box placeholder said only
-`"Add a comment… (Cmd+Enter to post)"` — no hint that `@claude` does anything. The
-reply composer mentioned Claude but inconsistently.
-
-## The change
-
-Reword both composer placeholders to advertise the `@claude` affordance, and keep
-them consistent:
-
-- New-comment composer (`AddCommentButton.tsx`): e.g.
-  `"Add a comment… (@claude to get an AI response)"`.
-- Reply composer (`CommentCard.tsx`): e.g.
-  `"Reply… (@claude to get an AI response)"`.
-
-Pure copy — no behavior change.
-
-## Guard test
-
-Add a small test that reads both component sources and asserts each composer's
-placeholder contains `@claude` (match **all** `placeholder="…"` occurrences in the
-file, not just the first, so a future inserted placeholder can't silently drop the
-hint), with a negative control (a placeholder lacking `@claude` fails the check).
-
-## Verify
-
-- Guard test green.
-- Real-app check: open the comment composer and the reply composer; both
-  placeholders mention `@claude`.
-
-## Notes for the porter
-
-- Final wording is your call; the invariant the test locks is only that both
-  mention `@claude`.
diff --git a/docs/to-improve/12-wider-reading-surface.md b/docs/to-improve/12-wider-reading-surface.md
deleted file mode 100644
index fa70eb9..0000000
--- a/docs/to-improve/12-wider-reading-surface.md
+++ /dev/null
@@ -1,55 +0,0 @@
-# 12 — Wider reading surface (trim the page margins)
-
-**Area:** CSS (`src/App.css` `:root` layout tokens) · **Type:** UX / readability
-
-## Problem
-
-The text column feels cramped. The page card is US-Letter width (`--page-max-width:
-816px`) with large side padding (`--page-padding-x: 96px`) → only **624px** of
-actual text column. The user wants a wider reading surface.
-
-## The change
-
-Widen the text measure by trimming the page side padding. The fork went
-`--page-padding-x: 96px → 64px`, keeping `--page-max-width: 816px` → an **688px
-measure** (~85 characters — comfortable, not sprawling), with **no change to the
-page footprint** (so no new horizontal-scroll risk against the fixed comment
-column).
-
-Constraints to respect:
-
-- **Don't force horizontal scroll.** A wider page competes with the fixed comment
-  column (`--comment-panel-width`, 260px) reserved on the right. Trimming padding
-  (not growing `--page-max-width`) keeps the footprint constant, which is the
-  safe lever. If you'd rather grow `--page-max-width` instead/also, verify
-  `page-width + comment-panel + gutters` still fits the app's **minimum window
-  width** without horizontal scroll.
-- **Leave print/PDF alone.** The `@media print` block flattens the page (width
-  auto, no padding), so the on-screen measure can differ from the US-Letter print
-  width without affecting the PDF. Don't touch the print block.
-- **Don't over-widen.** A very long measure hurts readability as much as a narrow
-  one — aim ~65–90 characters, not "as wide as possible."
-
-The numbers are **tunable** — pick a sensible default and confirm it visually in
-the real app.
-
-## Guard test
-
-Add a small CSS-reading test asserting the widened token holds (e.g.
-`--page-padding-x ≤ 72` and `--page-max-width ≥ 816`), with a negative control
-proving the old cramped 96px would fail. Keeps a later refactor from silently
-reverting the widening.
-
-## Verify
-
-- Guard test green.
-- Real-app check across themes: the reading column is visibly wider and
-  comfortable, no horizontal scrollbar at a normal window size, and Export-as-PDF
-  / print preview is unchanged (still US-Letter).
-
-## Notes for the porter
-
-- This is a one-line token change plus a guard test. The exact final value is a
-  visual judgment — 64px is a reasonable starting point.
-- A user-facing wide/narrow toggle was considered and deferred — a fixed better
-  default is the scope here.
diff --git a/docs/to-improve/README.md b/docs/to-improve/README.md
deleted file mode 100644
index 49e6977..0000000
--- a/docs/to-improve/README.md
+++ /dev/null
@@ -1,80 +0,0 @@
-# Quill — public-repo sync specs
-
-These specs describe improvements made to a downstream fork of Quill that should
-be ported back to the **public GitHub Quill** repo (`github.com/sam-powers/quill`).
-Hand them to a Claude Code session running in a checkout of the public repo.
-
-> **Claude, start here.** You are in a checkout of the public Quill repo. This
-> folder contains a set of independent improvement specs to port into _this_ repo.
-> Read this README, then work through the specs in the "Suggested order" section
-> below — for each one: reproduce the issue if you can, apply the change following
-> _this repo's_ existing conventions (the specs are behavior descriptions, not
-> patches — do not paste code from them verbatim), run the checks listed under
-> "How to use these", and confirm before moving on. Do one spec at a time and
-> pause after each so the maintainer can review. If a spec's "before" state
-> doesn't match what you find here, trust the current code and adapt — the fork
-> diverged from this repo in unrelated ways. Ask if anything is ambiguous rather
-> than guessing.
-
-Each spec is self-contained: problem, root cause, the change to make, and how to
-verify. They are written as **behavior specs, not patches** — the public repo has
-diverged from the fork in unrelated ways (fonts, update-checker, CSP), so apply
-the intent, matching the public repo's own conventions, rather than pasting diffs.
-
-## How to use these
-
-1. Open a Claude Code session in the public Quill checkout (your personal machine,
-   personal account — **not** the internal build).
-2. Feed it one spec at a time, in the order below (independent specs can go in any
-   order; the three "claude CLI resolution" specs are related and best done
-   together).
-3. For each: reproduce the bug first if you can, apply the change, run the repo's
-   existing checks (`npm run typecheck`, `npm run lint`, `npm test`, `npx playwright
-test`, and the Rust checks `cargo test && cargo clippy && cargo fmt --check`),
-   then confirm behavior in a real built app.
-
-## What is DELIBERATELY excluded
-
-None of the internal Brazil/Amazon porting work is in these specs — no build
-wiring, dependency-mirror changes, CSP scrubbing, font vendoring, plugin
-repointing, or removal of the GitHub update-checker. Those are downstream-only.
-These specs are **only** the genuine product/behavior improvements that any Quill
-user benefits from.
-
-Two things to know about provenance:
-
-- The three "claude CLI resolution / PATH" specs (01–03) were discovered because
-  the fork runs as a packaged macOS `.app` launched from Finder, which exposed a
-  minimal-`PATH` environment that a terminal `npm run tauri dev` never hits. They
-  are still real bugs in the public app for anyone who installs and launches the
-  built `.app` — but if the public repo is only ever run via `tauri dev` from a
-  terminal, they may appear not to reproduce. Fix them anyway; installed users hit
-  them.
-- One spec (04, window-destroy capability) references a Tauri **capability grant**.
-  The public repo's capability file may differ; apply the same grant to whatever
-  capability file the public repo uses.
-
-## Specs
-
-| #   | Spec                                                                                                         | Area              | Type    |
-| --- | ------------------------------------------------------------------------------------------------------------ | ----------------- | ------- |
-| 01  | [claude CLI: give the spawned process a working PATH](01-claude-spawn-path.md)                               | Rust backend      | bug     |
-| 02  | [claude CLI: resolve the user's configured binary, not a stale copy](02-claude-resolve-configured-binary.md) | Rust backend      | bug     |
-| 03  | [claude CLI: use an interactive login shell to read PATH](03-claude-interactive-login-shell.md)              | Rust backend      | bug     |
-| 04  | [Window won't close from the unsaved-changes dialog](04-window-close-capability.md)                          | Rust + capability | bug     |
-| 05  | [Deep link opens a doc but leaves the window hidden](05-deep-link-surface-window.md)                         | Rust backend      | bug     |
-| 06  | [Cmd+S (and other menu shortcuts) use stale handlers](06-menu-handler-stale-closure.md)                      | Frontend          | bug     |
-| 07  | [Retry failed @claude replies; gate "Re-link session"](07-claude-reply-retry-ux.md)                          | Frontend          | feature |
-| 08  | [Cancel during full-document review is a no-op](08-review-cancel-fix.md)                                     | Frontend          | bug     |
-| 09  | [Comments below the document's end can't be scrolled into view](09-below-fold-comment-scroll.md)             | Frontend          | bug     |
-| 10  | [Remove the faux page-break indicator](10-remove-page-break-indicator.md)                                    | Frontend/CSS      | fix     |
-| 11  | [Comment composer placeholders should mention @claude](11-comment-placeholder-hint.md)                       | Frontend          | copy    |
-| 12  | [Wider reading surface (trim page margins)](12-wider-reading-surface.md)                                     | CSS               | UX      |
-
-## Suggested order
-
-1. **Specs 01–03 together** (claude CLI resolution — they build on each other).
-2. **04, 05, 06** (small backend/frontend bug fixes, independent).
-3. **07** (retry UX — the largest change).
-4. **08, 09** (review-cancel + below-fold scroll — independent).
-5. **10, 11, 12** (page-break removal, placeholder copy, reading width — cosmetic/small).