@wardby/cli 0.5.2 → 0.6.0

package/docs/coding-worker-byo-images.md

@@ -7,6 +7,9 @@ wardby's published **driver base image** and point your agent's
 `workerImageRef` at it, instead of waiting for wardby to hand-author a new
 `Dockerfile.<toolchain>`.
 
+The driver image is for Codex agents. A Claude Code agent's image starts from a
+different base; see [Codex and Claude Code](#codex-and-claude-code).
+
 ## The driver image
 
 `ghcr.io/wardby/wardby/wardby-coding-worker-driver` contains wardby's
@@ -14,7 +17,13 @@ compiled Node.js coding-worker driver, `git`, `ca-certificates`, and the
 `wardby` user (uid/gid 10001) — nothing language-specific. It's built from
 `src/coding-worker/Dockerfile.driver` and published on `driver-vN` git tags;
 each release's GitHub Release notes carry the resolved
-`@sha256:...` digest to pin.
+`@sha256:...` digest to pin. `wardby doctor` prints the digest your installed
+version's own workers are built on ("Base image for your own worker images:
+…"); build on that one so your image matches the run input your Wardby sends.
+
+An MCP assistant connected to Wardby can do the whole procedure for you: the
+`build-worker-image` help article walks it through finding the toolchain,
+writing and checking the Dockerfile, and setting `workerImageRef`.
 
 The image deliberately stops before setting `USER`, `WORKDIR`, or
 `ENTRYPOINT`, and before any of the hardened binary-absence checks wardby's
@@ -54,7 +63,38 @@ own READMEs tell it to — reports a failed command even when the suite is
 green. `Dockerfile.node-python` symlinks `python` to `python3` for exactly
 that reason, and asserts both work.
 
-Build it, push it to your own registry, and note the resulting digest —
+### Design for the run's filesystem
+
+A run's root filesystem is read-only; `/tmp` and `/home/wardby` are empty
+`noexec` tmpfs mounts of 16 to 64 MB (anything the image put there is hidden);
+`/workspace` (the checkout, `CODING_DISK_MB` large, or the agent's
+`codingProfile.workspaceDiskMb`) is the only place a run can write and execute;
+and a run reaches no package registry except Wardby's npm and PyPI proxy. So:
+
+- point every cache, build output and temp directory under `/workspace/.cache/`
+  (a `.cache` folder is never collected into the result, at any depth), and
+  create those directories from a small wrapper around the toolchain command,
+  keeping the `ENTRYPOINT` unchanged. For Go: `GOCACHE`, `GOTMPDIR` (`go test`
+  runs its test binary from there) and `GOMODCACHE`;
+- bake dependencies into a read-only location the toolchain only reads from
+  (Go: a file-based module proxy filled by `go mod download`, used through
+  `GOPROXY=file://...`); a baked cache cannot be written to during a run;
+- add build folders that stay in the checkout (Maven `target`, Gradle `build`)
+  to `codingProfile.collectExclude`.
+
+Before using the image, run the project's tests against a throwaway clone with
+a run's restrictions: `--read-only`, `--tmpfs /tmp:rw,noexec,nosuid,size=64m`,
+`--tmpfs /home/wardby:rw,noexec,nosuid,size=64m,uid=10001,gid=10001`,
+`--network none`, `--user 10001:10001`, `--cap-drop ALL` and
+`--security-opt no-new-privileges`. The `build-worker-image` help article has a
+complete Go Dockerfile that passes this check, recipes for Rust and Java, and
+the exact command.
+
+### Build and pin it
+
+On a local quickstart install with the Docker launcher, `workerImageRef` can be
+the local image ID (`docker image inspect --format '{{.Id}}' <your-tag>`).
+Otherwise, build it, push it to your own registry, and note the resulting digest —
 `docker inspect --format '{{index .RepoDigests 0}}' <your-tag>` after a push,
 or read it straight from `docker buildx build --push`'s output.
 
@@ -75,6 +115,189 @@ point one at an arbitrary image without the step-up scope. The scope alone
 isn't enough: the caller must also hold the admin role (see
 [roles and privileged operations](security-deployment.md#roles-and-privileged-operations)).
 
+## Codex and Claude Code
+
+A Codex agent runs in one container, and its commands run there too. A Claude
+Code agent uses two containers: one runs Claude Code and holds its API key; the
+other runs the agent's commands and has your repository. `workerImageRef` always
+replaces the container that runs commands.
+
+|                                | Codex agent                                                       | Claude Code agent                                                                                               |
+| ------------------------------ | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
+| What `workerImageRef` replaces | the agent's only container                                        | the container that runs commands                                                                                |
+| Build your image `FROM`        | [the coding-worker driver image](#the-driver-image) (`driver-vN`) | the `wardby-claude-tool-runner` image from the same wardby release (or `wardby-claude-tool-runner-node-python`) |
+| Rebuild when                   | the driver image changes                                          | you upgrade wardby                                                                                              |
+| Claude Code itself runs on     | —                                                                 | wardby's standard image, never yours                                                                            |
+
+The driver image sections above are for Codex. The subsections below are for
+Claude Code. In them, "tool runner" means the container that runs a Claude Code
+agent's commands.
+
+### Build a custom image for a Claude Code agent
+
+1. **Find your release's tool runner image.** It is the value of
+   `CODING_CLAUDE_TOOL_RUNNER_IMAGE` on your server. To start from Node and
+   Python, use `CODING_CLAUDE_TOOL_RUNNER_IMAGE_NODE_PYTHON_3_12` instead. A
+   release value looks like
+   `ghcr.io/wardby/wardby/wardby-claude-tool-runner@sha256:<digest>`. If the
+   value is a local image ID (`sha256:...` only), give it a name first, because
+   Docker cannot build `FROM` a bare ID:
+   `docker tag sha256:<id> wardby-tool-runner-base:local`.
+2. **Make a build folder.** Use a small folder of your own, outside your
+   repository. Put in it the Dockerfile and only the files the Dockerfile
+   copies.
+3. **Write the Dockerfile.** Start from the image in step 1, install your tools
+   as `root`, then switch back to the tool runner's user:
+
+   ```dockerfile
+   FROM <image from step 1>
+   USER root
+   RUN apt-get update \
+       && apt-get install -y --no-install-recommends <your packages> \
+       && rm -rf /var/lib/apt/lists/*
+   USER 10001:10001
+   ```
+
+   Keep these rules:
+   - The last `USER` line is `USER 10001:10001`.
+   - Do not set `ENTRYPOINT` or `CMD`. The tool runner starts with the base
+     image's own entrypoint.
+   - Install everything at build time. A run cannot install system packages.
+   - Put tools in `/usr/local/bin` or `/usr/bin`. Do not put anything under
+     `/tmp` or `/home/wardby`: a run hides both.
+   - Put environment settings your commands need in a file under
+     `/etc/profile.d/` (see "How the tool runner runs commands" below). `ENV`
+     lines in the Dockerfile do not reach the agent's commands.
+
+4. **Build it:** `docker build --tag <name> <build folder>`. Release images are
+   `linux/amd64`. On an ARM machine, add `--platform linux/amd64` here and to
+   `docker run` in step 5.
+5. **Run the tests the way a run would.** Clone the repository to a throwaway
+   folder (on Linux, make it writable: `chmod -R a+rwX <clone>`). Then run the
+   project's test command with a run's restrictions and its fixed environment,
+   so `ENV` lines in the image do not apply:
+
+   ```sh
+   docker run --rm --read-only --tmpfs /tmp:rw,noexec,nosuid,size=64m --tmpfs /home/wardby:rw,noexec,nosuid,size=64m,uid=10001,gid=10001,mode=0700 --network none --user 10001:10001 --cap-drop ALL --security-opt no-new-privileges -v <clone>:/workspace -w /workspace --entrypoint env <name> -i HOME=/home/wardby LANG=C.UTF-8 PATH=/opt/wardby/bin:/usr/local/bin:/usr/bin:/bin sh -lc '<test command>'
+   ```
+
+   On an ARM machine, add `--platform linux/amd64` after `docker run`. Fix the
+   Dockerfile until the tests pass, then delete the clone.
+
+6. **Get an immutable reference.** A tag is refused.
+   - **Docker launcher** (wardby runs coding jobs with Docker on a single
+     machine): use the local image ID,
+     `docker image inspect --format '{{.Id}}' <name>`. Build on that machine.
+     Wardby never pulls these images.
+   - **Kubernetes:** push the image to a registry your cluster can pull from,
+     and use `<registry>/<name>@sha256:<digest>`.
+7. **Point the agent at it.** Call `update_agent` with the agent's id. This
+   needs the `agents:admin` scope and the admin role:
+
+   ```json
+   {
+     "id": "<agent id>",
+     "codingProfile": { "workerImageRef": "<reference from step 6>" }
+   }
+   ```
+
+8. **Try it.** Trigger a small task that uses your tools, such as "Run the
+   project's tests and report the results. Change nothing."
+
+To undo it, set `codingProfile.workerImageRef` to `null`. The agent then uses
+the standard tool runner for its `toolchain`.
+
+### Languages other than Node and Python
+
+A run can download packages only from wardby's package registry, which serves
+npm and PyPI. Packages for any other language must be in the image. If a
+package compiles native code, compile it in an earlier build stage and copy
+only the results into the final image. The final image then needs no compiler.
+
+The tool runner is based on Debian 12 (bookworm). Build stages that compile
+code must use a bookworm-based image too, so the results work with the tool
+runner's system libraries.
+
+This example adds Ruby and a project's gems. It is a starting point to adapt,
+not a tested recipe. Copy the project's `Gemfile` and `Gemfile.lock` into the
+build folder first.
+
+```dockerfile
+# Stage 1: install Ruby and the project's gems, compiling any native code.
+FROM ruby:3.3-slim-bookworm AS builder
+RUN apt-get update \
+    && apt-get install -y --no-install-recommends build-essential \
+    && rm -rf /var/lib/apt/lists/*
+ENV BUNDLE_PATH=/usr/local/bundle \
+    BUNDLE_DEPLOYMENT=true
+WORKDIR /build
+COPY Gemfile Gemfile.lock ./
+RUN bundle install
+
+# Stage 2: the tool runner from your wardby release, plus Ruby and the gems.
+FROM <tool runner image from step 1>
+USER root
+# Shared libraries Ruby needs at run time, plus any library your native gems
+# link to (for example libpq5 for pg).
+RUN apt-get update \
+    && apt-get install -y --no-install-recommends libffi8 libgmp10 libssl3 libyaml-0-2 zlib1g \
+    && rm -rf /var/lib/apt/lists/*
+# Ruby lives in /usr/local, and the gems in /usr/local/bundle.
+COPY --from=builder /usr/local /usr/local
+# Settings for the agent's commands (Dockerfile ENV lines do not reach them).
+RUN ldconfig \
+    && printf '%s\n' \
+      'export GEM_HOME=/usr/local/bundle' \
+      'export BUNDLE_PATH=/usr/local/bundle' \
+      'export BUNDLE_APP_CONFIG=/usr/local/bundle' \
+      'export BUNDLE_DEPLOYMENT=true' \
+      > /etc/profile.d/ruby.sh \
+    && sh -lc 'ruby --version && bundle --version'
+USER 10001:10001
+```
+
+Pin the `ruby` image by digest for repeatable builds. Rebuild the image when
+the project's `Gemfile.lock` changes.
+
+### If a run fails
+
+| What you see                            | What it usually means                                                                                                                                  |
+| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `worker_tool_runner_unreachable`        | The image was not built `FROM` the tool runner of the same wardby release, or the Dockerfile changed its `USER` or `ENTRYPOINT`.                       |
+| A command is "not found"                | The tool is not in the image, or a setting it needs is in an `ENV` line instead of `/etc/profile.d/`.                                                  |
+| "Permission denied" when running a file | On Docker, something writes a program to `/tmp` or `/home/wardby` and runs it. Point that tool's temporary or cache folder under `/workspace/.cache/`. |
+
+### How the tool runner runs commands
+
+These details explain the rules above.
+
+- **User and privileges.** Commands always run as user `10001`, with no Linux
+  capabilities and `no-new-privileges`. `root` and setuid programs do not work
+  at run time.
+- **Filesystem.** The root filesystem is read-only. `/tmp` and `/home/wardby`
+  are small, empty scratch space; anything the image put there is hidden. On
+  Docker, files there cannot be run. `/workspace` holds the repository; put
+  caches, build output and temporary files under `/workspace/.cache/`.
+- **Shell and environment.** Each command runs as `sh -lc "<command>"` with a
+  fixed environment: `HOME=/home/wardby`, `LANG=C.UTF-8`, `TMPDIR` under
+  `/workspace/.cache/`, wardby's package registry settings, and
+  `PATH=/opt/wardby/bin:/usr/local/bin:/usr/bin:/bin`. The login shell reads
+  `/etc/profile` and the files in `/etc/profile.d/`, so that is where your own
+  settings go. `/etc/profile` resets `PATH` to Debian's default, so add any
+  other folder to `PATH` in your `/etc/profile.d/` file.
+- **Network.** The tool runner reaches only wardby's package registry (npm and
+  PyPI).
+- **Images on the Docker launcher are never pulled.** When wardby runs coding
+  jobs with Docker on a single machine, the image must already be on that
+  machine. Kubernetes needs a registry digest
+  (`repo@sha256:<64 hex>`).
+- **Server settings.** Claude Code itself always runs on
+  `CODING_CLAUDE_WORKER_IMAGE`. The server still needs both
+  `CODING_CLAUDE_WORKER_IMAGE` and `CODING_CLAUDE_TOOL_RUNNER_IMAGE` set, even
+  for agents with their own `workerImageRef`.
+- **Toolchain.** While `workerImageRef` is set, `toolchain` and
+  `toolchainVersion` do not choose the image, for either builder.
+
 ## Running services with a BYO image
 
 An agent whose `codingProfile.services` allows a service ([coding
@@ -85,6 +308,20 @@ a worker built on an older driver base doesn't recognize the input's
 without them. Rebuild your image on a current `driver-vN` digest (see "The
 driver image" above) before allowing any service on an agent that uses it.
 
+## Repository skills need a current driver
+
+On a Codex agent, a `workerImageRef` image never receives Claude Code's
+repository context (`claudeContext`) or `claudeBareMode`. The one new input key
+it can see is `repoSkills`, which wardby writes only when an agent sets
+`repoSkills: false`. A worker built on
+an older driver base validates its input with a strict schema, so it rejects
+runs of agents with `repoSkills: false` (the run fails with
+`worker_input_failed`), and it keeps offering Codex's built-in skills
+(`imagegen`, `openai-docs`, `skill-creator`, `skill-installer`), which a
+current driver always disables. Rebuild any `workerImageRef` image on a
+current `driver-vN` digest (see "The driver image" above) before relying on
+either behavior.
+
 ## What this doesn't cover
 
 wardby does not re-validate the contents of your built image beyond the

package/docs/coding-worker-isolation.md

@@ -1,16 +1,24 @@
 # Coding Worker Isolation
 
-Wardby supports isolated Codex execution with Docker or Kubernetes and
-credential-separated Claude Code execution with Docker. Both launchers fail
-closed when the effective runtime does not match the reviewed policy.
+Wardby runs Codex and Claude Code coding workers through Docker or Kubernetes
+launchers. Both fail closed when the effective runtime does not match the
+reviewed policy. Claude Code separates its model-facing worker from its
+workspace-facing tool runner: Docker uses companion containers, while
+Kubernetes uses a native sidecar in the run pod.
 
 ## Security Boundary
 
-Coding-agent repositories and instructions are untrusted. The Docker daemon,
-host kernel, Wardby control plane, immutable worker image, and dedicated coding
-proxy are trusted. Containers are defense in depth rather than a VM boundary;
-production should run the Docker host on a dedicated worker node or VM with no
-production credentials beyond those required by the proxy.
+Coding-agent repositories and instructions are untrusted. The Wardby control
+plane, immutable worker images, dedicated coding proxy, and the platform
+enforcing container and network policies are trusted.
+
+### Docker launcher
+
+The Docker daemon and host kernel are trusted. Docker containers are defense
+in depth rather than a VM boundary. Production should run the Docker host on a
+dedicated worker node or VM with no production credentials beyond those
+required by the proxy. The Kubernetes launcher section below describes the
+corresponding pod and network rules.
 
 The Codex worker has one network attachment: a unique per-run internal bridge using
 Docker's isolated gateway mode. It has no default external route, published
@@ -588,6 +596,7 @@ Kubernetes-specific settings (`src/config/providers.ts`,
 | `KUBERNETES_CONTEXT`            | (unset → in-cluster/default kubeconfig context) | Which kubeconfig context `ClientNodeKubernetesApi` connects with.                                                                                                                                                                                                                                     |
 | `KUBERNETES_RUNTIME_CLASS`      | (unset)                                         | e.g. `gvisor` on GKE. Unset means pods run without a sandboxing runtime class — logged once per launch as `kubernetes_runtime_class_unset` and development-only.                                                                                                                                      |
 | `KUBERNETES_RESOURCE_QUOTA`     | (unset)                                         | Name of the namespace ResourceQuota run pods count against, e.g. `wardby-coding` in the GKE overlay. When set, a run whose pod would not fit the quota's free room waits in the coding queue instead of failing at pod create. Needs `get` on that one `resourcequotas` object. Unset means no check. |
+| `KUBERNETES_PLATFORM`           | `generic`                                       | `generic`, `gke-autopilot` or `eks`. Selects the cluster's admission rules that run pods are conformed to. `gke-autopilot` and `eks` both require `KUBERNETES_RUNTIME_CLASS=gvisor`; see the platform profile section below.                                                                          |
 | `KUBERNETES_RUN_PRIORITY_CLASS` | (unset)                                         | PriorityClass for run pods and the preflight canary, e.g. `wardby-coding-run` in the GKE overlay. Must be an existing class and a DNS-1123 subdomain; `system-` classes are refused. Unset means no class (priority 0).                                                                               |
 
 The `CODING_CPUS` / `CODING_MEMORY_MB` / `CODING_PIDS` / `CODING_DISK_MB` /
@@ -798,6 +807,16 @@ landed on — cannot appear in it. That case reached a live Autopilot launch wit
 every dry-run-derived check passing, and is now pinned by tests. Treat a
 captured fixture as a lower bound on what a platform mutates.
 
+The `eks` profile is for Amazon EKS clusters with a dedicated gVisor node group.
+EKS has no managed sandbox runtime, so the cluster must provide a RuntimeClass
+named `gvisor` with handler `runsc` whose `scheduling` block selects nodes
+labelled `wardby.dev/sandbox=gvisor` and tolerates the taint
+`sandbox=gvisor:NoSchedule` on those nodes. Kubernetes' RuntimeClass admission
+merges that block into each pod; Wardby sets neither the node selector nor the
+toleration itself, and the `eks` profile forgives exactly that nodeSelector and
+that toleration and nothing else. Pod resources follow the generic rules, plus
+an explicit ephemeral-storage request and limit.
+
 ### The enforcement gate
 
 The Kubernetes API can create a NetworkPolicy object without that policy
@@ -808,12 +827,12 @@ not just the harness: the worker gate could otherwise
 open on a pod whose isolation isn't active yet.
 
 The fix, before seeding or opening the worker gate: the launcher execs into
-the keeper (which shares the pod's network namespace with the worker) one
-`node -e` probe that measures **both of the coding proxy's ports against the
-proxy Service's ClusterIP, in the same pass** — `8787` (the proxy itself, which
-the run policy permits) and `8788` (the deny port, which no run policy ever
-permits). Only the outcome **(8787 connected, 8788 blocked)** counts toward the
-streak.
+the keeper (which shares the pod's network namespace with the worker) a
+`node -e` script whose every probe measures **both of the coding proxy's ports
+against the proxy Service's ClusterIP, in the same pass** — `8787` (the proxy
+itself, which the run policy permits) and `8788` (the deny port, which no run
+policy ever permits). Only the outcome **(8787 connected, 8788 blocked)** counts
+toward the streak.
 
 Stated exactly, that outcome proves: **the SYN to 8788 was dropped somewhere on
 the path, while the same destination answered on 8787.** That the drop was the
@@ -861,10 +880,21 @@ from "unserved" is not a witness — and such a cluster needs a different one.
 
 It requires **3 consecutive proven results, 500ms apart** (anything else
 resets the streak — this guards against a single dropped SYN packet on an
-allowed path being misread as "policy enforced"), bounded by
-`enforcementTimeoutMs` (default 30,000ms — configurable via
+allowed path being misread as "policy enforced"). The whole streak runs in a
+single keeper exec: the script exits successfully only after three consecutive
+proven probes, and stops at the first probe that is not proven, exiting with
+that probe's result. A broken streak is retried from zero 500ms later, bounded
+by `enforcementTimeoutMs` (default 30,000ms — configurable via
 `KubernetesJobLauncherOptions.enforcementTimeoutMs`; a drop-style CNI can
-need close to this whole window). The verdict at the bound comes from the
+need close to this whole window). Each probe has a time budget of
+`KUBERNETES_ENFORCEMENT_EXEC_TIMEOUT_MS` (default 10,000ms), so one streak exec
+is allowed three budgets plus the two 500ms gaps (31,000ms at the default), and
+the launcher never lets `enforcementTimeoutMs` fall below that one-streak value
+— at the defaults the effective bound is therefore 31,000ms. The bound is
+checked between streak execs, so a launch can run past it by up to one streak
+exec. An exec that exceeds its timeout fails the launch with
+`kubernetes_exec_timeout`. The
+verdict at the bound comes from the
 _last_ probe — not from whether any probe was ever unavailable, so an early
 blip while the pod's networking came up does not misdirect the operator — and
 the three non-proven outcomes stay distinct, because each sends an operator
@@ -900,9 +930,9 @@ default 90,000ms):
 1. `platform` — pure configuration, checked before any cluster API call:
    `assertPlatformConfig` (`src/providers/jobs/kubernetes-platform.ts`) refuses
    a deployment that cannot work under `KUBERNETES_PLATFORM`. Under
-   `gke-autopilot` this means `KUBERNETES_RUNTIME_CLASS` must be `gvisor`
-   (gVisor is mandatory there — an unset or different runtime class is refused,
-   not warned about), and the effective `CODING_MAX_DISK_MB` must leave room
+   `gke-autopilot` and `eks`, `KUBERNETES_RUNTIME_CLASS` must be `gvisor` (an
+   unset or different runtime class is refused, not warned about). Under
+   `gke-autopilot` the effective `CODING_MAX_DISK_MB` must also leave room
    for the worker container's 1 GiB reservation inside Autopilot's 10 GiB pod
    ephemeral-storage ceiling. The same assertion runs again at process
    start-up in `buildConfiguredExecutor`
@@ -931,20 +961,55 @@ default 90,000ms):
 5. `canary` — creates a real run pod + NetworkPolicy from the same builders
    as a live run, running a script that waits for policy enforcement (as
    above) then attempts DNS resolution, a connect to the proxy's deny port,
-   the internet (`1.1.1.1:443`), the metadata server, and the proxy itself —
-   requiring every one of the first four to fail and the proxy connect to
+   the internet (`1.1.1.1:443`), the cloud metadata endpoints (`169.254.169.254:80`,
+   the EKS Pod Identity agent `169.254.170.23:80` and its IPv6 address
+   `[fd00:ec2::23]:80`, and EC2's IPv6 metadata address `[fd00:ec2::254]:80`), and the proxy itself —
+   requiring every one of the first four kinds to fail and the proxy connect to
    succeed. Any other outcome, or a canary pod that itself fails to
    schedule/run, is `kubernetes_isolation_unsupported:canary`.
 
 This whole preflight is **memoized per launcher instance and its failure is
 sticky**: `KubernetesJobLauncher.runPreflight()` caches the first call's
-promise (`this.preflightResult ??= ...`, `kubernetes.ts:472-487`), including
+promise (`this.preflightResult ??= ...`, `kubernetes.ts:790`), including
 a rejection — so once a launcher process has seen preflight fail, every
 subsequent `launch()` in that process fails immediately with the same error
 without re-probing the cluster. A fresh preflight requires a new process
 (or, from the CLI, a fresh `wardby coding preflight` invocation, which is
 not memoized).
 
+**A long-running server process starts this same memoized preflight at
+start-up, not on the first coding run.** `wardby serve`, `wardby mcp` (both
+transports), and `wardby scheduler` each call `KubernetesJobLauncher.warmUp()`
+right after the executor is built, fire-and-forget: it runs the identical
+preflight `launch()` would otherwise run lazily, so the first coding run
+after a restart doesn't pay the preflight's own cost (a canary pod, routinely
+tens of seconds on a resource-constrained cluster such as `kind`).
+`wardby scheduler` needs this just as much as the other two — it dispatches
+scheduled coding runs through its own Kubernetes executor without ever
+starting an MCP server, so without this it would still pay the lazy cost on
+its first scheduled run. The result is logged once at start-up — an info
+line on success, a warning naming the failure code (e.g.
+`kubernetes_isolation_unsupported:<check>`) otherwise.
+
+**A start-up warm-up's failure is logged and retried on the next run, not
+left stuck until restart.** This is the one way a preflight failure is
+_not_ memoized: a transient cluster problem at process start (the API
+server briefly unreachable, a slow CNI not yet programmed, and the like)
+must not fail every coding run for the rest of that process's life, so a
+failed warm-up clears its own failed attempt once it has logged it, and the
+_next_ `launch()` runs the preflight fresh — succeeding if the cluster has
+since recovered. A `launch()` that was already waiting on that same
+in-flight warm-up attempt still fails with that attempt's error (it shares
+the same preflight call), exactly as it always has; it's only the attempt
+_after_ that one which retries. A preflight failure `launch()` triggers
+itself — because no warm-up ran, or because a warm-up's cleared failure was
+never retried before the next `launch()` found the cluster still broken —
+keeps the original behavior exactly: it stays memoized, failing every
+subsequent `launch()` in that process until it is restarted. This never
+runs for a one-shot CLI command (`wardby run`, `wardby coding preflight`,
+migrations, imports) — only for a process that stays up to serve or
+dispatch runs.
+
 **A hung pod create during preflight can leave a preflight pod and its
 NetworkPolicy behind.** If `createPod` never settles (rather than failing),
 the preflight's own timeout still fires and the caller sees `:timeout`, but