docs(spec): Phase 6 — client-grouped navigation and project kind

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 <noreply@anthropic.com>

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.