@@ -51,8 +51,10 @@ <h1>Phase 1 runbook: the one session that needs a human</h1>
 <p><span class="pill pill-good">Already staged</span> Two things are done so you do not wait on them:</p>
 <ul>
 <li><strong><code>m1n1.bin</code> is on the mini</strong> at <code>~/m1n1-stage/m1n1.bin</code> &mdash; built from <code>main</code> at <code>169f73b</code>, 1,114,112 bytes, SHA-256 <code>68f61c7b&hellip;41a6043</code>. Verify it before use; it must be reachable from 1TR.</li>
-<li><strong>The matching macOS installer is downloading</strong> to <code>/Applications</code> on the mini &mdash; 26.6.2 (25G83), an exact match for the running build, which is what <a href="nextbsd-m4-boot-footprint-plan.html">the footprint subplan</a> calls for.</li>
+<li><strong>The matching macOS installer</strong> is fetched to <code>/Applications</code> on the mini &mdash; 26.6.2 (25G83), an exact match for the running build. Matching matters: a shared Recovery volume tracks the newest volume group, and an older APFS driver should never touch a newer container.</li>
+<li><strong>The target volume exists.</strong> <code>disk3s7</code>, named <code>NextBSDBoot</code>, created with <code>diskutil apfs addVolume</code> &mdash; additive, reversible, and it touched nothing existing. <code>Macintosh&nbsp;HD</code> is exactly as it was.</li>
 </ul>
+<p>So Step&nbsp;1 below reduces to one command, and Steps&nbsp;4&ndash;6 are the only part that needs you at the machine.</p>
 </div>
 
 <div class="callout callout-bad">
@@ -92,17 +94,20 @@ <h2>Step 1 &mdash; a second volume group</h2>
 <div class="step">
 <span class="where">on the mini, normal macOS</span>
 
-<p>Add a volume to the <em>existing</em> container. No repartition, no resize, no GPT rewrite &mdash; that is the whole point of <a href="nextbsd-m4-boot-footprint-plan.html">Route&nbsp;B</a>.</p>
+<p><span class="pill pill-good">staged</span> The volume is already there &mdash; added to the <em>existing</em> container, so no repartition, no resize, no GPT rewrite. That is the whole point of <a href="nextbsd-m4-boot-footprint-plan.html">Route&nbsp;B</a>. Confirm it:</p>
 
-<pre><code>diskutil apfs addVolume disk3 APFS NextBSDBoot
-diskutil list disk3</code></pre>
+<pre><code>diskutil list disk3        # expect: 7:  APFS Volume NextBSDBoot</code></pre>
 
-<p>Then install macOS onto it. The installer is what turns a bare volume into a <em>volume group</em> (System + Data), which is the thing that gets a LocalPolicy:</p>
+<p>Now install macOS onto it. The installer is what turns a bare volume into a <em>volume group</em> (System + Data), which is the thing that gets a LocalPolicy:</p>
 
 <pre><code>sudo "/Applications/Install macOS Tahoe.app/Contents/Resources/startosinstall" \
      --volume /Volumes/NextBSDBoot --agreetokeeplicense</code></pre>
 
-<p>This reboots the mini one or more times and takes a while. It is an ordinary macOS install; nothing about it is unusual or risky, and <code>Macintosh&nbsp;HD</code> is not touched.</p>
+<p>This reboots the mini one or more times and takes roughly half an hour. It is an ordinary macOS install &mdash; nothing about it is unusual or risky, and <code>Macintosh&nbsp;HD</code> is not touched.</p>
+
+<div class="callout callout-warn">
+<p><span class="pill pill-warn">Why this step was left for you</span> It could have been run unattended overnight, and deliberately was not. <code>startosinstall</code> reboots into the new system and stops at Setup Assistant, which needs a human regardless &mdash; so it cannot finish on its own, and running it would have taken SSH access to the mini away for the rest of the night in exchange for about half an hour of your time. The download, which is pure waiting, was done instead.</p>
+</div>
 
 <p><span class="pill pill-neutral">Budget</span> ~25&ndash;30&nbsp;GB against 164.3&nbsp;GB free.</p>