Advance WP-0008: governance, candidate survey, pilot manifests, CLA draft
T01: specs/TRSL-Governance.md. Resolves the Licensor-identity question
(maintainer decision, 2026-07-29): a single shared Licensor, Binky
Hedgehog GmbH, operating as the binky tenant, across all four product
lines - not per-product-line. Unblocks (does not itself resolve) the
License/CUA arbitral-institution selection now that the Licensor's own
jurisdiction is known. Tables versioning/extension-governance/operator-
governance status per concept §20, naming open items (compatibility
rules, deprecation criteria, conflict-of-interest rule, key-rotation
history) rather than silently assuming them solved.
T02: specs/PilotPhaseCandidateSurvey.md. Direct repo inspection (hub
had no goal data for three of four product lines) plus an Explore-agent
survey of all ten railiance-* repos. Two defensible candidates found:
NK-WP-0002 Local Identity (net-kingdom, Incremental 10x) and
vergabe-teilnahme (railiance-apps, Product-defining 100x, the only
genuinely product-shaped deliverable across ten railiance-* repos).
coulomb-loop and helix-forge have no candidate, for stated principled
reasons (internal tooling; pre-implementation-stage, respectively).
T03: examples/pilot-candidates/ - draft, non-binding Phase Manifests
for both real candidates, trsl:phase:draft-* ids, empty ledgers,
schema-validated, explicit README stating nothing here is authorized
to go live.
T04: specs/TRSL-ContributorLicenseAgreement-Draft.md, implementing the
CLA-not-assignment recommendation from
history/260729-TRSL-ContributorRights-Research.md - narrowly scoped to
the current Phase's TRSL terms plus its already-declared Future
License at Conversion, same preliminary-candidate treatment as the
License/CUA V1C1 documents. CONTRIBUTING.md updated to point at it
while keeping the external-contribution block in effect until accepted.
T05's precondition list updated to reflect what's now resolved, still
left todo by design pending the maintainer's own go-live decision.
2026-07-29 22:52:52 +02:00
|
|
|
|
# Pilot candidate Phase Manifests — DRAFT, NOT DECLARED
|
|
|
|
|
|
|
|
|
|
|
|
These manifests are **draft, non-binding worked examples**
|
|
|
|
|
|
(`workplans/TREV-WP-0008-governance-and-pilot-rollout.md` T03), following
|
|
|
|
|
|
the pattern established by `examples/phase-001/`. They are structurally
|
|
|
|
|
|
valid and conformance-tested exactly like `examples/phase-001/`, but:
|
|
|
|
|
|
|
|
|
|
|
|
- **No Commercial Entitlement is for sale under either manifest.**
|
|
|
|
|
|
- **No Development Credit is being tracked for either candidate.**
|
|
|
|
|
|
- **Neither repo's actual License header has been changed to TRSL.**
|
|
|
|
|
|
- `phase.id` uses a `draft-` prefix specifically so it cannot be confused
|
|
|
|
|
|
with a real, declared Phase.
|
|
|
|
|
|
|
|
|
|
|
|
Built from the two candidates identified with a defensible rationale in
|
|
|
|
|
|
`specs/PilotPhaseCandidateSurvey.md` (T02) — `coulomb-loop` and
|
|
|
|
|
|
`helix-forge` produced no defensible candidate at survey time and are
|
|
|
|
|
|
not represented here.
|
|
|
|
|
|
|
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.
2026-07-29 23:15:42 +02:00
|
|
|
|
**`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.
|
|
|
|
|
|
|
Advance WP-0008: governance, candidate survey, pilot manifests, CLA draft
T01: specs/TRSL-Governance.md. Resolves the Licensor-identity question
(maintainer decision, 2026-07-29): a single shared Licensor, Binky
Hedgehog GmbH, operating as the binky tenant, across all four product
lines - not per-product-line. Unblocks (does not itself resolve) the
License/CUA arbitral-institution selection now that the Licensor's own
jurisdiction is known. Tables versioning/extension-governance/operator-
governance status per concept §20, naming open items (compatibility
rules, deprecation criteria, conflict-of-interest rule, key-rotation
history) rather than silently assuming them solved.
T02: specs/PilotPhaseCandidateSurvey.md. Direct repo inspection (hub
had no goal data for three of four product lines) plus an Explore-agent
survey of all ten railiance-* repos. Two defensible candidates found:
NK-WP-0002 Local Identity (net-kingdom, Incremental 10x) and
vergabe-teilnahme (railiance-apps, Product-defining 100x, the only
genuinely product-shaped deliverable across ten railiance-* repos).
coulomb-loop and helix-forge have no candidate, for stated principled
reasons (internal tooling; pre-implementation-stage, respectively).
T03: examples/pilot-candidates/ - draft, non-binding Phase Manifests
for both real candidates, trsl:phase:draft-* ids, empty ledgers,
schema-validated, explicit README stating nothing here is authorized
to go live.
T04: specs/TRSL-ContributorLicenseAgreement-Draft.md, implementing the
CLA-not-assignment recommendation from
history/260729-TRSL-ContributorRights-Research.md - narrowly scoped to
the current Phase's TRSL terms plus its already-declared Future
License at Conversion, same preliminary-candidate treatment as the
License/CUA V1C1 documents. CONTRIBUTING.md updated to point at it
while keeping the external-contribution block in effect until accepted.
T05's precondition list updated to reflect what's now resolved, still
left todo by design pending the maintainer's own go-live decision.
2026-07-29 22:52:52 +02:00
|
|
|
|
**Nothing here is authorized to go live.** That remains gated behind
|
|
|
|
|
|
`workplans/TREV-WP-0008-governance-and-pilot-rollout.md` T05, regardless
|
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.
2026-07-29 23:15:42 +02:00
|
|
|
|
of how complete or plausible these examples look — including
|
|
|
|
|
|
`info-tech-canon`, which was explicitly confirmed as dry-run-only.
|
Advance WP-0008: governance, candidate survey, pilot manifests, CLA draft
T01: specs/TRSL-Governance.md. Resolves the Licensor-identity question
(maintainer decision, 2026-07-29): a single shared Licensor, Binky
Hedgehog GmbH, operating as the binky tenant, across all four product
lines - not per-product-line. Unblocks (does not itself resolve) the
License/CUA arbitral-institution selection now that the Licensor's own
jurisdiction is known. Tables versioning/extension-governance/operator-
governance status per concept §20, naming open items (compatibility
rules, deprecation criteria, conflict-of-interest rule, key-rotation
history) rather than silently assuming them solved.
T02: specs/PilotPhaseCandidateSurvey.md. Direct repo inspection (hub
had no goal data for three of four product lines) plus an Explore-agent
survey of all ten railiance-* repos. Two defensible candidates found:
NK-WP-0002 Local Identity (net-kingdom, Incremental 10x) and
vergabe-teilnahme (railiance-apps, Product-defining 100x, the only
genuinely product-shaped deliverable across ten railiance-* repos).
coulomb-loop and helix-forge have no candidate, for stated principled
reasons (internal tooling; pre-implementation-stage, respectively).
T03: examples/pilot-candidates/ - draft, non-binding Phase Manifests
for both real candidates, trsl:phase:draft-* ids, empty ledgers,
schema-validated, explicit README stating nothing here is authorized
to go live.
T04: specs/TRSL-ContributorLicenseAgreement-Draft.md, implementing the
CLA-not-assignment recommendation from
history/260729-TRSL-ContributorRights-Research.md - narrowly scoped to
the current Phase's TRSL terms plus its already-declared Future
License at Conversion, same preliminary-candidate treatment as the
License/CUA V1C1 documents. CONTRIBUTING.md updated to point at it
while keeping the external-contribution block in effect until accepted.
T05's precondition list updated to reflect what's now resolved, still
left todo by design pending the maintainer's own go-live decision.
2026-07-29 22:52:52 +02:00
|
|
|
|
|
|
|
|
|
|
| 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) |
|
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.
2026-07-29 23:15:42 +02:00
|
|
|
|
| `info-tech-canon-service-surface/` | `info-tech-canon` | Cumulative service surface, `ITC-WP-0001`–`ITC-WP-0012` | Product-defining (100x) |
|
Advance WP-0008: governance, candidate survey, pilot manifests, CLA draft
T01: specs/TRSL-Governance.md. Resolves the Licensor-identity question
(maintainer decision, 2026-07-29): a single shared Licensor, Binky
Hedgehog GmbH, operating as the binky tenant, across all four product
lines - not per-product-line. Unblocks (does not itself resolve) the
License/CUA arbitral-institution selection now that the Licensor's own
jurisdiction is known. Tables versioning/extension-governance/operator-
governance status per concept §20, naming open items (compatibility
rules, deprecation criteria, conflict-of-interest rule, key-rotation
history) rather than silently assuming them solved.
T02: specs/PilotPhaseCandidateSurvey.md. Direct repo inspection (hub
had no goal data for three of four product lines) plus an Explore-agent
survey of all ten railiance-* repos. Two defensible candidates found:
NK-WP-0002 Local Identity (net-kingdom, Incremental 10x) and
vergabe-teilnahme (railiance-apps, Product-defining 100x, the only
genuinely product-shaped deliverable across ten railiance-* repos).
coulomb-loop and helix-forge have no candidate, for stated principled
reasons (internal tooling; pre-implementation-stage, respectively).
T03: examples/pilot-candidates/ - draft, non-binding Phase Manifests
for both real candidates, trsl:phase:draft-* ids, empty ledgers,
schema-validated, explicit README stating nothing here is authorized
to go live.
T04: specs/TRSL-ContributorLicenseAgreement-Draft.md, implementing the
CLA-not-assignment recommendation from
history/260729-TRSL-ContributorRights-Research.md - narrowly scoped to
the current Phase's TRSL terms plus its already-declared Future
License at Conversion, same preliminary-candidate treatment as the
License/CUA V1C1 documents. CONTRIBUTING.md updated to point at it
while keeping the external-contribution block in effect until accepted.
T05's precondition list updated to reflect what's now resolved, still
left todo by design pending the maintainer's own go-live decision.
2026-07-29 22:52:52 +02:00
|
|
|
|
|
Apply Development Effort Calculator to real pilot candidates (WP-0010-T03)
Adds since/until date-range scoping to cluster_commit_hours() and
workplan_task_counts() (threaded through calculate_target_basis()),
needed whenever a candidate is one bounded workplan within a repo
whose overall history spans much more (net-kingdom, railiance-apps)
rather than the whole repo being the candidate (vergabe-teilnahme,
info-tech-canon).
Fixes a real bug found along the way: workplan_task_counts() only
scanned the top level of workplans/, missing net-kingdom's
workplans/archived/ convention entirely - silently reported zero
finished workplans for NK-WP-0002, which lives there. Fixed to scan
recursively; added a regression test.
Updates all three draft pilot-candidate manifests with calculator-
derived target_basis/initial_target values, replacing the hand-picked
placeholders:
net-kingdom-local-identity: 200,000 -> 10,000 EUR (floor + sanity warnings)
railiance-vergabe-teilnahme: 3,500,000 -> 648,800 EUR (no warnings)
info-tech-canon-service-surface: 2,500,000 -> 141,800 EUR (sanity warning)
history/260730-EffortCalculator-CandidateApplication.md records full
derivation, warnings, and the judgment calls made explicit rather than
silently picked (date-scoping windows; measuring vergabe-teilnahme's
own repo rather than railiance-apps' deployment-only wiring, with both
figures shown). Still draft/non-binding - WP-0008-T05 unaffected.
5 new tests (20 -> now covering since/until scoping and the
archived-subdirectory fix). Full suite: 84 passing offline.
2026-07-30 13:29:06 +02:00
|
|
|
|
**`target_basis`/`initial_target` figures (updated 2026-07-30):** all
|
|
|
|
|
|
three now use `target_revenue.effort_calculator`-derived values
|
|
|
|
|
|
(`workplans/TREV-WP-0010-development-effort-calculator.md` T03), not the
|
|
|
|
|
|
originally hand-picked illustrative placeholders. Full derivation,
|
|
|
|
|
|
warnings, and the judgment calls involved (date-scoping, and which of two
|
|
|
|
|
|
repos to measure for `railiance-vergabe-teilnahme`) are in
|
|
|
|
|
|
`history/260730-EffortCalculator-CandidateApplication.md`. Two of the
|
|
|
|
|
|
three carry explicit calculator warnings recommending a manual override
|
|
|
|
|
|
before any real use — these are still draft, non-binding figures, not a
|
|
|
|
|
|
settled costing proposal. See `specs/PilotPhaseCandidateSurvey.md` for
|
|
|
|
|
|
the underlying candidate rationale (unaffected by this figure update).
|