91 lines
6.4 KiB
Markdown
91 lines
6.4 KiB
Markdown
|
---
|
|||
|
|
repo: prj-helixforge-factory
|
|||
|
|
repo_flavor: project
|
|||
|
|
project_status: draft
|
|||
|
|
started: "2026-09-08"
|
|||
|
|
reviewed: "2026-09-08"
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Goal
|
|||
|
|
|
|||
|
|
## Outcome
|
|||
|
|
|
|||
|
|
Establish an internal HelixForge software factory that repeatedly turns bounded
|
|||
|
|
Coulomb demands into validated, reusable capabilities, with agent execution and
|
|||
|
|
at least one resulting software service running on Railiance. Humans retain
|
|||
|
|
capability acceptance and the release decisions required by existing policy.
|
|||
|
|
|
|||
|
|
The first factory serves one explicitly admitted internal tenant. A second
|
|||
|
|
repository demonstrates reuse; it does not introduce a second tenant. The
|
|||
|
|
existing Glas proof's `tenant:platform`, `actor: agt`, `project: glas-local-proof`
|
|||
|
|
remain scoped to that proof. The pilot gets its own reviewed binding where
|
|||
|
|
needed; no identity or authorization transfers merely by copying a profile.
|
|||
|
|
|
|||
|
|
## Invariants
|
|||
|
|
|
|||
|
|
1. Source files and their published revisions own work. Existing owners retain
|
|||
|
|
code, deployment and policy authority. The project links their records.
|
|||
|
|
2. An admitted task states capability intent, scope, tests, allowed repository
|
|||
|
|
effects, actor/tenant, runtime/profile pins, timeout, spend envelope and review
|
|||
|
|
disposition before execution. Repo instructions/prompts cannot expand grants.
|
|||
|
|
3. Repository-changing agents execute inside the demonstrated isolation and
|
|||
|
|
repository transaction boundary. The first pilot permits one active mutator.
|
|||
|
|
4. Source tests, deployed operation and accepted usefulness are separate claims.
|
|||
|
|
A local stub, startup probe or historical profile does not prove the current
|
|||
|
|
production route. The localhost proof is not Railiance admission.
|
|||
|
|
5. Credential custody, policy decisions, approval consumption, audit delivery
|
|||
|
|
and publication use existing admitted owner paths. No secret material goes
|
|||
|
|
into Git, messages or progress evidence.
|
|||
|
|
6. Build/test workers and release authority remain separated by their existing
|
|||
|
|
credential and trust boundaries. An accepted commit grants no implicit push,
|
|||
|
|
package publication or deployment authority.
|
|||
|
|
7. Preserve working coordination and recovery services during migrations.
|
|||
|
|
Source deletion, public exposure changes and broader tenant admission retain
|
|||
|
|
their existing independent gates.
|
|||
|
|
8. No new permanent service or generic framework is established in this project
|
|||
|
|
or in the retiring State Hub. Product implementations remain with owners.
|
|||
|
|
|
|||
|
|
## Success gates
|
|||
|
|
|
|||
|
|
Targets below are proposed for T01 acceptance; they are not measured baselines
|
|||
|
|
or spending approval. Any revision must be decided before its observation window.
|
|||
|
|
|
|||
|
|
| Gate | Required evidence |
|
|||
|
|
| --- | --- |
|
|||
|
|
| G0 — A bounded operating contract | Named capability acceptance owner, operational owner, internal tenant, pilot service, two participating repos, exact grants, budget, allowed release lane, test oracle and source-backed owner dependencies. All pilot dependencies have an owner, return evidence and next review/action. |
|
|||
|
|
| G1 — Real governed model execution | Current GLAS-WP-0012 candidate produces its real artifact with protected owner credentials, correct attribution, declared egress, denial and teardown proof. Only the demonstrated profile becomes ready. |
|
|||
|
|
| G2 — Railiance execution | Admitted installed runtime and worker on railiance01 execute through Activity Core with a current versioned profile and repository grant. Natural claim/heartbeat/close, accepted changed paths, clean source baseline, durable evidence/replay and controlled lease-loss refusal are demonstrated. |
|
|||
|
|
| G3 — Useful delivered capability | One bounded real service/library change has intent and contract, relevant OAS structural/semantic checks, independent tests, accepted review, immutable Forgejo artifact identity, authorized Railiance release, service smoke and rollback proof. A second repo consumes or reuses the capability. Documentation-only or smoke-only output is insufficient for this gate. |
|
|||
|
|
| G4 — Controlled operation | Budget/timeout and grant violations stop work; worker crash, Hub/queue outage, terminal-close replay and sandbox cleanup are exercised without duplicate accepted mutations. Backup and recovery evidence covers the actual worker state, source/artifact path and pilot workload. No stale evidence claim is presented as current. |
|
|||
|
|
| G5 — Repeatability and founder load | Over 14 consecutive calendar days, at least five useful accepted changes across two repos, at least one service release, ≥80% of admitted delivery attempts accepted without operator repair, median human handling ≤30 minutes per accepted change, routine operation ≤30 minutes/day. All attempts, retries, rejects, costs and interventions retained. Report setup and attended security/recovery time separately and in total founder load. |
|
|||
|
|
|
|||
|
|
Suggested initial hard limits for T01: one mutating run; 30 minutes wall clock
|
|||
|
|
per run; EUR 5 equivalent maximum model spend per run; EUR 25 equivalent per
|
|||
|
|
day and EUR 150 total pilot model spend. The admitted provider/runtime must be
|
|||
|
|
able to enforce the selected envelope; token counts alone do not establish a
|
|||
|
|
currency cap. If enforcement is unavailable, adopt and prove an enforceable
|
|||
|
|
conservative limit before admitting paid execution. Infrastructure costs are
|
|||
|
|
measured separately; adding capacity requires an owner decision.
|
|||
|
|
|
|||
|
|
G5 counts one admitted capability-change request as one delivery attempt;
|
|||
|
|
retries consume the same attempt's cost and handling time and must not inflate
|
|||
|
|
the denominator. Cancellation/refusal after admission remains an unsuccessful
|
|||
|
|
attempt with a reason. A human's planned review/release approval is expected;
|
|||
|
|
manual repair, re-prompting to rescue output, or bypassing a failed gate prevents
|
|||
|
|
that attempt from counting as accepted without repair. Five clean trivial runs
|
|||
|
|
cannot stand in for five useful changes with predeclared acceptance criteria.
|
|||
|
|
|
|||
|
|
## Project retirement
|
|||
|
|
|
|||
|
|
Archive only when G0–G5 have accepted evidence, the permanent owners have
|
|||
|
|
accepted operating responsibility, and every actionable residual has a live
|
|||
|
|
owner record outside the closing narrative. Update HelixForge's durable
|
|||
|
|
capability/operating documentation and owning repos' runbooks; retain links to
|
|||
|
|
merged/published revisions, deployment evidence, decisions and residual IDs in
|
|||
|
|
a completion record. Do not archive or shut down any participating service as
|
|||
|
|
part of retiring this coordination repository.
|
|||
|
|
|
|||
|
|
External tenant onboarding, autonomous production release, additional rein/model
|
|||
|
|
families, full HA and commercial-company success are outside these gates.
|
|||
|
|
`UPC-WP-0003` retains its separate ≥30-day company-load objective.
|