tegwick
6eec4f6634
Adds since/until date-range scoping to cluster_commit_hours() and workplan_task_counts() (threaded through calculate_target_basis()), needed whenever a candidate is one bounded workplan within a repo whose overall history spans much more (net-kingdom, railiance-apps) rather than the whole repo being the candidate (vergabe-teilnahme, info-tech-canon). Fixes a real bug found along the way: workplan_task_counts() only scanned the top level of workplans/, missing net-kingdom's workplans/archived/ convention entirely - silently reported zero finished workplans for NK-WP-0002, which lives there. Fixed to scan recursively; added a regression test. Updates all three draft pilot-candidate manifests with calculator- derived target_basis/initial_target values, replacing the hand-picked placeholders: net-kingdom-local-identity: 200,000 -> 10,000 EUR (floor + sanity warnings) railiance-vergabe-teilnahme: 3,500,000 -> 648,800 EUR (no warnings) info-tech-canon-service-surface: 2,500,000 -> 141,800 EUR (sanity warning) history/260730-EffortCalculator-CandidateApplication.md records full derivation, warnings, and the judgment calls made explicit rather than silently picked (date-scoping windows; measuring vergabe-teilnahme's own repo rather than railiance-apps' deployment-only wiring, with both figures shown). Still draft/non-binding - WP-0008-T05 unaffected. 5 new tests (20 -> now covering since/until scoping and the archived-subdirectory fix). Full suite: 84 passing offline.
193 lines
9 KiB
Markdown
193 lines
9 KiB
Markdown
# Development Effort Calculator Applied to Real Pilot Candidates
|
||
|
||
**Document status:** Dated execution record, non-normative, append-only
|
||
(`workplans/TREV-WP-0010-development-effort-calculator.md` T03).
|
||
**Not a Phase declaration.** Updates draft, non-binding
|
||
`examples/pilot-candidates/*/manifest.json` figures from hand-picked
|
||
illustrative placeholders to calculator-derived ones — nothing here
|
||
authorizes a real Phase (`workplans/TREV-WP-0008-governance-and-pilot-rollout.md`
|
||
T05 still gates that).
|
||
|
||
---
|
||
|
||
## 1. Method
|
||
|
||
Ran `target_revenue.effort_calculator.calculate_target_basis` (WP-0010-T02)
|
||
against each candidate's real local repository, `daily_rate=1000` (EUR,
|
||
consistent with the earlier hand-picked drafts and the Licensor's own
|
||
jurisdiction), `tokens_in=tokens_out=0` (no `get_token_summary` data was
|
||
available for these repos at the time of this run — `approved_direct_costs`
|
||
is therefore `0` for all three, not a claim that no AI cost was actually
|
||
incurred, just that none is currently on record).
|
||
|
||
**Scoping decision, made explicit per candidate:** two of the four
|
||
candidates repos are the *whole repo's* history (the repo's entire
|
||
purpose is the candidate); two are one bounded workplan inside a much
|
||
larger, longer-lived repo, and were date-scoped accordingly (`since`/
|
||
`until`) — running whole-repo history against a single narrow workplan
|
||
would badly overstate that workplan's own effort.
|
||
|
||
| Candidate | Repo | Scope used | Why |
|
||
|---|---|---|---|
|
||
| `net-kingdom-local-identity` | `net-kingdom` | `2026-03-01` .. `2026-03-06` | `NK-WP-0002` is one bounded workplan; `net-kingdom` has since grown into a much larger, multi-year security platform with dozens of unrelated workplans |
|
||
| `railiance-vergabe-teilnahme` | `vergabe-teilnahme` (primary) + `railiance-apps` (secondary, scoped) | whole repo (primary); `2026-05-18` .. `2026-07-12` (secondary) | See §3 — the actual application code lives in `vergabe-teilnahme`, a separate repo from `railiance-apps`, which only holds the Helm/deployment wiring |
|
||
| `info-tech-canon-service-surface` | `info-tech-canon` | whole repo | The candidate *is* the repo's cumulative service surface (`ITC-WP-0001`–`0012`); no narrower scope applies |
|
||
|
||
## 2. `net-kingdom-local-identity`
|
||
|
||
```json
|
||
{
|
||
"estimated_effort_days": 1.0,
|
||
"daily_rate": 1000,
|
||
"approved_direct_costs": 0.0,
|
||
"warnings": [
|
||
"Raw commit-clustered estimate was 0.804 day(s), below the 1.0-day floor. Floored to 1.0 day(s)... very likely a measurement gap... manual override... recommended.",
|
||
"1 finished workplan(s) and 21 finished task(s) on record suggest more real effort than the 0.80-day raw time estimate reflects — treat the time estimate as under-counted and consider a manual override."
|
||
],
|
||
"derivation": {
|
||
"raw_commit_clustered_hours": 6.435, "sessions": 4, "commits": 19,
|
||
"finished_workplans": 1, "finished_tasks": 21,
|
||
"file_count": 274, "line_count": 44359
|
||
}
|
||
}
|
||
```
|
||
|
||
**Both warnings fired.** The raw 0.8-day estimate hit the 1-day floor
|
||
(§1's date-scoping correctly isolated `NK-WP-0002`'s own 19 commits across
|
||
4 sessions), and the sanity-check independently flagged that 21 finished
|
||
tasks across one workplan implies more real effort than 0.8 raw days
|
||
suggests. **This is exactly the situation the maintainer's requested
|
||
floor-and-warning design exists for**: the manifest below uses the
|
||
1.0-day floored value, not a manually-adjusted "better" number — a human
|
||
reviewing this candidate before any real Phase declaration should treat
|
||
`estimated_effort_days: 1.0` as a flagged, likely-too-low placeholder, not
|
||
a settled figure.
|
||
|
||
**Manifest updated:** `estimated_effort_days: 1.0`, `approved_direct_costs: 0`,
|
||
`target_multiple: 10` (unchanged, Incremental) → **Initial Target: 10,000 EUR**
|
||
(previously a hand-picked 200,000 EUR — the calculator's own honest,
|
||
warning-flagged output is materially lower, not a refinement of the old
|
||
guess).
|
||
|
||
## 3. `railiance-vergabe-teilnahme`
|
||
|
||
Two repos exist for this candidate, discovered during the earlier
|
||
architecture work: `railiance-apps` holds the Helm/deployment wiring;
|
||
`vergabe-teilnahme` holds the actual Django application source code.
|
||
`RAILIANCE-WP-0002`/`-0014` (the workplans naming this Milestone Release)
|
||
live in `railiance-apps`, but the real development effort producing the
|
||
application itself happened in `vergabe-teilnahme`.
|
||
|
||
**Primary figure used — `vergabe-teilnahme`, whole-repo history (no
|
||
scoping; the repo's entire purpose is this one application):**
|
||
|
||
```json
|
||
{
|
||
"estimated_effort_days": 6.488,
|
||
"daily_rate": 1000,
|
||
"approved_direct_costs": 0.0,
|
||
"warnings": [],
|
||
"derivation": {
|
||
"raw_commit_clustered_hours": 51.904, "sessions": 42, "commits": 223,
|
||
"finished_workplans": 1, "finished_tasks": 123,
|
||
"file_count": 322, "line_count": 26773
|
||
}
|
||
}
|
||
```
|
||
|
||
**Secondary figure, not used in the manifest — `railiance-apps`, date-scoped
|
||
to `2026-05-18`..`2026-07-12`:**
|
||
|
||
```json
|
||
{
|
||
"estimated_effort_days": 4.146,
|
||
"derivation": {
|
||
"raw_commit_clustered_hours": 33.168, "sessions": 36, "commits": 127,
|
||
"finished_workplans": 12, "finished_tasks": 71,
|
||
"file_count": 140, "line_count": 11118
|
||
}
|
||
}
|
||
```
|
||
|
||
**Judgment call, made explicit rather than silently picked:** this
|
||
document uses `vergabe-teilnahme`'s figure as the candidate's
|
||
`target_basis`, since that repo is where the substantive product
|
||
development happened; `railiance-apps`'s deployment effort (4.146 days)
|
||
is real work but comparatively thin infrastructure glue, not the
|
||
Milestone Release's own value creation. A different, equally defensible
|
||
call would sum or otherwise combine both — flagged here so a human
|
||
reviewing this later can see both numbers and the reasoning, not just
|
||
the one that was picked.
|
||
|
||
**Manifest updated:** `estimated_effort_days: 6.488`,
|
||
`approved_direct_costs: 0` (the hand-picked draft's `5000` placeholder
|
||
removed — no real token-cost or other direct-cost data exists yet),
|
||
`target_multiple: 100` (unchanged, Product-defining) → **Initial Target:
|
||
648,800 EUR** (previously a hand-picked 3,500,000 EUR).
|
||
|
||
## 4. `info-tech-canon-service-surface`
|
||
|
||
```json
|
||
{
|
||
"estimated_effort_days": 1.418,
|
||
"daily_rate": 1000,
|
||
"approved_direct_costs": 0.0,
|
||
"warnings": [
|
||
"12 finished workplan(s) and 51 finished task(s) on record suggest more real effort than the 1.42-day raw time estimate reflects — treat the time estimate as under-counted and consider a manual override."
|
||
],
|
||
"derivation": {
|
||
"raw_commit_clustered_hours": 11.348, "sessions": 12, "commits": 48,
|
||
"finished_workplans": 12, "finished_tasks": 51,
|
||
"file_count": 235, "line_count": 93663
|
||
}
|
||
}
|
||
```
|
||
|
||
Above the 1-day floor (no floor warning), but the sanity-check warning
|
||
still fired — 12 finished workplans and 51 finished tasks against only
|
||
1.42 raw days is a clear under-count signal in its own right, independent
|
||
of the floor. Same treatment as `net-kingdom`: the flagged, warning-
|
||
carrying value is used as-is, not manually adjusted.
|
||
|
||
**Manifest updated:** `estimated_effort_days: 1.418`,
|
||
`approved_direct_costs: 0`, `target_multiple: 100` (unchanged,
|
||
Product-defining) → **Initial Target: 141,800 EUR** (previously a
|
||
hand-picked 2,500,000 EUR).
|
||
|
||
## 5. A bug found and fixed along the way
|
||
|
||
Applying the calculator to `net-kingdom` surfaced a real defect in
|
||
`workplan_task_counts()`: it originally scanned only the top level of
|
||
`<repo>/workplans/`, non-recursively — and `NK-WP-0002` lives in
|
||
`net-kingdom/workplans/archived/`, a convention several repos in this
|
||
ecosystem use for finished workplans instead of deleting them. The
|
||
initial scoped run silently reported zero finished workplans/tasks for a
|
||
candidate that has exactly one, cleanly finished workplan. Fixed to scan
|
||
recursively (`rglob` instead of `glob`); a regression test
|
||
(`test_workplan_task_counts_scans_archived_subdirectory`) now guards this.
|
||
|
||
## 6. Summary table
|
||
|
||
| Candidate | Old (hand-picked) Initial Target | New (calculator-derived) Initial Target | Warnings fired |
|
||
|---|---:|---:|---|
|
||
| `net-kingdom-local-identity` | 200,000 EUR | **10,000 EUR** | Floor + sanity-check (both) |
|
||
| `railiance-vergabe-teilnahme` | 3,500,000 EUR | **648,800 EUR** | None |
|
||
| `info-tech-canon-service-surface` | 2,500,000 EUR | **141,800 EUR** | Sanity-check only |
|
||
|
||
Every calculator-derived figure is materially lower than the earlier
|
||
hand-picked illustrative placeholder — expected, since those placeholders
|
||
were invented for shape-checking the schema, not reasoned from any real
|
||
measurement. Two of the three carry explicit warnings recommending a
|
||
manual override before this could ever inform a real Phase declaration;
|
||
the third (`vergabe-teilnahme`) has no warnings, but is itself the
|
||
product of a judgment call (§3) about which of two repos to measure.
|
||
|
||
## 7. Non-goals
|
||
|
||
- Declaring any real Phase — `workplans/TREV-WP-0008-governance-and-pilot-rollout.md`
|
||
T05 is unaffected by this document.
|
||
- Resolving the `railiance-apps`/`vergabe-teilnahme` scoping judgment call
|
||
with finality — flagged, not settled, in §3.
|
||
- Sourcing real `get_token_summary` data for these three repos — not
|
||
attempted in this pass; `approved_direct_costs: 0` reflects absence of
|
||
data, not a claim that no AI cost was incurred.
|