tegwick
ca53a9f820
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>
74 lines
2.6 KiB
Markdown
74 lines
2.6 KiB
Markdown
---
|
|
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.
|