Pipeliner Client

PR: https://github.com/omdev-tech/PipeLiner-Client/pull/97 — branch `feat/1543-board-visibility-matrix`, based on **`dev`** (this builds on #1542/PR #96 and #1544/PR #95, neither of which is on `master` yet).

## What shipped

**The D2 matrix** is applied in `ListProjectTasks` / `BuildTaskBoard` and expressed as data (`BOARD_SCOPE`) in `domain/tasks/progression.py` rather than as a chain of ifs — so "which roles have a matrix entry" is something a test can read. An unrecognised role fails **closed** to the narrowest scope, and `BOARD_SCOPE` is asserted against `InternalRole` itself, so a role added without a matrix entry turns the build red instead of defaulting quietly. The developer scope is *narrower* than the client's, as decided.

**Per-card capability** is computed in one pass by `card_capability`, which delegates to `may_set_status` / `next_status` / `selectable_statuses` — no rule is re-implemented, and the board, the transition route and MCP `transition_ticket` cannot disagree. Memoised on `(status_id, is-it-mine)`, so a tenfold board costs the same number of rule evaluations and zero Redmine calls.

**`board_read_only`** is on the payload as a property of the *viewer*, per the amendment. A developer whose queue all sits at Shipped has no movable card and is still `false`.

**The `_detail_out` redaction is lifted.** `test_an_ordinary_client_never_sees_the_assignee` was **inverted and renamed** to `test_an_ordinary_client_sees_the_assignee_but_no_controls`, with this ticket in the docstring and the assertion structure kept, so the reversal reads as a decision. Scope respected: only the *name* is disclosed — `can_move_forward`, `can_assign` and the narrowed `allowed_statuses` are unchanged and still give a client nothing.

## Two decisions the reviewer should look at

1. **A card is evaluated against the canonical pipeline** (`FORWARD_ORDER`), not the per-issue Redmine allowed set, because the latter is one HTTP call per card and the spec forbids the fan-out. Backlog(16)/Blocked(14) are therefore never offered to anyone; where a project's workflow is narrower than the canonical pipeline, a card may advertise a target Redmine then refuses, landing as the 409 the drop path already handles. The **role** half of the answer — the half that could leak — is exact. Documented at `BOARD_CANDIDATE_STATUSES`.

2. **Closing the existence leak required the detail route and MCP too.** For a scoped viewer, "not yours", "not in this project" and "you are not a member" all collapse to the same `403 {"detail":"Forbidden"}`. Without this the matrix would be cosmetic — an omitted card could be read back by asking for its id. `MCP list_tickets` is scoped by the same matrix, since the standing rule cuts both ways.

## Tests

New `api/tests/test_board_visibility.py`, 48 cases: the parametrised matrix over every viewer kind × both modes; the byte-for-byte leak comparison; the call-count/N+1 proof at 20 and 200 cards; Backlog/Blocked never offered; the credit gate (inert card **and** a still-409ing transition route); MCP parity and card↔pane parity; the null `assignee_ref` case from #1541; and no role name or status order on the wire.

Mutation-checked rather than assumed: widening the developer scope to `all` fails 7 of them (both leak tests included), and breaking the memo fails the N+1 test.

**Gates green:** `pytest` 1202 passed / 2 skipped, run green **twice on one database**; `ruff check .` clean; `mypy src` clean.

⚠️ Shipping constraint from the amendment still stands: #1542 must not reach prod without this, or clients get the half-state (name on the card, blank in the pane).

## Code review: FAIL — back to In development

PR https://github.com/omdev-tech/PipeLiner-Client/pull/97 is **not shippable as-is**. Three blocking security findings, all reproduced against a live Postgres, and B1 independently re-confirmed.

**What is good, and should not be disturbed by the fix:** the matrix itself. The reviewer could not find a way to make `board_scope` / `visible_tasks` / `card_capability` hand a developer someone else's card; the matrix is data and fails closed; ordering is scope→sort→cap; MCP narrows and never widens; both CLAUDE.md MCP invariants hold (`create_ticket` still scores server-side, the Entra allowlist is still re-checked per request); and the assignee test was correctly inverted and renamed with a #1543 reference rather than deleted, with every capability left internal-only.

### B1 — `may_view_task` guards one route out of six
Called exactly once, `presentation/api/tasks.py:997`, inside `get_task`. Six routes return the identical `_detail_out` body — `get_task` (guarded), `transition_task`, `assign_task`, `pause_task`, `reopen_task`, `patch_task`. Verified:

