Publish factory efficiency return and point to canonical project

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
+The dedicated private project is published at
-[/home/worsch/prj-helixforge-factory](/home/worsch/prj-helixforge-factory/README.md).
+[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
+The routed OpenBao login completed. Both already-integrated PRs now report
-has no caller OpenBao login. Organization push-to-create is disabled. The same
+closed/merged with the exact reviewed commit. Forgejo initially refused the
-login can record both already-integrated PRs as manually merged; the PR metadata
+disabled manual-merge style; it was enabled only for each metadata operation and
-still says open, although the tested source is on main. There is no secret-value
+restored to disabled. Current main ancestry was verified before the operations.
-request or additional token provision in this handoff.
+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.

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

@@ -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.

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

@@ -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.

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
+own ongoing coordination. The private
-await the routed OpenBao caller login.
+[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
+The original proposal files were removed after canonical publication; their
-until canonical project publication succeeds. Do not update them as a second
+history remains in Git. HFACT-WP-0001 in the dedicated project is the current
-programme. HFACT-WP-0001 in the dedicated project is the current source.
+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

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

@@ -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.

docs/proposals/prj-helixforge-factory/dependency-map.md

@@ -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.

docs/proposals/prj-helixforge-factory/history/2026-09-08-genesis.md

@@ -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.

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

@@ -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.