Repurpose as the Railiance bootstrap path

This repo carried a copied declaration identifying it as the S2 cluster runtime
layer - byte-similar to railiance-cluster, with which it shares no git history
but nearly all of its content. It was one of four repos (bootstrap, cluster,
hosts, infra) created by copying working trees as the S1/S2 layering idea
emerged, and the INTENT was copied along with everything else.

Its own QUICKSTART.md - set up your very first Railiance host - describes what
the repo is actually for. INTENT.md and SCOPE.md now declare that: turning a
single bare virtual machine into a working Railiance, then handing off to the
ordinary layers.

Inherited S2-era content in ansible/, helm/, docs/ and wiki/ is not yet sorted;
SCOPE records that restructuring is in progress rather than claiming it is done.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

SCOPE.md

@@ -8,120 +8,108 @@
 
 ## One-liner
 
-S2 Cluster Runtime layer of the Railiance OAS Stack — owns k3s installation, Helm, ingress, CNI, admission controllers, operators, and kubeconfig management.
+The Railiance bootstrap path — turning a single bare virtual machine into a working Railiance, then handing off to the ordinary layers.
 
 ---
 
 ## Core Idea
 
-Railiance is structured as five independent repos per OAS Stack layer. This repo is S2. It installs and configures the Kubernetes cluster runtime: k3s, Helm, ingress controller, CNI plugin, cluster addons and operators. S1 (OS) must be converged before S2 can run. S2 explicitly does not own platform services (PostgreSQL, caches) — those are S3.
+Every Railiance layer describes how to operate a system that already exists.
+S1 converges a substrate, S2 runs a cluster on it, S3 provides shared services.
+None of them owns the first step: *you have one virtual machine and an
+intention — now what?*
+
+This repo owns that step. It sequences the layers into a runnable path from
+nothing to a working Railiance, and then gets out of the way. One of Railiance's
+goals is that initiating a new Railiance should be easy; this repo is where that
+claim is made testable.
+
+**Repository status:** this repo previously carried a copied declaration
+identifying it as the S2 cluster runtime layer, duplicating `railiance-cluster`.
+That was wrong and has been corrected — see `INTENT.md` → History. Restructuring
+of the inherited content is in progress; expect S2-era material still present in
+`ansible/`, `helm/`, `docs/` and `wiki/` that has not yet been sorted into
+"bootstrap path" versus "belongs to S1/S2".
 
 ---
 
 ## In Scope
 
-- k3s installation and baseline configuration
-- Helm chart management
-- Ingress controller, CNI plugin
-- Admission controllers and cluster operators
-- Cluster addons (cert-manager, etc.)
-- kubeconfig management and access
-- Smoke tests to validate cluster health
+- The newcomer path from bare VM to working Railiance (`QUICKSTART.md`)
+- Prerequisite and ordering contracts between substrate, cluster, secrets, forge
+- Bootstrap secret material: how it is introduced, and how it is retired once
+  the real custody path (OpenBao, S3) exists
+- The handoff point where the ordinary layers take over
+- A rehearsable test that the bootstrap path still works
 
 ---
 
 ## Out of Scope
 
-- OS security hardening, SSH, firewall → railiance-infra (S1)
-- Platform services (PostgreSQL HA, Valkey, object storage) → railiance-platform (S3)
-- CI/CD and developer tooling → railiance-enablement (S4)
-- Application deployments → railiance-apps (S5)
-- No re-configuration of S1 concerns from this repo
+- OS provisioning, hardening, server baseline → `railiance-infra` (S1)
+- k3s, Helm, ingress, CNI, admission controllers, operators, kubeconfig
+  management → `railiance-cluster` (S2)
+- Shared stateful services: databases, cache, secrets, object storage
+  → `railiance-platform` (S3)
+- Ongoing operation of anything. After handoff this repo has no running role
+- Duplicating layer content — this repo sequences layers, it does not own what
+  they own
 
 ---
 
 ## Relevant When
 
-- Setting up or maintaining the Kubernetes cluster runtime
-- Installing or updating cluster-level operators and addons
-- Diagnosing cluster health (smoke tests)
-- k3s upgrades or kubeconfig rotation
-
----
+- Standing up a **new** Railiance from nothing
+- Establishing or changing the ordering between substrate, cluster and secrets
+- Resolving a bootstrap chicken-and-egg problem (needing a secret to fetch the
+  code that manages secrets)
+- Testing that the adoption path still works by raising a fresh Railiance
 
 ## Not Relevant When
 
-- OS-level work (use railiance-infra)
-- Platform service configuration (use railiance-platform)
-- Application deployments (use railiance-apps)
+- Operating, upgrading, or troubleshooting an existing Railiance — that belongs
+  to the layer that owns the concern
+- Deploying a workload (that is `rapp-*` and S5)
 
 ---
 
 ## Current State
 
