coulomb/target-revenue
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add TREV-WP-0012/0013/0014: modeling pass + spun-out implementation gaps

Browse source 
TREV-WP-0012 is the modeling-only workplan requested after using the
Control Plane UI surfaced real gaps: Phase registration has no
structured repo/provenance fields, the ledger URI is hand-typed, and
degeneration policies are opaque ids with no reviewable spec behind
them. It produces a use-cases document and a discussable spec addendum
before any schema/UI implementation.

Two of the use cases uncovered while scoping this turned out to be
bigger than documentation gaps and are tracked as their own workplans
per that direction: TREV-WP-0013 (nothing currently computes or writes
Remission Credit ledger entries at all) and TREV-WP-0014 (Extension
Registry, Breach Record, and Conversion Attestation backends already
exist from WP-0006 but have no Control Plane UI).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-07-30 19:35:18 +02:00
parent e103937e21
commit ca53a9f820
4 changed files with 331 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

74
workplans/TREV-WP-0014-control-plane-extensions-breach-attestation-ui.md Normal file
View file

@ -0,0 +1,74 @@
---
id: TREV-WP-0014
type: workplan
title: "Control Plane UI: Extension Registry, Breach Records, Conversion Attestation"
domain: infotech
repo: target-revenue
status: active
owner: claude
topic_slug: infotech
created: "2026-07-30"
updated: "2026-07-30"
---
# Control Plane UI: Extension Registry, Breach Records, Conversion Attestation
Spun out of `workplans/TREV-WP-0012-phase-provenance-and-policy-modeling.md`
(use cases 5, 6, 7). Unlike `workplans/TREV-WP-0013-remission-credit-automation.md`,
the backend for all three already exists and is tested
(`registry.register_extension`/`promote_extension_canonical`,
`breach_record.publish_breach_event`/`get_breach_records`,
`attestation.publish_attestation`) — this is UI-only work, extending
`service/control_plane_app.py` and its templates the same way WP-0009-T04
did for Phases and the Ledger. Not blocked on WP-0012; can start any time.
```task
id: TREV-WP-0014-T01
status: todo
priority: medium
```
**Extension Registry UI**: a page listing registered extensions with
their `registered`/`canonical` status, a form to register a new extension
(any authenticated tenant, per `registry.register_extension` — confirm
whether Control Plane rights-gating applies here or whether extension
registration is intentionally open, since `control_plane.py` today has no
wrapper for it at all), and a canonical-promotion action restricted to
whatever rights tier canonicalization review actually requires (check
`specs/TargetRevenueControlPlaneConcept.md` §2's rights table — this may
need its own entry there if it's missing).
```task
id: TREV-WP-0014-T02
status: todo
priority: medium
```
**Breach/Compliance Record UI**: a form to publish a breach/compliance
determination against a Phase (`breach_record.publish_breach_event`),
respecting the anonymized-by-default / named-only-with-opt-in rule
(FR-10, License V1C1 §7.4), and a read view on `phase_detail.html`
listing a Phase's published records.
```task
id: TREV-WP-0014-T03
status: todo
priority: low
```
**Conversion Attestation UI**: read-only — a Phase that has converted
should show its Attestation (`attestation.publish_attestation` is
idempotent/publish-on-first-observation) on `phase_detail.html`, including
Future License and the supporting ledger checkpoint, rather than requiring
a caller to hit the Trust Service's `GET /phases/{id}/attestation`
directly to see it.
```task
id: TREV-WP-0014-T04
status: todo
priority: low
```
**Tests and docs**: Docker-gated `TestClient` tests for all three (same
pattern as `tests/test_control_plane_app.py`), workplan Result sections,
`README.md` row update.