Lumotia/docs/release/v0.1-checklist.md

---
name: v0.1-checklist
type: release
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

**Locked scope:** v0.1 ships the stable local capture product. Garden Inbox is v0.2. Cloud providers stay dormant. OEM verification stays v0.2+. See `docs/release/v0.2-garden-roadmap.md` for what comes next.

**Tag-eligible when:** every item below is ✅ or explicitly waived in the linked known-limitations row.

## 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. 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.
3. Grant microphone permission via the OS prompt the onboarding surfaces.
4. Pick or download a speech model (sensible default suggested).
5. Test recording (a short pre-supplied prompt the onboarding asks them to read).
6. See the live transcript appear.
7. Stop dictation. See the cleaned transcript.
8. Extract one task from the transcript.
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

### Product surface (already shipped, verify via Phase A/B/C dogfood passes)

- [ ] Phases 1–8 functional on Linux primary, parity-tested on macOS + Windows
- [ ] Phase 9a — native OS save-dialog Markdown export (single + bulk + collision-suffixing)
- [ ] Phase 9b — LLM content tags with manualTags promote-on-click
- [ ] Phase 9d — sparkline + badge a11y + `prefers-reduced-motion` respect
- [ ] Phase 9c — Settings sanity pass: Start Here / transcription basics / model picker / privacy / accessibility / advanced (full 7-group regroup deferred to v0.2)

### First-run onboarding (engine architecture Phase F — promoted to v0.1 must-ship)

- [ ] Onboarding steps wired in `src/lib/pages/FirstRunPage.svelte`: permissions → model check/download → test recording → cleaned transcript surfaced → "you're ready" → main UI
- [ ] 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
- [ ] **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

- [ ] Three-way version sync: `Cargo.toml` workspace + `src-tauri/Cargo.toml` + `package.json` + `tauri.conf.json` all on `0.1.0`
- [ ] `CHANGELOG.md` seeded with Phase 1–8 outcomes in end-user voice (not commit-log style)
- [ ] Release notes drafted in plain language (one page max, no jargon)
- [ ] Windows code-signing certificate sourced + signing wired into `tauri build`
- [ ] macOS notarisation + Gatekeeper acceptance via Apple Developer ID (or documented Gatekeeper-warning workaround if notarisation isn't available)
- [ ] Linux AppImage SHA-256 checksum published alongside artefact + GPG signature optional
- [ ] "What warning you may see on first install" documented per platform (SmartScreen / Gatekeeper)
- [ ] CI green on Linux/macOS/Windows artefact builds on tag push
- [ ] Manual smoke-test on each platform artefact before public release (see matrix below)

### Documentation surface

- [ ] `docs/release/v0.1-known-limitations.md` complete + user-readable
- [ ] `docs/release/how-lumotia-is-built.md` complete + linked from README
- [ ] 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
- [ ] `cargo fmt --check` — clean
- [ ] `cargo clippy --workspace --all-targets -- -D warnings` — clean
- [ ] `npm run test` — green
- [ ] `npm run check` — 0 errors / 0 warnings
- [ ] `scripts/dogfood-rebrand-drill.sh` — 8/8 probes pass (carry from Phase A)
- [ ] Rust toolchain still pinned to `rust-toolchain.toml`
- [ ] npm dev deps still exact-pinned

### Trust + security boundary verified

- [ ] MCP surface read-only / stdio-only / no write tools confirmed (see Audit 1 in `docs/release/how-lumotia-is-built.md`)
- [ ] LLM failure paths preserve raw transcript / extract tasks via fallback / never block export (see Audit 2 in `docs/release/how-lumotia-is-built.md`)
- [ ] `lumotia-cloud-providers` crate compiles but has no UI exposure (KI-04)
- [ ] `npm audit signatures` runs in `run.sh` and on CI before any tag

### Release-blocker resolution

- [ ] **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 |
|---|---|---|---|---|---|---|---|
| Linux (AppImage on Fedora) | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
| Linux (AppImage on Ubuntu LTS) | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
| macOS (Apple Silicon, .dmg) | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
| macOS (Intel, .dmg) | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
| Windows (.msi on Win 11) | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |

### 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

### Private beta (closed, ~20 testers)

Defined activation:

- **Activation:** Tester completes their first recording within **3 minutes** of opening the app for the first time.
- **Core value:** Tester creates **3 useful captures** in the first 24 hours.
- **Retention:** Tester returns within **7 days** and uses history / search / review.
- **Quality:** Tester accepts or edits at least **one extracted task**.
- **Trust:** Tester can articulate **what stays local** if asked.

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)

Defined pass-bar:

- Can **20 strangers** install Lumotia successfully?
- Can **15 of them** complete first capture?
- Can **10 of them** use it twice within a week?
- Can **5 of them** say they would pay **£39** for a Founding Licence?

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.

- Garden Inbox / review cards / suggested routing → **v0.2**
- Engine Phase B filter-chain refactor → **v0.2**
- Engine Phase C vocabulary crate → **v0.2**
- Engine Phase D model warmup coordinator → **v0.2**
- Engine Phase E dictionary quick-add → **v0.2**
- Engine Phase G OpenAI Whisper API provider → **v0.2 at earliest, with BYOK / off-by-default / never-required / clearly-labelled framing**
- Engine Phase I OEM verification → **v1.0 commercial track**
- Engine Phase J full degraded-mode indicator → **v0.2** (data-loss path closed in v0.1 per Audit 2; the UI-wedge case is documented in known-limitations)
- Full SettingsPage 7-group regroup → **v0.2**
- Rust-side OS-activity watcher for nudges → **v0.2 if ever**
- Obsidian plugin → **v0.2 ecosystem play**
- Mobile companion → not on any current track
- Cloud sync → not on any current track

## Pre-tag verification (the morning of)

In order, before `git tag v0.1.0`:

1. Re-run all quality gates fresh on a clean checkout.
2. Re-run `scripts/dogfood-rebrand-drill.sh` against a freshly-built binary.
3. Re-execute the 10-step tester acceptance flow personally on Linux.
4. Confirm the smoke-test matrix is fully green for the platforms we're announcing.
5. Confirm known-limitations doc has no item marked "TBD" or "pending decision".
6. Confirm `CHANGELOG.md` + release notes are user-readable, not commit-log dumps.
7. Tag, push to both remotes, watch CI complete the per-platform builds, smoke-test one artefact per platform from the CI output.

If any step fails, the day's ship is off. Reopen, fix, repeat.