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>
Replies sent to policy-nexus (F1 substrate boundary, F2 ADR surface, F5
frontmatter corpus), rapp-postgres and net-kingdom (F3 rule/number split,
F4 provider-versus-consumer ladders), tenant-engine (placement policy
answering its three asks), adaptive-pricing (co-signature requested) and
railiance-master (bao.coulomb.social still open, second public name
proposed). Routed inbox marked read.
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>
Routed by tenancy-posture_v0.1 §19.2/§20 (rapp-postgres, tenant-engine) and
by POLICY-NEXUS-WP-0001, which assigns this repo substrate ownership for
policy.coulomb.social and includes it in the ADR publication corpus.
Records four findings against the policy as drafted: the substrate
assignment crosses the S1/S2 boundary; this repo holds no ADRs and records
decisions in the hub, so its decisions are unpublishable; §19.8 asks S3 for
a number that lives in rapp-postgres; and the posture vector is
service-shaped while this repo is a layer.
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.
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.
32 assertions, 31 pass on Railiance01. The one failure is a real defect the old
loose assertion could never have seen: Flannel VXLAN declared open to Anywhere
with no source restriction, currently absent from the host, so converging would
introduce the exposure rather than correct drift.
Also records the sharper finding from wiring it up: verify.yaml was missing the
vars_files the bootstrap play had, so the firewall assertions rendered empty and
silently asserted nothing - worse than having no check at all.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
T04 done, and the answer changes the order. Item 10 was scored size 5 as a
greenfield build. It is not. railiance-infra already has a Goss baseline suite,
an ansible runner, a make verify target that runs it against all hosts and
commits TAP reports to git, and an evidence trail in reports/. The mechanism is
built and wired.
Two things are wrong with it and neither is a build. Nothing runs it - the last
TAP report is dated 2026-03-09, five months ago. And its firewall assertion
matches /6443\/tcp.*ALLOW/, which asserts the port is allowed but not from
whom - it passes identically whether 6443 is restricted to one operator address
or open to the internet, which is exactly the drift that went undetected. It
would however have caught the other finding, since it asserts Status: active and
UFW is inactive on CoulombCore.
Rescoped into slices: 10a (run it, tighten the assertion) is size 1-2 and rises
to WSJF 12.0, fourth overall and the highest-value item after the ratifications.
10b (schedule + alert path) is 7.0. Names the shared dependency - 10b and 9b are
the same plumbing, and building either of 9 or 10 without it produces logs
nobody reads.
The lesson recorded: the gap analysis correctly identified no-conformance-loop
as a capability gap, but the capability was two-thirds built and abandoned.
Before sizing a gap as a build, check whether it is actually an abandonment.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
T03 done: sent as ac73b172 with the recommendation that master takes the eight
ratification and taxonomy items, and including the correction that our earlier
ArgoCD report to them was wrong.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Compares INTENT (declared aspiration) against SCOPE (declared state) against
verified reality for every railiance-* repo. This was only possible now: a gap
could not be distinguished from a stale document until the architecture was
coherently defined, the SCOPE files described verified rather than assumed
reality, and the INTENT files stated current rather than copied intent.
Names the pattern that organizes the work: every gap is declared-but-unbuilt
(telemetry, S4, conformance loop), built-but-undeclared (the firewall
restriction, Q1 custody, the Plane dimension), or decided-but-unmoved (forge
placement, hosts retirement, rapp schema). The third kind is cheapest to clear
and blocks the most; the second is most dangerous, because it stays invisible
until something breaks - the firewall case was found by accident.
RAILIANCE-WP-0016 orders 19 items by WSJF with owner and reasoning per item.
Top three are nearly free and all decided-but-unmoved. Item 1, converging the
firewall allowlist, is a live exposure: two standing grants point at addresses
the ISP has reassigned. Item 2, five pending ratifications in railiance-master,
blocks a quarter of the backlog for a day of decisions.
Flags honestly that the size scores for telemetry and the conformance loop are
guesses, that item 13 is blocked rather than deprioritized, and that this
backlog belongs to railiance-master rather than S3 - it lives here only because
the analysis was done here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Populates each canonical dimension with Railiance's actual position, canon's
sub-levels, owners where they exist, and honest status.
Findings from doing it:
- Q1 Security and Compliance is already implemented in S3 to a mature standard
(approval gates, delegated apply, revocation, front-door readiness) and was
never named as a dimension. Evidence the dimensions describe real structure
rather than impose vocabulary.
- Plane is operated in full and declared nowhere. P1 workload, P2 control
(ArgoCD, CNPG, ESO, cert-manager), P3 management (State Hub, master,
workplans). Likely to clarify the rail/rapp relationship, since a rail is
essentially a P1 contract.
- Intelligence is already referenced in practice - qonto-assistant cites an I1
isolation profile - and the whole agent operating model is I4-I5. Leaving it
unmodelled understates what this fleet actually is.
- Q3 Operability and Q7 Governance remain unowned; Q5 unaddressed.
Adds a recommended establishing order for railiance-master to ratify: Quality
first (most unowned concerns), Plane second (cheap, descriptive), Capability
third (blocked on the C1 attribution drift), Intelligence fourth, Logic last or
never if Helix Forge owns functional decomposition.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reads all ten local railiance-* INTENT.md files as a statement of intended
architecture, cross-checked against git history, remotes and the live cluster.
Ten repos declare eight distinct intents. The aspiration is coherent and the
handoffs are stated from both sides. Findings: railiance-bootstrap is a second
local clone of railiance-cluster rather than a repo (which means fleet counts
built by scanning ~ overcount, including the 112 figure in the org refactor);
railiance-hosts and railiance-infra are distinct remotes with unrelated
histories and byte-identical INTENT, both claiming S1; railiance-forge is
unplaced in the OAS stack dimension; S4 is aspiration-only at 25 commits and
zero workplans.
The strongest finding is a shared thread nobody named: five layers
independently aspire to be "self-evidencing" or "auditable", and no repo owns
the verification substrate that would evaluate those claims. That is the same
gap as the enforcement control loop, arrived at from the opposite direction.
Also notes missing homes for observability, end-to-end restore proof, and the
cost-attribution interface.
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>
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>