-- Status: active / stable
-- Implementation: k3s baseline, pgpool HA failover fix, age-encrypted backup, kubeconfig delivery, staged promotion lifecycle, and activity-core/llm-connect reconcile gates all finished (RAIL-BS-WP-0002…0006, RAILIANCE-WP-0012…0014)
-- Open work: RAIL-BS-WP-0007 ThreePhoenix HA cluster (active, 0/7); RAIL-BS-WP-0008 activity-core WP-0016 deploy (ready); RAIL-BS-WP-0009 admin-sync smoke (ready)
-- Usage: core Kubernetes runtime for all Railiance deployments; runs on COULOMBCORE (92.205.130.254)
-- Also deployed at cluster level: cert-manager, ArgoCD, CloudNative PG operator (cnpg), nginx ingress, SSO stack (mfa + sso namespaces via net-kingdom)
+- Status: **repurposed, restructuring in progress**
+- The bootstrap intent is declared (`INTENT.md`, 2026-08-11); the inherited S2
+  content has not yet been sorted
+- `QUICKSTART.md` is the existing seed of the newcomer path; a near-identical
+  copy also exists in `railiance-cluster` and the two need consolidating
+- `install/` exists in `railiance-cluster` but not here, and is a candidate to
+  move
+- Open: whether the bootstrap path has ever been walked end to end from scratch
 
 ---
 
 ## How It Fits
 
-- Upstream dependencies: railiance-infra (S1) — OS must be converged and verified
-- Downstream consumers: railiance-platform (S3), railiance-enablement (S4), railiance-apps (S5)
-- Often used with: railiance-platform (next layer to configure after cluster is up)
+- Sequences: `railiance-infra` (S1) → `railiance-cluster` (S2) →
+  `railiance-platform` (S3), and hands off once they can run themselves
+- Downstream: everything, indirectly — this is the entry point
+- Often used with: `railiance-master` (which owns the layer model this
+  sequences), `railiance-platform` (which takes over secret custody after
+  bootstrap material is retired)
 
 ---
 
 ## Terminology
 
-- Preferred terms: OAS Stack Level S2, smoke test, pre-condition chain, boundary rule
-- Potentially confusing terms: cluster runtime ≠ platform services; Gitea and databases are NOT S2 concerns
-
----
-
-## Related / Overlapping
-
-- `railiance-infra` (S1) — must be converged before this layer runs
-- `railiance-platform` (S3) — consumes the cluster runtime provided by S2
+- Preferred terms: bootstrap path, ignition sequence, handoff point,
+  bootstrap secret material
+- Potentially confusing: "bootstrap" here means *initiating a whole Railiance*,
+  not `cluster bootstrap` in the k3s sense (that is S2), and not ArgoCD
+  app-of-apps bootstrapping (that is S3's `argocd/bootstrap/`)
 
 ---
 
 ## Getting Oriented
 
-- Start with: `CLAUDE.md` (session protocol, remote execution via SSH tunnel), `README.md`
-- Key files / directories: `workplans/` (4 active), `.sops.yaml` (secret encryption)
-- Entry points: `Makefile` targets; remote work requires SSH tunnel to State Hub
-
----
-
-## Provided Capabilities
-
-```capability
-type: infrastructure
-title: Kubernetes cluster provisioning (k3s)
-description: Install and configure a production k3s cluster including Helm, ingress controller, CNI plugin, and kubeconfig management on Railiance servers.
-keywords: [kubernetes, k3s, cluster, helm, ingress, cni, k8s, provisioning]
-```
-
-```capability
-type: infrastructure
-title: Cluster operators and addon management
-description: Deploy and manage cluster-wide operators and addons (cert-manager, CloudNative PG operator, ArgoCD, nginx ingress) on the running Railiance Kubernetes cluster.
-keywords: [operator, addon, cert-manager, cnpg, argocd, admission, kubernetes, cluster]
-```
-
-```capability
-type: operations
-title: Kubernetes runtime backup (age-encrypted)
-description: Daily encrypted backup of k3s cluster state (SQLite hot copy), Helm release values, and kubeconfig to /opt/backup/railiance/cluster/ using age encryption. Run via sudo make backup.
-keywords: [backup, restore, age, encryption, k3s, state, helm, kubeconfig, disaster-recovery]
-```
-
----
-
-## Notes
-
-Runs on COULOMBCORE (92.205.130.254). State Hub access via ops-bridge reverse tunnel — `bridge up state-hub-coulombcore` from the workstation (see ADR-004). Gitea Helm values were migrated to S5 (railiance-apps) in RAIL-HO-WP-0004-T06 — boundary violation resolved.
+- Start with: `INTENT.md`, then `QUICKSTART.md`
+- Context: `railiance-platform/ArchitectureBlueprint.md` §4 records this repo's
+  lineage and status
+- Pre-conditions: one reachable virtual machine, and nothing else