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>
2.6 KiB
| id | type | title | domain | repo | status | owner | topic_slug | created | updated |
|---|---|---|---|---|---|---|---|---|---|
| TREV-WP-0014 | workplan | Control Plane UI: Extension Registry, Breach Records, Conversion Attestation | infotech | target-revenue | active | claude | infotech | 2026-07-30 | 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.
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).
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.
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.
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.