Should you build your own Canary Mail?

Build a personal replacement for Canary Mail in an empty repository.
Use Tauri 2, React, TypeScript, SQLite, IMAP, SMTP, and OAuth where available; do not offer alternative stacks.
The core loop is: connect an existing mailbox, index messages locally, provide a fast focused inbox with optional summaries, and send through the account's normal SMTP service.
Make the first run work locally with one documented command.
Store all user data locally by default and make export straightforward.
Put secrets in .env, ship .env.example, and never commit credentials.
Support one IMAP and SMTP account with credentials stored only in the OS keychain.
Index headers and message bodies locally with resumable sync and a visible status page.
Implement standards-based threading, folders, labels, archive, snooze, drafts, and search.
Render HTML email in a locked-down sandbox and block remote images by default.
Send multipart messages with attachments and preserve a local copy of every draft.
Add export, local cache reset, account reconnect, diagnostics, and safe logging.
Include clear empty, loading, success, and recoverable error states.
Add input validation, safe filenames, and graceful handling of unavailable APIs.
Write focused tests for the core transformation and one end-to-end happy path.
Create a README with setup, architecture, permissions, data location, and backup steps.
Do not add accounts, billing, telemetry, analytics, or a hosted control plane.
Deliberately leave out running a public mail server.
Deliberately leave out shared team inboxes and sales workflows.
Deliberately leave out mobile push services and provider-scale spam filtering.
Finish by running the tests and listing the exact commands used.