Failed or inconsistent config-preflight commands can report worker capacity

[sylvesterkaczmarek]

Summary

The worker-status parser can report delegation/capacity from a config_preflight.py command whose execution metadata contradicts the helper result, because preflightStatus() validates the command text and JSON payload but does not reconcile the command's explicit status/exit code with that payload.

Reproduction / evidence

Current upstream main at 37bf87a692fc72d41f7312cc48808d699d204fba routes completed command events through preflightStatus() whenever the command matches config_preflight.py and aggregated_output contains a recognized capability document.

A deterministic contradictory event is:

{
  type: "item.completed",
  item: {
    type: "command_execution",
    command: "python3 /plugin/scripts/config_preflight.py --profile security_scan",
    status: "failed",
    exit_code: 2,
    aggregated_output: JSON.stringify({
      profile: "security_scan",
      status: "ready",
      results: [
        { capability: "delegated_workers", status: "pass" },
        { capability: "usable_worker_slots_6", status: "pass", actual: 8 },
      ],
    }),
  },
}

Current behavior: workerStatusFromEvent() reports delegation available with configuredSlots: 8.

Expected behavior: explicitly failed or internally inconsistent command metadata must not be presented as trustworthy capability evidence.

Important exit-code semantics

config_preflight.py intentionally uses nonzero exit codes for valid evaluated states:

• ready -> 0
• blocked -> 1
• incomplete -> 2
• helper/parser error -> 2 with an error envelope

So a blanket exit_code !== 0 rejection would be wrong: valid blocked/incomplete results can still contain useful delegation/capacity observations.

Root cause

preflightStatus() checks the outer event and payload shapes independently but never reconciles them.

Suggested fix

• always reject item.status === "failed";
• when a numeric exit_code is present and the payload has a recognized top-level status, require the documented status/exit mapping;
• for legacy payloads that omit a top-level status, retain exit 0 compatibility but reject unexplained nonzero exits;
• preserve valid blocked and incomplete capability observations.

Add focused regressions for explicit command failure, contradictory status/exit combinations, and valid ready/blocked/incomplete controls.

Impact

This is observability correctness. The CLI/dashboard can otherwise display worker delegation and configured capacity from execution metadata that says the helper did not produce that successful result.