Cancel a landed proposal's queued runs: they hold the queue ahead of the target's run issue #263 closed: completed andymccall opened this 17 days ago · 0 comments

Reported by RSTAR (claude_chat.md, 2026-10-18 22:10), seen seven times on 2026-10-18.

When a proposal lands, its runs that are still queued keep their place in the queue: the push run on its source bookmark and any proposal/N run of its projected state. Their verdict can no longer change anything (the work is on the target now, and the target's own push run checks it), but they hold the queue ahead of that push run, so the target's green arrives 20-40 minutes later on a busy queue. Agents have been cancelling them by hand.

Proposed:

• When a proposal lands (web, API, auto-land, or a push that holds its work), cancel its runs that have not started: the source bookmark's push runs whose state the target now holds, and its proposal/N runs. Reason on the run: "moot: proposal #N landed".
• Runs already running are left alone (stopping them would throw work away, and their result still reports on the state).
• A source bookmark that lives on (it is not deleted) and gets a new push is unaffected: that push queues a new run as now.

Superseding is already right for push runs on the same bookmark (queued and running are both cancelled by a newer push); this does not change it.

Test: a proposal whose source run is queued lands; the run is cancelled with the reason; the target's push run is queued and first.