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
This commit is contained in:
2026-05-14 22:12:21 +01:00
parent c5460a169c
commit bf1b68275a
2 changed files with 319 additions and 6 deletions

View File

@@ -1,8 +1,8 @@
--- ---
name: v0.1-checklist name: v0.1-checklist
type: release type: release
tags: [release, v0.1, checklist, tester-acceptance, activation-metrics] 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?'. 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." 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 # 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 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. 1. Install Lumotia from the artefact for their platform.
2. Open the app. First-run onboarding starts automatically. 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. 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. 10. Find the dictation again in History via search.
Steps 14 are the cold-setup pass. Steps 510 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. 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 ## 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 - [ ] First-run gate routes anyone with no onboarding-event record through this flow
- [ ] `onboarding_events` SQLite table (`completed_at`, `skipped`, `version`) + migration - [ ] `onboarding_events` SQLite table (`completed_at`, `skipped`, `version`) + migration
- [ ] Onboarding Tauri commands - [ ] 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) - [ ] Time-to-first-capture measurable from the onboarding events (raw signal for activation metrics)
### Release artefacts + trust path ### 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) - [ ] 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 - [ ] 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 ### Quality gates carried forward from Phase A + B
- [ ] `cargo test --workspace` — green - [ ] `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`) - [ ] **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) - [ ] 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) ### Smoke-test matrix (executed against final tagged artefacts)
| Platform | Install | First-run | Capture | Cleanup | Export | History search | Uninstall + reinstall preserves transcripts | | 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) | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | | macOS (Intel, .dmg) | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
| Windows (.msi on Win 11) | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | | 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 ## Activation metrics
@@ -113,7 +154,7 @@ Defined activation:
- **Quality:** Tester accepts or edits at least **one extracted task**. - **Quality:** Tester accepts or edits at least **one extracted task**.
- **Trust:** Tester can articulate **what stays local** if asked. - **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) ### 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. 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) ## 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. To stop ourselves second-guessing under release pressure, these are pinned **not in v0.1**. Reopening any of them moves the ship date.

View File

