tegwick
b0f61b2d8b
Maintainer chose info-tech-canon (outside the original four product lines) as the actual first repo to build up the practical Phase-declaration routine on, explicitly confirmed as a dry run, not a T05 go-live decision. Adds a third draft, non-binding manifest (examples/pilot-candidates/info-tech-canon-service-surface/): the cumulative service surface across ITC-WP-0001-0012 (all finished), Product-defining (100x). Flags a notable complication rather than smoothing it over: this repo's current LICENSE is already MIT-0, so a real Phase here would mean replacing an already-open license with restricted pre-conversion TRSL terms - a materially different step than the other two candidates. Exercised the full onboarding routine end-to-end against a real, ephemeral local instance of the hosted Trust Service (Docker Postgres, migrations applied, binky Licensor token seeded, uvicorn running the actual service/app.py): register-phase -> append-entry -> status all worked via scripts/trf_onboard.py exactly as specs/TrustServiceOnboarding.md describes, no code changes needed. Dry-run infrastructure torn down afterward; only the draft manifest files persist.
42 lines
2.3 KiB
Markdown
42 lines
2.3 KiB
Markdown
# 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.id` uses a `draft-` 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) |
|
||
|
||
All figures (`initial_target`, `target_basis`) are illustrative
|
||
placeholders for this worked-example exercise, not a real costing or
|
||
pricing proposal — see `specs/PilotPhaseCandidateSurvey.md` for the
|
||
underlying candidate rationale.
|