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-0010-development-effort-calculator.md

@@ -0,0 +1,111 @@
+---
+id: TREV-WP-0010
+type: workplan
+title: "Development Effort Calculator"
+domain: infotech
+repo: target-revenue
+status: active
+owner: claude
+topic_slug: infotech
+created: "2026-07-30"
+updated: "2026-07-30"
+---
+
+# Development Effort Calculator
+
+Turns measurable repo activity (human interaction time, workplan/task
+volume, file/line complexity, AI token cost) into `target_basis` values
+(`specs/PhaseManifestSpecification.md`), which combined with a human
+Target Multiple classification (10x/100x/1000x) produces a proposed
+Initial Target via the framework's own existing formula
+(`specs/TargetRevenueFrameworkCore.md` §1.4) — **not a new formula**. This
+calculator is a value-input tool feeding that existing formula, not a
+competing valuation methodology.
+
+**Split from the former combined `TREV-WP-0009-control-plane-and-effort-calculator.md`
+(2026-07-30)** — this deliverable has its own formula decision and
+implementation arc, independent of the Target Revenue Control Plane
+(`workplans/TREV-WP-0009-target-revenue-control-plane.md`), even though
+the Control Plane's Phase-registration flow is expected to consume this
+calculator's output once both exist.
+
+**Does not include:** declaring any real Phase for any repo, or choosing
+a repo's Target Multiple classification unilaterally — per
+`specs/DevelopmentEffortCalculatorConcept.md` §4, that classification
+remains a human judgment call the calculator can inform but not make.
+
+Concept: `specs/DevelopmentEffortCalculatorConcept.md`.
+
+## Formula decision (human gate)
+
+```task
+id: TREV-WP-0010-T01
+status: todo
+priority: high
+human_accept_required: true
+```
+
+`specs/DevelopmentEffortCalculatorConcept.md` §3 presents two combination
+strategies without choosing between them:
+
+- **Candidate A (labor-cost-anchored, recommended v0 default)** — human
+  time drives `estimated_effort_days`/`daily_rate` directly; AI token
+  cost becomes `approved_direct_costs` (a real, metered direct cost);
+  workplan/task-volume and repo-size metrics are a sanity check/adjustment
+  on the human-time estimate, not a separate dollar figure.
+- **Candidate B (composite-index-anchored)** — all four metric families
+  scored into one weighted complexity index, converted to dollars via a
+  declared $-per-unit rate.
+
+Confirm one as the adopted v0 approach (or propose a refinement), per the
+same human-gate pattern already used for the degeneration policy formula
+(`workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md` T02).
+Agents may prepare a recommendation and leave this `todo`.
+
+## Implement the calculator
+
+```task
+id: TREV-WP-0010-T02
+status: todo
+priority: high
+```
+
+Using T01's confirmed formula, implement data collection for each metric
+family and the combination formula itself, producing `target_basis`
+field values ready to drop into a Phase Manifest:
+
+- **Human interaction time** — v0 default: commit-timestamp clustering
+  (session-gap grouping over git history), explicitly a floor estimate,
+  not a true count (concept §2a).
+- **Workplan/task volume** — counts via state hub `list_tasks`/
+  `list_workplans` scoped to the repo, or direct `workplans/` directory
+  inspection where hub coverage is thin (concept §2b).
+- **File/line complexity** — raw counts with generated/vendored-path
+  exclusion (concept §2c's flagged distortion: dependency trees,
+  lockfiles, and generated files must not inflate this signal).
+- **AI token cost** — `get_token_summary(scope="repo", id=...)`, the
+  strongest, least speculative input since it is a real metered cost, not
+  a proxy (concept §2d).
+
+Output must show its work (which inputs produced which numbers) — a
+black-box dollar figure with no visible derivation would undermine the
+"transparent, non-gameable" goal (`specs/TargetRevenueLicenseConcept.md`
+§4.6) this whole framework is built around.
+
+## Apply calculator to real candidate repos
+
+```task
+id: TREV-WP-0010-T03
+status: todo
+priority: medium
+```
+
+Once T02 is implemented, run it against the real candidates already
+identified (`specs/PilotPhaseCandidateSurvey.md`: `net-kingdom`'s
+`NK-WP-0002`, `railiance-apps`'s `vergabe-teilnahme`, and
+`info-tech-canon`'s service surface) to produce **proposed**,
+calculator-derived `target_basis` values, replacing the hand-picked
+illustrative figures currently in `examples/pilot-candidates/*/manifest.json`.
+This remains draft/non-binding — updating a draft manifest's numbers is
+not a Phase declaration, and does not touch
+`workplans/TREV-WP-0008-governance-and-pilot-rollout.md` T05's own gate.