Assess factory backlog and record first implemented delivery

docs/proposals/prj-helixforge-factory/GOAL.md

@@ -0,0 +1,90 @@
+---
+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.