tegwick
ca53a9f820
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>
77 lines
3 KiB
Markdown
77 lines
3 KiB
Markdown
---
|
||
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.
|