factorysemantics-mes 0.4.0__tar.gz → 0.4.2__tar.gz

{factorysemantics_mes-0.4.0 → factorysemantics_mes-0.4.2}/.github/scripts/doctor_writes_nothing_of_yours.py

@@ -61,9 +61,9 @@ from plant_from_wheel import (
     PLANT,
     fail,
     install,
-    port_answers,
     print_in_the_words_the_plant_used,
     say,
+    the_port_is_back,
     until,
     venv_bin,
 )
@@ -291,8 +291,7 @@ def main() -> int:
     stopped_command = run([fsmes, "demo", PLANT, "stop"], cwd=work, env=environment)
     if stopped_command.returncode != 0:
         fail(f"`fsmes demo {PLANT} stop` exited {stopped_command.returncode}")
-    if port_answers(API):
-        fail(f"something is still listening on {API[1]} after stop")
+    the_port_is_back(API, "the dashboard")
     logs = home / "logs" / PLANT
     # The console logs last, so that they are among the most recently written
     # and `doctor` reads them: a stopped plant has no record of its processes

{factorysemantics_mes-0.4.0 → factorysemantics_mes-0.4.2}/.github/scripts/plant_from_shape.py

@@ -301,6 +301,21 @@ def port_answers(where: tuple[str, int]) -> bool:
         return False
 
 
