diff --git a/.planning/phases/20-tablo-detail-kanban-restyle/20-RESEARCH.md b/.planning/phases/20-tablo-detail-kanban-restyle/20-RESEARCH.md new file mode 100644 index 0000000..af350fc --- /dev/null +++ b/.planning/phases/20-tablo-detail-kanban-restyle/20-RESEARCH.md @@ -0,0 +1,616 @@ +# Phase 20: Tablo Detail & Kanban Restyle - Research + +**Researched:** 2026-05-18 +**Domain:** Go + HTMX + Tailwind + templ — new page creation + CSS restyle +**Confidence:** HIGH + +--- + +## Summary + +Phase 20 has two intertwined goals: (1) create a **tablo detail page** that does not yet exist in the codebase, and (2) deliver the Figma-matching visual restyle for that page's kanban board and task cards. The current Go backend has no `GET /tablos/{tabloID}` route — clicking a tablo in the list has no detail view. This phase must build the page from scratch, then style it to match the UI-SPEC. + +The existing kanban implementation lives exclusively inside the global `/tasks` page (`tasks.templ` → `TasksKanbanLayout`). That layout uses a CSS grid (`grid-cols-1 md:grid-cols-2 lg:grid-cols-4`) and the `TaskCard` component. The tablo detail kanban is a separate surface: a flex-row of fixed-width columns (18rem each, `overflow-x: auto`) scoped to one tablo, with Sortable.js drag-and-drop. The Phase 4 code (task creation, reorder handler, Sortable.js init) for the tablo-detail kanban currently exists only in `router_test.go` integration tests referencing `ListTasksByTablo`, implying it was coded in a previous milestone's tablo detail handler that was later replaced by `go-backend/`. All task mutation infrastructure (CreateTask, GetTaskByID, UpdateTask, SoftDeleteTask, ListTasksByTablo) exists in the repository layer and in the InMemory test repository — it just has no route-level handler wiring for the detail page. + +The primary recommendation: build `GET /tablos/{tabloID}` as a new handler + templ component, add `GET/POST /tablos/{tabloID}/tasks/...` for task CRU within the detail context, implement the tab-bar, and apply the full CSS restyle from `20-UI-SPEC.md` in `app.css`. + +**Primary recommendation:** Create the tablo detail page as a new handler + view layer; reuse existing `ListTasksByTablo` and task mutation repo methods; apply all UI-SPEC CSS changes to `app.css` and the new templ components. + +--- + +## Architectural Responsibility Map + +| Capability | Primary Tier | Secondary Tier | Rationale | +|------------|-------------|----------------|-----------| +| Tablo detail route (`GET /tablos/{tabloID}`) | Go handler (server) | — | Fetches tablo record + tasks, builds view model, renders templ | +| Tab bar (Overview/Tasks/Files/Discussion/Events) | templ template | — | Static HTML tabs, HTMX push-url for navigation | +| Kanban board layout | templ template (`tablos_detail.templ`) | CSS (`app.css`) | Column+card HTML; flex layout and card styles in CSS | +| Task CRUD within detail | Go handler (server) | — | CreateTask/UpdateTask/DeleteTask/ReorderTask scoped to tabloID | +| Drag-and-drop reorder | Browser (Sortable.js) | Go handler (reorder endpoint) | JS-side drag; server persists new order via existing handler pattern | +| Progress bar computation | Go handler (server) | — | doneTasks/totalTasks computed at render time from task list | +| CSS restyle (cards, columns, header) | CSS (`app.css`) | — | Token-based rules; no new tokens needed | +| Files tab (restyle only) | templ + CSS | — | Existing `ui.Table`; add border/radius wrapper and header style | + +--- + + +## Phase Requirements + +| ID | Description | Research Support | +|----|-------------|------------------| +| DETAIL-01 | Tablo detail page (header, tasks section, etapes section, files table) is restyled to match Figma | New `GET /tablos/{tabloID}` handler + `TabloDetailPage` templ component + CSS in `app.css` matching UI-SPEC tokens | +| TASK-01 | Kanban board columns, task cards, and drag-and-drop are restyled to match Figma | New tablo-scoped kanban templ + `.task-card` CSS block in `app.css`; Sortable.js init preserved verbatim | + + +--- + +## Standard Stack + +### Core (existing — no new packages) + +| Library | Version | Purpose | Why Standard | +|---------|---------|---------|--------------| +| `github.com/a-h/templ` | existing | HTML components | Entire view layer uses templ | +| Sortable.js | CDN (existing) | Drag-and-drop | Already wired in router_test; Phase 4 integration | +| HTMX | CDN v4.0.0-beta2 (existing) | Partial page swaps | Entire app uses HTMX for navigation | +| Tailwind CSS | existing build | Utility classes | Used alongside custom CSS classes | + +### No new packages needed + +The UI-SPEC explicitly confirms: "No external registries. All components are templ + custom CSS." All needed UI primitives (`ui.Button`, `ui.IconButton`, `ui.Badge`, `ui.Table`) exist in `backend/internal/web/ui/`. + +**Installation:** none required. + +--- + +## Package Legitimacy Audit + +> No new packages to install in this phase. The phase is purely a restyle + new page creation using existing infrastructure. + +**Packages removed due to slopcheck:** none +**Packages flagged as suspicious:** none + +--- + +## Architecture Patterns + +### System Architecture Diagram + +``` +Browser + │ GET /tablos/{tabloID} + ▼ +Go handler: GetTabloDetailPage + │ repo.ListTablos (find single tablo by ID + owner check) + │ repo.ListTasksByTablo (fetch tasks for this tablo) + │ compute progress: doneTasks / totalTasks * 100 + ▼ +TabloDetailPageViewModel {tablo, tasks by status column, progress} + │ + ▼ +templ: TabloDetailPage + ├── TabloDetailHeader (name h1, status badge, progress bar, owner row) + ├── TabloTabBar (Overview | Tasks | Files | Discussion | Events) + └── tab: Tasks → KanbanBoardSection + ├── KanbanColumn × 4 (Todo / In Progress / In Review / Done) + │ ├── ColumnHeader (title, count badge, "+ Add" link) + │ └── TaskCardList (sortable-column) + │ └── TaskCard × N (drag-handle, title, delete icon) + └── TaskCreateInlineForm (htmx fragment, within column) + +Browser + Sortable.js init (DOMContentLoaded + htmx:afterSettle) + handles: .sortable-column containers + POST /tablos/{tabloID}/tasks/reorder (existing reorder pattern) +``` + +### Recommended Project Structure + +New files to create: + +``` +go-backend/internal/web/ +├── views/ +│ ├── tablo_detail.templ # TabloDetailPage + all sub-components +│ └── tablo_detail_view.go # TabloDetailViewModel + helpers +├── handlers/ +│ └── tablo_detail.go # GetTabloDetailPage handler +``` + +Modified files: + +``` +go-backend/ +├── router.go # Add GET /tablos/{tabloID} +├── internal/web/ui/app.css # All CSS changes from UI-SPEC delta table +``` + +### Pattern 1: Tablo Detail Handler (new page + HTMX swap) + +```go +// Source: existing handler pattern from handlers/auth.go + handlers/tablos.go +func (h *AuthHandler) GetTabloDetailPage() http.HandlerFunc { + return func(w http.ResponseWriter, r *http.Request) { + user, ok := h.authenticatedUser(r.Context(), r) + if !ok { + http.Redirect(w, r, "/login", http.StatusSeeOther) + return + } + + tabloID, err := uuid.Parse(r.PathValue("tabloID")) + if err != nil { + http.Error(w, "invalid tablo id", http.StatusBadRequest) + return + } + + // Reuse ListTablos to find the owned tablo (no GetTabloByID sqlc query exists) + tablos, err := h.repo.ListTablos(r.Context(), ListTablosInput{OwnerID: user.ID}) + if err != nil { + http.Error(w, "failed to load tablos", http.StatusInternalServerError) + return + } + tablo, ok := findTabloByID(tablos, tabloID) + if !ok { + http.Error(w, "tablo not found", http.StatusNotFound) + return + } + + // ListTasksByTablo is defined in the repo and InMemory repo + taskRepo := h.repo.(interface { + ListTasksByTablo(context.Context, ListTasksByTabloInput) ([]TaskRecord, error) + }) + tasks, err := taskRepo.ListTasksByTablo(r.Context(), ListTasksByTabloInput{ + OwnerID: user.ID, + TabloID: tabloID, + }) + if err != nil { + http.Error(w, "failed to load tasks", http.StatusInternalServerError) + return + } + + vm := views.NewTabloDetailViewModel(tablo, tasks) + content := views.TabloDetailPage(vm) + + w.Header().Set("Content-Type", "text/html; charset=utf-8") + var renderErr error + if isHXRequest(r) { + renderErr = views.DashboardContentSwap("/tablos/"+tabloID.String(), tablos, content).Render(r.Context(), w) + } else { + renderErr = views.DashboardPage("/tablos/"+tabloID.String(), tablos, content).Render(r.Context(), w) + } + if renderErr != nil { + http.Error(w, "failed to render tablo detail", http.StatusInternalServerError) + } + } +} +``` + +**[ASSUMED]** — GetTabloByID does not exist in sqlc queries; using ListTablos + findTabloByID is the current pattern from GetEditTabloModal. For a large tablo list this is an O(n) scan. At v1 scale this is acceptable. + +### Pattern 2: Progress Computation + +```go +// Source: [ASSUMED] — derived from existing tabloStatusPresentation pattern +func computeTabloProgress(tasks []TaskRecord) int { + total := len(tasks) + if total == 0 { + return 0 + } + var done int + for _, t := range tasks { + if t.Status == TaskStatusDone { + done++ + } + } + return (done * 100) / total +} +``` + +### Pattern 3: Kanban Column templ (new, scoped to tablo detail) + +```templ +// Source: UI-SPEC + existing TasksKanbanLayout pattern +templ TabloDetailKanbanColumn(col TabloDetailColumnView) { +
+
+ { col.Label } + { len(col.Tasks) } + + + Ajouter + +
+
+ for _, task := range col.Tasks { + @TabloDetailTaskCard(task) + } +
+
+
+} +``` + +### Pattern 4: Drag Handle (opacity-based hover) + +```css +/* Source: UI-SPEC Component Delta section */ +.task-drag-handle { + color: var(--color-text-faint); + cursor: grab; + font-size: 1rem; + opacity: 0; + transition: opacity 0.12s ease; +} + +.task-card:hover .task-drag-handle { + opacity: 1; +} +``` + +### Pattern 5: Sortable.js init (preserved from Phase 4) + +```javascript +// Source: [ASSUMED] — Sortable.js init pattern from STATE.md Phase 4 decisions +// Must fire on DOMContentLoaded AND htmx:afterSettle +function initSortable() { + document.querySelectorAll('.sortable-column').forEach(function(el) { + if (el._sortable) return; // idempotent + el._sortable = Sortable.create(el, { + group: 'tablo-tasks', + animation: 150, + handle: '.task-drag-handle', + draggable: '.task-card', + onEnd: function(evt) { + // Update hidden reorder form + submit + document.querySelector('#reorder-form').requestSubmit(); + } + }); + }); +} +document.addEventListener('DOMContentLoaded', initSortable); +document.addEventListener('htmx:afterSettle', initSortable); +``` + +The UI-SPEC states: "Sortable.js initialization on `DOMContentLoaded` and `htmx:afterSettle` is PRESERVED verbatim." + +### Anti-Patterns to Avoid + +- **Using `display: none` for drag handle / delete icon:** UI-SPEC requires `opacity: 0 → 1` (not display-toggling) to preserve layout during hover. +- **Mixing global tasks kanban with tablo-detail kanban:** The `TasksKanbanLayout` in `tasks.templ` is for the global `/tasks` page and must remain unchanged. The tablo detail gets a new separate `TabloDetailKanbanLayout`. +- **Adding a task-view switcher (Board/List/Gantt):** UI-SPEC explicitly defers the inner task-view switcher to Phase 21. Do not add it. +- **Using inline Tailwind for the card restyle:** The UI-SPEC defines `.task-card` as a named CSS class in `app.css`. Inline Tailwind classes on these components would conflict with the CSS cascade. +- **Routing task create/delete to global `/tasks` endpoints:** Task mutations within the detail page must include `tabloID` context so the response re-renders the detail page, not the global tasks page. + +--- + +## Don't Hand-Roll + +| Problem | Don't Build | Use Instead | Why | +|---------|-------------|-------------|-----| +| Drag-and-drop column reorder | Custom JS drag | Sortable.js (already included) | Phase 4 already wired; re-implementing is regression risk | +| Status badge pill | Custom badge HTML | `ui.Badge` with `badgeVariantForTone` | Already has all required tone variants in `badge.css` | +| Modal dialog | Raw HTML `` | `ui.Modal` | Already exists in `modal.templ` + `modal.css` | +| Progress bar math | Separate API endpoint | Compute inline in handler from task list | Task list already fetched; no extra query needed | +| Table wrapper | Custom `` | `ui.Table` + wrapper div | `ui.Table` handles shell; Phase 20 adds `border/radius` wrapper div around it | + +--- + +## Common Pitfalls + +### Pitfall 1: No `GetTabloByID` sqlc query +**What goes wrong:** Code tries to call `h.repo.GetTabloByID(...)` which doesn't exist in the `AuthRepository` interface or sqlc. +**Why it happens:** The repository only exposes `ListTablos` (filtered list). No single-record lookup was added in earlier phases. +**How to avoid:** Use `findTabloByID(tablos, tabloID)` after `ListTablos`. This is the same pattern used in `GetEditTabloModal`. +**Warning signs:** Compiler error: `AuthRepository has no method GetTabloByID`. + +### Pitfall 2: `ListTasksByTablo` not in `AuthRepository` interface +**What goes wrong:** `h.repo` is typed as `AuthRepository` which does not include `ListTasksByTablo`. The method is only on `taskPageRepository` interface (defined in `handlers/tasks.go`). +**Why it happens:** `AuthRepository` in `handlers/auth.go` was not extended with task methods. +**How to avoid:** Either (a) add a `TabloDetailRepository` interface combining the needed methods, or (b) type-assert `h.repo.(taskDetailRepository)` the same way `renderTasksPage` does. Pattern (b) requires the InMemoryAuthRepository to also implement `ListTasksByTablo` — it already does (`in_memory_auth_repository.go:168`). +**Warning signs:** Compiler error about interface satisfaction. + +### Pitfall 3: HTMX active-path mismatch in sidebar +**What goes wrong:** The sidebar nav item for the current tablo is not highlighted when viewing `/tablos/{tabloID}`. +**Why it happens:** `sidebarNavItemID` uses the href to generate DOM IDs; tablo-detail is a sub-path that doesn't match any primary nav item's `Href`. +**How to avoid:** Pass `activePath` as `/tablos` (the parent) for all tablo detail pages so the sidebar "Tablos" nav item remains active. + +### Pitfall 4: Sortable.js double-init after HTMX swap +**What goes wrong:** After an HTMX swap refreshes the kanban (e.g., after task create), Sortable.js is initialized again, creating a second instance on already-initialized containers, causing duplicate handlers. +**Why it happens:** `htmx:afterSettle` fires every time a swap completes; naive re-init doesn't check for existing instances. +**How to avoid:** Guard init with `if (el._sortable) return;` — set `el._sortable` on first init. + +### Pitfall 5: `progressInlineStyle` uses `var(--project-color)` +**What goes wrong:** The progress bar fill color on the tablo detail page matches the project color instead of `var(--color-brand-primary)` as specified. +**Why it happens:** The existing `.project-progress-bar` rule uses `background: var(--project-color, var(--color-project-fallback))` — inherited from Phase 19 tablo cards. +**How to avoid:** UI-SPEC says "Change fill color from `var(--project-color)` to `var(--color-brand-primary)`". Apply a scoped override for the detail page header progress bar: `.tablo-detail-header .project-progress-bar { background: var(--color-brand-primary); }` — or use a separate CSS class `tablo-progress-bar` on the detail page's progress element. + +### Pitfall 6: Tablo `Status` vs task `Status` confusion +**What goes wrong:** The tablo status field (`todo/in_progress/done`) is used to drive the progress bar value (0/50/100) on tablo cards — but this is NOT the task completion progress. The tablo detail header's progress must be computed from actual task statuses (done tasks / total tasks), not the tablo's own status field. +**Why it happens:** `buildTabloCardViews` uses `tabloStatusPresentation(tablo.Status)` to set `Progress: 50` for in-progress tablos — that's a placeholder. +**How to avoid:** In the detail handler, compute `progress = computeTabloProgress(tasks)` from real task records. + +--- + +## Code Examples + +### CSS: `.task-card` new block (from UI-SPEC) + +```css +/* Source: 20-UI-SPEC.md Surfaces: Kanban Board → Task cards */ +.task-card { + background: var(--color-surface-default); + border: 1px solid var(--color-border-default); + border-radius: 8px; + cursor: pointer; + display: flex; + flex-direction: column; + gap: 8px; + padding-inline: 12px; + padding-block: 8px; + transition: box-shadow 0.12s ease, border-color 0.12s ease; +} + +.task-card:hover { + border-color: var(--color-border-strong); + box-shadow: 0 8px 24px rgba(15, 23, 42, 0.08); +} +``` + +### CSS: Kanban column border-radius change + +```css +/* Source: 20-UI-SPEC.md Component Delta table — change 1rem → 0.75rem */ +.tablo-kanban-column { + background: var(--color-surface-default); + border: 1px solid var(--color-border-default); + border-radius: 0.75rem; /* was 1rem in tasks-section */ + overflow: hidden; + width: 18rem; + flex-shrink: 0; +} +``` + +### CSS: Task list gap + +```css +/* Source: 20-UI-SPEC.md Component Delta — add gap: 8px; padding: 8px */ +.task-list { + display: flex; + flex-direction: column; + gap: 8px; + padding: 8px; +} +``` + +### CSS: Kanban board container + +```css +/* Source: 20-UI-SPEC.md Surfaces: Kanban Board → Board container */ +.tablo-kanban-board { + display: flex; + gap: 16px; + overflow-x: auto; + padding-bottom: 16px; +} +``` + +### CSS: Empty column state + +```css +/* Source: 20-UI-SPEC.md Surfaces: Kanban Board → Empty column state */ +.tablo-kanban-empty { + color: var(--color-text-faint); + font-size: 0.875rem; + padding: 24px 16px; + text-align: center; +} +``` + +### CSS: Files table wrapper restyle + +```css +/* Source: 20-UI-SPEC.md Surfaces: Files Table */ +.tablo-files-table-wrapper { + border: 1px solid var(--color-border-default); + border-radius: 12px; + overflow: hidden; +} + +.tablo-files-table-wrapper thead tr { + background: var(--color-surface-muted); +} + +.tablo-files-table-wrapper thead th { + color: var(--color-text-muted); + font-size: 0.75rem; + font-weight: 600; + letter-spacing: 0.04em; + text-transform: uppercase; +} + +.tablo-files-table-wrapper tbody tr { + border-bottom: 1px solid var(--color-border-default); +} + +.tablo-files-table-wrapper tbody tr:hover { + background: var(--color-surface-subtle); +} +``` + +### templ: Tablo detail header layout + +```templ +// Source: [ASSUMED] — pattern derived from UI-SPEC header spec +templ TabloDetailHeader(vm TabloDetailHeaderView) { +
+
+
+ { vm.Initial } +
+

