codex e2b832b5d4

CI Smoke / host-smoke (push) Successful in 0s

Details

CI Smoke / container-smoke (push) Successful in 1s

Details

feat: journal strict task consumption before native fixture effects

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a140c4-354a-7823-8f0d-8f717397f786

2026-10-16 09:20:33 +02:00

79 KiB

Raw Blame History

type

title

domain

repo

status

flavor

owner

created

updated

state_hub_workstream_id

RPF-WP-0035

workplan

Implement reviewed credential lanes with separate owner gates

financials

railiance-platform

blocked

implementation

codex

2026-09-05

2026-10-13

RPF-WP-0032

RPF-WP-0033

RPF-WP-0034

975db491-5412-5e27-8e34-14a2417bb039

Credential lane implementation

One S3 queue for three designed lanes; each task keeps its own approval, execution and closure boundary. This replaces the implementation tasks in the three completed design workplans, not the designs themselves. No approval is inherited by consolidation. INTENT binding: secure custody, dependable delivery, stable consumer interfaces. Incident custody remains in RPF-WP-0027/0029.

Consolidate completed designs and owner dependencies

id: RPF-WP-0035-T01
status: done
priority: medium
state_hub_task_id: "0f3606bb-e95b-5484-8a57-bcdd6e3916fd"

Completed 2026-09-05. Preserved the three designs under docs/credential-lane-designs/, identified native owner responsibilities and linked each superseded task below. Owners have not been sent new requests and no new external acceptance is claimed. STATE-WP-0085-T09 is already done; the signing dependency belongs to the proposed FLEX-WP-0020-T05 cutover.

id: RPF-WP-0035-T02
status: wait
decision_id: 62aa95e4-3ccc-4867-8806-5e3db005b483
depends_on: [KEY-WP-0039-T02, MASON-WP-0009-T05]
blocking_reason: "Agent work, not a human gate: claim refusals (KEY-WP-0039-T02 probe) and capabilities-self deny, then ops-mason MASON-WP-0009-T05."
priority: high
state_hub_task_id: "e0c82ea9-05a5-537e-8fbf-67534263572e"

2026-10-11: requalified — the remaining waits are other owners' tasks, not a human gate. See the-custodian docs/decisions/2026-10-11-security-unblock-decisions.md.

Supersedes RPF-WP-0032-T02. Design: docs/credential-lane-designs/secrets-engine-service-jwt.md.

Platform owns the exact JWT mount/role/policy, effective-policy negative tests and a metadata-only custody receipt. KeyCape owns issuer/JWKS and service registration (KEY-WP-0009); secrets-engine owns service authentication and authority consumption (SECRETS-WP-0008-T06, SECRETS-WP-0007-T04).

Unblock: live registration and protected client custody, reviewed exact source and attended apply authority. Issuer/JWKS and consumer source claims now agree; see the 2026-09-27 return below. A service login does not grant lane mutation authority. Do not build another identity provider or lifecycle engine here.

Done when: approved exact role succeeds for the intended service, wrong issuer/audience/subject/claims and unrelated secret access fail, bounded TTL and revocation are proven, the consumer explicitly opts into the verified contract, and rollback/cleanup receipts contain no secret material.

2026-10-09 (T03 source): founder ruled the tenant segment stays coulomb (ops-mason b72ff77d). New CCR request type workload-kv-operator-matrix (scripts/operator_matrix_lane.py): exact per-entry capabilities, OIDC role on the existing netkingdom mount only, and exact agent denies on all four data and metadata paths appended to the live agent-high-risk-boundary (live content preserved; partial presence refused). scripts/fluid_telegram_custody_move.py copies the four undocumented infotech entries with CAS 0, verifies all, then metadata-deletes the sources. scripts/kv_duplicate_retire.py retires activity-core/default/llm-connect-provider-secrets only if no live non-admin policy grants it. Founder session (each helper prints nothing; read the receipts):

cd ~/railiance-platform
export BAO_ADDR=http://127.0.0.1:18200 VAULT_ADDR=http://127.0.0.1:18200
W='warden access openbao-platform-admin-login --exec --'
# 1. dry-runs (no value reads, no writes)
$W python3 scripts/fluid_telegram_custody_move.py --dry-run --confirm 'MOVE fluid-telegram hall-of-helix to coulomb' --receipt ~/ft-move-dry.json
$W python3 scripts/kv_duplicate_retire.py --dry-run --confirm 'RETIRE activity-core/default/llm-connect-provider-secrets' --receipt ~/kv-retire-dry.json
# 2. lane: approve, confirm binding, apply
python3 scripts/credential-change.py approve CCR-2026-0039 --reviewer "platform-owner, fluid-telegram-owner, key-cape-owner (founder Bernd Worsch)" --comment "Approve ops-mason plan fluid-telegram-operator-credential-lane (spec 41a0ca27): four-entry matrix at coulomb/fluid-telegram/hall-of-helix, OIDC role on netkingdom, agent denies." \
 && python3 scripts/credential-change.py confirm-binding CCR-2026-0039 --reviewer founder --comment "groups=[fluid-telegram-operators] (LLDAP, member tegwick) and /assurance/level=aal2 match key-cape b2ed890f." \
 && $W python3 scripts/credential-change.py applier-apply CCR-2026-0039 --confirm "DELEGATED APPLY CCR-2026-0039" --actor founder --record-state-hub --quiet
# 3. custody move, then duplicate retirement
$W python3 scripts/fluid_telegram_custody_move.py --confirm 'MOVE fluid-telegram hall-of-helix to coulomb' --receipt ~/ft-move.json
$W python3 scripts/kv_duplicate_retire.py --confirm 'RETIRE activity-core/default/llm-connect-provider-secrets' --receipt ~/kv-retire.json

