Check

/rl:check — preflight one Lego-RL run

Answers one question: is it safe to launch this config right now?

Deterministic checks come from the runner itself (never re-implemented here); this skill adds the local live layer and prints one report ending in a clear YES / NO. Read-only — it never edits a config and never launches.

/rl:check <config>
   │
   ├─ 1. PREFLIGHT_ONLY=1 <kind>.sh <config> ... resolved parameters + OK/WARN/FATAL
   │
   ├─ 2. lib/live_probe.sh <kind> .......... local facts; this skill judges ownership
   │
   └─ 3. report ............ verdict + status table + run parameters + next steps

Each check lives in exactly one layer:

Everything is local host only — no SSH to 221/222/240/243, no cluster mutation. Cluster-side faults (registry down, kyverno crash-looping, a node missing its insecure-registry config) are out of scope here; they surface as env_setup_failed once a run is live, which is /rl:status's job.

Step 0 — Orient

Repo root is the Lego-RL checkout (contains scripts/lib/preflight.sh). If the user ran this from elsewhere, locate it; if there is none, abort — but still print the Step 3 report with a NO verdict whose reason is the abort.

Resolve the config. The argument may be a full path, a bare filename, or absent:

• full/relative path that exists → use it;
• bare name (qwen35a3b_4n_mix1582, smoke_sync_cc_qwen35a3b_243.env) → search scripts/{train,eval,infer}/configs/ then .../templates/;
• absent, or more than one match → list the candidates (ls scripts/*/configs/*.env) and ask which one. Do not guess.

Infer the kind from the resolved path: scripts/train/… → train, scripts/eval/… → eval, scripts/infer/… → infer. If the path is ambiguous, read the config: TRAIN_MODE/N_NODES_ROLLOUT → train, DATASET_PATH/DATASET_NAME → eval, RESULTS_DIR/OUTPUT_INDEX → infer.

Read scripts/README.md for context if you need the axis vocabulary. Do not echo config or README content into the report.

Step 1 — Deterministic checks

PREFLIGHT_ONLY=1 bash scripts/train/train.sh <config> 2>&1; echo "EXIT=$?"

This one command sources the config and its templates, resolves every derived value, prints the run configuration block, then runs preflight.sh and exits without launching. Read its output as-is — never re-run a probe separately and never overrule an OK.

Only the train runner has PREFLIGHT_ONLY. For an eval or infer config, use bash scripts/<kind>/<kind>.sh --dry-run <config>: it resolves and prints everything the same way but does not run preflight.sh, so for those two kinds the deterministic layer is thinner — say so in the report rather than implying the config passed rules that never ran.

Two things need follow-up:

• the run configuration (<kind>) block → copy verbatim into the report; on an SAO / critic run it carries extra gae:, bypass: and critic lines — quote them too, they are what rule 10 (SAO / critic) of preflight.sh judged;
• a non-zero EXIT with no ✗ FATAL line → the runner died before preflight (bad config syntax, missing PROJECT_NAME/EXP_TAG, unreadable venv). Treat as a blocking failure and quote the error.

preflight.sh failing is never something to work around. Every ✗ FATAL has an entry in the Troubleshooting section of the docs site; point the user at it.

Step 2 — Live checks

bash scripts/lib/live_probe.sh <kind> 2>&1

The probe prints facts only (OK / WARN / INFO); deciding whether a process is ours is this skill's job. Four outcomes block a launch — job:running, gpu:foreign, port:conflict, import:missing. Everything else is advisory.

2a — Is a run already in flight?

A second run on the same GPUs OOMs or corrupts both.

On job:running, record the PID set — call it the run tree; it anchors the ownership tests below. Report pid + etime, and tell the user to let it finish or stop it themselves (kill -INT <pid>). Never kill anything.

2b — Are the GPUs free, mine, or a foreign job's?

Input: each WARN gpu:busy pid=<pid> comm=<comm> mem=<mem> line.

Ownership test: walk the parent chain (ps -o ppid= -p <pid>, repeated) and see whether it reaches a PID in the run tree. A VLLM::Worker_TP* / EngineCore holding ~130GB with no runner above it is someone else's serving job — block, report pid + memory + etime, and let the user decide whether to wait or ask its owner. This box is shared; a foreign vLLM squatting on all 8 GPUs is the common case, not an anomaly.

If nvidia-smi is absent (INFO gpu:absent), emit gpu:unknown (⚠) and say the GPU layer could not be judged — do not silently pass it.