Architecture refinements before module work begins: - Calendars become first-class entities (mirror of lists). Each calendar has its own visibility (private | household) and is independently shareable. Updated CLAUDE.md data model and task 10. - Drop the singleton/parameterized split for dashboard widgets. Every widget declares a configSchema + defaultConfig + resolveConfigOptions and every placement is an independent instance — same widgetId can appear multiple times on one dashboard pointed at different things. Updated task 04 contract; tasks 11/12 widget sections aligned. - Add tasks 25 (multiple dashboards per user) and 26 (customizable layout + widget configuration). Replaces the previously-considered three-task plan with a cleaner two-task split that the uniform contract enables. Phase 3 index updated; STATUS records the rationale. - Task 20 reframed as a single-dashboard MVP that exercises the new contract end-to-end before the customization layer lands.
3.6 KiB
3.6 KiB
25 — Multiple dashboards per user
Goal
Each user can create any number of named dashboards, switch between them, and choose one as their default. No customization mechanic yet — that's task 26.
Why
Decouples "the dashboard" from "user's home page". A user might have a Daily, Garden, and Wedding planning dashboard, each composing different widgets. This task introduces the entity; task 26 adds the editor.
Depends on
- 20 (single-dashboard MVP — provides the layout shape we generalize from)
Scope
Schema
CREATE TABLE dashboards (
id uuid PRIMARY KEY,
user_id uuid REFERENCES users(id) ON DELETE CASCADE,
name text NOT NULL,
slug text NOT NULL, -- url-safe, unique per user
is_default boolean NOT NULL DEFAULT false,
position int NOT NULL DEFAULT 0,
layout jsonb NOT NULL DEFAULT '{"version":1,"widgets":[]}',
created_at timestamptz NOT NULL DEFAULT now(),
updated_at timestamptz NOT NULL DEFAULT now()
);
CREATE UNIQUE INDEX dashboards_user_slug_uq ON dashboards (user_id, slug);
CREATE UNIQUE INDEX dashboards_user_default_uq
ON dashboards (user_id) WHERE is_default;
Migration also copies each user's default_dashboard_layout (from task 20) into a single dashboard row named "Home" with is_default = true, then drops the users.default_dashboard_layout column.
Routes
/— redirect to the user's default dashboard (/d/<default-slug>)./d/[slug]— render that dashboard. 404 if the slug doesn't belong to the current user. Layout rendering is unchanged from task 20 (still no edit mode).
Server actions
createDashboard({ name })— generates a slug from the name (collision-suffixed); empty layout; not default.renameDashboard(id, name)— also re-derives slug if name changes (or keeps slug stable; pick stable, document it).deleteDashboard(id)— disallowed if it's the user's only dashboard. If it was default, mark another as default before deleting.setDefaultDashboard(id)— flip flags within a transaction.reorderDashboards(orderedIds)— bulk updateposition.
All gated on dashboards.user_id = currentUserId.
UI
- Switcher in the app header — desktop: tabs strip with the user's dashboards in
positionorder, an active indicator, a "+ new" tab at the end, and a kebab on the active tab for rename / set default / delete. Mobile: dropdown with the same actions. /settings/dashboards— full management view: drag to reorder (use the same library task 26 will pull in, or a smalldnd-kitsetup — leave a note for task 26 to consolidate).- New-dashboard flow: prompts for a name, creates an empty dashboard, navigates to it. Empty state explains "this dashboard has no widgets yet — task 26 will add the picker." (Or, if 26 has landed, just "Add widget".)
Out of scope
- Drag / resize / picker / configure (task 26).
- Sharing dashboards with the household or via share-link (deferred; nullable
household_idlater). - Per-device or per-orientation layouts.
Acceptance criteria
- Migration moves every existing user to a single
Homedashboard withis_default = true. Idempotent. - User can create, rename, reorder, delete dashboards; cannot delete their last one; cannot have two defaults.
/redirects to the user's default dashboard's/d/<slug>.- Switcher renders in the header on both desktop and mobile, scoped to the current user only.
- Server actions reject any operation against a dashboard the caller doesn't own.
- No regression in task 20's layout rendering — existing widgets render identically inside the new route.