deploy.

App/wwwroot/HiAPI-docsite/manual/basics/finding-your-way.html

@@ -166,7 +166,8 @@ one, and it reveals nothing without a project open. In practice that means the t
 on that address: pasting the link into a new tab, reloading on it, or opening General Setup for the
 first time since the page or the project was loaded. Jumping to it from a screen that has already
 shown General Setup for the current project does not rebuild that tree, so the address is dropped
-in silence with the selection left where it was.</p>
+in silence: the address bar keeps the value, the node does not appear, and the selection stays
+where it was.</p>
 </div>
 <p>The same page at <code>/general-setup?tree=equipment/controller-csv</code>, loaded fresh on that address with
 the CSV Controller preference still off — the address alone is what puts the node in the tree.

App/wwwroot/HiAPI-docsite/manual/basics/messages-and-logs.html

@@ -152,8 +152,11 @@ last showed stays on the bar after the run has ended; a project change is what e
 takes the strip away with it. A cursor line carries <code>Sn</code> and the sentence index it sits on; a
 message line carries whatever anchor the message supplies. Two limits are worth knowing: the strip
 mirrors the newest message across three of the four lists — nothing from <strong>NC Manipulation</strong> reaches
-it — and it is sampled rather than recorded, so messages arriving faster than it refreshes never
-appear on it at all. The lists on the service drop nothing.</p>
+it — and it is sampled rather than recorded. There is no refresh interval to tune: the service
+sends the newest message and, while that send is still on its way to the browsers, keeps only the
+newest of whatever arrives behind it, so a message that lands inside that window is replaced before
+it was ever sent and never appears on the strip at all. The cursor line is thinned the same way
+under a fast run. The lists on the service drop nothing.</p>
 <h2 id="the-session-message-panel">The session message panel</h2>
 <p>The panel sits on the Execution page, in the middle column, below the 3D Rendering Canvas. Its
 header row reads <strong>Session Messages</strong> and stays visible when the panel is collapsed, so a grey strip
@@ -205,9 +208,9 @@ behind its one line carries a chevron; clicking it opens what the message brough
 a <strong>Reset</strong>. The badge at the right of that toolbar reads two numbers separated by a slash, and they
 count different things — rows currently shown on the left, raw messages on the right, so folding
 alone makes them differ, and on a long session the left number stops at the most recent thousand
-while the right goes on counting. That badge is also the tab's connection indicator: it is outlined
-green only while the connection behind that list is up, and its tooltip names the state. <strong>Export</strong>
-writes the tab's filtered rows to a CSV file.</p>
+rows while the right goes on counting. That badge is also the tab's connection indicator: it is
+outlined green only while the connection behind that list is up, and its tooltip names the state.
+<strong>Export</strong> writes the tab's filtered rows to a CSV file.</p>
 <div class="IMPORTANT">
 <h5>Important</h5>
 <p>Two different controls on this screen answer to <strong>Reset</strong>, and only one of them is labelled with
@@ -249,7 +252,9 @@ file for today.</em>, and both hide the line count entirely — no count is draw
 reading zero, so the caption simply being absent is itself the signal that nothing came back. The
 day badge is what separates them: when the file exists, the day comes from the service's own clock;
 when there is no file at all, it comes from the browser's clock in UTC, which need not name the same
-day.</p>
+day — before eight in the morning in Taipei it names the day before. The service itself never
+leaves the file empty: the day's file comes into being with its first line already in it, so an
+empty file is one that something outside the service emptied.</p>
 <p>A fetch that fails replaces the pane with the reason and a <strong>Retry</strong> button, and posts the reason to
 the footer under the viewer's own name — one of the few lines that reaches the footer without ever
 having been a toast.</p>

App/wwwroot/HiAPI-docsite/manual/basics/projects.html

@@ -217,10 +217,11 @@ underneath — so a Save from any of them writes to the new path. A stale row co
 time the service reports its state to that browser: a reload, the browser's status connection
 dropping and coming back, another project change, or a run being started, paused, finished or reset
 from any browser.</p>
-<p>New, Load, ReLoad, Save and Save As take a turn each. A second one asked for while the first is still
-running is refused rather than queued, and the refusal arrives as a warning reading <em>Another project
-operation is in progress. Please try again.</em> Close Project takes no part in that turn-taking: it
-neither waits for a running operation nor holds one off, and it never raises the warning.</p>
+<p>New, Load, ReLoad, Save, Save As and Close Project take a turn each. A second one asked for while the
+first is still running is refused rather than queued, and the refusal arrives as a warning reading
+<em>Another project operation is in progress. Please try again.</em> Close Project holds the turn like the
+other five: a Close asked for while a Load is still reading is refused, and so is a Load asked for
+while a Close is still tearing the project down.</p>
 <h2 id="losing-work">Losing work</h2>
 <p>Nothing keeps track of whether the open project has unsaved changes. No marker in the menu bar or in
 the path row says the project has been edited, there is no prompt in front of <strong>ReLoad</strong> or <strong>Close

App/wwwroot/HiAPI-docsite/manual/basics/the-app-window.html

@@ -152,10 +152,12 @@ the file is read again on the service, but the screens keep what they were showi
 entry to use for that, and it is the one that always rebuilds.</p>
 <p>The same rebuild runs once at startup, with nobody having done anything: a browser reaching a service
 that already has a project open receives that path as its first project change and builds on it.</p>
-<p><strong>New</strong>, <strong>Load</strong>, <strong>ReLoad</strong>, <strong>Save</strong> and <strong>Save As</strong> run one at a time. A second one started while
-the first is still running is refused rather than queued, and the refusal arrives as a warning reading
-<strong>Another project operation is in progress. Please try again.</strong> Nothing is rebuilt and nothing is
-lost. <strong>Close Project</strong> takes no part in that turn-taking and never raises the warning.</p>
+<p><strong>New</strong>, <strong>Load</strong>, <strong>ReLoad</strong>, <strong>Save</strong>, <strong>Save As</strong> and <strong>Close Project</strong> run one at a time. A
+second one started while the first is still running is refused rather than queued, and the refusal
+arrives as a warning reading <strong>Another project operation is in progress. Please try again.</strong> Nothing
+is rebuilt and nothing is lost. The turn is held for the whole of the operation, so a Close asked for
+while a Load is still reading is refused the same way, and so is a Load asked for while a Close is
+still tearing the project down.</p>
 <h2 id="the-footer">The footer</h2>
 <p>A 29-pixel strip holding three regions, each independent of the other two.</p>
 <p><strong>Left — the latest reported line, with the recent ones behind it.</strong> The text is the most recent

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

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

@@ -92,10 +92,14 @@ what plays is exactly what the list says — including which entries are ticked
 <h2 id="where-it-is">Where it is</h2>
 <p>The Execution page at <code>/execution</code>, <strong>Mission</strong> branch of the Control Tree; <code>/mission</code> lands on the
 same place. This is the page the application opens on.</p>
-<p>The branch root is the list editor: it is where the list is assembled and rearranged. A command's
-own settings are edited one level in, on that command's node.</p>
+<p>The list is assembled and rearranged on the tree rows themselves: the <strong>Mission</strong> row and every
+<strong>List</strong> row carry a <strong>+</strong> that adds a command, and every command row carries a drag handle in
+front of its label and its own move, duplicate and delete buttons. The <strong>Mission</strong> node's panel
+below the tree is informational — the command count and a hint naming those affordances. A
+command's own settings are edited one level in, on that command's node.</p>
 <h2 id="add-a-command">Add a command</h2>
-<p><strong>Add Command</strong> opens a search-first picker. Type to narrow it: the search matches a command's
+<p>The <strong>+</strong> pinned to the right edge of the <strong>Mission</strong> row, or of any <strong>List</strong> row, is <strong>Add
+Command</strong>; it opens a search-first picker. Type to narrow it: the search matches a command's
 display name, its internal kind key and the aliases it declares, and an alias matches both by its
 English key and by its word in the interface language. Arrow keys walk the results and
 <kbd>Enter</kbd> takes the highlighted one.</p>
@@ -130,17 +134,25 @@ English key and by its word in the interface language. Arrow keys walk the resul
 </tr>
 </tbody>
 </table>
-<p>What you pick is appended to the <strong>end</strong> of the list you added it to, and the selection stays on the
-list rather than jumping into the new command. Nothing is pinned to a position: the order is
-entirely yours, and every command is placeable anywhere.</p>
-<p><strong>Add Command is disabled until a project is open.</strong> With nothing open the list reads <em>No project
-loaded</em>; with a project and an empty mission it reads <em>No commands yet</em> and names the button.</p>
+<p>What you pick lands in the list whose <strong>+</strong> you pressed, <strong>directly after the focused command</strong> when
+that command is an entry of the same list, and at the list's end otherwise. The focus is the
+selected command — or, while the selection sits on one of a command's child nodes, the command that
+owns it — or the command the last add created; and when a move, duplicate, delete or drag carries
+the selection to another row, the focus follows it there. So a run of adds lands in order below the
+focus, and the <strong>Mission</strong> row's <strong>+</strong> always adds at root level even while a command inside a
+group is selected. The new row is revealed in the tree, but the selection stays where it was rather
+than jumping into the new command. Nothing is pinned to a position: the order is entirely yours, and
+every command is placeable anywhere.</p>
+<p><strong>Add Command is disabled until a project is open.</strong> With nothing open the <strong>Mission</strong> panel reads
+<em>No project loaded. Open or create a project first.</em> With a project and an empty mission it reads
+<em>No commands yet</em> and names the button.</p>
 <p>The set on offer is served by the application rather than built into the interface, so a command
 kind can appear in this dialog before this manual has a page for it.</p>
-<p>The picker over the demo mission, at <code>/execution?tree=execution/mission</code> with <strong>Add Command</strong>
-pressed. The five category headings are the grouping in the table above, the search box at the top
-is what narrows them, and the first result is highlighted ready for <kbd>Enter</kbd>.</p>
-<p><img src="building-a-mission-img/add-command.en.png" alt="The Add Command dialog open over the Execution page: a Search commands box above thirteen entries under five headings — Setup with Machining Resolution, Machining Motion Resolution, Collision Detection, Pause on Failure and Physics; Program with Program File, NC Code and Script; Optimization with NC Optimization Config; Output with Post-Execution, Record Meshed Geometry and Export Meshed Geometry STL; and Flow with List"></p>
+<p>The picker over the demo mission, at <code>/execution?tree=execution/mission</code> with the <strong>Mission</strong>
+row's <strong>+</strong> pressed. The five category headings are the grouping in the table above, the search
+box at the top is what narrows them, and the first result is highlighted ready for
+<kbd>Enter</kbd>.</p>
+<p><img src="building-a-mission-img/add-command.en.png" alt="The Add Command dialog open over the Execution page, in front of the Control Tree whose Mission row carries a + at its right edge and whose transport buttons and green ready badge show above it: a Search commands box above thirteen entries, each with its kind icon, under five headings — Setup with Machining Resolution highlighted, Machining Motion Resolution, Collision Detection, Pause on Failure and Physics; Program with Program File, NC Code and Script; Optimization with NC Optimization Config; Output with Post-Execution, Record Meshed Geometry and Export Meshed Geometry STL; and Flow with List"></p>
 <h2 id="the-shape-to-start-from">The shape to start from</h2>
 <p>An empty list is legal, but it is not where a project should end up. A finished mission has the
 same shape whatever it machines: <strong>setup at the top, the program in the middle, the program held
