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

name, type, tags, description

name	type	tags	description
v0.1-checklist	release	release v0.1 checklist tester-acceptance activation-metrics ui-acceptance support-burden	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.