The attended session enumerated field names at the governed path: NPM_AUTH_TOKEN
is the only field present, at KV version 2. This repository's record was correct.
secrets-engine's lowercase field name and the ops-warden catalog change made on
that statement both name a field absent from that path, so that change points the
front door at nothing and must be reverted before next use. The both-fields
reconciliation is ruled out.
The same session found the legacy path is real: secret/coulomb/whynot-design/
npm/publish exists at version 1, created five days after the governed lane was
verified, outside its policy and outside any CCR. Only metadata was read; field
names were not enumerated and nothing was deleted. Disposition is the new
RPF-WP-0035-T07, which asks first whether the consumer's proven publish has been
reading the duplicate rather than the governed lane.
Receipt carries field names only, attended_identity true, no mutation.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WLUjpv3ssxNRAEPPgLFnEB
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275505@bnt-lap001
Assistant-Session: 97265baa-f08f-4032-b290-a1e2965a69c5
Layer declaration (gate-house). INTENT.md now carries the declaration in its own
voice with layer.yaml as the machine-readable form, adapted from ops-warden's
reference. railiance-platform is Staff: operating OpenBao is not a claim to the
Tooling layer, because §4 is explicit that no operator-of-third-party-Tooling
shape exists and that someone running it stays a declared gap. Six direct
Tooling contacts are mapped by capability rather than by file — one §5.2
conduit, one §5.1 diagnostic, four §5.3 gaps with intended owners and review
dates — and the uncatalogued contacts are listed so the check is total. We are
PEP-shaped and the unreachable-engine stance map is NOT published; that is
recorded as an open obligation to build against v0.8, not left silent.
Placement admission. canned-prompts was added as a PostgresConsumer on
platform-pg-2 in rapp-postgres 1b68b4c without a placement owner here, which is
exactly the cross-repo drift the assurance check exists to catch; the check had
been failing on it. Registered with its real boundary evidence, corrected the
stale test expectation that pinned the overflow cell at one consumer, and
updated the SCOPE occupancy line to 2/4.
Also records owner input received today: key-cape's issuer view on CCR-2026-0020's
presenting actor, and their confirmation that codex-railiance-platform correctly
stays tenant:coulomb, so the flagged T02 discrepancy is closed as not-a-defect.
The whynot-design npm field is NOT changed. Two dated live receipts here name
NPM_AUTH_TOKEN as the field, including an attended founder fetch; that is
recorded against the counterparty claim rather than either side being flipped
before the session settles it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WLUjpv3ssxNRAEPPgLFnEB
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275505@bnt-lap001
Assistant-Session: 97265baa-f08f-4032-b290-a1e2965a69c5
RPF-WP-0035-T06. Adds CCR-2026-0019 (secrets-engine) and CCR-2026-0020
(approval-engine-operator) with their exact-path read policies, reusing the
existing version-1 custody from the verifier activation. No reseed, rotation,
shared reader or verifier Secret reuse; both requests are in_flight and nothing
is applied.
The two shapes were decided by read-only survey rather than assumed.
secrets-engine consumes its client secret through an operator-run CLI reading a
protected file, and its namespace holds no workload, so reader 1 is an attended
operator-workstation OIDC lane rather than an ESO lane; its one missing input is
the operator group claim, which NetKingdom and KeyCape own. approval-engine is
not deployed and no owner source names who presents the operator client, so
reader 2 records the undetermined actor instead of guessing one for the widest
approval scope in the pair. Both declare openbao.auth missing rather than
carrying a placeholder binding.
T06 moves to wait on those two owner inputs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WLUjpv3ssxNRAEPPgLFnEB
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275505@bnt-lap001
Assistant-Session: 97265baa-f08f-4032-b290-a1e2965a69c5
Answers KEY-WP-0013-T02. Both proposed KV paths are confirmed unchanged; the
field name is corrected to CLIENT_SECRET for the platform uppercase convention
and the CCR validator. Kubernetes delivery references are confirmed against the
live sso namespace. Attended authority is the governed openbao-platform-admin-login
lane, and the rollout is one attended window ordered after the Authelia issuer
precondition.
Adds CCR-2026-0017/0018, two exact-path read policies, two namespace-limited
ClusterSecretStores with Kubernetes auth, two ExternalSecrets, and RPF-WP-0035-T05.
Nothing is applied and no value exists: both CCRs remain proposed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WLUjpv3ssxNRAEPPgLFnEB
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275505@bnt-lap001
Assistant-Session: 97265baa-f08f-4032-b290-a1e2965a69c5
Use IAM application resource-control and policy Scoped backup access.
OpenBao path is platform/workloads/railiance/backup/object-storage.
rapp-postgres keeps Secret platform-pg-backup-s3 as the first projection.
Document the one recipe a new rapp uses to acquire runtime secrets:
standing KV secrets bind through a CCR target.rapp, leases through
grant rapp_id. Stamp the existing postgres grants and the qonto
workload CCR. Gate, delivery, and revocation are unchanged.
Five failures in full credential test discovery, none of them broker
regressions:
- CCR-2026-0009 referenced a policy file that was never added, and used a
schema-invalid access_frontdoor.readiness value. Add the least-privilege
workload-kv-read-qonto-assistant.hcl (read-only on tenants/binky/qonto-api)
and set readiness to pending-review. The lane stays proposed and
non-resolvable.
- Three refusal tests used the live CCR-2026-0002 file as their "unapproved
CCR" fixture. That lane is now approved, applied and active, so the gates
correctly permitted it and the tests failed; applier-apply then walked into
its interactive confirmation prompt and raised EOFError under a
non-interactive runner. Add an unapproved_ccr() helper that materializes a
normalized temp copy so approval state is no longer read off a mutable
production artifact.
- The approve/unconfirmed-claim test demoted an active CCR to approved while
leaving resolvable=true, tripping a correct validation rule. Build it from
the same helper.
No gate, blocker, validation rule, or grant semantic was changed. Verified:
credential discovery 52/52 and full discovery 61/61 pass non-interactively,
make credential-change-validate passes all nine CCRs, the grant catalog
validates, and both audit-core openbao-database-credential grants retain
exec-env-only delivery and revoke-on-exec-exit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
QONTO-WP-0004-T06. Requests a second, workload-scoped access lane into
the existing tenants/binky/qonto-api credential (CCR-2026-0008 is
human/OIDC admin access only, not usable by a running pod). Mirrors
CCR-2026-0003's llm-connect pattern: External Secrets Operator reads
the KV path into a namespace-scoped Kubernetes Secret via a
ClusterSecretStore restricted to the new qonto-assistant namespace;
the pod never touches the OpenBao token directly.
Status: proposed, not approved -- requires platform-operator and
binky-tenant-owner sign-off before the auth role/policy are applied.
Draft ClusterSecretStore manifest included, following the same
"deployed separately, not via this kustomization" pattern as the
existing activity-core/forgejo/reuse stores. Validated against
schemas/credential-change-request.schema.yaml.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Align path and fields (API_KEY, API_USER) with provisioned secret; policy and
OIDC role applied; agent-high-risk-boundary deny on data path. Front door ready.
Enable tenant commercial secrets: applier accepts mount tenants/, apply
policy and OIDC role for company-email IMAP (metadata only; values are
founder Red provision). Extend agent-high-risk-boundary for the path.
Record WP-0026 T07 promotion evidence (no secret values), mark the
offsite backup lane front door resolvable/ready, and add OpenBao policy
agent-high-risk-boundary for coding-agent metadata-only access.
Establish proposed workload-kv-read custody for the Forgejo site-admin
PAT at platform/workloads/forgejo/forgejo-admin, sibling to forgejo-mailer.
OIDC workstation fetch mirrors the railiance-backup-offsite pattern.
RAILIANCE-WP-0011-T01: propose OpenBao path
platform/workloads/reuse/reuse-surface/runtime-secrets with
REUSE_SURFACE_TOKEN and REUSE_SURFACE_FORGEJO_WEBHOOK_SECRET, matching
read policy, and metadata review for Railiance01 interim ESO delivery.
Add workload KV lane for Nextcloud WebDAV token, URL, and age recovery
escrow at platform/workloads/railiance/backup/offsite-lane. Apply read
policy and OIDC role railiance-backup-workload-kv-read; wire forgejo-backup
to load credentials from OpenBao when env is unset.
