# 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 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 | 2/4 | In Progress| | | 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 while Xtablo keeps owning user accounts and sessions; Apple sign-in is disabled and hidden for now. **Mode:** mvp **Status:** Complete **Requirements:** AUTH-08, AUTH-09, AUTH-10, AUTH-11, AUTH-12, AUTH-13 **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 **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:** 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 **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:** 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 **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:** 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 **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:** 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 **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*