@cat-factory/executor-harness 1.145.1 → 1.149.0

package/dist/docker-status.js

@@ -1,6 +1,6 @@
-import { execFile } from 'node:child_process';
 import { readFile } from 'node:fs/promises';
-import { promisify } from 'node:util';
+import { probeDockerWorkload } from './docker-capability.js';
+import { log } from './logger.js';
 // What this container knows about its own Docker daemon, as recorded by `entrypoint.sh`.
 //
 // The Tester's local-mode infra stand-up (`docker compose up --wait`) is the only thing in the
@@ -13,8 +13,12 @@ import { promisify } from 'node:util';
 // daemon reads it instead.
 //
 // The recorded verdict describes BOOT, and a container outlives its boot, so nothing refuses on
-// it unconfirmed: `resolveDockerVerdict` re-checks a recorded absence against a live daemon and
-// keeps the record for what only the record holds, the cause and the daemon's own log tail.
+// it unconfirmed: `resolveDockerVerdict` re-checks it against a live daemon and keeps the record
+// for what only the record holds, the cause and the daemon's own log tail. What it records is
+// also only that a SOCKET answered, which is a weaker fact than any caller wants, so the live
+// check RUNS A CONTAINER (docker-capability.ts) rather than settling for the daemon's word about
+// itself. It still reports that weaker fact alongside, since a check that could not be carried
+// out is what the boot record has to be read against, and nothing else establishes it.
 //
 // The three-valued shape is deliberate and is the point (CLAUDE.md, "Degrade loudly"): a daemon
 // that FAILED and a daemon nobody asked about are different facts with different correct
