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

---
id: TREV-WP-0009
type: workplan
title: "Target Revenue Control Plane and Development Effort Calculator"
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 and Development Effort Calculator

Builds the two pieces the maintainer identified as needed to move from
"license text adopted org-wide" (`history/260730-TRSL-OrgWideLicenseRollout.md`)
toward actually declaring real Phases with defensible Initial Targets:

1. A **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, to interactively register Phases and — the specific,
   named requirement — create Development Credit ledger entries
   interactively rather than via raw API calls or the CLI.
2. A **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.

**Does not include:** declaring any real Phase for any repo. Both
deliverables here are inputs to that decision
(`workplans/TREV-WP-0008-governance-and-pilot-rollout.md` T05), not a way
to bypass it.

## Development Effort Calculator — formula decision (human gate)

```task
id: TREV-WP-0009-T01
status: todo
priority: high
human_accept_required: true
state_hub_task_id: "96ea1067-22f5-490b-8c42-5236a2193b1a"
```

`specs/DevelopmentEffortCalculatorConcept.md` §3 presents two combination
strategies without choosing between them: Candidate A (labor-cost-
anchored — human time drives `estimated_effort_days`/`daily_rate`, token
cost becomes `approved_direct_costs`, workplan/file metrics are a sanity
check) or Candidate B (composite-index-anchored — all four metric
families scored into one complexity index, converted via a $-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`.

## Control Plane user rights model — decision (human gate)

```task
id: TREV-WP-0009-T02
status: todo
priority: high
human_accept_required: true
state_hub_task_id: "9d3b2d3d-1a3c-4b63-8cd1-8e6c949ad8b8"
```

`specs/TargetRevenueControlPlaneConcept.md` §2 proposes a four-tier rights
model (Viewer/Contributor/Operator/Admin) and recommends option (b) for
the auth-attribution question (Control Plane holds the one Licensor
token server-side, 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). Confirm the rights tiers and the (a)-vs-(b) choice, or
propose a refinement. Agents may prepare a recommendation and leave this
`todo`.

## Implement Development Effort Calculator

```task
id: TREV-WP-0009-T03
status: todo
priority: high
state_hub_task_id: "fadaef32-0d6a-443f-8dde-9a85952c6d76"
```

Using T01's confirmed formula, implement the calculator: data collection
(commit-timestamp clustering for human time; workplan/task counts via
state hub `list_tasks`/`list_workplans` or direct `workplans/` directory
inspection; file/line counts with generated/vendored-path exclusion per
`specs/DevelopmentEffortCalculatorConcept.md` §2c's flagged distortion;
token cost via `get_token_summary(scope="repo", id=...)`), and the
combination formula itself, producing `target_basis` field values ready
to drop into a Phase Manifest. 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.

## Implement Control Plane (backend + interactive UI)

```task
id: TREV-WP-0009-T04
status: todo
priority: high
state_hub_task_id: "77b91435-780b-4360-8fe0-922d6483d549"
```

Using T02's confirmed rights model, implement the Control Plane: human
user authentication, the rights-tiered action set from
`specs/TargetRevenueControlPlaneConcept.md` §3–§4 (interactive Development
Credit entry creation as the priority flow), and the Control Plane's own
audit log distinct from the Trust Service's signed records (§5). Reuses
the existing hosted Trust Service API (`service/app.py`) as its backend
without modification unless T02 specifically selects the
per-human-sub-credential option, in which case that WP-0006 auth
extension is this task's prerequisite, not an assumed given.

## Apply calculator to real candidate repos

```task
id: TREV-WP-0009-T05
status: todo
priority: medium
state_hub_task_id: "3ee25a56-3cbb-4284-b240-d58e12622bf9"
```

Once T03 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.