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 |

specs/TargetRevenueControlPlaneConcept.md

@@ -45,10 +45,19 @@ T01, maintainer-accepted, as proposed):
 
 | Right | Can do |
 |---|---|
-| Viewer | Read Phase status, metrics, ledger, attestations, breach records (all already public per FR-9/FR-10 — a Viewer arguably needs no new auth at all, since these are unauthenticated reads today) |
+| Viewer | Read Phase status, metrics, ledger, attestations, breach records, extension registry (all already public per FR-9/FR-10 — a Viewer arguably needs no new auth at all, since these are unauthenticated reads today) |
 | Contributor | Everything Viewer can, plus: submit a *proposed* Development Credit entry for review (not directly appended) |
-| Operator | Everything Contributor can, plus: directly append Development Credit/Remission Credit entries, register new Phases, publish breach/compliance records |
-| Admin | Everything Operator can, plus: manage which human users hold which right within the `binky` tenant |
+| Operator | Everything Contributor can, plus: directly append Development Credit/Remission Credit entries, register new Phases, register new Monetization Extensions, publish breach/compliance records, trigger policy remission |
+| Admin | Everything Operator can, plus: manage which human users hold which right within the `binky` tenant, **promote a Monetization Extension from `registered` to `canonical`** |
+
+**Extension rights (resolved 2026-08-05, WP-0014-T01):** the gap noted in
+`specs/PhaseLifecycleUseCases.md` use case 6 is closed here. Registering
+an extension is Operator+ (same tier as Phase registration — the tenant is
+publishing structure it will use on its ledgers). Canonicalization is
+Admin only (governance action, never automated; matches
+`set_extension_status` SECURITY DEFINER and credential management). The
+Trust Service's own `POST /extensions` still accepts any authenticated
+tenant token; these tiers are Control Plane policy layered on top.
 
 **Design tension — resolved 2026-07-30, option (a) adopted, not (b):**
 WP-0006's Ledger append API (`ledger.append_entry`) currently

specs/policies/linear-longstop-v0.md

@@ -26,10 +26,19 @@ cohort, not merely a Stage 0 pilot placeholder.
 
 ## Status
 
-Not yet automated — see
-`workplans/TREV-WP-0013-remission-credit-automation.md`. Nothing in this
-codebase currently computes or writes these entries; this file is the
-formula those entries must be checkable against once that workplan lands.
+Automated as of WP-0013 (`src/target_revenue/remission.py`):
+
+- Pure cumulative formula: `cumulative_remission(T0, t0, tL, as_of)`.
+- Hosted apply writes the delta
+  `max(0, R(as_of) − Σ policy remission-credit already on the ledger)`.
+- **t0** = Trust Service `phase_manifests.registered_at` (no separate
+  `activated_at` manifest field in Stage 0).
+- **Cadence**: monthly UTC (1st 00:00) for scheduled batch
+  (`POST /remission/run`); on-demand via
+  `POST /phases/{id}/remission` or Control Plane "Apply policy remission now".
+- **Actor**: Licensor credential labeled `system:policy-engine`
+  (not a human token).
+- Re-runs at the same `as_of` are no-ops (idempotent by cumulative delta).
 
 ## Superseded / next iteration