@@ -189,38 +201,61 @@ play; a box the kernel builds instantly, and caching it costs more than it saves
 <p><a href="a-mission-that-resumes.html">A Mission That Resumes</a> is this layout in full, with the reasoning and
 the measurements behind each row.</p>
 <h2 id="read-a-row">Read a row</h2>
-<p>Each row shows the command's kind followed by the detail that identifies it, in brackets. Where you
-can name a command that detail is the title you typed, so a row still says what it is after it has
-been named: <code>List [Roughing]</code>, <code>NC Code [Inline finishing pass]</code>. Where you cannot, the command brackets what
-it holds instead — <code>Program File [NC/circle.ptp]</code>, <code>Machining Resolution [1 mm]</code>,
-<code>Collision Detection [On]</code> — so a mission is readable without opening anything.</p>
-<p>Beside the label sit four buttons — <strong>up</strong>, <strong>down</strong>, <strong>duplicate</strong> and <strong>delete</strong>. Up and down are
-disabled at the ends of the list. Delete asks first, in a dialog naming the command. Duplicate is a
-deep copy: a group copies with everything inside it, and the copy lands directly after the original.</p>
-<p>Clicking a row anywhere but on a button selects that command's node and opens its editor.</p>
+<p>Each row shows the command's kind and, where one detail identifies the command, that detail after
+it in brackets. Where you can name a command that detail is the title you typed, so a row still says
+what it is after it has been named: <code>List [Roughing]</code>, <code>NC Code [Inline finishing pass]</code> — and
+while the title is empty the row is the bare kind, <code>NC Code</code> or <code>Script</code>. Where you cannot, the
+command brackets what it holds instead — <code>Program File [NC/circle.ptp]</code>,
+<code>Machining Resolution [1 mm]</code>, <code>Collision Detection [On]</code> — so a mission is readable without
+opening anything. Two kinds have no single detail to show and read as their kind alone:
+<code>NC Optimization Config</code> and <code>Post-Execution</code>, whose settings are the child nodes beneath the row
+rather than one value.</p>
+<p>Every command row carries four buttons — <strong>Move up</strong>, <strong>Move down</strong>, <strong>Duplicate</strong> and <strong>Delete</strong> —
+revealed while the pointer is over the row or while the row is selected, and always shown on a
+touch screen. Up and down are disabled at the ends of the list. Delete asks for confirmation, in a
+dialog naming the command. Duplicate is a deep copy: a group copies with everything inside it, and
+the copy lands directly after the original. The selection follows the operation when it sits on
+the acted-on row <strong>or anywhere beneath it</strong>: on an entry inside a group when you act on the group's
+row, or on a child node when you act on its command's row. It then lands on the acted-on row itself
+— the row at its new position, the copy, or the nearest survivor of a delete (the list itself, once
+it is empty) — so an editor you were in beneath that row is replaced by the row's own panel. Acting
+on a row the selection is neither on nor under leaves the selection, and the editor you are in,
+where they are.</p>
+<p>Before a row operation writes anything — for a delete, only after you have confirmed it — it
+settles whatever the open editor has not yet saved. If you cancel that prompt, the operation is
+dropped and a notice says so.</p>
+<p>Clicking a row anywhere but on its checkbox or a button selects that command and opens its editor
+below the tree.</p>
 <h2 id="tick-what-runs">Tick what runs</h2>
-<p><strong>The checkbox is on the tree item, not in the row, and it is the only thing that decides whether a
-command runs.</strong> Clearing it greys the row and the tree node; the editor stays open and fully
-editable. Clearing the box on a group greys the whole group, and the run skips the group together
-with everything nested inside it.</p>
+<p><strong>The checkbox at the front of a command row is the only thing that decides whether a command
+runs.</strong> Clearing it greys the row; the editor stays open and fully editable, with a note that the
+command is disabled. Clearing the box on a group greys the whole group, and the run skips the group
+together with everything nested inside it.</p>
 <p>Leaving a command in place with its box cleared is how you skip a step without losing its settings,
 which is what you want while you narrow down a problem.</p>
 <h2 id="group-with-a-list">Group with a list</h2>
 <p><strong>List</strong> is an ordinary command in the Flow category, and adding one grows a sub-tree: its children
-are its own entries, edited by the same list editor one level down. That nests to any depth, so a
-mission can be grouped by operation rather than left flat.</p>
-<p>A list carries an optional title, entered on its own node above the embedded editor. The row reads
-<code>List</code> while the title is empty and <code>List [title]</code> once it says something; a title of nothing but
-spaces counts as unset. The Mission root is the one list with no title field — it reads <strong>Mission</strong>.</p>
+are its own entries, rows with the same handle and buttons one level down, and its row carries its
+own <strong>+</strong>. That nests to any depth, so a mission can be grouped by operation rather than left flat.</p>
+<p>A list carries an optional title, and its node's panel holds that <em>Title (optional)</em> field alone —
+its entries are its rows in the tree — with, as on any command, the note that it is disabled above
+the field while its checkbox is cleared. The row reads <code>List</code> while the title is empty and
+<code>List [title]</code> once it says something; a title of nothing but spaces counts as unset. The Mission
+root is the one list with no title field — it reads <strong>Mission</strong>.</p>
 <p>The demo mission at <code>/execution?tree=execution/mission</code>: two groups and seven loose entries. The
-tree above shows <strong>List [Roughing]</strong> and <strong>List [Finishing]</strong> opened, with the two Program File
-entries inside each bracketing their files; the editor below shows the same nine root entries as
-rows. The greyed <strong>Program File</strong> and <strong>Post-Execution</strong> rows are entries left in place with their
-checkboxes cleared — part of the mission, and not run.</p>
-<p><img src="building-a-mission-img/grouped-mission.en.png" alt="The Mission branch of the Control Tree showing Machining Resolution 1 mm and Collision Detection On, then List Roughing expanded over Program File NC/circle.ptp and Program File NC/drill_slot.ptp, List Finishing expanded over Program File NC/side.ptp and Program File NC/slide.ptp, then Program File NC/circle.ptp, NC Code Inline finishing pass, a greyed Program File NC/slide-test-resolution-script.ptp with its checkbox cleared, NC Optimization Config and a greyed Post-Execution with its checkbox cleared; below it the list editor shows the same nine root entries under an Add Command button and a Commands badge reading 9, each row with up, down, duplicate and delete buttons, above the line reading that commands run top-down"></p>
+transport buttons and the <strong>ready</strong> badge sit at the top of the Control Tree; <strong>Mission</strong> is its
+first root, with <strong>List [Roughing]</strong> and <strong>List [Finishing]</strong> opened and the two Program File
+entries inside each bracketing their files, and the <strong>Mission</strong> row and both List rows carry a
+<strong>+</strong> at the right edge. The <strong>Program</strong> root sits collapsed beneath. The <strong>Mission</strong> panel below
+the tree reads <em>Commands 9</em> and the hint naming the row affordances. The greyed <strong>Program File</strong>
+and <strong>Post-Execution</strong> rows are entries left in place with their checkboxes cleared — part of the
+mission, and not run.</p>
+<p><img src="building-a-mission-img/grouped-mission.en.png" alt="The Control Tree on the Execution page: six transport buttons and a green ready badge above the tree; the Mission root row with a + at its right edge, then Machining Resolution 1 mm and Collision Detection On, List Roughing expanded over Program File NC/circle.ptp and Program File NC/drill_slot.ptp, List Finishing expanded over Program File NC/side.ptp and Program File NC/slide.ptp, both List rows with their own +, then Program File NC/circle.ptp, NC Code Inline finishing pass, a greyed Program File NC/slide-test-resolution-script.ptp with its checkbox cleared, NC Optimization Config with a collapsed expand arrow and a greyed Post-Execution with a collapsed expand arrow and its checkbox cleared, every command row with a checkbox and a drag handle before its label; a collapsed Program root below; under the tree the Mission panel reads Commands 9 and the hint that commands run top-down in the Control Tree, naming the + on the Mission or a List row, drag to reorder, the row's own move, duplicate and delete buttons, and the checkbox that enables or disables the command"></p>
 <h2 id="reorder-and-move-in-and-out">Reorder, and move in and out</h2>
-<p>Up and down move an entry within its own list and never change which list owns it. Dragging does
-more, and where you drop decides which:</p>
+<p>Up and down move an entry within its own list and never change which list owns it. Dragging a row
+does more — the handle in front of its label marks the row as draggable, but the whole row is the
+grip: a drag started on the handle, on the label or on the blank space beside them picks the row
+up — and where you drop decides which:</p>
 <table>
 <thead>
 <tr>
@@ -230,27 +265,35 @@ more, and where you drop decides which:</p>
 </thead>
 <tbody>
 <tr>
-<td>Another row</td>
-<td>Reorder within this list. A row splits at its midline into <em>before</em> and <em>after</em>.</td>
+<td>A command row</td>
+<td>Land <strong>before</strong> or <strong>after</strong> it — the row splits at its midline. In the same list that is a reorder; in another list, the entry moves there.</td>
 </tr>
 <tr>
 <td>The middle band of a <strong>List</strong> row</td>
-<td>Move the entry <strong>into</strong> that list. The row's outer quarters still reorder around it.</td>
+<td>Move the entry <strong>into</strong> that list, at its end. The row's outer quarters still land before or after it.</td>
 </tr>
 <tr>
-<td>The drop-out zone below a nested list's entries</td>
-<td>Move the entry <strong>out</strong>, landing directly after the list it came from.</td>
+<td>The <strong>Mission</strong> row</td>
+<td>Move the entry <strong>into</strong> the root list, at its end — the whole row is a landing.</td>
 </tr>
 </tbody>
 </table>
-<p>The drop-out zone belongs to a nested list's editor and appears only while a row inside it is being
-dragged. Moving a list into itself, or into one of its own groups, is refused.</p>
-<p>Dragging serves rearrangement only — dropping text or files on the list does nothing. To bring
-several programs in at once, use one Program File command's picker and select them together; see
+<p>While the drag is over a row, a line along the row's top or bottom edge marks <em>before</em> or <em>after</em>
+and a tinted row marks <em>into</em>. To take an entry out of a group, drop it on a row outside the group,
+or on the <strong>Mission</strong> row. Moving a list into itself, or into one of its own groups, is refused. A
+dragged command that was selected — or that held the selection somewhere beneath it, on one of its
+entries or child nodes — is selected where it lands; the selection on any other row stays on that
+row.</p>
+<p>Dragging serves rearrangement only. The tree accepts nothing but its own rows: text or a file
+dragged in from outside gets the browser's no-drop cursor over every row, and releasing it there
+hands the drop to the browser's own default rather than to the application — nothing is imported,
+and a browser typically opens a dropped file in the tab, leaving the page. To bring several
+programs in at once, use one Program File command's picker and select them together: the extra
+files become Program File commands directly after that one; see
 <a href="playing-a-program.html">Playing a Program</a>.</p>
 <h2 id="edit-one-command">Edit one command</h2>
