agent: lumotia — v0.1 release-completion run
Some checks failed
check / cargo check (macos-latest) (push) Has been cancelled
check / cargo check (ubuntu-22.04) (push) Has been cancelled
check / cargo check (windows-latest) (push) Has been cancelled
check / svelte build + lint (push) Has been cancelled

Closes the code-side v0.1 ship gate. All quality gates green:
cargo fmt/clippy/test (~327 tests), npm check (0/0), vitest 13/13,
scripts/dogfood-rebrand-drill.sh 8/8.

Phase F — first-run onboarding promoted to v0.1
- FirstRunPage with skip-to-main + failure recovery + event recording
- Six onboarding commands (record/list/has-completed + lumotia_events)
- Storage migration v17 (onboarding_events + lumotia_events tables)

UI hardening (in-scope items from v0.1-ui-hardening.md)
- StatusPill + PostCaptureCard components, 21st preview entry
- Sidebar recording-as-sacred-state (opacity + aria-disabled, reduced-motion)
- Settings 6-section regroup + Help section + Activation log + Privacy toggle
- Error-state copy sweep (DictationPage + SettingsPage, plain-language)
- Global :focus-visible rule, textarea outlines restored
- Ctrl+K / Ctrl+, / Escape bindings in +layout

LLM resilience
- rule_based_extract_tasks (regex-free imperative-verb extractor) +
  extract_tasks_with_fallback wrapper — task extraction never returns zero
- tokio::time::timeout(120s) wraps cleanup/tags/tasks commands

Release artefacts
- LICENSE (canonical AGPL-3.0), CHANGELOG (Keep-a-Changelog format)
- v0.1-release-notes, privacy-and-ai-use, install-warnings,
  tester-onboarding-kit, tester-acceptance-runbook, code-signing-setup,
  apple-silicon-rb08-runbook, virtual-audio-setup, v0.1-contrast-audit
- Workspace versioning + AGPL spdx; npm exact-pin (10 ranges removed)
- AppImage SHA-256 sidecar in build.yml
- README v0.1 section + Reporting-issues; canonical repo slug

Closure pass — items moved from human-required to code-complete
- KI-02 Linux idle inhibit: zbus 5 → org.freedesktop.login1.Manager.Inhibit
- KI-03 Windows sleep prevention: SetThreadExecutionState(ES_CONTINUOUS|...)
- acquire/release_idle_inhibit Tauri commands, wired in DictationPage
- Diagnostic-bundle frontend wire-up (Settings → Help button)
- WCAG-AA contrast fix via .btn-filled-text utility (no token changes)
- 8 destructive-action sites wrapped in plain-language confirm() guards
- KNOWN-ISSUES.md + v0.1-known-limitations.md updated (KI-02/03 fixed)

Scripts
- pre-tag-verify.sh, tag-day.sh, smoke-linux + driver
- parse-diagnostic-bundle.sh, parse-activation-log.py

Per-item audit trail: docs/release/v0.1-completion-status.md
Remaining: W-01…W-08 (signing certs, hardware probes, smoke matrix,
tester recruitment) — see docs/release/v0.1-known-limitations.md.
This commit is contained in:
2026-05-15 06:59:08 +01:00
parent bf1b68275a
commit 3770815fbf
77 changed files with 8697 additions and 1017 deletions

View File

