diff --git a/.planning/ROADMAP.md b/.planning/ROADMAP.md index d450a16..e6f02bf 100644 --- a/.planning/ROADMAP.md +++ b/.planning/ROADMAP.md @@ -1,10 +1,10 @@ -# Roadmap: Xtablo v2.0 Collaboration, Planning, and Social Sign-in +# Roadmap: Xtablo v3.0 Design System & Visual Polish -**Created:** 2026-05-15 +**Created:** 2026-05-16 **Project mode:** Brownfield milestone on existing Go+HTMX backend -**Milestone:** v2.0 — Collaboration, planning, and social sign-in +**Milestone:** v3.0 — Design System & Visual Polish -5 phases, sequential. Phase numbering continues from v1.0, so v2.0 starts at Phase 8. +5 phases, sequential. Phase numbering continues from v2.0, so v3.0 starts at Phase 13. --- @@ -12,99 +12,96 @@ | # | Phase | Goal | Requirements | |---|-------|------|--------------| -| 8 | Social Sign-in | Google sign-in creates/links local users and issues existing Xtablo sessions; Apple sign-in is disabled | AUTH-08..13 | -| 9 | Etapes | Tasks can be grouped under one-level etapes without breaking the kanban model | ETAPE-01..06 | -| 10 | 4/4 | Complete | 2026-05-16 | -| 11 | 2/2 | Complete | 2026-05-16 | -| 12 | 3/3 | Complete | 2026-05-16 | +| 13 | Design System Foundation | Port full component library from go-backend into backend/ | DS-01..DS-09 | +| 14 | Auth Pages | Restyle login/signup to match JS app auth-card layout | AUTH-UI-01..03 | +| 15 | Dashboard & Tablos | Restyle sidebar and tablo list to match JS app | DASH-01..03 | +| 16 | Tablo Detail | Restyle tasks, etapes, and files views | DETAIL-01..04 | +| 17 | Chat & Planning | Restyle discussion and planning pages | CHAT-UI-01, PLAN-UI-01 | --- ## Phase Details -### Phase 8: Social Sign-in -**Goal:** Users can sign in with Google while Xtablo keeps owning user accounts and sessions; Apple sign-in is disabled and hidden for now. +### Phase 13: Design System Foundation +**Goal:** Replace the minimal `backend/internal/web/ui` with a full design system ported from `go-backend/internal/web/ui` — tokens, components, and Tailwind integration — so every subsequent phase has a stable component library to consume. **Mode:** mvp -**Status:** Complete -**Requirements:** AUTH-08, AUTH-09, AUTH-10, AUTH-11, AUTH-12, AUTH-13 +**Status:** Pending +**Requirements:** DS-01, DS-02, DS-03, DS-04, DS-05, DS-06, DS-07, DS-08, DS-09 **Success Criteria:** -1. Login/signup page shows Google sign-in alongside email/password and no Apple sign-in controls -2. Google callback validates state, exchanges authorization code, verifies ID token, creates or links `user_identities`, and issues a local session -3. `/auth/apple/start` and `/auth/apple/callback` are not mounted while Apple sign-in is disabled -4. Existing email/password signup/login/logout tests still pass unchanged -5. `.env.example` and README document required Google config without committing secrets and state that Apple sign-in is disabled +1. `backend/internal/web/ui/base.css` defines all CSS custom properties (color, spacing, typography, shadows, gradients) matching the go-backend token vocabulary +2. All component types are implemented as templ components: button, input, textarea, select, card, badge, modal, empty-state, table, icon-button +3. `backend/tailwind.input.css` imports all component CSS files and the app shell CSS +4. A component catalog page (`/ui-catalog`, dev-only) renders all components for visual verification +5. All existing templates compile and unit tests pass with no regressions -**User-in-loop:** Approve `user_identities` schema and account-linking behavior for matching verified emails before migration/sqlc generation. +**User-in-loop:** Review the catalog page before proceeding to per-view application phases. Confirm token choices (brand color, radius, shadow levels) match what you want the product to look like. -### Phase 9: Etapes -**Goal:** A user can organize tasks under one-level etapes inside a tablo while preserving existing task status and ordering behavior. +### Phase 14: Auth Pages +**Goal:** Restyle login and signup pages to match the JS app's auth-card layout using the design system from Phase 13. **Mode:** mvp -**Requirements:** ETAPE-01, ETAPE-02, ETAPE-03, ETAPE-04, ETAPE-05, ETAPE-06 +**Status:** Pending +**Requirements:** AUTH-UI-01, AUTH-UI-02, AUTH-UI-03 **Success Criteria:** -1. User can create, edit, delete, and reorder etapes inside a tablo -2. User can assign or unassign a task from an etape -3. Tasks continue to move/reorder across kanban statuses after etape support is added -4. Deleting an etape unassigns its tasks and does not delete those tasks -5. Database schema prevents nested etapes by modeling etapes as a separate table and tasks as optional children +1. Login page has gradient background with animated background layer, centered auth card with brand logo, and status banner using design tokens +2. Signup page matches the same visual treatment as login +3. Google sign-in button uses the Material Design button style from the go-backend design +4. All existing auth handler tests pass unchanged +5. Browser walkthrough of login and signup matches the go-backend app.css auth-card design -**User-in-loop:** Approve etape table fields, delete behavior, and the first functional UI shape for grouping/filtering tasks. +**User-in-loop:** Share design references (screenshots from JS app) before this phase begins; /frontend-design skill applies them during plan execution. -### Phase 10: Events -**Goal:** A user can schedule events that belong to tablos, with the same authorization expectations as tasks and files. +### Phase 15: Dashboard & Tablos +**Goal:** Restyle the layout shell (sidebar + main) and tablo list/dashboard to match the JS app's sidebar + project-card layout. **Mode:** mvp -**Requirements:** EVENT-01, EVENT-02, EVENT-03, EVENT-04, EVENT-05 +**Status:** Pending +**Requirements:** DASH-01, DASH-02, DASH-03 **Success Criteria:** -1. User can create an event for a tablo with title, start time, optional end time, optional description, and optional location -2. User can edit and delete a tablo event -3. Tablo detail page exposes an events view listing events for that tablo -4. Server validation rejects events whose end time is before or equal to start time -5. Tests prove inaccessible tablo events cannot be read, created, updated, or deleted +1. Sidebar has brand section, nav items with icons, tablo list section, and user/account footer using sidebar-nav-shell classes +2. Tablo list uses project-card layout with color avatars, creation date, and action controls +3. Dashboard empty state uses the empty-state component +4. All existing tablo CRUD handler tests pass unchanged +5. Browser walkthrough of tablos list matches the go-backend project-card / sidebar design -**User-in-loop:** Approve event schema, timezone/display assumptions, and whether the first UI is list/agenda-first rather than calendar-grid. +**User-in-loop:** Approve sidebar shape (nav items, tablo list section) and tablo card layout before implementation. -### Phase 11: Individual Planning -**Goal:** Each authenticated user can open a personal planning view that aggregates their scheduled events across tablos. +### Phase 16: Tablo Detail +**Goal:** Restyle the tablo detail view — header, task kanban, etapes, and files — using design system components. **Mode:** mvp -**Requirements:** PLAN-01, PLAN-02, PLAN-03, PLAN-04 +**Status:** Pending +**Requirements:** DETAIL-01, DETAIL-02, DETAIL-03, DETAIL-04 **Success Criteria:** -1. `/planning` is protected and renders only for authenticated users -2. Planning page lists the user's accessible events across tablos in chronological order -3. Each listed event links back to its tablo context -4. Empty state and date filtering/navigation work without a JS framework -5. Planning query does not leak events from inaccessible tablos +1. Tablo detail header uses project-card-top layout with title, avatar, and action controls +2. Task kanban uses tasks-section design: section header with add button, task rows with checkbox and meta +3. Etapes section uses the same card/section visual pattern as tasks +4. Files section uses the table component with consistent row actions +5. All existing task, etape, and file handler tests pass unchanged -**User-in-loop:** Approve first working planning view behavior: today/upcoming filter versus week navigation. +**User-in-loop:** Approve kanban layout shape (whether columns stay horizontal or fold to list) and etape grouping UI before implementation. -### Phase 12: Native Tablo Chat -**Goal:** Each tablo has a native persisted discussion stream with real-time updates and no managed chat/realtime provider. +### Phase 17: Chat & Planning +**Goal:** Restyle the discussion view and planning page using design system components to make them visually consistent with the rest of the app. **Mode:** mvp -**Requirements:** CHAT-01, CHAT-02, CHAT-03, CHAT-04, CHAT-05, CHAT-06 +**Status:** Pending +**Requirements:** CHAT-UI-01, PLAN-UI-01 **Success Criteria:** -1. Tablo detail page includes a discussion view that loads persisted message history -2. User can post a text message with CSRF protection and server-side validation -3. Messages persist in Postgres with tablo, author, body, created timestamp, and edit/delete metadata -4. A second open browser receives new messages without manual refresh -5. Implementation uses Xtablo-owned infrastructure only; no managed chat/realtime provider or external realtime runtime is added -6. Message rendering escapes user content and enforces a maximum body length -7. Streaming behavior is verified behind the local/prod reverse proxy path, including keep-alives or buffering behavior +1. Discussion view uses card/surface design; own messages vs. others are visually differentiated +2. Planning page uses overview-section layout with chronological event list +3. All existing chat and planning handler tests pass unchanged +4. Browser walkthrough confirms both views look consistent with the Phase 15–16 restyled surfaces -**User-in-loop:** Approve final real-time transport choice during planning. Research recommends SSE receive + HTMX POST send for v2; WebSockets remain available if the plan-phase proves bidirectional transport is required. +**User-in-loop:** Approve chat bubble/row style and planning event row design before implementation. --- ## Coverage -- v2.0 requirements: 27 -- Mapped to phases: 27 -- Unmapped: 0 +**21 requirements mapped across 5 phases** -## Notes - -- Phase ordering isolates auth changes first, task schema/UI extension second, event domain third, planning aggregation fourth, and real-time chat last. -- Existing v1.0 roadmap history remains available in git history and `.planning/phases/`. -- The user will provide a more polished UI later; each phase should build functional, clean, testable UI with minimal visual ambition. -- Schema decisions remain hard gates before migrations/sqlc generation. -- Research recommends SSE for real-time chat because message sends can stay as CSRF-protected HTTP POSTs while receive streams provide real-time updates. - ---- -*Roadmap created: 2026-05-15* +| Phase | Requirements | Count | +|-------|-------------|-------| +| 13 | DS-01, DS-02, DS-03, DS-04, DS-05, DS-06, DS-07, DS-08, DS-09 | 9 | +| 14 | AUTH-UI-01, AUTH-UI-02, AUTH-UI-03 | 3 | +| 15 | DASH-01, DASH-02, DASH-03 | 3 | +| 16 | DETAIL-01, DETAIL-02, DETAIL-03, DETAIL-04 | 4 | +| 17 | CHAT-UI-01, PLAN-UI-01 | 2 | +| **Total** | | **21 / 21 ✓** |