target-revenue/workplans/TREV-WP-0009-target-revenue-control-plane.md
tegwick 5e0f39bbc8 chore(consistency): write back state hub IDs after WP-0009/WP-0010 split
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-30 11:03:40 +02:00

4.1 KiB

id type title domain repo status owner topic_slug created updated state_hub_workstream_id
TREV-WP-0009 workplan Target Revenue Control Plane infotech target-revenue active claude infotech 2026-07-30 2026-07-30 0e8dfd43-a742-4458-9e9b-514a9284821b

Target Revenue Control Plane

An interactive UI over the hosted Trust Service (workplans/TREV-WP-0006-trust-service-implementation.md, finished), usable by a human user with appropriate rights acting as the binky tenant. The specific, named requirement driving this workplan: make it possible to interactively register Phases and create Development Credit ledger entries, rather than requiring raw API calls or the scripts/trf_onboard.py CLI.

Split from the former combined TREV-WP-0009-control-plane-and-effort-calculator.md (2026-07-30) — the Development Effort Calculator is a separate concern with its own formula decision and implementation arc; it now lives in workplans/TREV-WP-0010-development-effort-calculator.md. The two remain related (the Control Plane's Phase-registration flow is expected to use the Calculator's output, per T03 below) but are sequenced and reviewed independently.

Does not include: declaring any real Phase for any repo, or changing the Trust Service's core guarantees (determinism, append-only, no discretionary conversion authority) — the Control Plane is a client of the existing hosted service, bound by the same rules any other client is.

Concept: specs/TargetRevenueControlPlaneConcept.md.

User rights model — decision (human gate)

id: TREV-WP-0009-T01
status: todo
priority: high
human_accept_required: true
state_hub_task_id: "177117e7-955b-4f12-b17b-75ee3f0357c4"

specs/TargetRevenueControlPlaneConcept.md §2 proposes a four-tier rights model (Viewer/Contributor/Operator/Admin) and recommends option (b) for the auth-attribution question: the Control Plane holds the one binky Licensor token server-side and layers its own human-user auth/audit log in front of it, rather than requiring a WP-0006 schema change for per-human sub-credentials (option (a)). Confirm the rights tiers and the (a)-vs-(b) choice, or propose a refinement. Agents may prepare a recommendation and leave this todo.

Control Plane backend: auth layer and audit log

id: TREV-WP-0009-T02
status: todo
priority: high
state_hub_task_id: "86a58e61-dccd-4678-b694-22a9eaea2b3c"

Using T01's confirmed rights model, implement the human-user authentication/authorization layer and the Control Plane's own audit log (concept §5) — which human user took which action, timestamped, alongside the Trust Service's own signed record id for that action. This is the piece that must exist before any write-capable UI flow (T03) can be built responsibly, since the Trust Service's own signature only ever attests "the binky Licensor did this," never which individual human initiated it (concept §2's design tension).

Control Plane interactive UI: Phase registration and Development Credit entry

id: TREV-WP-0009-T03
status: todo
priority: high
state_hub_task_id: "01b295f2-8f97-4fc4-a14e-6f68aa85458d"

Implement the interactive flows themselves, using T02's auth/audit layer and the existing hosted Trust Service API (service/app.py) as the backend, unmodified unless T01 specifically selected the per-human-sub-credential option:

  • Phase registration, informed by workplans/TREV-WP-0010-development-effort-calculator.md's output once available (not blocking — a manual target_basis entry path must work standalone too, since the Calculator may not be ready first);
  • the priority flow: interactively creating a development-credit ledger entry against a selected, already-registered Phase (concept §3's step-by-step description) — select Phase, fill amount/currency/ recognized-date/evidence-reference/Monetization-Extension, submit, immediately show the updated GET /phases/{id}/metrics result;
  • read-only views (Phase status, Ledger, Attestation, Breach/Compliance Record history) — already public/unauthenticated at the Trust Service layer, so these need no new backend work, only UI.