-<p>Select a command's node. Its editor opens below a control bar carrying the same up, down, duplicate
-and delete operations the row has, and a note while the command is switched off.</p>
+<p>Select a command's row. Its editor opens in the panel below the tree — the editor alone, with a
+note while the command is switched off. Moving, duplicating and deleting stay on the row.</p>
 <p>A command with one job — Program File, NC Code, Script — puts its whole editor on that one node.
 A command with several cards spreads them: the general settings stay on the command node and each
 remaining card becomes a <strong>child node</strong> beneath it, so a long command is read by walking down the
@@ -264,7 +307,7 @@ the child node's own checkbox. Which commands do that, and what each card holds,
 <li><a href="the-other-commands.html">The Other Commands</a> — what the rest of the command kinds are for</li>
 <li><a href="a-mission-that-resumes.html">A Mission That Resumes</a> — the shape a mission should start from, in full</li>
 <li><a href="running-a-simulation.html">Starting and Stepping</a> — the transport that plays the list built here</li>
-<li><a class="xref" href="../../anatomy/execution/mission/mission-root-panel.html">Mission Root Panel</a> — the component behind this branch: the list editor, the picker and the three drag landings</li>
+<li><a class="xref" href="../../anatomy/execution/mission/mission-root-panel.html">Mission Root Panel</a> — the node behind this branch: the row operations, the picker and the three drag landings</li>
 <li><a class="xref" href="../../anatomy/execution/mission/ListCommand-panel.html">List Command Panel</a> — the component behind a group: what nesting costs, and what a disabled list skips</li>
 </ul>
 

App/wwwroot/HiAPI-docsite/manual/run/inspecting-a-step.html

@@ -147,9 +147,12 @@ reading the run.</p>
 </tr>
 </tbody>
 </table>
+<p>The two sensor charts are present only while their checkboxes on the <strong>Preference</strong> menu are ticked;
+both are off by default, so a column nobody has configured ends at Sim Spindle Moment Cycle.</p>
 <p>The group bar above them carries the step number as a badge, or <strong>No step selected</strong>. That badge is
 the only place the step index is shown — Step Properties leaves that row out rather than repeat it,
-which is why the list you configure and the list you see differ by one row.</p>
+so when S.I. is among the keys you chose, the list you configure and the list you see differ by one
+row.</p>
 <p><strong>Step Properties shows short names.</strong> Hovering a name gives the full one, and the unit follows the
 value. A field with nothing in it reads <code>-</code>.</p>
 <p><strong>CWE is a footprint, not a solid.</strong> It is a small 3D view of its own, drawing the contact contours
@@ -168,16 +171,22 @@ step</strong> while the simulated pair beside them is full.</p>
 <p>Each cycle chart's header carries a <strong>value boundary</strong> — <em>Auto</em>, or a fixed ± bound that pins the
 scale so two steps can be compared without the axis moving under you — and a reload. The two spindle
 moment charts carry one more: a <strong>Line / Dartboard</strong> switch, where Dartboard replots the same cycle
-as a locus in the plane instead of three channels against the cycle parameter.</p>
+as a locus in the plane instead of three channels against the cycle parameter. Sim Cutting Force
+Cycle carries a frame switch instead — <strong>To workpiece / program</strong> or <strong>To tool / tool-running</strong> —
+choosing whether the plotted force is the one on the workpiece, in program coordinates, or the one
+on the tool, in the tool's running coordinates.</p>
 <p><strong>Clicking a point in a cycle chart marks that point for its whole group.</strong> The two simulated charts
 share one mark in spindle angle; the two sensor charts share another in seconds. The mark survives a
-switch between Line and Dartboard and a change of selected step. It also reaches the CWE panel: the
-cutter in that view rotates to the angle you clicked, so &ldquo;the force peaked here&rdquo; and &ldquo;this is what
-the cutter was touching there&rdquo; become one picture rather than two.</p>
-<p>The column with the demo mission paused and a step selected: Sentence Syntax at the top, the step
-badge on the bar below it, then Step Properties, CWE and the two simulated cycle charts. The two sensor charts are folded away at the bottom — this project carries no measured data,
-so nothing is lost by leaving them shut.</p>
-<p><img src="inspecting-a-step-img/step-info.en.png" alt="The Execution page's Step Info column filled: a Sentence Syntax panel showing the arc block N0120 G02 I0.0 J11. above its parsed form, a group bar badged step #500, a Step Properties list reading FileNo 1, LineNo 13, FilePath NC/circle.ptp and a Time of four seconds, a CWE panel whose small 3D view draws the cutter's flute contours against an orange contact patch on the workpiece, and two cycle charts carrying X, Y and Z traces of cutting force and spindle moment across a full 0 to 360 degree spindle revolution"></p>
+switch between Line and Dartboard and a change of selected step. The simulated pair's mark also
+reaches the CWE panel: the cutter in that view rotates to the angle you clicked, so &ldquo;the force peaked
+here&rdquo; and &ldquo;this is what the cutter was touching there&rdquo; become one picture rather than two. The sensor
+pair's mark is a time, not an angle, so it stays on its own two charts and leaves the cutter where it
+is.</p>
+<p>The column with a step selected and the other three columns toggled off, so it fills the window:
+Sentence Syntax at the top, the step badge on the bar below it, then Step Properties, CWE and the two
+simulated cycle charts. The two sensor charts are absent — their checkboxes on the Preference menu
+are off, as they are by default.</p>
+<p><img src="inspecting-a-step-img/step-info.en.png" alt="The Execution page with only its Step Info column shown, filling the window: a Sentence Syntax panel badged F1 L13 · Sn 13 with a copy button, showing the arc block N0120 G02 I0.0 J11. above the opening lines of its parsed form, a Step Info group bar badged step #500, a Step Properties list reading FileNo 1, LineNo 13, FilePath NC/circle.ptp, a Time just over four seconds and the top of a LineText row, a CWE panel whose small 3D view draws a fluted cutter overlay standing on the orange contact contours, with an X axis label beside it and a 12.5 mm scale bar in the lower right, a Sim Cutting Force Cycle chart headed To workpiece / program and Auto, and a Sim Spindle Moment Cycle chart headed Line and Auto, each carrying X, Y and Z traces across a full 0 to 360 degree spindle revolution; no sensor chart is present"></p>
 <h2 id="choosing-what-step-properties-shows">Choosing what Step Properties shows</h2>
 <p>Step Properties does not show everything a step carries — it shows what you asked for, out of a much
 longer list. The small button on that panel's header opens the chooser, beside the list it
@@ -186,14 +195,15 @@ configures.</p>
 group, and <strong>Add Selected</strong> moves what you ticked across. Anything already displayed is greyed with a
 tick beside it, so the left side never offers you a duplicate. The displayed list is on the right, in
 the order it will appear: drag a row, or use its up and down buttons, and remove one row at a time or
-<strong>Clear</strong> the lot. <strong>Reset</strong> empties the list entirely.</p>
+<strong>Clear</strong> the lot. <strong>Reset</strong>, on the dialog's header, empties the list entirely; Clear and Reset each
+ask you to confirm first.</p>
 <p><strong>There is no Save button, and that is not an omission.</strong> Every add, removal and reorder is written
 as you make it, and the header reports the write — so the way to undo an experiment is to put the
 rows back, not to close the dialog.</p>
 <p>The chooser open over the column, at <code>/execution</code>. The counts in its header are this account's
-displayed list against everything the run can offer; the green ticks down the candidate side are the
-rows already on the right.</p>
-<p><img src="inspecting-a-step-img/step-present.en.png" alt="The Step Present Preference dialog open over the Execution page: a header counting displayed against available keys with Reset and close, a Candidate Keys panel on the left with collapsible categories and an Add Selected button, and a Displayed Keys panel on the right listing the chosen properties with up, down and remove buttons and a Clear action"></p>
+displayed list against every property a step can present; the green ticks down the candidate side
+are the rows already on the right.</p>
+<p><img src="inspecting-a-step-img/step-present.en.png" alt="The Step Present Preference dialog open over the Step Info column: a header reading 12 displayed / 77 available with Reset and close buttons, a Candidate Keys panel on the left with an Add Selected button and the first three of its categories open — File / Command / Flag / Time / System with 8 keys, Tool / Feedrate / Spindle Speed with 10 keys, and Coordinate / Move with 3 keys, the third cut off at the panel's bottom edge after its CL row with the remaining categories scrolled out of view below — where the rows already displayed are greyed with a green tick, and a Displayed Keys panel on the right with a Clear action and a reorder hint, listing the first eleven of the twelve chosen properties, S.I. down to MRR, with the last row scrolled out of view below the panel's edge; each row has a drag handle and up, down and remove buttons"></p>
 <h2 id="see-also">See Also</h2>
 <ul>
 <li><a href="index.html">Running a Simulation</a> — the rest of running a job</li>

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

@@ -91,8 +91,9 @@
 lives rather than what it does: <strong>Program File</strong> references a file on disk, <strong>NC Code</strong> carries the
 text inside the project.</p>
 <h2 id="where-they-are">Where they are</h2>
-<p>The Execution page's <strong>Mission</strong> branch. Both sit in the <strong>Program</strong> category of <strong>Add Command</strong>,
-and both are placed like any other command — see <a href="building-a-mission.html">Building a Mission</a>.</p>
+<p><strong>Mission</strong>, the first root of the Execution page's Control Tree. Both sit in the <strong>Program</strong>
+category of <strong>Add Command</strong>, the <strong>+</strong> on the Mission row or on a List row, and both are placed
+like any other command — see <a href="building-a-mission.html">Building a Mission</a>.</p>
 <h2 id="which-one-to-use">Which one to use</h2>
 <ul>
 <li><strong>Program File</strong> — the program stays a file, and the project stores the path. Editing the file
@@ -139,7 +140,7 @@ reached by typing its absolute path into the field instead.</p>
 </table>
 <p><strong>The picker takes more than one file.</strong> The first goes on the command you opened it from; every
 further pick becomes a <strong>new Program File command</strong> placed directly after it, in the order you
-picked them, inside the same list — including inside a group. That is the quick way to bring a
+picked them, inside the same list — including inside a nested List. That is the quick way to bring a
 folder of CAM output into a mission.</p>
 <h3 id="choose-the-reader">Choose the reader</h3>
 <p><strong>Play As</strong> decides which reader plays the file:</p>
