Two reachable clusters each carry a CNPG Cluster named apps-pg in a
namespace named databases. KUBECONFIG is an environment variable, so the
Makefile ?= default never applied, and RAILIANCE01_KUBECONFIG pointed at
config-hosteurope - a different cluster. Had the environment pointed at the
other reachable cluster instead of an unauthorized one, make apps-pg-deploy
would have applied RPF-WP-0019 connection limits, role timeouts and backup
config to the wrong cluster and reported success. The Unauthorized error was
the only thing that prevented it.
Filename selection cannot protect against this: both kubeconfigs resolve to
a 127.0.0.1 tunnel port and the environment wins either way. railiance01-guard
pins identity instead, comparing the live kube-system namespace UID against
RAILIANCE01_CLUSTER_UID, and fails closed on mismatch or unreachability. It
gates apps-pg deploy, backup-deploy, overflow-dry-run, status and shell.
Verified refusing on the wrong cluster, refusing when unreachable, and
passing on railiance01. Not global: db-status legitimately targets the other
cluster for gitea-db.
RPF-WP-0019 blocker note corrected - the cluster was never unreachable, our
wiring was wrong.
RPF-WP-0020 seeded for the pre-existing CCR test failure, which is two
unrelated problems: CCR-2026-0010 is an active lane missing its whole
openbao.auth block, and CCR-2026-0011 is an honest in-flight draft the suite
has no way to express.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
RPF-WP-0018 closed: all seven tasks done. The provider-declaration finding
was adopted upstream and its canonical form is the provider: block in
tenancy.yaml; adaptive-pricing declined the standing co-signature and
supplied typed tier minima instead, recorded in ADR-0002. Three corrections
against our own output are recorded in the documents rather than edited
away.
RPF-WP-0019 T03 done (ceiling of three, memory binding, apps-pg-2 named as
overflow, enforced by make apps-pg-verify-capacity). T01/T02 are
repository-complete: backup target, retention, per-consumer connection
limits, role timeouts and Burstable resources are declared in source and
published in s3-consumer-interfaces 1.1.0 before rollout. They stay in
progress because no live application, backup success or restore proof
exists, and declared configuration is not a section 13 artifact. T04 waits
on that window.
apps-pg R reason corrected to say the target is declared-not-applied rather
than absent.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Placement policy 3.1 records that the P1 levels for vergabe and
coulomb_social are provisioning declarations without the SS13 isolation
probes - apps-pg has none. 3.2 records that apps-pg cannot produce the
noisy-neighbour artifact at all until per-consumer controls exist, per
SS13.4: with nothing to bind, a probe could only demonstrate degradation.
RPF-WP-0019 seeded for the three live defects the disclosure work found:
no backup, no per-consumer controls, no isolation probes. Kept separate
from RPF-WP-0018 so declaring is not confused with fixing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Self-audit after reading SS6, SS11, SS12 and SS13 in full rather than the
sections cited in review.
openbao A:2 -> A:0. The claim was incoherent (it invoked the absence of
tenant context to justify E:0 and ignored it to claim A2, which SS4.2
defines in terms of tenant context) and unevidenced at the moment of
claiming, which SS13.1 forbids and SS13.1a does not excuse above the floor.
The real authorization evidence, openbao-verify-token-grants.py, is
consumer-boundary and is now cited under the provider statement.
Floor claims carry reason: per SS13.1a; permanent-by-design lines are
marked so SS12 guard does not read them as stalled.
The provider-versus-consumer finding is narrowed: SS6 plus the flex-auth
I1-forever precedent already express a structurally permanent low level,
so that half is withdrawn. What survives is that a provider cannot state
the level it makes reachable for its consumers.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
T01 docs/tenancy-posture.md - vector set per service rather than one repo
vector, with the provider-versus-consumer finding routed to net-kingdom.
T02/T03/T06 docs/placement-policy.md - accepts placement ownership scoped
to rule-here/number-there, records a placement owner per workload, reports
the latency-critical + batch co-residency on platform-pg, marks the
connection-ceiling trigger unmonitored pending railiance-telemetry, and
answers the retention floor/ceiling question.
T04 s3-consumer-interfaces 1.1.0 - quota disclosure per SS10.2. Surfaces
that apps-pg has no backup, no resource limits and no tuned parameters.
T05 docs/adr/ created with a mandatory-frontmatter convention and the
first three ADRs. This repo previously held none.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Read the resource-control open/restricted signal and refuse new orders
that would exceed a restricted entity's published allowance. Open and
missing signals stay unchanged. Safety paths admit with an exception.
Item 13 is the restore RESOURCE-WP-0002 already proved. Item 14 retires
the dead Bitnami postgresql-ha deploy path and gates Valkey until a
consumer exists. Item 17 publishes the versioned S3 consumer-interface
index.
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.
Publish capacity, recovery, labor, and allocation-driver evidence for
resource:railiance:apps-pg so resource-control can forecast and allocate
without reading application data or inventing booked cost.
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.
Converge the S3 platform-service pattern onto ADR-0007, emit the
reef-railiance live deployable inventory for the family coverage
check, and mark T02 done. Declaration edits land in rapp-openbao
and rapp-postgres.
Gitea has been replaced by Forgejo. Updates prose mentions in docs/ while
deliberately preserving live names that a blind sweep would have broken:
GITEA_BACKEND_TOKEN is a provisioned OpenBao field in CCR-2026-0002, GITEA_URL
is a Makefile variable, and gitea-db is a running cnpg cluster. Capitalisation
discriminates prose from identifiers. Archived workplans are left as historical
record.
Blueprint 5.2: forge placement decided - workload to rapp-forgejo, layer
responsibility to S4 railiance-enablement, which already declares the handoff
contract and gains its first concrete owned responsibility.
Blueprint 5.6: whether Railiance should use ArgoCD at all is recorded as an open
decision rather than acted on by removing mentions. S3 runs four live ArgoCD
Applications plus AppProjects, and the two most recent commits here add more, so
deleting the documentation would describe a system that does not exist. The
question is real; it needs a decision and a migration, not a docs edit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Operator design review considered binding bounded rapp context to Forgejo orgs
or State Hub domains and rejected both. OAS P1 governs - independent
perspectives must stay in separate dimensions - and cardinality forces it: a
repo has exactly one Forgejo org (a path segment in the clone URL) so org:repo
is 1:many, while rapp:repo is many:many, and a many:many grouping cannot be
derived from a 1:many one.
Records the dimension table, the composition block (first-party member repos
plus pinned upstream components and a stated purpose), and the precision that
makes enforcement well-defined: repos are many:many with rapps but deployables
are 1:1, so the validator can ask whether every live deployable belongs to
exactly one rapp. That is the coverage check that would have caught all three
of this survey's drift findings at once.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
T01: docs/rapp-platform-service-pattern.md generalizes the ownership split
already drawn in the rapp-openbao and rapp-postgres boundary docs into a
reusable four-question test, a reference rapp.yaml for platform services, the
grouped-rapp member rule, and the credential-lane position. It deliberately
does not restate the four-axis model, which railiance-master owns.
T03/T04/T05: proposals routed to the repos that own the model rather than
authored here - reef-railiance (bound_rapps lists 1 of 3 live rapps, and should
be derived rather than hand-listed), railiance-master (rapp.schema.json plus a
family declaration validator, grouped-rapp members field, wave-2 candidate
refresh), the-custodian (canon promotion of the four-axis model, which also
closes the open C-31 multi-segment prefix failures).
T02 is held until the schema settles so the platform rapps and the schema do
not converge on different answers.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
