deploy.

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

@@ -131,7 +131,7 @@ is placeable anywhere, and <a href="building-a-mission.html">Building a Mission<
 <td>5</td>
 <td><strong>Record Meshed Geometry</strong></td>
 <td>Output</td>
-<td><code>Cache/&lt;stage&gt;-init.wct</code> — the stock, meshed once; drop this row where the stock is already a recorded mesh</td>
+<td><code>Cache/&lt;stage&gt;-init.wct</code> — the stock, meshed once. Keep this row whenever the stock is an STL; drop it where the stock is procedural, or is already a recorded mesh (<a href="#the-stage-0-cache-goes-stale-silently">which, and why</a>)</td>
 </tr>
 <tr>
 <td>6</td>
@@ -234,12 +234,49 @@ what the run starts from — so <strong>changing the workpiece geometry, its ini
 Machining Resolution has no effect until the cache is cleared.</strong> Nothing warns you: the run simply
 reproduces the previous one. After changing any of those three, Reset the stage-0 record (or delete
 its file) before reading anything into the result.</p>
-<p><strong>Give a stage a stage-0 record only when the stock costs real time to mesh</strong> — a large mesh or a
-solid the kernel has to build. Where a stage's stock is itself a recorded mesh, as it is for the
-second operation in a chained pair, a stage-0 record buys no time at all and freezes the chain: the
-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>
+<p><strong>Give a stage a stage-0 record when the stock costs real time to mesh, and not otherwise.</strong> The
+test is what the workpiece's initial geometry actually is:</p>
+<table>
+<thead>
+<tr>
+<th>Stock geometry</th>
+<th>Stage-0 record</th>
+<th>Why</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td><strong>An STL of any size that is not trivial</strong> — a CAD export, a scanned blank, anything with more than a few thousand triangles</td>
+<td><strong>Yes</strong></td>
+<td>meshing it is a fixed, single-threaded cost paid on every play, and it does not shrink with a shorter program</td>
+</tr>
+<tr>
+<td>A box, a cylindroid, or another procedural solid</td>
+<td>No</td>
+<td>the kernel builds it in moments; the record would cost more than it saves</td>
+</tr>
+<tr>
+<td>A mesh recorded by an earlier stage</td>
+<td><strong>No</strong> — see below</td>
+<td>it is already a cache</td>
+</tr>
+</tbody>
+</table>
+<p>The first row is the case worth spelling out, because the cost does not look like it belongs to the
+geometry. A stock STL is meshed into the cube tree when the first program plays, so the time lands
+inside the run and reads as if the NC were slow. It is not: it is a constant. One measured example
+is a 8.9 MB stock STL whose mesh build was <strong>168 s of every play, unchanged when the program was
+swapped for a 4.8 KB one</strong> — on a 193 s run, 168 s of it was the stock. Recording that mesh once
+turns the second and every later play into a file read of a few hundredths of a second.</p>
+<p>The cost climbs steeply with triangle count, so the finer the tessellation the more a stage-0 record
+is worth: a 1.17-million-triangle stock at 0.125 mm had still not finished meshing after 268 s.</p>
+<p>Where a stage's stock is itself a recorded mesh, as it is for the second operation in a chained
+pair, a stage-0 record buys no time at all and freezes the chain: the 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>
+<p>One thing the record does not do is make a stock that the kernel cannot mesh meshable. The record
+writes what the build produced; if the build itself fails, there is nothing to write, and the
+mission fails in the same place on every run.</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