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

3 KiB

Raw Blame History

kind	slug	title	plan_slug	epic_slug	status	priority	tenant_id	owner	cursor_todo_id	updated_at
task	pick-workspace-landing-route	Decide and implement the post-sign-in landing route	daily-driver-finish	shipping-the-shell	ready	P1	global	unassigned	null	2026-06-01

Task summary

After sign-in, where should a user land? Today they land on [workspaceSlug]/page.tsx, which is a mostly-decorative dashboard. Make a deliberate decision and implement it.

Description

The decision

Three reasonable defaults:

Workspace home (current) — only good once Task-wire-workspace-home-dashboard lands. Until then, it's a mockup.
Planner — [workspaceSlug]/planner, the most "active" view. Lots of tenants will prefer this.
Last visited surface — store last_visited_path on the user (or in localStorage) and redirect there. Best UX but requires a column and a tiny middleware.

Recommendation: (1) workspace home, but only after Task-wire-workspace-home-dashboard has landed. If that task isn't done yet, ship a redirect to (2) /planner as the interim default and remove the redirect once the home page is real.

Implementation

The redirect target for an authenticated user with no specific URL is decided in apps/web/middleware.ts (if it exists) or via the NextAuth pages.signIn and the post-sign-in callbackUrl.
Verify signIn(provider, { callbackUrl: "/" }) lands somewhere sensible. The current top-level page should redirect to the user's first workspace's slug. Check apps/web/app/page.tsx (the unauth root) and apps/web/app/(app)/page.tsx (the auth root).
The redirect must use workspace_members to find a workspace the user belongs to. Don't trust the slug from a query param without verifying membership.

Anti-goals

Don't introduce a "switcher" workflow as part of this task. If users have multiple workspaces today, just pick the first one (oldest membership) and land them there.
Don't add new DB columns for last_visited_path unless you're committing to do the full implementation. The simple redirect is fine for now.

Subtasks

Read apps/web/middleware.ts and apps/web/app/(app)/layout.tsx to find the existing landing logic.
Decide: workspace home or planner. Document the choice in this task before implementing.
Implement the redirect, scoped through workspace_members.
Verify with a fresh OAuth sign-in that the user lands somewhere useful.

Owner or assignee

Unassigned

Status

ready

Estimation

Acceptance criteria

A fresh sign-in lands on a page that shows real state, not a mockup.
Landing logic resolves workspace via workspace_members (no URL-trust).
Users with zero workspaces don't 404 — they hit an onboarding flow or the workspace-creation dialog. (If neither exists, file a follow-up task and gate this acceptance criterion on it.)

Epic: ./Epic-shipping-the-shell.md
Plan: ../Plan-daily-driver-finish.md

3 KiB Raw Blame History