78 lines
3 KiB
Markdown
78 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.
|