deploy.

2026-09-15 01:12:50 +08:00
parent 2db889ad89
commit 1a75503105
99 changed files with 4168 additions and 726 deletions
@@ -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.
@@ -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>
@@ -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
@@ -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