railiance-platform/workplans/RPF-WP-0035-credential-lane-implementation.md

---
id: RPF-WP-0035
type: workplan
title: "Implement reviewed credential lanes with separate owner gates"
domain: financials
repo: railiance-platform
status: blocked
flavor: implementation
owner: codex
created: "2026-09-05"
updated: "2026-10-21"
related:
  - RPF-WP-0032
  - RPF-WP-0033
  - RPF-WP-0034
state_hub_workstream_id: "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

```task
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.

## Accept and provision secrets-engine service JWT login

```task
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-17: KEY-WP-0039-T02 owner returns prepared from source (not admitted):
`docs/proposals/2026-10-17-key39-t02-owner-returns.md`. Bao origin and role
leeway are not declared in source and need attended sanitized owner reads.

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):

```bash
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):

```bash
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

```task
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.

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.

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

```task
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

```task
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

```task
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

```task
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.

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.

## Admit the two factory audit-sender custody lanes

```task
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](../docs/credential-lane-designs/factory-audit-senders-review.md).
[Preparation evidence](../docs/evidence/2026-09-11-factory-audit-custody.json).
Do not fold these senders into CCR-2026-0019 or the cancelled CCR-2026-0020.

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.

## 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](../docs/evidence/2026-09-11-factory-receiver-live.json).

### 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](../docs/evidence/2026-09-11-factory-audit-sender-seed.json).

### Delivery prepared; fresh login did not hand off — 2026-09-11

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](../docs/evidence/2026-09-11-factory-audit-delivery-login.json).
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](../docs/evidence/2026-09-11-factory-audit-delivery-live.json).

### 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](../docs/evidence/2026-09-11-factory-native-producers.json).


## 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](../docs/evidence/2026-09-11-factory-native-readback.json).


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

```task
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)

```task
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:

4. **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.
5. **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

```task
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

```task
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-16 T12 wave 5 source preparation: disposable adapter now binds owner
canonical before/after metadata snapshots to existing descriptor hashes, rejects
per-target baseline/readback mismatch, and records readback/verified evidence.
Mediator reports cleanup-confirmed only after independent fixed cleanup receipts.
Complete role metadata and policy name/HCL/version/cas are compared; validated
modification timestamp alone is excluded. This is sequential fixture acceptance,
not aggregate CAS, concurrent-writer exclusion or native production completion.
Role conflict may follow a policy write. Restart refuses dispatch and cannot
recover memory-only token/accessor cleanup handles. T12 remains progress; actual
fresh CCR/catalog/grant, source/trust/caller/policy admission, isolated owner custody,
scoped recovery and attended native acceptance remain explicit prerequisites.


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

