agent: lumotia — Pass 1 v0.1 checklist refinements + Pass 2 v0.1 UI hardening boundary doc

Operationalises the ChatGPT review of the v0.1 release-doc set into two
related landings. Both bounded; no Garden Inbox work, no architecture
refactor, no full redesign.

PASS 1 — v0.1-checklist.md refinements
=======================================

Seven targeted edits to the existing checklist:

1. Cold setup vs warm activation split. Tester acceptance test was
   conflating model-download time (variable, network-dependent) with
   UX-controlled flow time. Two-phase pass:
     - Cold setup: install → onboarding → ready-to-record (no time bound)
     - Warm activation: model-ready → first recording within 3 minutes
   Steps 1-4 are cold; 5-10 are warm.

2. Migration-aware onboarding wording. "Skip-onboarding path for users
   who already have transcripts on disk" → "Migration-aware onboarding:
   existing users with valid data are not forced through first-run, but
   can launch the tutorial manually from Settings → Help."

3. UI acceptance section. New testable items between Documentation
   surface and Quality gates — turns "redo the UI" into measurable
   requirements:
     - Main capture action visible <1s on Home
     - Recording state not communicated by colour alone
     - 10-step flow completable at 900×700 + keyboard only
     - Destructive actions reversible or confirmed
     - Every async state has sidebar status chip feedback
     - Error states preserve raw transcript + plain-words next step
     - Settings Start Here / Privacy / Accessibility findable
     - Focus ring visible everywhere
     - prefers-reduced-motion respected
     - WCAG AA contrast spot-check both modes
     - Post-capture card surfaces (display-only; NOT Garden Inbox)

4. Supported platforms scope. New subsection before smoke-test matrix
   explicitly naming:
     - Primary (must work end-to-end): Linux Fedora + Ubuntu LTS
     - Best-effort (announced if smoke-tested): macOS Apple Silicon,
       Windows 11
     - Not announced unless smoke-tested: macOS Intel

5. P0/P1/P2 smoke-test severity replacing "any ❌ blocks tag":
     - P0 — blocks tag (tester spine on a primary platform)
     - P1 — ships only with explicit known-limitation entry
     - P2 — does not block private beta (not-announced platform / v0.2
       feature)
   Pre-tag verification confirms no unresolved P0 or undocumented P1.

6. "Telemetry" → "local activation log". Re-worded the activation
   metrics capture mechanism. Word choice deliberate — privacy-conscious
   audience reacts to "telemetry" itself. Surface: Settings →
   Diagnostics → Activation log. Nothing sent automatically.

7. Support burden signal. New activation-metric subsection covering
   the AI-assisted-indie risk that every issue becomes a support call:
     - Self-service rate ≥ 70% (issues filed to bug tracker, not inbox)
     - Diagnostic bundle (logs + system info + crash dumps; skips
       transcript content + audio by default)
     - Top-3 setup failures documented after first 5 testers

PASS 2 — v0.1-ui-hardening.md
==============================

New strict-boundary doc at docs/release/v0.1-ui-hardening.md (262
lines). Anchored on the line:

  The v0.1 UI pass is not there to make Lumotia beautiful. It is there
  to make the first successful capture inevitable.

Step 0 (before any code change): walk the 20 existing
src/design-system/preview/ files and classify each item as
already-good / needs-v0.1-hardening / v0.2-polish. Don't rebuild what
works. Inventory table inline in the doc cross-references each preview
file to the in-scope items below.

