Micro assistant: ordered delivery and reliability checklist

Keep the web light. Home is the assistant workspace; Inbox holds Messages / Scheduled / Saved and New message. Current top navigation is Home / Account / Admin / Inbox / Logout; there is no sidebar or Recent list. Blog is in the footer. Clients and tokens are secondary Account destinations. No service dashboard or extra primary destination for each capability.

Priority after v2.1.0

1. Delivery and notification reliability: #1823 and #1808, with restart and two-account verification. Privacy, account isolation and verified recovery (#1653, #1811, #1458) remain constraints on this work.
2. Sustainable subscriptions and pricing: #1867, one allowance for app and API with optional top-ups.
3. Prove one useful personal app end to end: #1646, using the existing services and output contract #1801.

Groups (#1821), voice (#1582) and personal-front-door proposals (#1589) remain later work. Do not expand navigation to expose them in advance.

Detailed delivery checklist

Work through these tasks in order, completing each outcome before expanding scope:

1. Verify the shipped message-first UI. v2.1.0 includes canonical Home/named-agent readers, Assistant/Mail compose, editable titles, draft protection, agent working status, centered content, top navigation, mobile brand and one-row Inbox links (#1840–#1848, #1855, #1863–#1865). Earlier sidebar/channel-link designs are superseded. Remaining gate: authenticated desktop/mobile/PWA checks, keyboard/composer placement, empty/populated states and long titles.
2. Verify identity and routing across existing channels. Prove web, SMTP, SMS, WhatsApp and XMPP route to the same correct account. Verify webhook signatures and proxy URL handling, duplicate delivery, replies and delivery receipts. Unknown senders must not access an existing account. Bounded Hello email introduction shipped in #1849; verify its delivery and ownership continuity. General provisional identity, challenge retries, partial account creation recovery, linking and phone-only recovery remain separate unfinished work; do not assume the older onboarding draft #1798 is live. Done when an existing user and a fresh identity can each complete a bounded exchange without cross-account exposure.
3. Verify durable asynchronous messages. #1824 and #1825 persist acceptance and use the shared queue for Inbox/SMTP replies and Home; #1840 corrects Assistant compose routing. Stable identifiers and interruption handling are implemented. Remaining gate: disconnect, duplicate submission and deliberate restart checks showing no accepted request is lost and no external action is replayed blindly; audit channels still outside that acceptance path.
4. Unify background job lifecycle and outcome delivery. Persist execution checkpoints, scoped account identity, cancellation, attempt/time/spend budgets and delivery state. Reconcile uncertain writes before retrying. Done when interrupted mail actions, schedules and app jobs are recoverable and the user gets either a verified result or an actionable failure.
5. Complete the created-output contract (#1801). Store typed output references in the originating conversation, render them independently of model prose, preserve ownership and explicit sharing, and keep Saved current after rename/delete. Finish usable file access/downloads beyond the current awake-workspace text previews. Done when notes, docs, files, schedules and apps can be reopened later from both the conversation and their view.
6. Make mail/calendar assistance dependable and bounded. Use selected calendars, relevant email threads and a bounded history window; inspect what leaves for the model. Separate reminders from agent instructions, respect timezone/DST and recurrence, and report where a result will arrive. Done when a forwarded-email commitment and tomorrow's brief each work without unrelated private content or unnecessary background generation.
7. Finish app-building outcomes. Use concrete requests (prayer tracker, expense log, simple booking form) and explicit acceptance criteria. Validate the generated app in its sandbox: domain-specific behaviour, persistence, SDK permissions, mobile layout and owner isolation. Show build/repair/failure status; preserve a working version. Done when the requested app works, not merely when HTML is produced.
8. Enforce single-VM operating budgets. Bound concurrent model/browser/code work, per-job runtime and retries, per-account spend and storage; maintain backups and demonstrate restore. Keep production credentials out of browser/code execution. Measure cost per completed job, latency and manual intervention. Never reintroduce blanket IP throttling that blocks login or ordinary page access.
9. Evaluate voice after the above. Prototype an inbound call using Twilio ConversationRelay or equivalent with the existing agent pipeline, explicit caller verification, interruption handling, spend limits and a conversation record. Start with user-initiated calls; add a Call link only after it works. iMessage remains a separate channel evaluation, not an SMS relabel.

Verification status at v2.1.0: implementation checks are documented in the linked PRs; authenticated browser/PWA, live protocol and deliberate restart drills remain unverified. Record evidence against each acceptance criterion. Do not send live messages without the applicable authorization or mistake merge/build success for end-to-end verification.

No specific files or tests are named. Start with the implementation checks in the linked pull requests and the authenticated browser/PWA, live protocol, and restart checks; record evidence against each acceptance criterion, including account isolation, durable delivery, recovery, and output access.