the-custodian/docs/assessments/2026-09-08-helixforge-factory-followthrough.md

# Factory implementation return — 2026-09-08

Later execution: [critical-path corrections and next admission](2026-09-08-helixforge-factory-critical-path.md)
records the installed policy fix, pinned KeyCape rollout candidate, resolved
audit scope inputs and thirteen updated owner-return records.

The user authorized following through and selected vergabe-teilnahme as the
primary customer service/UI product. The Custodian selected reuse-surface for
the first internal capability: its existing hosted registry offers immediate
utility; Railiance Fabric’s hosted authority still adds prerequisite work.

## Delivered

- **REUSE-WP-0022:** explicit hosted plan-check, bounded/fresh/unwarned source
  acceptance, no failure-to-NEW/local fallback, and snapshot provenance. All
  208 tests and live Forgejo CI passed. Integrated on main at `998a5ef`, with
  image `main-998a5ef` published. [Change](https://forgejo.coulomb.social/coulomb/reuse-surface/pulls/1).
- **VERGABE-WP-0018-T01/T02:** product identity, hosted reuse consumer, container
  application gate before publication, missing-template build fix and pinned
  BuildKit setup for the actual Railiance runner. All 82 tests passed on SQLite,
  disposable PostgreSQL and in the container; live CI and image publication
  passed. Integrated at `fa9f082`; image `main-fa9f082` published.
  [Change](https://forgejo.coulomb.social/coulomb/vergabe-teilnahme/pulls/1).
- **Portfolio hygiene:** four obsolete human-needed flags now match explicit
  published `needs_human: false` in the completed Forgejo migration source.
  Task statuses and historical notes were preserved. Thirteen other terminal
  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 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 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.
Final [publication verification](2026-09-08-helixforge-factory/publication-final.json)
confirmed all eight task statuses, assignees and waiting reasons, the correct
workplan topic, and published main revisions with clean source repositories.
Project consistency returned zero failures and one advisory about the allowed
`automation` classification tag. Progress receipt:
`89b2a709-5f91-4d66-8c8b-40c13b1c6dc2`.

## Remaining gates

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 unknown-zone fail-open
during publication. Subsequent critical-path execution reproduced an explicit
HTTP 403 from the reachable PDP, fixed that misclassification and verified the
installed CLI now refuses before credential transport. WARDEN-WP-0039-T03 and
HFACT-WP-0001-T03 retain the exact delegated policy binding and live admission.

The workplan retains exact native credential/approval/audit receipts through
GLAS-WP-0015, protected runtime placement, natural worker claim/heartbeat/close,
customer deployment/data/access/recovery acceptance and the 14-day observation
window. Today’s attended source delivery does not substitute for those proofs.

Both child workplans were registered and synchronized. The customer repository
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.