Randall Stillwell 778fe1d321 plans: scaffold daily-driver-finish, saas-hardening, agent-coordination

Three new plan trees that fill in the gaps surfaced during repo review.
Together they map out what remains between the current scaffold-with-stubs
state and a daily-usable, multitenant, agent-coordinated app.

* Plan-daily-driver-finish (P0): turn stubs into real data. Five tasks
  covering the lint/shared-types breakage, hardcoded dashboard mocks,
  AI-page setTimeout placeholder, post-signin landing decision, and a
  cross-browser collab smoke test against the deployed Hocuspocus
  instance.

* Plan-multitenant-saas-hardening (P1): everything multitenant needs
  beyond what Plan-multitenant-cursor-sync already covers. Invites and
  role management, soft-delete + append-only audit log, rate limits on
  the auth + mutation hot paths, and a Vitest + GitHub Actions test
  foundation so PRs can't ship red.

* Plan-agent-coordination (P2): the layer that makes a Task-*.md
  runnable, not just readable. Adds workflow_prompt with task -> epic
  -> plan inheritance, an agent_runs table for auditable sessions, and
  two new MCP tools (claim_task / complete_task) that replace the
  freeform update_object composition agents do today. Includes an
  intentionally-deferred Epic-optional-orchestrator that captures the
  Symphony-shaped runner as a decision point rather than an immediate
  build.

Each task is bead-scale (one focused Cursor session) with explicit
in-scope, out-of-scope, and anti-goal sections so a future agent can
pick up a single Task-*.md and start without scrollback context.

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

2026-06-01 23:52:22 -05:00

1.8 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-01

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

Invite + role management (workspace_members already exists; add invite flow on top).
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
Workspace invites and roles	`./Task-workspace-invites-and-roles.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`

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
Invites	Week 1	Owner can add a teammate end-to-end.
Audit + soft-delete	Week 2	Schema + middleware.
Guardrails	Week 3	Rate limits + abuse signals.

1.8 KiB Raw Blame History