2026-10-09 (T03 founder session): CCR-2026-0039 applied at 10:30Z; readback matched for the 8 boundary denies, policy and role. Custody move moved: all four entries copied at coulomb v1 (operator-session from infotech v4) and the infotech entries metadata-deleted. Duplicate activity-core/default/llm-connect-provider-secrets retired; its first dry-run refused on mount-wide platform/metadata/* survey grants, after which the check was narrowed to data-path grants (64ae594). Receipts: docs/evidence/2026-10-09-fluid-telegram-t03-founder-session.json.

2026-10-03: the historical D1 routing was withdrawn because provision/delivery already completed. Owner routing now uses decision ab85ae8a-12a0-4945-ae64-1d3d86d5b26f, specifically independent archive readback and coordinated interim audit bearer revocation acceptance. needs_human and the wait remain; resolving a decision requires owner receipt re-check, not automatic completion.

2026-10-03 (CUST-WP-0075): gate check. SECRETS-WP-0007-T04 is done (2026-09-27), so the gate named in the design is open. It is not the last one: the design says to confirm the exact live client registration and protected client-side custody before writing, and positive-login proof needs a real KeyCape service JWT. KeyCape's contract (openbao-service-auth-contract.md) and KEY-WP-0009 claim source registration only; the live registration of secrets-engine-openbao and its client-credential custody are "a separate approved custody action" that no workplan task owns yet (SECRETS-WP-0008-T06 waits on this task). Re-qualified with blocked_on: message-from:key-cape; key-cape was asked for the owning task id, which will replace it as depends_on. The design stays proposed and no child command was written. Not approvable in D1 yet.

2026-10-04: Founder authorized the prepared coordination request. Sent b4fc62ea-f92c-4410-919a-9f3cce2d406b to key-cape on preparation thread f84637fa-2355-4971-a2dc-7f1fd01710a8, referencing platform source 6b91d510395215d178d60ee8884e7fc00930a0cf. Requested actual registration and protected-custody owning tasks/status/revisions and non-secret receipts. Source registration is not live custody; no value fetch or live registration was requested. T02 remains waiting on the owner return and separate execution gates.

2026-10-04 blocked-task review: KeyCape returns 58826056/eb20a78c now identify KEY-WP-0037-T02/T03/T04, replacing the unowned-registration wait with real dependencies. Prepared proposed CCR-2026-0033 and exact-path issuer policy/auth, sso-only ESO and evidence checklist from the returned candidate coordinates. No issuer/consumer value, registration or native issuance is supplied by them. secrets-engine must return independent source acceptance of consumer host/path, protected delivery and rotation/revocation ownership; awaiting that source phase does not depend on its full live service-login task. KeyCape's exact-primary sync remains pending its scoped historical identity repair. Requirements and acceptance boundaries: docs/provisioning-windows/2026-10-04-1000/dependency-requirements.md. This workplan was already blocked and remains blocked on its open owner/live gates.

2026-10-06: secrets-engine returned consumer custody source acceptance (message 680136e2, SECRETS-WP-0012, commit a3897c2). CCR-2026-0033 finalized as proposed: KV path corrected to platform/workloads/keycape/secrets-engine-openbao (applier scope), consumer copy coordinates with D1-D4 pending founder choice, rotation/revocation ownership, live order and rollback. Attended custody child scripts/keycape_secrets_engine_openbao_custody.py with fake-only tests (tests/test_keycape_secrets_engine_openbao_custody.py) refuses without an exact founder decision id recorded in the approved CCR. Nothing executed, generated or applied; nothing added to active GitOps. The founder approval it needs is T09.

2026-10-09: KEY-WP-0037 finished 2026-10-07 (registration live, issuance verified 10/10, key-cape e0b5fae); CCR-2026-0033/0034 applied. Source for this lane is now complete as CCR-2026-0038 (proposed, credential-change-requests/CCR-2026-0038-secrets-engine-service-jwt-login.yaml). The delegated applier gained a narrow service-jwt-login request type (scripts/service_jwt_lane.py): auth mount fixed to keycape-services, policy must equal the generated login-self policy, role/config keys allow-listed, TTLs at most 15m, uses 1..16, token_no_default_policy, refusal if the mount exists with another type, and a value-free readback compare after the writes. Policy secrets-engine-login-self now also carries explicit deny on platform/{data,metadata}/workloads/keycape/secrets-engine-openbao so ops-mason invariant (ii) (no capability on the client-secret path) holds even if identity groups were ever attached. Tests: tests/test_service_jwt_lane.py (8) plus the updated contract test; full suite unchanged apart from 5 pre-existing failures unrelated to this lane.

Founder apply (one line; approval, binding confirmation and silent apply):

cd /home/worsch/railiance-platform && python3 scripts/credential-change.py approve CCR-2026-0038 --reviewer "platform-owner, key-cape-owner, secrets-engine-owner (founder Bernd Worsch)" --comment "Approve service-JWT login lane: mount keycape-services, role secrets-engine-openbao, policy secrets-engine-login-self (self endpoints + deny on the client-secret path)." && python3 scripts/credential-change.py confirm-binding CCR-2026-0038 --reviewer founder --comment "Bound claims match KeyCape registration: aud secrets-engine-openbao, sub service:secrets-engine, principal_type service, tenant tenant:platform, roles secrets-engine, scope openbao:login; issuer https://kc.coulomb.social RS256." && warden access openbao-platform-admin-login --exec -- python3 /home/worsch/railiance-platform/scripts/credential-change.py applier-apply CCR-2026-0038 --confirm "DELEGATED APPLY CCR-2026-0038" --actor founder --record-state-hub --quiet

Done after that: login proof with a real KeyCape service JWT (SECRETS-WP-0012-T03 probe-openbao; policies exactly [secrets-engine-login-self], capabilities-self deny on the guarded paths, revoke-self), negative claim checks, then publish the consumer contract file and ops-mason MASON-WP-0009-T05 rechecks invariant (ii).

Implement the platform operator-write CCR contract and Fluid lane

id: RPF-WP-0035-T03
status: wait
decision_id: 62aa95e4-3ccc-4867-8806-5e3db005b483
blocking_reason: "Founder session done 2026-10-09; waits on ops-mason verification (MASON-WP-0005-T05) and the FT-WP-0002 owner salt CAS probe."
priority: high
depends_on: [MASON-WP-0005-T05, FT-WP-0002]
state_hub_task_id: "f47e5bc5-6f3c-54bb-aa35-260ad03892ba"

2026-10-11: requalified — founder part done; remaining waits are owner tasks. See the-custodian docs/decisions/2026-10-11-security-unblock-decisions.md.

Supersedes RPF-WP-0033-T02. Design: docs/credential-lane-designs/fluid-telegram-operator-kv.md.

Platform owns the per-path capability schema/validator, exact OpenBao policy and accepted custody coordinates. MASON-WP-0005 owns construction coordination and engine integration; KeyCape/NetKingdom own OIDC/MFA and group membership; FT-WP-0002 owns client CAS, prefix correction, output containment and Telegram application acceptance. Retain the existing read-only CCR semantics.

Unblock: accept tenant/path and per-entry field/capability matrix; confirm actual group/assurance and callbacks, reviewed construction contract and writer authority. Contract review can proceed without a live credential; the final schema cannot be treated as accepted solely because a draft exists.

Done when: validation rejects broad/unsupported grants, the consumer proves CAS=0 first-write behavior and no value output, approved identities can perform only the exact matrix, negative/expiry/revocation checks pass, custody is seeded through the separate writer, and the verified route has a safe handoff receipt. The unattended adapter remains a separate demand and gets no operator session.

Accept the needed signing lane and deliver it to the owning runtime

id: RPF-WP-0035-T04
status: done
priority: medium
state_hub_task_id: "35a85846-61d5-54ce-8b18-ede45733d53c"

Supersedes RPF-WP-0034-T02. Design: docs/credential-lane-designs/state-hub-preflight-signing.md.

Platform owns signing-key custody, exact read policy/role and scoped delivery acceptance. State Hub owns API chart/env wiring, all-replica rotation fencing and health. FLEX-WP-0020-T05 owns the rename preflight/cutover dependency; STATE-WP-0085-T09's adoption-plan delivery is already complete.

Unblock: State Hub/repo-manager and the consuming migration owner confirm that this transitional State Hub lane is still needed during retirement; record the target runtime, namespace/SA/auth audience and an executable rotation fence, plus approved writer and deployment window. Do not broaden the lane into a general repository-rename authority or provision for a stale demand.

Done when: protected one-time generation, API-only ESO delivery, negative access checks and a non-mutating signed preflight pass; every API replica uses the accepted version; rotation/invalidation and recovery are evidenced. No repository rename is part of S3 lane acceptance. If demand is withdrawn, record the owning decision and cancel this task explicitly rather than provision it.

2026-09-05 continuation: verified the live primary cluster identity and healthy single API replica; the signing ExternalSecret is still absent. Added a writer guard against wrong-cluster kubeconfigs before any OpenBao access. The default workstation kubeconfig's local port-forward listener was unavailable. Activation still needs the contained attended OIDC/MFA login and the acceptance evidence above; source preparation is not live completion. See history/2026-09-05-preflight-signing-activation-readiness.md.

Completed 2026-09-05: user-led attended activation generated version 1 and rotated to version 2 with every API replica stopped. Exact access and negative identity checks passed; ESO delivery and API-only exposure passed; the recovered single API replica accepts new signed preflight and rejects its predecessor by signature, with healthy primary identity and no preflight blockers. State Hub chart commit 49e3182, Helm revision 59. No repository rename executed. Evidence: docs/evidence/RPF-WP-0035-T04-signing-activation-2026-09-05.json; closure: history/2026-09-05-preflight-signing-activation-complete.md.

Admit KeyCape approval-engine client custody and delivery

id: RPF-WP-0035-T05
status: done
needs_human: false
intervention_note: ""
priority: high
state_hub_task_id: "e15d62c9-e5da-5721-a135-87c050f7851c"

Answers KEY-WP-0013-T02 (State Hub message 278a3ebe-b529-49f6-bd1a-e3ebcf318260). Admission: docs/credential-lane-designs/keycape-approval-clients.md; requests CCR-2026-0017 (secrets-engine-approval) and CCR-2026-0018 (approval-engine-operator).

Platform owns the two custody paths, exact-path read policies, Kubernetes auth roles and the KeyCape-side ESO delivery. KeyCape owns the client registrations, issuance, claim set and disablement; approval-engine owns approval semantics and audit of emitted actions.

2026-09-08 admission response: both proposed KV paths confirmed unchanged; field client_secret corrected to CLIENT_SECRET for the uppercase KV convention and CCR validator. Kubernetes delivery references confirmed against the live sso namespace, which already resolves KEYCAPE_RAPP_QONTO_CLIENT_SECRET through the same secretKeyRef{key: client-secret} shape on image main-153258b. Attended authority named as the governed openbao-platform-admin-login lane (founder_required); KeyCape's refusal to treat its generic warden plan database match as authorization was correct. Rollout agreed as one attended session with the KeyCape reading build pinned but undeployed, ordered after the Authelia issuer precondition in message c8b1ad10-dae8-48fb-a0ea-7e2a101c54bf. Policies, ClusterSecretStores and ExternalSecrets are written and validated, none applied.

Unblock: owner approval of both CCRs, a KeyCape image that reads both environment names, the settled Authelia iss pin, and a founder-attended window date. Verifier-side custody only — no client-side read lane is admitted, and no scope beyond the two declared sets.

Done when: both CCRs are approved, the attended window seeds both KV paths with CAS=0, policies/roles/stores/ExternalSecrets apply and sync, the KeyCape build resolves both environment names, KeyCape evidences live JWKS signature and exact claim bindings with excess scopes denied (operator consume, human consume), platform evidences cross-path/wrong-identity/out-of-namespace denial, and every receipt is metadata-only. If either registration is abandoned, KeyCape disables it before the KV version is destroyed.

2026-09-08 actual upstream issuer returned

The admitted KeyCape one-shot probe verified the actual signed upstream issuer as https://auth.coulomb.social at 21:44:44 UTC. Signature, audience, validity window and nonce checks passed and the pinned Job exited 0. All five temporary resources and the Pod were removed; normal KeyCape Deployment and config Secret metadata are unchanged. See docs/evidence/2026-09-08-keycape-upstream-issuer-proof.json.

T05's unknown-issuer input is resolved. The configuration owner still ensures authelia.issuer equals that exact HTTPS value before the custody window. Both CCRs remain proposed and await the named reviews; this probe grants no custody mutation or client-side read. Keep the current authority preflight and this signed-token proof as separate receipts. Live ESO/client/approval and separate audit/client-side custody acceptance remain open.

2026-09-09 configuration and review-queue return: NetKingdom pinned the verified HTTPS issuer, using an atomic UID/resourceVersion test and independent readback. Secret revision 58713343; unrelated configuration and signing key unchanged; no Deployment rollout. Receipt: docs/evidence/2026-09-09-keycape-upstream-issuer-pin.json.

The two existing CCRs remain proposed. They now link to concrete pending review decisions, with platform-operator and key-cape-owner named explicitly. See docs/credential-lane-designs/keycape-approval-clients-review.md. T05 owns this human dependency; HFACT consumes it without a duplicate approval request. Custody/ESO activation, client verification and the separate client-side/audit lanes remain open. Current CLI apply plans refuse the proposed requests.

2026-09-09 admission: the user explicitly approved both CCRs in the named platform-operator and key-cape-owner roles. Both source requests are approved and both linked Hub decisions are resolved. Receipt: docs/evidence/2026-09-09-keycape-approval-admission.json. The completed review intervention is cleared; T05 is progress while the contained first-provision procedure is exercised and the admitted attended rollout is carried through. Verifier-side scope, separate client-side/audit lanes and live acceptance remain as defined in the reviewed requests.

2026-09-09 verifier-side return: both CCRs are verified after recorded user approval, CAS=0 version-1 custody, native read/auth denials and revocation, Valid stores, SecretSynced delivery, compatible KeyCape rollout and live positive/negative service checks. Existing human OpenBao login passed again on the new image. Receipt: docs/evidence/2026-09-09-keycape-verifier-admission.json. Failed attempts restored the compatible configuration/image and detached delivery; final resume reused version 1.

T05 is done against its verifier-only acceptance criteria. Its former "remains progress for client-side reads" statement expanded the task past its reviewed scope; that residual now has the live owner task RPF-WP-0035-T06 below. Neither Warden fetch selector is resolvable through these verifier-only CCRs. Do not re-request the completed two named reviews or reseed these paths. Rotation is a distinct, version-guarded operation.

Dispose of the ungoverned whynot-design npm duplicate

id: RPF-WP-0035-T07
status: wait
decision_id: 1591daa1-6e85-4dfd-aadd-5a9fe1ef47fa
blocking_reason: "Hold kept by D3 until SECRETS-WP-0006-T06 moves publishing off the legacy whynot-design npm path; then rotate and prove a fresh publish."
priority: high
depends_on: [SECRETS-WP-0006-T06]
state_hub_task_id: "0dd7c9a5-65a0-53fc-b6c3-5ad96ee56f7b"

2026-10-11: requalified after founder decision D3 (trust root, build-mode default) resolved — see the-custodian docs/decisions/2026-10-11-security-unblock-decisions.md.

Found by the attended session on 2026-09-10 while settling the npm field question. secret/coulomb/whynot-design/npm/publish exists at version 1, created 2026-07-03T15:00:44Z and never updated — five days after the governed lane at platform/workloads/coulomb/whynot-design/npm-publish was verified (CCR-2026-0001, 2026-06-28). It sits outside that lane's exact-path policy and outside any CCR here. Receipt: docs/evidence/2026-09-10-npm-lane-field-resolution.json.

Only metadata was read. Its field names were not enumerated, its value was not read, and nothing was deleted — a location holding real credential material is disposed of deliberately, not tidied away in the session that found it.

The likely explanation, unconfirmed: secrets-engine reports the lane's field under a lowercase name that is absent from the governed path, and their catalog declares this legacy location. If their proven pilot publish read from here, then a working production lane has been running off an ungoverned duplicate, and the governed lane's acceptance evidence describes a path the consumer does not use. That is worth establishing before anything is removed.

Operator decision, 2026-09-15: destroy the legacy path after confirming the governed lane is the live consumer. Do not wrap secret/coulomb/whynot-design/npm/publish in a CCR. Value remains unread. Platform will ask secrets-engine which path publish actually reads before any attended destroy.

Unblock: admit the governed exact-path AppRole policy and coordinated catalog path/field migration under SECRETS-WP-0006-T06; prove native delivery from the governed lane before the attended legacy destroy. secrets-engine confirmed the legacy source path on 2026-09-21 (message 355424d4-17ab-435e-9e1d-6921775cb4a2). No comparison of values, fingerprints, lengths or shapes is needed or authorized.

Done when: the legacy path's provenance and consumer are established, the governed lane is confirmed as the one in use or the consumer is moved to it as a reviewed lane change, the duplicate is destroyed under the September 15 operator decision and the disposition is recorded. Do not bring the legacy duplicate under a CCR. If the value proves to be live and ungoverned, treat it as an exposure with the same custody rules as RPF-WP-0027: never record the value, fingerprint, length or shape.

2026-10-03: human gate routed to hub decision 1591daa1-6e85-4dfd-aadd-5a9fe1ef47fa (D3: Trust root and secret custody: unseal/recovery holders, break-glass, and the deferred rotation of exposed material) by CUST-WP-0075; resolving that decision raises C-40 here.

Admit the separate approval client-side readers

id: RPF-WP-0035-T06
status: done
decision_id: 62aa95e4-3ccc-4867-8806-5e3db005b483
priority: high
intervention_note: ""
state_hub_task_id: "68bff751-e48b-548b-8fb4-dfb3b16210c2"

2026-10-11: requalified after founder decision D1 (attended window standing rule) resolved — see the-custodian docs/decisions/2026-10-11-security-unblock-decisions.md.

Current return, 2026-09-10: CCR-2026-0020 is cancelled on the requesting Approval Engine owner's explicit withdrawal, source 849c75bb094613ff6ac1a1d4cda56a745520c5a1:docs/keycape-service-registrations.md. No presenter exists and no reader is wanted. The validator now accepts terminal cancellation of an incomplete request only with owner/source/reason evidence, retained declared omissions and a disabled, non-resolvable front door. Apply remains refused. No live identity, policy, role, custody or verifier was changed. Human approval follows existing INFD-WP-0001-T07/T08; future service requesters need a separate narrow registration, not this withdrawn bundle.

Operator binding confirmed, 2026-09-14: The user explicitly selected net-kingdom-admins and authorized applying CCR-2026-0019. Its OIDC role is secrets-engine-approval-client-workload-kv-read, aligned with the platform applier naming rule; policy and exact KV scope are unchanged. The metadata dry run passes with no warnings. Attended apply and exact role/policy readback passed; the enclosing Warden command exited successfully after its self-revocation/cleanup. Receipt: docs/evidence/2026-09-14-ccr0019-operator-binding.json. Scoped delivery proof remains pending; the front door stays non-resolvable. Completed CCR-2026-0017/0018 remain closed and T06 stays wait.

Consumer procedure returned in source, 2026-09-10: secrets-engine@98d72ceb1dbcff2d2a80fb8c3058d76777a0ac93:docs/approval-service-auth.md specifies the requested private 0700 runtime directory, 0600 file outside Git, path-only use, claim/consume lifetime and attended cleanup including hard-stop residual inspection. CCR-2026-0019 retains this source-review comment without changing admission status. Exact group, required-owner review, attended apply and native positive/negative/cleanup evidence remain. No role or credential changed.

Separate retained owner decision: KeyCape's 2026-09-10 return 21427688-725f-4dea-aab4-7c78fd4328d2 identifies the already-live, unpresented CCR-2026-0018 registration. Approval Engine, KeyCape and Platform must explicitly decide retention/expiry or coordinated disablement. Reader cancellation neither disables that live registration nor accepts indefinite retention. Keep this disposition in T06; it is separate from the wanted CCR-2026-0019 factory reader. No unilateral issuer/config/Secret change is authorized by this closeout.

Operator decision, 2026-09-15: coordinated disablement with KeyCape and Approval Engine. Platform will not disable the live registration or verifier delivery unilaterally. T06 stays wait until both owners confirm the joint disablement sequence.

Residual handoff from RPF-WP-0035-T05; consumes the completed verifier custody without extending CCR-2026-0017/0018. Owner: railiance-platform with the named secrets-engine and approval-engine operator consumers.

Prepare separate exact-reader admissions for existing version-1 paths: platform/workloads/secrets-engine/approval-client and platform/workloads/approval-engine/operator-client, field CLIENT_SECRET. Name each actual actor/placement, bounded authentication/reader policy, protected consumer delivery, cleanup/revocation and rollback, then obtain the required owner reviews for those concrete requests. No reseeding, rotation, shared reader, reuse of the sso verifier Secret, or implicit operator consume grant.

2026-09-09 preparation return: both exact-reader admissions are prepared as CCR-2026-0019 (secrets-engine) and CCR-2026-0020 (approval-engine-operator), with their exact-path read policies written and committed. Design: docs/credential-lane-designs/keycape-approval-client-side-readers.md. Both reuse existing version-1 custody; no reseed, rotation, shared reader or verifier Secret reuse. Both are in_flight and unapproved; nothing is applied.

Read-only survey findings that decided the two shapes. Namespace secrets-engine holds only ServiceAccount secrets-engine with no workload, and flex-auth/flex-auth-secrets-engine is that consumer's PDP, not the service; secrets-engine consumes the client secret through an operator-run CLI reading SECRETS_ENGINE_APPROVAL_CLIENT_SECRET_FILE (SECRETS-WP-0009-T03, revision 9eb07fd). So reader 1 is an attended operator-workstation OIDC lane, not an ESO lane. approval-engine has no namespace, workload or Service; its manifest is unapplied, and no owner source names who presents the operator client — approval-engine verifies these tokens and never holds them.

Unblock: reader 1 needs the exact NetKingdom/KeyCape group claim for the authorized operator, plus secrets-engine confirming the file mode and removal step; openbao.auth is declared missing rather than filled with a placeholder that would later read as a confirmed binding. Reader 2 needs its owner to name the presenting actor and placement, or to record that no client-side reader is wanted so the request is cancelled. Naming a reader for the widest approval scope without that decision is the failure this task exists to avoid.

Done when: each reader has a named actor and placement, a completed and reviewed auth binding, admitted delivery, and its owner approvals; positive and negative checks pass, including cross-path, wrong-identity and parent-list denial and operator consume denial; or the request is explicitly cancelled by its owner. Rotation stays a distinct version-guarded operation shared with CCR-2026-0017/0018.

Consumer input supplied 2026-09-09: secrets-engine now implements per-request secrets-engine-approval exchange from a protected temporary client-secret file, with exact approval-engine / tenant:platform / read-or-consume scope, no token file and no fallback. The pinned KeyCape image and actual Approval Engine source passed its disposable component exercise; only the PDP was a sequencing double. See secrets-engine/docs/approval-service-auth.md and the metadata receipt secrets-engine/docs/evidence/2026-09-09-approval-identity-exercise.json.

Routing check: warden route show keycape-secrets-engine-approval-client is unknown; generic openbao-api-key routes ownership only and is not a delegable lane. Do not advertise a working fetch command before this task supplies its own accepted native delivery return. Client-side admission is not ready for a new human decision until exact requests and contained execution/rollback checks are reviewable; the completed verifier reviews must not recur in that queue.

Done when: each retained consumer admission is approved and implemented, or its requesting owner explicitly cancels it (CCR-2026-0020 now satisfies that branch); actual consumer authentication/delivery succeeds; sibling/listing/wrong-reader and scope refusals plus reader expiry/revocation/cleanup are evidenced; version-1 custody and verifier availability remain intact. Return the source and metadata receipts to HFACT-WP-0001-T03, SECRETS-WP-0009-T03 and APPROVAL-WP-0002-T01/T05. Audit receiver/sender custody remains AUDIT-WP-0009-T09 and must not be folded into this client-identity grant.

Admit the two factory audit-sender custody lanes

id: RPF-WP-0035-T08
status: wait
decision_id: "ab85ae8a-12a0-4945-ae64-1d3d86d5b26f"
blocking_reason: "Approved conditionally (ab85ae8a, standing change rule): executes once independent archive readback and the interim bearer revocation receipt exist; owner work with audit-core."
priority: high
assignee: railiance-platform
intervention_note: null
blocked_on: message-from:audit-core
state_hub_task_id: "0ef52c26-2669-5cd1-8149-b1f6fcdda6cb"

2026-10-11: requalified — ab85ae8a resolved under the standing build-mode change rule. See the-custodian docs/decisions/2026-10-11-security-unblock-decisions.md.

2026-10-03 correction (CUST-WP-0075, informed-decision sitting draft 55fb078): the D1 routing was wrong. First provision and delivery already ran on 2026-09-11, with seed and delivery receipts, and the review packet says not to repeat them. The task is not a provisioning-window act. It was taken off decision D1, and its blocking_reason now names what actually remains. railiance-platform should re-qualify it further if the receiver rollout has since happened.

2026-10-03 (CUST-WP-0075): re-qualified. The receiver rollout already happened: Audit Core c82e0442de0f carries evidence_kind and native producer accepted/duplicate and scope/read-refusal checks passed 2026-09-11 10:42 UTC (docs/credential-lane-designs/factory-audit-senders-review.md, factory-native-acceptance.md). Remaining: independent archive readback and audit bearer-revocation acceptance. Still not a provisioning-window act.

Consume AUDIT-WP-0009-T09/T11's exact declarations for approval-engine and informed-decision: tenant:platform, write-only, load-bearing, redact. Source preparation supplies two approved CCRs, independent exact-path policies/ESO projections, and the attended factory_audit_custody.py first-provision helper. Its CAS and request-provenance checks preserve unrelated senders and recover interrupted writes without generating replacements. The user approved all named review roles on 2026-09-11. Native provision/delivery/receiver-ingestion acceptance remains open.

The 2026-09-11 native read-only check found an additional deployment dependency: receiver image c2fe39a is 1/1 Ready but does not support evidence_kind. The synthetic native probe now refuses before any credential read. Current receiver source passes. AUDIT T09/T11 retain compatible release/source-manifest rollout; Approval Engine's missing namespace remains its owner prerequisite.

Review packet. Preparation evidence. Do not fold these senders into CCR-2026-0019 or the cancelled CCR-2026-0020.

Dependency review — 2026-09-06

2026-09-09 tenant question resolved — no change needed

The tenant:coulomb / tenant:platform discrepancy raised against T02 is not a discrepancy. KeyCape confirms decision 5ed3fb35-eca9-413a-82b9-95171ba85bf6 binds the approval chain to the landlord zone and was applied to exactly two registrations, secrets-engine-approval and approval-engine-operator. codex-railiance-platform is not in that chain and correctly stays tenant:coulomb, as do secrets-engine-openbao and the human directory default. KEY-WP-0013-T04 records this and their TestServiceRegistrationTenantsAreExactPerDecision pins every reviewed client's tenant against the real fixture, so a reintroduced alias fails their build.

docs/credential-lane-designs/secrets-engine-service-jwt.md already says tenant:coulomb and is therefore correct as written. Bind the exact role to tenant:coulomb. Do not "correct" it to tenant:platform later; that would break the issued claim.

SECRETS-WP-0008-T02 now records the local PIP claim/validation join implemented and tested. Its remaining gate is the unreachable approval-engine claim endpoint and access-engine Check (SECRETS-WP-0007-T04). Do not carry forward the old local stub as a blocker. T02 still needs the accepted service issuer/JWKS, claims, audience and consumer binding. T03 still needs confirmed operator group/tenant and consumer semantics; T04 is already complete. No new owner acceptance inferred.

2026-09-08 attended capability preflight

HFACT-WP-0001's continued execution verified the existing first-provision front door without provisioning anything. warden plan selected openbao-platform-admin-login / founder_required / one oidc_login. The native scripts/openbao-attended-exec.py supplied the existing WSL browser launcher; a direct attempt had no launcher and failed before handoff. Its first revocation result was unconfirmed and is preserved in the receipt rather than silently reclassified. The two subsequent contained sessions completed self-revocation and helper cleanup.

scripts/keycape-approval-custody-preflight.py --receipt <new-private-file> is a silent, read-only command for that envelope. The installed Bao CLI supports one path per token capabilities call; the final run used six single-path calls. Create/update authority is present on both exact policy paths, both Kubernetes auth-role paths and both KV data paths from CCR-2026-0017/0018. This is authority metadata, not a secret-data read or policy/role/KV mutation. Receipt: docs/evidence/2026-09-08-keycape-approval-custody-preflight.json.

T05 remains wait: both CCRs are still proposed, the actual upstream ID-token issuer precondition remains open, and no verifier-side credential is provisioned. Client-side retrieval and audit-sender custody are still separate owner returns. The capability receipt is not a review approval or service readiness proof.

Sender approval recorded — 2026-09-11

The user replied "good, go on" to the explicit CCR-2026-0021/0022 question naming platform-operator, audit-core-owner and both producer owners. Both exact requests are approved; their existing State Hub decisions are resolved. This clears the review request only. Receiver rollout, namespace readiness, attended custody and positive/negative native evidence remain the execution gates.

Native receiver and attended execution return — 2026-09-11

Audit Core c82e0442de0f is deployed and passes the native synthetic contract. Its existing 32-event chain/head is unchanged. The owner Approval Engine namespace now exists and all four ESO objects pass strict server dry-run. The two exact ingress rules are applied; sender custody/ESO application is not.

Warden selected founder_required/oidc_login and attempted the reviewed silent seed command through the contained wrapper. Login failed before command handoff; no custody receipt was created. Warden could not confirm remote session revocation. Await operator browser/MFA feedback and login/session resolution. Approvals remain valid; T08 waits for the identity act, not review.

The receiver check now selects component=receiver, so retained attestation-job pods cannot falsely block a stable receiver. Eighteen custody tests pass. Native return.

Attended custody retry succeeded — 2026-09-11

The user requested a retry and completed the attended identity act. Both CCRs are applied: independent version-1 custody and registry CAS 7→8 succeeded, preserving other senders/fields. Warden exited 0 with self-revocation confirmed for this session. This does not retrospectively attest the earlier failed login's remote session state. The old login wait is cleared; T08 is progress for ESO delivery, exact native reader/namespace refusals, receiver reload and producer acceptance. No token is reseeded or rotated on continuation. Seed receipt.

The delivery helper and custody receipt are committed at 44314ca and exactly projected on primary/railiance01. Seven delivery tests and 18 custody tests (including 11 actual disposable OpenBao cases) pass. The fresh attended delivery invocation exited 5 before command handoff; no native delivery receipt exists, no ESO application or receiver restart ran. The receiver remains 1/1 Ready on c82e0442de0f. Warden could not confirm revocation for this failed login; that is separate from the successful seed session. T08 now waits for this delivery identity act. Neither CCR review nor first provision reopens.

Delivery return. Use the reviewed delivery command with a new receipt after login feedback. Actual producer ingestion/duplicate/refusal and bearer revocation acceptance remain open under AUDIT-WP-0009-T09/T11.

Native delivery accepted — 2026-09-11 08:27 UTC

The user returned and requested another login attempt. It succeeded and the reviewed delivery command completed in 28 seconds. Both native ESO readers passed exact-path access and explicit sibling/registry/metadata/listing denials, wrong-SA/namespace refusal and the coding-agent deny check. Each 900-second reader session was revoked and lookup refusal verified. Both intended ExternalSecrets are Ready; exact producer value and ESO ownership match. The disallowed namespace produced an explicit store restriction and no Secret; the uniquely owned namespace is now absent.

Registry version 8 matches the delivered receiver JSON. Audit Core reloaded and remains 1/1 Ready on c82e0442de0f; /readyz reports operational/durable with tamper_evidence=false, as bounded by AUDIT-WP-0009-T12. Warden exited 0 and confirmed self-revocation for this successful session. Earlier failed login receipts remain historical and are not retroactively attested.

The login wait is cleared. T08 remains progress and CCR21/22 remain applied for native producer ingestion/duplicate/scope/read-refusal and bearer revocation acceptance under AUDIT T09/T11. No credentials were reseeded or rotated. No producer was deployed and no factory attempt or paid call ran. Native delivery receipt.

Native producer return — 2026-09-11 10:42 UTC

Both actual source adapters used their own ESO-delivered credential inside a bounded native Job. Each synthetic event received 202, retained its durable outbox after an injected lost receipt, and received duplicate 200 after a fresh process reopened the outbox. Each source's reconciliation reported exactly one record for its unique probe class. Wrong source/tenant, seven archive read routes, sibling reconciliation and invalid-bearer requests were refused.

The first Informed Decision probe exposed a private-store startup defect: fsGroup volumes add inherited setgid to a newly created 0700 directory. Informed Decision 1a12223 corrects creation without repairing unsafe existing data. The regression failed before the fix; the available suite now passes 335 tests with 39 optional checks skipped. Native retry verifies the exact corrected helper. Six probe tests and eleven rebuilt-container checks pass, including actual setgid-volume startup, restart/restore and cleanup.

All temporary probe Jobs, Pods, ConfigMaps and NetworkPolicies are verified absent. Receiver c82e0442 remains operational/durable; tamper_evidence=false. Producer verification requires no operator registry read or new OpenBao login. Independent readback is a separate attended command consuming the successful receipt; it must not rerun the producer jobs. Both attended verification-login attempts this session ended before handoff (exit 5; remote revocation unconfirmed), so independent archive readback remains pending.

This proves synthetic outbox delivery/recovery with native sender credentials, not domain-transaction atomicity, deployed producer services or human binding. An invalid bearer is not a revoked formerly valid bearer. AUDIT T09/T11 and RPF T08 remain progress for independent readback and audit bearer-revocation acceptance; CCR21/22 remain applied. Service/policy/human admission and native runtime/spend gates remain separate. Factory attempts and paid calls remain 0.

Native producer receipt.

Independent audit readback — 2026-09-11 13:11 UTC

The existing attended readback command completed with exit 0 while the user was present. Independent read-only identity operator found both retained factory-audit-20260911104152-94aced producer events with exact source and tenant:platform; receiver integrity is intact across 36 events. The wrapper confirmed this session's self-revocation and private-helper cleanup. Prior failed sessions' unconfirmed revocation remains historical unresolved evidence.

This supersedes the earlier readback-login wait. No producer jobs were rerun, no credentials were reseeded and no event was written by the reader. The inherited zero registry-read count belongs to the producer phase; the attended reader did consume registry version 8. CCR21/22 stay applied and owner tasks stay progress pending formerly-valid audit-bearer revocation acceptance. Service/domain-transaction/human and factory runtime/spend admission remain separate; factory attempts and paid model calls remain zero.

Receipt: native readback.

T06 native reader acceptance — 2026-09-14

The scoped Warden login lane secrets-engine-approval-client-login now routes to the applied OIDC reader and the platform's silent preflight. The installed Warden package still carries an older catalog; use the explicit source catalog WARDEN_ROUTING_CATALOG=/home/worsch/ops-warden/registry/routing/catalog.yaml until its next normal installation refresh. This lane authenticates the reader; it is not a raw secret fetch or retained-file delivery interface.

Live effective-policy and capability checks passed: only exact data/metadata read, no sibling secret, parent listing, write or control-plane authority. A second contained session read existing version 1 into an operator-owned 0600 file in a private 0700 runtime tmpfs directory. The native consumer exchanged separate read and consume scopes; Approval Engine verified the read token before returning 404 for a fresh nonexistent approval, and refused the consume-only token's read request with 403. No approval was created, bound or consumed. Both Warden sessions exited 0 after self-revocation/helper cleanup; temporary credential file and directory were removed. Four refusal/path/redirect tests pass. Receipts are in platform docs/evidence/2026-09-14-ccr0019-{reader-preflight,delivery-check}.json.

Remaining: an actual nonmember login refusal, real approval claim/consume, separate narrow requester admission and deployed Informed Decision review with an explicitly admitted human mandate. The reader group alone grants no review mandate. T03 and CCR delivery activation remain open; no OpenRouter key was read.

T03 scoped review deployment — 2026-09-14

The operator explicitly admitted net-kingdom-admins as the human review group for only the T03 apply, verify and read-only key-check records, separately from its credential-reader membership. The review service is live and ready at https://decisions.coulomb.social with verified KeyCape groups, fresh MFA and a dedicated caller-bound Flex Auth policy. Its mandate does not grant consumption.

The new secrets-engine-requester client has subject secrets-engine, tenant tenant:platform, role secrets-engine-requester, and only approval:create. CCR-2026-0024 and CCR-2026-0025 provide distinct verifier and attended reader custody. Native signature, subject, scope and TTL checks passed; excess scopes and a wrong secret were refused. Existing consumer identity is unchanged. Three real requested approvals were created with human control, required count one, and zero entries. Platform evidence is docs/evidence/2026-09-14-t03-native-approval-requests.json.

Review image: sha256:8f55bcecf37a8d65f96e073510b1ffb4636c0a91d75e1ee7d582ad4bce8b953a. Policy image: sha256:c9f028b49dfcede930a9cc48757ec8371ecc71d20b1bfee2733e55298dffcc7c. Review tests: 339 passed, 39 optional integration tests skipped; 11 container checks and HIGH/CRITICAL image scan passed. Policy checks: 57 local and 6 native caller checks passed, using synthetic subjects, not human binding evidence. Approval Engine CPU request was reduced from 25m to 10m after observing 1m use; review requests 20m and its PDP 5m. Limits are unchanged. Native services ready.

Remaining T03 gate: the operator's exact signed-in account is needed to address three prepared immutable memos, followed by real acknowledgements and acceptance in Informed Decision. No human entry or consume has been generated by an agent. Then execute claim -> validated PDP Check -> CAS consume separately for apply, verify and exec using scoped attended authority, and capture native denial, revocation, workload health and key-check evidence. No OpenRouter credential has been read and no inference or spend was performed. T03 remains waiting; this entry supersedes earlier statements that requester or group admission is missing.

2026-09-27 T02/T07 source follow-up

T02 now has the exact proposed RS256 configuration, bounded JWT role and self-only policy in openbao/. Operator correction: platform infrastructure belongs to tenant:platform; KeyCape registration and consumer preflight are corrected together. Existing live registrations must be migrated and verified. Public discovery confirms issuer/JWKS/token endpoint. Registration/custody, attended provisioning and live rejection/cleanup evidence remain required; T02 stays wait. No service credential or backend entitlement was issued.

T07 consumed the confirmed legacy consumer return. The stale value-comparison ask is removed. WARDEN-WP-0037-T03's no-rotation hold stays in force until the governed native migration is evidenced. Legacy destruction follows migration; neither source reconciliation nor the historical pilot is that evidence.

Loose-end review — 2026-09-27

T08 now explicitly waits for formerly-valid audit-bearer revocation acceptance from AUDIT-WP-0009-T09/T11. Native delivery, producer checks and independent readback already passed; do not reopen login, seed or review gates. T02/T03/T06/T07 retain their latest exact service registration, signed-in human acceptance, owner delivery/disposition and governed-consumer migration dependencies. No credential value was read or changed.

Founder approval of the CCR-2026-0033 custody child

id: RPF-WP-0035-T09
status: done
needs_human: false
priority: high
decision_id: 2ab717e1-7881-491e-aed4-28946550c289
depends_on: []
state_hub_task_id: "7c753be6-42f1-58a6-a4a4-a7ed686f461f"

Packets: credential-change-requests/CCR-2026-0033.yaml (custody child, KV metadata, issuer ESO reader, live_order, rollback) and CCR-2026-0034.yaml (attended operator OIDC reader, in-memory, 5m/4 uses). Revised 2026-10-06 per founder direction; the consumer file is removed. Exact founder commands: docs/provisioning-windows/2026-10-04-1000/keycape/founder-runbook.md. Live order: custody child → platform applies policies/roles/ESO (Secret sso/keycape-secrets-engine-openbao-client exists) → NetKingdom env patch (NK-WP-0046) → KeyCape registration merge (KEY-WP-0037-T03) → KeyCape restart immediately → live issuance check (KEY-WP-0037-T04) → OpenBao JWT role/login proof (RPF-WP-0035-T02). Each live step after the custody run needs its own go.

2026-10-11 evidence reconciliation: T09's approval obligation is complete. Authoritative founder decision 2ab717e1-7881-491e-aed4-28946550c289 is resolved, decided by Bernd Worsch at2026-10-06T13:07:18.627943Z, and explicitly covers A1 design, A2 CCR33/CCR34 plus owner reviews/bound claims, and A3 one custody run. The approval comments in both CCRs record those exact grants; both source records are applied. MASON-WP-0009-T02/T03 additionally record the October8 approval/owner-delivery reconciliation and reference KeyCape docs/evidence/2026-10-07-secrets-engine-openbao-issuance.json. Closing this approval task clears its obsolete human gate. It grants no new run, credential access, rotation or service execution: RPF35T02/T12, MASON9T05 and SECRETS8T06 retain their actual native/adoption obligations. Historical per-step exclusions remain above.

Retire the approval-engine-operator client delivery and custody (CCR-2026-0018)

id: RPF-WP-0035-T10
status: wait
priority: medium
blocked_on: message-from:approval-engine
blocking_reason: "Blue lane under the standing change rule (removing access, with reviewed order, rollback and receipts): executes once approval-engine confirms there is no presenter. No founder window needed."
state_hub_task_id: "af2d4dba-f83a-5819-9a8b-671bae799364"

2026-10-11: access removal is blue lane (canon build-mode-change-authorization_v0.1); no founder window.

key-cape proposed a joint disablement on 2026-10-10 (message 7f2128fb). Precondition: approval-engine reconfirms there is no presenter. The order is the reverse of provisioning, so KeyCape never starts with a client whose secret is missing. key-cape removes the registration and restarts (1), checks that invalid_client is returned (2), and net-kingdom removes KEYCAPE_APPROVAL_ENGINE_OPERATOR_CLIENT_SECRET from Deployment sso/keycape (3). Platform steps, amended from the proposal:

Delivery. In one commit, remove ExternalSecret sso/keycape-approval-engine-operator-client from argocd/platform-addons/openbao-secretstore/keycape-approval-clients.externalsecrets.yaml and ClusterSecretStore openbao-keycape-approval-engine-operator from openbao-keycape-approval-clients.clustersecretstore.yaml. Keep the secrets-engine-approval objects. Then bump targetRevision of argocd/railiance01/applications/openbao-secretstore.application.yaml. The app is pinned and has no automated sync, so nothing changes live until an attended argocd app sync openbao-secretstore --prune runs after step 3. Verify, value-free, that the ExternalSecret, the store and Secret sso/keycape-approval-engine-operator-client are gone. The target is creationPolicy: Owner and deletionPolicy: Retain, so the Secret should follow its owner; delete it explicitly if it does not. Then delete OpenBao role auth/kubernetes/role/external-secrets-keycape-approval-engine-operator and policy workload-kv-read-keycape-approval-engine-operator, and remove their source files. Also remove policy workload-kv-read-approval-engine-operator-client (CCR-2026-0020, cancelled) if it exists live.
Custody. Run the metadata delete of platform/workloads/approval-engine/operator-client, the destruction foreseen in docs/credential-lane-designs/keycape-approval-clients.md. A disabled client's secret has no recovery value; a narrowed successor gets a fresh secret through the mint-secret lane at platform/workloads/keycape/<client_id>. Only after step 2's invalid_client receipt. Keep the agent boundary denies for that path until the delete is verified, then drop them.

2026-10-10: key-cape agreed the amended steps 4 and 5 (message 59304e33, KEY-WP-0013 c528daa). Waits on approval-engine confirming there is no presenter, and on the founder's window.

The manifest edits wait for the scheduled window, so a stray targetRevision bump cannot remove KeyCape's secret before step 3.

Complete independent service-JWT source preparation and execution design

id: RPF-WP-0035-T11
status: done
priority: high
state_hub_task_id: "7952c8cd-c066-5b72-a025-78d24341c1ab"

2026-10-11: Platform-scoped agent loaded this checkout's AGENTS.md and INTENT, RPF35-T02, actual CCR38/login contract/typed applier and Secrets Engine's native claim/PDP/CAS/provider/apply flow. Frozen Secrets v2 manifest and all named staged bytes/proof were hash-verified. Independent tests reproduced three source counterexamples while retaining the frozen files: close exception can coexist with native_verified=true; successful result needs no source/session fingerprints; HTTP200 mixed errors+data envelope is accepted. Original 37 tests plus the three counterexample tests pass (40 cases, synthetic/local only). Proposed owner design docs/credential-lane-designs/secrets-engine-task-execution-entitlement.md binds an explicit metadata-only execute-ccr action, immutable typed owner bodies, CAS/journal replay control, 120s/12-use owner-held task token, independent payload validation, native ACL endpoint bounds, revoke/readback and recovery. This completed preparation record is established before the formal source review. It grants no live authority and does not close T02 or represent acceptance by another owner. Formal review artifact follows under this work item; all implementation/live obligations are retained in T12 and existing T02 rather than a finished residual.

Implement and prove the separately approved task execution entitlement

id: RPF-WP-0035-T12
status: progress
priority: high
depends_on: [RPF-WP-0035-T11]
state_hub_task_id: "914bf383-c13f-5247-9af0-91d7e3a4784a"

Review the proposed task-execution-grant schema and exact metadata-only execute-ccr backend with Secrets Engine/access-engine/approval-engine; implement trusted service subject and served consume verification, durable one-shot reservation, bounded owner-held token issuer/middleware and exact source/payload enforcement. Obtain separate exact founder approval/attendance before provisioning or live actions. Prove disposable intended result and identity/action/target/body/time/replay/crash/ cleanup negatives, and return owner-native acceptance. Existing service login policy and defaults stay unchanged. T02 still owns login/claim/TTL/use/MASON acceptance; Secrets T06 separately owns dispatcher adoption and steady-state default migration.

2026-10-11 T11 refinement (same source-review trial): the exact Secrets Engine v3 manifest 6bb05bac74e4939c3e42db2ae95c5f9fb4616bb20cc285811a315c26669ebce1 and all named bytes/proof were verified and independently re-reviewed. The three v2 counterexamples are corrected: close exceptions cannot pass through stale true flags, complete typed source/session/attempted/revoke evidence is required, and mixed HTTP200 errors/data fails closed. 49 maker/current-provider tests plus three independent regressions passed (52, synthetic/local only). Platform source review docs/reviews/2026-10-11-secrets-service-jwt-v3-platform-review.json approves only the corrected boundary verifier and truthful packet. Prior changes-requested v2 review is retained; this is not a second native success or changed authority. No native or founder go is granted. T02, T12 and Secrets T06 remain open; the metadata-only execute-ccr pilot is explicitly insufficient for generic lifecycle adoption. All consume-verification/journal/action/body/backend implementation and native acceptance gates remain real prerequisites, not architecture promises.

2026-10-11 T11 readiness refinement: independently reviewed frozen consumer manifest 709b9dddd1c8f00a995b1ff14264323fbe080ed95df244270ce9607528878fa7. Platform source review docs/reviews/2026-10-11-secrets-execution-readiness-v2-platform-review.json approves the local fail-closed guard and proposed consumer contract direction only. All ten current protected backend handlers pass provider args through readiness before authorization/consume; session revoke checks before handle reads. Configured auto/explicit service-jwt therefore cannot burn a protected-action approval or open the insufficient login-self backend. Explicit env/bootstrap and self-only probes retain their existing contracts; local compromise/reactivate and disabled destroy remain separate. Existing ambient-token route readiness reads are unchanged, not claimed governed by this guard. 58 isolated tests passed: original36 plus20 provider/action cases, handler enumeration and actual session-revoke ordering. Prior v2 changes-requested and v3 boundary source reviews remain unchanged, same T11 trial. No runtime grant, native acceptance, new Access/Approval semantics, backend entitlement or full Lifecycle adoption is approved. T02/T12/SecretsT06 and WP13 implementation/native gates remain open; the metadata pilot substitutes for none of the ordinary generic lifecycle outcomes.

Complete independent KEY39 v4 lifecycle source review preparation

id: RPF-WP-0035-T13
status: done
priority: high
state_hub_task_id: "8f6966fa-6e9a-58b2-8b40-c47340ec19d1"

2026-10-11: Platform agent loaded its owner instructions/INTENT and RPF35-T02, actual applied CCR38, exact native role/policy source and frozen KEY39 lifecycle v4 manifest d079f85c47d5c2635e1ee633ea4d1346b1737ce2be9ca273f22a38e620f418d8. All staged entry hashes were verified without changing the reviewed inputs. Source role omits expiration_leeway: its observed actual default must be confirmed natively, with -1→0 and 0→150 normalization preserved as a bounded model. Source claims and login-only policy are unchanged. The supplied 41 lifecycle tests pass; five independent cases also pass, including a new exceptional-response-close elapsed-bound counterexample and four current-leeway normalization checks. A 10ms HTTP request can take over70ms because exceptional finally response.close runs outside the hard elapsed timer. Unknown native login is correctly recorded, but source total elapsed enforcement is incomplete. This completed owner preparation record exists before the formal exact source review entry. No credential was requested/read, native action run, owner checkout edited or native session grant inherited. T02 retains native role/policy/leeway, negative claims, cleanup acceptance and MASON gates; KEY39 producer handoff and founder attendance remain prerequisites. Source correction/re-review is required, not a native success.

2026-10-11 T13 correction preparation (same trial): exact KEY39 v5 manifest d1f997624db46693a7126a6eb6435f6b3a353d5bd67dcc8a539683e4b7147285 and all entry hashes verified. The v4 exceptional-close finding is addressed: one 20ms abort is clipped to original remaining time and the nonresettable aggregate cleanup budget; zero calls after aggregate expiry; failed abort stays unconfirmed/unknown with signal state restored. 46 supplied lifecycle checks and five independent regressions pass; the unchanged runner's earlier17 tests remain valid against identical source SHA. Existing T13 preparation record is retained before the formal v5 exact source review. V4 changes-requested review and earlier failed history remain retained, with no native success, inherited grant or scope promotion. Actual private producer admission, fresh installed role/leeway/policy observation, authenticated founder window and native refusal/cleanup remain gates.

2026-10-11 T11 journal preparation refinement (source-only): independently inspected frozen root-maker v2 manifest 341cac1de945d2fbe8f516119909bd44fc37e85dccfb38b451981d4de2d402e7, verified all input hashes, and ran14 supplied tests plus5 independent checks. The actual four-process race admits once; a separately forked process exiting immediately after pending intent leaves durable unknown/nonresumable state. Private SQLite modes, lock admission and binding/replay protections remain guarded. Three independent counterexamples show after_call accepts False,0.0 or text'0' as persisted integer ordinal0, contrary to before_call's exact integer validation. Completed preparation under this existing done ownerT11 record precedes formal review; require identical ordinal/call-digest validation before confirmation so malformed calls cannot clear pending outcome. RPF35-T12 retains caller/PDP/consume validation, exact body compiler/adapter and owner-private cleanup/recovery after unknown; this unintegrated primitive proves none of those or full contract/native acceptance. Inputs/prior reviews are preserved; no privileged/native action occurred.

2026-10-11 T11 journal v3 correction preparation (same trial): frozen manifest 905ff6666d05df6a19d165a535579d917d7de31a43e066c2afc34a57e8cbdc9d verified against every file. Strict after_call integer0..63 and64hex string digest validation now precedes SQLite confirmation; False,0.0 or text'0' cannot clear pending external outcome.15 supplied tests plus5 independent regressions pass, including realfork abrupt exit after durable intent and privatefile checks. This existing completed ownerT11 refinement precedes the formal corrected-source review. Prior v2 refusal is retained; no extra success/authority trial is counted. Acceptance is only unintegrated journal source. Actual caller/PDP/consume validation, independently compiled body/ordinal plan, restricted adapter, owner-private unknown cleanup recovery and native/whole-contract adoption remain live RPF35-T12 gates.

2026-10-11 T13 node-route source preparation refinement (same trial): exact successor manifest 23a972abc5175e121e594726d2b7f7a28c62109253f58f12623eaf2e5564a035 verified against all entries. Platform Service openbao-ui-gateway8080 and its nginx /v1 proxy agree with the proposed bounded founder-held node port-forward; workstation tunnel/DNS assumptions are not reused as node evidence.54 supplied lifecycle/route checks plus6 independent public-health/abort checks pass, offline. Initial execute/recovery health pin and repeated pre-create check fail before native/Secret effects; public-preflight reads neither stdin nor Kubernetes. Completed ownT13 preparation precedes this fresh exact source review, not reuse of v5 acknowledgment. Main execute currently reads private stdin before execute's health gate; the packet's pre-token-input phrase is not accepted. Private producer handoff must preserve actual ordering or move the health gate before credential input when implemented. Public cluster digest detects drift, not authenticated estate identity. No route was opened or observed; no source packet authenticates a founder approval. Native role/plugin version and raw/effective expiration, clock-skew and not-before leeways require actual owner observation/semantic proof. Issuer readiness_state/Argo ownership is not established by the inspected source; unmapped means production-tier. If adopted/production-approved, temporary direct CAS requires an explicit reviewed one-use maintenance exception and close-down entry, plus reconciliation, before native go. No helper/source acknowledgment waives that gate. Private token producer/callback/client/custody admission and actual native negative/revoke/restoration/cleanup remain prerequisites.

2026-10-11 T13 v7 node-route preparation refinement (same trial): exact frozen manifest 90aabec336008d7d51e37c04b5ff96ba8ed6630821cca1a4c333d803367247f7 and all entries verified.58 supplied lifecycle/route checks plus9 independent checks pass offline. Actual main now verifies source/public health before private stdin; execute preserves the original wall/monotonic window rather than renewing it. Actual child-process partial-pipe counterexample shows unbounded stdin.read remains blocked beyond a synthetic20ms original window (still alive after100ms without EOF). No credential/native/provider access is involved. Before private producer admission, require byte-capped, deadline-bounded JSON input and EOF within the original window, with fail-closed fixed receipt and no protected effects. This completed ownT13 preparation precedes formal v7 source changes-requested review. Retain v6 qualified health-gate agreement and all prior reviews; neither v7 health ordering nor any source acknowledgment establishes custody completion, actual route/plugin/leeway/readiness/Argo identity or founder/runtime authority. Native and private-producer gates remain open; no owner checkout write occurred.

2026-10-11 T13 v8 bounded-input correction preparation (same trial): exact frozen manifest 316fd6005cc4cb7fe14ea69a5fd408aed13e6122afef60afd13d97952b27cf4a and all entry hashes verified.65 supplied tests plus12 fresh independent checks pass offline, including a standard buffered stdin pipe with complete JSON/noEOF interrupted within original20ms window and restored SIGALRM state; exact64KiB JSON/EOF accepted and extra byte refused, UTF8 token bytecap enforced, original wall deadline clips longer monotonic budget. Original preinput window is retained. Completed ownT13 preparation precedes fresh exact source review; v7 refusal and v6 qualified agreement/prior reviews retained. This accepts child bounded-input source only. No parent-ready handshake exists: producer must not eagerly pipe private inputs, and producer/session/window readiness protocol remains an unimplemented admission gate. No custody/native completion, sourcepacket approval authentication, route/plugin/leeway/readiness/Argo observation or inherited grant. Native prerequisites and producer handoff remain open; no owner checkout changed.

2026-10-11 T11 journal v4 canonical-format preparation refinement (same trial): exact frozen manifest 22c6d225d393b994ab7b44a43904ced1b6d7f74e0e2bebf71ffe99f87191ef4c and entry hashes verified. Actual access-engine pkg/api/canonical.go RequestDigest/ CanonicalDigest, Approval binding.py and Secrets authorization/approval_consume all use sha256:<64 lowercase hex> request digests. V4 now preserves this exact request value without prefix stripping; plan/call/evidence content hashes remain explicit bare64hex.15 supplied checks plus15 fresh independent checks pass, including malformed prefix/bare/uppercase/trailing whitespace refusal before reservation, exact persistent value/reopen/mismatch replay, private-file mode, real child crash after pending intent, ill-typed confirmations and pending-unknown refusal. Completed ownT11 preparation precedes formal v4 source review; prior v2 refusal/v3 approval and T13 v7 refusal/v8 source acknowledgment retained. Acceptance is unintegrated primitive source only; no data migration/native use of v3 journal has occurred. RPF35-T12 caller/PDP/consume validation, independent owner plan compiler/restricted adapter, private runtime custody, bounded execution and owner-private unknown cleanup recovery remain open. No checkout/native writes.

2026-10-11 T13 paired ready-child/launcher preparation refinement (same trial): exact NetV9 manifest 84542ddcff00932fc7ce22dcb2626be8942a3c006c5098a62fdd6b2478d0cd14 and KeyproducerV2 55a8e794af983ca2202e7a0054d0415a120d2c95018fb03fdb5f28313a109d58 verified against all entries.74 Net checks plus31 Key checks and10 independent checks pass offline including a truthful-unknown counterexample: adapter uncertain private delivery with confirmed=false is copied into launcher receipt, but consumer_outcome_unknown incorrectly remains false after local SSH teardown. Complete bytes may have reached remote child before adapter timeout/EOF; local terminate does not establish remote no-effects. Require sticky propagation of uncertain delivery into consumer outcome before early return, retain unknown unless independently established native outcome/recovery. Bad markers/source pins/injection reject before private reads; extra marker authority/lines reject; prohibited child output never forwards. Child-ready synchronization is not authentication/approval. Proposed founder directSSH profile is incompatible with warden quiet-output lane and not admitted here. Completed ownT13 preparation precedes formal paired source review; preserve v7 refusal/v8 acknowledgment and journal histories. No transport grant, coding-agent/private custody admission, live SSH, credential/native action or owner checkout write. All native role/plugin/ leeway/route/issuer readiness/Argo/maintenanceexception gates remain prerequisites.

2026-10-11 T13 paired producerV4 correction preparation (same trial): exact producer manifest d6f641dc1e4aae7d36658d4199d89af14d2fd7a4bd4e526856eb340234f2d33e and unchanged NetV9 84542ddcff00932fc7ce22dcb2626be8942a3c006c5098a62fdd6b2478d0cd14 entry hashes verified.74 Net tests,40 producer checks,9 actual local fakeSSH/ realwrapper/child synthetic roundtrip regressions and12 fresh Platform checks pass (135 total). V2 deliveryunknown now remains sticky consumerunknown with completion=false after earlyreturn/localteardown. V3 Net FIFO acquisition finding and originalbudgetreset are corrected: actualCLI starts original5s timer before regular/nofollow/bytebounded contract acquisition, each later preparation phase clips remaining time. ActualCLI FIFO refuses promptly; expired original budget never validates/spawns/reads private files. Completed ownT13 preparation precedes formal corrected pair source agreement. Preserve V2 Platform refusal, Key old exactV2 acknowledgment and NetV3 refusal; no old acknowledgment repinned. Agreement is only reviewed source synchronization/launcher behavior, not admission. Founder authenticated SSH host/profile/channel/runtime pins, exclusive sameUID file custody and explicit tmpfs file allowance/cleanup, verified human and coding-agent producer/client/source, native role/plugin/leeway/route/issuer readiness/Argo/maintenanceexception, refusal/revoke/restoration/readback and unknown owner recovery remain prerequisites. Warden quietlane cannot carry ready controlstdout; no transport/custody/native grant. No owner checkout/liveSSH/native.

2026-10-11 RPF35-T12 source implementation progress: durable journal source v4 was independently accepted/committed; owner-derived typed plan compiler component v2 is prepared at immutable manifest 41cda74ab32384c789ea8a760475671aadad4e5121335c8f60567ff53d66665b with40 offline tests. Completed own bounded source-preparation ADHOCT02 anchor was persisted at7adbcb4 before the qualified Platform contract/readiness receipt. T12 progresses for actual source implementation underway, not native acceptance or full descriptor/authority readiness. The compiler derives local CCR/HCL/role bodies, matches actual independently pinned Secrets catalogue and revalidates source/body before fixed calls; no body/target chosen by service is dispatched. Independent technical integration review and exact full ExecutionContract/owner grant/baseline/estate/deadline matching, initiating human/User/Tenant PIP/transport representation/service identity, served PDP/claim/consume correspondence, journal call dispatch/restricted adapter, native token TTL/uses/custody/revoke/cleanup and owner-private unknown recovery remain unimplemented integration/native gates. Actual CCR42 has no eligible approved pilot/catalogue; no source metadata is invented. T02 and original negative/capability/native evidence remain unchanged; T11/T13 history retained, no defaultflip/nativego or SecretsT06 closure follows.

2026-10-13 T12 source correction: the compiler hashed the catalogue sources but used cached Python modules with matching paths, which did not establish executing those exact bytes. A failing regression reproduced the substitution. Catalogue, package and dependencies now execute from the verified snapshot in temporary private modules; ambient modules remain untouched and cleanup runs on refusal. 45 compiler plus 15 journal tests pass. The v2 source review remains historical; this change needs its own integration review. T12 retains all existing full contract, identity/consume, dispatch, custody and native acceptance requirements. RPF-IN-0012 remains open for the independent contract/wrapped-delivery return; this code correction does not authorize either operation.

2026-10-16 T12 source preparation (isolated owner checkout; not owner delivery): added durable precommitted cleanup obligations and separate outcome evidence to the existing Journal, plus a fixed three-method owner cleanup driver. Same live postconsume admission can clean after a business timeout/failed/unknown outcome; cleanup closes business dispatch and cannot replay or restore admission after a crash. Empty obligations no longer produce cleanup-confirmed. Real SQLite multiprocess races and abrupt process death before/after a separately durable synthetic effect verify refusal on reopen. Current compiler/journal/cleanup suite: 73 passed, local source/fixture only. Details: docs/task-execution-cleanup.md. No native adapter or production mediator exists; full grant/request/cleanup binding, authenticated consume/identity, ephemeral token issuance, deadline/use checks, native effect/revoke/absence, audit and protected recovery remain prerequisites. T12 remains progress. No CCR38 default/entitlement or live grant was changed.

2026-10-16 T12 second source package: Compiler Plans now bind deterministic cleanup commitments and can bind the complete independently installed engine execution descriptor. A fixed disposable-loopback native adapter actually materializes exact per-operation metadata ACL/task token, executes six source-derived metadata calls, and verifies self-revocation/accessor invalidation and policy retirement. Each cleanup request has its own durable intent. Native fault tests cover lost response after real write and policy deletion while task revoke fails. All initiating identity/approval/consume/grant/state/source admission in this fixture is synthetic; no production authority or complete native owner acceptance is claimed. Exact remaining owner schema/admission and mediator work: docs/task-execution-native-fixture.md. T12 stays progress; no live grant, credential/default change or owner sync performed.

2026-10-16 T12 third source package: implemented proposed task-execution-grant immutable projection and exact compiler/native-fixture integration through the existing descriptor grant ID/SHA fields. Only typed review.comments/evidence.events are excluded; separate append-only checks reject removal/rewrite/reordering and unknown guessed evidence exclusions refuse. Owner-pinned grant bytes and validator source must match independently reconstructed descriptor/source/cleanup/ACL/token bodies before a native fixture can materialize. Proposed source records gain no execution authority; no real grant, policy or legacy applier registration added. Details and remaining production gates: docs/task-execution-grant-projection.md. T12 remains progress; no owner sync or production effect performed by this package.

2026-10-16 T12 fourth source package: connected the Secrets-owned strict task handoff to actual Approval ExecutionConfirmationClient independent GET before consume-confirmed/native fixture work. Platform accepts no supplied authorization boolean/object/callback and preserves its exact owner descriptor/grant/Plan join. Durable CAS/GET intents precede native ordinals through the repaired journal prefix API. Actual source-server fixture uses signed Access/enforced synthetic TokenReview, real Approval WSGI/SQLite with distinct synthetic human/service identities, actual strict Secrets signature/CAS validation and disposable native OpenBao. Untouched actual task policy remains signed DENY; separately named synthetic fixture policy is never production admission. Read-scope denial after CAS records consumed/unknown with zero native effects. Exact dependency/source hashes, tests and remaining gates are retained with the source package and in docs/task-execution-mediator-seam.md. No real grant/custody, policy default, owner sync or native production acceptance is performed; T12 stays progress.

79 KiB Raw Blame History