Summary

Vigilante can get stuck replaying historical @vigilanteai ... iteration comments on open issues, causing repeated Iteration Ignored comments and unnecessary redispatch attempts. The comment-claim cursor for iteration requests needs monotonic semantics so older comments are treated as already consumed once a newer comment has been claimed.

Problem

• FindIterationComment currently skips only the exact last claimed comment ID, then returns the next older matching iteration comment.
• On the next scan, Vigilante can reprocess a historical iteration comment instead of stopping at the claimed cursor.
• When the issue has no current assignees, each replayed historical comment fails the assignee check and produces a fresh Iteration Ignored comment.
• This creates sustained GitHub issue noise and can trigger unnecessary follow-up session starts after the relevant work already completed.

Context

• Repository: aliengiraffe/vigilante
• Production evidence was observed on issues Prevent automerge/completion from racing ahead of comment-driven iterations #300 and Introduce project-management backend abstractions beyond GitHub #330 on March 28, 2026.
• Issue Prevent automerge/completion from racing ahead of comment-driven iterations #300 accumulated 31 Iteration Ignored comments between 2026-03-28T18:45:42Z and 2026-03-28T19:15:42Z.
• Issue Introduce project-management backend abstractions beyond GitHub #330 accumulated 67 Iteration Ignored comments between 2026-03-28T18:53:46Z and 2026-03-28T19:59:46Z.
• In both cases, the issues had no assignees while Vigilante still tracked successful sessions with stored last_iteration_comment_id metadata.
• The current behavior in internal/github/github.go treats the cursor as “skip this exact comment ID” instead of “everything at or before this point is already consumed”.
• The processing path in internal/app/app.go then turns each replayed historical comment into a new Iteration Ignored comment.

Desired Outcome

• Iteration comment claiming is monotonic: once a comment has been claimed, older iteration comments are no longer eligible for replay on later scans.
• A long-lived successful session can still react to genuinely new follow-up comments, but it must not walk backward through historical ones.
• Issues like Prevent automerge/completion from racing ahead of comment-driven iterations #300 and Introduce project-management backend abstractions beyond GitHub #330 stop accumulating repeated Iteration Ignored comments from old history.
• Non-goal: changing the general ability for successful sessions to accept legitimate new iteration requests.

Implementation Notes

• Update iteration comment selection so comments at or before the stored claim cursor are considered consumed.
• Use a monotonic comparison based on comment timestamp and ID, rather than exact-ID equality only.
• A reasonable implementation is to consider only comments newer than LastIterationCommentAt, with ID as a tie-breaker if needed.
• Preserve the ability to detect genuinely new iteration comments that arrive after the stored cursor.
• Audit any similar command-claim helpers for resume, cleanup, or recreate to confirm they do not have the same replay behavior.
• Keep the fix narrow: the primary problem is historical iteration comment replay, not the broader session lifecycle.

Acceptance Criteria

• After Vigilante claims or rejects an iteration comment, older iteration comments are not reconsidered on subsequent scans.
• A session with multiple historical @vigilanteai ... iteration comments does not emit repeated Iteration Ignored comments one per scan.
• A genuinely new iteration comment posted after the stored claim cursor is still detected and handled.
• Issues with no assignees emit at most one rejection per newly discovered invalid iteration comment, not one rejection per historical comment in backlog order.
• The observed loop pattern from issues Prevent automerge/completion from racing ahead of comment-driven iterations #300 and Introduce project-management backend abstractions beyond GitHub #330 is prevented.

Testing Expectations

• Add regression tests for a session with multiple historical iteration comments where only the newest unclaimed comment should be considered.
• Add coverage for repeated scans after an ignored iteration request to verify that older comments are not replayed.
• Add coverage for the positive case where a new iteration comment arrives after the stored cursor and is correctly detected.
• Verify the assignee-mismatch path does not produce repeated Iteration Ignored comments for older history.

Operational / UX Considerations

• The fix should reduce GitHub issue noise and avoid confusing operators with repeated rejection comments for stale history.
• Preserve compatibility with existing persisted session state that already contains last_iteration_comment_id and last_iteration_comment_at.
• If the implementation changes cursor semantics, make the behavior explicit in logs so future comment-processing bugs are easier to diagnose.