@@ -0,0 +1,139 @@
---
name: tester-onboarding-kit
type: release
tags: [release, v0.1, testers, onboarding, email-template, feedback]
description: "Recruitment email template, platform targets, day-3 check-in script, and feedback-collection protocol for the Lumotia v0.1 private beta (~20 testers)."
---
# Tester onboarding kit
## Inviting a tester
Paste this into Gmail. Fill in the three variables. Send from your personal address, not a mailing list.
```
Subject: Lumotia v0.1 — would you try it for me?
Hi {{NAME}},
I'm shipping v0.1 of Lumotia, a local-first dictation + task-capture desktop app.
Local-first means everything runs on your device. No cloud, no telemetry.
Would you install it on your {{PLATFORM}} and try the 10-step getting-started?
Should take 1015 minutes.
Download: {{DOWNLOAD_URL}}
First-install warnings (SmartScreen / Gatekeeper): https://github.com/jakeadriansames/lumotia/blob/main/docs/release/install-warnings.md
What to do at each step: docs/release/tester-acceptance-runbook.md in the repo
What I'm looking for:
- Did anything confuse you?
- Did anything break?
- Did the cleanup and task extraction make sense?
- Would you use it again next week?
Reply with a few sentences when you're done. No form, no survey.
Thanks,
Jake
```
Variables:
- `{{NAME}}` — first name
- `{{PLATFORM}}` — "Linux", "macOS (Apple Silicon)", or "Windows 11"
- `{{DOWNLOAD_URL}}` — direct link to the platform artefact from the GitHub release
## How many testers, on which platforms
Target: 20 testers across three platforms. Bias toward Linux — it is the primary platform, bugs surface fastest, and iteration is quickest.
| Platform | Target count | Priority |
|---|---|---|
| Linux (Fedora or Ubuntu) | 810 | Primary — recruit first |
| macOS Apple Silicon | 57 | Best-effort — needed for RB-08 verification |
| Windows 11 | 35 | Best-effort |
For week 1 of private beta, 57 testers total across all platforms is realistic. The public-launch metric (20 strangers, post-tag) is separate.
When recruiting, prefer people who:
- Actually dictate or take notes for work
- Are comfortable with "this is pre-release software"
- Will reply honestly if something breaks (not just go quiet)
Avoid recruiting anyone who will feel obligated to say it's great.
## Day-3 check-in (if no reply)
Send this if a tester hasn't replied after three days:
```
Hi {{NAME}},
Just checking in on the Lumotia install. If you got stuck or something broke,
tell me what you saw — that is the most useful feedback I can get right now.
If you didn't get a chance to try it, no worries. Let me know and I'll follow
up later or remove you from the list.
Jake
```
Do not send a second nudge after this. Silence after two messages means the install failed silently or life happened.
## Feedback collection
**Routing replies.** Every reply goes into one of two places:
1. Real bug or confusing UX — add to `docs/release/v0.1-known-limitations.md` under "Reporting issues" or open a GitHub issue.
2. Deferred or unclear — add to a private scratch file (`docs/private/v0.1.1-deferred-notes.md`, not committed). Do not let it sit in your inbox.
After the first five replies: identify the three most common stumbling points and add workarounds to `docs/release/v0.1-known-limitations.md`. This is a required metric (see v0.1-checklist.md "Support burden signal").
**Activation log.** Ask testers who are comfortable to optionally share their activation log after three days of use: Settings → Privacy → Activation log. They paste the table into their reply. This is fully local and opt-in — never require it.
**Target state.** At least 70% of issues should be self-service (tester can describe what went wrong without a call). If you drop below 50%, improve docs and the diagnostic bundle flow before recruiting more testers.
## Once a tester replies
When a tester sends a reply that includes an activation log or a diagnostic bundle, use the parser scripts to extract actionable information in under a minute.
### Parsing an activation log
Testers paste their activation log table from Settings → Privacy → Activation log. Save the pasted content to a file and run:
```sh
python3 scripts/parse-activation-log.py path/to/tester-activation.json
```
Or if they pasted a plain table (not JSON), pipe it through `--paste`:
```sh
pbpaste | python3 scripts/parse-activation-log.py --paste # macOS
xclip -o | python3 scripts/parse-activation-log.py --paste # Linux
```
The script prints a one-screen summary covering all five activation metrics:
- **Activation** — was first capture within 3 min of opening the app?
- **Core value** — did they get ≥ 3 useful captures in the first 24 hours?
- **Retention** — did they return within 7 days?
- **Quality** — did extracted tasks get accepted/edited? (`?` — follow up qualitatively)
- **Trust** — can they articulate what stays local? (`?` — follow up qualitatively)
Items marked `?` are not in the activation log. Follow up with a direct question per the tester acceptance runbook.
### Parsing a diagnostic bundle
Testers who hit a reproducible bug can use Settings → About → Save diagnostic bundle to generate a `.zip`. They attach it to their reply. Run:
```sh
./scripts/parse-diagnostic-bundle.sh path/to/tester-bundle.zip
```
The script:
1. Checks the bundle passed the redaction deny-list (no audio, no transcripts, no `.db` files). A `FAIL` verdict means the bundler has a bug — do not share the bundle further.
2. Prints a content inventory, log error summary (top 3 patterns), and the non-secret preference values.
3. Exits non-zero if any check fails, so it can be piped into a CI-style workflow.
Both scripts require no installation beyond Python 3 (stdlib only) and `unzip` + `jq` (for the shell script; jq falls back to grep-based extraction if missing).