parallel-wavelisted

# Parallel Wave Turn a batch of ready issues into concurrent delivery lanes. Parallelism is the **output of a judgment machine**, never a preference. Composes with fleet-orchestrate (controller contract) — this skill decides *what runs concurrently and how*; fleet-orchestrate governs roles, briefs, and review. ## Unit of parallelism One issue = one bundle = one **single-phase** conduct plan = one worktree = one build lane. Parallelism happens *between* plans (conductor already runs plans concurrently), never inside one plan. Never write declarative `depends_on` chains: a dependency edge must name a real reason (same symbols, same invariant, API/schema order). Plan YAMLs live outside the repo (scratchpad or `.tmp/plans/`) so agents cannot commit them. ## Layer 1 — static judgment (before dispatch) Layer 1's input **is** the select-this-batch table from fleet-orchestrate's ready-batch selection procedure — a batch never appears from nowhere. That table already applied the exclusion checklist (cross-machine claims, in-flight PRs/remote branches, `needs-operator`); this layer starts from its selected rows and does not repeat those checks. Ready-queue intake is a machine check, not memory (GH-665): source candidate issues from `scripts/fleet/ready-queue-lint.sh`, never a raw `gh issue list --label fleet:ready` — the script excludes open issues whose delivery PR already merged, so a delivered issue still carrying `fleet:ready` is never dispatched. Derive each issue's predict