Survey of the four-axis repo family model against the live cluster and all six
family repos found the concepts sound but unenforced: rapp.yaml has no schema
and has drifted three ways across the three existing rapps, the reef binding
registry lists 1 of 3 live rapps, the rapp population diverged from the
first-wave plan of record, and the model is not in custodian canon so
fix-consistency cannot check it.
Operator decisions recorded in the workplan: grouped-by-bounded-context rapp
granularity, S3 owns only its own rapps and routes schema/canon changes to the
repos that own them, canonize the model now, and build the missing wave-1
user-facing exemplar.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
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.
RAILIANCE-WP-0011 plans migration of REUSE_SURFACE_TOKEN and
REUSE_SURFACE_FORGEJO_WEBHOOK_SECRET from bootstrap K8s Secret custody to
OpenBao KV plus External Secrets, following the issue-core lane pattern.
Helper-side preflight scope is complete and unit-tested; the live flex-auth
deny capability is re-scoped to flex-auth-side work (capability request
893ff109). Autonomous decision, documented in the task note for easy revert.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
