From b93a60442c8a2b8f43ccd6167a4dab99edaa1294 Mon Sep 17 00:00:00 2001 From: tegwick Date: Thu, 30 Jul 2026 01:29:13 +0200 Subject: [PATCH] Add Control Plane + Development Effort Calculator concepts and workplan specs/TargetRevenueControlPlaneConcept.md: an interactive UI over the hosted Trust Service for the binky tenant, prioritizing interactive Development Credit entry creation. Flags the actual new design gap WP-0006 didn't need to solve: one Licensor token vs. multiple human users needing individually attributable actions - recommends the Control Plane hold the Licensor token server-side and layer its own human-user auth/audit log in front, rather than requiring a WP-0006 auth schema change, while leaving the choice to a human gate (T02). specs/DevelopmentEffortCalculatorConcept.md: turns four metric families (human interaction time via commit-clustering, workplan/task volume, file/line complexity, AI token cost via the state hub's get_token_summary) into target_basis values feeding the framework's own existing Initial Target formula - not a new formula. Presents two combination strategies (labor-cost-anchored vs. composite-index) as alternatives for a human gate (T01) rather than picking one. workplans/TREV-WP-0009-control-plane-and-effort-calculator.md: 5 tasks (two human-gated formula/rights decisions, two implementation tasks, one task to apply the calculator to the real candidate repos already identified in WP-0008). Explicitly does not declare any real Phase - both deliverables feed WP-0008-T05's own gate, they don't bypass it. --- README.md | 1 + specs/DevelopmentEffortCalculatorConcept.md | 209 ++++++++++++++++++ specs/TargetRevenueControlPlaneConcept.md | 136 ++++++++++++ ...009-control-plane-and-effort-calculator.md | 132 +++++++++++ 4 files changed, 478 insertions(+) create mode 100644 specs/DevelopmentEffortCalculatorConcept.md create mode 100644 specs/TargetRevenueControlPlaneConcept.md create mode 100644 workplans/TREV-WP-0009-control-plane-and-effort-calculator.md diff --git a/README.md b/README.md index 7ca0c38..c51ba2e 100644 --- a/README.md +++ b/README.md @@ -81,6 +81,7 @@ The concept's §13 now defines a **Global Contingency Share Determination Rule** | [TREV-WP-0006](workplans/TREV-WP-0006-trust-service-implementation.md) | Hosted Trust Service reference implementation (PRD Phase 4b) — **finished**, all 9 tasks done (Postgres-backed registries/ledger/metrics/attestation/breach-record, ADR-0002 accepted, onboarding CLI, hosted conformance suite) | | [TREV-WP-0007](workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md) | Degeneration policy + canonical monetization profile catalog — **finished**, all 4 tasks done. `trsl:policy:linear-longstop-v0` confirmed 2026-07-29 as the v1 norm for the first pilot cohort; `progress-paused-longstop-v1` named as the next iteration, not yet adopted | | [TREV-WP-0008](workplans/TREV-WP-0008-governance-and-pilot-rollout.md) | Governance formalization + pilot rollout — active; T01–T04 done. `info-tech-canon` dry-run onboarding routine exercised end-to-end 2026-07-29. **Org-wide TRSL license adoption executed 2026-07-30** across ~90 `coulomb`-org repos (`history/260730-TRSL-OrgWideLicenseRollout.md`) — a license-text adoption, not a Phase declaration. T05 (real Phase go-live gate) remains `todo` by design; no Phase exists yet for any repo | +| [TREV-WP-0009](workplans/TREV-WP-0009-control-plane-and-effort-calculator.md) | Target Revenue Control Plane (interactive UI for the `binky` tenant, incl. interactive Development Credit entry creation) + Development Effort Calculator (turns human time/workplan-task volume/repo size/AI token cost into `target_basis` values) — active, concepts only so far (`specs/TargetRevenueControlPlaneConcept.md`, `specs/DevelopmentEffortCalculatorConcept.md`); T01/T02 human-gated formula/rights decisions not yet made | Hub index: [`WORK-RECORDS.md`](WORK-RECORDS.md) · brief: [`.custodian-brief.md`](.custodian-brief.md) diff --git a/specs/DevelopmentEffortCalculatorConcept.md b/specs/DevelopmentEffortCalculatorConcept.md new file mode 100644 index 0000000..0a419d0 --- /dev/null +++ b/specs/DevelopmentEffortCalculatorConcept.md @@ -0,0 +1,209 @@ +# Development Effort Calculator — Concept + +Status: Concept v0.1 +Date: 2026-07-30 +Workplan: `workplans/TREV-WP-0009-control-plane-and-effort-calculator.md` +Primary artifacts: `specs/TargetRevenueFrameworkCore.md` §1.4 (Target Multiple, Initial Target formula), `specs/PhaseManifestSpecification.md` (`target_basis` fields), state hub `get_token_summary`/`get_recent_progress`/`list_tasks` tools + +**Scope note:** this is a concept for a **working, explicitly refinable v0 +estimator** — not a final, authoritative valuation methodology. Every +formula below is a starting point the maintainer expects to iterate on +once real repos produce real data, consistent with how +`specs/TargetDegenerationPolicyResearch.md` treated its own formula +proposal. + +--- + +## 1. What this calculator produces + +It does **not** invent a new target-setting mechanism. It produces +concrete values for the fields `specs/PhaseManifestSpecification.md` +already defines under `phase.target_basis`: + +- `estimated_effort_days` +- `daily_rate` +- `approved_direct_costs` +- `target_multiple` + +and lets `specs/TargetRevenueFrameworkCore.md` §1.4's existing formula do +the rest: + +``` +Estimated Development Cost = (estimated_effort_days × daily_rate) + approved_direct_costs +Initial Target = Estimated Development Cost × Target Multiple +``` + +This calculator's job is narrowly: turn measurable repo activity into +defensible values for the left-hand side, and turn a repo's Target +Multiple *classification* (10x/100x/1000x — Incremental/Product-defining/ +Platform-defining) into the right-hand multiplier, per the same guidance +table already in `specs/TargetRevenueFrameworkCore.md` §1.4. It is a +value-input tool feeding an existing formula, not a competing formula. + +## 2. Input metrics (v0 candidate set) + +Four metric families, per the maintainer's request: + +### 2a. Human interaction time + +**What:** hours a human spent interacting with the repo in any way +(coding sessions, review, planning conversations). + +**Candidate sources, weakest to strongest signal:** +- Git commit timestamp clustering: group commits into sessions (a gap + threshold, e.g. commits within 2 hours of each other belong to the same + session), sum session durations. Cheap, works on any repo's existing + history, but systematically undercounts (thinking/reading time between + commits, non-commit work). +- State hub `get_recent_progress`/session records for repos already + tracked there — likely more accurate for repos actively worked on + through this agent/hub workflow, but not available for repos with no + hub-tracked history. +- Explicit human-logged time (a repo's own time-tracking, if it has one) — + most accurate where available, not universal. + +**v0 default:** commit-timestamp clustering, since it works uniformly +across every repo without depending on hub coverage — explicitly a +*floor* estimate (real effort is almost certainly higher), not a +best-effort true count. + +### 2b. Workplan/task volume — complexity index component + +**What:** number and status distribution of workplans and tasks +associated with the repo (state hub `list_tasks`/`list_workplans` scoped +to the repo, or direct inspection of a `workplans/` directory as this +repo's own convention already does). + +**v0 formula sketch:** `complexity_units_workplans = finished_workplans × 3 + finished_tasks × 1` +(a workplan is worth more than a bare task, since it implies scoping and +sequencing work beyond the sum of its tasks) — **weights are placeholders, +not derived from any data yet**, flagged explicitly for refinement once +multiple repos' actual effort-vs-workplan-count relationship is known. + +### 2c. Repo size — complexity index component + +**What:** file count and line count in the repo, as a raw +complexity/scope proxy. + +**v0 formula sketch:** `complexity_units_size = file_count × 0.1 + line_count × 0.001` +— deliberately crude (a config repo with 10,000 generated lines is not +"more effort" than a 500-line algorithm-dense repo), which is exactly why +this is one input among several, not a standalone valuation. **Known +distortion to correct for in refinement:** vendored/generated +files/lines, `node_modules`-style dependency trees, and lockfiles +inflate this signal without reflecting real effort — a v1 refinement +should exclude common generated/vendored paths (`.gitignore`-aware or an +explicit exclude list) before counting. + +### 2d. AI token cost — estimated and consumed + +**What:** the actual $ cost of AI-assisted implementation work on this +repo, both consumed-to-date and, where a task is still in flight, +estimated to completion. + +**Source:** the state hub already tracks this — `get_token_summary(scope="repo", id=)` +aggregates recorded token consumption per repo, populated via +`record_token_event`. This is the **strongest, least speculative** input +in this whole set, since it is a real, metered cost already being +recorded for other purposes (token budget policy), not a proxy. + +**v0 formula sketch:** `token_cost_usd = tokens_in × input_price_per_token + tokens_out × output_price_per_token`, +using the actual per-model pricing for whatever model(s) `get_token_summary` +reports were used — this is not an estimate at all where data exists, it +is a direct cost figure; it only becomes an *estimate* for effort not yet +performed (extrapolating from a partial task to its expected completion). + +## 3. Combining the metrics — v0 formula (explicitly provisional) + +Two candidate combination strategies, presented as alternatives for the +maintainer to weigh rather than a single forced answer (matching +`specs/TargetDegenerationPolicyResearch.md`'s own pattern of presenting, +not silently picking, a design fork): + +### Candidate A — labor-cost-anchored (recommended v0 default) + +Treat human time as the primary cost driver (`estimated_effort_days`, +`daily_rate` directly), and route token cost into `approved_direct_costs` +(a real, metered direct cost, exactly what that field is for per +`specs/OpenQuestions-WorkingDefaults.md` Q5). The workplan/task-volume and +repo-size complexity indices (§2b, §2c) are used as a **sanity check / +adjustment factor** on the human-time estimate — e.g., if commit-timestamp +clustering suggests very little time but the repo has a large, mature +workplan/task history, that's a signal the time-tracking input is +under-counting and should be revised upward, not a separate dollar figure +of its own. + +``` +estimated_effort_days = (commit-clustered hours) / 8 [sanity-adjusted per §2b/§2c signal] +daily_rate = a declared, repo-independent rate (not computed from metrics) +approved_direct_costs = token_cost_usd (from §2d) +target_multiple = per the Target Multiple classification (§4) +``` + +### Candidate B — composite-index-anchored + +Convert every metric family into a common "complexity unit" score +(weighted sum across §2a–§2d, all four as scored inputs, not three +checking one), then map the total score to a dollar figure via a +declared $-per-unit rate. More uniform across very different repos +(a repo with almost no logged human time but a huge, real workplan/task +history and heavy AI-token spend wouldn't be under-valued the way +Candidate A might undervalue it), but introduces a second calibration +constant ($-per-complexity-unit) with even less grounding than +`daily_rate` has. + +**This document does not choose between A and B** — that is exactly the +kind of working default a future task (see workplan T02) should propose +and a maintainer should confirm, the same way +`specs/TargetDegenerationPolicyResearch.md` handled the degeneration +formula fork. + +## 4. Target Multiple classification (the Nx factor) + +Reuses `specs/TargetRevenueFrameworkCore.md` §1.4's existing guidance +table unchanged — this calculator does not redefine what 10x/100x/1000x +mean, it only needs a repeatable way to *classify* a given repo/Phase +against that existing table: + +| Class | Multiple | Indicative interpretation (unchanged from framework core) | +|---|---:|---| +| Commons | 0x | Immediate permissive release or no development monetization target | +| Recovery | 1x | Direct development cost recovery | +| Incremental | 10x | Material enhancement of an existing use case | +| Product-defining | 100x | Significant commercial differentiator or new product capability | +| Platform-defining | 1000x | New platform, market, ecosystem, or foundational capability | + +**v0 approach: human classification, calculator-assisted, not +calculator-decided.** The calculator can surface signals relevant to the +choice (e.g., "this repo's capability is consumed by N other repos" as a +platform-defining signal, drawing on state hub repo-dependency data where +available) but per `specs/TargetRevenueFrameworkCore.md` §1.4's own +framing ("represents a product and commercial hypothesis, not an +objectively measurable claim"), the actual classification choice remains +a human judgment call, not an automated output. This mirrors +`specs/PilotPhaseCandidateSurvey.md`'s own indicative classifications, +which were reasoned, not computed. + +## 5. Worked illustration (not a real valuation) + +Using `info-tech-canon`'s dry-run draft manifest +(`examples/pilot-candidates/info-tech-canon-service-surface/manifest.json`) +purely as a shape check, not a claim that these numbers are its real +value: 25 estimated effort days × 1000/day = 25,000, + 0 direct costs +(no real token-cost data pulled for this illustration) = 25,000 Estimated +Development Cost × 100 (Product-defining) = 2,500,000 — matching the +draft manifest's existing illustrative figures, which were hand-picked, +not calculator-derived. A real application of this calculator to +`info-tech-canon` (or any repo) is future work once §3's formula choice +is confirmed (workplan T02) and implemented (T03). + +## 6. Non-goals + +- Choosing Candidate A vs. B — a human decision, workplan T02. +- Implementing the actual calculator (data collection + formula code) — + workplan T03. +- Producing a real Initial Target for any specific repo — that requires + both this calculator's implementation and a human Target Multiple + classification decision per repo, neither done here. +- Replacing or reinterpreting `specs/TargetRevenueFrameworkCore.md` §1.4's + existing formula — this calculator feeds it, it does not compete with it. diff --git a/specs/TargetRevenueControlPlaneConcept.md b/specs/TargetRevenueControlPlaneConcept.md new file mode 100644 index 0000000..1c6c054 --- /dev/null +++ b/specs/TargetRevenueControlPlaneConcept.md @@ -0,0 +1,136 @@ +# Target Revenue Control Plane — Concept + +Status: Concept v0.1 +Date: 2026-07-30 +Workplan: `workplans/TREV-WP-0009-control-plane-and-effort-calculator.md` +Primary artifacts: `specs/TrustServiceProductRequirementsDocument.md`, `src/target_revenue/service/app.py`, `specs/TRSL-Governance.md` §1 (Licensor identity), `scripts/trf_onboard.py` + +**Scope note:** this is a concept, not an implementation. It defines what +the Control Plane UI is for, who uses it, and what it must and must not +be able to do — building directly on the hosted Trust Service +(`workplans/TREV-WP-0006-trust-service-implementation.md`, finished) and +the onboarding mechanism (`specs/TrustServiceOnboarding.md`) rather than +replacing either. + +--- + +## 1. Purpose + +Everything in `scripts/trf_onboard.py` today is a CLI, operated by +whoever has shell access and the Licensor's token in an environment +variable. That is adequate for the dry-run routine already exercised +(`info-tech-canon`), but not adequate for **an actual "binky tenant" user** +— someone who should be able to interactively register Phases, review +Phase status, and — the maintainer's specific requirement — **interactively +create Development Credit ledger entries**, without needing to construct +raw JSON payloads or hold the Licensor's raw API token directly in their +own shell environment. + +The Control Plane is a web (or equivalent interactive) front end over the +existing hosted Trust Service API (`service/app.py`), for the `binky` +tenant specifically, not a replacement for that API or a new Trust +Service instance. + +## 2. Users and rights model — the actual new design gap + +**This is the concept's main open design question**, not something WP-0006 +already solved: WP-0006's auth model is **one token per Licensor** +(`migrations/0001_registries.sql`'s `licensors` table), sufficient for a +script or CI pipeline acting *as* the Licensor, but not sufficient for +**multiple human users**, potentially with **different rights**, acting +*on behalf of* the same Licensor tenant (`binky`). + +**Candidate rights tiers** (not yet decided, proposed for workplan T01 to +resolve): + +| Right | Can do | +|---|---| +| Viewer | Read Phase status, metrics, ledger, attestations, breach records (all already public per FR-9/FR-10 — a Viewer arguably needs no new auth at all, since these are unauthenticated reads today) | +| Contributor | Everything Viewer can, plus: submit a *proposed* Development Credit entry for review (not directly appended) | +| Operator | Everything Contributor can, plus: directly append Development Credit/Remission Credit entries, register new Phases, publish breach/compliance records | +| Admin | Everything Operator can, plus: manage which human users hold which right within the `binky` tenant | + +**Design tension to resolve, not paper over:** WP-0006's Ledger append API +(`ledger.append_entry`) currently authenticates a single Licensor token, +not an individual human user — so "Operator Alice" and "Operator Bob" +both acting for `binky` are currently indistinguishable at the API layer +(both just look like "the `binky` token"). Either (a) the Control Plane +issues per-human-user sub-credentials that map to the same underlying +Licensor identity (requiring a schema/API change in WP-0006's auth +layer — a real, scoped follow-on task), or (b) the Control Plane holds +the one Licensor token server-side and layers its own human-user +authentication/authorization in front of it, recording *which human* +took an action in its own audit log distinct from the Trust Service's +own record (simpler, no WP-0006 changes required, but the Trust +Service's own signed records still only attest "the `binky` Licensor did +this," not "Alice, acting for `binky`, did this"). **Recommendation: start +with (b)** — it requires no changes to the already-finished, tested +WP-0006 auth model, and the Control Plane's own audit log (§5) can carry +the finer-grained human-attribution that the Trust Service's own +cryptographic signature does not need to. + +## 3. Core interactive flow: creating a Development Credit entry + +The maintainer's specific requirement. Concretely, for an Operator-tier +user: + +1. Select a registered Phase (from a list, via `GET /phases/{id}` reads — + already public, already implemented). +2. Fill a form for a new `development-credit` ledger entry: amount, + currency, recognized date, evidence reference, applicable Monetization + Extension (selected from `specs/CanonicalMonetizationProfiles.md`'s + catalog, not free text). +3. The Control Plane server-side calls `POST /phases/{id}/ledger` + (`ledger.append_entry`, already implemented, WP-0006-T04) using the + `binky` Licensor token it holds — the human user never sees or handles + that token directly. +4. The Control Plane records, in its own audit log (§5), which human user + initiated this specific entry, alongside the Trust Service's own + returned signed record. +5. Display the updated Phase status (`GET /phases/{id}/metrics`, already + implemented) immediately after, so the user sees the effect of what + they just did. + +**Nothing here requires changing the Ledger append API itself** — the +Control Plane is a client of it, exactly like `scripts/trf_onboard.py` is +today, just interactive and multi-user rather than single-shot CLI. + +## 4. Other interactive capabilities (lower priority than §3) + +- Registering a new Phase, using the Development Effort Calculator + (`specs/DevelopmentEffortCalculatorConcept.md`) to help populate + `target_basis`, rather than requiring the user to hand-author a JSON + manifest. +- Viewing the Breach/Compliance Record history for a Phase and initiating + a new breach/cure/determined event (Operator+ only, per License V1C1 + §7.4's Licensor-determination principle — the Control Plane must not + let this become the Control Plane's own discretionary judgment about + whether a breach occurred, consistent with TSD §4.1's forbidden-action + column). +- Viewing the Conversion Attestation once a Phase converts (read-only, + already public). + +## 5. Audit logging — a Control Plane responsibility, not a Trust Service one + +Every write action taken through the Control Plane must be logged with: +which human user, what action, when, and the resulting Trust-Service- +signed record's id — **in the Control Plane's own storage**, since the +Trust Service itself has no concept of individual human users under one +Licensor token (§2). This log is the answer to "who actually clicked the +button," which matters operationally even though it's not part of the +Trust Service's own cryptographic guarantees. + +## 6. Explicit non-goals + +- Replacing `scripts/trf_onboard.py` — the CLI remains valid for + scripted/CI use; the Control Plane is for interactive human use. +- Changing the Trust Service's core guarantees (determinism, append-only, + no discretionary conversion authority) — the Control Plane is a client, + bound by the same rules any other client is. +- Deciding the human-user rights model unilaterally — §2 is a proposal + for workplan T01 to confirm, not a decided design. +- Multi-tenant support for Licensors other than `binky` — in scope + structurally (the Trust Service already supports multiple Licensors, + TS-FR-8), but this concept is scoped to the one tenant that currently + exists; extending the UI to other tenants is natural future work, not + blocking this concept. diff --git a/workplans/TREV-WP-0009-control-plane-and-effort-calculator.md b/workplans/TREV-WP-0009-control-plane-and-effort-calculator.md new file mode 100644 index 0000000..e3a0fde --- /dev/null +++ b/workplans/TREV-WP-0009-control-plane-and-effort-calculator.md @@ -0,0 +1,132 @@ +--- +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" +--- + +# 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 +``` + +`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 +``` + +`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 +``` + +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 +``` + +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 +``` + +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.