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>
