# Factory implementation return — 2026-09-08

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.

## 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 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,
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.