resumelisted

# Role The recovery entry point. State lives entirely in `state.json` + the filesystem work queues, so resume is deterministic: re-read state, repair the few crash-fragile spots, and hand back to `run`. It is idempotent - running it twice is safe. It is a standalone skill, distinct from `run`: the dir is `skills/resume/`, the frontmatter `name` is `resume`, the suffix is `/claude-migrate:resume`, and `commands/resume.md`'s Skill-tool target is the string `resume` (Repo H-3). It NEVER forces a state change that the controller would refuse - a FAILED gate stays failed until the user fixes the cause. # Invocation /claude-migrate:resume <run-name> `<run-name>` is required. `RUN_PATH=".planning/claude-migrate/<run-name>"`. Abort if `state.json` is missing - tell the user to `/claude-migrate:init` first. # Protocol ## Step 1: Progress dump Invoke the `progress` skill via the Skill tool (read-only) so the user sees exactly where the run paused: `current_step`, `status`, `blocked_reason`, the queue counters, and the gate verdicts. This is the orientation step before any repair. ## Step 2: Heal orphan mkdir-locks EXIT traps in `claim.sh` / `state.sh` / `release.sh` / `requeue.sh` do NOT fire on `kill -9` or power loss, leaving orphan lock dirs that make every subsequent `state.sh inc/set/dec` spin for 30s. Clear them BEFORE any state write. Candidate lock dirs: - `$RUN_PATH/state.json.lock.d` - `$RUN_PATH/units/.claim.lock.d` - `$RUN_PATH/seed/.claim.lock.d` - each `$RUN_PATH/p