Implement WP-0009-T04: Control Plane interactive UI on whynot-design

Builds the Control Plane's browser UI (login, dashboard, Phase
registration, Development Credit entry/proposal/review, credential
admin, audit log) as a FastAPI + Jinja2 app over the already-finished
T03 backend, rather than from scratch — whynot-design's Lit web
components are vendored as static assets (source commit 4b62cffc,
v0.4.1), with lit itself resolved via an esm.sh CDN import map.

Session auth re-checks the credential token against the database on
every request rather than trusting the session cookie's cached rights,
so a mid-session revocation takes effect immediately.

9 new Docker-gated HTTP-level tests via FastAPI's TestClient (no
browser-automation tool available, so real rendering of the <wn-*>
components was never visually verified). All four WP-0009 tasks are
now done; workplan marked finished.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-07-30 15:43:16 +02:00
parent 5fbae0df02
commit c89b4aa4a5
24 changed files with 3486 additions and 3 deletions

View file

@ -4,7 +4,7 @@ type: workplan
title: "Target Revenue Control Plane"
domain: infotech
repo: target-revenue
status: active
status: finished
owner: claude
topic_slug: infotech
created: "2026-07-30"
@ -191,7 +191,7 @@ containers left running.
```task
id: TREV-WP-0009-T04
status: todo
status: done
priority: high
state_hub_task_id: "01b295f2-8f97-4fc4-a14e-6f68aa85458d"
```
@ -212,3 +212,46 @@ sub-credential extension as the backend:
- read-only views (Phase status, Ledger, Attestation, Breach/Compliance
Record history) — already public/unauthenticated at the Trust Service
layer, so these need no new backend work, only UI.
**Result:** Built on `whynot-design` (vendored, source commit
`4b62cffc86496d587ac8d48a8e199624bc4a5c1f`, v0.4.1 — see
`src/target_revenue/service/static/whynot-design/VENDORED.md` for what is
vendored versus resolved via an `esm.sh` CDN import map for the `lit`
peer dependency, a disclosed v0 trade-off) rather than from scratch, per
the explicit direction to check feasibility first. New FastAPI app
`src/target_revenue/service/control_plane_app.py`, session-based sign-in
(paste-a-credential-token, `itsdangerous`-signed cookie via Starlette's
`SessionMiddleware`, re-authenticated against the database on every
request so a mid-session revocation takes effect immediately, never
trusted from the cookie alone), seven Jinja2 templates under
`service/control_plane_templates/` (`base`, `login`, `dashboard`,
`phase_new`, `phase_detail`, `proposals`, `admin_credentials`, `audit`),
all wired to real `control_plane.py`/`registry.py`/`ledger.py`/`metrics.py`
calls — no mock data. Routes cover: login/logout; dashboard (list Phases
for the signed-in tenant); Phase registration (Operator+); Phase detail
(status/metrics + Ledger table); the priority flow — append a
Development Credit entry directly (Operator+/Admin) or submit it for
review (Contributor), same form, button label switches on rights;
proposal review (approve/reject, Operator+); credential issue/revoke
(Admin); and the Control Plane's own audit log (any signed-in user).
Rights gating is enforced identically to T03's backend — the UI layer
adds no new authorization logic, it only redirects with a flash message
when a route requires more than the signed-in credential's tier.
Tests: `tests/test_control_plane_app.py`, 9 Docker-gated tests via
FastAPI's `TestClient` (same disposable-Postgres-per-module pattern as
`test_control_plane.py`) — covers unauthenticated redirect to `/login`,
invalid-token rejection, successful login/dashboard, rights-gated route
redirects (viewer blocked from Phase registration and admin pages), the
full Operator register-Phase-then-append-entry flow, the
Contributor-proposes/Operator-reviews flow, and admin credential
issuance. Explicit scope disclosure: these are HTTP-level tests against
the FastAPI app, not real-browser tests — no browser-automation tool is
available in this environment, so the `<wn-*>` web components' actual
rendering/interactivity was never visually verified, only the
server-rendered HTML/session/redirect behavior around them. Full suite:
84 passing offline (unchanged), 146 passing with Docker (up from 53); no
stray containers left running.
All four WP-0009 tasks (T01T04) are now done — this workplan is
finished.