docs(remaster): record multi-tenant SaaS direction + multi-provider email
User decision (2026-07-05): evolve from single-user to public multi-tenant SaaS. Adds PRODUCT_DIRECTION.md: email linking generalises beyond Gmail (Microsoft Graph + IMAP + always-available free-text fallback), SaaS platform wave (onboarding, billing, quotas, per-tenant AI budget, rate limiting, outbox), and resolves the .gsd "use next.js" override in favour of executing it (public SEO). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,50 @@
|
||||
# Product Direction — decision addendum (2026-07-05)
|
||||
|
||||
Supersedes the open question in [REMASTER_PROPOSAL.md](REMASTER_PROPOSAL.md) §1 and `.gsd` D003
|
||||
("individual job seeker").
|
||||
|
||||
## Decision
|
||||
**Job Tracker becomes a multi-tenant SaaS** (public sign-up), evolved incrementally from the current
|
||||
single-user-origin codebase. The existing `OwnerUserId` + global-query-filter tenancy is the right
|
||||
foundation and already enforced; SaaS work builds on it rather than replacing it.
|
||||
|
||||
## New requirement: multi-provider email linking
|
||||
Email↔job linking must not be Gmail-only.
|
||||
- **Gmail** — existing OAuth path (`GmailOAuthService`, `GmailController`) — keep as provider #1.
|
||||
- **Microsoft / Outlook** — add via Microsoft Graph OAuth (large share of users).
|
||||
- **Generic IMAP** — cover "any other provider" (Fastmail, Proton Bridge, corporate, etc.).
|
||||
- **Unsupported / no-connect → free-text fallback** — the user can paste an email or log correspondence
|
||||
manually against a job (this already exists as manual `Correspondence`; make it a first-class, always-
|
||||
available path so a missing provider never blocks the workflow).
|
||||
|
||||
**Design implication:** introduce an `IEmailProvider` abstraction (connect, search, fetch-thread,
|
||||
refresh-linked-thread) with `GmailProvider`, `MicrosoftGraphProvider`, `ImapProvider`, and a `ManualEntry`
|
||||
non-provider. `Correspondence` already stores `ExternalThreadId` + from/to metadata — generalise it with a
|
||||
`Provider` discriminator instead of Gmail-specific assumptions. Keep the no-auto-send boundary (D002).
|
||||
|
||||
## What SaaS adds to the roadmap (new wave, after the refactor foundation)
|
||||
These were flagged `[SaaS]` in the proposal and are now in scope:
|
||||
- **Onboarding & account lifecycle** — sign-up, email verification, password reset (parts exist), per-user
|
||||
workspace bootstrap, delete/export (GDPR).
|
||||
- **Plans, billing & quotas** — free vs paid; meter AI usage; Stripe (or similar).
|
||||
- **Per-tenant AI cost control** — the provider router (Wave 1) plus per-tenant budgets and optional
|
||||
**BYO-API-key** (a real differentiator, see [RESEARCH_COMPETITORS.md](RESEARCH_COMPETITORS.md) §4).
|
||||
- **Abuse resistance & rate limiting** — public sign-up widens the SSRF/import/AI attack surface; add
|
||||
per-tenant rate limits and re-check tenant isolation on every endpoint.
|
||||
- **Background processing at scale** — move the polling hosted services toward an outbox + worker so
|
||||
reminders/enrichment scale beyond a single busy node.
|
||||
|
||||
## Frontend consequence — the "use next.js" override is now justified
|
||||
A public SaaS needs SEO/SSR marketing pages + fast first paint. This **resolves the `.gsd` OVERRIDES
|
||||
"use next.js" conflict in favour of executing it**: migrate the frontend to **Next.js** (was previously a
|
||||
toss-up with Vite for a private tool). Still its own milestone, not coupled to backend work.
|
||||
|
||||
## Re-sequenced roadmap
|
||||
1. **Wave 1 — Performance + AI provider router** *(in progress; provider-agnostic, unaffected by SaaS)*
|
||||
2. **Wave 2 — Safe refactors** (extract services/DTOs from god controllers)
|
||||
3. **Wave 3 — Data-model evolution** (versioned CV/cover letter, split import content, drop drift-prone flags)
|
||||
4. **Wave 4 — Email provider abstraction** (Gmail + Microsoft Graph + IMAP + free-text) & AI hardening
|
||||
5. **Wave 5 — SaaS platform** (onboarding, billing, quotas, per-tenant AI budget, rate limiting, outbox)
|
||||
6. **Wave 6 — Next.js frontend migration** (public SEO/SSR)
|
||||
|
||||
Wave 1–3 harden the core for *any* identity; Waves 4–6 deliver the public-SaaS pivot.
|
||||
@@ -17,6 +17,7 @@ begin [MIGRATION_PLAN.md](MIGRATION_PLAN.md) Wave 1.
|
||||
8. [MIGRATION_PLAN.md](MIGRATION_PLAN.md)
|
||||
9. [RESEARCH_COMPETITORS.md](RESEARCH_COMPETITORS.md)
|
||||
10. [REBUILD_DECISION.md](REBUILD_DECISION.md)
|
||||
11. [PRODUCT_DIRECTION.md](PRODUCT_DIRECTION.md) — 2026-07-05 decision: **multi-tenant SaaS** + multi-provider email (Gmail/Microsoft/IMAP + free-text), re-sequenced roadmap
|
||||
|
||||
## Method
|
||||
Every finding is code-grounded (file/line) or explicitly labelled `[Speculative issue]`. Tags:
|
||||
|
||||
Reference in New Issue
Block a user