railiance-platform/docs/provisioning-windows/2026-10-04-1000/dependency-requirements.md

Remaining dependency requirements — 2026-10-04

Review scope: RPF-WP-0050-T03, RPF-WP-0051-T02/T03 and the selected RPF-WP-0035-T02 service-login lane. Source work is implemented where independent of receiving-owner facts. Both preparation workplans are blocked on the deliveries below. Completed design judgments are retained.

Platform task	Receiving repo / owner task	Required independent delivery	Reopen condition
RPF-WP-0051-T02	informed-decision / source phase of INFD-WP-0005-T05	Process-owned private listener and explicit runtime configuration consuming compose_intake; authenticated bounded TokenReview transport using API-server CA; exact owner deploy renderer with private Service, NetworkPolicy, TokenReview RBAC and projected registries; final immutable image/config/source	Accept source composition and publication receipt, reviewed deployment proposal and named native verification/abort attendance. Do not require this owner's entire live T05 completion as a predecessor.
RPF-WP-0051-T03	informed-decision receiving runtime; founder execution gate	Complete T02 source packet, approve exact final live action, then native ESO/auth/file/exchange and revocation/rotation/cleanup receipts	Native delivery and owner runtime acceptance, after platform metadata and separately approved runtime promotion. Source proofs are already complete.
RPF-WP-0035-T02	secrets-engine / service-auth source acceptance in SECRETS-WP-0008-T06	Explicit consumer host, protected file path and owner, mode-0600 delivery mechanism, refresh/rotation/revocation ownership and bounded validation interface	Source acceptance of those coordinates, independent of obtaining a working OpenBao service token. The entire live consumer task must not precede platform login provisioning.
RPF-WP-0035-T02	key-cape / KEY-WP-0037-T02/T03/T04; net-kingdom deployment authority	Accept proposed issuer coordinates and separate consumer delivery; reviewed single-client/env-preserving registration operation with immutable image/config; independently approved custody and actual registration/issuance receipts	Protected custody, real registration and validated provider claims are returned. Platform then performs its separately approved isolated JWT mount/role/self-policy operation and login proof.
RPF-WP-0050-T03	user-engine / USER-WP-0035-T02 and provider owner	Provider-supported single-use password-setup-link delivery contract and intended-recipient evidence; retained value-safe failure/retry behavior	Real handoff receipt. SMTP and invitation delivery already exist and are not reprovisioned.

Delivered owner work and platform checks

Informed-decision source acceptance: implementation eb9614c2677c7f07c9d78eee7543f95f329d2c83, exact-primary receipt f06b7e9c53d3477f1e690ed8259f2eaab3661f91. Requests/replies: 17bcfb39-f8c0-4cda-acce-de7af6d0afbc and d304e328-1e77-4a02-ae47-783a7290b6ce. Its RequesterTokenProvider and compose_intake are implemented with 37 focused owner tests. Exact source binding/mount acceptance is supplied; live claims are not confirmed.

Platform independently verified railiance01's node address and the actual external-secrets controller ServiceAccount, then checked permission to create serviceaccounts/token in informed-decision through SubjectAccessReview. The explicit subresource query returned yes. Receipt: docs/evidence/2026-10-04-requester-eso-tokenrequest-review.json. This is an authorization check; no token was minted and it does not prove Secret delivery. The earlier slash-resource spelling gave a different result and is not accepted as the TokenRequest receipt. The explicit subresource query is authoritative.

KeyCape source packet: 44cc067aa2c7dadffc75b631baa221a5f5caa531; managed IDs/index locally at f485d6fe9c7389b7f29d97e5da51b14eb0692eb3. Replies 58826056-55f2-4300-9b42-05ceeec9c26a and eb20a78c-0b9b-41e6-b349-dfaa9873633b name the real owner tasks. Its latest exact-primary sync is pending: Repo Manager refused grandfathered ADHOC-2026-09-27-T02 without UUID. KeyCape/repo-manager must reconcile the source identity through the required scoped decision, then return an applied/noop receipt for the actual current commit. Platform does not invent UUIDs or bypass the refusal. This is separate from actual provider registration/custody.

Implemented platform issuer-reader preparation

The KeyCape packet's candidate path platform/services/keycape/secrets-engine-openbao is outside the platform-mount applier scope (platform/workloads/ only) and was corrected on 2026-10-06 to platform/workloads/keycape/secrets-engine-openbao, field CLIENT_SECRET.

Revised 2026-10-06 (founder direction: the secret lives only in OpenBao; ops-mason plan keycape-secrets-engine-openbao-client-custody, 658cdbc, MASON-WP-0009). The secrets-engine consumer file and secrets-engine D1-D4 are withdrawn. Two readers:

• Issuer: CCR-2026-0033, unchanged ESO reader. Policy workload-kv-read-keycape-secrets-engine-openbao-eso, Kubernetes role external-secrets-keycape-secrets-engine-openbao (external-secrets/external-secrets, audience openbao, 15m, no default policy). The store admits sso only; target Secret sso/keycape-secrets-engine-openbao-client key client-secret. It must stay on Kubernetes auth.
• Operator: sibling CCR-2026-0034, OIDC role keycape-secrets-engine-openbao-operator-workload-kv-read on auth/netkingdom. Policy workload-kv-read-keycape-secrets-engine-openbao-operator grants read on the data path and update on auth/token/revoke-self only. The token is 5m, 4 uses, service type, with no default policy. Bound claims are groups=net-kingdom-admins and /assurance/level=aal2 (KeyCape 7d96ee4: MFA is not pinned on the openbao-admin client). secrets-engine reads the value into memory per command, with no copy at rest.

CCR-2026-0033 now declares the KV metadata: cas_required=true, max_versions=2, delete_version_after=0s, and custom_metadata as in the plan. Its target.domain is corrected to infotech. The custody child scripts/keycape_secrets_engine_openbao_custody.py (source only, never run) writes KV with cas=0, or with cas=<current> under --rotate, then compares the metadata before it writes. It writes no consumer file. Both CCRs remain proposed with bound claims unconfirmed. Confirming them is a founder item for both readers.

Founder approvals: A1 design, A2 both CCRs, A3 custody-child decision id (not 632a8893). 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). Exact founder commands, including the metadata-only survey: keycape/founder-runbook.md. Payloads and ESO stay outside active GitOps in this window's keycape/ directory. No value exists by implication of these drafts.

Dependency boundary

Owner source readiness precedes platform promotion. Platform native delivery proof follows its own authorized apply, and receiving live acceptance follows that delivery. Requiring a receiving repo's full live completion before platform supplies its credential would create a mutual wait. Where an owner composite task includes both phases, the wait is qualified as message-from:<owner> for the exact independent source receipt until that owner names a separate source task; no fabricated task ID or complete-task dependency is introduced.

Once source deliveries arrive, reopen only the affected platform task. The founder-approved informed-decision design needs no repeat decision unless scope changes. Live actions still require a fresh reviewed execution packet and go; the historical 10:00 preparation window is not a standing execution grant.