@@ -183,17 +184,19 @@ and what its words mean is <a href="../../technique/nc-dialects/index.html">NC D
 <p>Typing saves the path as you type; the banner refreshes when you leave the field or press
 <kbd>Enter</kbd>. An orange banner is worth trusting: it means the path does not resolve on the
 machine that will play it, which is not always the machine you are typing on.</p>
-<p>The first Program File in the demo mission's <strong>Roughing</strong> group, at
-<code>/execution?tree=execution/mission/2/0</code>. The path field carries a project-relative path, <strong>Play As</strong>
-reads <em>Auto</em>, and the green banner below reports the file's size, modified time and line count with
-<strong>Preview</strong> beside it. The row and the tree label both read <code>Program File</code> followed by the path,
-which is how a mission of several programs stays readable.</p>
-<p><img src="playing-a-program-img/program-file.en.png" alt="The Program File command panel in the Control Tree dock: a program file path field with a Browse button, a Play As select reading Auto, and a green file information banner giving size, modified time and line count with a Preview button"></p>
+<p>The first Program File in the demo mission's <strong>List [Roughing]</strong>, at
+<code>/execution?tree=execution/mission/2/0</code>, selected in the tree under the run header with its move,
+duplicate and delete buttons revealed. The path field carries a project-relative path, <strong>Play As</strong>
+reads <em>Auto (by extension)</em>, and the green banner below reports the file's size, modified time and
+line count with <strong>Preview</strong> beside it. The tree row and the panel's header both read <code>Program File</code>
+followed by the path in brackets, which is how a mission of several programs stays readable.</p>
+<p><img src="playing-a-program-img/program-file.en.png" alt="The Execution page's Control Tree with the six transport buttons and a green ready badge above the tree; the Mission root row carries a + at its right edge, and under it Machining Resolution 1 mm, Collision Detection On, then List Roughing expanded with its own + over a selected Program File NC/circle.ptp row showing its move up, move down, duplicate and delete buttons and a Program File NC/drill_slot.ptp row, a collapsed List Finishing with a +, Program File NC/circle.ptp, NC Code Inline finishing pass, a greyed Program File NC/slide-test-resolution-script.ptp with its checkbox cleared, NC Optimization Config expanded over Distances, Feedrate, Motion Dynamics, Force &amp; Safety and Compensation, and a greyed Post-Execution with its checkbox cleared over a child row cut off at the tree's bottom edge, every command row with a checkbox and a drag handle; the panel below is headed Mission / List [Roughing] / Program File [NC/circle.ptp] and holds a Program File Path field reading NC/circle.ptp with a Browse button, a Play As select reading Auto (by extension), and a green banner reading 298 B, modified 2024-09-05 10:38:37, 21 lines with a Preview button"></p>
 <h2 id="nc-code">NC Code</h2>
 <h3 id="name-it">Name it</h3>
 <p><strong>Title</strong> is optional in the sense that the field may be cleared, but it is not decoration: it is
-the program name the run reports under, and it is the detail the mission row brackets. A new command
-arrives with <code>NC Code</code> already in the field; rename it and both the log and the row follow.</p>
+the program name the run reports under, and it is the detail the command's row in the Control Tree
+brackets. A new command arrives with <code>NC Code</code> already in the field; rename it and both the log and
+the row follow.</p>
 <h3 id="write-it">Write it</h3>
 <p>The editor is a plain monospace area — no line numbers and no syntax highlighting, because this is
 NC text, not a program in a language the application parses while you type. Line and character
@@ -207,10 +210,11 @@ counts sit below it and follow what you type.</p>
 <p><strong>Nothing is checked while you type.</strong> The text is stored exactly as written, and a mistake in it
 surfaces when the mission plays it — in <strong>NC Diagnostics</strong>, see
 <a href="when-something-goes-wrong.html">When Something Goes Wrong</a>.</p>
-<p>The demo mission's short hand-written pass, at <code>/execution?tree=execution/mission/5</code>. The title
-above the editor is what the row brackets, and the line and character counts below it are the whole
-of the feedback this editor gives.</p>
-<p><img src="playing-a-program-img/nc-code.en.png" alt="The NC Code command panel: a Title field reading Inline finishing pass above a monospace text area holding a short NC program, with line and character counts and the Trim Blank Lines and Clear buttons below it"></p>
+<p>The demo mission's short hand-written pass, at <code>/execution?tree=execution/mission/5</code>, selected in
+the tree as <code>NC Code [Inline finishing pass]</code>. The title above the editor is what that row brackets,
+and the editor holds the whole program, the closing % of which is cut off at the bottom edge; the
+counts and the two buttons sit beneath it, past the bottom of this view.</p>
+<p><img src="playing-a-program-img/nc-code.en.png" alt="The Execution page's Control Tree with the six transport buttons and a green ready badge above the tree; the Mission root row carries a + at its right edge, List Roughing and the collapsed List Finishing carry their own +, and the NC Code Inline finishing pass row is selected with its move up, move down, duplicate and delete buttons revealed, the greyed Post-Execution at the bottom over a child row cut off at the tree's bottom edge, every command row with a checkbox and a drag handle; the panel below is headed Mission / NC Code [Inline finishing pass] and holds a Title (optional) field reading Inline finishing pass above a monospace NC Code text area whose program runs from a % line through N0010 to N0170 M30 and a closing % cut off at the bottom edge, the text area reaching the bottom edge of the panel"></p>
 <h2 id="after-it-has-played">After it has played</h2>
 <p>Every program a session read appears under the <strong>Program</strong> branch, with the passes that went over it
 and the marks the run left on each line. That is where you see what happened to a line, as opposed

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

@@ -91,10 +91,11 @@
 can press at a given moment is the part worth learning</strong>, because the availability of a button is
 what tells you where the run actually is.</p>
 <h2 id="where-it-is">Where it is</h2>
-<p>The Execution page at <code>/execution</code>. The transport sits along the top of the editor panel in the left
-dock, and it is mounted for the <strong>Execution</strong> root and every node beneath it — so it stays reachable
-while you are editing a Mission command one level in. There is exactly one of it on the page, and it
-is the thing that binds <kbd>F5</kbd> to <kbd>F8</kbd>.</p>
+<p>The Execution page at <code>/execution</code>. The transport sits in the run header at the top of the Control
+Tree pane in the left dock, above the <strong>Mission</strong> and <strong>Program</strong> roots, with the run-state badge at
+its right end. It is there whatever the tree has selected — so it stays reachable while you are
+editing a Mission command — and its keys keep working while the Control Tree row is collapsed. There
+is exactly one of it on the page, and it is the thing that binds <kbd>F5</kbd> to <kbd>F8</kbd>.</p>
 <h2 id="the-six-controls">The six controls</h2>
 <table>
 <thead>
@@ -196,19 +197,21 @@ the run has not stopped yet.</p>
 <p>The bar at rest, with the demo project open and nothing run yet, at <code>/execution</code>. Start, the two
 single-advance buttons and Reset are live; Pause and Stop are greyed, because there is no run to hold
 or to end — and the two single-advance buttons carry the <strong>L</strong> and the <strong>S</strong> that tell them apart. The
-badge on the <strong>Execution</strong> tree item reads <em>ready</em>, and the block on the canvas is uncut.</p>
-<p><img src="running-a-simulation-img/transport-ready.en.png" alt="The Execution page with the Control Tree on the left showing the Mission and Program branches, a green ready badge on the Execution item, the transport row above the editor panel with the pause and stop buttons greyed, and the 3D canvas showing an uncut rectangular aluminium block on its fixture"></p>
+badge at the right end of the run header reads <em>ready</em>, and the block on the canvas is uncut.</p>
+<p><img src="running-a-simulation-img/transport-ready.en.png" alt="The Execution page with the run header at the top of the Control Tree pane — the six transport buttons with the pause and stop buttons greyed, and a green ready badge at the right end — above the Mission root with its nine command rows, each with a checkbox and a drag handle and two of them unticked and dimmed, a + on the Mission row and on the two List rows, and the Program root listing four .ptp files and an inline entry; the Mission editor panel below reads Commands 9; the 3D canvas shows an uncut light-grey rectangular block on its grey fixture, and the Session Messages Shell tab reads No messages match the current filter"></p>
 <h2 id="reading-the-run-state">Reading the run state</h2>
-<p>The state rides the <strong>Execution</strong> item in the Control Tree as a coloured badge — <em>ready</em>, <em>running</em>,
-<em>paused</em>, <em>finished</em> — so it is readable from wherever you are in the tree rather than only from the
-transport. The footer along the bottom of the window carries the session's own messages beside it.</p>
-<p>The same page with the mission paused part way through. The badge now reads <em>paused</em> in orange, Pause
-has gone grey, and Stop has joined the live ones — so the bar alone tells you a run is open and held.
+<p>The state sits at the right end of the run header, beside the transport, as a coloured badge —
+<em>ready</em>, <em>running</em>, <em>paused</em>, <em>finished</em> — pinned above the tree, so it stays in view however far you
+scroll the tree. When the left dock is narrowed the buttons scroll out of view before the badge does:
+the run state is the last thing a resize hides. The footer along the bottom of the window carries the
+session's own messages.</p>
+<p>The same page with the mission paused part way through. The badge reads <em>paused</em> in orange, Pause is
+grey, and Stop has joined the live ones — so the bar alone tells you a run is open and held.
 On the canvas the tool path the run has laid down so far is now drawn over the block, and the tabs
 under it are counting what the run has reported: <strong>Shell</strong> is badged with the eleven messages the
 load and the run have written between them and <strong>NC Diagnostics</strong> with the one the parser raised,
 while <strong>Step Diagnostics</strong> and <strong>NC Manipulation</strong> carry no badge at all.</p>
-<p><img src="running-a-simulation-img/transport-paused.en.png" alt="The Execution page with the Control Tree on the left, its Execution item carrying an orange paused badge, the transport row above the editor panel with the pause button greyed and the rest live, the 3D canvas showing a gold disc cutter sunk into the top face of the white block on its grey fixture with a single thin green tool path entering from the upper left and dropping to it, and a footer reading Ready"></p>
+<p><img src="running-a-simulation-img/transport-paused.en.png" alt="The Execution page with the run header at the top of the Control Tree pane — the six transport buttons with only the pause button greyed, and an orange paused badge at the right end — above the Mission root with its nine command rows and the Program root with its five entries, the Mission editor panel below reading Commands 9, the 3D canvas showing a gold disc cutter sunk into the top face of the white block on its grey fixture with a single thin tool path entering from the upper left and dropping straight down in green to it, the Session Messages Shell tab badged 11 and NC Diagnostics badged 1 over a list of system messages, and a footer reading Ready"></p>
 <h2 id="the-keys-and-where-they-stop">The keys, and where they stop</h2>
 <p><kbd>F5</kbd> to <kbd>F8</kbd> are bound only while the Execution page is the one on screen. On every
 other page <kbd>F5</kbd> is the browser's own reload, and the same is true here in two cases: when

