deploy.

App/wwwroot/HiAPI-docsite/manual/run/a-mission-that-resumes.html

@@ -140,7 +140,7 @@ mechanics.</p>
 <td>6</td>
 <td><strong>Program File</strong></td>
 <td>Program</td>
-<td>the stage</td>
+<td>the stage's program — one control file, whole</td>
 </tr>
 <tr>
 <td>7</td>
@@ -158,16 +158,26 @@ mechanics.</p>
 </table>
 <p>Every entry keeps its own checkbox, so any of them can be switched off without being deleted and
 without its settings being lost.</p>
+<p><strong>A stage is rows 5–7 wrapped in a List command.</strong> List is the one command in the Flow category
+of Add Command; give it the stage's name and its row reads <code>List [Roughing]</code>, with the record,
+the Program File and the closing record as its rows one level down. The Setup rows stay loose
+above the first stage and Post-Execution loose below the last. The List row carries a checkbox of
+its own, and clearing it greys every row inside and skips the whole group — that checkbox is
+what the re-running section below turns on and off.
+<a href="building-a-mission.html#group-with-a-list">Group with a list</a> is how the group is made, titled
+and moved.</p>
 <h2 id="why-commands-rather-than-one-script">Why commands rather than one script</h2>
 <p>A script sets the same values, and that is the whole of its advantage. Against it:</p>
 <ul>
 <li><strong>A row states its value.</strong> <code>Machining Resolution [0.125 mm]</code>, <code>Physics [On]</code>,
 <code>Program File [NC/facing.ptp]</code> — the mission is legible without opening anything.</li>
 <li><strong>A checkbox replaces commenting-out.</strong> A commented line is invisible in the tree and survives
-into the saved project as text nobody reads. A cleared checkbox greys the row and says so.</li>
+into the saved project as text nobody reads. A cleared checkbox greys the row, and the command's
+editor below the tree says so.</li>
 <li><strong>The fields are typed.</strong> A resolution is a number field with a unit, not a line that has to
 compile.</li>
-<li><strong>The order is the run.</strong> Moving a setting above or below a program is a drag, not an edit.</li>
+<li><strong>The order is the run.</strong> Moving a setting above or below a program is a drag of its row in the
+Control Tree's <strong>Mission</strong> branch, not an edit.</li>
 </ul>
 <p>Leave in the Script only what no command covers, and title it for what it is.</p>
 <h2 id="resolution-before-the-first-record">Resolution before the first record</h2>
@@ -216,18 +226,19 @@ writes the result.</li>
 <li><strong>Every run after.</strong> Entry 5 finds its file and nothing has played, so it <strong>reads</strong> — the stock is
 not re-meshed. The program plays, so by entry 7 something has played, and it <strong>writes</strong> the fresh
 result.</li>
-<li><strong>Re-running one stage.</strong> Clear the checkbox on the stages you do not want. The first record entry
-that is still ticked becomes the first thing to run, so it reads its cache, and the run picks up
-from there.</li>
+<li><strong>Re-running one stage.</strong> Clear the checkbox on the <strong>List</strong> row of each stage you do not want.
+The first record entry that is still ticked becomes the first thing to run, so it reads its
+cache, and the run picks up from there.</li>
 </ul>
-<p><strong>Clearing a stage clears everything in it, including its record.</strong> A stage is a checkbox around a
-list, and a cleared one is skipped whole — so in a chain where the cache a stage resumes from is the
-<em>previous</em> stage's end-of-stage record, clearing that previous stage removes the very entry that
-would have loaded it. The run then starts from the stock, quietly and without an error. Either leave
-the earlier stages ticked and clear only the Program File rows inside them, or clear them but keep
-the one stage whose end-of-stage record you are resuming from, with its own programs cleared. The
-rule is simply that <strong>the record you are resuming from has to be reachable</strong>: every checkbox above
-it stays ticked.</p>
+<p><strong>Clearing a stage clears everything in it, including its record.</strong> A stage is a List row with its
+entries beneath it; clear that row's checkbox and every entry inside greys with it and the group is
+skipped whole — so in a chain where the cache a stage resumes from is the <em>previous</em> stage's
+end-of-stage record, clearing that previous stage removes the very entry that would have loaded
+it. The run then starts from the stock, quietly and without an error. Either leave the earlier
+stages ticked and clear only the Program File rows inside them, or clear them but keep the one
+stage whose end-of-stage record you are resuming from, with its own programs cleared. The rule is
+simply that <strong>the record you are resuming from has to be reachable</strong>: every checkbox above it
+stays ticked.</p>
 <p>That last line is the point of the layout. The cost of getting back to the middle of a long job is
 one file read.</p>
 <h2 id="the-stage-0-cache-goes-stale-silently">The stage-0 cache goes stale, silently</h2>
@@ -301,9 +312,10 @@ and costs the whole roughing run at the finishing price.</p>
 caching the <em>stock</em>: there the frozen mesh is what the run starts from, so the resolution really is
 stuck until the file is cleared.</p>
 <h2 id="one-record-per-stage">One record per stage</h2>
-<p>A mission with several Program File entries gets a record after each, plus the stage-0 record where
-that one earns its place. Name each file after the stage it ends, not after the program that wrote
-it, so the file that a stage <em>reads</em> is the one named for the stage before it.</p>
+<p>A mission with several stages — one List per stage, each with its Program File — gets a record
+after each, plus the stage-0 record where that one earns its place. Name each file after the
+stage it ends, not after the program that wrote it, so the file that a stage <em>reads</em> is the one
+named for the stage before it.</p>
 <p>Do not split one control file into several Program File entries to get finer stages. A program's
 modal state — units, plane, work offset, absolute or incremental — is established in its header and
 carried forward; cutting it in half hands the second half to a runner that never saw the header. The