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>
3 KiB
| id | type | title | domain | repo | status | owner | topic_slug | created | updated |
|---|---|---|---|---|---|---|---|---|---|
| TREV-WP-0013 | workplan | Remission Credit automation (degeneration policy execution) | infotech | target-revenue | active | claude | infotech | 2026-07-30 | 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.
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.
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.
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.