App/wwwroot/HiAPI-docsite/manual/run/the-other-commands.html

@@ -90,9 +90,10 @@
 <p>Beyond putting a program into a run, a mission can change the session's settings part-way through,
 steer the optimizer, write out what the run produced, and drive the session from a script.</p>
 <h2 id="where-they-are">Where they are</h2>
-<p>The Execution page's <strong>Mission</strong> branch, all from the same <strong>Add Command</strong>. The Program category's
-other two commands are on <a href="playing-a-program.html">Playing a Program</a>, and the Flow category's one
-command is on <a href="building-a-mission.html">Building a Mission</a>.</p>
+<p>The Execution page's <strong>Mission</strong> branch of the Control Tree, all from the same <strong>Add Command</strong> —
+the <strong>+</strong> on the <strong>Mission</strong> row or on a <strong>List</strong> row. The Program category's other two commands
+are on <a href="playing-a-program.html">Playing a Program</a>, and the Flow category's one command is on
+<a href="building-a-mission.html">Building a Mission</a>.</p>
 <h2 id="settings-one-per-command">Settings, one per command</h2>
 <p>The <strong>Setup</strong> category holds five commands, each carrying one setting:</p>
 <table>
@@ -144,9 +145,10 @@ linear resolution in mm and a rotary one in degrees.</p>
 <h5>Note</h5>
 <p><strong>General Config is not on the menu, and it is not missing.</strong> It was one command carrying all five
 of these settings at once, and the five above replace it. A project that still stores one loads as
-those five commands in its place — preceded by a Record Meshed Geometry command where the bundle
-also read a meshed geometry file — and saving from then on writes the five. There is nothing to
-add and nothing to look for.</p>
+those five commands in its place, and saving from then on writes the five. Where the bundle named a
+meshed geometry file or had reading one switched on, a Record Meshed Geometry command set to
+<strong>Read</strong> precedes them — ticked only where reading was switched on. There is nothing to add and
+nothing to look for.</p>
 </div>
 <h2 id="the-optimizer-as-a-step">The optimizer, as a step</h2>
 <p><strong>NC Optimization Config</strong> is the Optimization category's one command, and it exists so the
@@ -192,10 +194,12 @@ optimizer is on, which is the first switch on its panel.</p>
 means, and why an optimized result can look wrong, is
 <a href="../../technique/nc-optimization/index.html">NC Optimization</a>.</p>
 <p>The demo mission's optimizer command, at <code>/execution?tree=execution/mission/7</code>. In this mission it
-sits below both program groups rather than above them, so the ordering rule at the top of this
-section is what decides how much of the run it reaches. The five switches are on the command's own
-panel; the five value nodes are indented under it in the tree.</p>
-<p><img src="the-other-commands-img/nc-optimization-config.en.png" alt="The NC Optimization Config command selected in the Mission branch, with Distances, Feedrate, Motion Dynamics, Force and Safety and Compensation child nodes listed beneath it, and the panel below showing the Enable Optimization, Enable Feedrate Optimization, Enable Depth Splition and Enable Interpolation checkboxes ticked above an unticked Omit Leading Zero in Output checkbox"></p>
+sits below both <strong>List</strong> groups and the three loose entries after them rather than above them, so
+the ordering rule at the top of this section is what decides how much of the run it reaches. The
+five switches are on the command's own panel below the tree, headed <em>Mission / NC Optimization
+Config</em>; the five value nodes are indented under it in the tree. Because the row is selected, its
+move, duplicate and delete buttons show at its right edge.</p>
+<p><img src="the-other-commands-img/nc-optimization-config.en.png" alt="The Control Tree on the Execution page, with the six transport buttons and a green ready badge above the tree and the Mission root row carrying a + at its right edge; among the command rows, each with a checkbox and a drag handle, NC Optimization Config is selected with its move up, move down, duplicate and delete buttons revealed at the right, and Distances, Feedrate, Motion Dynamics, Force &amp; Safety and Compensation are listed beneath it without checkboxes, with a greyed, unticked Post-Execution row at the pane's bottom edge below them; the panel below is headed Mission / NC Optimization Config and shows Enable Optimization, Enable Feedrate Optimization, Enable Depth Splition and Enable Interpolation ticked above an unticked Omit Leading Zero in Output"></p>
 <h2 id="writing-out-what-the-run-produced">Writing out what the run produced</h2>
 <p>The <strong>Output</strong> category holds three commands: <strong>Post-Execution</strong>, <strong>Record Meshed Geometry</strong> and
 <strong>Export Meshed Geometry (STL)</strong>.</p>
@@ -230,7 +234,7 @@ it writes an interim snapshot of the same accumulating run. <strong>Its placemen
 </tr>
 <tr>
 <td><strong>CL → NC Writeback</strong></td>
-<td>brand NC re-synthesized from what was played</td>
+<td>Fanuc NC re-synthesized from what was played</td>
 <td><code>Output/[NcName].nc</code></td>
 </tr>
 <tr>
@@ -260,8 +264,11 @@ tree lists them in, and which matters only if you are reading their timestamps.<
 <p>The demo mission's Post-Execution command with <strong>Step Files Output</strong> selected, at
 <code>/execution?tree=execution/mission/8/step-files</code>. Each output is a child node with its own
 checkbox — that tick is what switches the output on — and the template field for the selected one
-sits in the panel below.</p>
-<p><img src="the-other-commands-img/post-execution.en.png" alt="The Post-Execution command in the Mission branch with its five child nodes, each carrying its own checkbox, and the Step File Template field in the panel below"></p>
+sits in the panel below, headed <em>Mission / Post-Execution / Step Files Output</em>. In the demo the
+<strong>Post-Execution</strong> row itself is greyed with its checkbox cleared, and its outputs stay editable
+all the same; the row is the last one the tree pane shows in full here, its child nodes cut off at
+the pane's edge with only the top sliver of the first showing.</p>
+<p><img src="the-other-commands-img/post-execution.en.png" alt="The Control Tree on the Execution page, with the six transport buttons and a green ready badge above the tree and the Mission root row carrying a + at its right edge; the command rows run down to a greyed Post-Execution row with its checkbox cleared at the bottom edge of the tree pane, only the top sliver of its first child row showing before the pane's edge cuts it off; the panel under the tree is headed Mission / Post-Execution / Step Files Output and holds one Step File Template field reading Output/[NcName].step.csv"></p>
 <h2 id="keeping-the-workpiece-between-runs">Keeping the workpiece between runs</h2>
 <p>The Output category's other two commands both take the workpiece as it stands at their own point in
 the list. <strong>Record Meshed Geometry</strong> stores it in the application's mesh format so a later run can
@@ -302,8 +309,10 @@ first such entry reads, and every one below a program writes. Building a mission
 Resolution command belongs above it. A missing file is not an error: writing it is what a run does.
 <strong>Reset</strong> on the command's panel deletes the file it points at, so the next run records afresh.</p>
 <p>Export Meshed Geometry (STL) takes a path — <code>Output/MeshedGeom.stl</code> by default, since an export is
-something you asked for rather than a cache — and a resolution in millimetres; leave it at 0 for the
-default. It also builds the mesh, so the same placement rule applies.</p>
+something you asked for rather than a cache — and a resolution in millimetres for the triangles it
+writes; 0 uses the display mesh resolution. What it triangulates is the same mesh Record Meshed
+Geometry writes, built the same way, so the placement rule above applies to it too: the STL
+resolution decides how finely that mesh is tessellated, not how finely it was cut.</p>
 <h2 id="driving-the-session-from-a-script">Driving the session from a script</h2>
 <p><strong>Script</strong> is the Program category's third command: C# evaluated against the running session, for
 anything the other command kinds do not cover. Where the script returns a sequence of actions, that
@@ -317,10 +326,15 @@ tooltip. <strong>Staged means the service is holding the script, not that the pr
 save the project to keep it.</p>
 <p>Two prompts guard the edges, and neither is a yes/no question, so each has three buttons:</p>
 <ul>
-<li><strong>Unsaved Changes</strong>, when you select another node while a save is still pending — <em>Save &amp; switch</em>
-flushes it first, <em>Discard</em> drops it, <em>Cancel</em> leaves the selection where it is.</li>
+<li><strong>Unsaved Changes</strong>, when the script still has unsaved edits and you select another node, or
+move, duplicate, delete or add a command from the tree rows — a save already on its way is let
+land first, and the prompt appears only for what is still unsaved after it. <em>Save &amp; switch</em>
+saves and then proceeds, and only once the save has landed; <em>Discard</em> drops the edits; <em>Cancel</em>
+leaves the selection where it is, and a cancelled row operation is dropped with a notice that
+the editor keeps its unsaved edits.</li>
 <li><strong>Script changed elsewhere</strong>, when the command changed underneath you — another tab, or a project
-reload.</li>
+reload. <em>Discard &amp; reload</em> takes the server's copy, <em>Force overwrite</em> writes yours over it,
+<em>Cancel</em> keeps your edits in the editor, unsaved, and the server's copy as it is.</li>
 </ul>
 <p>Like NC Code, the title is optional and is what the row brackets.</p>
 <h2 id="the-list-is-not-closed">The list is not closed</h2>

App/wwwroot/HiAPI-docsite/manual/run/the-program-branch.html

@@ -88,26 +88,35 @@
           <h1 id="the-program-branch">The Program Branch</h1>
 
 <p>What the run actually read, line by line, as opposed to what the mission asked for.</p>
-<p>The Execution page's Control Tree carries two branches: <strong>Mission</strong> above, <strong>Program</strong> below, at
-Control-Tree path <code>execution/program</code>. Program is read-only — every node on it is either a file the
-mission points at or a pass a run made over one — and the transport bar stays pinned above its
-panels, so a run can be started, stepped and reset without leaving the branch.</p>
+<p>The Execution page's Control Tree carries two roots: <strong>Mission</strong> above, <strong>Program</strong> below, at
+Control-Tree path <code>execution/program</code>. Program is read-only — its nodes are what the session played
+or produced: the files the mission points at, the files the run reached from them, the inline text
+of the NC Code commands, one node per distinct title, and the writeback files converted from a
+played file — and the transport sits in the run header at the top of the Control Tree pane, with
+the run-state badge at its right end, so a run can be started, stepped and reset without leaving
+the branch.</p>
 <h2 id="before-anything-runs">Before anything runs</h2>
