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.
This commit is contained in:
parent
a29d781d92
commit
b0f61b2d8b
7 changed files with 122 additions and 17 deletions
|
|
@ -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)
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
[]
|
||||
|
|
@ -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"
|
||||
]
|
||||
}
|
||||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue