From b0f61b2d8b7f3be51e605fb1e49cb418de027983 Mon Sep 17 00:00:00 2001 From: tegwick Date: Wed, 29 Jul 2026 23:15:42 +0200 Subject: [PATCH] Add info-tech-canon as first dry-run pilot candidate, exercise onboarding routine 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. --- README.md | 2 +- examples/pilot-candidates/README.md | 13 ++++- .../ledger.json | 1 + .../manifest.json | 28 ++++++++++ specs/PilotPhaseCandidateSurvey.md | 55 ++++++++++++++++--- tests/test_pilot_candidate_manifests.py | 17 +++--- ...EV-WP-0008-governance-and-pilot-rollout.md | 23 ++++++++ 7 files changed, 122 insertions(+), 17 deletions(-) create mode 100644 examples/pilot-candidates/info-tech-canon-service-surface/ledger.json create mode 100644 examples/pilot-candidates/info-tech-canon-service-surface/manifest.json diff --git a/README.md b/README.md index 428f845..9077294 100644 --- a/README.md +++ b/README.md @@ -80,7 +80,7 @@ The concept's §13 now defines a **Global Contingency Share Determination Rule** | [TREV-WP-0005](workplans/TREV-WP-0005-enforcement-network-research.md) | Enforcement Network legal feasibility research — **finished**, T10 synthesis accepted 2026-07-29 on the same alpha/beta basis (Japan's Article 12 risk remains explicitly unresolved) | | [TREV-WP-0006](workplans/TREV-WP-0006-trust-service-implementation.md) | Hosted Trust Service reference implementation (PRD Phase 4b) — **finished**, all 9 tasks done (Postgres-backed registries/ledger/metrics/attestation/breach-record, ADR-0002 accepted, onboarding CLI, hosted conformance suite) | | [TREV-WP-0007](workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md) | Degeneration policy + canonical monetization profile catalog — **finished**, all 4 tasks done. `trsl:policy:linear-longstop-v0` confirmed 2026-07-29 as the v1 norm for the first pilot cohort; `progress-paused-longstop-v1` named as the next iteration, not yet adopted | -| [TREV-WP-0008](workplans/TREV-WP-0008-governance-and-pilot-rollout.md) | Governance formalization + pilot rollout across `coulomb-loop`/`net-kingdom`/`helix-forge`/`railiance-*` — active; T01 (Licensor: Binky Hedgehog GmbH), T02 (candidate survey), T03 (draft pilot manifests), T04 (CLA draft) done; T05 (go-live gate, human decision) remains `todo` by design | +| [TREV-WP-0008](workplans/TREV-WP-0008-governance-and-pilot-rollout.md) | Governance formalization + pilot rollout across `coulomb-loop`/`net-kingdom`/`helix-forge`/`railiance-*` — active; T01 (Licensor: Binky Hedgehog GmbH), T02 (candidate survey), T03 (draft pilot manifests), T04 (CLA draft) done. `info-tech-canon` added 2026-07-29 as the maintainer's chosen first repo to build up the routine on (dry run only, confirmed) — full onboarding CLI round trip exercised end-to-end against a live local instance. T05 (go-live gate, human decision) remains `todo` by design | Hub index: [`WORK-RECORDS.md`](WORK-RECORDS.md) · brief: [`.custodian-brief.md`](.custodian-brief.md) diff --git a/examples/pilot-candidates/README.md b/examples/pilot-candidates/README.md index 99f4b7a..13795a0 100644 --- a/examples/pilot-candidates/README.md +++ b/examples/pilot-candidates/README.md @@ -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 diff --git a/examples/pilot-candidates/info-tech-canon-service-surface/ledger.json b/examples/pilot-candidates/info-tech-canon-service-surface/ledger.json new file mode 100644 index 0000000..fe51488 --- /dev/null +++ b/examples/pilot-candidates/info-tech-canon-service-surface/ledger.json @@ -0,0 +1 @@ +[] diff --git a/examples/pilot-candidates/info-tech-canon-service-surface/manifest.json b/examples/pilot-candidates/info-tech-canon-service-surface/manifest.json new file mode 100644 index 0000000..84edca6 --- /dev/null +++ b/examples/pilot-candidates/info-tech-canon-service-surface/manifest.json @@ -0,0 +1,28 @@ +{ + "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" + ] +} diff --git a/specs/PilotPhaseCandidateSurvey.md b/specs/PilotPhaseCandidateSurvey.md index bbdfb4e..a2658ea 100644 --- a/specs/PilotPhaseCandidateSurvey.md +++ b/specs/PilotPhaseCandidateSurvey.md @@ -128,6 +128,45 @@ that broader roadmap information. --- +## 4a. `info-tech-canon` — added 2026-07-29, maintainer-selected first repo + +Outside this survey's original four product lines, the maintainer +selected `info-tech-canon` directly as the actual first repo to build up +the practical Phase-declaration routine on — **confirmed explicitly as a +dry run, not a go-live decision** (`examples/pilot-candidates/README.md`). + +**One-liner:** "Building interoperable, adaptable, and extensible +information-processing systems" — InfoTechCanon: a markdown-first canon +of standards/models plus a real, running service surface (CLI, importable +Python service functions, a local JSON/HTTP API) built on top of it. + +**Candidate:** the cumulative service surface across all twelve finished +workplans (`ITC-WP-0001` through `ITC-WP-0012`, all `status: finished`, +most recently `ITC-WP-0012` "Canonical Repository Layout Standard +Integration," commit `f7ad73d`) — the kernel, service surface (CLI + +JSON + local HTTP API), validation/indexing, a worked "small SaaS" +profile proof, and consumer-facing review-kit/alignment tooling, all +already used by at least one other repo in this ecosystem +(`ITC-WP-0008` explicitly supports `railiance-fabric` conformance). + +**Notable complication, flagged rather than smoothed over:** this repo's +current `LICENSE` is already **MIT-0** — fully permissive today. A real +Phase declaration for this repo (unlike `net-kingdom`/`railiance-apps`, +which are not currently under any delayed-open-source license) would +require *replacing* an already-open license with the restricted +pre-conversion TRSL terms, not merely adding a monetization layer to a +previously-closed codebase. That is a materially different, and more +visible, change than the other two candidates involve — one more reason +the maintainer's dry-run-only choice here is the right call before any +real T05 decision. + +**Indicative Target Multiple classification:** **Product-defining +(100x)** — a real, differentiated, reusable standards-and-service +capability that other repos already depend on, not mere cost recovery or +an incremental tweak; not classified 1000x ("platform-defining") absent +evidence it constitutes a new platform/market/ecosystem beyond its +current consumer base. + ## 5. Summary table for T03 | Product line | Candidate | Status | Indicative Target Multiple | @@ -136,14 +175,16 @@ that broader roadmap information. | `net-kingdom` | `NK-WP-0002` Local Identity | Finished 2026-03-05 | Incremental (10x) | | `helix-forge` | None (pre-product) | — | — | | `railiance-*` | `vergabe-teilnahme` (`RAILIANCE-WP-0002`/`-0014`) | Finished 2026-05-19 / refreshed 2026-07-11 | Product-defining (100x) | +| `info-tech-canon` | Service surface (`ITC-WP-0001`–`0012`) | All finished, latest 2026-06-13 | Product-defining (100x) | -Two of four product lines (`net-kingdom`, `railiance-*`) have a -defensible candidate; two (`coulomb-loop`, `helix-forge`) do not, for -principled reasons stated above, not because the survey was shallow. -T03's draft, non-binding worked Phase Manifest examples should be built -from the two real candidates — inventing manifests for the other two -would misrepresent repos that are not yet at a stage this framework -applies to. +Two of the original four product lines (`net-kingdom`, `railiance-*`) +have a defensible candidate; two (`coulomb-loop`, `helix-forge`) do not, +for principled reasons stated above, not because the survey was shallow. +`info-tech-canon` was added afterward as the maintainer's own choice for +the first practical dry run, not part of the original four-product-line +survey. T03's draft, non-binding worked Phase Manifest examples should be +built from real candidates only — inventing manifests for repos not yet +at a stage this framework applies to would misrepresent them. ## 6. Non-goals diff --git a/tests/test_pilot_candidate_manifests.py b/tests/test_pilot_candidate_manifests.py index 1bc6e5f..3cbfa3f 100644 --- a/tests/test_pilot_candidate_manifests.py +++ b/tests/test_pilot_candidate_manifests.py @@ -16,20 +16,21 @@ from target_revenue import validation PILOT_CANDIDATES_DIR = REPO_ROOT / "examples" / "pilot-candidates" -@pytest.mark.parametrize( - "name", - ["net-kingdom-local-identity", "railiance-vergabe-teilnahme"], -) +PILOT_CANDIDATE_NAMES = [ + "net-kingdom-local-identity", + "railiance-vergabe-teilnahme", + "info-tech-canon-service-surface", +] + + +@pytest.mark.parametrize("name", PILOT_CANDIDATE_NAMES) def test_pilot_candidate_manifest_is_conformant(name): manifest = json.loads((PILOT_CANDIDATES_DIR / name / "manifest.json").read_text()) validation.validate_phase_manifest(manifest) assert manifest["phase"]["id"].startswith("trsl:phase:draft-") -@pytest.mark.parametrize( - "name", - ["net-kingdom-local-identity", "railiance-vergabe-teilnahme"], -) +@pytest.mark.parametrize("name", PILOT_CANDIDATE_NAMES) def test_pilot_candidate_ledger_is_empty_draft_state(name): ledger = json.loads((PILOT_CANDIDATES_DIR / name / "ledger.json").read_text()) assert ledger == [], "draft candidates must not carry any real ledger entries" diff --git a/workplans/TREV-WP-0008-governance-and-pilot-rollout.md b/workplans/TREV-WP-0008-governance-and-pilot-rollout.md index d0cad24..68101db 100644 --- a/workplans/TREV-WP-0008-governance-and-pilot-rollout.md +++ b/workplans/TREV-WP-0008-governance-and-pilot-rollout.md @@ -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