the-custodian/docs/assessments/2026-09-08-helixforge-factory-critical-path.md
codex dbcf6c8134
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 2s
docs: record successful factory audit delivery continuation
2026-09-11 10:34:18 +02:00

211 lines
14 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Factory critical-path execution — 2026-09-08
Continued on [2026-09-09: issuer pin complete and custody reviews ready](2026-09-09-helixforge-issuer-pin.md).
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, then verified the actual upstream issuer. 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: ensure the now-verified upstream issuer is pinned; 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; G0G5 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. G0G5 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).
## Live issuer observation completed
The user admitted the prepared ten-minute probe. At **2026-09-08 21:44:44 UTC**
it verified an actual signed upstream token with issuer exactly
**`https://auth.coulomb.social`**. Signature, audience, validity window and nonce
checks passed. The pinned container exited 0. This closes the unknown-issuer
observation in KEY-WP-0013-T02 and RPF-WP-0035-T05; the earlier preparation-only
state above is superseded by this live return.
Cleanup removed the dedicated route, Job/Pod, Service and both temporary network
policies. Deletion used the recorded object UIDs; every temporary resource is
absent. Normal KeyCape Deployment/config Secret metadata and image remained
unchanged. The probe retained no token and issued no downstream credential.
It did not prove downstream MFA/application login or activate custody.
KeyCape `41f6916` and Platform `8f40d73` published the owner returns. Project
`89041ec` consumes the live proof and records HFACT-DEC-2026-002 (Hub decision
`1c0d9fd1-4790-4d9a-be6c-0ed4c4890549`). The concrete probe approval is resolved;
its pending human-needed flag is cleared. HFACT-WP-0001-T03 remains wait for
the configuration owner to ensure `authelia.issuer` equals the verified HTTPS
value, named CCR-2026-0017/0018 reviews, and the admitted custody/compatible
KeyCape rollout. Separate client-side/audit/native delivery remains open.
The efficiency gain is one fewer unknown on the activation path and a retained
repeatable check for relevant provider/configuration changes. No renewed token
observation is needed for this unchanged proof context. Autonomous throughput,
spend and the fourteen-day factory observation are still unproved.
Final readback found stale KeyCape T02 and Platform T05 task descriptions despite
applied repository reconciliation receipts. Both were repaired from the published
source and verified. HFACT-WP-0001-T02 retains the underlying source/projection
parity work; these repairs do not establish that automatic synchronization is fixed.
[Live issuer and synchronization receipt](2026-09-08-helixforge-factory/live-upstream-issuer-continuation.json)
records the proof, cleanup, source/Hub parity and progress IDs.
### 2026-09-11 retry: sender credentials provisioned
The user requested another attended login attempt. It succeeded: CCR21/22
created independent version-1 custody and advanced the shared sender registry
with CAS 7→8, preserving existing senders and fields. The seed wrapper exited 0
and confirmed self-revocation for that session. This clears first provisioning
for Approval Engine and Informed Decision.
Platform's delivery helper now pins the reviewed manifests and verifies native
reader/namespace restrictions, exact ESO projection and receiver-registry
equality before reload. Seven delivery tests and 18 custody tests pass,
including 11 actual disposable OpenBao cases. A fresh attended delivery login
then failed before command handoff (exit 5; remote revocation unconfirmed), so
no delivery or reload is claimed. RPF-WP-0035-T08 waits for delivery login and
AUDIT-WP-0009-T09/T11 retain real producer acceptance. Do not repeat the approved
CCRs or reseed their credentials.
Factory attempts and paid calls remain zero. The immediate sequence remains
delivery/receiver proof, native approval and Informed Decision policy/service/
human admission, exact credential delivery and runtime/spend admission, then
the single bounded reuse-surface worker attempt. CCR19's existing operator-group
question remains separate; the customer UI product remains vergabe-teilnahme.
The successful seed and failed delivery attempt are separate metadata receipts
in the platform, Audit Core and factory project evidence directories.
### 2026-09-11 08:27 UTC: native audit delivery completed
The user was available for the renewed attended login. It succeeded; the
reviewed delivery command completed in 28 seconds and Warden exited 0 with
self-revocation confirmed for this session. Both independent version-1 sender
credentials now reach only their intended ESO-owned producer Secrets. Native
reader/path/namespace denials and the coding-agent boundary all passed.
Temporary reader sessions were revoked and the denied namespace was removed.
Audit Core reloaded only after its registry JSON matched authoritative version
8. Receiver c82e0442 remains 1/1 Ready and reports operational/durable storage.
RPF-WP-0035-T08 clears its human login wait and returns to progress for native
producer acceptance. AUDIT-WP-0009-T09/T11 retain accepted/duplicate events,
source/tenant/read refusals, independent readback and audit bearer-revocation
proof. Reader-session revocation is a different control. Both CCRs stay applied
until their full acceptance criteria are proved.
This supersedes the earlier delivery wait; no provisioning or login retry is
needed for the unchanged successful delivery. Attestation/offsite operation
remains AUDIT-WP-0009-T12, and tamper_evidence=false remains the accurate claim.
Factory attempts and paid calls are still zero. The next useful step is actual
producer/receiver acceptance, followed by the existing service/policy/human
admission chain and the bounded reuse-surface factory attempt.