tegwick
9886742fa8
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.
158 lines
8.5 KiB
Markdown
158 lines
8.5 KiB
Markdown
# Pilot Phase Candidate Survey
|
|
|
|
Status: Draft v0.1
|
|
Date: 2026-07-29
|
|
Workplan: `workplans/TREV-WP-0008-governance-and-pilot-rollout.md` T02
|
|
Feeds: `workplans/TREV-WP-0008-governance-and-pilot-rollout.md` T03 (draft pilot Phase Manifests)
|
|
Primary artifacts: `specs/TargetRevenueFrameworkCore.md` §1.4 (Target Multiple)
|
|
|
|
Surveys `coulomb-loop`, `net-kingdom`, `helix-forge`, and the
|
|
`railiance-*` family for one plausible first Milestone Release candidate
|
|
per product line — a bounded, recently- or soon-to-be-completed piece of
|
|
work with a defensible Target Multiple classification, not an arbitrary
|
|
pick. The state hub's `get_repo_goals` returned no data for
|
|
`coulomb-loop`, `net-kingdom`, or `helix-forge` at survey time, so this
|
|
relied on direct repo inspection (README/SCOPE.md, `git log`, `workplans/`)
|
|
instead, per the task's own fallback instruction.
|
|
|
|
**This is a candidate survey, not a Phase declaration.** Nothing here
|
|
authorizes any real Phase — that remains gated behind T05.
|
|
|
|
---
|
|
|
|
## 1. `coulomb-loop` — no defensible candidate found
|
|
|
|
**One-liner:** "Customer engagement repository for Coulomb fleet
|
|
self-improvement loops — contracts, rosters, and activity definitions;
|
|
not agent runtime" (SCOPE.md). Its own scope explicitly excludes
|
|
"application code for Coulomb products" — this repo organizes *how* other
|
|
repos get worked on, it does not itself contain a product.
|
|
|
|
**Recent activity:** workplan-first agent guidance, instruction
|
|
regeneration from state-hub templates, `.repo-classification.yaml` setup —
|
|
all internal coordination tooling, not customer-facing capability.
|
|
|
|
**Recommendation:** no candidate. Forcing a pick here would violate the
|
|
task's own "not an arbitrary pick" instruction — this repo is
|
|
infrastructure for *how work happens*, not a governed software capability
|
|
a Customer would pay for. Revisit if `coulomb-loop`'s scope changes, or
|
|
treat product Phases for Coulomb-managed products as living in those
|
|
products' own repos rather than here.
|
|
|
|
## 2. `net-kingdom` — candidate: Local Identity (`NK-WP-0002`)
|
|
|
|
**One-liner:** "Platform domain for NetKingdom identity and security
|
|
services" (SCOPE.md) — a real product domain, unlike `coulomb-loop`.
|
|
|
|
**Candidate:** `NK-WP-0002` — "Local Identity: Bootstrap User Store &
|
|
Minimal OIDC" (finished 2026-03-05). A zero-dependency, file-based user
|
|
management capability deriving the primary user from the Linux identity,
|
|
auto-generating test users, and (Stage 3) providing a minimal native OIDC
|
|
provider for dev/test use — a standalone, bounded capability a Kubernetes
|
|
deployment without a running Keycloak/full IAM stack yet could adopt
|
|
independently.
|
|
|
|
**Passed over:**
|
|
- `NK-WP-0001` (Keycloak SSO/MFA Platform) — status `DEFERRED`, superseded
|
|
by `NK-WP-0003` (KeyCape + Authelia + LLDAP). Not a clean "finished"
|
|
candidate; the stack it targeted is no longer the deployed one.
|
|
- `NET-WP-0020` (OpenBao unseal custody models), `NK-WP-0021`
|
|
(activity-core ops/Temporal UI least-privilege SSO) — both finished and
|
|
real, but both are *operational hardening of NetKingdom's own
|
|
infrastructure* (secrets custody, internal operator access control), not
|
|
a bounded capability an external Customer would license. These are
|
|
exactly the kind of "internal-infra, necessary but not product-shaped"
|
|
work the task's Target Multiple guidance is meant to screen out.
|
|
- `NK-WP-0022`/`NK-WP-0023` (railiance01 identity cutover, user-engine
|
|
portal integration) — currently `active`, not yet a "finished" candidate.
|
|
|
|
**Indicative Target Multiple classification:** **Incremental (10x)** —
|
|
NK-WP-0002 is a material, standalone enhancement (bootstrap identity
|
|
without a full IAM stack dependency) rather than a net-new platform
|
|
(1000x) or mere cost recovery (1x); it is a real, reusable capability, not
|
|
a from-scratch new market (100x-class "product-defining" would overstate
|
|
a bootstrap utility component).
|
|
|
|
## 3. `helix-forge` — no candidate; explicitly pre-product
|
|
|
|
**One-liner:** "HelixForge defines a capability-first development
|
|
ecosystem for turning human intent into governed, reusable software
|
|
capabilities" — but its own SCOPE.md states plainly: **"It is not yet an
|
|
application implementation."**
|
|
|
|
**Recommendation:** no candidate, and this is not a survey gap — the repo
|
|
itself says it is not yet at the implementation stage a Milestone Release
|
|
requires. Revisit once HelixForge produces an actual implemented
|
|
capability, not its current intent/architecture/vocabulary artifacts.
|
|
|
|
## 4. `railiance-*` family — candidate: `vergabe-teilnahme` (`railiance-apps` / `RAILIANCE-WP-0002`)
|
|
|
|
Surveyed all ten repos (`railiance-apps`, `-bootstrap` [not found under
|
|
this exact name at survey time], `-cluster`, `-enablement`, `-fabric`,
|
|
`-forge`, `-hosts`, `-infra`, `-master`, `-platform`).
|
|
|
|
**Candidate:** `RAILIANCE-WP-0002` (`railiance-apps`, finished 2026-05-19,
|
|
refreshed by `RAILIANCE-WP-0014` finished 2026-07-11) — deployed
|
|
`vergabe-teilnahme`, a Django application supporting participation in
|
|
German public-sector procurement ("Vergabe") processes, to production at
|
|
`https://vergabe-teilnahme.whywhynot.de`, with its own PostgreSQL
|
|
database, container registry image, HTTPS/cert-manager TLS, and an
|
|
operator runbook.
|
|
|
|
**Why this is the strongest candidate across the whole family:** it is
|
|
the *only* deliverable found across all ten repos that is genuinely
|
|
product-shaped — a discrete, customer-facing application a business that
|
|
participates in public tenders could plausibly license or subscribe to.
|
|
Everything else surveyed is internal infrastructure necessary to keep the
|
|
Railiance stack itself running:
|
|
|
|
| Repo | What was found | Why passed over |
|
|
|---|---|---|
|
|
| `railiance-cluster` | Kubernetes substrate (k3s, Helm, ingress, CNI), most recently a Knative serving install | Infra plumbing, not customer-facing |
|
|
| `railiance-enablement` | CI/CD templates, SDKs, buildpacks | Internal developer tooling |
|
|
| `railiance-fabric` | Ecosystem graph/registry modeling repo-family relations | Internal ontology/graph plumbing |
|
|
| `railiance-forge` | Forgejo/Gitea, registries, Actions runners | Internal build/artifact infra |
|
|
| `railiance-hosts` | Legacy Terraform/Ansible server provisioning, being retired in favor of `railiance-infra` | Superseded internal infra |
|
|
| `railiance-infra` | Canonical infra substrate (successor to `-hosts`); recent finished work is a Forgejo production migration | Internal ops |
|
|
| `railiance-master` | Repo taxonomy, cross-repo ADRs — architecture home, not even code-shaped | Organizational restructuring, not software |
|
|
| `railiance-platform` | Shared platform services (Postgres HA, cache, secrets, identity, object storage); recent finished work is a secrets-management extraction boundary | Internal platform plumbing |
|
|
|
|
**Indicative Target Multiple classification:** **Product-defining (100x)**
|
|
— `vergabe-teilnahme` is a real, market-facing application serving a
|
|
specific commercial use case (public-tender participation management),
|
|
not merely cost recovery or an incremental internal enhancement; whether
|
|
it in fact represents a *new platform* (1000x) depends on ambitions beyond
|
|
this survey's scope (e.g., whether it becomes a multi-tenant SaaS offering
|
|
vs. a single-deployment tool) — 100x is the defensible default absent
|
|
that broader roadmap information.
|
|
|
|
---
|
|
|
|
## 5. Summary table for T03
|
|
|
|
| Product line | Candidate | Status | Indicative Target Multiple |
|
|
|---|---|---|---|
|
|
| `coulomb-loop` | None | — | — |
|
|
| `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) |
|
|
|
|
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.
|
|
|
|
## 6. Non-goals
|
|
|
|
- Declaring any real Phase — gated behind T05 regardless of what this
|
|
survey finds.
|
|
- Selecting a Target Multiple value with legal or financial finality — the
|
|
classifications above are indicative, per `specs/TargetRevenueFrameworkCore.md`
|
|
§1.4's own framing ("a product and commercial hypothesis, not an
|
|
objectively measurable claim").
|
|
- Re-surveying `coulomb-loop`/`helix-forge` on a schedule — revisit
|
|
opportunistically when either repo's own scope changes, not on a fixed
|
|
cadence this document sets.
|