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