The lab said nothing was running while two machines were

'incus list' failed because this shell had no permission to reach the daemon,
incusOk returned null, and the caller wrote ?? "[]". So 'mesh-lab list'
printed 'no scenario instances standing' -- confidently, about a question it
had never managed to ask.

The comment on incusOk warns about exactly this, in those words: absence and
success made indistinguishable. Three of its own callers then did it. Two
listings and the live diagram, which would have drawn an empty scenario rather
than fail -- a picture that is confidently wrong, which is worse than none.

Anything enumerating what exists now goes through enumerate() and throws.
incusOk stays right where failure genuinely means no, like instanceExists,
and there is a test holding that line so this does not get over-corrected
until nothing can be asked at all.

Worth noting 'mesh-lab check' already diagnoses this precise cause, down to
'a session that predates it cannot see it'. The diagnosis existed; the
listing just never asked for it.

test/enumerate.test.ts

@@ -0,0 +1,41 @@
+// Set before importing: the client reads MESH_LAB_INCUS once, at module load.
+// `false` is a real program that exits non-zero and prints nothing — which is also the worst
+// case, because an empty stderr is how a failure arrives with no explanation.
+process.env["MESH_LAB_INCUS"] = "false";
+
+import { test } from "node:test";
+import assert from "node:assert/strict";
+import { instanceExists, taggedInstances, taggedNetworks } from "../src/incus/client.ts";
+
+/**
+ * "I cannot see" must never be answered as "there is nothing there."
+ *
+ * This is the fault the comment on `incusOk` warns about, committed by three of its own callers
+ * writing `?? "[]"`. It cost a session: `mesh-lab list` printed *no scenario instances standing*
+ * while two were standing, because the shell had no permission to reach the daemon. Nothing was
+ * wrong with the lab's knowledge of the instances — it had never managed to ask.
+ *
+ * The same shape as the fault the node host exists to prevent, in the tool that tests the host:
+ * a service that does not exist reported as `stopped`.
+ */
+
+test("listing instances fails rather than reporting none", async () => {
+  await assert.rejects(
+    () => taggedInstances(),
+    "a failed `incus list` came back as an empty list; every caller would report nothing running",
+  );
+});
+
+test("listing networks fails rather than reporting none", async () => {
+  await assert.rejects(
+    () => taggedNetworks(),
+    "a failed `incus network list` came back as an empty list",
+  );
+});
+
+test("but a question whose failure genuinely means no still answers no", async () => {
+  // The distinction worth keeping. `instanceExists` asks about one named thing, and a daemon
+  // that will not answer is not evidence the instance exists — so false is honest here, and
+  // making this throw too would be over-correcting until nothing can be asked at all.
+  assert.equal(await instanceExists("anything"), false);
+});