IN SCOPE (10 items, each testable):
  1. Home capture clarity — big record button, status pill, last-capture
     preview, capped Now/Tasks at 1-3 visible
  2. Recording as sacred UI state — hide settings/history/advanced
     during capture; show only timer/pause/stop/cancel + live transcript
     + level meter
  3. Post-capture card — the v0.1 headline UI artefact. Display-only
     surface of raw + cleaned + tasks + microsteps + 4 actions
     (Save/Export/StartFirstMicroStep/OpenInHistory). Explicitly NOT
     Garden Inbox: no routing, no accept/edit/park/archive, no
     backlinks, no confidence scores
  4. First-run onboarding polish — single clear next action per step,
     pre-supplied prompt for test recording, graceful failure recovery,
     skip-to-main escape hatch (tracked as known-limitations follow-up)
  5. Settings sanity pass — 6 sections in order: Start Here /
     Transcription / Models / Tasks / Accessibility / Privacy / Advanced.
     Full 7-group progressive-disclosure regroup deferred to v0.2
  6. Error-state copy sweep — every error preserves raw transcript,
     explains in plain words, says next user action, no stack traces
     user-facing
  7. Keyboard flow — entire 10-step tester acceptance completable by
     keyboard only, focus ring visible, no hover-only controls
  8. Responsive at 900×700 + 1440×900 ONLY — ultrawide / mobile / split-
     screen deferred to v0.2 unless a tester reports them
  9. Accessibility practical checks (WCAG-style, not certification) —
     keyboard, focus, not-colour-alone, reduced motion, contrast spot-
     check, literal-words status labels, form-label association
  10. Status labels everywhere — new StatusPill component (no existing
     class found in survey); add to design-system/preview/components-
     status-pills.html. Pill states: Ready / Recording / Paused /
     Transcribing / Cleaning / Extracting tasks / Saved / Exported /
     Needs review / Failed safely

OUT OF SCOPE (the traps to refuse — each ships in v0.2 or later):
  - New visual identity (brand book v3 PDF is locked)
  - New navigation model
  - Garden Inbox (review cards, routing, accept/edit/park/archive,
    related notes, backlinks, P-P-T detection)
  - Suggested routing
  - Backlinks
  - Graph view
  - Canvas view
  - New animation system
  - Full SettingsPage 7-group redesign
  - Obsidian plugin
  - Cloud / provider UI

Plus a "Definition of done" with 8 specific completion criteria, and
cross-references to checklist + Garden roadmap + how-built + design-
system preview + locked brand book.

VERIFICATION
============
- cargo fmt --check: clean (no Rust touched)
- All four release docs cross-reference cleanly
- No new tests required (boundary docs, not code)
- v0.1 ship gate unchanged in shape, sharpened in detail

docs/release/v0.1-checklist.md

@@ -1,8 +1,8 @@
 ---
 name: v0.1-checklist
 type: release
-tags: [release, v0.1, checklist, tester-acceptance, activation-metrics]
-description: "Source of truth for 'are we allowed to ship v0.1?'. The must-ship list, the 10-step tester acceptance test, the activation metrics for private beta + v0.1, signing/notarisation status, and the per-platform smoke-test matrix. Updated whenever an item lands."
+tags: [release, v0.1, checklist, tester-acceptance, activation-metrics, ui-acceptance, support-burden]
+description: "Source of truth for 'are we allowed to ship v0.1?'. Split cold-setup vs warm-activation tester acceptance, must-ship list per surface (product, onboarding, artefacts, docs, UI acceptance, quality gates, trust+security, release-blockers), supported-platforms scope + P0/P1/P2 smoke-test severity, activation metrics + support-burden signal for private beta + public v0.1, explicit out-of-scope list, pre-tag verification sequence. Pairs with docs/release/v0.1-ui-hardening.md for the UI scope boundary."
 ---
 
 # Lumotia v0.1 release checklist
@@ -13,7 +13,13 @@ description: "Source of truth for 'are we allowed to ship v0.1?'. The must-ship
 
 ## The tester acceptance test (private beta spine)
 
-The product is ready when a stranger can complete this flow on a fresh install, on their primary platform, without coaching. Time it: if it takes more than ten minutes including the model download, the onboarding needs more work.
+The product is ready when a stranger can complete this flow on a fresh install, on their primary platform, without coaching. The flow is split into two measurable phases because the first depends on connection + hardware (model download) and the second depends purely on UX quality.
+
+**Cold setup pass.** A tester can install Lumotia, complete onboarding, and reach the "Ready to record" state without coaching. No hard time bound — the model download is the dominant variable. Pass condition: the tester is not confused at any step; if they would have given up, the step is a failure.
+
+**Warm activation pass.** Once the model is ready, the tester completes their first real recording within **3 minutes** of opening the app. This measures the part of the flow Lumotia controls.
+
+The full ten-step flow:
 
 1. Install Lumotia from the artefact for their platform.
 2. Open the app. First-run onboarding starts automatically.