-<p>The branch is not empty before a run. The service seeds it from the mission: one node per distinct
-NC file a <strong>Program File</strong> command names, and one per <strong>NC Code</strong> command, taken in the order the
-mission lists them and reaching into nested groups. Those nodes are placeholders — a file the run
-has not opened yet — and the branch panel says so, badging itself <em>not run yet</em> beside the file
-count.</p>
-<p>Three things decide what is seeded, and each of them is visible in the screenshot below:</p>
+<p>The branch is not empty before a run. The service seeds it from the mission: first one node per
+distinct file an enabled <strong>Program File</strong> command names — NC, CL or CSV alike, since the seed reads
+the command's path and not its kind — in the order the mission lists them and reaching into nested
+<strong>List</strong> commands, then one node per distinct title among the enabled
+<strong>NC Code</strong> commands — so an NC Code command listed above a Program File still seeds below every
+file node. Those nodes are placeholders — a file the run has not opened yet — and the branch panel
+says so, badging itself <em>not run yet</em> beside the file count.</p>
+<p>Three things decide what is seeded:</p>
 <ul>
-<li><strong>A disabled command seeds nothing.</strong> The mission's greyed <em>Program File</em> entry names an NC file
-that never reaches the branch, and nothing beneath a disabled group reaches it either.</li>
+<li><strong>A disabled command seeds nothing.</strong> The mission's greyed <em>Program File</em> entry names a file
+that never reaches the branch, and nothing beneath a disabled List reaches it either.</li>
 <li><strong>Two commands naming one file seed one node.</strong> Paths are compared with case and slash direction
-ignored, so a file played twice appears once.</li>
+ignored, so a file played twice appears once. In the screenshot below the first <code>circle.ptp</code>
+command sits inside the collapsed <strong>List [Roughing]</strong> and the second is the top-level
+<strong>Program File</strong> row, so the branch shows one plain <code>circle.ptp</code>; the <code>×2</code> it takes once both
+commands have played is in the next section.</li>
 <li><strong>An NC Code command is seeded under its own title</strong>, not under a file name, because it has no
-file — its text lives in the mission. The branch marks it <code>(inline)</code>.</li>
+file — its text lives in the mission. The branch marks it <code>(inline)</code>, and two NC Code commands
+with the same title share one node.</li>
 </ul>
-<p><img src="the-program-branch-img/program-before-run.en.png" alt="The Execution page before a run: the Control Tree shows the Mission branch with nine commands — two of them greyed out and unticked — over the Program branch, whose five nodes are circle.ptp, drill_slot.ptp, side.ptp, slide.ptp and (inline) Inline finishing pass. The branch panel below the transport bar is badged not run yet beside 5 files, and the four Session Messages tabs are empty"></p>
+<p><img src="the-program-branch-img/program-before-run.en.png" alt="The Execution page before a run: the run header at the top of the Control Tree pane shows the six transport buttons and a green ready badge at its right end; under it the Mission root row, with a + at its right edge, lists nine command rows, each with a checkbox and a drag handle, two of them greyed out and unticked, and the two List rows carry their own +; the Program root below is selected and holds five nodes — circle.ptp, drill_slot.ptp, side.ptp, slide.ptp and (inline) Inline finishing pass; the Program panel in the editor row under the tree is badged not run yet beside 5 files with a round refresh button at the row's right end, above the hint to run the mission; the 3D canvas shows an uncut block, and the four Session Messages tabs carry no badge"></p>
 <p><em>The Program branch at <code>/execution?tree=execution/program</code>, on a project that has not been played.
 The disabled <code>Program File</code> entry in Mission has no node under Program; the enabled <code>NC Code</code>
 command has one, under its title.</em></p>
@@ -116,25 +125,37 @@ command has one, under its title.</em></p>
 not name — a subprogram call nests its callee under the caller. The panel's badge changes from
 <em>not run yet</em> to <em>run data</em>, and a file the run made more than one pass over takes a <code>×</code> and a
 count in its tree label.</p>
-<p><img src="the-program-branch-img/program-after-run.en.png" alt="The same page after the run has finished: the Execution root badge reads finished, the first Program node now reads circle.ptp ×2, the branch panel is badged run data beside 5 files, and the Session Messages tabs carry counts — Shell 11 and NC Diagnostics 7, with Step Diagnostics and NC Manipulation still unbadged"></p>
+<p><img src="the-program-branch-img/program-after-run.en.png" alt="The same page after the run has finished: the badge at the right end of the run header reads finished, the Mission rows are unchanged, the first Program node reads circle.ptp ×2, the Program panel under the tree is badged run data beside 5 files with the refresh button at the row's right end, the 3D canvas shows the cut block with a gold cutter and green tool paths above it, and the Session Messages tabs carry counts — Shell 11 and NC Diagnostics 7, with Step Diagnostics and NC Manipulation still unbadged — over a list of System messages"></p>
 <p><em>The same deep link once the run has finished. <code>circle.ptp ×2</code> is one node holding two passes,
 because two Program File commands named the same file.</em></p>
 <div class="IMPORTANT">
 <h5>Important</h5>
-<p>The branch is rebuilt when the run <strong>changes state</strong> — starting, finishing, being reset — and not
-while it is playing. During a long run the nodes on screen are the ones the last transition left
-there, so a file the run has since opened may not be listed yet. Pausing brings it up to date.</p>
+<p>The branch is rebuilt when the run <strong>changes state</strong> — starting, pausing, finishing, being reset —
+and not while it is playing. During a long run the nodes on screen are the ones the last
+transition left there, so a file the run has since opened may not be listed yet. The round
+refresh button at the far right end of the Program panel's badge row — across the row from the
+<em>run data</em> badge and the file count, its tooltip <em>Re-read the file tree from the current
+session</em> — rebuilds the branch on the spot without touching the transport; pausing rebuilds it
+too, since a pause is a state change.</p>
 </div>
 <h2 id="reading-one-file">Reading one file</h2>
 <p>Selecting a node opens the file as the run saw it: the path it was read from, a selector for the
 passes made over it, and the text with what each line produced beside it.</p>
-<p><img src="the-program-branch-img/program-file-passes.en.png" alt="The Program branch with circle.ptp ×2 selected: the breadcrumb reads Execution / Program / circle.ptp ×2, the path caption NC/circle.ptp, a pass selector reading Pass (2) and #2 · re-entry beside a Follow toggle, then twenty-one numbered lines of NC with a step range printed to the right of thirteen of them, and a footer reading 21 lines · 21 executed lines"></p>
+<p><img src="the-program-branch-img/program-file-passes.en.png" alt="The Program branch with circle.ptp ×2 selected and the canvas and right-hand columns switched off, so the Control Tree pane spans the window: the menu bar carries a red disconnected chip beside the four layout toggles, the run header's green finished badge sits at the far right, the Mission root row is collapsed with a + at its right edge, the Program root beneath it is open and holds five nodes — circle.ptp ×2 highlighted in blue, drill_slot.ptp, side.ptp, slide.ptp and (inline) Inline finishing pass — and the editor row's header reads Program / circle.ptp ×2; inside it the path caption NC/circle.ptp, a pass selector reading Pass (2) and #2 · re-entry beside a Follow toggle, then twenty-one numbered lines of NC with a step range printed to the right of ten of them, a footer reading 21 lines · 21 executed lines, and the window footer reading Ready"></p>
 <p><em>One file node at <code>/execution?tree=execution/program/0</code>, with the canvas column switched off so the
-line viewer has the width. The pass selector names the pass and why it was entered.</em></p>
+line viewer has the width — which is why the menu-bar chip reads <strong>disconnected</strong>: the badge folds the
+page's rendering connection in with its service connections, and with the canvas column off the page
+holds no rendering connection (see <a href="../basics/the-app-window.html">The Application Window</a>).
+The pass selector names the pass and why it was entered.</em></p>
 <ul>
-<li><strong>The pass selector</strong> carries one entry per pass, labelled with how that pass was entered — the
-first arrival at the top of the file, a re-entry when the mission came back to it, or the call
-that reached it from another file.</li>
+<li><strong>The pass selector</strong> carries one entry per pass, labelled with how that pass was entered. A
+pass that an <code>M98</code>/<code>M198</code> subprogram call started carries the call word and its <code>P</code> number —
+<code>M98 P8</code> — on every pass, so a subprogram the caller repeats with an <code>L</code> count or calls a second
+time reads <code>×N</code> with each pass labelled by the call, never as a re-entry. A pass with no call
+behind it reads <em>top</em> on the first arrival at that path and <em>re-entry</em> on every later pass over
+it — whether a second Program File command named the file again or a <code>WHILE</code> or <code>GOTO</code> inside a
+single play of it started a new pass. So a file the mission names once can still read <code>×N</code>, with
+every pass after the first labelled re-entry.</li>
 <li><strong>The step range</strong> beside a line is what that line produced. A line with no range beside it ran
 and produced no motion: <code>G</code> and <code>M</code> words that set state, and the tape marks, all execute without
 cutting anything.</li>
@@ -146,13 +167,17 @@ was put.</li>
 </ul>
 <h2 id="what-the-branch-does-not-hold">What the branch does not hold</h2>
 <ul>
-<li><strong>The writeback files are not inside the file nodes.</strong> Converting a played program back to NC
-makes its own node at the top of the branch, beside the file nodes rather than under them, and
-clicking a line on either side jumps to its twin on the other. That conversion is the CL-to-NC
-writeback, so a mission that plays brand NC produces none, and the branch shows only source files.</li>
-<li><strong>Node addresses are positions, not files.</strong> A node is <code>execution/program</code> followed by its index,
-so a deep link into the branch survives only as long as the branch has the same shape. Link to the
-branch, not into it.</li>
+<li><strong>The writeback files are not inside the file nodes.</strong> With <strong>Post-Execution › CL → NC
+Writeback</strong> enabled, the mission re-serializes every file the session played — NC plays as well
+as CL plays — and each converted file makes its own node, labelled <code>→</code> and the output file's
+name, at the top level of the branch, after the file nodes rather than under them; the Program
+panel counts them beside the file count, and clicking a line on either side jumps to its twin on
+the other. With that section disabled the branch shows only source files.</li>
+<li><strong>Node addresses are positions, not files.</strong> A node is <code>execution/program</code> followed by an index
+at each level of nesting — <code>execution/program/0</code> for a top-level file, <code>execution/program/0/0</code>
+for a subprogram nested under it — and a writeback node takes <code>dst-</code> and its own index in place
+of a file index, <code>execution/program/dst-0</code>. So a deep link into the branch survives only as long
+as the branch has the same shape. Link to the branch, not into it.</li>
 <li><strong>A skipped line is not only recorded here.</strong> A line suppressed by block skip is also announced in
 the <strong>NC Diagnostics</strong> list while the run is playing — see
 <a href="when-something-goes-wrong.html">When Something Goes Wrong</a>.</li>

App/wwwroot/HiAPI-docsite/manual/run/watching-the-run.html

@@ -141,7 +141,7 @@ so re-expanding is instant rather than a fresh connection.</p>
 <p>The <strong>Scene</strong> menu open over the canvas at <code>/execution</code>, with the Strip Charts column beside it. The
 three groups are the ones listed above, and the ticked boxes are the set the page opens with —
 Workpiece, Fixture and Dimension Bar — with Machine and Tool unticked.</p>
