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.
28 lines
799 B
JSON
28 lines
799 B
JSON
{
|
|
"framework": "TRF-0.1",
|
|
"license": "TRSL-0.1",
|
|
"phase": {
|
|
"id": "trsl:phase:draft-info-tech-canon-service-surface",
|
|
"milestone_release": {
|
|
"name": "info-tech-canon-service-surface-v1 (ITC-WP-0001..0012)",
|
|
"source_revision": "f7ad73d"
|
|
},
|
|
"initial_target": {
|
|
"amount": 2500000,
|
|
"currency": "EUR"
|
|
},
|
|
"target_basis": {
|
|
"estimated_effort_days": 25,
|
|
"daily_rate": 1000,
|
|
"approved_direct_costs": 0,
|
|
"target_multiple": 100
|
|
},
|
|
"future_license": "MIT",
|
|
"degeneration_policy": "trsl:policy:linear-longstop-v0@1.0",
|
|
"longstop_at": "2029-01-01T00:00:00Z",
|
|
"ledger": "examples/pilot-candidates/info-tech-canon-service-surface/ledger.json"
|
|
},
|
|
"extensions": [
|
|
"trsl:extension:development-license@1.0"
|
|
]
|
|
}
|