tegwick
2a176d9961
Schema: phase.milestone_release gains required repo_hub/repo_hub_uri/
repo_id/repo_name; phase gains optional base_phase_id. Backfilled the
golden phase-001 fixture (placeholder values, it's synthetic) and the
three real pilot-candidate manifests with actual Forgejo repo ids
confirmed live (net-kingdom=67, vergabe-teilnahme=62,
info-tech-canon=47, all coulomb/*).
Discovered along the way: the schema change alone would have broken
the existing Control Plane registration form, since nothing collected
the four new fields. Fixed inline rather than leaving it broken
between tasks -- this also completes T04's ledger UI change (drop the
hand-typed ledger input, auto-compute /phases/{id}/ledger, add a
drill-down reference link on phase_detail.html) since both changes
touch the same form/route.
Full suite: 94 passing offline (was 84), 158 passing with Docker
(was 146).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| info-tech-canon-service-surface | ||
| net-kingdom-local-identity | ||
| railiance-vergabe-teilnahme | ||
| README.md | ||
Pilot candidate Phase Manifests — DRAFT, NOT DECLARED
These manifests are draft, non-binding worked examples
(workplans/TREV-WP-0008-governance-and-pilot-rollout.md T03), following
the pattern established by examples/phase-001/. They are structurally
valid and conformance-tested exactly like examples/phase-001/, but:
- No Commercial Entitlement is for sale under either manifest.
- No Development Credit is being tracked for either candidate.
- Neither repo's actual License header has been changed to TRSL.
phase.iduses adraft-prefix specifically so it cannot be confused with a real, declared Phase.
Built from the two candidates identified with a defensible rationale in
specs/PilotPhaseCandidateSurvey.md (T02) — coulomb-loop and
helix-forge produced no defensible candidate at survey time and are
not represented here.
info-tech-canon (2026-07-29): the maintainer chose info-tech-canon
as the actual first repo to build up the practical Phase-declaration
routine on, explicitly as a dry run, not a go-live decision
(confirmed directly, not assumed) — see
specs/PilotPhaseCandidateSurvey.md §5 for the candidate rationale. This
repo was outside the original four product lines T02 surveyed; its
candidate was added afterward as this specific, real routine-building
exercise, not a T02 survey gap.
Nothing here is authorized to go live. That remains gated behind
workplans/TREV-WP-0008-governance-and-pilot-rollout.md T05, regardless
of how complete or plausible these examples look — including
info-tech-canon, which was explicitly confirmed as dry-run-only.
| Directory | Product line | Candidate deliverable | Indicative Target Multiple |
|---|---|---|---|
net-kingdom-local-identity/ |
net-kingdom |
NK-WP-0002 Local Identity |
Incremental (10x) |
railiance-vergabe-teilnahme/ |
railiance-* (railiance-apps) |
vergabe-teilnahme (RAILIANCE-WP-0002/-0014) |
Product-defining (100x) |
info-tech-canon-service-surface/ |
info-tech-canon |
Cumulative service surface, ITC-WP-0001–ITC-WP-0012 |
Product-defining (100x) |
target_basis/initial_target figures (updated 2026-07-30): all
three now use target_revenue.effort_calculator-derived values
(workplans/TREV-WP-0010-development-effort-calculator.md T03), not the
originally hand-picked illustrative placeholders. Full derivation,
warnings, and the judgment calls involved (date-scoping, and which of two
repos to measure for railiance-vergabe-teilnahme) are in
history/260730-EffortCalculator-CandidateApplication.md. Two of the
three carry explicit calculator warnings recommending a manual override
before any real use — these are still draft, non-binding figures, not a
settled costing proposal. See specs/PilotPhaseCandidateSurvey.md for
the underlying candidate rationale (unaffected by this figure update).