@@ -26,6 +32,8 @@ The product is ready when a stranger can complete this flow on a fresh install,
 9. Break the task into MicroSteps and start a 5-minute timer on the first one.
 10. Find the dictation again in History via search.
 
+Steps 1–4 are the cold-setup pass. Steps 5–10 are the warm-activation pass.
+
 Every step has a green path. Every step has a clearly-named failure mode in the known-limitations doc. No step depends on a feature that's marked v0.2 or later.
 
 ## Must-ship
@@ -44,7 +52,7 @@ Every step has a green path. Every step has a clearly-named failure mode in the
 - [ ] First-run gate routes anyone with no onboarding-event record through this flow
 - [ ] `onboarding_events` SQLite table (`completed_at`, `skipped`, `version`) + migration
 - [ ] Onboarding Tauri commands
-- [ ] Skip-onboarding path for users who already have transcripts on disk (post-rebrand migration)
+- [ ] **Migration-aware onboarding:** existing users with valid data are not forced through first-run, but can launch the tutorial manually from the Settings → Help section
 - [ ] Time-to-first-capture measurable from the onboarding events (raw signal for activation metrics)
 
 ### Release artefacts + trust path
@@ -66,6 +74,23 @@ Every step has a green path. Every step has a clearly-named failure mode in the
 - [ ] Privacy + AI-use disclosure page (what stays local, what optionally reaches the network, what NEVER leaves the machine)
 - [ ] README updated for v0.1 launch: install paths per platform, first-run expectations, where to file issues
 
+### UI acceptance (the v0.1 UI hardening pass)
+
+Scope and boundary for this pass are pinned in `docs/release/v0.1-ui-hardening.md`. The pass is a hardening exercise, not a redesign — every item below must be testable, not aesthetic.
+
+- [ ] Main capture action is visible within 1 second of landing on Home (no hover or scroll required)
+- [ ] Recording state is communicated without relying on colour alone (literal status pill: Ready / Recording / Paused / Transcribing / Cleaning / Saved / Failed safely)
+- [ ] Tester acceptance flow (10 steps) can be completed at **900 × 700** without horizontal scrolling
+- [ ] Tester acceptance flow can be completed using keyboard only — no mouse touched
+- [ ] All destructive / cancel actions are reversible (soft-delete + restore) or guarded by explicit confirmation (e.g. type-the-word DELETE)
+- [ ] Every async state has visible feedback in the sidebar status chip: downloading model / transcribing / cleaning / extracting tasks / exporting
+- [ ] Error states preserve the raw transcript and explain the next user action in plain words (not stack traces, not codes)
+- [ ] Settings has a visible **Start Here** section, with **Privacy** and **Accessibility** sections findable from the first sidebar group (no drilling into Advanced)
+- [ ] Focus ring is visible on every interactive element at standard zoom
+- [ ] `prefers-reduced-motion` respected app-wide (carry from Phase 9d sparkline + badge polish)
+- [ ] Text contrast acceptable in both light and dark mode (WCAG AA spot-check, not full audit)
+- [ ] Post-capture card surfaces after every recording: raw transcript / cleaned transcript / extracted tasks / MicroSteps / Save-or-Export / Start-first-MicroStep / Open-in-History. **Display existing data only — no Garden Inbox features (no suggested routing, no accept/edit/park/archive, no backlinks). That is v0.2.**
+
 ### Quality gates carried forward from Phase A + B
 
 - [ ] `cargo test --workspace` — green
@@ -89,6 +114,14 @@ Every step has a green path. Every step has a clearly-named failure mode in the
 - [ ] **RB-08** macOS App Nap power-assertion runtime verification on Apple Silicon (resolve or document with workaround per `KI-01`)
 - [ ] Decision recorded per platform-power-assertion item: KI-02 Linux idle inhibit, KI-03 Windows sleep prevention — fix-if-tiny vs document-as-known-limitation (see known-limitations doc)
 
