Pipeliner Client

## Spec + decomposition

Specced and decomposed into **7 children (#1532–#1538)**. Carrying spec: `docs/superpowers/specs/2026-08-03-kanban-board-design.md`.

### Product-owner decisions (these override the ticket text)

**D1 — The board replaces the list, for everyone.** In place, no overlay, no new tab, no toggle. Drag inert for ordinary clients. This **supersedes acceptance criterion #2** ("visible only to the CTO and the assigned developer") — that AC is withdrawn and replaced by the D2 matrix. QA tests against the matrix, not AC #2.

**D2 — Visibility matrix.**

| Viewer | Cards visible | Drag |
|---|---|---|
| Ordinary client | all tickets in their project | none — read-only |
| Developer | **only** tickets assigned to them | their single legal forward step |
| CTO / admin | all tickets | full allowed set, backward included |

A developer deliberately sees **fewer** cards than the client does — the client owns the project view, a developer's board is their work queue. Not a bug; do not widen it in review.

**D3 — "Real-time" means polling.** `refetchInterval` + refetch-on-focus. This **narrows** the "tickets move instantly" AC to "within one poll interval, animated, plus manual refresh". SSE is out of scope and becomes a follow-up ticket.

**D4 — Design gate.** No frontend code before the design-system section is written and approved (the ticket's own AC #10).

### Children

| # | Child | Surface | Depends on |
|---|---|---|---|
| #1532 | Aggregator emits assignee + priority on `ticket_list` | `../aggregator` | — |
| #1533 | API: assignee, priority, parent + board fetch cap + pre-change resilience | `api/` | — (soft: #1532) |
| #1534 | API: per-viewer visibility matrix + per-card drag capability | `api/` | #1533 |
| #1535 | API: per-user board column preferences | `api/` | — |
| #1536 | Design: Kanban section in the design system | docs only | — |
| #1537 | Frontend: the board replaces the list view | `src/`+`app/` | #1534, #1535, #1536 |
| #1538 | Frontend: polling, manual refresh, card-move animation | `src/` | #1537 |

Display data (#1533) and authorization (#1534) are split on purpose: a mistake in the former shows a wrong name, a mistake in the latter leaks another developer's or another tenant's tickets.

### Three things the review caught that the original scoping missed

1. **Board data is aggregator-owned** — the list comes from the aggregator's `ticket_list`, not Redmine, so assignee and priority need a sibling-repo change first. Priority does not exist anywhere in pipeliner-client today.
2. **Cross-repo delivery risk** — the aggregator ships on its own pipeline, so the dashboard will run against a version without the new fields. #1533 carries an explicit test feeding a pre-change payload (schema-valid 200, null fields, no 500 — gotcha #2). That demotes #1532 from release blocker to data-quality follow-through.
3. **Board scale was unaddressed** — the replaced view is paginated; a board loads whole columns. Now an explicit per-status cap (proposed 50) with a "+N more" affordance, asserted server- and client-side.

### Open questions

1. **#1535** — server-side preference store, or localStorage? The ticket permits either. Not on the critical path.
2. **Board cap** (proposed 50/column) and **poll interval** (proposed 30s).

### Billing

Complexity stays pinned at **7/10** as charged at filing. No child carries or re-derives a complexity or price field.

## Shipped

Live in production, master build **#109** (`c784f95`). QA passed on prod; proof attached to #1546. All eight children Shipped.

### What the client gets
The ticketing screen at `/projects/{id}/ticketing` is now a Kanban board for **every** viewer — columns in canonical stage order with Shipped hidden by default, cards carrying title, assignee, priority and parent, drag-to-transition where the server permits it, a column filter that persists per user and per project, 30s polling with a manual refresh and a freshness line, and an animated card move when work advances elsewhere. Fully bilingual.

### The four decisions that overrode the ticket as written
**D1** — the board is for everyone with drag inert for clients, superseding AC #2 ("visible only to the CTO and the assigned developer"), which was withdrawn rather than left to fail at QA. **D2** — the visibility matrix, in which a developer deliberately sees *fewer* cards than the client, since the client owns the project view and a developer's board is their work queue. **D3** — "real-time" means polling; SSE is out of scope. **D4** — design approved before code.

### Known and carried forward, none blocking
- **#1548** (Backlog, unbilled) — durable ticket authorship. `ticket_charges` is cleared at submit, so a developer's filer-scope lasts only while a ticket sits in Backlog; after submitting, an unassigned filer loses sight of their own ticket. Fails closed.
- **§KB.8.3's enter/exit fades** are unimplemented — the exit half needs mount retention, and enter-only would cause the teleport the section exists to prevent.
- **The priority scale assumes the stock five-entry Redmine enumeration** — `position` is a rank within whatever that instance configured. Wrong-but-calm on a four- or six-entry instance; commented in place.
- **Drag was never exercised against the live API.** Doing so on prod would have meant moving a real client's ticket, so QA stopped rather than mutate live work. Drag, the zero-network assertion on locked columns, and the real 403/409 rollback rest on unit tests plus the prod-commit suite. Closing that needs a disposable ticket on a throwaway project.
- **Two freshness controls now share the screen** — the project header's "Updated … | Refresh data" and the board toolbar's "Refresh | Updated just now". They report different things but read as redundant.
- Pre-existing, surfaced during review: the **RAG corpus** is scoped by project only, so a developer's own chat can be grounded in a colleague's ticket text.

### Process note, for the next epic of this size
Every one of the six implementation children failed its first review and passed the next. Three shipped fully green gates with tests that asserted the right *intent* against the wrong *thing* — a drag-negative that could never start a drag because jsdom has no `PointerEvent`; an `assert not writes.called` on a respx route registered second and therefore unreachable; a `staleTime` override checked against a bare QueryClient that never carried the app's default. Between them the reviews caught two existence leaks, four dead user paths, and a board that blanked on any failed poll.

Green gates were not evidence. Mutation-testing each guard — breaking the thing it protects and confirming the test goes red — is what actually caught these, and it is the practice worth keeping.

**Complexity stayed pinned at 7/10 as charged at filing.** No child carried or re-derived a score, and the one regression this epic introduced (#1554) was absorbed as a child rather than billed again.