clean rig

rig/docs/index.html

@@ -267,7 +267,7 @@
 <pre><code><span class="c"># then, in the environment directory:</span>
 make check     <span class="c"># is this machine ready? reports, never fixes</span>
 make deps        <span class="c"># install the pinned toolchain</span>
-make cluster up  <span class="c"># build the cluster for the active profile</span>
+make cluster up  <span class="c"># cluster + registry + addons; ports derive by themselves</span>
 </code></pre>
       <p>Read <code>make check</code> before <code>make deps</code>. It never changes
       anything — it prints what it found and, at the end, the steps it cannot perform
@@ -288,20 +288,14 @@ make cluster up  <span class="c"># build the cluster for the active profile</spa
       one failure at a time.</p>
 <pre><code>make check</code></pre>
 
-      <h3>2 &middot; make setup</h3>
-      <p>Does the preparation that can be automated: installs the pinned
-      toolchain if it is missing, checks PATH, Docker, and this environment's
-      ports. Every step is independently checked, so running it twice is safe and
-      running it half-configured finishes the job.</p>
-      <p>It <b>does not stop at the first failure</b>. A setup script that dies at
-      step two hides that steps four and five would also have failed, and on an
-      unfamiliar machine the complete list is the point. The tail of the output is
-      a to-do list of only what is outstanding.</p>
-<pre><code>make setup                  <span class="c"># host + toolchain</span>
-</code></pre>
+      <h3>2 &middot; make deps</h3>
+      <p>Installs the pinned toolchain — only what is missing — and tells you
+      if its directory is not on PATH yet. Running it twice is safe.</p>
+<pre><code>make deps</code></pre>
 
       <h3>3 &middot; make cluster up</h3>
-      <p>Builds the cluster for the active profile. It prints what the profile
+      <p>Builds the cluster, starts its registry and installs the profile's
+      addons — there is nothing else to run first. It prints what the profile
       locks in <i>before</i> spending the time, because the kind config is
       fixed at creation and cannot be changed afterwards.</p>
       <p>Re-running is safe and, more importantly, <b>convergent</b>: if a first
@@ -322,17 +316,17 @@ make cluster reset              <span class="c"># destroy and rebuild — how an
       <h3>Checking on things</h3>
       <dl>
         <dt>make cluster list</dt><dd>Every cluster on the machine, its memory cost and its port block. The usual reason a new one will not start is an old one you forgot about; <code>make cluster free</code> frees them without deleting.</dd>
-        <dt>make ports</dt><dd>This environment's port block, and whether each is derived or overridden.</dd>
-        <dt>make registry</dt><dd>Which of the four registry modes is active, and where it points.</dd>
+        <dt>make check</dt><dd>Also this environment's port block, its registry and the profile's addons.</dd>
+        <dt>make check mem</dt><dd>Memory in depth: what caps it, how far it really climbs, and on WSL the <code>.wslconfig</code> backup and restore.</dd>
       </dl>
 
       <h3>Running more than one</h3>
-      <p>Copy the directory, rename it, and repeat from step 2. Cluster name,
+      <p>Copy the directory, rename it, and run <code>make cluster up</code>. Cluster name,
       context, image tags and the port block all follow the directory name, so
       the second environment collides with nothing and neither one's teardown can
       reach the other.</p>
 <pre><code>cp -r rig ../platform-v2 &amp;&amp; cd ../platform-v2
-make setup &amp;&amp; make cluster up
+make cluster up
 </code></pre>
     </div>
   </section>
@@ -370,16 +364,15 @@ make setup &amp;&amp; make cluster up
       </table>
 <pre><code>make deps core   <span class="c"># kubectl and jq only — nothing that creates a cluster</span>
 make deps        <span class="c"># dev, the default</span>
-make setup core  <span class="c"># same distinction, via setup</span>
 </code></pre>
       <p>Testing <i>in situ</i> on a managed machine is still possible — install
       the <code>dev</code> tier deliberately when you need it. The point is that
-      it should be a decision rather than a side effect of running setup.</p>
+      it should be a decision rather than a side effect of installing.</p>
       <p>The documentation itself needs neither tier: <code>make docs</code>
       wants only Docker.</p>
 
       <h3>Air-gapped</h3>
-<pre><code>make deps-image full                       <span class="c"># bakes every binary into the image</span>
+<pre><code>make deps image full                       <span class="c"># bakes every binary into the image</span>
 docker save …-deps:full | gzip &gt; rig.tgz
 <span class="c"># carry that one file in, then:</span>
 docker load &lt; rig.tgz &amp;&amp; make cluster up PROFILE=offline   <span class="c"># from env.d/offline.env.example</span>
@@ -403,8 +396,8 @@ docker load &lt; rig.tgz &amp;&amp; make cluster up PROFILE=offline   <span clas
         <dt>registry + images</dt><dd>Named after the environment, so two copies never share one.</dd>
       </dl>
       <p>Two copies therefore never collide, and neither one's
-      <code>make cluster down</code> can touch the other. <code>make ports</code>
-      shows the block; <code>make ports persist</code> freezes it into
+      <code>make cluster down</code> can touch the other. <code>make check</code>
+      shows the block; <code>bash ctrl/ports.sh persist</code> freezes it into
       <code>ctrl/.env</code> if you want it fixed rather than derived.</p>
 
       <h3>Configuration layers</h3>