Add TREV-WP-0006-T09: Breach/Compliance Record hosting

Reopens WP-0006 (status: active) to track the gap T01's Trust Service
PRD flagged: the Breach/Compliance Record component (TSD §4.1, added
alongside License V1C1 §7.4) postdates WP-0002 and was never assigned
to T03-T08. Scopes it: publish alleged/determined breach status
without adjudicating, default anonymized with CUA-§9-gated named
disclosure, append-only per the existing pattern, reusing the
per-Licensor token model for writes.

README.md

@@ -78,7 +78,7 @@ The concept's §13 now defines a **Global Contingency Share Determination Rule**
 | [TREV-WP-0003](workplans/TREV-WP-0003-normative-core-extraction.md) | Extract stable normative core docs — **finished**, reviewed and accepted 2026-07-29 |
 | [TREV-WP-0004](workplans/TREV-WP-0004-global-jurisdiction-research.md) | Global jurisdictional research backing the License/CUA candidates — **finished**, T10 synthesis accepted 2026-07-29 with alpha/beta working defaults (full legal review deferred until out of beta — see `SCOPE.md` §1) |
 | [TREV-WP-0005](workplans/TREV-WP-0005-enforcement-network-research.md) | Enforcement Network legal feasibility research — **finished**, T10 synthesis accepted 2026-07-29 on the same alpha/beta basis (Japan's Article 12 risk remains explicitly unresolved) |
-| [TREV-WP-0006](workplans/TREV-WP-0006-trust-service-implementation.md) | Hosted Trust Service reference implementation (PRD Phase 4b) — **finished**, all 8 tasks done (Postgres-backed registries/ledger/metrics/attestation, ADR-0002 accepted, onboarding CLI, hosted conformance suite). T01's flagged gap — no task owns hosting the Breach/Compliance Record component (License V1C1 §7.4) — remains open, not yet assigned |
+| [TREV-WP-0006](workplans/TREV-WP-0006-trust-service-implementation.md) | Hosted Trust Service reference implementation (PRD Phase 4b) — active; T01–T08 done (Postgres-backed registries/ledger/metrics/attestation, ADR-0002 accepted, onboarding CLI, hosted conformance suite); T09 (Breach/Compliance Record hosting, License V1C1 §7.4) added 2026-07-29, not yet started |
 | [TREV-WP-0007](workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md) | Degeneration policy + canonical monetization profile catalog — active, not yet started |
 | [TREV-WP-0008](workplans/TREV-WP-0008-governance-and-pilot-rollout.md) | Governance formalization + pilot rollout across `coulomb-loop`/`net-kingdom`/`helix-forge`/`railiance-*` — active, not yet started; real Phase declarations gated behind T05 |
 

workplans/TREV-WP-0006-trust-service-implementation.md

@@ -4,7 +4,7 @@ type: workplan
 title: "Trust Service reference implementation (PRD Phase 4b)"
 domain: infotech
 repo: target-revenue
-status: finished
+status: active
 owner: claude
 topic_slug: infotech
 created: "2026-07-29"
@@ -343,6 +343,43 @@ parametrized regression test across four distinct ledger shapes
 (credits-only, with remission, with a reversal, with both administrative
 correction types) asserts hosted-append-then-offline-fold always
 reproduces the exact expected totals, generalizing the single-shape check
-already added ad hoc in T04. This closes WP-0006 — all 8 tasks done. Full
+already added ad hoc in T04. Full suite: 49 passing offline (plain system
-suite: 49 passing offline (plain system Python, no new dependency), 77
+Python, no new dependency), 77 passing with Docker; no stray containers
-passing with Docker; no stray containers left running.
+left running.
+
+## Breach/Compliance Record hosting
+
+```task
+id: TREV-WP-0006-T09
+status: todo
+priority: medium
+```
+
+T01's Trust Service PRD flagged this gap explicitly: the
+Breach/Compliance Record component (`specs/TechnicalSpecificationDocument.md`
+§4.1 table, added 2026-07-29 alongside License V1C1 §7.4) postdates
+WP-0002 and was not assigned to any of T03–T08. Implement it now as this
+workplan's ninth task, per TrustServicePRD TS-FR-7:
+
+- publish the Licensor's breach and termination determinations for a
+  Phase, distinguishing `alleged` (notice given) from `determined` (cure
+  period expired or breach otherwise established per the License's own
+  terms) — the Trust Service never adjudicates whether a breach occurred,
+  it only publishes the Licensor's own determination (TSD §4.1 Forbidden
+  column, restated in TrustServicePRD TS-FR-7);
+- default to an anonymized Phase-and-category record (License V1C1 §7.4);
+  named disclosure of the Commercial Entitlement holder occurs only where
+  the applicable Commercial Use Agreement's naming/disclosure clause (CUA
+  V1C1 §9) opts in, following that clause's notice period;
+- append-only per the same pattern as `phase_manifests`/`ledger_entries`/
+  `attestations` — a determination, once published, is not silently
+  revised; a correction is a new, dated record, not an edit;
+- add the read/write API surface to `service/app.py` and reuse
+  `registry.authenticate`'s per-Licensor token model for the write side
+  (only the Phase's own Licensor may publish a determination for it) —
+  reads are public per the anonymized-by-default rule above.
+
+**Deliverable:** a new migration (`migrations/0004_breach_records.sql` or
+similar), `src/target_revenue/breach_record.py`, corresponding
+`service/app.py` endpoints, and Docker-gated tests following the existing
+pattern in `tests/test_hosted_conformance.py`/`test_ledger_hosting.py`.