RAILIANCE-WP is a family name, not a repository (ADR-007, and the prefix
registry already lists it retired). Three repositories independently used one
number space for unrelated work — RAILIANCE-WP-0012 was openbao extraction here,
a cnpg backup in railiance-apps and a deploy-verify in railiance-cluster. This
repository also carried two files both numbered 0016.
Active workplans move to the successor prefix and are renumbered from 0001 in
historical order. Archived workplans keep their historical identifiers.
Projection UUIDs are re-derived from the new canonical ids. Records already
registered under the old identifiers leave orphaned hub rows behind; that debt
is recorded in CUST-WP-0068 and clears when ADR-012's reset-from-forge lands.
Refs CUST-WP-0068-T03
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
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>
