Add TREV-WP-0012/0013/0014: modeling pass + spun-out implementation gaps

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>

workplans/TREV-WP-0013-remission-credit-automation.md

@@ -0,0 +1,77 @@
+---
+id: TREV-WP-0013
+type: workplan
+title: "Remission Credit automation (degeneration policy execution)"
+domain: infotech
+repo: target-revenue
+status: active
+owner: claude
+topic_slug: infotech
+created: "2026-07-30"
+updated: "2026-07-30"
+---
+
+# Remission Credit automation (degeneration policy execution)
+
+Spun out of `workplans/TREV-WP-0012-phase-provenance-and-policy-modeling.md`
+(use case 4). Every Phase declares a `degeneration_policy`
+(`trsl:policy:linear-longstop-v0` is the accepted v1 norm,
+`specs/OpenQuestions-WorkingDefaults.md` Q7), which is supposed to
+generate `remission-credit` Target Ledger entries over time when
+Development Credit progress is insufficient (FR-6,
+`specs/ProductRequirementsDocument.md`). **Nothing in this codebase
+currently computes or writes these entries.** `fold.py` can consume them
+if they exist; nothing produces them. This gap predates the Control Plane
+UI work — it was never in scope for WP-0006 (Trust Service) or WP-0009
+(Control Plane), and surfaced now only because reviewing the UI's
+Phase-registration flow prompted a fuller look at what a Phase's lifecycle
+actually requires end to end.
+
+Blocked on `workplans/TREV-WP-0012-phase-provenance-and-policy-modeling.md`
+T03's decision (how a policy id maps to its spec file) — the
+implementation here should be checkable against that spec file, per the
+user's explicit requirement that policy code and policy specification stay
+verifiably in sync.
+
+```task
+id: TREV-WP-0013-T01
+status: wait
+priority: high
+```
+
+**Design the remission calculation and scheduling model.** `R(t) = T0 ×
+clamp((t - t0)/(tL - t0), 0, 1)` (Q7) needs: a chosen recognition cadence
+(daily/monthly UTC per Q7's own text), an idempotent
+"has this period's remission already been recorded" check (ledger entries
+are append-only — a re-run must not double-remit), and a decision on
+where `t0` (Phase activation) comes from if it isn't already a manifest
+field (registration time? an explicit `activated_at`?). Cross-check
+against whatever `trsl:policy:linear-longstop-v0`'s spec file (once
+WP-0012-T03 lands) says, rather than re-deriving the formula from Q7
+prose alone.
+
+```task
+id: TREV-WP-0013-T02
+status: wait
+priority: high
+```
+
+**Implement and test** the calculation as a pure function (mirroring
+`fold.py`'s determinism discipline) plus whatever writes the resulting
+`remission-credit` entries into the hosted Target Ledger — a scheduled
+job, an on-demand Control Plane action, or both. Decide which actor
+"submits" these entries for attribution purposes (no human credential
+naturally owns a policy-driven entry) and record that decision explicitly
+rather than leaving `submitted_by_token` implicitly null.
+
+```task
+id: TREV-WP-0013-T03
+status: wait
+priority: medium
+```
+
+**Surface it in the Control Plane UI**: `phase_detail.html`'s Ledger
+table already renders `remission-credit` rows generically once they
+exist; verify that holds, and add a metrics-level explanation (e.g. next
+scheduled remission date/amount) if `metrics.py` doesn't already forecast
+one.