Pipeliner Client

## PO approval — D4 gate passed

Approved by the PO. The frontend children #1546 and #1547 are unblocked.

**Section:** `## Kanban board — ticketing (KB)`, `docs/design/design-system.md:6087`, anchor `#kanban-board--ticketing-kb`. Subsections KB.0–KB.11 cover all ten lettered acceptance criteria. Committed on `docs/1511-kanban-spec`, PR https://github.com/omdev-tech/PipeLiner-Client/pull/94. Diff is `docs/` only.

**Approved with two amendments already applied to the section**, both PO decisions taken after it was drafted:

1. **The assignee name renders for every viewer**, ordinary clients included. This reverses §IR for the *name* only — every capability stays internal-only and `StaffActionBar` still returns `null` for a client. #1543 lifts the `_detail_out` redaction so the card and the detail pane agree.
2. **`priorityToken` resolves on `priority_ref.position`**, not `key`. #1541 ships `key` as a slug of the display name, which is neither locale- nor rename-stable.

**Design decisions the implementers must not quietly undo:**
- Zero new colours — the priority scale reuses the §SO/§SM severity ladder. **Normal and null render no chip at all**; priority is always in the card's accessible name instead.
- The client's read-only board is absence + substitution, never padlocks or greying.
- Backlog and Blocked are locked for *different* reasons and the copy says which: Backlog because the server never offers it, Blocked because it is a decision rather than a gesture — reachable from the Move menu with a confirm, never by drag.
- KB.1a recomposes the `New request` CTA and `KnowledgeStrip` into the toolbar. Deleting the rail without them would remove the only intake path from this screen and the app's only reindex control.

The section's own review findings have been folded into #1542, #1543, #1546 and #1547 as ticket amendments.

## Delivered and shipped — moving to QA

Its last AC ("PO approval recorded as a comment") was satisfied on 2026-08-03; the ticket simply never advanced past `Design` afterwards, which left it as the epic's least-advanced child and held #1511's rollup at `Design`.

The deliverable is live: §KB.0–KB.11 is in `docs/design/design-system.md` on `master` (`c784f95`, deployed in build #109), and both frontend children were built against it — #1546's review checked the components section by section, and QA on #1546 confirmed the shipped board matches it.

It has also been amended twice since approval, by the tickets that changed the behaviour it describes:
- **§KB.3** — `priorityToken` resolves on `priority_ref.position`, not `key` (a slug of the localised display name, so neither locale- nor rename-stable).
- **§KB.2** — the assignee row renders for every viewer, reversing §IR for the *name* only.
- **§KB.1a / §KB.6e** — the three-number model, closing drift #1547 introduced: **header = what is shown, "+N more" = what was never fetched, pill = the whole project.**

Two self-contradictions inside §KB are known and unresolved, both harmless as shipped but worth settling before the next board change:
1. **Toolbar DOM order** — §KB.1a says tabs → knowledge → Columns → New request; §KB.9's tab-order sentence puts New request first. The code follows §KB.1a.
2. **The priority scale assumes the stock five-entry Redmine enumeration.** `position` is a rank *within whatever that instance configured*: four priorities shifts every rank down, six makes the top one unrecognised and fall to Normal. Both wrong-but-calm; commented in place, the real fix is upstream where the enumeration length is known.

Also unimplemented and named: **§KB.8.3's enter/exit fades** (a card new to the board, or gone from it). The exit half needs a mount-retention mechanism, and shipping enter-only would produce exactly the teleport-into-the-gap §KB.8.3 exists to prevent.

Shipped to production in master build #109 (`c784f95`). §KB.0–KB.11 is live in `docs/design/design-system.md` and both frontend children were built against it.