@@ -0,0 +1,262 @@
---
name: v0.1-ui-hardening
type: release
tags: [release, v0.1, ui, hardening, boundary, no-redesign]
description: "Strict scope boundary for the v0.1 UI hardening pass. Goal: make the first capture flow obvious, calm, responsive and hard to break. NOT a redesign. Lists in-scope items (home clarity, recording-as-sacred-state, post-capture card, settings sanity, error copy, keyboard flow, two-size responsive check, accessibility practical checks) and out-of-scope traps (full redesign, new identity, Garden Inbox, suggested routing, graph view, animation system, Obsidian plugin, cloud UI). Pairs with docs/release/v0.1-checklist.md UI acceptance section."
---
# Lumotia v0.1 UI hardening — scope boundary
**Goal.** Make the first capture flow obvious, calm, responsive and hard to break.
**Not goal.** Make the whole app beautiful. That comes after we have real users telling us what's actually wrong.
The v0.1 UI pass is not there to make Lumotia beautiful. It is there to make the first successful capture inevitable.
The product is already feature-rich. The UI's job in this pass is to **hide that richness until needed** so the tester acceptance flow (`docs/release/v0.1-checklist.md`) is unmistakable.
## Mantra for every UI decision in this pass
Every screen should answer in under 1 second:
- One primary action
- One obvious status
- One safe way back
- No more than 3 visible next actions
If a change adds visual interest without serving that mantra, it does not belong in v0.1. Save it for v0.2.
## Step 0: verify the design-system preview before changing anything
Before any UI change, walk through the existing 20-file preview at `src/design-system/preview/` and classify each item:
- **Already good** — ships in v0.1 unchanged
- **Needs minor v0.1 hardening** — listed in the in-scope sections below
- **v0.2 polish** — defer; track in `v0.2-garden-roadmap.md`
The classification itself is the first deliverable of this pass. Do not rebuild what is already working.
Existing preview files (auditable surface):
| File | Surface | Reuse for |
|---|---|---|
| `colors-accent.html`, `colors-semantic.html`, `colors-surfaces.html`, `colors-text.html`, `colors-zones.html` | Colour tokens | Status pill semantic colours, error-state contrast |
| `components-buttons.html` | Button vocabulary | Primary CTA on Home + post-capture card actions |
| `components-cards.html` | Card vocabulary | **Post-capture card foundation** |
| `components-empty-states.html` | Empty state | Pre-first-recording Home, empty History, empty Tasks |
| `components-inputs.html` | Form controls | Settings + onboarding inputs |
| `components-nav.html` | Navigation | Sidebar / tab patterns; recording-state simplification |
| `components-toasts.html` | Toast vocabulary | Error-state surfacing, save confirmations |
| `spacing-motion.html`, `spacing-radii.html`, `spacing-scale.html`, `spacing-shadows.html` | Spacing tokens | Layout density at 900×700 |
| `type-body.html`, `type-headings.html`, `type-transcript-mono.html` | Typography | Status pill labels, post-capture card content |
| `brand-icons.html`, `brand-wordmark.html` | Brand assets | Header / loading / about |
## In scope (v0.1 hardening pass)
### 1. Home capture clarity
**Symptom this fixes:** "What am I meant to do here?"
The Home / capture screen must answer the four questions a first-time user has on landing, all visible without scrolling, within 1 second:
- What can I do here? → Big record button, impossible to miss
- What is recording? → Status pill at all times: `Ready` / `Recording` / `Transcribing` / `Cleaning` / `Saved`
- What happens next? → Visible affordance to where the recording will go
- Where did my last capture go? → Last-capture preview surfaced on Home
Structure target:
```
Main capture area
- Big record button (primary CTA, unmistakable)
- Currently selected profile + model (read-only summary line)
- Status pill: Ready / Listening / Transcribing / Cleaning / Saved
- Last capture preview (collapsed, click expands)
Now / Tasks
- At most 13 current tasks visible
- MicroSteps visible only when the parent task is selected
Recent
- Last 3 dictations as quick-access cards
- Search shortcut visible
Secondary nav
- History · Tasks · Settings (no more, no less in the main bar)
```
### 2. Recording as a sacred UI state
**Symptom this fixes:** "Did I accidentally click the wrong thing while recording?"
While recording is active, the app simplifies itself. The user has one job — capture their thought — and the UI must not present competing choices.
Hidden or de-emphasised during recording:
- Settings, History, Tasks navigation (secondary nav greys / collapses)
- Advanced controls
- Tag chips, manual-edit affordances
- All secondary CTAs
Visible during recording:
- Recording timer
- Pause / Stop / Cancel (with cancel requiring a confirm — destructive)
- Live transcript stream
- Input level / waveform indicator
Recording is not the moment to present choices.
### 3. Post-capture card (the headline v0.1 UI artefact)
**Symptom this fixes:** "I stopped recording. What now?"
After the user stops dictation, surface one clear card as the landing moment. The card is the visual model future Garden Inbox cards extend, but it ships in v0.1 with display-only behaviour.
**v0.1 post-capture card (display-only):**
- Raw transcript (collapsible, always preserved)
- Cleaned transcript (LLM cleanup result; or rule-based fallback if LLM failed — labelled either way)
- Extracted tasks (frontend rule-based or LLM, surfaced inline)
- MicroSteps if any task is selected
- Actions:
- **Save** (default, already happened; this is the confirmation)
- **Export** (opens native save dialog — Phase 9a flow)
- **Start first MicroStep** (kicks off the 5-min timer — Phase 1 flow)
- **Open in History** (jumps to the history detail view)
**Explicitly NOT in v0.1 (these are v0.2):**
- Suggested title (display the user's title if they set one; otherwise omit the field)
- Suggested type / folder / project / area / person / topic (no routing surface)
- Possible links to existing transcripts (no backlinks)
- Accept / Edit / Park / Archive (no review-card actions)
- Confidence scores (no per-suggestion score surface)
The v0.1 card is "here is what we captured". The v0.2 card extends to "here is where this belongs". Same shell, different ambition.
### 4. First-run onboarding polish
Scope already locked in `v0.1-checklist.md` under "First-run onboarding". This pass adds the UX polish layer:
- Each onboarding step has a single clear next action
- The "test recording" step ships with a pre-supplied prompt so the user knows what to say
- Failure at any step recovers gracefully (no dead-end "something went wrong" screens)
- A skip-to-main option exists for users who fail the tutorial but want to proceed (they show up in known-limitations as the next support burden)
### 5. Settings sanity pass
Group the existing settings into six sections in this order, visible without scrolling on a 900×700 window:
1. **Start Here** — model picker, microphone, language
2. **Transcription** — engine choice, cleanup level, custom vocabulary preview
3. **Models** — download, switch, disk-space readout
4. **Tasks** — energy-aware sequencing toggles, WIP limit
5. **Accessibility**`prefers-reduced-motion`, contrast, typography size, screen-reader hints
6. **Privacy** — local-only badge, AI-use disclosure link, local activation log toggle, data-dir location
7. **Advanced** — everything else, hidden under a click
The full 7-group progressive-disclosure regroup with search box is **deferred to v0.2**. The v0.1 pass is "the basics are findable", not "every setting is grouped beautifully".
### 6. Error-state copy
Every visible error message must:
- Preserve the raw transcript (this is the data-loss contract from Audit 2)
- Explain in plain words what just happened (not "Error: 0x80004005")
- Tell the user what to do next (retry / continue without LLM / see known-limitations entry)
- Never include a stack trace in the user-facing surface (stack traces go to the crash dump file)
Sweep every error surface in the codebase and rewrite to match. Reuse `components-toasts.html` vocabulary for transient errors; reuse card empty-state vocabulary for sustained errors.
### 7. Keyboard flow through the tester acceptance path
The entire 10-step tester acceptance flow must be completable using keyboard only. Minimum keyboard paths:
- Start / stop recording (a sensible shortcut, configurable)
- Pause / resume recording
- Open search (`Ctrl+K` or platform equivalent)
- Move focus through MicroSteps with arrow keys
- Start the 5-min timer from the focused MicroStep
- Save / export from the post-capture card
- Escape closes any modal
- Open Settings from anywhere
Focus ring must be visible on every interactive element at default zoom. No `:hover`-only controls — every action has a keyboard-reachable trigger.
### 8. Responsive test at 900 × 700 and 1440 × 900
These two sizes catch the biggest layout failures without turning this into a responsive-design project. Pass condition:
- **900 × 700 (small desktop / split-screen laptop):** every screen in the tester acceptance flow renders without horizontal scrolling. Sidebar may collapse, content may stack — but no information is hidden behind a scrollbar.
- **1440 × 900 (typical laptop):** every screen looks comfortable, not cramped. Three-column layouts (sidebar + main + right panel) work where designed.
Ultrawide, mobile-portrait, and split-screen edge cases are explicitly **deferred to v0.2** unless a tester actively reports them.
### 9. Accessibility practical checks (WCAG-style, not certification)
The pass-bar for v0.1 is "the core flow is not hostile", not "fully WCAG 2.2 AA conformant". Concrete checks against the WCAG framework's perceivable / operable / understandable / robust pillars:
- Tester flow completable by keyboard alone (operable)
- Focus visible on every interactive element (operable)
- Recording state not communicated by colour alone (perceivable)
- `prefers-reduced-motion` respected app-wide (operable)
- Text contrast acceptable in both light and dark modes (perceivable) — spot-check, not full audit
- Status pill labels use literal words, not just icons (understandable)
- Form labels associated with their inputs (robust)
The full WCAG 2.2 AA conformance audit is v0.2.
### 10. Status labels everywhere
Use plain status pills for every async state. Do not rely on colour, icons, or animation alone. The pill labels:
- `Ready` (idle, ready to record)
- `Recording`
- `Paused`
- `Transcribing`
- `Cleaning` (LLM cleanup in flight)
- `Extracting tasks` (LLM extraction in flight)
- `Saved`
- `Exported`
- `Needs review` (for any failure that left data in an editable state)
- `Failed safely` (for the documented LLM-failure paths — see Audit 2 / known-limitations)
The `StatusPill` component is a new build (no existing class found in survey). Add it to `src/design-system/preview/components-status-pills.html` so it joins the catalogued surface.
## Out of scope (the traps to refuse)
Each item below is a real temptation. Each ships in v0.2 or later. Touching any of them in this pass moves the v0.1 ship date.
- **New visual identity.** No new colour palette, no new typography choices. The brand book v3 PDF in `outputs/lumotia/lumotia-brand-book-v3.pdf` is the locked source; v0.1 is "use what's locked", not "revisit what's locked".
- **New navigation model.** Sidebar + History/Tasks/Settings is the v0.1 nav. Tabbed top nav, command palette as primary nav, gesture-based nav — all v0.2 or later.
- **Garden Inbox.** Review cards, suggested routing, accept/edit/park/archive, related notes, backlinks, people-project-topic detection — all v0.2 marquee. The v0.1 post-capture card displays existing data only.
- **Suggested routing.** Folder, project, area, person, topic — all v0.2 ontology work.
- **Backlinks.** No "you mentioned this before" surface in v0.1.
- **Graph view.** No force-directed graph, no concept map, no entity visualisation.
- **Canvas view.** No spatial / freeform layout.
- **New animation system.** Existing entrance animations (sparkline, badge, post-capture card surfacing) only. No custom motion choreography, no Lottie, no parallax.
- **Full SettingsPage 7-group redesign.** The 6-section sanity pass above is the v0.1 ceiling. The full regroup with progressive disclosure + search box is v0.2.
- **Obsidian plugin.** Markdown export already exists. The plugin itself is a v0.2 ecosystem play.
- **Cloud / provider UI.** `lumotia-cloud-providers` stays compiled-but-dormant per the v0.1 checklist.
## Definition of done for the UI hardening pass
This pass is complete when:
1. The design-system preview classification is filed (step 0)
2. Every in-scope item ships a focused commit referencing this doc
3. The UI acceptance section in `v0.1-checklist.md` is fully ✅
4. The 10-step tester acceptance flow has been walked end-to-end at 900 × 700 with keyboard only
5. The post-capture card is on disk, surfacing after every recording
6. The `StatusPill` component is in `src/design-system/preview/components-status-pills.html` and used everywhere an async state appears
7. The error-state sweep has touched every visible error surface
8. No item from the out-of-scope list has been started
## Cross-references
- `docs/release/v0.1-checklist.md` — the UI acceptance section pairs with this doc
- `docs/release/v0.2-garden-roadmap.md` — Garden Inbox extends the post-capture card pattern
- `docs/release/how-lumotia-is-built.md` — references the dogfood drill + atomiser audit; UI hardening adds the user-facing trust layer
- `src/design-system/preview/` — the 20-file existing visual vocabulary to inherit from
- `outputs/lumotia/lumotia-brand-book-v3.pdf` — locked brand identity (not opened in this pass)