Roster preflight

Run this first, every run, before planning or dispatching anything.

1. Harnesses — RESOLVE IS NOT ENOUGH, YOU MUST INVOKE

Start with resolution, one call, not one per worker:

command -v claude codex agy || true

Then actually run each one. A resolved path proves nothing:

for b in claude codex agy; do
  command -v "$b" >/dev/null 2>&1 || { echo "$b MISSING"; continue; }
  if timeout 60 "$b" --version >/dev/null 2>&1; then echo "$b OK"
  else echo "$b RESOLVES BUT FAILS TO RUN"; fi
done

This is not paranoia. Measured on this machine, 2026-08-14: command -v codex resolved successfully to /mnt/c/.../AppData/Roaming/npm/codex — the Windows npm shim reached through /mnt/c — and invoking it under WSL died with Missing optional dependency @openai/codex-linux-x64. A resolve-only preflight declared four of nine agents available when all four were dead, and the failure surfaced as a sub-agent that dispatched and simply never returned.

An agent is available only if its harness ran. Route work only to those.

Watch the shell. agy lives in ~/.local/bin, which a non-login shell does not have on PATH — bash -c "which agy" fails while bash -lc "which agy" succeeds. A missing binary that is actually a PATH artifact will silently shrink your roster in the other direction.

Windows-installed harnesses do not work under WSL. If a binary resolves to a /mnt/c/... path, treat it as suspect until it passes the invoke test — most CLIs ship platform-specific native dependencies and the shim will resolve on both sides while only executing on one.

2. Models — an empty list is NOT a verdict

Call sys_list_models and confirm each agent's configured model is actually runnable on this deployment's credentials.

But sys_list_models is not authoritative for harnesses that carry their own authentication. Antigravity signs in with its own Google account, independent of Omnigent's credential store. On this machine omnigent config list reports Gemini (none configured) and sys_list_models returns models: [] for every antigravity agent — and those agents dispatch and return correctly anyway.

An empty or missing model list therefore means unverified, not unavailable. Resolve it with a bounded probe rather than a verdict:

Dispatch that agent one trivial read-only task (pwd, reply with one line) with a hard timeout of ~120s. Returns in time → AVAILABLE. Times out → UNAVAILABLE.

This is the one sanctioned exception to "do not test by dispatching." The reason that rule exists is that a dead harness hangs forever — so the timeout is the test, and it is safe precisely because it is bounded. Never probe by dispatching real work.

Marking a working agent unavailable is not the safe error. It shrinks a team below its convene threshold and halts a run that should have proceeded, and it sends the operator off to reinstall software that was fine. The model IDs in agents/*/config.yaml were written from the operator's naming and have not been verified against a live provider. An invalid model/harness pair fails loud at dispatch — read the error and adjust rather than retrying blindly.

Note that harnesses are vendor-bound: Antigravity runs Gemini only and will not run Claude or GPT-family models; Codex runs GPT; claude-sdk / claude-native run Claude.

3. Skill roots — the one people skip

Skill-path resolution is the most frequently recorded failure in these repos (eight logged incidents: wrong skill root, root misresolved, skill reference absent, catalog path lookup). Checking that a CLI exists tells you nothing about whether it can find its skills.

For each available agent, verify it resolves its catalog:

Verify by reading a SKILL.md through the path and parsing its name: and description: lines — not by counting files and not by ls. These catalogs are symlink farms into /mnt/c, and several tools traverse them incorrectly: ripgrep and grep -r silently return zero matches on the Windows-side NTFS junctions while a direct read of the same file succeeds. A count is not evidence.

Also confirm no broken links: find <root> -maxdepth 1 -xtype l.

3b. If you have no shell, say so — do not report anyway

Before checking anything, confirm you actually have a shell tool. If you do not, the correct output is one line:

PREFLIGHT IMPOSSIBLE — no shell tool in this session. Roster not certified.

Then stop. Do not produce a roster table.

This is not hypothetical. On this framework's first dry run the orchestrator had no shell tool registered, and it returned a fully formatted roster table declaring nine agents unavailable and three skill roots absent. All three roots existed, with 40, 16, and 42 entries, readable. The report was fabricated, confident, and would have sent the operator to reinstall working software.

Every line of your report must be backed by output you actually saw. Paste the raw command output verbatim under each check before drawing any conclusion from it. A preflight that asserts findings without pasting evidence is exactly the unevidenced delivery this framework rejects everywhere else — and it is worse here, because the whole point of preflight is to be the thing you can trust before anything else runs.

4. Report

Say nothing when everything resolves — get on with the task. A missing binary, an unavailable model, or an unresolvable skill root is the only roster fact worth words: name it, say which agent is affected, and tell the PM what to install or fix. Then run with the reduced roster only if the affected team still meets its convene threshold; if it does not, halt.