deploy.

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

@@ -217,6 +217,14 @@ result.</li>
 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>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>
@@ -232,6 +240,26 @@ second operation in a chained pair, a stage-0 record buys no time at all and fre
 upstream stage can be re-run all it likes and this one keeps reading the copy it took the first
 time. There, the previous stage's own end-of-stage file is already the cache, and the stage needs
 no record above its program.</p>
+<h2 id="resuming-then-cutting-finer">Resuming, then cutting finer</h2>
+<p>A record freezes the workpiece <strong>as meshed at the width in force when it ran</strong>. Reading one back
+does not pin the rest of the run to that width: put a finer Machining Resolution below the record
+and above the next program, and that program's removal is built at the finer width. Measured on a
+roughing stage recorded at 0.5 mm — read back, then cut at 0.0625 mm — the cut ran at 0.0625 mm and
+took 779 s where the same program at 0.5 mm took 27 s, for five times the mesh's own memory. The
+request binds; the record is not a ceiling, and at this end of the ladder it is not free either.</p>
+<p>What reading back cannot do is add detail that was never stored. Surfaces inherited from the record
+keep the width they were recorded at; only what the later program cuts is meshed finer. That is
+normally exactly right — the roughed surface is about to be cut away, and the finish surface is the
+one the fine mesh is for.</p>
+<p>So <strong>record each stage at the width that stage needs — with one exception: the stage the finishing
+pass reads from.</strong> Everything the finishing tool does not touch keeps that record's width, and that
+includes the surface the finish is measured against. Choose that one record's width against the
+finish, then, rather than against the roughing stage it happens to belong to.</p>
+<p>The earlier stages have no such constraint. Roughing at the finishing width to be safe buys nothing
+and costs the whole roughing run at the finishing price.</p>
+<p>This is a different thing from the stage-0 trap above, which is about the record above a program
+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

App/wwwroot/HiAPI-docsite/manual/run/playing-a-program.html

@@ -222,6 +222,7 @@ to what the mission asked for — see <a href="the-program-branch.html">The Prog
 <li><a href="the-program-branch.html">The Program Branch</a> — what the run recorded against each line</li>
 <li><a href="the-other-commands.html">The Other Commands</a> — the rest of the command kinds, including the script that drives a session without NC</li>
 <li><a class="xref" href="../../anatomy/execution/mission/NcFileCommand-panel.html">NcFileCommand Panel</a> — the component behind Program File: its fields, its picker and the endpoints behind the banner</li>
+<li><a href="a-mission-that-resumes.html">A Mission That Resumes</a> — the layout these two commands sit in when the run has to be restartable</li>
 <li><a class="xref" href="../../anatomy/execution/mission/NcCodeCommand-panel.html">NcCodeCommand Panel</a> — the component behind NC Code: its editor, its stats row and how it saves</li>
 </ul>
 

App/wwwroot/HiAPI-docsite/manual/run/running-a-simulation.html

@@ -226,6 +226,7 @@ Pause with <kbd>F6</kbd> first.</p>
 <li><a href="inspecting-a-step.html">Inspecting a Step</a> — the column that reads whichever step you stopped on</li>
 <li><a href="when-something-goes-wrong.html">When Something Goes Wrong</a> — what to read when the run does not do what you expected</li>
 <li><a href="../basics/the-app-window.html">The Application Window</a> — the menu bar's connection badge, and the footer this page's state is reported in</li>
+<li><a href="a-mission-that-resumes.html">A Mission That Resumes</a> — how to lay the mission out so a stopped run restarts from where it got to</li>
 <li><a class="xref" href="../../anatomy/execution/execution-tool-bar.html">Execution Tool Bar</a> — the component behind these buttons: the enable rules, the status feed and the key bindings</li>
 </ul>