Randall Stillwell 820dae6510 docs(plans): split workspace-invites convoy into identity + invites + autocomplete

User pushed back on "strict email match in v1" — the right architectural
answer is multi-email identity (one users row owning multiple verified
emails), not a stopgap. Scaling the convoy accordingly:

1. Task-multi-email-identity (NEW, P1, foundation)
   - user_email_identities table (user_id, email lowercased, verified_at,
     source: primary | oauth:<provider> | manual)
   - Refactor ensureUserIdByEmail -> ensureUserIdByVerifiedEmail against
     the new table.
   - OAuth callback writes a source='oauth:<provider>' identity when the
     provider returns email_verified=true. Cross-user conflict rejects.
   - Profile UI: "Linked emails" section, read-only in v1.
   - Exports userOwnsEmail(userId, emailLower) for invite accept to call.

2. Task-workspace-invites-and-roles (existing, narrowed)
   - All the original spec.
   - Accept procedure calls userOwnsEmail() instead of comparing
     users.email directly. Mismatch renders an explainer page, not a
     silent accept.

3. Task-invite-recipient-autocomplete (NEW, P1, polish)
   - invites.suggestRecipient returns typed suggestions across four
     kinds: member / pending_invite / known_user / new_email.
   - Tenancy fence on known_user is the security-relevant assertion;
     test for it explicitly.
   - Combobox UI renders each kind with its own affordance.

Three follow-ups filed explicitly to keep this convoy PR-sized:
- Task-manual-email-verification (add an email outside OAuth)
- Task-disconnect-linked-email (destructive, needs last-verified guard)
- Task-account-merge (handle the legacy duplicate-users case)

Epic file refreshed with the new task table, follow-up table, and a
phase ordering note. Identity lands first because it touches the
sign-in path; invites and autocomplete can ship in their own PRs.

Co-authored-by: Cursor <cursoragent@cursor.com>

2026-06-02 10:02:38 -05:00

3 KiB

Raw Blame History

kind	slug	title	plan_slug	status	priority	tenant_id	cursor_epic_id	updated_at
epic	tenant-lifecycle	Tenant lifecycle — invites, roles, soft-delete, audit, rate-limits	multitenant-saas-hardening	ready	P1	global	null	2026-06-02

Epic objective

Cover the operational edges of running a multitenant app: who's in the workspace, what they did, can we recover from a mistake, and can we cap abuse.

In scope / out of scope

In scope

Multi-email identity on user profile (foundation — one user can own multiple verified emails).
Invite + role management (workspace_members already exists; add invite flow on top).
Smart invite-recipient autocomplete (members / pending / known users / new email).
Append-only audit_log table with write hooks.
Soft-delete on workspaces and core tenant-scoped tables.
Rate-limiting middleware on auth + mutation routes.

Out of scope

SSO group sync (later).
Per-tenant billing (separate plan).

Task	Link
Multi-email identity on user profile	`./Task-multi-email-identity.md`
Workspace invites and roles	`./Task-workspace-invites-and-roles.md`
Invite recipient autocomplete	`./Task-invite-recipient-autocomplete.md`
Workspace soft-delete and audit	`./Task-workspace-soft-delete-and-audit.md`
Rate limit and abuse guardrails	`./Task-rate-limit-and-abuse-guardrails.md`

Follow-ups (filed, not in this convoy)

Task	Link	Why deferred
Manual email verification	`./Task-manual-email-verification.md`	Add an email outside an OAuth provider; needs verification token + send + entry UI.
Disconnect linked email	`./Task-disconnect-linked-email.md`	Has destructive edge cases (last verified email, primary swap).
Account merge	`./Task-account-merge.md`	Merge two existing users who turn out to share an email — security-sensitive, not v1.

Dependencies

Depends on: Plan-daily-driver-finish (don't harden surfaces that are still stubs).
Blocks: charging real money, onboarding non-trusted tenants.

Acceptance criteria

An owner can invite an email; the recipient lands in the workspace after sign-in.
Every tenant-scoped mutation produces an audit_log row.
An archived workspace stops serving its data through tRPC but is restorable for at least 30 days.
Credentials sign-in is rate-limited at the route handler level.

Proposed timeline

Phase	Window	Notes
Identity foundation	Week 1 (first half)	`Task-multi-email-identity` lands before any invite work touches the sign-in path.
Invites	Week 1 (second half)	`Task-workspace-invites-and-roles` end-to-end with copy-paste URL.
Invite polish	Week 2 (first half)	`Task-invite-recipient-autocomplete`. Can parallelize with audit/soft-delete.
Audit + soft-delete	Week 2 (second half)	Schema + middleware.
Guardrails	Week 3	Rate limits + abuse signals.

3 KiB Raw Blame History