deploy.

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

@@ -96,14 +96,16 @@ Picking the right surface is most of the difference between a specific question
 <ul>
 <li><strong>A toast</strong> — bottom right, for a few seconds, then gone. The only surface that interrupts, and
 the only one that keeps nothing itself.</li>
-<li><strong>The footer's latest line, and the recent list behind it</strong> — every toast that carried any text is
-copied here before it is shown, so this list is the toast's afterlife. Only a toast with neither
-message nor caption is skipped, and a small number of status lines are written straight here and
-never toast at all.</li>
+<li><strong>The footer's latest line, and the recent list behind it</strong> — a toast is copied here before it is
+shown, so this list is the toast's afterlife. Two kinds never arrive: a toast carrying neither
+message nor caption, and the notices Tool House, the <strong>Spindle Capability</strong> editor and the
+Controller panels raise, which are shown once and not kept. A small number of status lines go the
+other way — written straight here, and never toasted at all.</li>
 <li><strong>The footer's session strip</strong> — the middle of the bar, drawn once a run has produced something
 and empty until then.</li>
-<li><strong>The footer's background zone</strong> — the right end, drawn only while a project file operation is in
-flight, naming the operation and the path it is working on.</li>
+<li><strong>The footer's background zone</strong> — the right end, drawn only while one of the <strong>Project</strong> menu's
+operations is in flight — <strong>Close Project</strong> included — naming the operation and the path it is
+working on.</li>
 <li><strong>The Session Messages panel</strong> — on the Execution page, four lists kept by the service.</li>
 <li><strong>The Log Viewer</strong> — the file the service itself writes for the current day.</li>
 </ul>
@@ -111,12 +113,20 @@ flight, naming the operation and the path it is working on.</li>
 four lists, and the panel is where it stays.</p>
 <h2 id="messages-a-project-load-raises">Messages a project load raises</h2>
 <p>Opening or re-reading a project can report holes in it — a referenced STL missing from disk, or a
-mesh-geometry <code>.wct</code> file a raw geometry names but that is not there. <strong>None of these fail the load.</strong>
-The project opens, the body that needed the missing file simply comes up without its geometry, and
-the action still reports success. The message is the only thing that says otherwise.</p>
-<p>These messages then take a path of their own, and it has a consequence worth knowing before you rely
-on it. A project file operation runs outside any session, so the panel's four lists — which belong to
-the service, and are where everything a <em>run</em> reports stays — never see them. Instead the first five
+runner configuration the file names that would not load, leaving the project on a default one.
+<strong>None of these fail the load.</strong> The project opens, the body that needed the missing file simply
+comes up without its geometry, and the action still reports success. The message is the only thing
+that says otherwise.</p>
+<p>Two neighbouring cases go elsewhere. A mesh-geometry <code>.wct</code> file a raw geometry names but that is not
+there raises nothing here at all, because the load never opens it; the first word about it comes when
+the meshed geometry is next needed, and that message belongs to the run, so it lands in the Session
+Messages panel like any other. A side file the project names as a reference — the machine chain, the
+spindle capability, a material, a cutting parameter set — is the opposite case: a missing one fails
+the load outright, and that arrives as an error rather than as one of the messages described here.
+See <a href="projects.html">Projects</a>.</p>
+<p>These messages then take a path of their own, and it has a consequence worth knowing before that
+path is relied on. A project file operation runs outside any session, so the panel's four lists —
+which belong to the service, and are where everything a <em>run</em> reports stays — never see them. Instead the first five
 errors and warnings are toasted, anything past that goes straight to the footer's recent list, and
 one more toast says how many did not get their own. Anything milder than a warning is not surfaced in
 the window at all.</p>
@@ -126,15 +136,15 @@ read <a href="#the-service-log">the service log</a>, which has them either way.
 not.</p>
 <h2 id="the-footer">The footer</h2>
 <p>The left region is this browser's own record and nothing else's. The list behind the latest line is
-newest first, capped at a hundred entries, emptied by its <strong>Clear</strong> button and by a reload, and
-written down nowhere — nothing about it survives closing the tab. Each entry keeps the wording it
+newest first, capped at a hundred entries, emptied by its <strong>Clear</strong> button — which takes the latest
+line back to <em>Ready</em> with it — and by a reload, and written down nowhere — nothing about it survives closing the tab. Each entry keeps the wording it
 was raised in, so switching the language leaves the list as a mixture while the panel's lists
 re-render at once. The frame page describes the regions themselves: see
 <a href="the-app-window.html">The Application Window</a>.</p>
 <p><strong>Nothing marks the list as having something new in it.</strong> The button carries no badge and no dot,
 deliberately, because a toast has already drawn attention once. The consequence is the failure this
-page exists to prevent: a message raised while another screen was open, or while the window was
-behind something else, is invisible until that menu is opened by hand. Opening it after an action
+page exists to prevent: a message that never toasted at all, or one whose few seconds expired while
+the window was behind something else, is invisible until that menu is opened by hand. Opening it after an action
 that seemed to do nothing is the cheapest check available.</p>
 <p>The middle strip is the other way round — the service pushes it, so every connected browser sees the
 same run activity, and each browser keeps its own short ring of the last entries behind it. What it
@@ -149,7 +159,7 @@ appear on it at all. The lists on the service drop nothing.</p>
 header row reads <strong>Session Messages</strong> and stays visible when the panel is collapsed, so a grey strip
 with that name on it is the panel, shut.</p>
 <p><strong>The whole column can be switched off, and nothing on the page says so.</strong> The column quick-toggles
-in the middle of the menu bar include one whose tooltip reads <em>Toggle the Execution canvas &amp;
+at the right-hand end of the menu bar include one whose tooltip reads <em>Toggle the Execution canvas &amp;
 messages column</em>; with it off, neither the panel nor its header row is drawn, and the page simply
 looks like it has fewer parts. That choice is the browser's and survives a reload. The expanded or
 collapsed state of the panel itself is not: it is kept by the service, and is therefore the same for
@@ -269,14 +279,14 @@ application.</p>
 </tr>
 <tr>
 <td>what was reported while another screen was open</td>
-<td>the recent list behind it — nothing else will mention it</td>
+<td>the recent list behind it — the only copy the window keeps</td>
 </tr>
 <tr>
 <td>where a run has got to</td>
 <td>the footer's session strip</td>
 </tr>
 <tr>
-<td>whether a project file operation is still running</td>
+<td>whether one of the Project menu's operations is still running</td>
 <td>the footer's background zone</td>
 </tr>
 <tr>
@@ -297,7 +307,7 @@ application.</p>
 </tr>
 <tr>
 <td>why a project opened with pieces missing</td>
-<td>the toasts it raised, or the Log Viewer — <strong>not</strong> the Session Messages panel</td>
+<td>the footer's recent list, or the Log Viewer — <strong>not</strong> the Session Messages panel</td>
 </tr>
 <tr>
 <td>what the service recorded, shown or not</td>