ubiquitous-invention/plans/Plan-daily-driver-finish/Epic-shipping-the-shell/Task-pick-workspace-landing-route.md

71 lines
3 KiB
Markdown
Raw Normal View History

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-02 00:52:22 -04:00
---
kind: task
slug: pick-workspace-landing-route
title: Decide and implement the post-sign-in landing route
plan_slug: daily-driver-finish
epic_slug: shipping-the-shell
status: ready
priority: P1
tenant_id: global
owner: unassigned
cursor_todo_id: null
updated_at: "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:
1. **Workspace home** (current) — only good once `Task-wire-workspace-home-dashboard` lands. Until then, it's a mockup.
2. **Planner**`[workspaceSlug]/planner`, the most "active" view. Lots of tenants will prefer this.
3. **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
1. 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`.
2. 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).
3. 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
S
## 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.)
## Links to related Epic / Plan
- Epic: `./Epic-shipping-the-shell.md`
- Plan: `../Plan-daily-driver-finish.md`