Xtablo — Go + HTMX Product

What This Is

A Go + HTMX version of Xtablo centered on tablos as collaborative workspaces. v1 established the authenticated Tablos workflow (tasks, files, worker, deploy); v2 added collaboration, messaging, etapes, events, planning, and Google sign-in; v3 ported the full design system from the reference JS app — CSS token vocabulary, typed templ component library, and a visual reskin of every surface.

Built for a developer who wants a simpler, durable product stack: one Go server, Postgres, server-rendered UI, and no managed chat provider.

Core Value

A user can sign in and run the Tablos workflow — organize work, attach files, discuss, and plan scheduled events — without a JS framework or managed chat provider.

If everything else fails, this must work end-to-end on a single Go binary backed by Postgres and an S3-compatible bucket.

Current Milestone: v4.0 Figma Design Parity

Goal: Bring every product surface to match the Figma design — new task views (grid + roadmap), calendar rework, navigation refresh, and tablo list revamp.

Target features:

Navigation bar + top header redesigned to match Figma
Tablo list: project card revamp + card/list view toggle
Tasks: restyle kanban + new grid view + new roadmap view
Calendar: restyle /planning as Google Calendar-style (month/week/day navigation, proper event blocks)
Tablo detail view restyled to match Figma

Shipped: v3.0 Design System & Visual Polish (2026-05-17)

Delivered: Full CSS token vocabulary and typed templ component library (11 types) applied to every surface — auth pages, app shell sidebar, tablo list, tablo detail, chat, and planning. Build-tag-gated /ui-catalog visual verification page included.

Requirements

Validated

✓ Server-managed sessions with email/password auth — Phase 2 (v1.0)
✓ Tablos CRUD with ownership — Phase 3 (v1.0)
✓ Tasks kanban with drag-and-drop reorder — Phase 4 (v1.0)
✓ File attachments with orphan cleanup worker — Phases 5–6 (v1.0)
✓ Single-binary production deploy with Caddy TLS — Phase 7 (v1.0)
✓ Google sign-in (server-managed sessions) — Phase 8 (v2.0)
✓ Etapes as one-level task wrappers — Phase 9 (v2.0)
✓ Tablo events with CRUD — Phase 10 (v2.0)
✓ Individual planning view (/planning) — Phase 11 (v2.0)
✓ Native per-tablo chat with real-time SSE — Phase 12 (v2.0)
✓ CSS design token vocabulary + typed templ component library (11 types) in backend/internal/web/ui — Phase 13 (v3.0)
✓ Auth pages (login/signup) match JS app visual — Phase 14 (v3.0)
✓ App shell sidebar + project-card tablo grid — Phase 15 (v3.0)
✓ Tablo detail (tasks, etapes, files) restyled with design system components — Phase 16 (v3.0)
✓ Chat and planning views visually consistent with app shell — Phase 17 (v3.0)

Active

Navigation bar + top header redesigned to match Figma
Tablo list project card revamped to match Figma
Tablo list card/list view toggle
Tasks kanban restyled to match Figma
Tasks grid view (new — brand new data model + UI)
Tasks roadmap view (new — brand new)
Planning page restyled as Google Calendar-style (month/week/day, event blocks)
Tablo detail view restyled to match Figma

Out of Scope

Managed chat/messaging providers — no Stream Chat, Ably, Pusher, Firebase Realtime Database, or equivalent for v2 chat
Stripe / billing — defer monetization until product loop is validated
Public booking widget — apps/external rewrite not in v1 (may return in a later milestone)
Client portal — apps/clients magic-link experience deferred
Admin app — apps/admin internal tooling deferred
Notes / rich documents inside a Tablo — not part of this milestone
Managed auth platforms — no Clerk/Auth0/Lucia; Google and Apple are identity providers only, with Xtablo still owning users and sessions
Mobile / Expo app — out of scope for this rewrite
Supabase as a runtime dependency — Postgres only; Supabase Auth / RLS replaced by Go-side authz
The existing go-backend/ directory — treated as scratch; new code lives in a fresh backend/ Go package

Context

The JS monorepo (this repository) is the source of truth for product behavior and is fully mapped in .planning/codebase/ (ARCHITECTURE, STACK, STRUCTURE, INTEGRATIONS, CONVENTIONS, CONCERNS, TESTING). Use these to derive expected behavior — but the rewrite is free to simplify both schema and visuals.
The DB schema will change during the rewrite — the JS version's Supabase schema is a reference, not a constraint. The user wants to be in the loop on schema decisions for each domain (users/sessions, tablos, tasks, files).
v3.0 shipped the full design system and visual reskin. backend/internal/web/ui now has: CSS token vocabulary, 11 typed templ components, an app shell, and surface-specific CSS (auth, dashboard, tablo detail, chat, planning).
Current backend source footprint: ~18,600 non-test Go LOC + ~3,400 templ LOC.
Developer is comfortable in Go and wants a low-dependency, server-rendered stack going forward.
Known stubs shipped in v3.0: tablo status field hardcoded as "En cours", progress bar hardcoded at 0% — both require a DB schema extension to wire properly.

Constraints