-<p><img src="watching-the-run-img/scene-menu.en.png" alt="The Execution page with the Scene dropdown open over the 3D canvas, showing Solid with Machine, Tool, Workpiece and Fixture, Coordinate with Program Zero and ISO Coordinate, and Display Aids with Dimension Bar and Color Scale Bar; Workpiece, Fixture and Dimension Bar are ticked, and the Strip Charts column stands to the right"></p>
+<p><img src="watching-the-run-img/scene-menu.en.png" alt="The Execution page with the left dock hidden and the Scene dropdown open from the 3D Rendering Canvas header, showing Solid with Machine, Tool, Workpiece and Fixture, Coordinate with Program Zero and ISO Coordinate, and Display Aids with Dimension Bar and Color Scale Bar; Workpiece, Fixture and Dimension Bar are ticked, the canvas behind the menu shows a white block on a grey fixture with the dimension bar reading 22.9 mm, the Session Messages panel sits beneath it, and the Strip Charts column with its three filled charts stands to the right"></p>
 <h2 id="the-three-strip-charts">The three strip charts</h2>
 <p>One group bar drives three charts, and each of them plots <strong>the whole mission rather than the current
 moment</strong>:</p>
@@ -172,8 +172,10 @@ samples: the window is downsampled to the width it has on screen, so what you ar
 shape of the run — where the spindle is loaded, where surface quality degrades, where thermal limits
 are approached — rather than individual values. The values themselves are in the legend panel down
 the side of each chart, which follows the cursor and can be dragged wider.</p>
-<p>All three carry a <strong>Y-axis range</strong> editor in their header — <em>Fit</em> to the data, <em>Lock</em> to a minimum
-and maximum you type, or <em>Symmetric</em> about zero with a bound; locking one is how you compare two
+<p>All three carry a <strong>Y-axis range</strong> editor in their header, behind a button that reads <strong>Auto</strong>
+until you change it. Its three choices are <em>Fit (auto)</em>, which follows the data; <em>Lock</em>, a <strong>Min</strong>
+and <strong>Max</strong> you type, after which the button reads them as <code>[min, max]</code>; and <em>Symmetric</em>, about zero
+with a <strong>± bound</strong> you type, which the button shows as <code>±bound</code>. Locking one is how you compare two
 parts of a run without the axis moving under you. The
 Color Index chart adds two more: the property picker, which is a type-to-filter list of every
 quantifiable step property, and <strong>Colors</strong>, which edits the colour guide. Colors is worth
@@ -202,7 +204,7 @@ colour scale bar, not the line in the chart.</p>
 </tr>
 <tr>
 <td><strong>Fit view</strong></td>
-<td>Fits the 3D canvas to the tool path — the one control here that acts on the canvas</td>
+<td>Fits the 3D canvas to the tool path, or to the home view when there is no tool path yet — the one control here that acts on the canvas</td>
 </tr>
 <tr>
 <td><strong>Stick to live end</strong></td>
@@ -249,7 +251,7 @@ being dragged back to the live end — and <em>Reset display range</em> is how y
 </tr>
 <tr>
 <td>Hover</td>
-<td>Puts that x-value in the group bar's cursor readout</td>
+<td>Puts that x-value in the group bar's cursor readout, and marks that step's position on the tool path in the canvas</td>
 </tr>
 <tr>
 <td>One finger / two fingers</td>
@@ -259,15 +261,23 @@ being dragged back to the live end — and <em>Reset display range</em> is how y
 </table>
 <p>A left drag shorter than a few pixels counts as a click, so selecting a step does not need a steady
 hand.</p>
+<p>Hovering is the light-touch twin of clicking. A click selects a step and fills the Step Info column;
+a hover only tells the engine which step the pointer is over, and the canvas answers by lighting up
+that step's cutter location on the tool path — a dot with an <code>@index</code> label, joined by a short
+segment to the position before it — so sweeping the pointer along a chart walks a marker along the
+cut. The marker goes away when the pointer leaves the chart, it is only drawn while <strong>Tool Path</strong> is
+on, and a touch screen has no hover, so it never appears there.</p>
 <p>Before anything has run, all three read <strong>No mission data</strong>. A chart that has data but no physics
 behind it reads <strong>No physics data</strong> instead — that is what the Availability chart looks like when
 the run produced no physics results.</p>
-<p>The three charts with the demo mission paused part way through and a step selected. The vertical rule
+<p>The three charts with the whole demo mission in the window and a step selected. The vertical rule
 crossing all three at the same place is that selection; the range chip on the group bar names the
-window, the x-axis is in seconds, and each chart's legend stands down its right side with one entry
-per series — five on each of the first two, one on the Color Index chart, which plots the single
-property named in its header.</p>
-<p><img src="watching-the-run-img/strip-charts.en.png" alt="The Execution page's Strip Charts column filled from a paused run: an Availability Chart, a Surface Roughness Chart and a Color Index Time Chart stacked under one group bar, each showing banded series across the mission timeline with a legend listing its series down the right side, and the 3D canvas showing the part-machined block to the left"></p>
+window — here every one of the 6402 steps — the x-axis is in seconds, and each chart's legend
+stands down its right side with one entry per series — five on each of the first two, one on the
+Color Index chart, which plots the single property named in its header. The transport and the
+run-state badge sit in the run header at the top of the Control Tree pane, in the left dock this
+shot hides.</p>
+<p><img src="watching-the-run-img/strip-charts.en.png" alt="The Execution page with the left dock hidden: the 3D Rendering Canvas on the left shows a white block on a grey fixture with the tool path drawn down onto a coloured cut in its top face and the dimension bar reading 22.9 mm, the Session Messages panel sits beneath it, and the Strip Charts column on the right stacks an Availability Chart, a Surface Roughness Chart and a Color Index Time Chart under one group bar whose range chip reads [0..6402] / 6402 and whose cursor readout reads Time (s): —; every chart's x-axis is Time (s), each chart header's range button reads Auto, a vertical selection rule crosses all three charts near the start of the timeline, and each chart carries a legend down its right side"></p>
 <h2 id="see-also">See Also</h2>
 <ul>
 <li><a href="index.html">Running a Simulation</a> — the rest of running a job</li>

App/wwwroot/HiAPI-docsite/manual/run/when-something-goes-wrong.html

@@ -97,15 +97,19 @@ something in it, so a tab with no number beside its name is a sink nothing has r
 <ul>
 <li><strong>Shell</strong> — the session's own account of itself: what started, what finished, what it built, and
 the verdicts it reaches at the end of a play. A conversion or an optimization reports itself here
-too, stage by stage and file by file, from its opening row to its closing count. These rows carry
-no anchor, because there is nothing
+too, from its opening row to its closing count — an optimization stage by stage and file by
+file; a conversion in those two rows alone, the closing one carrying the count and the names of
+every file written in a single sentence, and a row of its own only for a file it could not write.
+These rows carry no anchor, because there is nothing
 in the program to anchor them to. <strong>This is the list a run that appears to have done nothing is
 diagnosed from</strong>: a play that ends with no step having touched the workpiece is reported here, and
 the message names the usual causes — an incremental header with no <code>G90</code> after it, a work offset
 or program zero that puts the program somewhere else, stock that is not where the program expects
-it.</li>
+it, and the tool geometry.</li>
 <li><strong>NC Diagnostics</strong> — everything the NC pipeline said while playing, which is not only complaints.
-It opens each file with the line count it found, and a row about one sentence carries an anchor
+It closes each file with the line count it read — the <em>contains lines</em> row is written once the
+file's last line has been consumed, so it follows every diagnostic that file raised, and a file
+the play is still reading has no such row yet — and a row about one sentence carries an anchor
 naming it. This is the list to read when the program did not do what its text says.</li>
 <li><strong>Step Diagnostics</strong> — anchored to a machining step rather than to a position in the text. Most of
 it is about motion, but not all: an NC-embedded script that fails to compile is reported here too,
@@ -120,33 +124,44 @@ account of itself is on <strong>Shell</strong>.</li>
 <p>A message about a <code>G</code> word and a message about a move are different problems, and they never share a
 list. Looking in the wrong one reads as silence.</p>
 <h2 id="reading-a-row">Reading a row</h2>
-<p><img src="when-something-goes-wrong-img/nc-diagnostics.en.png" alt="The Execution page with the left and right columns switched off: the canvas above, and below it the Session Messages panel with the NC Diagnostics tab selected. The tab row shows Shell badged 11 and NC Diagnostics badged 7, with Step Diagnostics and NC Manipulation carrying no badge at all. Under a filter toolbar of Severity, Category, a text box, Reset and Export, seven rows are listed: six System rows reading Sys-Init&ndash;FileLines with each file and its line count, and one warning row whose anchor column reads Sn 2105, category Unsupported, id Parsing&ndash;Unconsumed, text Unconsumed Parsing entries: G02"></p>
+<p><img src="when-something-goes-wrong-img/nc-diagnostics.en.png" alt="The Execution page with the left and right columns switched off, so no Control Tree pane and no run header is in view: the 3D Rendering Canvas above, showing a white block on a grey fixture with a gold disc cutter at its top face and green tool paths rising above it, and below it the Session Messages panel with the NC Diagnostics tab selected. The tab row shows Shell badged 11 and NC Diagnostics badged 7, with Step Diagnostics and NC Manipulation carrying no badge at all. Under a filter toolbar of Severity, Category, a Filter text… box, Reset and Export, with a 7 / 7 counter at its right end, seven rows are listed: six System rows reading Sys-Init&ndash;FileLines with each file and its line count — circle.ptp listed twice, Inline finishing pass last — and, sixth in the list, one warning row whose anchor column reads Sn 2105, category Unsupported, id Parsing&ndash;Unconsumed, text Unconsumed Parsing entries: G02"></p>
 <p><em>The four lists at <code>/execution</code>, with NC Diagnostics selected. Two of the four tabs carry no badge,
-which is how an empty sink looks.</em></p>
+which is how an empty sink looks. The warning at <code>Sn 2105</code> sits above the line-count row for
+<code>Inline finishing pass</code> because that row closes its file rather than opening it.</em></p>
 <p>A row carries, left to right, the position it is about, the category, the message's own id, and its
-text. The position is the anchor: <code>Sn</code> and a number for a sentence, <code>S</code> and a number for a step. Not
-every row has one — a complaint about the pipeline rather than about a particular sentence has
-nothing to anchor to, and neither has anything on <strong>Shell</strong>.</p>
+text. The position is the anchor. On the two NC lists it is <code>Sn</code> and a number, naming a sentence. On
+<strong>Step Diagnostics</strong> it opens with <code>S</code> and the step's number, and when that step was reached from a
+sentence the one anchor carries both markers — <code>S12 · Sn 340</code> names the step and then the sentence
+behind it; only a step with no sentence behind it reads <code>S</code> and its number alone. Not every row has
+one — a complaint about the pipeline rather than about a particular sentence has nothing to anchor
+to, and neither has anything on <strong>Shell</strong>.</p>
 <p>The id is worth reading. It is stable across languages and releases, so it is the thing to quote
 when asking someone else about a message, and the thing to filter on when one message is repeating.
 The <strong>Filter text…</strong> box, the <strong>Severity</strong> and <strong>Category</strong> lists and <strong>Export</strong> are described with
 the rest of the panel in <a href="../basics/messages-and-logs.html">Messages and Logs</a>.</p>
 <div class="IMPORTANT">
 <h5>Important</h5>