{ vm.Name }

+
+
+ + + + + @ActionIcon("calendar") + if vm.DueDate != "" { vm.DueDate } else { "—" } + + + @ui.Badge(ui.BadgeProps{Label: vm.StatusLabel, Variant: badgeVariantForTone(vm.StatusTone)}) + + +
+
+
+ { vm.ProgressLabel } + +
+
+} +``` + +--- + +## State of the Art + +| Old Approach | Current Approach | When Changed | Impact | +|--------------|------------------|--------------|--------| +| Tablo progress = tablo.Status mapped to 0/50/100 | Compute from actual task done/total ratio | Phase 20 | Detail page shows real progress | +| No tablo detail page | `GET /tablos/{tabloID}` with tab bar | Phase 20 | First time users can navigate into a tablo | +| Global kanban (flat grid, `grid-cols-4`) | Tablo-scoped kanban (flex row, `overflow-x: auto`) | Phase 20 | Detail page kanban vs global tasks page kanban | + +**Deprecated/outdated:** +- `.project-progress-bar { background: var(--project-color) }` for detail page use: replaced by `var(--color-brand-primary)` per UI-SPEC. +- `.tasks-section { border-radius: 1rem }` in cards context: changed to `0.75rem` for kanban columns. + +--- + +## Assumptions Log + +| # | Claim | Section | Risk if Wrong | +|---|-------|---------|---------------| +| A1 | `GetTabloByID` sqlc query does not exist; must use `ListTablos + findTabloByID` | Pitfall 1 | If a GetTabloByID query was added via `just generate` after last codebase read, handler can be simplified — low risk either way | +| A2 | `ListTasksByTablo` is not in `AuthRepository` interface; needs type assertion or new interface | Pitfall 2 | If someone added it to the interface, no type-assert needed | +| A3 | Sortable.js CDN is already loaded on the tablo detail page | Pattern 5 | If Sortable.js is not in `DashboardPage` head, it must be added | +| A4 | The tablo detail page has no existing route and no existing templ component | Standard Stack | If a partial implementation exists in a branch, avoid duplication | +| A5 | Files tab shows files from the tablo's R2 bucket; no file listing query currently exists for tablo-scoped files | Files Table section | Phase 20 UI-SPEC says "restyle only" — implies files list already renders. If no file data available, the files tab renders with empty state only | + +--- + +## Open Questions + +1. **Tablo detail route navigation from tablo cards** + - What we know: `TabloGridCard` and `TabloListRow` in `tablos.templ` have no `hx-get` to the detail page — they have edit/delete buttons only. + - What's unclear: Should clicking the card title navigate to detail? Or is there a separate "View" button? + - Recommendation: Make the card title/avatar an `hx-get="/tablos/{id}"` link, consistent with the linear-style navigation pattern. + +2. **Files tab data for tablo detail** + - What we know: The UI-SPEC says "restyle only" for the files table. No file listing sqlc query for tablo-scoped files was found. + - What's unclear: Are files accessible? Is there a `ListFilesByTablo` repo method? + - Recommendation: If no files query exists, render files tab with empty state (`ui.EmptyState`) only — no blocking dependency for TASK-01 or DETAIL-01. + +3. **Owner display for tablo detail header** + - What we know: `tablo.OwnerID` exists; `GetPublicUserByID` exists in `AuthRepository`. + - What's unclear: Whether the handler should fetch the owner record for display. + - Recommendation: Fetch owner display name in handler via `GetPublicUserByID` for the metadata row. Falls back to "Propriétaire" if fetch fails. + +--- + +## Environment Availability + +> Phase is code/CSS only. No new external tools or services required. + +**Step 2.6: SKIPPED** — No external dependencies beyond existing Go toolchain, templ, and Tailwind build already in place. + +--- + +## Validation Architecture + +### Test Framework + +| Property | Value | +|----------|-------| +| Framework | Vitest (frontend not applicable) / Go stdlib `testing` + `net/http/httptest` | +| Config file | none (Go stdlib test runner) | +| Quick run command | `go test ./... -run TestTabloDetail -count=1` | +| Full suite command | `go test ./... -count=1` | + +### Phase Requirements → Test Map + +| Req ID | Behavior | Test Type | Automated Command | File Exists? | +|--------|----------|-----------|-------------------|-------------| +| DETAIL-01 | `GET /tablos/{tabloID}` returns 200 with tablo name in response | unit/integration | `go test ./... -run TestGetTabloDetailPage -count=1` | ❌ Wave 0 | +| DETAIL-01 | Progress bar percentage rendered as `{N}%` in response | unit | `go test ./... -run TestTabloDetailProgress -count=1` | ❌ Wave 0 | +| DETAIL-01 | Status badge label rendered in metadata row | unit | `go test ./... -run TestTabloDetailStatusBadge -count=1` | ❌ Wave 0 | +| TASK-01 | Kanban columns render 4 status columns | unit | `go test ./... -run TestTabloDetailKanbanColumns -count=1` | ❌ Wave 0 | +| TASK-01 | Task cards contain `.task-card` class | unit | `go test ./... -run TestTabloDetailTaskCardMarkup -count=1` | ❌ Wave 0 | +| TASK-01 | Drag handle has `opacity:0` at rest (CSS class present) | unit | `go test ./... -run TestTabloDetailDragHandle -count=1` | ❌ Wave 0 | + +### Sampling Rate +- **Per task commit:** `go test ./... -run TestTabloDetail -count=1` +- **Per wave merge:** `go test ./... -count=1` +- **Phase gate:** Full suite green before `/gsd:verify-work` + +### Wave 0 Gaps +- [ ] `go-backend/internal/web/handlers/tablo_detail_test.go` — covers all DETAIL-01 + TASK-01 handler tests +- [ ] `go-backend/router_test.go` additions — integration-level smoke test for `GET /tablos/{tabloID}` + +*(Existing test infrastructure in `handlers/tablos_test.go` provides the scaffold pattern to follow.)* + +--- + +## Security Domain + +### Applicable ASVS Categories + +| ASVS Category | Applies | Standard Control | +|---------------|---------|-----------------| +| V2 Authentication | yes | `authenticatedUser(r.Context(), r)` — existing session check, same as all other handlers | +| V3 Session Management | yes | existing `xtablo_session` cookie pattern | +| V4 Access Control | yes | `findTabloByID` filters by `OwnerID` — prevents accessing other users' tablos | +| V5 Input Validation | yes | `uuid.Parse(r.PathValue("tabloID"))` guards invalid IDs | +| V6 Cryptography | no | No crypto in this phase | + +### Known Threat Patterns for this stack + +| Pattern | STRIDE | Standard Mitigation | +|---------|--------|---------------------| +| IDOR — access another user's tablo by guessing UUID | Elevation of Privilege | `findTabloByID` only returns tablos owned by authenticated user's ID | +| Task mutation across tablo boundary | Tampering | `ListTasksByTablo` includes `OwnerID` in query; UpdateTask/DeleteTask handlers enforce ownership | + +--- + +## Sources + +### Primary (HIGH confidence) +- `/go-backend/internal/web/ui/base.css` — all CSS custom property tokens confirmed +- `/go-backend/internal/web/ui/app.css` — existing `.task-row`, `.project-progress-bar`, `.tasks-section` CSS rules +- `/go-backend/internal/web/views/tasks.templ` — existing `TasksKanbanLayout`, `TaskCard`, `TasksKanbanColumnView` patterns +- `/go-backend/internal/web/views/tablos.templ` — existing `TabloGridCard`, header/progress patterns +- `/go-backend/internal/web/handlers/tablos.go` — `findTabloByID`, `tabloStatusPresentation`, existing handler patterns +- `/go-backend/internal/web/handlers/auth.go` — `AuthRepository` interface definition (no `ListTasksByTablo`) +- `/go-backend/router.go` — confirmed no `GET /tablos/{tabloID}` route exists +- `/go-backend/internal/tablos/model.go` — tablo model fields confirmed +- `/go-backend/internal/tasks/model.go` — task status enums, `ListByTabloInput` +- `.planning/phases/20-tablo-detail-kanban-restyle/20-UI-SPEC.md` — locked visual decisions + +### Secondary (MEDIUM confidence) +- `.claude/skills/sketch-findings-xtablo-source/SKILL.md` — design direction and CSS patterns verified against existing `base.css` tokens + +### Tertiary (LOW confidence) +- `[ASSUMED]` items in the Assumptions Log above — architectural inferences from existing handler patterns + +--- + +## Metadata + +**Confidence breakdown:** +- Standard stack: HIGH — confirmed from codebase; no new packages +- Architecture: HIGH — detail page gap confirmed, handler patterns confirmed, CSS tokens confirmed +- Pitfalls: HIGH — confirmed from direct code inspection (interface gaps, CSS overrides) + +**Research date:** 2026-05-18 +**Valid until:** 2026-06-17 (30-day window; stable stack)