[webandseo]

Three fixes to run tracking, found on Windows. One commit per fix, reviewable separately; each builds on the one before, so they come as one PR.

1. Refuse concurrent write-capable delegate runs; fix the Windows liveness check

The muse-delegate subagent ran run --write in the foreground. Claude Code's Bash tool moved it to the background after its 120 s default timeout, and the subagent then called run again, so two write-capable Muse runs edited the same checkout at once.

• process.mjs: isProcessAlive() asked ps -o stat= after signal 0 to spot zombies. On Windows ps is either missing or Git Bash's (no -o), so every live process looked dead. Windows now trusts signal 0 (ESRCH = dead, EPERM = alive); POSIX keeps the zombie check.
• muse-bridge.mjs: run --write refuses to start while another write-capable run in the workspace is alive, names its id with the /muse:runs <id> --wait and /muse:stop <id> follow-ups, and exits non-zero. Stale records are marked failed instead of blocking. --allow-concurrent overrides. Foreground runs print their run id to stderr so a backgrounded call can still be followed.
• muse-delegate agent, muse-delegate-runtime skill, /muse:delegate: the single Bash call sets timeout 600000; if it is backgrounded or times out, the subagent returns the notice and run id and never calls run again.

2. Make the write-run guard atomic

The guard read the run list without a lock, and the new run's record was written later, so run --write calls started together could all pass the check. claimWriteSlot now checks for a live write run and records the new one as queued inside a single state lock.

3. Mark runs whose processes are gone as failed everywhere

A run whose bridge and muse processes had exited (an interrupted foreground review or delegate, a killed worker, a closed terminal) stayed running forever:

• runs <id> --wait sat out its whole timeout and returned running.
• stop answered "process may still be running (kill not delivered)" for a process that had died long before.
• --resume refused with "still running", and run-resume-candidate did not offer the interrupted run.

retireDeadRuns claims each dead queued or running run as failed under the state lock and logs it only when the claim wins, so a run that completed in the meantime is left alone. runs, show, stop, resume and run-resume-candidate call it first, and runs --wait calls it on every poll. The write guard uses the same helper. Runs with no pid yet keep a 60 s grace.

README and CHANGELOG (Unreleased) are updated.

Tests

• process.test.mjs: live and exited children, signal 0 on win32 without ps, POSIX zombies still dead.
• job-control.test.mjs (new): live/stale partitioning with the no-pid grace, sequential claimWriteSlot, a four-process race on claimWriteSlot, and retireDeadRuns (dead review, dead read-only run, live run, finished run).
• runtime.test.mjs: write-run refusal and --allow-concurrent; a CLI race of three concurrent run --write --background calls; a dead write run retired by the guard; the foreground run id notice; runs, runs --wait and show on a dead run; a run that dies while --wait is polling; stop on a dead run; --resume-last and run-resume-candidate after a run died.
• commands.test.mjs: the delegate forwarding contract (long Bash timeout, no second run, --wait kept on the Claude side).
• Both race tests fail against a check-then-record guard, and the mid-wait test times out without the per-poll retire.
• Local suite on Windows 11, Node 24: 104/104 pass.

🤖 Generated with Claude Code

[rtravellin]

Thanks for this, really solid work. The write-run guard, the atomic claim, and cleaning up dead runs all fix real problems, and the tests are great, especially the race tests.

Three things I'd like changed before merging:

1. Live runs get marked failed when ps isn't available. isZombieProcess returns true (dead) when ps can't run or exits non-zero. That was harmless when only stop used it, but retireDeadRuns now calls it on every runs/show/stop/resume and every --wait poll. On a box without ps (e.g. slim Docker images), /muse:runs marks every active run failed while it's still working, and the real result is thrown away when it finishes. Since signal 0 has already shown the process exists, can we count it as alive when ps itself fails? It's the same thing you fixed for Windows, just on the POSIX side.

2. The guard blocks --worktree runs. Worktree runs edit their own checkout under .muse/worktrees/, so they can't clash with the live checkout or with each other. Right now run --write --worktree is refused while any other write run is going, and a worktree run blocks a normal one. Could you record the worktree flag on the job and leave worktree runs out of partitionActiveWriteRuns?

3. (minor) A stop prefix can match the wrong run. handleCancel looks at the just-retired runs first, so if a partial id matches both a dead run and a live one, it prints "had already ended… Nothing to stop" and the live run keeps going. I'd expect the usual "ambiguous reference" error there.

Happy to merge once 1 and 2 are in. 3 can go in this PR or a follow-up, whichever you prefer.

[webandseo]

All three addressed in b8b5801:

1. isZombieProcess only reports dead when ps shows a zombie state; a missing/failing ps or empty output keeps the pid alive since signal 0 already found it. Test covers ENOENT, non-zero exit, empty stdout and a throw.
2. Task jobs record worktree; partitionActiveWriteRuns excludes them and run --write --worktree skips the guard, so worktree runs neither wait for nor block other write runs. The flag is also kept on the foreground record path in runTrackedJob.
3. stop resolves the reference against just-retired and live runs together, so a prefix matching both gets the usual "ambiguous" error.

[rtravellin]

Thanks, all three look good. Merging.