@@ -106,42 +110,95 @@ function absenceCause(source) {
 function unnamedSource(source) {
     return `no Docker daemon answered in this container (unrecognised source ${JSON.stringify(source)})`;
 }
-/** A live probe may not outlast the thing it is guarding; a hung socket is an absent daemon here. */
-const PROBE_TIMEOUT_MS = 10_000;
-const execFileAsync = promisify(execFile);
 /**
- * The default {@link DockerProbe}: `docker version` talks to the SERVER, unlike the client-only
- * `docker --version`, which answers happily with no daemon at all.
+ * The default {@link DockerProbe}: the process-wide workload probe, which loads a one-layer
+ * image and runs a container from it, memoised per container.
+ *
+ * Named for what it answers. It was `probeDockerServing`, which is the fact this module exists to
+ * say is not enough.
  */
-export const probeDockerServing = async () => {
-    try {
-        await execFileAsync('docker', ['version', '--format', '{{.Server.Version}}'], {
-            timeout: PROBE_TIMEOUT_MS,
-        });
-        return true;
-    }
-    catch {
-        return false;
-    }
-};
+export const probeLiveDockerCapability = (signal) => probeDockerWorkload(signal);
 /**
- * Resolve what to do now, from what boot recorded plus what a daemon says today.
+ * The sentence for a daemon that is serving and cannot run anything. It names what was tried,
+ * because "docker is unavailable" against a daemon the agent can see answering reads as a bug in
+ * the platform rather than as the sandbox limit it is.
+ */
+export function describeDockerUnusable(workload) {
+    return `this container's Docker daemon is reachable but cannot run a container (${workload.detail})`;
+}
+/**
+ * Resolve what to do now, from what boot recorded plus what the daemon can do today.
+ *
+ * `entrypoint.sh` probes once, at boot, within a bounded wait, and it probes for a SOCKET. Two
+ * things follow, and the branches below are one each.
  *
- * `entrypoint.sh` probes once, at boot, within a bounded wait. A container outlives that: a warm
- * pool serves many jobs from one, and a sidecar daemon that took longer than the wait allows is
- * serving perfectly well by the second job. Refusing off the recorded verdict alone latches that
- * container into refusing local infra that in fact works, for its whole life, with a stale
- * sentence explaining why. So a recorded absence is a HYPOTHESIS here, and the live probe settles
- * it; the recorded verdict is still what supplies the cause and the daemon's own log tail, which
- * no probe can reconstruct.
+ * A recorded absence is a HYPOTHESIS. A container outlives its boot: a warm pool serves many jobs
+ * from one, and a sidecar daemon that took longer than the wait allows is serving perfectly well
+ * by the second job. Refusing off the record alone latches that container into refusing local
+ * infra that works, for its whole life, with a stale sentence explaining why. The record is still
+ * what supplies the cause and the daemon's own log tail, which no probe can reconstruct.
  *
- * Only a recorded `false` is re-confirmed. "Not decided" keeps attempting exactly as before: the
- * point of the third value is that nothing turns it into a refusal, and a probe here would.
+ * A recorded PRESENCE is a hypothesis too, and that half was missing. `serving` is not `usable`:
+ * a rootless daemon in a sandbox answers while unable to mount any image layer, so compose ran
+ * and died on a mount error the agent then had to interpret. So the probe is consulted in both
+ * directions, and it runs a real container rather than asking the daemon about itself.
+ *
+ * A check that could not be CARRIED OUT settles nothing, and the cheap fact is what decides
+ * there. Falling straight back to the boot record would re-latch the very refusal the paragraph
+ * above rules out: the four ways the workload check can come back undeterminable (no payload in
+ * this image variant, an architecture it is not built for, a `docker load` the engine refuses, a
+ * timeout) have nothing to do with whether a daemon is up, so a warm container whose sidecar
+ * arrived late would be denied local infra for the rest of its life over a stale sentence. So a
+ * daemon that ANSWERED contradicts a recorded absence exactly as the old `docker version` probe
+ * did, and only a check that never reached a daemon at all leaves the record to decide.
+ *
+ * "Not decided" still keeps attempting, untouched. The point of the third value is that NOTHING
+ * turns it into a refusal: the entrypoint's bounded wait may still be running, and a workload
+ * probe against a daemon that has not finished starting fails for a reason that says nothing
+ * about what it will do a second later.
  */
-export async function resolveDockerVerdict(status, probe = probeDockerServing) {
-    if (status.available !== false)
-        return { available: status.available };
-    if (await probe())
-        return { available: true };
-    return { available: false, refusal: describeDockerAbsence(status) };
+export async function resolveDockerVerdict(status, opts = {}) {
+    if (status.available === undefined)
+        return { available: undefined };
+    const workload = await askTotally(opts.probe ?? probeLiveDockerCapability, opts.signal, opts.logger);
+    if (workload.status === 'usable')
+        return { available: true, daemon: true, workload };
+    if (workload.status === 'unusable') {
+        return {
+            available: false,
+            refusal: describeDockerUnusable(workload),
+            daemon: true,
+            workload,
+        };
+    }
+    if (workload.daemonAnswered)
+        return { available: true, daemon: true, workload };
+    return status.available
+        ? { available: true, workload }
+        : { available: false, refusal: describeDockerAbsence(status), workload };
+}
+/**
+ * Call the probe and answer even if it throws.
+ *
+ * The default probe is total by construction and says so, but this is the seam an injected one
+ * arrives through, and the caller is a stand-up documented as best-effort: a throw here would
+ * fail a job over the mechanism whose whole purpose is to make a failure legible. A throw settles
+ * nothing about the daemon, so it becomes the same value as any other check that could not be
+ * carried out and the boot record decides, exactly as it did before the probe existed.
+ */
+async function askTotally(probe, signal, logger) {
+    try {
+        return await probe(signal);
+    }
+    catch (err) {
+        const message = err instanceof Error ? err.message : String(err);
+        (logger ?? log).warn('docker: the live daemon check threw; falling back to the boot record', {
+            error: message,
+        });
+        return {
+            status: 'unknown',
+            reason: `the live Docker check could not be carried out (${message})`,
+            daemonAnswered: false,
+        };
+    }
 }

package/dist/environment-inventory.d.ts

@@ -1,4 +1,5 @@
 import { type Logger } from './logger.js';
+import { type ContainerEgress, type DockerWorkload } from './docker-capability.js';
 /**
  * What running one probe did, kept as RAW as the spawn: whether the binary ran, and with what.
  * Classification into presence lives in pure code below, because the two callers classify the
@@ -35,6 +36,44 @@ export type ToolPresence = {
     status: 'unknown';
     reason: string;
 };
+/**
+ * What this machine's Docker daemon is good for, which is FIVE answers and not three.
+ *
+ * `absent` and `unknown` mean for the daemon what they mean for any other tool. The three that
+ * are particular to Docker split the case where a daemon ANSWERED, because answering is not the
+ * question anyone is asking:
+ *
+ *   - `usable`:   a container was built and run on it here. `docker build` / `run` / `compose`
+ *                   work, and this is the only state that may say so.
+ *   - `unusable`: a container could NOT be run, with the daemon serving throughout. The state
+ *                   issue #2120 is about; stated as a prohibition, with the cause.
+ *   - `serving`:  it answered, and the workload check could not be carried out (no payload on
+ *                   this machine, an unmapped architecture, a timeout). Neither of the other two,
+ *                   and rendered as "try it if you need it".
+ *
+ * `usable` then carries what a nested container could REACH, which is a second fact and not a
+ * sixth state: what an agent may do with the daemon and what its containers can fetch are
+ * different questions, and each of the three egress answers changes the advice without changing
+ * the verdict on the daemon.
+ */
+export type DockerCapability = {
+    status: 'usable';
+    server?: string;
+    egress: ContainerEgress;
+} | {
+    status: 'unusable';
+    server?: string;
+    detail: string;
+} | {
+    status: 'serving';
+    server?: string;
+    reason: string;
+} | {
+    status: 'absent';
+} | {
+    status: 'unknown';
+    reason: string;
+};
 /** One probed entry: the name the agent would type, and what came back. */
 export interface ProbedTool {
     name: string;
@@ -46,12 +85,13 @@ export interface ProbedTool {
 export interface EnvironmentInventory {
     tools: ProbedTool[];
     /**
-     * Whether a Docker daemon actually answered: the readiness fact, not the CLI's presence. The
-     * image's `entrypoint.sh` starts a rootless daemon BEST-EFFORT and execs the server without
-     * waiting for it, so at job start this probe is the only thing that knows how that went, and
-     * "has not answered yet" is one of its answers (see {@link probeDockerDaemon}).
+     * What the Docker daemon is good for: not the CLI's presence, and not merely whether the
+     * daemon answered. The image's `entrypoint.sh` starts a rootless daemon BEST-EFFORT and execs
+     * the server without waiting for it, so at job start this probe is the only thing that knows
+     * how that went; "has not answered yet" is one of its answers (see {@link probeDockerDaemon})
+     * and "answered, but cannot run a container" is another (see {@link DockerCapability}).
      */
-    dockerDaemon: ToolPresence;
+    dockerDaemon: DockerCapability;
     /**
      * The port the harness's own job server holds in this network namespace. Not probed: the
      * process reads its own {@link harnessListenPort}, which is the only honest answer when a
@@ -124,6 +164,18 @@ export interface ProbeEnvironmentOptions {
      * only so the suite can assert the rendered line without an ambient `PORT` deciding its text.
      */
     harnessPort?: number;
+    /**
+     * Whether the daemon can actually RUN a container, defaulting to the process-wide probe
+     * (docker-capability.ts). Asked only once a daemon has answered, since there is nothing to run
+     * a workload on otherwise, and memoised per container so a warm pool pays for it once.
+     */
+    workload?: (signal?: AbortSignal) => Promise<DockerWorkload>;
+    /**
+     * The job's signal, forwarded to the probes that spawn something. The workload check starts a
+     * CONTAINER, so a cancelled job must stop paying for it rather than hold the daemon for the
+     * rest of its budget.
+     */
+    signal?: AbortSignal;
 }
 /**
  * Probe the machine. EVERYTHING runs concurrently, the daemon included.
@@ -163,7 +215,6 @@ export declare function renderEnvironmentInventory(inventory: EnvironmentInvento
  * the pass itself, and it says so in a log line rather than silently shortening the prompt.
  */
 export declare function appendEnvironmentInventory(systemPrompt: string, opts?: {
-    signal?: AbortSignal;
     log?: Logger;
     run?: ProbeRunner;
 } & ProbeEnvironmentOptions): Promise<string>;

package/dist/environment-inventory.js

@@ -2,6 +2,7 @@ import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
 import { log } from './logger.js';
 import { harnessListenPort } from './harness-port.js';
+import { probeDockerWorkload, } from './docker-capability.js';
 // ---------------------------------------------------------------------------
 // What this machine actually has, probed ONCE per job and stated to the agent.
 //
@@ -31,6 +32,18 @@ import { harnessListenPort } from './harness-port.js';
 //     a daemon this machine is CONFIGURED for but which has not answered yet is a fourth state
 //     that resolves to `unknown`, never to the absence a refused connection looks like: the
 //     image's daemon is started in the background and the job begins before it is ready.
+//   - A daemon that ANSWERS is still not a daemon that WORKS, which is the same mistake one level
+//     in. A rootless daemon nested in a sandbox serves while its snapshotter cannot mount any
+//     image layer, so `docker info` succeeds and `docker build` / `docker run` / `docker pull`
+//     all fail (issue #2120). Only a container that RAN settles that, so the reachable case is
+//     split by a real workload (docker-capability.ts) into `usable`, `unusable`, and a daemon
+//     that answered while the check itself could not be carried out.
+//   - And a daemon that runs containers is still not one whose containers have a NETWORK, which
+//     is the same mistake one level in again. Loading and running a local image needs no network,
+//     so a daemon started with `--iptables=false` passes the workload check while every nested
+//     container is cut off (issue #2174): what an agent then hits is a `docker build` whose
+//     `RUN npm ci` sits in retry backoff for about seven minutes before failing. So `usable`
+//     carries its own egress verdict, and the line below says something different for each.
 //
 // Deliberately NOT here: the agent's own tools (web search, file tools, MCP servers). Those are
 // the CLI's, they differ per harness, and each is already stated where it is true. Claiming one
@@ -260,10 +273,33 @@ export async function probeEnvironment(run, opts = {}) {
             showVersion: probe.showVersion,
             presence: toolPresence(await run(probe.command, probe.args)),
         }))),
-        probeDockerDaemon(run, opts),
+        probeDockerCapability(run, opts),
     ]);
     return { tools, dockerDaemon, harnessPort: opts.harnessPort ?? harnessListenPort() };
 }