+def the_port_is_back(where: tuple[str, int], what: str, *, ceiling: float = 30) -> None:
+    """Wait for a stopped plant's socket to close, the way the way up waits.
+
+    The same spelling as `plant_from_wheel.the_port_is_back`, kept here because
+    this script shares no code with that one on purpose. `stop` returning is
+    not the same thing as the socket being gone: on Windows a listening socket
+    can outlive the process that owned it by a moment, and one bare connect
+    straight after `stop` failed three CI jobs on 2026-10-16 on plants that had
+    stopped perfectly well. The ceiling is a grace period, not a measurement:
+    nothing here asserts a clock.
+    """
+    until(f"{what} has stopped listening on {where[1]}",
+          lambda: not port_answers(where), ceiling=ceiling, every=0.5)
+
+
 def what_is_on_screen(shape: dict, speed: float) -> None:
     """Every fact the handoff asks of a running plant, asked of this one."""
     until("the dashboard answers", lambda: ask("/health").get("status") == "ok",
@@ -475,8 +490,7 @@ def one_shape_all_the_way(shape: dict, *, repo: Path, work: Path, fsmes: Path,
         say("== stopping ==")
         run([str(fsmes), "demo", name, "stop"], cwd=work, env=started, timeout=600)
     for where, what in ((API, "the dashboard"), (OPC, "the OPC server")):
-        if port_answers(where):
-            fail(f"{what} is still listening on {where[1]} after stop")
+        the_port_is_back(where, what)
     say("  both ports are back")
 
 

{factorysemantics_mes-0.4.0 → factorysemantics_mes-0.4.2}/.github/scripts/plant_from_wheel.py

@@ -25,7 +25,9 @@ What it asserts, in order, and why each one:
   there including the counted one, the OPC replay port answers, the floor is
   watching with every machine connected and a check recorded, and at least one
   counted lot has been inspected;
-* `fsmes demo bottling stop` puts the ports back.
+* `fsmes demo bottling stop` puts the ports back **before it returns**, so
+  `fsmes demo bottling start` in the next breath starts the plant instead of
+  refusing on a port that is still closing.
 
 Facts, never seconds: every wait below is a poll for a state with a generous
 ceiling, and the times it prints are information for the Result, not gates. A
@@ -216,6 +218,80 @@ def port_answers(where: tuple[str, int]) -> bool:
         return False
 
 
+def the_port_is_back(where: tuple[str, int], what: str, *, ceiling: float = 30) -> None:
+    """Wait for a stopped plant's socket to close, the way the way up waits.
+
+    `stop` returning is not the same thing as the socket being gone: on Windows
+    a listening socket can outlive the process that owned it by a moment, and
+    one bare connect straight after `stop` failed three CI jobs on 2026-10-16
+    on plants that had stopped perfectly well. So this is the same poll for a
+    state as everything on the way up. The ceiling is a grace period, not a
+    measurement: nothing here asserts a clock.
+
+    Since `fsmes.plant.ports_are_back` the product waits for its own ports, so
+    after a `stop` this now returns at once - `the_ports_are_back_already`
+    below is what holds it to that. This stays for the callers that ask after
+    something was *killed*, where nothing waited for anything.
+    """
+    until(f"{what} has stopped listening on {where[1]}",
+          lambda: not port_answers(where), ceiling=ceiling, every=0.5)
+
+
+def the_ports_are_back_already(what_happened: str) -> None:
+    """Ask each port once, with no poll, straight after a command returned.
+
+    A poll would pass whether the product waited or not, which is the whole
+    question here: `fsmes.plant.stop` holds the command until the ports its
+    processes were listening on are free, because on Windows a listening
+    socket outlives its process by about two seconds and a start inside those
+    two seconds used to refuse - naming a program that no longer existed. One
+    connect each, now, is the only shape of check that can tell the difference.
+    """
+    still = [f"{where[0]}:{where[1]} ({what})"
+             for where, what in ((API, "the dashboard"), (OPC, "the OPC server"))
+             if port_answers(where)]
+    if still:
+        fail(f"{what_happened} returned while {', '.join(still)} was still listening. "
+             "`stop` is meant to wait for its own ports before it comes back, so that "
+             "the next start does not meet a port that is still closing.")
+    say(f"  both ports were already free when {what_happened} returned")
+
+
+def and_a_start_in_the_next_breath_works(fsmes: Path, work: Path, environment: dict,
+                                         speed: float) -> None:
+    """Stop, then start again at once - the thing a person actually types.
+
+    On 2026-10-21 every Windows cell of this project's CI waited about two
+    seconds after `stop` for the plant's socket to disappear, and every Linux
+    cell waited zero (PR #184). CI learned to wait; the product had not, so on
+    a Windows PC `fsmes demo bottling stop` followed by `fsmes demo bottling
+    start` said *127.0.0.1:8010 is already in use ... Stop that program* about
+    the plant that had just been stopped. This is that pair of commands, in
+    that order, with nothing between them.
+    """
+    say("== and a start in the next breath: fsmes demo bottling start ==")
+    again = subprocess.run([str(fsmes), "demo", PLANT, "start", "--speed", str(speed)],
+                           cwd=work, env=environment, capture_output=True,
+                           timeout=2700, **AS_WORDS)
+    said = (again.stdout or "") + (again.stderr or "")
+    say(said)
+    if "already in use" in said:
+        fail("the start refused a port that nothing is holding: this is the sentence "
+             "the whole change exists to remove")
+    if again.returncode != 0:
+        fail(f"`fsmes demo {PLANT} start` exited {again.returncode} straight after a stop")
+    until("the dashboard answers again", lambda: ask("/health").get("status") == "ok",
+          ceiling=300)
+
+    say("== stopping again ==")
+    last = subprocess.run([str(fsmes), "demo", PLANT, "stop"], cwd=work, env=environment,
+                          capture_output=True, timeout=600, **AS_WORDS)
+    say((last.stdout or "") + (last.stderr or ""))
+    if last.returncode != 0:
+        fail(f"`fsmes demo {PLANT} stop` exited {last.returncode} the second time")
+    the_ports_are_back_already("the second stop")
+
+
 def the_plant_is_what_the_lab_runs(speed: float) -> None:
     """Every fact the handoff asks for, asked of the running plant."""
     until("the dashboard answers", lambda: ask("/health").get("status") == "ok",
@@ -341,12 +417,11 @@ def main() -> int:
         if stopped.returncode != 0:
             fail(f"`fsmes demo {PLANT} stop` exited {stopped.returncode}")
 
-    for where, what in ((API, "the dashboard"), (OPC, "the OPC server")):
-        if port_answers(where):
-            fail(f"{what} is still listening on {where[1]} after stop")
-    say("  both ports are back")
+    the_ports_are_back_already("the stop")
+    and_a_start_in_the_next_breath_works(fsmes, work, environment, args.speed)
 
-    say(f"\nThe wheel brought {PLANT} up on {sys.platform} and put it back down.")
+    say(f"\nThe wheel brought {PLANT} up on {sys.platform}, put it back down, and "
+        "started it again in the next breath.")
     return 0
 
 

{factorysemantics_mes-0.4.0 → factorysemantics_mes-0.4.2}/.github/scripts/recover_a_half_dead_plant.py

@@ -21,7 +21,10 @@ wheel, then kill the one process everything else needs, the dashboard and API
   plant, not a stopped one;
 * `fsmes demo bottling stop` recovers it with no flag, exits 0, and says what
   it found;
-* `fsmes demo bottling` brings the plant back up afterwards.
+* `fsmes demo bottling` brings the plant back up afterwards;
+* `fsmes demo bottling stop --force` - the flag `fsmes fleet stop` puts in a
+  person's head, and the one he typed on 2026-10-15 - is taken, answered in a
+  sentence that names the command it belongs to, and stops the plant anyway.
 
 And, because the same person's first question was that `fsmes` was not on
 PATH at all: `python -m fsmes --version` answers in the same venv.
@@ -65,6 +68,7 @@ from plant_from_wheel import (
     port_answers,
     print_in_the_words_the_plant_used,
     say,
+    the_port_is_back,
     until,
     venv_bin,
 )
@@ -191,8 +195,7 @@ def main() -> int:
         fail("stop recovered the plant without saying what it found; a command that "
              f"silently does more than it was asked is worse: {recovery!r}")
     for where, what in ((API, "the dashboard"), (OPC, "the OPC server")):
-        if port_answers(where):
-            fail(f"{what} is still listening on {where[1]} after stop")
+        the_port_is_back(where, what)
     say("  both ports are back")
 
     say(f"== and again: fsmes demo {PLANT} --speed {args.speed:g} ==")
@@ -202,10 +205,28 @@ def main() -> int:
     try:
         until("the dashboard answers again", health_says_ok, ceiling=300)
     finally:
-        run([fsmes, "demo", PLANT, "stop"], cwd=work, env=environment)
+        # Taken down with the word he actually typed on 2026-10-15. The plant
+        # is up and answering here, so the flag is the only thing under test.
+        say(f"== the word he typed: fsmes demo {PLANT} stop --force ==")
+        last = run([fsmes, "demo", PLANT, "stop", "--force"], cwd=work, env=environment)
+
+    guessed = (last.stdout or "") + (last.stderr or "")
+    if last.returncode != 0:
+        fail(f"`fsmes demo {PLANT} stop --force` exited {last.returncode}; the flag is "
+             "taken and answered, never refused - refusing it is what cost him "
+             "2026-10-13 and again 2026-10-15")
+    if "No such option" in guessed:
+        fail(f"typer refused the flag `fsmes fleet stop` had put in his head: {guessed!r}")
+    if "stop needs no --force here" not in guessed:
+        fail("the flag was swallowed and nothing said why it was not needed; the "
+             f"sentence is the whole reason for accepting it: {guessed!r}")
+    for where, what in ((API, "the dashboard"), (OPC, "the OPC server")):
+        the_port_is_back(where, what)
+    say("  the flag was answered in a sentence and the plant still went down")
 
     say(f"\nA half-dead {PLANT} on {sys.platform} was described, recovered and started "
-        "again, with no flag and nothing killed by hand.")
+        "again, with no flag and nothing killed by hand - and the flag he guessed was "
+        "answered in words instead of refused.")
     return 0
 
 

{factorysemantics_mes-0.4.0 → factorysemantics_mes-0.4.2}/.github/workflows/ci.yml

@@ -297,7 +297,9 @@ jobs:
     # kill the API process and nothing else - and proves the product talks a
     # person out of it: `status` names the process that is gone and the log
     # that says why, `stop` recovers it with no flag, and the plant starts
-    # again afterwards.
+    # again afterwards - and `stop --force`, the flag `fsmes fleet stop` puts
+    # in a person's head and the one he typed on 2026-10-15, is answered in a
+    # sentence rather than refused with `No such option`.
     #
     # Beside `wheel-plant` and on both runners for the same reason: it is all
     # processes, pids and console output, which is exactly where Windows
@@ -315,7 +317,7 @@ jobs:
           python-version: "3.12"
       - run: python -m pip install --upgrade pip build
       - run: python -m build --wheel
-      - name: A half-dead plant is described, recovered with no flag, and started again
+      - name: A half-dead plant is described, recovered with no flag, started again, and stopped with the flag people guess
         shell: bash
         run: python .github/scripts/recover_a_half_dead_plant.py --wheel "$(ls dist/*.whl)" --speed 60
 

{factorysemantics_mes-0.4.0 → factorysemantics_mes-0.4.2}/.github/workflows/scorecard.yml

@@ -18,7 +18,7 @@ jobs:
       - uses: actions/checkout@v7
         with:
           persist-credentials: false
-      - uses: ossf/scorecard-action@v2.4.4
+      - uses: ossf/scorecard-action@v2.5.0
         with:
           results_file: results.sarif
           results_format: sarif

{factorysemantics_mes-0.4.0 → factorysemantics_mes-0.4.2}/.gitignore

@@ -78,3 +78,8 @@ lab-results/
 # Skill zips, built by `fsmes skills-zip` and attached to a release.
 /skills-dist/
 /*.zip
+
+# Where `scripts/record-kill-a-node.sh` writes. A recording is a file made on
+# one machine on one day; what belongs in the repository is the script that
+# makes it, and the one GIF under docs/assets/ that a page points at.
+recordings/

{factorysemantics_mes-0.4.0 → factorysemantics_mes-0.4.2}/CHANGELOG.md

@@ -10,7 +10,81 @@ goes under Honesty with a migration line, so plant people can find it.
 
 ## [Unreleased]
 
-Nothing yet.
+## [0.4.2] — 2026-10-26
+
+### Fixed
+
+- **The Maintenance screen loads again on a PostgreSQL plant.** Early
+  migrations had made nine status and kind columns native PostgreSQL enums;
+  when `assigned` became a maintenance status (0.3.0), no migration added it,
+  so every PostgreSQL plant whose schema came from `fsmes init-db` - new or
+  upgraded - refused the word, and
+  `/maintenance/due`, `/shift` and `/roster` answered 500 - the screen said
+  "reconnecting..." for good and the dispatcher could not assign work. A new
+  migration turns those columns into plain text, as the code always declared
+  them; run `fsmes init-db` (or `fsmes plant migrate`) after upgrading. No
+  data changes. SQLite plants were never affected. A
+  test now runs the shipped migrations on PostgreSQL and fails if the database
+  would refuse any value the code can write.
+- **The AI tab's header dot says "live" now, not "connecting…" forever.**
+  The page never told the dot anything, so it kept the words it was born
+  with. Every screen now sets the dot through one shared `FS.live`; the AI
+  tab sets it when a tab's list comes back, and "reconnecting…" when one
+  fails. Six other screens (Orders, Station, Quality, Ops, Admin,
+  Instructions) and Analysis said "live" with a grey dot; it is green now
+  like the rest.
+- **The orders page opens with the New-order form closed.** The permission
+  check that hides what a person may not use also *showed* everything they
+  may use, the closed form included. It now only takes away what it hid
+  itself.
+
+## [0.4.1] — 2026-10-23
+
+### Added
+
+- **A recording of a node being killed, on the README and the redundancy
+  page.** Two nodes of the bottling plant side by side, `docker kill` on the
+  one holding the `reader` lease, and the other one reading the machines a few
+  seconds later. `bash scripts/record-kill-a-node.sh` makes it again from a
+  checkout, so the picture can be of the version people install rather than of
+  whatever the box looked like the day it was first made. A developer tool: it
+  needs Docker, `ffmpeg` and a Python with Playwright, it is not in the wheel,
+  it is not in CI, and it is not asked to run on Windows.
+
+### Fixed
+
+- **`fsmes demo <plant> stop --force` answers in words instead of refusing.**
+  `fsmes fleet stop` names `--force` when it will not touch a plant that is
+  not answering, so that is the word people arrive with — and typed on the
+  demo command it printed typer's bare `No such option: --force` and stopped
+  nothing. The demo path has passed `--force` to the fleet by itself for two
+  releases, so the flag is unnecessary rather than missing. It is now accepted
+  (hidden, not advertised) and answered in one sentence naming the command it
+  belongs to, and the plant stops either way. The gate is unchanged: `--force`
+  gives up liveness, never ownership, and `fsmes fleet stop` keeps asking
+  for it.
+- **The upgrade pages say what to do when two Pythons disagree.** After
+  `py -m pip install --upgrade factorysemantics-mes`, `fsmes --version` can
+  still print the old version, because the `fsmes` on PATH belongs to pipx or
+  to another Python. [Upgrading between versions](docs/operate/upgrade.md),
+  [run it on your own box](docs/operate/run-it-on-your-own-box.md) and the
+  assistant folder's install page now say how to tell (`py -m fsmes --version`
+  against `fsmes --version`; `where fsmes`, or `which`) and the rule: upgrade
+  the one that owns the command you type.
+- **On Windows, stopping a plant and starting it again in the next breath
+  works.** `fsmes demo <plant> stop` no longer comes back while the plant's
+  ports are still closing. A listening socket there outlives the process that
+  owned it by about two seconds — every Windows cell of this project's CI
+  measured that, and every Linux cell measured zero — and a start inside those
+  two seconds refused with *127.0.0.1:8010 is already in use … Stop that
+  program*, about the plant that had just been stopped and a process that no
+  longer existed. `stop` now holds the command until the ports its own
+  processes were listening on are free, with an eight-second grace period, and
+  says which port it waited on only when it had to wait: on Linux the output
+  is unchanged. If the grace period is not enough, it says which port is still
+  closing rather than claiming it is done, and a start that meets a plant's own
+  closing socket now says to wait a moment rather than to go and stop a
+  program that is not there.
 
 ## [0.4.0] — 2026-10-16
 
@@ -5064,7 +5138,9 @@ number in it comes from a simulated plant.
   MES was not watching. Unlabelled downtime is reported as unlabelled. These
   are the house rules and they are tested.
 
-[Unreleased]: https://github.com/factorysemantics/factorysemantics-mes/compare/v0.4.0...HEAD
+[Unreleased]: https://github.com/factorysemantics/factorysemantics-mes/compare/v0.4.2...HEAD
+[0.4.2]: https://github.com/factorysemantics/factorysemantics-mes/releases/tag/v0.4.2
+[0.4.1]: https://github.com/factorysemantics/factorysemantics-mes/releases/tag/v0.4.1
 [0.4.0]: https://github.com/factorysemantics/factorysemantics-mes/releases/tag/v0.4.0
 [0.3.1]: https://github.com/factorysemantics/factorysemantics-mes/releases/tag/v0.3.1
 [0.3.0]: https://github.com/factorysemantics/factorysemantics-mes/releases/tag/v0.3.0

{factorysemantics_mes-0.4.0 → factorysemantics_mes-0.4.2}/CITATION.cff

@@ -8,6 +8,6 @@ authors:
 repository-code: https://github.com/factorysemantics/factorysemantics-mes
 url: https://factorysemantics.com
 license: Apache-2.0
-version: 0.4.0
-date-released: "2026-10-16"
+version: 0.4.2
+date-released: "2026-10-26"
 abstract: An open-source, modular, agent-native Manufacturing Execution System with OPC UA connectivity, honest OEE, quality with SPC and gauges, scheduling, traceability, an ERPNext connector and an MCP agent surface.

{factorysemantics_mes-0.4.0 → factorysemantics_mes-0.4.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: factorysemantics-mes
-Version: 0.4.0
+Version: 0.4.2
 Summary: An open-source, modular, agent-native Manufacturing Execution System
 Project-URL: Homepage, https://factorysemantics.com
 Project-URL: Documentation, https://docs.factorysemantics.com
@@ -241,7 +241,7 @@ Provides-Extra: dev
 Requires-Dist: playwright>=1.49; extra == 'dev'
 Requires-Dist: pytest-asyncio>=0.24; extra == 'dev'
 Requires-Dist: pytest>=8; extra == 'dev'
-Requires-Dist: ruff==0.16.10; extra == 'dev'
+Requires-Dist: ruff==0.17.1; extra == 'dev'
 Provides-Extra: docs
 Requires-Dist: mike>=2.1; extra == 'docs'
 Requires-Dist: mkdocs-material>=9.6; extra == 'docs'
@@ -267,12 +267,18 @@ Run one module on a laptop for a five-person shop, or the full suite across a fl
 
 ![A walk through a running plant: the floor, losses by machine, a stop on the filler's timeline, the SPC sample behind a low fill height, and the rule trace behind a maintenance job](docs/assets/walk.gif)
 
-> **Status: pre-alpha, 0.4.0, running simulated plants only (as of 2026-10-16).** Orders and routings, OPC UA execution, OEE, quality with SPC and gauges, maintenance, finite-capacity scheduling, serialisation and genealogy, a 95-tool MCP agent surface, an ERPNext connector, and a scoring harness that measures whether the MES told the truth about its plant. **New since 0.2.0:** the plant packs travel inside the package, so `pipx install factorysemantics-mes` and then `fsmes demo bottling` bring up a bottling plant on a machine with no checkout, on Linux and on Windows; an SPC tab with I-MR, X̄/R and p charts where a point can be pressed for the reading, the rules it broke, the gauge, the machine's state and the rest of the line; count data — how many units a lot sent back and what for; maintenance work that reaches the right trade by itself, and a supervisor's screen that reads like a plant; a chat on the AI tab that explains the chart in front of it (it needs `ANTHROPIC_API_KEY` and costs about $0.12 a question; the floor assistant needs a local [Ollama](https://ollama.com)); every floor row carrying the shift it happened on; and a simulated line that plays a whole eight-hour shift with a four-link chain of cause in it — a chiller order nobody started, its outlet climbing, the product reaching the filler colder, fill heights a millimetre and a half low — with no limit broken anywhere, which is the test. [The release page](docs/releases/0.3.0.md) is the whole of it. **New in 0.3.1:** the first run on a Windows PC recovers itself — `py -m fsmes` when the installer's folder is not on PATH, a half-dead plant named process by process by `status`, and `stop` clearing it with no flag; a simulated plant shaped like your own, three commands from a pip install; one folder of plain pages that lets whatever AI assistant you already use walk you through install and shadow mode, with no access to your machine; and `fsmes doctor`, one file to paste when something is wrong, with every value in it replaced by its shape. [The 0.3.1 release page](docs/releases/0.3.1.md) is the whole of that. **New in 0.4.0:** a plant can run as two copies on two boxes against one PostgreSQL and keep counting when one of them dies — the jobs that must run once (reading the machines, the simulated floor, pruning the history) are held one at a time by a lease in the database, the counts carry on rather than starting over, nobody signs in again, and `bash scripts/kill-a-node.sh` brings the whole thing up in Docker and pulls the plug on a node so you can watch it. [The 0.4.0 release page](docs/releases/0.4.0.md) is the whole of that. **Not yet:** a real plant — none has run this, and making a first one possible in shadow mode, beside the MES already in charge, is what shadow mode is for; [the guide](docs/operate/first-plant.md) is written and untried. Also not yet: ERPNext Job Card confirmations — whether Job Card is the right place at all is a question put to the ERPNext community on 2026-09-10 and not yet answered; the thin Frappe app that would list the connector on the Marketplace ([decision 0008](docs/decisions/0008-erp-connectors-are-modules.md)); and PLC write-back beyond a guarded recommendation queue. See [ROADMAP.md](ROADMAP.md) for what has landed and what is next, [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md) for the design, [docs/LANDSCAPE.md](docs/LANDSCAPE.md) for why this project should exist at all, [docs/operate/compatibility.md](docs/operate/compatibility.md) for what has been tested against what and when, and [docs.factorysemantics.com](https://docs.factorysemantics.com) for the documentation.
+> **Status: pre-alpha, 0.4.2, running simulated plants only (as of 2026-10-26).** Orders and routings, OPC UA execution, OEE, quality with SPC and gauges, maintenance, finite-capacity scheduling, serialisation and genealogy, a 95-tool MCP agent surface, an ERPNext connector, and a scoring harness that measures whether the MES told the truth about its plant. **New since 0.2.0:** the plant packs travel inside the package, so `pipx install factorysemantics-mes` and then `fsmes demo bottling` bring up a bottling plant on a machine with no checkout, on Linux and on Windows; an SPC tab with I-MR, X̄/R and p charts where a point can be pressed for the reading, the rules it broke, the gauge, the machine's state and the rest of the line; count data — how many units a lot sent back and what for; maintenance work that reaches the right trade by itself, and a supervisor's screen that reads like a plant; a chat on the AI tab that explains the chart in front of it (it needs `ANTHROPIC_API_KEY` and costs about $0.12 a question; the floor assistant needs a local [Ollama](https://ollama.com)); every floor row carrying the shift it happened on; and a simulated line that plays a whole eight-hour shift with a four-link chain of cause in it — a chiller order nobody started, its outlet climbing, the product reaching the filler colder, fill heights a millimetre and a half low — with no limit broken anywhere, which is the test. [The release page](docs/releases/0.3.0.md) is the whole of it. **New in 0.3.1:** the first run on a Windows PC recovers itself — `py -m fsmes` when the installer's folder is not on PATH, a half-dead plant named process by process by `status`, and `stop` clearing it with no flag; a simulated plant shaped like your own, three commands from a pip install; one folder of plain pages that lets whatever AI assistant you already use walk you through install and shadow mode, with no access to your machine; and `fsmes doctor`, one file to paste when something is wrong, with every value in it replaced by its shape. [The 0.3.1 release page](docs/releases/0.3.1.md) is the whole of that. **New in 0.4.0:** a plant can run as two copies on two boxes against one PostgreSQL and keep counting when one of them dies — the jobs that must run once (reading the machines, the simulated floor, pruning the history) are held one at a time by a lease in the database, the counts carry on rather than starting over, nobody signs in again, and `bash scripts/kill-a-node.sh` brings the whole thing up in Docker and pulls the plug on a node so you can watch it. [The 0.4.0 release page](docs/releases/0.4.0.md) is the whole of that. **New in 0.4.1:** an evening on a Windows PC that goes cleanly — `stop` waits until the plant's own ports are free so a start in the next breath works, `stop --force` is answered in a sentence instead of refused, and three pages say how to tell which Python owns the `fsmes` you type; nothing in the plant changed. [The 0.4.1 release page](docs/releases/0.4.1.md) is the whole of that. **New in 0.4.2:** the Maintenance screen loads again on a plant that runs on PostgreSQL — since 0.3.0 the database refused one word the screen needs — after the upgrade and one `fsmes init-db`; SQLite plants never had the fault. [The 0.4.2 release page](docs/releases/0.4.2.md) is the whole of that. **Not yet:** a real plant — none has run this, and making a first one possible in shadow mode, beside the MES already in charge, is what shadow mode is for; [the guide](docs/operate/first-plant.md) is written and untried. Also not yet: ERPNext Job Card confirmations — whether Job Card is the right place at all is a question put to the ERPNext community on 2026-09-10 and not yet answered; the thin Frappe app that would list the connector on the Marketplace ([decision 0008](docs/decisions/0008-erp-connectors-are-modules.md)); and PLC write-back beyond a guarded recommendation queue. See [ROADMAP.md](ROADMAP.md) for what has landed and what is next, [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md) for the design, [docs/LANDSCAPE.md](docs/LANDSCAPE.md) for why this project should exist at all, [docs/operate/compatibility.md](docs/operate/compatibility.md) for what has been tested against what and when, and [docs.factorysemantics.com](https://docs.factorysemantics.com) for the documentation.
 >
 > **Nothing on this page is measured on a real plant.** Every number in this repository comes from a simulated line and says so where it appears.
 
 ---
 
+**One plant on two boxes: a real `docker kill` on the node reading the machines, and the other one picks them up.**
+
+![One bottling plant running as two nodes side by side, each on its own address; a real docker kill on node a, which is reading the machines; node b taking the machines over seven seconds later with the counts carried across; node a started again and answering, as a standby](docs/assets/kill-a-node.gif)
+
+Node a held the machines and was killed; node b was reading them 6.6 seconds later; node a answered again 1.2 seconds after it was started, holding nothing. Two things in it are staged and nothing else is: the yellow line is the dashboard's own header line, enlarged so it can be read at this size, and the grey "no answer" panel is drawn by the recorder over a page that is really greying itself and saying "reconnecting". `bash scripts/record-kill-a-node.sh` makes the whole recording again from a checkout — kill included — so this can be a picture of the version you install. [What a failover costs](docs/operate/redundancy.md#what-a-failover-costs).
+
 ## Why this exists
 
 Three facts, verified 2026-08-28 (sources in [docs/LANDSCAPE.md](docs/LANDSCAPE.md)):

{factorysemantics_mes-0.4.0 → factorysemantics_mes-0.4.2}/README.md

@@ -8,12 +8,18 @@ Run one module on a laptop for a five-person shop, or the full suite across a fl
 
 ![A walk through a running plant: the floor, losses by machine, a stop on the filler's timeline, the SPC sample behind a low fill height, and the rule trace behind a maintenance job](docs/assets/walk.gif)
 
-> **Status: pre-alpha, 0.4.0, running simulated plants only (as of 2026-10-16).** Orders and routings, OPC UA execution, OEE, quality with SPC and gauges, maintenance, finite-capacity scheduling, serialisation and genealogy, a 95-tool MCP agent surface, an ERPNext connector, and a scoring harness that measures whether the MES told the truth about its plant. **New since 0.2.0:** the plant packs travel inside the package, so `pipx install factorysemantics-mes` and then `fsmes demo bottling` bring up a bottling plant on a machine with no checkout, on Linux and on Windows; an SPC tab with I-MR, X̄/R and p charts where a point can be pressed for the reading, the rules it broke, the gauge, the machine's state and the rest of the line; count data — how many units a lot sent back and what for; maintenance work that reaches the right trade by itself, and a supervisor's screen that reads like a plant; a chat on the AI tab that explains the chart in front of it (it needs `ANTHROPIC_API_KEY` and costs about $0.12 a question; the floor assistant needs a local [Ollama](https://ollama.com)); every floor row carrying the shift it happened on; and a simulated line that plays a whole eight-hour shift with a four-link chain of cause in it — a chiller order nobody started, its outlet climbing, the product reaching the filler colder, fill heights a millimetre and a half low — with no limit broken anywhere, which is the test. [The release page](docs/releases/0.3.0.md) is the whole of it. **New in 0.3.1:** the first run on a Windows PC recovers itself — `py -m fsmes` when the installer's folder is not on PATH, a half-dead plant named process by process by `status`, and `stop` clearing it with no flag; a simulated plant shaped like your own, three commands from a pip install; one folder of plain pages that lets whatever AI assistant you already use walk you through install and shadow mode, with no access to your machine; and `fsmes doctor`, one file to paste when something is wrong, with every value in it replaced by its shape. [The 0.3.1 release page](docs/releases/0.3.1.md) is the whole of that. **New in 0.4.0:** a plant can run as two copies on two boxes against one PostgreSQL and keep counting when one of them dies — the jobs that must run once (reading the machines, the simulated floor, pruning the history) are held one at a time by a lease in the database, the counts carry on rather than starting over, nobody signs in again, and `bash scripts/kill-a-node.sh` brings the whole thing up in Docker and pulls the plug on a node so you can watch it. [The 0.4.0 release page](docs/releases/0.4.0.md) is the whole of that. **Not yet:** a real plant — none has run this, and making a first one possible in shadow mode, beside the MES already in charge, is what shadow mode is for; [the guide](docs/operate/first-plant.md) is written and untried. Also not yet: ERPNext Job Card confirmations — whether Job Card is the right place at all is a question put to the ERPNext community on 2026-09-10 and not yet answered; the thin Frappe app that would list the connector on the Marketplace ([decision 0008](docs/decisions/0008-erp-connectors-are-modules.md)); and PLC write-back beyond a guarded recommendation queue. See [ROADMAP.md](ROADMAP.md) for what has landed and what is next, [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md) for the design, [docs/LANDSCAPE.md](docs/LANDSCAPE.md) for why this project should exist at all, [docs/operate/compatibility.md](docs/operate/compatibility.md) for what has been tested against what and when, and [docs.factorysemantics.com](https://docs.factorysemantics.com) for the documentation.
+> **Status: pre-alpha, 0.4.2, running simulated plants only (as of 2026-10-26).** Orders and routings, OPC UA execution, OEE, quality with SPC and gauges, maintenance, finite-capacity scheduling, serialisation and genealogy, a 95-tool MCP agent surface, an ERPNext connector, and a scoring harness that measures whether the MES told the truth about its plant. **New since 0.2.0:** the plant packs travel inside the package, so `pipx install factorysemantics-mes` and then `fsmes demo bottling` bring up a bottling plant on a machine with no checkout, on Linux and on Windows; an SPC tab with I-MR, X̄/R and p charts where a point can be pressed for the reading, the rules it broke, the gauge, the machine's state and the rest of the line; count data — how many units a lot sent back and what for; maintenance work that reaches the right trade by itself, and a supervisor's screen that reads like a plant; a chat on the AI tab that explains the chart in front of it (it needs `ANTHROPIC_API_KEY` and costs about $0.12 a question; the floor assistant needs a local [Ollama](https://ollama.com)); every floor row carrying the shift it happened on; and a simulated line that plays a whole eight-hour shift with a four-link chain of cause in it — a chiller order nobody started, its outlet climbing, the product reaching the filler colder, fill heights a millimetre and a half low — with no limit broken anywhere, which is the test. [The release page](docs/releases/0.3.0.md) is the whole of it. **New in 0.3.1:** the first run on a Windows PC recovers itself — `py -m fsmes` when the installer's folder is not on PATH, a half-dead plant named process by process by `status`, and `stop` clearing it with no flag; a simulated plant shaped like your own, three commands from a pip install; one folder of plain pages that lets whatever AI assistant you already use walk you through install and shadow mode, with no access to your machine; and `fsmes doctor`, one file to paste when something is wrong, with every value in it replaced by its shape. [The 0.3.1 release page](docs/releases/0.3.1.md) is the whole of that. **New in 0.4.0:** a plant can run as two copies on two boxes against one PostgreSQL and keep counting when one of them dies — the jobs that must run once (reading the machines, the simulated floor, pruning the history) are held one at a time by a lease in the database, the counts carry on rather than starting over, nobody signs in again, and `bash scripts/kill-a-node.sh` brings the whole thing up in Docker and pulls the plug on a node so you can watch it. [The 0.4.0 release page](docs/releases/0.4.0.md) is the whole of that. **New in 0.4.1:** an evening on a Windows PC that goes cleanly — `stop` waits until the plant's own ports are free so a start in the next breath works, `stop --force` is answered in a sentence instead of refused, and three pages say how to tell which Python owns the `fsmes` you type; nothing in the plant changed. [The 0.4.1 release page](docs/releases/0.4.1.md) is the whole of that. **New in 0.4.2:** the Maintenance screen loads again on a plant that runs on PostgreSQL — since 0.3.0 the database refused one word the screen needs — after the upgrade and one `fsmes init-db`; SQLite plants never had the fault. [The 0.4.2 release page](docs/releases/0.4.2.md) is the whole of that. **Not yet:** a real plant — none has run this, and making a first one possible in shadow mode, beside the MES already in charge, is what shadow mode is for; [the guide](docs/operate/first-plant.md) is written and untried. Also not yet: ERPNext Job Card confirmations — whether Job Card is the right place at all is a question put to the ERPNext community on 2026-09-10 and not yet answered; the thin Frappe app that would list the connector on the Marketplace ([decision 0008](docs/decisions/0008-erp-connectors-are-modules.md)); and PLC write-back beyond a guarded recommendation queue. See [ROADMAP.md](ROADMAP.md) for what has landed and what is next, [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md) for the design, [docs/LANDSCAPE.md](docs/LANDSCAPE.md) for why this project should exist at all, [docs/operate/compatibility.md](docs/operate/compatibility.md) for what has been tested against what and when, and [docs.factorysemantics.com](https://docs.factorysemantics.com) for the documentation.
 >
 > **Nothing on this page is measured on a real plant.** Every number in this repository comes from a simulated line and says so where it appears.
 
 ---
 
+**One plant on two boxes: a real `docker kill` on the node reading the machines, and the other one picks them up.**
+
+![One bottling plant running as two nodes side by side, each on its own address; a real docker kill on node a, which is reading the machines; node b taking the machines over seven seconds later with the counts carried across; node a started again and answering, as a standby](docs/assets/kill-a-node.gif)
+
+Node a held the machines and was killed; node b was reading them 6.6 seconds later; node a answered again 1.2 seconds after it was started, holding nothing. Two things in it are staged and nothing else is: the yellow line is the dashboard's own header line, enlarged so it can be read at this size, and the grey "no answer" panel is drawn by the recorder over a page that is really greying itself and saying "reconnecting". `bash scripts/record-kill-a-node.sh` makes the whole recording again from a checkout — kill included — so this can be a picture of the version you install. [What a failover costs](docs/operate/redundancy.md#what-a-failover-costs).
+
 ## Why this exists
 
 Three facts, verified 2026-08-28 (sources in [docs/LANDSCAPE.md](docs/LANDSCAPE.md)):

factorysemantics_mes-0.4.2/docker/docker-compose.record.yml

@@ -0,0 +1,22 @@
+# Recording only. Lay this over `docker-compose.redundant.yml` to give each
+# node its own address on the host, so one browser page can watch both at
+# once:
+#
+#   docker compose -p mes-record \
+#     -f docker/docker-compose.redundant.yml \
+#     -f docker/docker-compose.record.yml up -d node-a node-b
+#
+# The demo itself keeps the one address on :8000 and hides which node answers,
+# which is the point of it — and the wrong thing for a recording that has to
+# show a node dying. `bash scripts/record-kill-a-node.sh` uses this file and
+# its own project name; nothing here is part of the product.
+#
+# The ports come from the environment so two recordings, or a recording beside
+# the plain `mes-two-nodes` demo, do not fight over them.
+services:
+  node-a:
+    ports:
+      - "127.0.0.1:${FSMES_RECORD_PORT_A:-8001}:8010"
+  node-b:
+    ports:
+      - "127.0.0.1:${FSMES_RECORD_PORT_B:-8002}:8010"

{factorysemantics_mes-0.4.0 → factorysemantics_mes-0.4.2}/docs/operate/compatibility.md

@@ -1,6 +1,6 @@
 # Compatibility
 
-*Explanation. What has actually been tested against what, as of 2026-10-12 — the state of `main` that 0.3.0 is cut from. "Untested" is a fact, not a warning label.*
+*Explanation. What has actually been tested against what, as of 2026-10-26 — the state of `main` that 0.4.2 is cut from. "Untested" is a fact, not a warning label.*
 
 **Every row states the date it was last checked and what was run on that
 date.** A row with no date is a row nobody can age.
@@ -8,18 +8,18 @@ date.** A row with no date is a row nobody can age.
 | Neighbour | Status | Last checked | Evidence |
 |---|---|---|---|
 | **KEPServerEX** (OPC UA) | tested in the lab | **before 2026-09-08, exact date not recorded** | `labs/kepsim`: a trial server fed by ODBC from generated line data; `fsmes opc-verify` against it; certificate exchange and SignAndEncrypt. It was run in the private era and has not been run since the repository went public — nothing in CI touches it |
-| **The bundled OPC UA replay server** | tested continuously | 2026-10-12 | every scored run, and CI on every pull request |
+| **The bundled OPC UA replay server** | tested continuously | 2026-10-26 | every scored run, and CI on every pull request |
 | Other OPC UA servers (Ignition, Siemens, Prosys) | **untested** | never | nothing here has been on the other end of one. The client is `asyncua`; the tag map is the only server-specific part |
 | **ERP connectors** | see the table below | see below | they have rules of their own, and each row carries its own date |
-| **PostgreSQL 16.15** | tested continuously | 2026-10-12 | the `postgres` cell in CI: `alembic upgrade head` from an empty database and then the whole suite, against a PostgreSQL 16.15 service container pinned by digest, on every pull request. Also the Compose file and the cutlery plant's public demo |
-| **SQLite** | tested continuously | 2026-10-12 | the default. The whole suite runs on in-memory SQLite on every pull request, on Ubuntu and Windows, Python 3.12 and 3.13; `wheel-demo` runs `fsmes demo` on a SQLite file from the built wheel, and `upgrade_from_previous_release.sh` upgrades a database made by whatever wheel PyPI serves that day, which is 0.2.0 until 0.3.0 is tagged; `wheel-plant` starts the bottling plant on a SQLite file from the built wheel on Ubuntu and on Windows. Version: whatever CPython ships |
-| **Claude Code** as an MCP client | tested | scoring 2026-10-12; **the live-model run's date is not recorded** | the agent evals drive it headless. `tests/test_agent_eval.py` scores them on every pull request; the run that puts a real model against the live tool surface is `fsmes agent-eval`, a command a person types, and nothing records when it last ran |
+| **PostgreSQL 16.15** | tested continuously | 2026-10-26 | the `postgres` cell in CI: `alembic upgrade head` from an empty database and then the whole suite, against a PostgreSQL 16.15 service container pinned by digest, on every pull request. The suite builds its own schema from the model, so until 2026-10-25 nothing checked that the schema the migrations build accepts every word the code writes — and from 0.3.0 to 0.4.1 it did not, which cost every PostgreSQL plant its Maintenance screen. Since [#200](https://github.com/factorysemantics/factorysemantics-mes/pull/200) two tests in that cell build the schema with the shipped migrations and write every such word into it. Also the Compose file and the cutlery plant's public demo |
+| **SQLite** | tested continuously | 2026-10-26 | the default. The whole suite runs on in-memory SQLite on every pull request, on Ubuntu and Windows, Python 3.12 and 3.13; `wheel-demo` runs `fsmes demo` on a SQLite file from the built wheel, and `upgrade_from_previous_release.sh` upgrades a database made by whatever wheel PyPI serves that day, which is 0.4.1 until 0.4.2 is published; `wheel-plant` starts the bottling plant on a SQLite file from the built wheel on Ubuntu and on Windows. Version: whatever CPython ships |
+| **Claude Code** as an MCP client | tested | scoring 2026-10-26; **the live-model run's date is not recorded** | the agent evals drive it headless. `tests/test_agent_eval.py` scores them on every pull request; the run that puts a real model against the live tool surface is `fsmes agent-eval`, a command a person types, and nothing records when it last ran |
 | Claude Desktop, other MCP clients | **untested** | never | the server is streamable HTTP over the standard SDK |
 | **Jev** (TypeSafe), as a judgment model | **untested**; nothing in this repository calls it | never called; the vendor's answers in this row are dated **2026-09-17** | No request has been made to it from this repository and no accuracy number has been produced here, so there is nothing measured to report. What is known is what TypeSafe answered in writing to the maintainer on 2026-09-17, and it is the vendor's statement rather than this project's measurement: **hosted API only** — no on-premises, VPC or edge option now or planned; **United States only** — no public EU region, and no subprocessor list was given; **a version can be pinned**, with no fixed forced-retirement window; **250,000 tokens per second and 1,200 requests per minute**, with no availability commitment beyond those limits; **zero data retention is available on the enterprise tier only**, and no retention period was given for any other tier. The consequence for a plant is on the survey's preconditions ([`docs/ai/JEV.md`](../ai/JEV.md)): every state class above `catalogue` in decision [0032](../decisions/0032-a-hosted-judgment-and-the-shadow.md) is gated on the enterprise tier or on that plant accepting retention it has no stated period for, and an air-gapped site cannot use it at any tier |
 | **MQTT brokers** (Mosquitto, HiveMQ, EMQX) | **untested** | never | **no broker has been on the other end of either direction.** Both directions are built — `fsmes uns publish` and `fsmes inbound subscribe` — and both are driven by a fake transport in the suite. No broker has run against either; this repository does not start brokers on the machine it is developed on. The publisher has one opt-in test against a real broker (`MES_UNS_TEST_BROKER`) |
 | Node-RED, United Manufacturing Hub, Grafana | **untested**; the MQTT halves exist | never | the namespace is published and subscribed to over plain MQTT-JSON under an ISA-95 tree; no UMH or Node-RED deployment has been on the other end of it |
-| Windows (plant PCs) | tested continuously | 2026-10-12 | CI runs `ruff` and the whole suite on `windows-latest`, Python 3.12 and 3.13, on every pull request — and, since [#163](https://github.com/factorysemantics/factorysemantics-mes/pull/163) on 2026-10-12, the `wheel-plant` job (`.github/scripts/plant_from_wheel.py`) installs the built wheel on `windows-latest` in a directory holding none of this repository's files, starts the bottling plant and asks it whether sign-in works, the specifications are there, the OPC port answers, the floor is watching and a lot has been counted. That job is why three Windows-only bugs are fixed — a detach flag ignored, a signal that does not exist on Windows, a console script looked for in `bin` — none of which the green suite could see, because the suite never starts a plant. `tzdata` is a Windows-only dependency so `zoneinfo` can resolve a plant's zone. **No plant PC in a real plant has run it**: the only Windows this has started on is GitHub's runner, with no domain policy and no antivirus |
-| Python | 3.12, 3.13 | 2026-10-12 | CI, both on Ubuntu and on Windows. 3.11 and earlier are not supported; 3.14 is untested |
+| Windows (plant PCs) | tested continuously | 2026-10-26 | CI runs `ruff` and the whole suite on `windows-latest`, Python 3.12 and 3.13, on every pull request — and, since [#163](https://github.com/factorysemantics/factorysemantics-mes/pull/163) on 2026-10-12, the `wheel-plant` job (`.github/scripts/plant_from_wheel.py`) installs the built wheel on `windows-latest` in a directory holding none of this repository's files, starts the bottling plant and asks it whether sign-in works, the specifications are there, the OPC port answers, the floor is watching and a lot has been counted. Since 2026-10-22 it also stops the plant and starts it again with nothing in between, which is how a fourth Windows-only fault was found: a listening socket there outlives the process that owned it by about two seconds — every Windows cell measured that and every Linux cell measured zero — so a start inside those two seconds refused on a port that nothing was holding. That job is why four Windows-only bugs are fixed — a detach flag ignored, a signal that does not exist on Windows, a console script looked for in `bin`, and a stop that came back before its ports did — none of which the green suite could see, because the suite never starts a plant. `tzdata` is a Windows-only dependency so `zoneinfo` can resolve a plant's zone. **No plant PC in a real plant has run it**: the only Windows this has started on is GitHub's runner, with no domain policy and no antivirus |
+| Python | 3.12, 3.13 | 2026-10-26 | CI, both on Ubuntu and on Windows. 3.11 and earlier are not supported; 3.14 is untested |
 
 When a row changes, it changes here first, with the date and what was run.
 
@@ -51,6 +51,6 @@ rather than read is a table that misleads.
 |---|---|---|---|---|
 | **ERPNext** | supported | v15.120.0 (Frappe v15, MariaDB 10.6) | 2026-09-10, and on every pull request that touches the connector, its tests or its fixture since | the `ERPNext (live)` job: a clean container from `labs/erpnext/docker-compose.yml`, images pinned by digest, seeded and put through the whole round trip in `tests/test_erpnext_live.py`, asserting against ERPNext's own documents. Includes what ERPNext does with an over-run, measured 2026-09-10: inside its own over-production allowance it books every unit, beyond it it refuses the stock entry whole and books nothing ([what the connector does about it](erpnext.md#when-the-line-made-more-than-the-order-asked-for)). Also passes the conformance suite |
 | ERPNext v16 | experimental | **no live test** | — | nothing here claims anything about it; the live job pins v15 |
-| **file exchange** (B2MML-lite) | supported | not applicable — the far side is a folder | 2026-10-12 | `tests/test_file_erp.py`, `tests/test_erp_confirmation_files.py` and the conformance suite. The folder layout, the published schema and `fsmes erp validate` are on [the confirmation handoff](confirmation-files.md) |
-| **REST** (against the bundled mock ERP) | supported | not applicable — the far side ships with it | 2026-10-12 | `tests/test_erp_contract.py` and the conformance suite. Against a *real* ERP's REST API it is **untested**, and the three endpoints it needs are in `fsmes erp requirements` |
+| **file exchange** (B2MML-lite) | supported | not applicable — the far side is a folder | 2026-10-26 | `tests/test_file_erp.py`, `tests/test_erp_confirmation_files.py` and the conformance suite. The folder layout, the published schema and `fsmes erp validate` are on [the confirmation handoff](confirmation-files.md) |
+| **REST** (against the bundled mock ERP) | supported | not applicable — the far side ships with it | 2026-10-26 | `tests/test_erp_contract.py` and the conformance suite. Against a *real* ERP's REST API it is **untested**, and the three endpoints it needs are in `fsmes erp requirements` |
 | Odoo, SAP, Oracle, NetSuite | not written | — | — | the contract exists (`contract.py`), the conformance suite exists (`conformance.py`), the connectors do not. The confirmations are SAP-*shaped* and now [published with a schema and worked example files](confirmation-files.md), but no SAP has consumed one. [How to write one](../develop/erp-connectors.md) |

{factorysemantics_mes-0.4.0 → factorysemantics_mes-0.4.2}/docs/operate/redundancy.md

@@ -353,6 +353,33 @@ one PostgreSQL with `lease_seconds = 4` and the line replayed at 6x: the
 counters' own movement exactly, per machine. Your numbers will differ; the
 shape will not.
 
+Or watch it cost something. One plant as two nodes side by side, each on its
+own address, and a real `docker kill` on the one holding the machines:
+
+![One bottling plant running as two nodes side by side, each on its own address; a real docker kill on node a, which is reading the machines; node b taking the machines over seven seconds later with the counts carried across; node a started again and answering, as a standby](../assets/kill-a-node.gif)
+
+Node a held the machines and was killed; node b was reading them 6.6
+seconds later; node a answered again 1.2 seconds after `docker start`,
+holding nothing. Two things in it are staged and nothing else is: the
+yellow line is the dashboard's own header line, enlarged so it can be read
+at this size, and the grey "no answer" panel is drawn by the recorder over
+a page that is really greying itself and saying "reconnecting". The seconds
+are the ones measured on the machine it was recorded on, and they are
+printed by the script that records it: `bash scripts/record-kill-a-node.sh`
+from a checkout makes the whole thing again, so the picture can be of the
+version you are running rather than of the day it was first made. ([The
+same minute as an mp4](../assets/kill-a-node.mp4), if a loop is
+distracting.)
+
+One thing in it is worth reading twice. For the few seconds between the kill
+and the takeover the machine cards go idle and the line reads `0/6 running`,
+and then they are all running again. That is this being a *simulated* plant:
+the floor that moves those machines is itself one of the jobs held by a lease,
+so it stops while its lease moves, exactly as the reader does. On a real plant
+the machines are machines and do not pause — what pauses is the MES reading
+them, and the counters are absolute, so the units made in the gap are booked
+when the new holder catches up rather than lost.
+
 A node that comes back comes back as a standby. It does not take a role the
 other node is holding.