+### Supported platforms for v0.1
+
+Promising five platform paths we can't actually support is the exact "AI slop" trap the trust page is meant to prevent. Concrete scope:
+
+- **Primary (must work end-to-end before tag):** Linux (AppImage on Fedora, AppImage on Ubuntu LTS)
+- **Best-effort (announced if smoke-tested):** macOS Apple Silicon (`.dmg`), Windows 11 (`.msi`)
+- **Not announced unless smoke-tested:** macOS Intel — included in the matrix below but a `P2` failure (see severity matrix) blocks announcement, not tag
+
 ### Smoke-test matrix (executed against final tagged artefacts)
 
 | Platform | Install | First-run | Capture | Cleanup | Export | History search | Uninstall + reinstall preserves transcripts |
@@ -99,7 +132,15 @@ Every step has a green path. Every step has a clearly-named failure mode in the
 | macOS (Intel, .dmg) | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
 | Windows (.msi on Win 11) | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
 
-A single ❌ in any cell is a tag-blocker.
+### Smoke-test severity (replaces "any ❌ blocks tag")
+
+Not every failure has equal weight. Classify each ❌ at the moment it appears.
+
+- **P0 — blocks tag.** Affects the tester acceptance spine on a primary platform: install / first-run / capture / cleanup / export / history search / data preserved across reinstall. A single P0 stops the day's ship.
+- **P1 — ships only with explicit known-limitation entry.** Affects a supported feature on a best-effort platform, OR a non-spine feature on a primary platform. Entry must land in `docs/release/v0.1-known-limitations.md` with workaround.
+- **P2 — does not block private beta.** Affects a not-announced platform (e.g. macOS Intel without a smoke-tester), OR a v0.2-flagged feature. Tracked, not gated.
+
+Severity is recorded next to each ❌ in the matrix above. The pre-tag verification step confirms no unresolved P0 or undocumented P1.
 
 ## Activation metrics
 
@@ -113,7 +154,7 @@ Defined activation:
 - **Quality:** Tester accepts or edits at least **one extracted task**.
 - **Trust:** Tester can articulate **what stays local** if asked.
 
-Capture mechanism: opt-in anonymous local-only telemetry (`onboarding_events` table + a tiny `lumotia_events` table for first-capture / first-export / first-search events). No exfiltration. The tester reads these themselves and reports back qualitatively.
+Capture mechanism: an optional **local activation log** stored on-device. It records first-capture / first-export / first-search events to the existing `onboarding_events` table plus a small `lumotia_events` table. Nothing is sent automatically. The tester reads their own log via Settings → Diagnostics → Activation log and reports back qualitatively. Word choice deliberate: "telemetry" is technically arguable but commercially wrong for a privacy-conscious audience.
 
 ### Public v0.1 launch (open download)
 
@@ -126,6 +167,16 @@ Defined pass-bar:
 
 If we don't hit these numbers, the answer is iteration on first-run + clarity-of-pitch, not feature additions.
 
+### Support burden signal
+
+For an AI-assisted indie app, every issue that becomes a support call is a tax on the founder's time. Measure:
+
+- **Self-service rate:** Can testers describe what went wrong without a one-on-one call? Target: ≥ 70 % of issues filed against the bug tracker, not the inbox.
+- **Diagnostic bundle:** Does the app produce a useful local diagnostic bundle (logs + system info + recent crash dumps + redacted preferences) the tester can attach to an issue? Bundler must skip transcript content and audio files by default.
+- **Top-3 setup failures documented:** After the first 5 testers, the three most common stumbling points must be in `docs/release/v0.1-known-limitations.md` with explicit workarounds.
+
+This is a release metric, not a code metric. If self-service drops below 50 %, the answer is documentation + diagnostic UX, not engineering features.
+
 ## Out of scope for v0.1 (explicit non-goals)
 
 To stop ourselves second-guessing under release pressure, these are pinned **not in v0.1**. Reopening any of them moves the ship date.