+/**
+ * The daemon's full answer: whether one is reachable, and then whether it can run a container.
+ *
+ * The two steps are kept apart because they fail for unrelated reasons and only the FIRST has a
+ * cheap answer. A daemon nobody can reach has no workload to run, so the check that costs a
+ * container start is asked only where there is something to ask it of; a daemon that answered
+ * carries its server version into every one of the three states that follow it, because the
+ * agent reading the line is entitled to know which daemon the verdict is about.
+ */
+async function probeDockerCapability(run, opts) {
+    const daemon = await probeDockerDaemon(run, opts);
+    if (daemon.status === 'absent')
+        return { status: 'absent' };
+    if (daemon.status === 'unknown')
+        return { status: 'unknown', reason: daemon.reason };
+    const server = daemon.version ? { server: daemon.version } : {};
+    const workload = await (opts.workload ?? probeDockerWorkload)(opts.signal);
+    if (workload.status === 'usable')
+        return { status: 'usable', ...server, egress: workload.egress };
+    if (workload.status === 'unusable')
+        return { status: 'unusable', ...server, detail: workload.detail };
+    return { status: 'serving', ...server, reason: workload.reason };
+}
 /**
  * Ask the daemon itself, and do not mistake a daemon that is STARTING for one that is not there.
  *
@@ -377,20 +413,109 @@ function harnessPortLine(port) {
         'check aimed at it passes without your service ever having run. Bind anything you start ' +
         'somewhere else.');
 }
-/** The Docker line, which says something different in each of the three cases. */
+/**
+ * The Docker line, which says something different in each of the five cases, and is TOTAL over
+ * them: adding a state without deciding what an agent should do about it stops the build.
+ *
+ * Only `usable` may claim the commands work, and it may only be reached by having RUN one. The
+ * line that used to stand here made that claim off `docker info` alone, which is how every agent
+ * in a run was told, as fact, that a daemon which could not mount a single image layer would
+ * build and run one.
+ */
 function dockerDaemonLine(daemon) {
-    if (daemon.status === 'present') {
-        const server = daemon.version ? ` (server ${daemon.version})` : '';
-        return (`A Docker daemon is reachable${server}: \`docker build\`, \`docker run\` and ` +
-            '`docker compose up` work here.');
+    const server = 'server' in daemon && daemon.server ? ` (server ${daemon.server})` : '';
+    switch (daemon.status) {
+        case 'usable':
+            return `A Docker daemon is reachable${server} and the platform ran a container on it: ${usableCommands(daemon.egress)} work here. ${egressSentence(daemon.egress)}`;
+        case 'unusable':
+            return (`A Docker daemon is reachable${server} but it CANNOT run a container: the platform ` +
+                `built a one-layer image and tried to run it here, and that failed (${daemon.detail}). ` +
+                '`docker build`, `docker run`, `docker pull` of a multi-layer image and ' +
+                '`docker compose up` all fail for the same reason, so there is nothing to retry and no ' +
+                'flag that works around it. Produce the Dockerfile or compose file you were asked for, ' +
+                'say in one line that it could not be built or run here, and move on.');
+        case 'serving':
+            return (`A Docker daemon is reachable${server}, but whether it can actually build or run an ` +
+                `image was NOT established (${daemon.reason}). Reaching the daemon is not the same fact: ` +
+                'a sandboxed one answers while being unable to mount any image layer. Try it if you need ' +
+                'it, and do not read a failure as a defect in the work.');
+        case 'unknown':
+            return ('Whether a Docker daemon is reachable could not be determined ' +
+                `(${daemon.reason}): try it if you need it, and do not read a failure as a defect in the work.`);
+        case 'absent':
+            return ('NO Docker daemon is reachable: `docker build`, `docker run` and `docker compose up` ' +
+                'will fail here whatever the CLI reports. Produce the Dockerfile or compose file you ' +
+                'were asked for, say in one line that you could not build it here, and move on.');
+        default:
+            return unnamedCapability(daemon);
     }
-    if (daemon.status === 'unknown') {
-        return ('Whether a Docker daemon is reachable could not be determined ' +
-            `(${daemon.reason}): try it if you need it, and do not read a failure as a defect in the work.`);
+}
+function unnamedCapability(daemon) {
+    return `Whether a Docker daemon is reachable could not be determined (the platform reported an unrecognised verdict ${JSON.stringify(daemon)}): try it if you need it.`;
+}
+/**
+ * Which commands the `usable` line may claim, which is the EGRESS verdict's business and not the
+ * daemon's.
+ *
+ * Split out because the line used to open with the full list and then, one sentence later, tell
+ * the agent that every `RUN` line which fetches anything fails. A block that also says not to
+ * spend turns re-checking it cannot afford to state and then retract the same fact: an agent
+ * reading the first sentence has already been told `docker build` works here, which is the exact
+ * shape of the lie issue #2174 is about. TOTAL over {@link ContainerEgress}, like its sibling.
+ */
+function usableCommands(egress) {
+    switch (egress.status) {
+        case 'blocked':
+            // Deliberately omits `docker build`: it is the one the missing NAT rule actually breaks,
+            // and the sentence that follows explains which part of it and why.
+            return '`docker run` and `docker compose up` of images that are already built';
+        case 'reachable':
+        case 'undetermined':
+            return '`docker build`, `docker run` and `docker compose up`';
+        default:
+            return unnamedEgressCommands(egress);
+    }
+}
+/** The commands claimed for an egress verdict this build does not know: none of them. */
+function unnamedEgressCommands(egress) {
+    return `the docker commands the platform could name for its verdict ${JSON.stringify(egress)}`;
+}
+/**
+ * The second half of the `usable` line: what a container started HERE can reach, and what to do
+ * about it. TOTAL over {@link ContainerEgress} for the same reason the line above is over the
+ * daemon's states.
+ *
+ * The `blocked` arm is the one this exists for, and it is precise about WHICH commands break,
+ * because "docker has no network" is not true and an agent that believed it would skip work it
+ * could have done. The daemon has a network: it pulls base images and compose pulls its services
+ * normally. What has none is the container each `RUN` line executes in. The seven minutes are
+ * named because the failure does not look like a failure from inside the agent's loop: npm turns
+ * "no route" into `EAI_AGAIN` only once its retry backoff gives up, so the build reads as a hang
+ * and the natural response is to wait longer.
+ */
+function egressSentence(egress) {
+    switch (egress.status) {
+        case 'reachable':
+            return 'A container started here also reaches the network, so a build that installs dependencies works.';
+        case 'blocked':
+            return ('A container started here could reach NOTHING the platform tried, and that is a fact ' +
+                `about this sandbox rather than about your work (${egress.detail}). The daemon itself is ` +
+                'fine: it pulls base images, and `docker compose up` of pre-built images works. What ' +
+                'fails is every `RUN` line in a `docker build` that fetches from the public internet ' +
+                '(`npm ci`, `apk add`, `pip install`), and it fails SLOWLY: npm reports `EAI_AGAIN` only ' +
+                'after some seven minutes of retry backoff, so it reads as a hang. Do not wait it out ' +
+                'and do not retry. Vendor what you need, skip the image build, verify some other way, or ' +
+                'say in one line that you could not verify it here. If this project already builds ' +
+                'against a mirror inside this network, that is not one of the addresses tried above and ' +
+                'is worth one attempt.');
+        case 'undetermined':
+            return `Whether a container started here can reach the network was NOT established (${egress.reason}), so try it if you need it and do not read a failure as a defect in the work.`;
+        default:
+            return unnamedEgress(egress);
     }
-    return ('NO Docker daemon is reachable: `docker build`, `docker run` and `docker compose up` will ' +
-        'fail here whatever the CLI reports. Produce the Dockerfile or compose file you were asked ' +
-        'for, say in one line that you could not build it here, and move on.');
+}
+function unnamedEgress(egress) {
+    return `Whether a container started here can reach the network could not be determined (the platform reported an unrecognised verdict ${JSON.stringify(egress)}).`;
 }
 /**
  * Probe the machine and fold the inventory onto `systemPrompt`. THE composition point: the harness
@@ -408,18 +533,25 @@ function dockerDaemonLine(daemon) {
  */
 export async function appendEnvironmentInventory(systemPrompt, opts = {}) {
     const logger = opts.log ?? log;
+    // Everything that is not this function's OWN is forwarded by construction, rather than key by
+    // key. The list of copied keys silently dropped `workload`, whose whole point is that a suite
+    // can inject one: a test driving THIS entry point (the only one `handleAgent` uses) got the
+    // real probe instead, which starts a container on whatever machine the suite runs on.
+    const { log: _log, run, ...probeOptions } = opts;
     try {
-        const inventory = await probeEnvironment(opts.run ?? spawnProbeRunner(opts.signal), {
-            ...(opts.sleep ? { sleep: opts.sleep } : {}),
-            ...(opts.daemonExpected === undefined ? {} : { daemonExpected: opts.daemonExpected }),
-            ...(opts.harnessPort === undefined ? {} : { harnessPort: opts.harnessPort }),
-        });
+        const inventory = await probeEnvironment(run ?? spawnProbeRunner(opts.signal), probeOptions);
         logger.info('agent: probed the environment', {
             installed: inventory.tools
                 .filter((t) => t.presence.status === 'present')
                 .map((t) => t.name)
                 .join(','),
             dockerDaemon: inventory.dockerDaemon.status,
+            // Present only when a nested container was actually asked, which is the one state that has
+            // an egress answer at all. A word here for every other state would report "no measurement"
+            // and "measured, and it cannot get out" in the same field.
+            ...(inventory.dockerDaemon.status === 'usable'
+                ? { dockerEgress: inventory.dockerDaemon.egress.status }
+                : {}),
             // The unknowns, by NAME: the block tells the agent a probe failed, and this is the only place
             // an operator can see WHICH, since the reason the agent reads is deliberately wordy prose.
             unknown: inventory.tools

package/dist/harness-server.js

@@ -6,6 +6,7 @@ import { handleAgent } from './agent.js';
 import { handleInline } from './inline.js';
 import { redactSecrets } from './git.js';
 import { readDockerStatus } from './docker-status.js';
+import { reportedDockerWorkload } from './docker-capability.js';
 import { harnessListenPort } from './harness-port.js';
 import { JobRegistry, loadRunnerLimits } from './runner.js';
 import { log } from './logger.js';
@@ -122,11 +123,16 @@ const server = createServer((req, res) => {
             // would spawn a process per poll to answer a question this endpoint is not the one to act
             // on; the stand-up re-confirms a recorded absence at the moment it matters
             // (`resolveDockerVerdict`), so a stale negative here never becomes a stale refusal there.
+            //
+            // `workload` is the other half, and the reason the block used to mislead: what the record
+            // says is `serving`, and serving is not usable. It reports the last measurement any job
+            // took (docker-capability.ts) and NEVER takes one itself, for the same polling reason,
+            // which is why `unmeasured` is one of the words it can answer.
             return send(res, 200, {
                 status: 'ok',
                 ...(HARNESS_VERSION ? { version: HARNESS_VERSION } : {}),
                 capabilities: HARNESS_BODY_CAPABILITIES,
-                docker: await readDockerStatus(),
+                docker: { ...(await readDockerStatus()), workload: reportedDockerWorkload() },
             });
         }
         // All non-health endpoints are gated by the optional shared secret.

package/dist/infra-standup.d.ts

@@ -9,19 +9,22 @@ import type { Logger } from './logger.js';
  * still run unit-level tests and report what it could. A no-op for ephemeral / no-infra /
  * no-compose-path runs.
  *
- * A CONFIRMED absence of a Docker daemon short-circuits it: the container's own probe
- * ({@link readDockerStatus}, recorded by `entrypoint.sh`) already knows there is nothing to
- * talk to, so running compose against it would only turn a fact this container holds into a
- * connection error the agent has to interpret. The record then carries `dockerAvailable: false`
- * and the stated cause, which is what makes the Tester step say why it ran no infra instead of
- * looking like a Tester that simply chose not to. Anything OTHER than a confirmed absence
- * attempts as before (`DockerStatus.available` in docker-status.ts states why "undecided" is its
- * own value).
+ * A CONFIRMED absence of a USABLE Docker daemon short-circuits it: the container already knows
+ * compose cannot work, so running it would only turn a fact this container holds into an error
+ * the agent has to interpret. The record then carries the stated cause plus the two facts that
+ * decide where a human should look (`dockerAvailable`: was anything answering, `dockerWorkload`:
+ * what a container did on it), which is what makes the Tester step say why it ran no infra
+ * instead of looking like a Tester that simply chose not to. Anything OTHER than a confirmed
+ * negative attempts as before (`DockerStatus.available` in docker-status.ts states why
+ * "undecided" is its own value).
  *
- * "Confirmed", not merely recorded: {@link resolveDockerVerdict} re-checks a recorded absence
- * against a live daemon first, so a warm-pool container whose sidecar came up late is not
- * latched into refusing infra that works. `probe` is that check, injected so the unit suite can
- * state both answers on a machine that has its own daemon either way.
+ * "Confirmed", not merely recorded: {@link resolveDockerVerdict} re-checks the boot record
+ * against a live daemon first, so a warm-pool container whose sidecar came up late is not latched
+ * into refusing infra that works. It re-checks a recorded PRESENCE too, by running an actual
+ * container: a rootless daemon in a sandbox answers `docker version` while being unable to mount
+ * an image, and compose against that one died on a mount error inside the very mechanism that
+ * exists to explain why infra did not come up. `probe` is that check, injected so the unit suite
+ * can state every answer on a machine that has its own daemon either way.
  *
  * Whether it succeeds or fails, the (redacted, bounded) command output is captured into a
  * {@link InfraSetupRecord} returned alongside the prompt `note`, so the backend can surface