109 lines
6 KiB
Markdown
109 lines
6 KiB
Markdown
# 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
|
|
**Requirements:** AUTH-08, AUTH-09, AUTH-10, AUTH-11, AUTH-12, AUTH-13
|
|
**Success Criteria:**
|
|
1. Login/signup page shows Google and Apple sign-in entry points alongside email/password
|
|
2. Google callback validates state, exchanges authorization code, verifies ID token, creates or links `user_identities`, and issues a local session
|
|
3. Apple callback validates state/nonce, exchanges authorization code, verifies ID token, creates or links `user_identities`, and issues a local session
|
|
4. Existing email/password signup/login/logout tests still pass unchanged
|
|
5. `.env.example` and 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:**
|
|
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*
|