Containers coming back is not the mesh coming back

E2 asserted that every container was running after a reboot and stopped there.
The runtime restarts containers by itself; what makes a machine part of a mesh is
an agent listening for what it should be. A machine whose containers returned and
whose agent did not looks healthy and cannot be told anything.

The installer is explicit that a host started the way the lab starts it does not
survive a reboot, so this may now fail — and if it does, it is the packaging gap
the design already records under what is not yet true, not a fault in the mesh.
Better a named failure than a pass that means less than it appears to.

Claude-Session: https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx

one-node-mesh-report.json

@@ -1,13 +1,13 @@
 {
   "scenario": "one-node-mesh",
-  "established": 18,
+  "established": 20,
   "of": 21,
   "steps": [
     {
       "code": "R1",
       "title": "a bare machine becomes a mesh of one, raised by the installer",
       "status": "pass",
-      "seconds": 133,
+      "seconds": 145,
       "why": ""
     },
     {
@@ -56,14 +56,14 @@
       "code": "P1",
       "title": "the mesh builds the shared base from source",
       "status": "pass",
-      "seconds": 83,
+      "seconds": 72,
       "why": ""
     },
     {
       "code": "P2",
       "title": "the mesh builds and runs a store of its own",
       "status": "pass",
-      "seconds": 47,
+      "seconds": 43,
       "why": ""
     },
     {
@@ -77,7 +77,7 @@
       "code": "P4",
       "title": "the mesh rebuilds its own control plane from source",
       "status": "pass",
-      "seconds": 30,
+      "seconds": 33,
       "why": ""
     },
     {
@@ -98,7 +98,7 @@
       "code": "U1",
       "title": "the mesh builds a module standing on that base",
       "status": "pass",
-      "seconds": 23,
+      "seconds": 14,
       "why": ""
     },
     {
@@ -139,16 +139,16 @@
     {
       "code": "E1",
       "title": "a change to a module's source reaches the machine on its own",
-      "status": "fail",
+      "status": "pass",
-      "seconds": 1,
+      "seconds": 14,
-      "why": "the mesh does not report a module behind its source:\n1 machine(s), all doing what they were told, all heard from, running what the mesh would send them, and every module current with its source\n"
+      "why": ""
     },
     {
       "code": "E2",
       "title": "the mesh comes back after the machine reboots",
-      "status": "skip",
+      "status": "pass",
-      "seconds": 0,
+      "seconds": 32,
-      "why": "not attempted — E1 (a change to a module's source reaches the machine on its own) did not succeed"
+      "why": ""
     }
   ]
 }

test/integration/one-node-mesh.test.ts

@@ -901,7 +901,18 @@ before(async () => {
     const ps = (await on(CONTROL, `docker ps -a --format '{{.Names}}\t{{.Status}}'`)).out;
     assert.equal(missing.length, 0,
       `after a reboot these are not running: ${missing.join(", ")}\n\ncontainers:\n${ps}`);
-    return ps;
+
+    // **Containers coming back is not the mesh coming back.** The runtime restarts containers on
+    // its own; what makes a machine part of a mesh is an agent listening for what it should be. A
+    // machine whose containers returned and whose agent did not looks healthy and cannot be told
+    // anything — and the installer is explicit that a host started the way the lab starts it, with
+    // --host-in-background, does not survive a reboot. So this asks, and a failure here is the
+    // packaging gap the design already records rather than a fault in the mesh.
+    const agent = (await on(CONTROL, `pgrep -af '[m]esh-host run' | head -3`)).out.trim();
+    assert.ok(agent,
+      `every container came back and no host agent did, so the machine is running the right ` +
+      `things and can no longer be told anything:\n${ps}`);
+    return `${ps}\n${agent}`;
   });
 
   stateOutcome();