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

# Factory critical-path execution — 2026-09-08

Implemented and published prerequisite corrections in ops-warden, key-cape,
approval-engine and audit-core, followed by local runtime installation and an
attended OpenBao capability preflight. The canonical integration workplan and next
admission sequence remain in
[prj-helixforge-factory](/home/worsch/prj-helixforge-factory/operations/identity-admission.md).

| Delivered | Evidence | Effect |
| --- | --- | --- |
| Warden preserves explicit policy refusal | Code `31d9b66`; 429 tests passed, four integration tests excluded by the normal suite configuration; Ruff passed. Existing SSH probe still HTTP 200/ALLOW. Installed credential request now HTTP 403 / exit 4 before transport. | Replaces misleading “unavailable / fail-open” behavior with the actual caller/owner binding refusal. WARDEN-WP-0039-T03 owns that live admission. |
| Installer refreshes the actual Warden package | `19bb75c`; initial `--force` reused a cached wheel, while `--reinstall-package ops-warden` installed the corrected source. Installed module and behavior checked. | A published fix now reaches the executing CLI. |
| KeyCape requires genuine issuer denial | `dcebd46`; complete Go suite and vet passed. Negative checks reject timeouts, server errors, invalid tokens and unrelated refusals. Image pulled by immutable digest. | Prevents false successful scope/predecessor proofs. KEY-WP-0013-T06 is done. |
| Approval audit scope is exact | Approval `b46b0f2`, Audit `bbe8c15`; 81 receiver and six sender checks passed. Exact `tenant:platform`, source approval-engine, write-only/load-bearing, explicit redact. | Resolves both tenant/redaction input waits and removes the proposed wildcard tenant scope. Credential and live admission remain open. |
| KeyCape rollout is concrete | Pinned candidate plus two credential refs, `/readyz`, and single-instance replacement passed Railiance server dry-run. Rollback restores the compatible config/image pair. | The next attended rollout starts from a reviewed patch, with known configuration and credential prerequisites. No production deployment performed. |

The human approver UI/callback is now its own KEY-WP-0013-T05 task. Its absence
does not block the independent service registrations or approval service startup.
It still blocks evidence requiring a real human approver. Together with the two
audit inputs, three source-input waits are removed from the service-startup
path; no live security gate is marked complete by that separation.

The project now records thirteen source-pinned supplying records, including
RPF-WP-0035-T05 / proposed CCR-2026-0017/0018 and WARDEN-WP-0039-T03.
The two CCRs explicitly cover verifier-side delivery only. Client-side read
lanes and linked approval audit receiver/sender custody remain distinct returns.

The immediate sequence is: verify the actual upstream ID-token issuer; obtain
the named custody reviews and run the contained attended first provision;
deploy and verify KeyCape; admit audit/consumer credentials; prove deployed
approval claim/consume and native model credential delivery. Exact policy
binding and required human-approval evidence remain explicit. Runtime placement
preparation can proceed alongside this chain. The factory's exact operating
grant and enforceable budget still precede paid execution.

All four modified owner repos returned zero consistency failures. The checks
retain historical/advisory warnings where applicable; canonical reconciliation
then projected published source. Five new task assignees were empty despite
source metadata and were corrected through the supported API with readback.
HFACT-WP-0001-T02 retains that projection parity issue.

[Published evidence](/home/worsch/prj-helixforge-factory/evidence/2026-09-08-critical-path.json)
records revisions, validations and the dry-run. These changes reduce ambiguous
handoffs and unreliable checks. Time saved and autonomous throughput are not
measured. No secrets were provisioned, no new policy binding granted and no
paid model run admitted; G0–G5 remain open and the fourteen-day window has not
started.

## Runtime installation and custody authority follow-through

SAND-WP-0015-T06 is done. The existing pinned runtime is installed on
`bnt-lap001` in its owner's mode-0700 content-addressed store. The installer
checks the expected digest before writing, verifies the copied artifact,
rejects unsafe ownership/permissions and changed destinations, and publishes
atomically. Reusing an intact installation is idempotent. It is protected by
the local owner boundary; it is not root-owned or a Railiance installation.

Sand-boxer source `df5e941` passed the complete check: **188 tests and Ruff**.
The installed-path namespace smoke started Claude 2.1.263, rein and the adapter;
proved read-only runtime, private persistent HOME, isolated networking, clean
worktree and teardown. It used no model credentials or provider request.
Sand-boxer published main `3e49a98` and Glas `4499160` carry the receipt. T04 and
GLAS-WP-0012-T02 still own execution configuration, real-model acceptance and
Railiance placement. No repeat of the unchanged candidate build is needed.

RPF-WP-0035-T05 now has a successful first-provision **capability** proof.
Through the native founder-attended `openbao-platform-admin-login` envelope,
the platform diagnostic checked create/update capability on all six exact
policy, Kubernetes-role and KV data paths for CCR-2026-0017/0018. The successful
session self-revoked and removed its helper. Source `a94d06d` preserves the
metadata-only diagnostic and receipt. No secret value was read, custody seeded,
policy/role changed or production workload deployed.

The receipt preserves all attempts: the first direct launcher failed before
the child command and left revocation unconfirmed; the second native-wrapper
session revoked successfully but its query used unsupported multi-path syntax;
the final six single-path queries passed and that session revoked successfully.
The later success does not establish revocation for the first failed attempt.

The project consumes both returns in its thirteen-record dependency view.
Factory T03 and T04 remain waiting for their outstanding acceptance evidence;
installation and authority discovery no longer appear as unresolved inputs.
Source, Forgejo and the primary State Hub are reconciled at published revisions.

This removes two concrete setup uncertainties and makes installation and the
custody preflight reproducible. Throughput, hours saved and autonomous delivery
remain unmeasured. The next sequence is actual upstream signed-token issuer
proof, named CCR reviews, attended custody activation and compatible KeyCape
rollout. Separate client/audit/native credential admission, the exact factory
grant and enforceable spend limits still precede a real model run. G0–G5 and the
fourteen-day observation window remain open.

[Runtime and custody continuation receipt](2026-09-08-helixforge-factory/runtime-custody-continuation.json)
retains source revisions, validations, projection readbacks and progress IDs.


## Executable upstream issuer proof prepared

KEY-WP-0013-T07 closes the missing diagnostic preparation. KeyCape source
`6f33abd` adds a one-shot upstream verifier; source `1b9793f` pins the tested
image and [execution packet](/home/worsch/key-cape/docs/upstream-issuer-proof.md).
The probe verifies a real authorization-code response inside the adapter and
emits only a verified issuer and check metadata. It issues no downstream token.

The complete Go race suite and vet passed. Five packet/receipt tests and seven
real Traefik 3.6.7 route cases passed; ordinary callbacks remain on their normal
backend. Railiance server dry-run accepted the exact five-resource packet. The
immutable container also produced the expected one-second idle-timeout receipt
as UID 65534 with a read-only filesystem and no network.

The temporary Job has a ten-minute deadline and no retry; its route, service
and two network policies must carry the real Job UID for bounded cleanup. It
uses only the existing config YAML, without the signing-key mount or a
Kubernetes API token. That YAML contains credential data, so live execution
requires the deployment owner's admission. KEY-WP-0013-T02 retains that decision,
the actual signed issuer receipt, contained configuration pin and subsequent
custody/rollout reviews. No live issuer result is inferred from preparation.

This replaces an unspecified manual observation with a tested command and
bounded execution packet. The current receipt is
[key-cape/docs/evidence/upstream-issuer-probe.json](/home/worsch/key-cape/docs/evidence/upstream-issuer-probe.json).