-<p><strong>On the two NC lists, a row is not an occurrence.</strong> <strong>NC Diagnostics</strong> folds across a play and
-<strong>NC Manipulation</strong> across one conversion or optimization run; <strong>Shell</strong> and <strong>Step Diagnostics</strong>
-fold nothing, and every report they take becomes a row of its own. Where it applies, the pipeline
-keeps one entry per
-distinct message — same id, same wording — and drops every repeat instead of listing it. When the
-program ends, each message that occurred more than once gets one summary row reading <em>repeated N
-times in this run, first at</em> the sentence it was first seen on. So a diagnostic raised on forty
-different sentences leaves two rows for that program: the first occurrence, and the summary.</p>
+<p><strong>On the two NC lists, a row is not an occurrence.</strong> <strong>NC Diagnostics</strong> folds across the play of
+one mission command — one <strong>Program File</strong> or one <strong>NC Code</strong> entry, subprograms included, so a
+file played twice is two windows — and <strong>NC Manipulation</strong> across one conversion or optimization
+run; <strong>Shell</strong> and <strong>Step Diagnostics</strong> do no such folding — a report there gets a row of its own unless it is identical to the row just
+before it, in which case it joins that row under the multiplier badge described below. Where it
+applies, the pipeline keeps one entry per distinct message — same id, same wording — and drops
+every repeat instead of listing it. When the program ends, each message that occurred more than
+once gets one summary row: the first occurrence's text followed by <code>[repeated Nx in this run, first at Sn=…]</code>, with the count in place of <code>N</code> and the sentence it was first seen on after <code>Sn=</code>
+(a message with no sentence to anchor to ends in <code>[repeated Nx in this run]</code> instead). So a
+diagnostic raised on forty different sentences of one file leaves two rows for that file: the
+first occurrence, and the summary — and the same diagnostic raised again in the next file, or on
+the same file's second play, starts over with a first occurrence and a summary of its own. The
+screenshot above shows the window's edge: <code>circle.ptp</code> is played twice, and its line-count row
+is listed twice rather than folded.</p>
 <p>Two consequences are worth holding on to. The count is only in that summary sentence — the
 multiplier badge that marks consecutive identical messages is a different mechanism and does not
 appear on these. And <strong>the summary row's anchor is the last occurrence while its text names the
-first</strong>, so jumping from it lands at the end of the run of repeats, not at the beginning.
-Everything between the two rows has no anchor at all: to find those positions, fix the first one
-and play again.</p>
+first</strong>, so the <code>Sn</code> in its anchor column is the end of the run of repeats and the <code>Sn=</code> in its
+text the beginning. Neither is a link: clicking a row opens its detail when it has one and does
+nothing else, so an anchor is a position to read off, not a place to go. Everything between the
+two rows has no anchor at all: to find those positions, fix the first one and play again.</p>
 </div>
 <h2 id="then-the-runs-own-record">Then the run's own record</h2>
 <p>The <strong>Program</strong> branch holds what the run did to each line — the passes it made and the marks each
@@ -157,12 +172,20 @@ what the pipeline thought of a sentence while it was playing, the <strong>Progra
 sentence produced.</p>
 <h2 id="then-the-service-log">Then the service log</h2>
 <p><strong>Show Log</strong> on the menu bar opens the log the service is writing for the current day, with a
-<strong>Download</strong> for sending it to someone else. It holds things the four lists never carry — the
-exception behind a failure, and the engine's own start-up account of itself — and it is the only
-one of these surfaces that outlives the session. What it does not hold is the four lists: those are
-pushed to the browser and are never written to the file, so a message seen in a list is not
-findable there. The viewer itself is described in
-<a href="../basics/messages-and-logs.html">Messages and Logs</a>.</p>
+<strong>Download</strong> for sending it to someone else. It holds things the four lists do not carry — the
+engine's own start-up account of itself, and the exception behind a failure the engine did not report
+through a message, which the service writes to the log and nowhere else — and it outlives the
+session: a Reset on the transport — the eject button in the run header, not the <strong>Reset</strong> in a
+tab's filter toolbar, which clears that tab's filters and touches no list — empties <strong>Shell</strong>,
+<strong>NC Diagnostics</strong> and <strong>Step Diagnostics</strong>, and the log keeps what it had. An exception the engine <em>did</em> report through a message is a different case: it rides
+the row, which carries a chevron; opening it shows the exception in full, with a <strong>Copy</strong> of its
+own, so a script that would not compile or a step record that could not be read is answered from
+the list, not from the log. What the log does not hold is the four lists: those are pushed to the
+browser and are never written to the file, so a message seen in a list is not findable there — the
+exception on a row included. The one list the transport's Reset leaves
+alone is <strong>NC Manipulation</strong> — the next conversion or optimization is what empties it — so the last
+conversion's findings are still on that tab after the run has been reset away, not in the log. The
+viewer itself is described in <a href="../basics/messages-and-logs.html">Messages and Logs</a>.</p>
 <h2 id="while-an-optimization-is-running">While an optimization is running</h2>
 <p>An optimization reports itself on <strong>Shell</strong>, stage by stage. It opens with <em>Start NC optimization.</em>
 and ends with <em>Total N files optimized.</em> and <em>optimization cache cleared.</em>, and between them every
@@ -174,31 +197,50 @@ NC commands..</em>, with one <em>File optimized:</em> row naming each output fil
 stopped one. While the per-step feeds are being solved, every thousandth step adds another
 <em>Computing Optimized Feed by indivisual step..</em> row carrying the source file and line it has
 reached; while the optimized text is being written, every thousandth line adds a <em>Now optimizing
-to:</em> row carrying the same two numbers. <strong>Shell appends every one of them and folds nothing</strong>, so
-its newest row is where the run has got to: numbers that keep advancing are a run still working, and
-a list that has stopped growing on a stage whose successor has not been announced is a run that is
-not.</p>
+to:</em> row carrying the same two numbers. <strong>Each of them is a row on Shell</strong>, subject to the one
+folding <strong>Shell</strong> does: the file and line on a step row are those of the sentence the step came
+from, so a sentence that expands to more than a thousand steps — a long arc at a fine resolution —
+puts the same two numbers on two consecutive rows, and those join under the multiplier badge. And
+because the per-step feeds are solved in parallel, the numbers on successive step rows need not
+climb in strict order. What holds either way is that the newest row is where the run has got to:
+numbers that keep changing are a run still working, and a list that has stopped growing on a stage
+whose successor has not been announced is a run that is not.</p>
 <p>The counting rows are the instrument, not the stage rows. A stage with fewer than a thousand steps
 to solve, or fewer than a thousand lines to write, announces its start and then says nothing until
 it ends — so a short program crosses the whole ladder in near-silence, and that silence means
 nothing on its own.</p>
-<p><strong>A Stop ends an optimization on a success row.</strong> Stop reaches the optimizer between steps and
-between output files rather than only at the end, and what it leaves on <strong>Shell</strong> is <em>optimization
-canceled.</em> followed immediately by <em>Total N files optimized.</em> in success green — even <em>Total 0 files
-optimized.</em> arrives as a success. The count is of the files the run had opened, so a file the Stop
+<p><strong>A Stop ends an optimization on the same two closing rows as a finished one.</strong> Stop reaches the
+optimizer between steps and between output files rather than only at the end, and what it leaves
+on <strong>Shell</strong> is <em>optimization canceled.</em> followed immediately by <em>Total N files optimized.</em> in
+success green and then <em>optimization cache cleared.</em>, the run's last row — even <em>Total 0 files
+optimized.</em> arrives as a success. A Stop that lands while the per-step feeds are being solved puts
+one more row ahead of those: <em>Optimization Feed Process canceled.</em> stands where <em>Optimization
+Feedrate built.</em> would have. The count is of the files the run had opened, so a file the Stop
 landed part-way through is counted with the rest and is left on disk short. The complete ones are
 those whose own <em>File optimized:</em> row appeared before the cancel.</p>
 <h2 id="three-things-that-look-like-faults-and-are-not">Three things that look like faults and are not</h2>
 <p><strong>An English message in a translated interface is the safe answer, not a bug.</strong> Engine messages
-arrive with an id and their English text, and the interface substitutes its own translation only
-when its copy of that message matches the one the engine sent. An engine built against a different
-message set, or a message the interface has no copy of, leaves the original English in place rather
-than rendering text that might say something else. The English is the accurate text.</p>
+arrive with an id and their English text, and the interface translates by id. For a message that
+carries values — a file name, a count, a line number — it substitutes its own translation only when
+its template for that id matches the one the engine sent; an engine built against a different
+message set, or a message the interface has no entry for, leaves the original English in place
+rather than rendering text that might say something else. A message with no values in it is swapped
+on its id alone, with no comparison of wording, so an engine that has reworded such a message while
+keeping its id shows, in a translated interface, the translation of the wording it had before. In
+both cases the English the engine sent is the accurate text, and switching the interface to English
+shows every message exactly as it arrived.</p>
 <p><strong>An action refused because a run is playing is a guard, not a fault.</strong> Switching the NC runner and
 switching the controller brand are both refused while a program is playing, rather than swapping the
-parser underneath it; the refusal names the reason and asks for the run to be paused or finished
-first. It arrives on the action itself — no row is added to any of the four lists, so there is
-nothing to go looking for afterwards.</p>
+parser underneath it. The refusal is a toast that opens with the name of the action it refused and
+the status the service answered with: <em>Switch controller brand: HTTP 409: Cannot switch the
+controller brand while an NC program is playing; pause and let the current program finish first.</em>
+for a brand switch, and <em>Install NC runner: HTTP 409: Cannot switch the NC runner while an NC
+program is playing; pause and let the current program finish first.</em> for a runner installed
+through the <strong>Controller</strong> branch's <strong>Object Management</strong> menu, by a <strong>Load</strong> or a paste. The
+<em>pause</em> in it is not the part that lifts the guard: a paused run is still a playing one to this
+guard, so the switch is refused again until the program finishes or a Stop ends it. The refusal
+arrives on the action itself — no row is added to any of the four lists, so there is nothing to go
+looking for afterwards.</p>
 <p><strong>An empty Step Diagnostics list is not proof that nothing was wrong.</strong> Collision detection is off
 unless the mission turns it on, and the physics-dependent warnings — the cutter geometry checks
 raised at tool change among them — are not raised at all when physics is off. A quiet list on a run