From c1298bd47655095984c7daf7c7c5d83e56a4514a Mon Sep 17 00:00:00 2001 From: codex Date: Tue, 8 Sep 2026 14:54:13 +0200 Subject: [PATCH] Publish factory efficiency return and point to canonical project --- ...-09-08-helixforge-factory-followthrough.md | 65 +++- .../prj-helixforge-factory/AGENTS.md | 38 --- docs/proposals/prj-helixforge-factory/GOAL.md | 90 ----- .../prj-helixforge-factory/README.md | 11 +- .../proposals/prj-helixforge-factory/SCOPE.md | 55 --- .../prj-helixforge-factory/dependency-map.md | 44 --- .../history/2026-09-08-genesis.md | 24 -- ...FACT-WP-0001-establish-internal-factory.md | 320 ------------------ 8 files changed, 63 insertions(+), 584 deletions(-) delete mode 100644 docs/proposals/prj-helixforge-factory/AGENTS.md delete mode 100644 docs/proposals/prj-helixforge-factory/GOAL.md delete mode 100644 docs/proposals/prj-helixforge-factory/SCOPE.md delete mode 100644 docs/proposals/prj-helixforge-factory/dependency-map.md delete mode 100644 docs/proposals/prj-helixforge-factory/history/2026-09-08-genesis.md delete mode 100644 docs/proposals/prj-helixforge-factory/workplans/HFACT-WP-0001-establish-internal-factory.md diff --git a/docs/assessments/2026-09-08-helixforge-factory-followthrough.md b/docs/assessments/2026-09-08-helixforge-factory-followthrough.md index 1d131b7..54ddc82 100644 --- a/docs/assessments/2026-09-08-helixforge-factory-followthrough.md +++ b/docs/assessments/2026-09-08-helixforge-factory-followthrough.md @@ -23,20 +23,29 @@ utility; Railiance Fabric’s hosted authority still adds prerequisite work. flags still require source/residual disposition; none was cleared by counting it as completed. [Correction evidence](2026-09-08-helixforge-factory/human-flag-corrections.json). -The dedicated local project is -[/home/worsch/prj-helixforge-factory](/home/worsch/prj-helixforge-factory/README.md). +The dedicated private project is published at +[prj-helixforge-factory](https://forgejo.coulomb.social/coulomb/prj-helixforge-factory), +with [local source](/home/worsch/prj-helixforge-factory/README.md). It contains the accepted source-backed decision HFACT-DEC-2026-001, current workplan, ten exact owner-return records, delivery evidence and an empty measurement ledger. Hub decision receipt: `21159693-04b7-485e-bbab-1ed8f65aab43`. -The original staged packet is frozen pending project publication. +The original staged packet has been replaced with a pointer, preserving its Git +history. State Hub registration returned repository UUID +`99cc4689-9f73-42a2-9cca-d2e235393014` under the helix-forge topic. ## Remaining gates -Project creation needs the routed Forgejo admin API credential, which currently -has no caller OpenBao login. Organization push-to-create is disabled. The same -login can record both already-integrated PRs as manually merged; the PR metadata -still says open, although the tested source is on main. There is no secret-value -request or additional token provision in this handoff. +The routed OpenBao login completed. Both already-integrated PRs now report +closed/merged with the exact reviewed commit. Forgejo initially refused the +disabled manual-merge style; it was enabled only for each metadata operation and +restored to disabled. Current main ancestry was verified before the operations. +Non-secret [publication receipts](https://forgejo.coulomb.social/coulomb/prj-helixforge-factory/src/branch/main/evidence/pr-merge-receipts.json) +are retained in the project. + +The credential proxy reported flex-auth unavailable and its configured +unknown-zone fail-open behavior during this attended publication. HFACT-WP-0001-T03 +retains live policy availability and authorization-negative verification before +governed execution acceptance. Login success is not that enforcement proof. The workplan retains exact native credential/approval/audit receipts through GLAS-WP-0015, protected runtime placement, natural worker claim/heartbeat/close, @@ -48,3 +57,43 @@ has no consistency failures; historical warnings remain. Reuse-surface has three archived null-ID failures (REUSE-WP-0017/0018/0019), separate from the successfully registered new plan. HFACT-WP-0001-T02 retains their disposition; CUST-IN-0017 continues to own the pre-existing Custodian historical consistency issues. + +## Efficiency gains already evidenced + +| Change | Evidence and practical effect | +| --- | --- | +| Reuse before implementation | vergabe-teilnahme consumed the existing hosted registry with 65 capabilities and a dated, hashed snapshot. Source freshness and completeness checks prevent an unavailable registry from silently authorizing new work. No second registry was built. | +| Repeatable release checks | 208 provider tests and 82 customer application tests passed; application tests and migration checks now run before customer image publication. Two actual release defects were found and fixed: missing source templates and missing runner BuildKit support. | +| Less duplicate CI | Application checks run for PR updates and main, without an additional feature-branch push trigger duplicating the PR run. Main release validation remains explicit. | +| Less review-queue noise | Four completed tasks with explicit published `needs_human: false` were corrected in the Hub. The flagged queue fell from 19 to 15 (21%); the two nonterminal flagged tasks were unchanged. A fresh query after login still returned 15: 12 done, 1 cancelled, 1 todo, 1 wait. The other 13 terminal flags need source/residual review. | +| Clearer coordination | One published project owns factory integration; implementation stays in the two product repositories. Ten dependency-return records name the supplying task, source revision, next action and required evidence. Existing GLAS-WP-0015 coordination is reused. | +| Fewer stale open records | REUSE-WP-0022 is finished, customer source/release tasks are done, and both PRs now show merged. Customer deployment remains an explicit waiting task instead of being mixed with completed source work. | + +These are observed improvements in discovery, validation and coordination. +Hours saved, monetary savings and autonomous throughput have not been measured. +The original 94-plan/264-task portfolio baseline is dated; no later fleet-wide +count is implied by these changes. The governed-attempt ledger remains empty and +the fourteen-day acceptance window has not started. + +## Next execution sequence + +1. Prepare and accept the exact G0 tenant/actor/project/profile, repository + grants, operating owners and enforceable time/spend contract. Project + adoption and publication are complete; unattended operating admission is open. +2. Close the existing GLAS-WP-0015 chain: KeyCape service-client custody and + registration, audit sender admission, deployed approval claim/consume and + native Secrets Engine delivery. Obtain current policy allow/deny evidence. + Protected runtime installation can advance alongside that chain. +3. Prove the current Railiance worker's natural claim, immediate heartbeat, + execution and accepted terminal close, including lease-loss refusal and + durable close replay. Retain one integrated delivery item plus two prerequisite + closures as the project's WIP limit. +4. Use that worker for a useful accepted change; admit and deploy the tested + vergabe-teilnahme image through its exact tenant, database, storage, access + and rollback contract (VERGABE-WP-0018-T03). Keep Railiance Fabric in its + existing medium-term placement work until its additional utility is needed. +5. Complete recovery/limit drills, then measure fourteen days: at least five + useful accepted changes across two repositories, at least 80% without + operator repair, median handling at most 30 minutes per accepted change and + routine operation at most 30 minutes per day. Preserve every attempt, + failure, retry, cost and operator intervention. diff --git a/docs/proposals/prj-helixforge-factory/AGENTS.md b/docs/proposals/prj-helixforge-factory/AGENTS.md deleted file mode 100644 index f28f9dc..0000000 --- a/docs/proposals/prj-helixforge-factory/AGENTS.md +++ /dev/null @@ -1,38 +0,0 @@ -# Proposed project agent instructions - -This packet is staged in the Custodian. Until project adoption, changes here -prepare the proposal only; do not register it as an unrelated Custodian workplan -or claim it is an active project. - -After adoption, repo slug is `prj-helixforge-factory`; proposed workplan prefix -`HFACT-WP-` must be checked with the authoritative registrar before first index. - -Orient with `GOAL.md`, `SCOPE.md`, genesis, source workplans and `dependency-map.md`. -Read the generated `.custodian-brief.md` when available. Use State Hub HTTP at -`http://127.0.0.1:8000` locally, `http://10.43.68.154:8000` on railiance01; -use an enabled edge relay only with its explicit configuration. Direct requests -carry `X-StateHub-Component: prj-helixforge-factory` and canonical `/workplans/` -and `/tasks/?workplan_id=...` routes. - -Check this project's unread inbox and mark reviewed messages read. Do not send -messages to other owners without user authorization. Refer to existing -GLAS-WP-0015 threads and receipts to avoid repeated requests. - -Implementation remains in participating repos under their instructions. -Advance only within existing grants and session authorization. Do not infer -permission for secrets, publication, deployment or paid execution from this -proposed programme. Before any credential need, run `warden route find` and -`warden route show`; ops-warden issues SSH certificates, while OpenBao/platform, -KeyCape and the relevant policy/approval owners retain other responsibilities. -Never place secret values in work records or logs. - -Update source task statuses as work progresses. Record significant decisions -as source-backed decision records and the supported Hub decision projection. -At session close log a concise `POST /progress/` event and run -`statehub fix-consistency` after workplan edits. If the CLI/API is unavailable, -retain evidence of the failed sync and request operator recovery; do not claim -queued or failed writes are central success. - -Before finishing or archiving, create live owner records for actionable -residuals, name their IDs in the completion record, and verify synchronization. -No production implementation belongs in this coordination repository. diff --git a/docs/proposals/prj-helixforge-factory/GOAL.md b/docs/proposals/prj-helixforge-factory/GOAL.md deleted file mode 100644 index 98ac3e9..0000000 --- a/docs/proposals/prj-helixforge-factory/GOAL.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -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. diff --git a/docs/proposals/prj-helixforge-factory/README.md b/docs/proposals/prj-helixforge-factory/README.md index 9b2aa08..3f868b4 100644 --- a/docs/proposals/prj-helixforge-factory/README.md +++ b/docs/proposals/prj-helixforge-factory/README.md @@ -4,12 +4,13 @@ The user authorized implementation on 2026-09-08. The dedicated Git project now lives at [/home/worsch/prj-helixforge-factory](/home/worsch/prj-helixforge-factory/README.md). Its [current workplan](/home/worsch/prj-helixforge-factory/workplans/HFACT-WP-0001-establish-internal-factory.md) and [delivery evidence](/home/worsch/prj-helixforge-factory/evidence/2026-09-08-delivery.md) -own ongoing coordination. Forgejo repository creation and central registration -await the routed OpenBao caller login. +own ongoing coordination. The private +[canonical Forgejo project](https://forgejo.coulomb.social/coulomb/prj-helixforge-factory) +is published and registered with State Hub under the helix-forge topic. -The other files in this directory are the **frozen original proposal**, retained -until canonical project publication succeeds. Do not update them as a second -programme. HFACT-WP-0001 in the dedicated project is the current source. +The original proposal files were removed after canonical publication; their +history remains in Git. HFACT-WP-0001 in the dedicated project is the current +source. This directory is only a pointer. Internal capability: **reuse-surface** (REUSE-WP-0022, completed and published). Customer service/UI product: **vergabe-teilnahme** (VERGABE-WP-0018; source and diff --git a/docs/proposals/prj-helixforge-factory/SCOPE.md b/docs/proposals/prj-helixforge-factory/SCOPE.md deleted file mode 100644 index 487fddf..0000000 --- a/docs/proposals/prj-helixforge-factory/SCOPE.md +++ /dev/null @@ -1,55 +0,0 @@ -# Scope - -## Project authority - -This proposed project owns factory success gates, sequencing, integration -acceptance, the dependency map and consolidated evidence. The Custodian -coordinates; `helix-forge` owns the durable product and capability acceptance. -Accountable people/agents and allocated capacity are confirmed in T01, not -assigned to other repositories by writing this proposal. - -## Participating repositories - -| Owner | Responsibility retained | -| --- | --- | -| helix-forge | Human intent, reusable capability contract, architecture fit and value acceptance | -| the-custodian | Governance, source-record conventions, portfolio assessment and project oversight | -| repo-manager / current State Hub projection | Canonical repository/work identity, files, registration and derived coordination views | -| activity-core | Admitted definitions, ops_run queue, worker identity and leases | -| rein-aharness | Claim worker, repository transaction/acceptance, terminal-close delivery | -| glas-harness | Versioned profile selection and real-profile acceptance; existing owner coordination GLAS-WP-0015 | -| sand-boxer | Runtime provisioning, isolated execution, constrained egress, private state and teardown | -| key-cape, flex-auth (access-engine), approval-engine, secrets-engine, audit-core | Identity, decision, approval, native credential delivery and evidence contracts respectively | -| railiance-platform | Admitted credential custody and shared-service dependencies | -| railiance-master and concrete rail/rapp/reef owners | Execution/workload admission, placement, package deployment and recoverability | -| railiance-forge / railiance-enablement | Runner/artifact operations and existing reusable CI/release paths | -| Chosen source and workload repositories | Pilot code, meaningful tests, release, consumer integration and operating evidence | -| kaizen-agentic / coulomb-loop | Existing improvement definitions and demand/feedback context where appropriate | -| prj-unattended-progress-company | Receives relevant factory-load evidence; retains independent company/revenue gates | - -Names above are current checkout identities. This project does not rename -`flex-auth`, replace `coordination-engine`, or create a parallel ownership model. - -## In scope - -- One internal factory lane and its exact prerequisite closures. -- Two-repository capability delivery and reuse, including a Railiance service release. -- Minimal work-record hygiene needed for dispatch and accountability. -- Fresh operating evidence, recovery, cost and founder-load measurement. - -## Out of scope - -- Production code or credential material in this repository. -- Clearing the entire estate backlog as an entry gate. -- Full HA, wholesale hub retirement, broad renaming or global schema redesign. -- External tenant onboarding, community campaign expansion or revenue operations. -- Any implicit authorization from a proposed workplan or from another owner's - historic session authorization. - -## Work-record rule - -The project workplan contains acceptance/handoff tasks and references existing -owner work. It does not duplicate child implementation task lists. A newly -discovered implementation gap receives an owning source-backed task or intake -before it is counted as assigned. Dependencies are current records, not just -messages; an acknowledgement is not a completion receipt. diff --git a/docs/proposals/prj-helixforge-factory/dependency-map.md b/docs/proposals/prj-helixforge-factory/dependency-map.md deleted file mode 100644 index 59c7153..0000000 --- a/docs/proposals/prj-helixforge-factory/dependency-map.md +++ /dev/null @@ -1,44 +0,0 @@ -# Proposed factory dependency map - -Date: 2026-09-08. This is a source proposal for acceptance sequencing. Actual -owner task statuses remain in their repositories and the derived Hub. -Stage/receipt is not inferred from the existence of a message or package. - -| Project gate | Supplying record(s) | Current return / next evidence | Factory effect | -| --- | --- | --- | --- | -| T03 identity admission | KEY-WP-0013-T02; platform custody record to be resolved through the existing Glas request | Two service clients and protected consumer delivery remain unproven. Tenant choice is resolved. Identify the exact admitted custody record; do not substitute a generic database lane. | Blocks approval service acceptance | -| T03 audit admission | AUDIT-WP-0009-T03/T09; APPROVAL-WP-0002-T01 | Evidence kind is implemented; sender scope/secret policy and credential admission need owner returns. T09 is already high priority/progress. | Blocks approval startup | -| T03 approval | APPROVAL-WP-0002-T01/T03/T05 | Published image is pinned. Latest recorded production review found no deployed service. Need identity, audit, rollout, claim/consume and restart/restore receipts. | Blocks native credential action | -| T03 credentials | SECRETS-WP-0009-T03; SECRETS-WP-0007-T04 and SECRETS-WP-0008-T02/T06 as applicable | September 7 decision-path proof resolved digest normalization; remaining external dependency is the approval claim endpoint. Need real scoped activation/delivery evidence. | Blocks paid real-model proof | -| T04 runtime/profile | SAND-WP-0015-T04; GLAS-WP-0012-T02–T06 | Pinned startup candidate and synthetic transport exist. Need protected placement, native credentials, real model, exact binding, teardown and negative evidence. | Blocks current local profile readiness | -| T05 worker | REINAH-WP-0003-T05/T06; ACTIVITY-WP-0032-T05, ACTIVITY-WP-0035-T08, ACTIVITY-WP-0036-T04 | Queue and repository boundaries exist; current source heartbeat correction needs deployed natural trace and controlled late-close evidence. | Blocks governed production lane | -| T05 placement | railiance-master admission contracts; concrete runtime/reef owner record selected in T01 | Existing user-service worker on railiance01 is the starting point. Require explicit ownership and admitted profile/credential/recovery contract for this host. | Blocks claim that the local proof operates on Railiance | -| T06 delivery | Chosen source repo record and consuming repo record selected in T01; existing forge/enablement contracts | No existing end-to-end HelixForge factory acceptance owner was found. Adopt bounded useful-change/release work, with independent tests and actual consumer. | Blocks useful factory result | -| T07 recovery | REINAH-WP-0003-T05; RPF-WP-0038-T04 and actual pilot workload/package owner | Restore demonstrations exist; scheduled caller, inventory/retention and current worker/pilot recovery still need exact coverage. | Bounds operating readiness | -| T08 value/load | HelixForge acceptance; UPC-WP-0003 as receiving context | No current fourteen-day factory delivery/load evidence was established by this assessment. | Blocks repeatability claim | - -GLAS-WP-0015 is the existing owner-handoff coordinator for T03/T04. The factory -project consumes its results and adds the software-delivery/operating acceptance -that it does not own. Do not create parallel identity/audit/runtime coordination. - -When adopting the map, record canonical task IDs, accountable contact, required -receipt, source revision and next review condition in each owner handoff. Set -structured dependency fields/edges only with the supported source/projection -semantics; do not invent an API convention or overwrite source UUIDs. - -Separate lanes retained outside the factory critical path: - -- `NK-WP-0033/0034` and `RPF-WP-0027`: known incident/verification closure. - Resolve impact on the proposed privilege boundary before expansion; ordinary - incident priority is not displaced by factory WIP limits. -- `RMASTER-WP-0020-T08`: retained CoulombCore cleanup, with recovery and explicit - destructive-approval gates. It is not a prerequisite to installing the factory. -- `RMASTER-WP-0020-T09`, `RPF-WP-0025`, `RAPP-OPENBAO-WP-0002`, `NK-WP-0032`: - public listener/private login migration. Preserve existing requirements; do not - merge it into native service delivery unless an owner demonstrates dependency. -- `STATE-WP-0079`, `CORE-WP-0010`, relevant `HUB-*` and `RAPPCOREHUB-*` work: - staged hub migration, with receiver and quiet-window gates. Keep existing - coordination operational while the factory consumes stable contracts. -- `CUST-WP-0038`, ThreePhoenix HA, enterprise federation, broad repository - renames, extra rein/model profiles and publication campaigns: separate benefit - decisions; no blanket factory dependency. diff --git a/docs/proposals/prj-helixforge-factory/history/2026-09-08-genesis.md b/docs/proposals/prj-helixforge-factory/history/2026-09-08-genesis.md deleted file mode 100644 index f7b4f1b..0000000 --- a/docs/proposals/prj-helixforge-factory/history/2026-09-08-genesis.md +++ /dev/null @@ -1,24 +0,0 @@ -# Genesis — 2026-09-08 - -The operator asked the Custodian to assess the Coulomb, HelixForge and Railiance -ecosystem, especially blocked/open workplan load, and provide a plan for an -agentic software factory. - -The pre-proposal Hub snapshot contained 98 open workplan rows. Four explicitly -retired identities reduced the canonical baseline to 94 plans, 27 blocked, -containing 264 open tasks. All 94 matched local source workplan status. The -direct execution cohort contained nine plans and fifteen open tasks; much of -the remaining dependency load concerned identity/custody/audit and Railiance. - -The proposal consumes existing GLAS-WP-0015 coordination and implementation -work. Its distinct deliverable is a useful, repeatable capability delivery loop -on Railiance with operating evidence and measurable human load. This avoids -mistaking either source-complete components or the HelixForge publication -programme for a functioning software factory. - -Source assessment: -`the-custodian/docs/assessments/2026-09-08-helixforge-factory.md`. -Captured baseline and provenance live beside that report. This packet remains a -draft in the Custodian until HFACT-WP-0001-T01 establishes its dedicated project -source and verifies the prefix with the registrar. No factory work was activated -and no owner was contacted by this assessment. diff --git a/docs/proposals/prj-helixforge-factory/workplans/HFACT-WP-0001-establish-internal-factory.md b/docs/proposals/prj-helixforge-factory/workplans/HFACT-WP-0001-establish-internal-factory.md deleted file mode 100644 index 941bb8f..0000000 --- a/docs/proposals/prj-helixforge-factory/workplans/HFACT-WP-0001-establish-internal-factory.md +++ /dev/null @@ -1,320 +0,0 @@ ---- -id: HFACT-WP-0001 -type: workplan -title: "Establish the internal HelixForge software factory on Railiance" -domain: infotech -repo: prj-helixforge-factory -status: proposed -owner: the-custodian -topic_slug: infotech -created: "2026-09-08" -updated: "2026-09-08" -related: - - GLAS-WP-0012 - - GLAS-WP-0015 - - SAND-WP-0015 - - REINAH-WP-0003 - - ACTIVITY-WP-0032 - - ACTIVITY-WP-0035 - - ACTIVITY-WP-0036 - - KEY-WP-0013 - - APPROVAL-WP-0002 - - SECRETS-WP-0009 - - AUDIT-WP-0009 - - RPF-WP-0038 - - UPC-WP-0003 ---- - -# Establish the internal factory - -**Proposal only.** Prepared in the Custodian on 2026-09-08; not yet a registered -project or an execution authorization. Prefix allocation and adoption are T01. -The assessment is complete; the eight tasks below are future factory work. - -The [goal](../GOAL.md) defines success. The [dependency map](../dependency-map.md) -identifies existing work to consume. This workplan owns integration acceptance -and handoff; it neither replaces nor copies child implementation plans. - -Recommended sequence: - -```text -T01 → T02 -T01 → T03 ─┐ -T01 → T04 ─┴→ T05 → T06 → T08 -T01 → T07 ───────────────→ T08 -``` - -T04 runtime preparation can advance before T03 finishes; real model acceptance -cannot. T07 recovery preparation can advance early; its live proof depends on -the deployed T05/T06 configuration. T02 is complete before regular scheduling. - -## T01 — Adopt the project and select the first valuable capability - -```task -id: HFACT-WP-0001-T01 -status: todo -priority: high -assignee: the-custodian -``` - -Coordinator: the-custodian. Acceptance: the HelixForge product owner and the -operator responsible for Railiance. Estimated effort: 1–2 engineering days. - -Review this packet against current published owner revisions, confirm a unique -prefix, establish the dedicated project repo under ADR-005, publish/register it -through the authorized path, and sync its source records. Retain a pointer from -the Custodian rather than two editable copies of the programme. - -Select a **small, useful software service or library capability** with a -repeatable independent test, a known release path and a second consuming repo. -Prefer an existing internal workload and existing CI. Avoid beginning with -identity, credential or production-control code as the agent's pilot target. -HelixForge owns the demand/contract; the actual source and consumer owners -accept the bounded implementation records. Record why this capability matters -and the expected reuse before selecting a convenient task from the queue. - -Confirm one internal tenant, exact actor/project/repository/profile tuple, -human acceptance and operating owners, allowed branch/push/release effects, -the proposed G0–G5 targets, capacity allocation and an enforceable spend/time -envelope. Assess the outstanding NK-WP-0033/0034 verification incident against -the proposed privilege path; require applicable closure or an explicit scoped -owner disposition before expanding it. - -Done when G0 is accepted in a source-backed decision, the project and concrete -pilot work are registered, and a future operator can determine who may run, -review and release it without reconstructing this assessment. Recording a -proposal does not grant execution or spending rights. - -## T02 — Make the selected backlog actionable - -```task -id: HFACT-WP-0001-T02 -status: wait -priority: high -assignee: the-custodian -depends_on: [HFACT-WP-0001-T01] -blocking_reason: "Await project adoption and selection of the pilot dependency chain in T01." -``` - -Dependency: T01. Coordinator: the-custodian with source/projection owners. -Estimated effort: 1 engineering day, plus genuinely necessary projection fixes. - -Use the 94-plan/264-task baseline as the dated starting point. Review the four -retired open identities, seventeen terminal human flags, terminal-parent tasks -and the unmatched local KG-WP-0005 through their existing owning paths. Do not -bulk-delete history or set statuses to improve a dashboard total. -Existing CUST-IN-0017 owns the thirteen Custodian historical consistency -failures and prefix conflict; reuse it rather than duplicate its triage. - -For the pilot chain, ensure every waiting task has a supplying task/record, -accountable contact, precise return evidence, actual next action and review -condition; set human-needed only for real human dependencies. Capture published -source revision and freshness. Check projections without making the retiring -State Hub a new permanent owner. Refer off-path cleanup to existing owners; -it does not hold up the factory after its own records are trustworthy. - -Adopt a factory WIP limit of one integrated delivery item plus two prerequisite -closures, with a named incident exception. Any wider portfolio reprioritization -remains a recommendation until owners accept it. - -Done when the selected chain has complete actionable dependencies, a short -prepared human queue and a repeatable next-pick view; retired/terminal evidence -is excluded from current demand without losing residual ownership. - -## T03 — Accept the existing identity, audit, approval and credential chain - -```task -id: HFACT-WP-0001-T03 -status: wait -priority: high -assignee: the-custodian -depends_on: [HFACT-WP-0001-T01] -blocking_reason: "Await T01 adoption; live returns are owed by KEY-WP-0013-T02, AUDIT-WP-0009-T09, APPROVAL-WP-0002 and SECRETS-WP-0009-T03." -``` - -Dependency: T01. Existing coordinator: GLAS-WP-0015. Supplying owners: -KEY-WP-0013-T02, AUDIT-WP-0009-T09, APPROVAL-WP-0002-T01/T03/T05, -SECRETS-WP-0009-T03 and exact linked custody/authorization records. -Rough shared effort with T04: 4–8 engineering days plus owner waiting. - -Consume the existing seven-owner handoff packet. Identify the exact custody -record for both service clients and the audit sender; first-provision authority -cannot depend on the unprovisioned service. Keep the accepted tenant spelling -and proved policy/digest behavior pinned. Distinguish service-only admission -from a human callback requirement with owner evidence, not assumption. - -Accept the real identity/custody, audit admission, deployed approval claim and -consume, and native credential delivery receipts from the owners. Evidence must -include successful binding and relevant wrong-tenant/scope, denied/reused action -and out-of-scope read rejection, plus revocation/expiry and non-secret audit -references. An image digest or a delivered message alone closes no live gate. - -Done when native credential delivery for the exact proof tuple is verified -through the current owner contracts, with no bypass and no outstanding startup -prerequisite. Record later audit freshness/detection obligations separately; -admission success is not a completeness or tamper-evidence claim. - -## T04 — Accept the real profile and prepare its Railiance placement - -```task -id: HFACT-WP-0001-T04 -status: wait -priority: high -assignee: the-custodian -depends_on: [HFACT-WP-0001-T01] -blocking_reason: "Await T01 adoption for preparation; the real-model portion also requires T03 native credential acceptance." -``` - -Dependency: T01; real model execution also requires T03. Supplying owners: -SAND-WP-0015-T04, GLAS-WP-0012-T02–T06 and concrete Railiance admission owners. - -Accept protected installation of the already pinned runtime candidate and its -owner configuration. Reuse the existing real-rein acceptance contract: exact -profile/actor/project, provider path, model-created artifact, declared effects, -denial, cleanup and rollback to the retained blocked selection on failure. -Review changed pins as a new compatibility set. Do not re-prove resolved -candidate startup unless the artifact, environment or contract changed. - -Then define the production-specific railiance01 placement, runtime owner, -profile/grant, credential path, service restart behavior and recovery inventory. -Start from the evidenced host user-service worker. Satisfy the owning -Railiance rail/rapp/reef admission contract; if the current host service needs -an ownership/admission record, create it in that owner rather than assuming -Kubernetes packaging is the production process. A localhost-only profile needs -explicit target-specific acceptance. - -Done when G1 passes, the local result has acknowledged owner receipts, and the -Railiance configuration is concrete and admissible for T05. G2 is not closed -by this task's local proof. - -## T05 — Close the current worker and queue loop on Railiance - -```task -id: HFACT-WP-0001-T05 -status: wait -priority: high -assignee: the-custodian -depends_on: [HFACT-WP-0001-T02, HFACT-WP-0001-T03, HFACT-WP-0001-T04] -blocking_reason: "Await actionable admission records, owner credential chain and accepted profile/placement from T02-T04." -``` - -Dependencies: T02–T04. Supplying work: REINAH-WP-0003-T05/T06, -ACTIVITY-WP-0032-T05, ACTIVITY-WP-0035-T08, ACTIVITY-WP-0036-T04. -Estimated effort: 2–3 engineering days excluding upstream changes. - -Join the admitted task to the existing ActivityDefinition / ops_run intake and -current versioned profile/repository-grant contract. If a small intake adapter -is missing, record it in the proper owner and implement only that bounded gap; -the retired workplan launch endpoint is not a shortcut. Keep the definition -disabled until the owner's live readiness gates are accepted. - -Accept the deployed pin and a natural claim → immediate heartbeat → execution -→ accepted terminal close trace. Require a controlled late-close/lease-loss -negative case, correct changed paths and commit ancestry, external metrics, -clean source state and sandbox teardown. Exercise the current durable close -outbox without duplicate mutation. A healthy API poll is not an executed task. - -Done when G2 passes under the exact Railiance artifact/configuration and the -Activity Core, rein and Glas owners accept the same run evidence. Return it to -their existing tasks rather than leaving source-complete/live-wait tails open. - -## T06 — Deliver and reuse a useful capability through the existing release path - -```task -id: HFACT-WP-0001-T06 -status: wait -priority: high -assignee: the-custodian -depends_on: [HFACT-WP-0001-T05] -blocking_reason: "Await the current governed Railiance worker proof in T05." -``` - -Dependency: T05; capability and owning implementation records selected in T01. -Acceptance: HelixForge product owner, source/consumer maintainers and workload -operator. Estimated effort: 3–5 engineering days. - -Drive the selected human demand through capability intent, contract and relevant -OAS structural/semantic validation. The bounded agent change must satisfy an -independent predeclared test oracle and normal maintainer review. Record reuse -search and why an existing capability is extended or a new one is justified. - -Use the source repo's current Forgejo workflow, or adopt the existing -railiance-enablement template where needed. Join source commit, CI evidence, -artifact digest/package version and release configuration revision. Apply only -the separately authorized release through the actual workload owner. Validate -the service behavior on Railiance and exercise the agreed rollback. Have the -second repo consume/reuse the capability and retain its acceptance evidence. - -Done when G3 passes and the evidence chain links demand → contract → task/run -→ accepted change → CI → immutable artifact → authorized release → operational -result → reuse. Update the durable HelixForge capability/operating entry. A -generated document, empty commit or deterministic smoke alone is insufficient. - -## T07 — Establish recoverable, measurable operation - -```task -id: HFACT-WP-0001-T07 -status: wait -priority: high -assignee: the-custodian -depends_on: [HFACT-WP-0001-T01] -blocking_reason: "Await T01 adoption for design; final live recovery proof requires the deployed T05/T06 configuration." -``` - -Dependency: T01 for design; T05/T06 for final deployed proof. Supplying owners: -REINAH-WP-0003-T05, the selected workload/package/reef owner and applicable -RPF-WP-0038-T04 recovery/custody coverage. Estimated effort: 2–3 engineering days. - -Consolidate existing receipts for timeout/spend enforcement, worker death, -lease conflict, pending terminal-close replay, credential failure and sandbox -cleanup. Use disposable work and the current deployed configuration. Include -proof that a queue/Hub outage cannot produce duplicate accepted changes and -that restarting restores the right pending evidence. Bind backups and recovery -inventory to the actual host service, forge/artifacts and pilot workload. - -Record per attempt queue wait, execution time, accepted/rejected result, -retries, failure class, human handling, model cost, relevant infrastructure cost -and release result. Include refused/admitted failures in denominators. Use -existing evidence and cost owners; start with a small generated scorecard if -automated aggregation is absent. Monitoring must distinguish a stale receipt -from a healthy current worker and alert the responsible operator through an -already authorized channel. - -Done when G4 passes, rollback/recovery is executable by the named owner, costs -are bounded, and the measurement process can sustain G5 without reconstructing -individual agent sessions. Required audit claims are either freshly proved or -accurately degraded; unresolved detection work retains live owner records. - -## T08 — Accept repeated delivery, transfer ownership and retire the project - -```task -id: HFACT-WP-0001-T08 -status: wait -priority: high -assignee: the-custodian -depends_on: [HFACT-WP-0001-T06, HFACT-WP-0001-T07] -blocking_reason: "Await useful delivery and operational controls from T06/T07, then the complete fourteen-day observation window." -``` - -Dependencies: T06 and T07. Reviewers: HelixForge acceptance owner, Railiance -operating owner and the-custodian. Effort: 1–2 engineering days for review and -handoff plus fourteen calendar days of observation. - -Run the accepted fourteen-day G5 window. Admit at least five useful changes -across two repositories and preserve all attempts, costs, failure/repair events -and human time. If a target is missed, classify the limiting defect, create or -update its owner work record, and repeat the affected acceptance window after -correction. Do not redefine the metrics retrospectively to mark the project done. - -Publish the operating runbook and capability/contract references in permanent -homes, including correction of HelixForge's stale Inter-Hub/nested State Hub -orientation where relevant. Hand the measured factory evidence to the company -project's UPC-WP-0003 acceptance context without claiming its longer window or -commercial goals complete. Additional tenants, model families, HA or unattended -release receive new benefit/authority decisions, not automatic activation. - -Done when G0–G5 are accepted, durable owners acknowledge handoff, all actionable -residuals are live records, and the completion record lists owning repos, -merged/published revisions, deployment/rollback evidence and residual IDs. -Only then finish this workplan, synchronize it and archive the project as -read-only provenance. Participant services continue under their owners.