famapp/docs/tasks/25-multiple-dashboards.md

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 update position.

All gated on dashboards.user_id = currentUserId.

UI

• Switcher in the app header — desktop: tabs strip with the user's dashboards in position order, 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 small dnd-kit setup — 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_id later).
• Per-device or per-orientation layouts.

Acceptance criteria

• Migration moves every existing user to a single Home dashboard with is_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.