tegwick
7c2e33bc31
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.
111 lines
4.4 KiB
Markdown
111 lines
4.4 KiB
Markdown
---
|
|
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.
|