```
GET /projects/{pid}/tasks/3 → 403 Forbidden
PATCH /projects/{pid}/tasks/3 → 200, full body incl. description and assignee
POST /projects/{pid}/tasks/3/pause → 200, same body
```

A developer reads **and mutates** any colleague's ticket by id — pausing it, or overwriting its `spec_ref`. The use cases carry no authorization of their own. Same hole on MCP (`_set_ticket_paused`, `_update_ticket`, `_submit_ticket`, `_transition_ticket`'s `InvalidTransition` branch), which makes the MCP scoping cosmetic too. Fix is a shared `viewable_task` dependency across every `issue_id` route and MCP tool, refusing **before** the write.

### B2 — `transition_task` is an id oracle
`TaskNotInProject` → 404 while a foreign-but-present ticket → 403 with a role-specific message. One POST per id sorts "on my project" from "elsewhere", defeating the collapse `get_task` performs.

### B3 — a non-existent id is a third, distinguishable answer — a 500
`GetTask` lets `RedmineError` escape uncaught, so a missing id 500s where an existing one 403s. Existence is disclosed across the **whole Redmine instance**, other tenants included. Pre-existing, but this ticket is what asserts the property.

### Also required
**S3** — the `redmine_user_id is not None` guard in `holds_ticket` is mutation-survivable: deleting it gives an unmapped developer every unassigned ticket and no test goes red. A developer holding the role with a NULL Redmine id is a real state.
**S2** — the canonical-pipeline tradeoff is sound (it can only ever advertise a target the *workflow* refuses, never one the *role* refuses), but the docstring's claim that it lands as a 409 is wrong for a developer: role is checked before workflow, so it is a 403 on their own ticket.

Fix is in progress on the same branch and PR.

## Merged — review passed after three rounds

PR https://github.com/omdev-tech/PipeLiner-Client/pull/97 merged to `dev` (`b50f90c`, +2989/−77). Gates: **1253 passed** / 2 skipped, green twice; ruff and mypy clean; Jenkins PR-97 green.

**Round 2 review cleared the security question outright.** The reviewer enumerated from the live OpenAPI schema rather than by grep — 67 paths, 12 that touch a ticket, all 12 gated, plus all 6 issue-id MCP tools. It then attacked its own conclusion:
- the gate fires **before body parsing** — a malformed `status_id`, a missing field and unparseable JSON all return 403, not 422, with zero Redmine writes;
- the refusal collapse holds across **44 byte-identical responses per route set**, headers included, over four buckets (not yours / other project / doesn't exist in Redmine / not a member);
- nothing widened for clients or CTOs, and the old 500 on a missing id is now a 404.

**Round 3** added the filer admission (PO decision) plus two test-hygiene fixes:
- `owns_or_filed` = "assigned to me **or** filed by me", one predicate behind all four surfaces. Authorship comes from `ticket_charges`, not Redmine's `author` — every dashboard-filed ticket is authored by the shared "Client Dashboard" user, which identifies nobody. The port is a batch intersection (`issue_ids_filed_by`) chosen so an N+1 is not the natural implementation: **one query at 5 cards and at 200**, zero Redmine reads, and unscoped viewers never pay for it.
- Fixed a **vacuous assertion in our own suite**: `assert not writes.called` could never fire, because respx dispatches to the first matching route and the catch-all was registered second. With the gate removed the route returned 200 with the full foreign ticket and `call_count == 0`. Now bound to a route that matches — mutation-confirmed at `call_count == 1`.
- Corrected the docstring claiming one `is not None` guard was load-bearing. Measured: dropping either clause alone leaves the suite green; dropping **both** reddens 2 tests.

Mutation results: removing the filer clause reddens 4 tests, removing the assignee clause 14.

## ⚠ Known window, carried forward

`ticket_charges` rows are **cleared at submit** (`submit_ticket.py:147` — "drop the pinned charge so it cannot be re-read"). Filer-scope therefore lasts only while the ticket sits in **Backlog**.

That covers the operations this decision was about — submit, edit and delete are all backlog-window actions — but a developer who files a ticket, submits it, and is *not* assigned it loses sight of it again at Submitted/Spec, where `ticket_is_mutable` would still have let them edit. Closing it needs a durable authorship record, i.e. a schema change. Tracked separately; documented on `owns_or_filed`.

Also noted out of scope: the **RAG corpus** is built from every ticket's subject and description and retrieval is scoped by project only, so a developer's own chat can be grounded in a colleague's ticket text. Not an id oracle, predates this ticket, and scoping a vector index is a design decision rather than a one-liner.

Shipped to production in master build #109 (`c784f95`). PR #97, three review rounds.