81 lines
3.2 KiB
Markdown
81 lines
3.2 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"
|
||
state_hub_workstream_id: "4a423219-2a3e-413c-b0dc-f8542c2afba1"
|
||
---
|
||
|
||
# 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
|
||
state_hub_task_id: "d6ab7448-c009-4398-b616-560e8085cf1a"
|
||
```
|
||
|
||
**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
|
||
state_hub_task_id: "078da2e7-594b-4bd3-85b6-881a808f1ca2"
|
||
```
|
||
|
||
**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
|
||
state_hub_task_id: "fe12ee80-2868-4857-83ca-04bd7223e270"
|
||
```
|
||
|
||
**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.
|