6 KiB
Roadmap: Xtablo v2.0 Collaboration, Planning, and Social Sign-in
Created: 2026-05-15 Project mode: Brownfield milestone on existing Go+HTMX backend Milestone: v2.0 — Collaboration, planning, and social sign-in
5 phases, sequential. Phase numbering continues from v1.0, so v2.0 starts at Phase 8.
Phase Summary
| # | Phase | Goal | Requirements |
|---|---|---|---|
| 8 | Social Sign-in | Google and Apple sign-in create/link local users and issue existing Xtablo sessions | AUTH-08..13 |
| 9 | Etapes | Tasks can be grouped under one-level etapes without breaking the kanban model | ETAPE-01..06 |
| 10 | Events | Tablos have scheduled events with CRUD, validation, and authorization | EVENT-01..05 |
| 11 | Individual Planning | Users can view their own event agenda across tablos | PLAN-01..04 |
| 12 | Native Tablo Chat | Each tablo has persisted discussion with real-time delivery and no managed chat provider | CHAT-01..06 |
Phase Details
Phase 8: Social Sign-in
Goal: Users can sign in with Google or Apple while Xtablo keeps owning user accounts and sessions. Mode: mvp Status: Complete Requirements: AUTH-08, AUTH-09, AUTH-10, AUTH-11, AUTH-12, AUTH-13 Success Criteria:
- Login/signup page shows Google and Apple sign-in entry points alongside email/password
- Google callback validates state, exchanges authorization code, verifies ID token, creates or links
user_identities, and issues a local session - Apple callback validates state/nonce, exchanges authorization code, verifies ID token, creates or links
user_identities, and issues a local session - Existing email/password signup/login/logout tests still pass unchanged
.env.exampleand README document required Google and Apple config without committing secrets
User-in-loop: Approve user_identities schema and account-linking behavior for matching verified emails before migration/sqlc generation.
Phase 9: Etapes
Goal: A user can organize tasks under one-level etapes inside a tablo while preserving existing task status and ordering behavior. Mode: mvp Requirements: ETAPE-01, ETAPE-02, ETAPE-03, ETAPE-04, ETAPE-05, ETAPE-06 Success Criteria:
- User can create, edit, delete, and reorder etapes inside a tablo
- User can assign or unassign a task from an etape
- Tasks continue to move/reorder across kanban statuses after etape support is added
- Deleting an etape unassigns its tasks and does not delete those tasks
- Database schema prevents nested etapes by modeling etapes as a separate table and tasks as optional children
User-in-loop: Approve etape table fields, delete behavior, and the first functional UI shape for grouping/filtering tasks.
Phase 10: Events
Goal: A user can schedule events that belong to tablos, with the same authorization expectations as tasks and files. Mode: mvp Requirements: EVENT-01, EVENT-02, EVENT-03, EVENT-04, EVENT-05 Success Criteria:
- User can create an event for a tablo with title, start time, optional end time, optional description, and optional location
- User can edit and delete a tablo event
- Tablo detail page exposes an events view listing events for that tablo
- Server validation rejects events whose end time is before or equal to start time
- Tests prove inaccessible tablo events cannot be read, created, updated, or deleted
User-in-loop: Approve event schema, timezone/display assumptions, and whether the first UI is list/agenda-first rather than calendar-grid.
Phase 11: Individual Planning
Goal: Each authenticated user can open a personal planning view that aggregates their scheduled events across tablos. Mode: mvp Requirements: PLAN-01, PLAN-02, PLAN-03, PLAN-04 Success Criteria:
/planningis protected and renders only for authenticated users- Planning page lists the user's accessible events across tablos in chronological order
- Each listed event links back to its tablo context
- Empty state and date filtering/navigation work without a JS framework
- Planning query does not leak events from inaccessible tablos
User-in-loop: Approve first working planning view behavior: today/upcoming filter versus week navigation.
Phase 12: Native Tablo Chat
Goal: Each tablo has a native persisted discussion stream with real-time updates and no managed chat/realtime provider. Mode: mvp Requirements: CHAT-01, CHAT-02, CHAT-03, CHAT-04, CHAT-05, CHAT-06 Success Criteria:
- Tablo detail page includes a discussion view that loads persisted message history
- User can post a text message with CSRF protection and server-side validation
- Messages persist in Postgres with tablo, author, body, created timestamp, and edit/delete metadata
- A second open browser receives new messages without manual refresh
- Implementation uses Xtablo-owned infrastructure only; no managed chat/realtime provider or external realtime runtime is added
- Message rendering escapes user content and enforces a maximum body length
- Streaming behavior is verified behind the local/prod reverse proxy path, including keep-alives or buffering behavior
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.
Coverage
- v2.0 requirements: 27
- Mapped to phases: 27
- Unmapped: 0
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