attemp to develop rig in spr without an actual use case

rig/BOOTSTRAP.md

@@ -4,9 +4,8 @@ The README says the prerequisite is Docker and nothing else. This is what that
 actually looks like end to end: a bare Linux box, and a new project running under
 Tilt at the end of it.
 
-rig lives inside soleprint, at `spr/rig` — it is soleprint's cluster half, and
-a client copy is a sibling (`spr/acme-rig`). Paths below are relative to
-soleprint's checkout.
+A copy of this directory is a sibling of it, named after the environment it
+models (`acme-rig`). Paths below are relative to the parent checkout.
 
 It spans three repos because the work does. **rig** prepares the machine — the
 pinned toolchain, the cluster, the port arithmetic. **all** owns the shape a
@@ -50,7 +49,7 @@ isn't.
 ## Read the docs before installing anything
 
 ```bash
-cd spr/rig
+cd rig
 make docs
 ```
 
@@ -67,11 +66,11 @@ persists; ctrl-c ends it.
 ## Ask what is wrong with this machine
 
 ```bash
-make station
+make check
 cp ctrl/.env.example ctrl/.env
 ```
 
-`station.sh` reports and instructs, and fixes nothing. It runs bare rather than
+`check.sh` reports and instructs, and fixes nothing. It runs bare rather than
 in a container because host detection only ever reads `/proc` and `/etc` — no
 dependency beyond coreutils.
 
@@ -80,7 +79,7 @@ port rig binds derives from this directory's name, so the answer is specific to
 this copy, and a clash here surfaces as an opaque `failed to bind host port` in
 the middle of cluster creation if you skip it.
 
-Copy the `.env` even though station only warns about it. It is gitignored, it is
+Copy the `.env` even though the check only warns about it. It is gitignored, it is
 where a machine-local override goes, and `ports.sh persist` expects it to exist.
 
 
@@ -88,33 +87,33 @@ where a machine-local override goes, and `ports.sh persist` expects it to exist.
 
 This is the step where "nothing installed" stops being rhetorical.
 
-`make deps` runs `ctrl/wizard.sh install` directly on the host, and the wizard
+`make deps` runs `ctrl/deps.sh install` directly on the host, and the installer
 fetches with `curl`. A stock `debian:trixie-slim` has no curl — detection runs
 fine, then the first download dies with `curl: command not found` and an exit
-code of 127. That is the bootstrap paradox `ctrl/Dockerfile.wizard` exists
-to kill — the wizard carries its own toolchain so the host needs only Docker —
+code of 127. That is the bootstrap paradox `ctrl/Dockerfile.deps` exists
+to kill — the installer carries its own toolchain so the host needs only Docker —
 but building the image and running it are two different things, and only the
 build has a Makefile target today. **On a genuinely bare machine, run it by
 hand:**
 
 ```bash
-make wizard                          # builds rig-wizard:wizard
+make deps-image                          # builds rig-deps:deps
 mkdir -p ~/.local/bin
 docker run --rm \
   -v /:/host:ro \
   -v /var/run/docker.sock:/var/run/docker.sock \
   -v "$HOME/.local/bin:/out/bin" \
   -e HOST_UID="$(id -u)" -e HOST_GID="$(id -g)" \
-  rig-wizard:wizard install dev
+  rig-deps:deps install dev
 ```
 
-The image name follows the directory, like everything else here: in `spr/rig`
-it is `rig-wizard`, in a copy called `spr/acme-rig` it is `acme-rig-wizard`. The
-tag is `wizard` (or `full`, below), not `latest`.
+The image name follows the directory, like everything else here: in `rig`
+it is `rig-deps`, in a copy called `acme-rig` it is `acme-rig-deps`. The
+tag is `deps` (or `full`, below), not `latest`.
 
 None of the four arguments are guessable, so:
 
-- **`/:/host:ro`** — the wizard reads the *host's* `/etc/os-release` and
+- **`/:/host:ro`** — the installer reads the *host's* `/etc/os-release` and
   `/etc/wsl.conf`, not the container's. `HOST_ROOT=/host` is already baked into
   the image; this is what it points at. Read-only, and it is the only reason
   detection inside a container tells you anything about the machine.
@@ -122,7 +121,7 @@ None of the four arguments are guessable, so:
   and how it counts kind clusters already running.
 - **`/out/bin`** — the image's `OUT_BIN`. Whatever you mount here is where the
   four binaries land.
-- **`HOST_UID` / `HOST_GID`** — the wizard runs as root so it can reach that
+- **`HOST_UID` / `HOST_GID`** — the installer runs as root so it can reach that
   socket, which means everything it writes into a mounted volume is root-owned
   and useless to you. These drive the `chown` back. Omit them and the install
   looks like it worked.
@@ -131,18 +130,18 @@ None of the four arguments are guessable, so:
 tooling — which is the right answer on a managed or corporate-issued machine and
 is why the split exists.
 
-Then put them on PATH, which the wizard will remind you about because it cannot
+Then put them on PATH, which the installer will remind you about because it cannot
 edit your shell for you:
 
 ```bash
 export PATH="$HOME/.local/bin:$PATH"     # and add the same line to ~/.bashrc
 ```
 
-If something else on this machine already provides `kubectl`, the wizard says so
+If something else on this machine already provides `kubectl`, the installer says so
 by name rather than shadowing it quietly. `OUT_BIN=$PWD/def/bin` installs
 somewhere private instead.
 
-**Two variants worth knowing before you need them.** `make wizard full` bakes
+**Two variants worth knowing before you need them.** `make deps-image full` bakes
 every pinned binary into the image at build time (`DEPS_SOURCE=baked`), so
 `docker save` gives you the entire installer as one file to carry into an
 air-gapped network. And `DEPS_SOURCE=artifactory` with `DEPS_ARTIFACTORY_URL`