# 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>
## 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 |
</phase_requirements>

---

## 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) {
    <div class="tablo-kanban-column" data-status={ col.Status }>
        <div class="tablo-kanban-column-header">
            <span class="tablo-kanban-column-title">{ col.Label }</span>
            <span class="tablo-kanban-task-count">{ len(col.Tasks) }</span>
            <a href="#" class="tablo-kanban-add-link" hx-get={ col.CreateHref }
               hx-target={ "#create-zone-" + col.Status } hx-swap="innerHTML">
               + Ajouter
            </a>
        </div>
        <div id={ "task-list-" + col.Status } class="task-list sortable-column"
             data-status={ col.Status }>
            for _, task := range col.Tasks {
                @TabloDetailTaskCard(task)
            }
        </div>
        <div id={ "create-zone-" + col.Status }></div>
    </div>
}
```

### 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 `<dialog>` | `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 `<table>` | `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) {
    <header class="tablo-detail-header">
        <div class="tablo-detail-title-row">
            <div class="tablo-detail-avatar" style={ projectColorVariableStyle(vm.Color) }>
                { vm.Initial }
            </div>
            <h1 class="tablo-detail-title">{ vm.Name }</h1>
        </div>
        <div class="tablo-metadata-row">
            <span class="tablo-meta-segment">
                <!-- owner avatar 24×24 + name -->
            </span>
            <span class="tablo-meta-segment">
                @ActionIcon("calendar")
                if vm.DueDate != "" { vm.DueDate } else { "—" }
            </span>
            <span class="tablo-meta-segment">
                @ui.Badge(ui.BadgeProps{Label: vm.StatusLabel, Variant: badgeVariantForTone(vm.StatusTone)})
            </span>
            <span class="tablo-meta-segment tablo-meta-progress">
                <div class="project-progress-track" style="min-width:120px">
                    <div class="tablo-detail-progress-bar" style={ progressInlineStyle(vm.Progress) }></div>
                </div>
                <strong>{ vm.ProgressLabel }</strong>
            </span>
        </div>
    </header>
}
```

---

## 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)