docs(20): research phase — tablo detail page + kanban restyle
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Arthur Belleville
parent
e37b8c5855
commit
e18bf66dbf
1 changed files with 616 additions and 0 deletions
616
.planning/phases/20-tablo-detail-kanban-restyle/20-RESEARCH.md
Normal file
616
.planning/phases/20-tablo-detail-kanban-restyle/20-RESEARCH.md
Normal file
|
|
@ -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>
|
||||
## 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)
|
||||
Loading…
Reference in a new issue