Split TREV-WP-0009 into Control Plane (WP-0009) and Effort Calculator (WP-0010)

The two deliverables have independent formula/rights decisions and
implementation arcs; keeping them in one workplan blurred that they
can be reviewed and sequenced separately, even though the Control
Plane's Phase-registration flow is expected to consume the
Calculator's output once both exist.

WP-0009 (Target Revenue Control Plane): keeps the original workstream
ID, retitled and re-tasked to 3 focused tasks - rights-model decision
(human gate), backend auth/audit layer, interactive UI flows.

WP-0010 (Development Effort Calculator, new): 3 tasks - formula
decision (human gate), implementation, application to the real
candidate repos already identified in WP-0008. No real Phase
declaration in either workplan's scope.

Updated both concept documents' workplan cross-references and
README.md's summary table accordingly.

workplans/TREV-WP-0009-target-revenue-control-plane.md

@@ -0,0 +1,99 @@
+---
+id: TREV-WP-0009
+type: workplan
+title: "Target Revenue Control Plane"
+domain: infotech
+repo: target-revenue
+status: active
+owner: claude
+topic_slug: infotech
+created: "2026-07-30"
+updated: "2026-07-30"
+state_hub_workstream_id: "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)
+
+```task
+id: TREV-WP-0009-T01
+status: todo
+priority: high
+human_accept_required: true
+```
+
+`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
+
+```task
+id: TREV-WP-0009-T02
+status: todo
+priority: high
+```
+
+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
+
+```task
+id: TREV-WP-0009-T03
+status: todo
+priority: high
+```
+
+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.