coulomb/target-revenue
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add info-tech-canon as first dry-run pilot candidate, exercise onboarding routine

Browse source 
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.
This commit is contained in:
tegwick 2026-07-29 23:15:42 +02:00
parent a29d781d92
commit b0f61b2d8b
7 changed files with 122 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

13
examples/pilot-candidates/README.md
View file

@ -16,14 +16,25 @@ Built from the two candidates identified with a defensible rationale in
`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.
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