Tech stack: Go (server + templates) + HTMX + Tailwind + Postgres + sqlc — no JS framework, no managed BaaS
Auth: Server-managed sessions remain authoritative; Google/Apple sign-in may verify external ID tokens but must end by issuing Xtablo's own session cookie
Chat: No third-party chat provider; messages and read state live in Postgres, with real-time delivery handled by the Go app
Storage: Files in S3-compatible object storage (Cloudflare R2 to start)
Architecture: One web server binary + one background worker (same repo, possibly same binary with subcommand)
Deploy target: Single VPS / container — no Kubernetes
Planning: Events belong to tablos, but each individual user can access their own planning view
Etapes: One level only — a task can have at most one parent/wrapper, and a parent cannot itself have a parent
Scope discipline: v2 adds collaboration and planning only; billing, booking, portal, admin, notes, and mobile remain deferred

Key Decisions

Decision	Rationale	Outcome
Rewrite in Go + HTMX (no SPA)	Simpler stack, developer preference, product pivot	✓ Validated through v1-v2
Built-in sessions, no 3rd-party auth	Avoid vendor coupling; sessions are well-trodden ground	✓ Validated through email/password and Google sign-in
Drop Supabase (keep Postgres)	Owning the auth + RLS story in Go is simpler than maintaining the boundary	✓ Validated through owned authz queries
Fresh `backend/` Go package, set `go-backend/` aside	Existing scaffold has decisions to revisit; cleaner to start over	✓ Validated
v1 = Tablos workflow only (Tasks + Files), defer chat/billing/booking/portal/admin	Focus the rewrite around the load-bearing user loop first	✓ Completed
Single binary + background worker, single VPS deploy	Matches the "simpler stack" thesis; avoid orchestration cost early	✓ Validated for current deploy target
User-in-the-loop on Postgres schema for each domain	Schema is changing from JS version; explicit review before sqlc generation	— Pending
v2 chat is native, not vendor-backed	User explicitly does not want third-party chat; Postgres + Go should be enough for the first real-time version	✓ Validated with SSE receive + HTMX POST send
Google/Apple are identity providers only	Preserve server-owned users/sessions while allowing social sign-in	✓ Google validated; Apple disabled for now
Etapes are one-level wrappers around tasks	Matches the requested mental model and avoids recursive planning complexity	✓ Validated
Planning is individual, events remain tablo-scoped	Lets users see their schedule while preserving tablos as the source of work context	✓ Validated
Design system lives in `backend/internal/web/ui` (not go-backend)	Keep all production code in `backend/`; go-backend is scratch/reference only	✓ Validated — all 11 components + token CSS in backend/
Build-tag-gated `/ui-catalog` route for design system verification	Catalog must not ship in production; build tags are the idiomatic Go mechanism	✓ Validated — production build passes, catalog isolated
Tablo status + progress bar shipped as visual stubs	DB schema extension needed; unblocking is lower value than shipping the visual design	⚠️ Revisit — stub needs wiring in v4.0
Air config extended to watch .css files and run Tailwind CLI on rebuild	CSS edits require Tailwind rebuild; air restarts on template changes but not CSS without this	✓ Validated

Evolution

This document evolves at phase transitions and milestone boundaries.

After each phase transition (via /gsd-transition):

Requirements invalidated? → Move to Out of Scope with reason
Requirements validated? → Move to Validated with phase reference
New requirements emerged? → Add to Active
Decisions to log? → Add to Key Decisions
"What This Is" still accurate? → Update if drifted

After each milestone (via /gsd-complete-milestone):

Full review of all sections
Core Value check — still the right priority?
Audit Out of Scope — reasons still valid?
Update Context with current state

Phase History

Phase 1: Foundation — Completed 2026-05-14. Fresh backend/ Go package boots a web server, renders an HTMX-driven base layout, connects to local Postgres with goose migrations. FOUND-01..FOUND-05 satisfied; user-approved manual walkthrough. Two inline justfile/tailwind fixes during UAT (commit fix(01): guard sqlc on empty queries and correct tailwind paths).
Phase 7: deploy-v1 — Completed 2026-05-15. Multi-stage Dockerfile (assets→builder→distroless nonroot), docker-compose.prod.yaml with 4 services (postgres/web/worker/caddy), Caddyfile with {$DOMAIN} TLS, README runbook covering first-deploy/rollback/incident. DEPLOY-01..DEPLOY-05 satisfied. 3 UAT items (Docker build, compose config, live smoke test) pending on a Docker-equipped machine.
Milestone v2.0 started: Collaboration, planning, and social sign-in — Started 2026-05-15. Scope: native per-tablo chat, one-level etapes, Google/Apple sign-in, and individual planning with tablo events.
Milestone v2.0 shipped: Collaboration, planning, and social sign-in — Shipped 2026-05-16. Delivered Google sign-in, etapes, events, individual planning, and native SSE-backed tablo discussions. Closed with 7 acknowledged deferred artifact items; see .planning/milestones/v2.0-MILESTONE-AUDIT.md.

Last updated: 2026-05-17 after v4.0 milestone start — Figma design parity milestone defined

11 KiB Raw Permalink Blame History Unescape Escape