[webandseo]

stop <id> on a run that had already completed, failed or been cancelled failed with No run found for "<id>", as if the run did not exist. resolveCancelableJob only matched the id against active runs, so a run that finished a moment before the user typed /muse:stop looked like a typo.

• lib/job-control.mjs: given an id with no active match, resolveCancelableJob matches it against every run and returns it with finished: true. An id that matches no run at all still throws "No run found". An id that matches an active run behaves as before.
• muse-bridge.mjs: stop reports Run <id> is already <status>; nothing to stop., exits 0, sets alreadyTerminal: true in the JSON payload, and leaves the record as it was (no kill attempted, status not overwritten).
• This sits after the checks merged in Mark dead runs as failed; atomic, Windows-safe write-run guard #1: a run whose processes have just died is still retired and reported as "had already ended", and a prefix shared by a just-ended and a live run is still ambiguous.
• Runtime test: a finished run in text and JSON output with the record untouched, and an unknown id still erroring.
• README (/muse:stop) and CHANGELOG (Unreleased).

Independent of #2 to #6 apart from the shared top line of the CHANGELOG's Unreleased section; I'll rebase whichever lands later.

Tests: 109/109 locally on Windows.

🤖 Generated with Claude Code

[rtravellin]

Nice improvement. One edge case is worth closing, since this PR makes finished runs a normal target for stop.

scripts/lib/job-control.mjs:367: hasActiveMatch only looks at active runs. If exactly one active run matches the prefix, finished runs are never considered and nothing is reported as ambiguous.

Scenario: job-mabc12-x1 has completed and job-mabc9f-y2 is running. stop job-mabc, meant for the finished run, kills the live one and marks it cancelled, when it should say "already finished" or raise the "ambiguous" error. That's the same case the retired-run path in handleCancel already reports as ambiguous, so the two paths now disagree.

Suggested fix: run matchJobReference(jobs, reference) over all jobs first, then derive finished from the matched run's status, so a prefix shared by a finished and a live run throws the existing ambiguous error.

This will also need a rebase: #2 and #3 are merged and the CHANGELOG conflicts.

[webandseo]

Fixed in 8f38cfa: resolveCancelableJob now matches against all runs first and derives finished from the matched run, so a prefix shared by a finished and a live run raises the existing ambiguous error. The new test covers your scenario (before the fix it stopped the live run). Rebased on main.