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

23
workplans/TREV-WP-0008-governance-and-pilot-rollout.md
View file

@ -154,6 +154,29 @@ Entitlement is for sale, no Development Credit is tracked, and neither
repo's actual License header has changed — nothing here is authorized to
go live regardless of how complete it looks (T05 still gates that).
**Addendum, 2026-07-29:** the maintainer separately 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.** A third draft
manifest, `examples/pilot-candidates/info-tech-canon-service-surface/`,
was added (candidate: the cumulative service surface across
`ITC-WP-0001`–`ITC-WP-0012`, all finished; Product-defining 100x;
`specs/PilotPhaseCandidateSurvey.md` §4a). Notable complication surfaced
and flagged rather than smoothed over: this repo's current `LICENSE` is
already MIT-0 — a real Phase here would mean *replacing* an already-open
license with restricted pre-conversion TRSL terms, a materially different
and more visible step than the other two candidates. The full onboarding
routine (`scripts/trf_onboard.py register-phase` → `append-entry` →
`status`) was exercised end-to-end against a real, ephemeral local
instance of the hosted Trust Service (Docker Postgres, migrations
0001–0004 applied, `binky` Licensor token seeded, `uvicorn` running the
actual `service/app.py`) — register, a 10,000 EUR illustrative
development-credit entry, and a status check all worked exactly as
`specs/TrustServiceOnboarding.md` describes, with no code changes needed.
The dry-run Postgres container and service process were both torn down
afterward; nothing from this exercise persists beyond the draft manifest
files themselves.
## Contributor rights instrument (CLA)
```task