Go-live T05 + WP-0013/0014: first Phase and Control Plane completion

Accept WP-0008-T05 for trsl:phase:info-tech-canon-service-surface
(history/260805-T05-GoLive-info-tech-canon.md). Finish WP-0013 remission
automation and WP-0014 extension/breach/attestation Control Plane UI.
Update SCOPE, README, and pilot-candidate notes for pilot Stage 1.

specs/PhaseLifecycleUseCases.md

@@ -137,12 +137,9 @@ attestation about it"). `attestation.publish_attestation` is implemented,
 tested, and exposed at `GET /phases/{id}/attestation` — idempotent,
 publish-on-first-observation, never regenerated.
 
-**What's missing is purely presentational**: the Control Plane UI has no
-view of a Phase's Attestation once one exists. A caller has to know to
-hit the Trust Service endpoint directly.
-
-**Gap → `workplans/TREV-WP-0014-control-plane-extensions-breach-attestation-ui.md`
-T03.**
+**Resolved 2026-08-05** (WP-0014-T03): `phase_detail.html` shows the
+Conversion Attestation (Future License, final credits, ledger checkpoint,
+signature) via idempotent `get_or_publish_attestation` on page load.
 
 ---
 
@@ -155,22 +152,14 @@ SECURITY DEFINER, never a plain `UPDATE`) — the same pattern already used
 for credential revocation and proposed-entry review elsewhere in this
 project.
 
-**Two things are missing, one of them a real open question, not just
-UI**:
+**Resolved 2026-08-05** (`workplans/TREV-WP-0014-control-plane-extensions-breach-attestation-ui.md`
+T01, all four tasks finished):
 
-- No Control Plane UI to register an extension or review/promote one.
-- **Unresolved**: `specs/TargetRevenueControlPlaneConcept.md` §2's rights
-  table (cited in use case 3 above) does not mention extension
-  registration or canonicalization at all — unlike breach records (use
-  case 7), which the table explicitly assigns to Operator+. Whether
-  registering a new extension should require any rights tier at all
-  (the Trust Service's own `registry.register_extension` doesn't gate it
-  today — any authenticated tenant can call it directly), and who should
-  be able to canonicalize one, needs an explicit answer before UI work
-  starts, not an assumption made while building the form.
-
-**Gap → `workplans/TREV-WP-0014-control-plane-extensions-breach-attestation-ui.md`
-T01.**
+- Control Plane UI: `GET/POST /extensions`, Admin promote-to-canonical.
+- Rights (now in `specs/TargetRevenueControlPlaneConcept.md` §2):
+  **Operator+** registers; **Admin** promotes to canonical. Trust Service
+  `POST /extensions` remains open to any authenticated tenant token —
+  Control Plane policy is layered on top.
 
 ---
 
@@ -180,14 +169,12 @@ FR-10 and License V1C1 §7.4: a Licensor's own breach/termination
 determination, anonymized (Phase + category only) by default, named only
 with an explicit Commercial Use Agreement opt-in.
 `breach_record.publish_breach_event`/`get_breach_records` are implemented
-and tested. **Unlike extension registration, this one's rights tier is
-already decided**: `specs/TargetRevenueControlPlaneConcept.md` §2 assigns
-"publish breach/compliance records" to Operator+ explicitly, alongside
-Phase registration and direct ledger append. No open rights question here
-— purely a missing UI.
+and tested. Rights tier is Operator+
+(`specs/TargetRevenueControlPlaneConcept.md` §2).
 
-**Gap → `workplans/TREV-WP-0014-control-plane-extensions-breach-attestation-ui.md`
-T02.**
+**Resolved 2026-08-05** (WP-0014-T02): Control Plane form + list on
+`phase_detail.html`; named disclosure requires explicit CUA-authorization
+affirmation (records the assertion; does not verify CUA text).
 
 ---
 
@@ -234,12 +221,12 @@ conformance suite (`tests/test_hosted_conformance.py`).
 
 | # | Use case | Status |
 |---|---|---|
-| 1 | First Phase for a repo | Partially modeled — no repo/provenance fields (→ T02) |
-| 2 | Successive Phase, same repo | Not modeled at all (→ T02) |
+| 1 | First Phase for a repo | Done (WP-0015 provenance fields) |
+| 2 | Successive Phase, same repo | Done (WP-0015 `base_phase_id`) |
 | 3 | Register / propose / review (rights model) | Done (WP-0009) |
-| 4 | Remission Credit accrual | Not implemented (→ WP-0013) |
-| 5 | Conversion Attestation view | Backend done, no UI (→ WP-0014-T03) |
-| 6 | Extension registration/canonicalization | Backend done, no UI, rights tier undecided (→ WP-0014-T01) |
-| 7 | Breach/Compliance Record | Backend done, no UI, rights tier already decided (→ WP-0014-T02) |
+| 4 | Remission Credit accrual | Done (WP-0013) |
+| 5 | Conversion Attestation view | Done (WP-0014-T03) |
+| 6 | Extension registration/canonicalization | Done (WP-0014-T01) |
+| 7 | Breach/Compliance Record | Done (WP-0014-T02) |
 | 8 | Second Licensor tenant onboarding | Structurally supported, no onboarding flow — deferred to WP-0008 |
 | 9 | Offline evidence verification | Done by design, no UI needed |