mail-interaction-parity

# Mail Interaction Parity Use this as the acceptance workflow for Mail behavior. The target is observable interaction parity: the same intent, focus transition, visible state, keyboard result, optimistic feedback, and recovery path. Do not claim product parity from static inspection alone. ## Before testing 1. Read `mail-backends`, `inbox-reads-and-triage`, `email-drafts`, and `context-awareness` before touching connected mail or application state. 2. Run the app with deterministic synthetic mail when Gmail credentials are not available. Synthetic mail is not a live Gmail mailbox. 3. Open Mail and Superhuman side by side at the same viewport size. Record the exact Superhuman build/date and the Mail commit under test. 4. Seed or choose disposable messages that cover: one message, multi-message thread, unread, starred, labelled, draft, scheduled, attachment, HTML body, failed mutation, and partial account coverage. 5. Never send during the default pass. If a live round trip is explicitly approved, use only addresses the current user explicitly allowlisted for that run; use an exact user-approved subject/body and verify both Sent and Inbox afterward. Do not persist private addresses in fixtures or docs. ## Side-by-side protocol For every case in `references/interaction-matrix.md`: 1. Reset both products to the same starting state. 2. Perform the numbered Superhuman steps and record the resulting URL, focused element, visible rows, toast/banner, network state, and elapsed feel. 3. Repeat the exact intent in Mail, including the same alternate input paths (mouse, keyboard, touch, drag, paste, blur, reopen, refresh, and failure). 4. Mark `match`, `partial`, or `gap`. A `partial` requires a concrete next action; a `gap` must name the missing product capability or state. 5. Re-run the case after each fix, then run its neighboring cases. A fix is not complete until success, cancellation, loading, empty, error, rollback, and refresh/deep-link states remain distinguishable. Use stable Mail landmarks where present: `[data-mail-email-row]`, `[data-thread-key]`, `#mail-search`, `#mail-search-suggestions`, `[data-search-item]`, `[data-mail-compose]`, and the application-state keys described in `context-awareness`. ## Safety and truthfulness - Draft, queue, and inspect by default. A click, shortcut, or agent action that sends is an external side effect and needs explicit approval. - Do not use random recipients, generated addresses, or third-party inboxes for round-trip tests. The user's per-run allowlist is hard, not a suggestion. - Treat a local fallback as local. Treat a failed or incomplete account read as an error/partial result, never as an empty or successful mailbox. - Do not report “bug free” or “1:1” globally. Report the tested case IDs, evidence, and remaining gaps. ## Verification Run focused unit/action tests first, then a browser pass at 1440×900, 1024×768, 768×1024, and 390×844 when the browser harness is available. Check mouse, keyboard, touch, focus, loading, empty, error, undo, deep link, and refresh. Capture console errors and failed requests. For action changes, call the action and read the result back. For UI changes, exercise the exact broken path in a real browser or clearly record why the browser was unavailable. The exhaustive cases are in `references/interaction-matrix.md`; official comparison anchors are linked there so the behavior baseline can be revisited when Superhuman changes.