From 5c986e6449c97b3c56d5077bd52af6b65d854fb7 Mon Sep 17 00:00:00 2001 From: Dave Date: Thu, 17 Sep 2026 10:14:31 +0200 Subject: [PATCH] =?UTF-8?q?docs(spec):=20Phase=206=20=E2=80=94=20client-gr?= =?UTF-8?q?ouped=20navigation=20and=20project=20kind?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Design for grouping projects by client on the home page and in a new sidebar Kanban flyout tree, making the dashboard the project landing page with the board one click away, and a prototype/project kind flag so unsolicited client-facing prototypes can live alongside committed projects with the same permissions, just tagged differently. Co-Authored-By: Claude Sonnet 5 --- ...se-6-navigation-and-project-kind-design.md | 99 +++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 docs/superpowers/specs/2026-09-17-phase-6-navigation-and-project-kind-design.md diff --git a/docs/superpowers/specs/2026-09-17-phase-6-navigation-and-project-kind-design.md b/docs/superpowers/specs/2026-09-17-phase-6-navigation-and-project-kind-design.md new file mode 100644 index 0000000..2a7b307 --- /dev/null +++ b/docs/superpowers/specs/2026-09-17-phase-6-navigation-and-project-kind-design.md @@ -0,0 +1,99 @@ +# Phase 6: Client-Grouped Navigation & Project Kind — Design + +## Problem + +Project browsing today is a flat grid on the home page, with no client grouping and no +way to jump into a project's board without first landing on it as a tile. There is also +no way to represent a project that exists only as the developer's own unsolicited +prototype for a client, distinct from a project the client has actually committed to. + +## Goals + +- Group projects by client wherever they're browsed (home page, and a new sidebar + Kanban tree), so "whose is this" is always visible without reading captions. +- Make the dashboard the landing page for a project; the board becomes one click away, + not the default. +- Add a fast path from the sidebar straight into any project's board, without detouring + through the home page. +- Let a project be tagged as a `prototype` — full board, full dashboard, same + permissions as any other project — distinguished only by a visual tag. A prototype + still belongs to a client; it is not a client-less category. + +## Non-goals + +- No change to the permission model. Prototypes are visible to their client manager + exactly like any other project, governed by the same PocketBase row rules. +- No "promote to real project" workflow. Flipping `kind` from `prototype` to `project` + is just an edit on the existing admin project form. +- No change to the admin projects table's structure beyond one new column. +- No visibility toggle for prototypes. If it isn't ready to be shown, don't create it + under that client's project list yet. + +## Data model + +Add one field to the `projects` collection: + +- `kind`: select, `"project" | "prototype"`, required, default `"project"`. + +Existing rows backfill to `"project"` — nothing currently in production should read as +a prototype. `ProjectRecord` in `src/lib/pb/types.ts` gets a matching `ProjectKind` +union and `kind` field. No change to the `client` relation; it stays required. + +## Home page (`/`) + +`loadProjectSummaries()` groups its result by client (sorted by client name, then +project name within each). The page renders a client name as a section header, with +that client's projects underneath in the existing tile style — color dot, name, open +card count, inbox pill. + +A prototype tile carries an additional small tag (e.g. "Prototype") and a visually +distinct accent, but otherwise shows the same information as any other tile — no +information is hidden or degraded for a prototype. + +Tiles link to `/p/[clientSlug]/[projectSlug]/dashboard` instead of the board root. + +## Sidebar Kanban tree + +A new nav item, "Kanban", is added to the existing fixed icon rail in +`src/components/shell/sidebar.tsx`. Every other rail item is unchanged — this is +additive, not a rework of the rail. + +Clicking "Kanban" toggles a flyout panel anchored beside the rail (not a route +navigation by itself — it's a picker). Contents: + +- **Owner**: each client as a group header, its projects listed underneath (prototypes + tagged the same way as on the home page). +- **Client manager**: their own projects listed directly, with no client header — they + only ever have one client, so a header adds nothing. + +Clicking a project entry in the flyout navigates to `/p/[clientSlug]/[projectSlug]` +(the board) and closes the panel. Clicking outside the panel, or the Kanban icon again, +also closes it. No expand state is persisted between opens — it's recomputed fresh each +time, same data source as the home page grouping. + +## Dashboard → Board + +The project `TopBar` component is already shared across Board, Dashboard, Archive, and +(owner-only) Unassigned, and is rendered on all four pages. The implementation plan +confirms whether a "Board" tab is already visible from the dashboard page; if it's +missing, one is added. No new component should be needed here — this is a verify-and- +patch item, not new design. + +## Admin projects table + +`/admin/projects` gains a "Kind" column showing Project/Prototype. The create/edit form +gains a Kind toggle. No other change to the admin table or its permissions. + +## Permissions + +Unchanged. Prototypes are read and written under the exact same `scopedRead`/role rules +as any other project — there is no new rule, no new branch, and no new exception for +`kind`. A client manager sees a prototype for their own client the moment it's created, +same as any other project row. + +## Out of scope for this spec + +Onboarding the four existing Forgejo repos as projects is a data-entry task against the +existing admin project creation flow (which already wires up webhook + backfill +ingestion per Phase 2), not a design or implementation change. It's handled directly +once the repo URLs and client mapping are provided, outside this plan.