Summary

There is a race condition when an assignee sends a follow-up @vigilanteai ... prompt on a GitHub issue and the vigilante:automerge label is added immediately after. Vigilante can close the issue and let the PR automerge before the new comment-driven iteration actually runs, which causes the session to finish on stale state instead of honoring the follow-up instruction.

Problem

• A GitHub comment can request a new follow-up implementation pass, but Vigilante does not fully block completion/automerge while that new iteration is still being claimed or started.
• If vigilante:automerge is added immediately after the follow-up comment, the PR maintenance path can win the race and merge/close the work before Vigilante finishes iterating on the new instruction.
• This produces the wrong user-visible behavior: the issue is closed as completed and the PR is automerged even though a new assignee-requested change was still pending.

Context

• Repository: aliengiraffe/vigilante
• The attached screenshot shows this sequence:
  • an assignee posts a new @vigilanteai ... follow-up prompt
  • vigilante:automerge is added immediately after
  • the issue is closed as completed and the PR is merged
  • only then does a new Vigilante session-start comment appear for the requested iteration
• Current repository surfaces already indicate:
  • vigilante:automerge can trigger squash automerge from either the issue or PR side
  • vigilante:iterating exists as a lifecycle label for assignee-requested follow-up implementation passes
• The bug is specifically about ordering/state coordination between:
  • GitHub comment-driven iteration requests
  • issue/PR labels such as vigilante:automerge
  • PR maintenance/completion logic that can close the issue and merge the PR
• The expected behavior is that a newly requested iteration must become authoritative before completion/automerge decisions are allowed to proceed.

Desired Outcome

• When a valid comment-driven follow-up iteration request is detected, Vigilante must treat that request as a state transition that blocks completion/issue closure/automerge until the iteration is either completed, canceled, or rejected.
• Adding vigilante:automerge immediately after an iteration-request comment must not allow the stale pre-iteration PR state to be merged.
• The issue and PR should only be closed/merged after the requested iteration has been incorporated and the system returns to a stable post-iteration review-ready state.
• Non-goal: disabling automerge entirely. The goal is to coordinate automerge correctly with pending or active iterations.

Implementation Notes

• Audit the code paths that detect assignee comment commands, claim iteration work, set vigilante:iterating, evaluate issue completion, and trigger PR automerge.
• Introduce an explicit pending-or-active iteration gate in the session/issue state machine so PR maintenance cannot mark the issue done or merge the PR while a new comment-driven iteration is waiting to run or already in progress.
• Treat the GitHub comment request itself, not just the later session-start comment, as the authoritative moment when the follow-up pass must block terminal actions.
• Ensure the gate covers both:
  • the short window after the qualifying comment is observed but before the iteration session is fully started
  • the active follow-up iteration window after vigilante:iterating is set
• Review whether terminal labels such as vigilante:done and review labels such as vigilante:ready-for-review need stricter transitions when iteration is pending.
• If a replacement or follow-up run reuses the existing PR branch, make sure automerge reevaluates only after the updated branch state and requested changes are complete.
• Update comment/label behavior so the UI does not show a misleading completed state while iteration is still pending.

Acceptance Criteria

• After Vigilante detects a valid GitHub comment requesting a follow-up iteration, the issue/PR is no longer eligible for automatic completion or automerge until that iteration resolves.
• Adding vigilante:automerge immediately after a qualifying follow-up comment does not allow the existing PR to merge before the follow-up pass runs.
• The race window between comment detection and iteration-session startup is covered; terminal actions are blocked even before the new session-start comment is posted.
• Vigilante does not close the issue as completed while a requested iteration is pending or active.
• vigilante:iterating and related lifecycle labels remain consistent with the actual iteration state shown to users.
• Once the requested iteration completes and the branch returns to a merge-ready state, automerge can proceed normally if its other conditions are satisfied.
• Automated tests cover the specific race where a comment-driven iteration request and vigilante:automerge arrive in close succession.

Testing Expectations

• Add or update workflow tests that simulate:
  • a qualifying follow-up GitHub comment
  • immediate addition of vigilante:automerge
  • a preexisting mergeable PR
• Verify that the PR does not merge and the issue does not close before the follow-up iteration is started and completed.
• Add state-transition tests for pending iteration vs active iteration vs stable post-iteration review-ready states.
• Add regression coverage for label transitions and comment ordering so vigilante:done or completion comments cannot appear ahead of a newly requested iteration.
• Manually verify the GitHub timeline behavior matches user expectations: iteration request first, follow-up work second, merge/closure last.

Operational / UX Considerations

• The issue timeline should make it obvious that a new assignee instruction paused terminal automation until the follow-up pass was handled.
• Prefer deterministic blocking behavior over best-effort timing assumptions; this is a concurrency/state-machine bug, not just a UI polish issue.
• If Vigilante cannot honor the follow-up iteration safely, it should leave the issue open and report the blocker rather than merging stale work.

Recreated from #300 by Vigilante.

Recreated from #335 by Vigilante.