90 lines
6.4 KiB
Markdown
90 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.
|