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>
The 2026-08-11 decision to keep ArgoCD rested on a claim that turned out to be
wrong. Verified against both clusters once API access was restored: ArgoCD is
not on railiance01, it runs on CoulombCore, its Applications target CoulombCore
in-cluster, nothing on railiance01 is ArgoCD-managed, and the live S3 workloads
- target-revenue, openbao, external-secrets - deploy outside GitOps. Two
Applications are Degraded and one is OutOfSync/Missing.
The earlier claim that removing ArgoCD documentation would describe a system
that does not exist was backwards: the documentation already describes a
deployment path that is largely not in effect. Restates the question with three
real options - adopt properly on railiance01, retire, or relocate to Helix Forge
- and notes that doing nothing is the option with a cost.
Same defect class as RAIL-HO-WP-0009: declared and live state diverged, and
nothing detected it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
S3 has carried Q1 Security and Compliance for months - approval gates,
delegated apply, revocation semantics, front-door readiness - without the
dimension ever being named. Naming it does not change what this layer does; it
makes the responsibility legible to the rest of the fleet.
Also draws the line the other way: observability is Q2 and belongs to
railiance-telemetry, so S3's obligation is to emit through the standard contract
rather than build its own monitoring. The recoverability half is Q3 and remains
unowned.
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>
The central finding. OAS defines six canonical dimensions and states that each
architecture description MUST use them. Railiance has modelled itself almost
entirely on Stack. Everything that did not fit a stack level was treated as an
anomaly - "unplaced", "beside the stack" - and accumulated as exceptions.
They were never anomalies. They are concerns on dimensions Railiance was not
using, and the Quality dimension's sub-levels map almost one-to-one onto the
capability gaps this review found independently: Q2 Observability is
railiance-telemetry, named in canon in exactly those words; Q7 Governance is
the conformance loop; Q3 is restore proof; Q6 is cost attribution. The
self-evidencing thread across five stack layers is five Stack repos each
independently asking for Q2 and Q7 - what a missing dimension looks like from
inside the one you are using.
Also records four contradictions (C1-C4), of which C1 is actionable here: the
hub attributes ~11 capabilities to this repo including Terraform, Ansible, k3s,
CI/CD and app deployment, which S3 does not own. SCOPE.md declares four, all
correctly S3, and is authoritative.
ArgoCD decision closed: keep it, documentation stays accurate; relocating GitOps
to Helix Forge noted as possible future cleanup.
SCOPE.md: corrects the "five independent repos per OAS Stack layer" claim,
records the ArgoCD deployment path, the telemetry emission relationship, and the
hub capability drift.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Consolidates what this session established: the four orthogonal repo-family
axes and the separation rule that keeps Forgejo orgs, State Hub domains and
rapp contexts from being derived from each other; the stack levels plus the
concerns that sit beside the stack; the self-evidencing thread and its two
halves (evidence plane, now owned by railiance-telemetry, and the conformance
loop, still unowned); verified repository status including the two superseded
lineages; and the open placement decisions, each naming railiance-master as
the decider rather than settling them here.
Records that the railiance-forge retirement hypothesis was tested and rejected
- it and helix-forge are different lineages, one operational and one
methodological - so forge should be placed, not retired.
Also notes for tooling that the bootstrap/cluster/hosts/infra repos have
unrelated histories but near-identical content, so fleet inventories must
deduplicate by origin URL rather than by directory.
SCOPE.md gains the telemetry emission relationship and a pointer to the
blueprint.
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>
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>
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>
Managed role coulomb_social with passwordSecret
coulomb-social-app-credentials; Database CR coulomb_social_db.
Activates when apps-pg cluster is deployed.
WP-0011: sync coulomb/target-revenue path k8s/railiance into namespace
target-revenue (revenue.coulomb.social). Requires image, OpenBao secrets,
and DNS before a healthy sync — see target-revenue docs/deployment.md.
Maintainer decision, 2026-07-29: adopts TRSL V1C1 as this repo's
preliminary governing license, per target-revenue's
workplans/TREV-WP-0008-governance-and-pilot-rollout.md T05. Full
specialist legal review is deferred until out of beta (target-revenue
SCOPE.md §1). No Phase is yet declared for this repo.
Co-Authored-By: Claude Sonnet 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>
Add cnpg-option-a-backup JSON runner, vendored static age, kubectl install
helper, and ESO policy path for offsite lane so railiance01 workers can
upload without workstation OIDC (RAILIANCE-WP-0016).
Extend external-secrets-activity-core policy notes with forgejo-admin
paths used by activity-core actcore-forgejo-admin ExternalSecret
(ACTIVITY-WP-0023-T05).
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.
