cesnimda
4ce2df0a2b
CI / backend (push) Successful in 52s
CI / frontend (push) Successful in 14s
Deploy Staging / deploy (push) Successful in 18s
CI / backend (pull_request) Successful in 52s
CI / frontend (pull_request) Successful in 15s
Security / secrets (push) Successful in 4s
Security / dependencies (push) Successful in 55s
Security / secrets (pull_request) Successful in 4s
Security / dependencies (pull_request) Successful in 54s
2.9 KiB
2.9 KiB
Multi-Provider Email Platform + Admin/Settings — Design
Design + architecture phase. No implementation until approved.
Evolves InboxIntel from a single-account Gmail tool into a multi-provider platform (Gmail · Outlook/Graph · future IMAP) for a small self-hosted team, with settings, feature flags, and an admin panel. Extends — does not discard — the discovery blueprint.
Locked decisions (from interview)
- Tenancy: small team, self-hosted, one org. Roles = Admin / Member. Shared system settings + feature flags; each member's mail is private to them. No multi-tenant org table (one implicit org); the model stays extensible to multi-org later.
- App identity = provider OAuth. The first Google/Microsoft sign-in creates/authenticates the InboxIntel user; additional mailboxes link to that same user. No passwords stored.
How this reshapes the blueprint (the "review" deltas)
| Blueprint assumption | New reality |
|---|---|
| Single-user, local-first | Multi-user (small team) with Admin/Member RBAC + admin panel |
Gmail-centric Email/Sender |
Account-scoped, provider-normalised model (IEmailProvider) |
AI gated by Ai:Mode + user pref |
AI gated by system feature flag → user pref → capability (flag wins) |
| One implicit mailbox | N provider accounts per user (accounts table + per-account sync cursors) |
Sync = GmailSyncWorker |
Provider-agnostic sync orchestrator dispatching to provider adapters |
These deltas will be back-ported into main-blueprint docs 08 and 09 when this design is approved.
Documents
| # | Doc | Covers (brief part) | Status |
|---|---|---|---|
| 01 | Provider Abstraction | Part 1 | ✅ draft |
| 02 | Auth & Sign-in | Part 2 | ✅ draft |
| 03 | Database Design | Part 6 | ✅ draft |
| 04 | Settings & Feature Flags | Part 3 | ✅ draft |
| 05 | Admin System | Part 4 | ✅ draft |
| 06 | Security Model | Part 5 | ✅ draft |
| 07 | UX Flows | Part 7 | ✅ draft |
| 08 | AI Feature-Flag Integration | Part 8 | ✅ draft |
| 09 | Implementation Plan | Part 9 | ✅ draft |
| 10 | Git Workflow | Part 11 | ✅ draft |
| 11 | Risk Analysis | output | ✅ draft |
| 12 | Migration Guide | Part 10 | ✅ draft |
Non-negotiables carried forward
Provider logic never leaks into Domain · search works across all a user's accounts · emails stored in one unified format · AI never required for core function · tokens encrypted at rest · admin actions audit-logged.