Assess factory backlog and record first implemented delivery

docs/proposals/prj-helixforge-factory/workplans/HFACT-WP-0001-establish-internal-factory.md

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