15 KiB
| id | type | title | domain | repo | status | owner | topic_slug | created | updated | related | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| HFACT-WP-0001 | workplan | Establish the internal HelixForge software factory on Railiance | infotech | prj-helixforge-factory | proposed | the-custodian | infotech | 2026-09-08 | 2026-09-08 |
|
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 defines success. The dependency map identifies existing work to consume. This workplan owns integration acceptance and handoff; it neither replaces nor copies child implementation plans.
Recommended sequence:
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
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
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
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
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
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
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
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
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.