```task
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.

2026-10-16 T12 recovery successor source preparation: optional independently
installed fixture custody durably retains operation-bound private accessors and
issuance checkpoints. Fresh cleanup-only owner permits can reconcile after actual
executor process death using fixed revoke/readback and policy delete/readback,
without restoring business/consume admission. Separate durable attempt evidence
retains original unknown outcomes. Lost token-create response remains unresolved
when no accessor was committed. Source-only process-loss fixtures are not native
production custody or recovery-role admission; T12 remains progress.

2026-10-16 T12 recovery R2 source refinement retains R1's overbroad 404 failure:
policy cleanup now requires exact native empty-errors absence before/after delete;
HCL uses only documented single optional terminal LF normalization. Private
capsules are owner-key HMAC authenticated, strict nested schemas/ordered cleanup
commitments reject damage, and journal history prevents stale prepared capsules
from hiding issuance. Fixture process-loss source proof remains separate from
unadmitted production custody, integrity-key storage and recovery-role scope.

2026-10-16 T12 independently reviewable budget/source slice: bound native HTTP
header/body/close, compiler work and cleanup through fixed owner main-thread
absolute budgets, with actual task expiry narrowing global authority. Actual v2
mediator now verifies each independently installed source_bundle byte hash before
authorization/effects. No deadline/TTL extension, remint or generic service added.
Retained registry actual-provider proof still refuses Approval correspondence
before CAS/native; normalized pre-approval + precise immediate CAS whole-stack
positive remains live owner follow-up under CUST-WP-0080. T12 stays progress.

2026-10-16 T12 actual v2 successor source proof: retained registry signed DENY
normalization from the real Secrets prepare_task_approval builder precedes actual
Approval issue/human approval. Actual Access v2 then signs ALLOW; strict Secrets
CAS and independent confirmation GET precede six disposable native calls, exact
readback and confirmed token/policy cleanup. Approval precision source permits
immediate CAS without sleeps/backdating. The 60-second immutable deadline,
30-second backend TTL, 120-second synthetic observation and existing cleanup
reserve remain bound; issued credential expiry narrows business time. Source,
caller, revoke, source-reader, registry drift and expiry refusals cause no native
effects; revoke between ALLOW/CAS retains unknown without business dispatch.
This owner fixture uses separately installed synthetic identity/key/trust and
loopback OpenBao, grants no production authority and keeps T12 progress. Prior
failed temporal/normalization proofs remain retained.

2026-10-16 T12 signer custody R3 source preparation rebases the proposal to
integrated Access919ce25 and preserves current workplan state. Added protected
in-memory Ed25519 CAS/readback primitive with durable closed metadata receipts
and fixed disposable-only owner adapter. Actual synthetic OpenBao bootstrap,
rotation, conflict/unknown/readback/receipt/private-output and admission failures
are tested. Production direct entry refuses: exact CCR/founder scope, protected
executor/fencing/receipt custody, independent consumer public admission, migration
debt and native deployment prerequisites remain open. No live key/grant or CCR
admission; RPF-WP-0035-T12 remains progress.

R3 source metadata correction aligns proposal IDs across JSON/docs/Secret
annotation and documents existing base64url-ASCII public fingerprint hashing.
Frozen R2 source/evidence is preserved; no writer behavior or admission changes.

2026-10-16 T12 native signer preparation: proposed CCR-2026-0050 and generated
read-only HCL pass real schema checks; current proposed status/unconfirmed claims
keep apply refused. Native candidate uses existing external-secrets-* role
convention with dedicated SA unchanged and projected private field only. Exact
attended CAS0/metadata/fence/receipt/forward-recovery action plan is separate from
read-grant authority; production adapter implementation/independent tests and
founder plus distinct owner reviews remain necessary. Access observed zero PVCs;
new outbox storage/retention/runtime bounds remain separate Access/cluster scope.
No live credentials, grants, roles, key or deployment changed. T12 stays progress.

2026-10-16 T12 native signer adapter source: silent fixed-scope attended child
checks exact independent admission/source/CCR/image/caller/trust/identity inputs,
actual backend/reader role/policy, signer fence and private exclusive receipt
custody before fixed metadata/CAS0 effects. Separate fresh read-only recovery
reconciles real process loss after native write without remint/retry/new effects.
Disposable tests exercise actual KV while owner reviews/identity/fence facts are
explicitly synthetic. Current warden plan dispatch selects structure-survey, not
OIDC admin login; mismatch remains a live refusal. Canonical proposed CCR, native
owner/founder approval and Access/cluster/outbox/PVC gates stay open; no live
key, credential read, grant, role, storage or deployment action performed.

2026-10-16 T12 native signer R2 source correction preserves R1 failures: exact
phase-aware read-only recovery classifies current metadata-only/absent states,
never admits a key or retry and preserves original uncertainty. Fresh recovery
explicitly binds historical execution plus current source; current primitive
plan/source/receipt join is enforced and old pin labeled historical. Real fork
metadata-loss and denied/ambiguous tests added.120second expiry is unchanged;
external reviews and unbounded OIDC require a pre-reviewed exact scheduled
window, otherwise refuse/new explicit revision. No native or owner approval
inferred; no live action.


2026-10-16 T13 bounded source-review preparation note (no status/scope closure):
Native signer owner-boundary R3/R4 preparation replaces conflated
cluster-gitops-owner with cluster-runtime-storage-owner. Platform retains
OpenBao and existing GitOps Applications/sync-freeze integration; Access owns
workload/Helm release semantics; cluster reviews runtime/storage/headroom;
Enablement participates only for actual ArgoCD installation/controller changes.
Source facts reconcile implemented/tested native adapter a3e8eb64, canonical
local draft package d52f811/tree d4fbad7 (frozen source2b/current05a) and
ordinary CI402 published candidate84c78e0/image09a83b with OS lock/64MiB/startup
hardening. Prior R1/R2/R3 and packetP1/P2 reviews/failures remain frozen.
No missing-local-declaration waiver, remote placement, actual stopped fence,
PV retention, native custody, independent post-key trust or founder/owner
approval is inferred. Exact successor source/CCR/plan pins and fresh scoped
reviews remain required; T12 native gates and historical T13 outcome unchanged.

2026-10-16 T12 bounded native plan review: Platform independently approves the
exact P4/R2 custody/read-lane and existing manual Argo Application freeze/recovery
proposal only, per docs/evidence/2026-10-16-flex-auth-native-plan-review.json.
Current observed inventory has no signer Application; root and informed-decision
manual sync are held during ceremony, while shared openbao-secretstore and legacy
eso-token-renewer stay unchanged. Exact CCR read grant and one-use custody writer
remain separate. Actual CCR/founder/entity/expiry/window/fence, native ESO/readback,
independent Secrets public trust and Access/cluster runtime proofs remain gates.
No authority/admission field changes; T12 remains progress.


## Founder approval of the flex-auth envelope signing key custody scope (CCR-2026-0050)

```task
id: RPF-WP-0035-T14
status: wait
priority: high
needs_human: true
blocking_reason: "Founder resolves decision 18731e84 approving the exact CCR-2026-0050 custody scope (KV document, one CAS0 bootstrap, read policy and ESO role)"
depends_on: [RPF-WP-0035-T12]
decision_id: 18731e84-a6ab-4ac5-bf0e-7e7c3a9c4508
state_hub_task_id: "e310197f-d55c-5732-b606-8b0d88a69836"
```

Human gate for custody route `flex-auth-decision-envelope-signing-key`. The
founder resolves hub decision `18731e84-a6ab-4ac5-bf0e-7e7c3a9c4508`, which
states the exact new scope: KV document
`platform/data/workloads/flex-auth/envelope-signing` (seed, public key, kid;
CAS-required, max 2 versions), one attended CAS0 bootstrap with kid
`flex-auth-lifecycle-20261016-r1`, read policy
`workload-kv-read-flex-auth-envelope-signing` and Kubernetes role
`external-secrets-flex-auth-envelope-signing` (SA `flex-auth-envelope-signing-eso`,
namespace `flex-auth`, audience `openbao`, 15m). Approval is scope only; each
live step in `docs/runbooks/flex-auth-envelope-signing-attended-creation.md`
still needs the founder's go at the time.

2026-10-21 state: railiance-platform-owner approved (runbook review);
secrets-engine-owner approved with two receipt conditions (hub message
e73c9ffc, recorded in the CCR); access-engine-owner approved for Access scope
(hub message 6529bacf; its rollout go is separate decision 4fab263d);
cluster-runtime-storage-owner (railiance-cluster) review requested in hub
message f8b4b229. The warden routing defect from 2026-10-16 no longer
reproduces (`docs/evidence/2026-10-21-flex-auth-signer-warden-route.json`).
The native adapter's owner-review digest no longer binds `expires_at`, so
reviews can be given ahead of the 120 s attended window; the expiry check is
unchanged. Recorded as a build-mode change in the-custodian
`docs/security-close-down-checklist.md`. Nothing generated, written or applied.

Done when: the decision is resolved, `sync-decision` copies it into the CCR,
all five dispositions are recorded, and the runbook preconditions hold.