coulomb/target-revenue
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
target-revenue/workplans/TREV-WP-0010-development-effort-calculator.md
tegwick 7c2e33bc31 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.
2026-07-30 11:02:45 +02:00

4.4 KiB
Raw Blame History

id type title domain repo status owner topic_slug created updated
TREV-WP-0010 workplan Development Effort Calculator infotech target-revenue active claude infotech 2026-07-30 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)

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

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

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.