arthur/xtablo-source
1
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions 6

docs: create milestone v3.0 roadmap (5 phases)

Browse source
This commit is contained in:
Arthur Belleville 2026-05-16 10:57:13 +02:00
parent 88d0187c84
commit 7a1eaa7b0f
No known key found for this signature in database
1 changed files with 67 additions and 70 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

137
.planning/ROADMAP.md
View file

@ -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 ✓** |