Fix false 'no pull request was created' loop when a PR already exists for the issue branch

[nicobistolfi]

Summary

Vigilante can enter a self-sustaining retry loop after an implementation has already succeeded if PR detection races with the post-run completion logic. In the observed case, Vigilante opened a PR, verified that the PR was open and green, then repeatedly posted Incomplete comments claiming no PR existed and kept relaunching the same issue session.

Problem

• A successful implementation can be misclassified as "commits without PR" even when the PR already exists and all checks have passed.
• That false negative causes Vigilante to keep redispatching the same issue/worktree instead of transitioning into normal PR maintenance.
• Repeated no-op reruns create comment spam, keep the issue in an active state, and can eventually introduce a real blocker on top of an already-complete implementation.

Context

• Observed on April 16, 2026 while Vigilante was handling teros-dev/platform#343.
• The implementation opened PR teros-dev/platform#344 at 2026-04-16T17:27:56Z.
• PR #344 is open, mergeable (CLEAN), not draft, and its 5 checks passed by 2026-04-16T17:32:18Z.
• After that, the issue received a repeating sequence of comments:
• a verification/no-op comment saying PR #344 was already open and green
• then an Incomplete comment saying "The coding agent exited successfully but no pull request was created"
• then a fresh session start against the same branch/worktree
• Later comments explicitly identified this as a commits_without_pr false-positive / PR-creation race.
• The issue eventually also received a real Blocked comment with cause validation_failed, which appears to have been introduced by one of the unnecessary follow-up retries rather than by the original implementation.

Desired Outcome

• Once a session has produced a branch with an existing PR, Vigilante must treat that issue as completed implementation work and move into PR maintenance instead of redispatching implementation.
• If PR discovery happens slightly after the agent exits, the post-run logic should reconcile that state before posting any Incomplete/redispatch comment.
• Verification/no-op runs must not be followed by a contradictory Incomplete comment for the same branch/head state.
• Non-goal: redesign the broader session/maintenance architecture.
• Non-goal: change how providers post milestone comments unless required to eliminate this race.

Implementation Notes

• Investigate the transition from internal/runner.RunIssueSession success into the daemon/session bookkeeping that decides whether a session produced "commits without PR".
• Reconcile the branch state with GitHub before emitting any "no pull request was created" outcome. If a PR already exists for the branch, persist the PR metadata and route the session into the existing success/PR-maintenance path.
• Make the completion decision idempotent for already-open PRs so a later scan cannot flip a verified-successful issue back into redispatch.
• Review whether the component that emits the Incomplete comment is running from older logic than the current FindPullRequestForBranch / PR-maintenance recovery path.
• Preserve current behavior for genuine "branch pushed, no PR exists" cases.

Acceptance Criteria

• If a coding session exits successfully and a PR already exists for the issue branch, Vigilante does not post an Incomplete comment claiming no PR was created.
• In that case, Vigilante persists the PR number/URL/state and treats the session as successful PR maintenance state.
• A later scan or retry does not relaunch implementation work for the same issue while the PR is still open and the session is already in success/maintenance state.
• A verification/no-op run for an already-open PR cannot be immediately followed by a contradictory Incomplete comment for the same branch/head commit.
• Genuine "commits without PR" cases still surface the Incomplete path when no PR exists for the branch.

Testing Expectations

• Add a regression test covering: successful implementation session, PR creation visible by branch lookup, then daemon/scan pass; expected result is success with PR maintenance, not redispatch.
• Add a regression test for the race window where the PR is not visible at the first check but is visible on reconciliation before the Incomplete outcome is emitted.
• Add a regression test proving that an already-successful session with open PR metadata does not blockingly re-enter implementation on the next scan.
• Keep coverage for the true negative case where commits exist and no PR exists.

Operational / UX Considerations

• Avoid posting contradictory issue comments for the same observed state; these comments become the operator-facing source of truth.
• If Vigilante does recover an existing PR after a stale or raced state, prefer a single recovery comment over alternating Verified and Incomplete messages.
• Consider removing vigilante:blocked / vigilante:needs-git-fix automatically when the only reason for continued activity was this false-positive loop and the PR is already green.

[nicobistolfi]

🧢 Vigilante Session Start

Progress: [##--------] 20%
ETA: ~25 minutes

• Vigilante launched this implementation session in /home/zantez/git/vigilante/.worktrees/vigilante/issue-456.
• Branch: vigilante/issue-456-fix-false-no-pull-request-was-created-loop-when-a-pr-already-exists-for-the-issue-branch.
• Current stage: handing the issue off to the configured coding agent (Codex) for investigation and implementation.
• Common issue-comment commands: @vigilanteai resume retries a blocked session after the underlying problem is fixed, and @vigilanteai cleanup removes the local session state for this issue.

"Make it simple, but significant."

[nicobistolfi]

🕹️ Coding Agent Launched: Codex

Working branch: vigilante/issue-456-fix-false-no-pull-request-was-created-loop-when-a-pr-already-exists-for-the-issue-branch

Status: investigating the existing PR detection flow and preparing a minimal fix for the false "no pull request was created" loop.

Issue-comment commands:

@vigilanteai resume
@vigilanteai cleanup

[nicobistolfi]

🧭 Planning

Progress: ██░░░░░░░░ 20%
ETA: ~20 minutes

• Mapped the false-positive path to post-run session classification in internal/runner/session.go.
• Next I’m reconciling the branch against GitHub before the incomplete outcome is emitted.
• Then I’ll lock in the behavior with a focused regression test for the existing-PR race.

Tight loop, small fix.

[nicobistolfi]

🛠️ Implementing

Progress: ███████░░░ 70%
ETA: ~10 minutes

• Added post-run PR reconciliation so a successful session checks the branch on GitHub before falling into the Incomplete path.
• Persisted recovered PR metadata onto the session so the daemon stays in success / PR-maintenance state.
• Validation is green so far: go test ./internal/runner/..., go vet ./internal/runner/..., and targeted internal/app scan tests.

Stop the loop before it writes fiction.

[nicobistolfi]

✅ Pull Request Opened

Progress: ██████████ 100%
ETA: ~0 minutes

• Opened PR Fix false no-PR loop when the issue branch already has a PR #457: Fix false no-PR loop when the issue branch already has a PR #457
• The fix now reconciles existing branch PRs before emitting the Incomplete / commits_without_pr path.
• Validation included go test ./internal/runner/..., go vet ./internal/runner/..., and targeted internal/app scan tests.

One clean state, one clear story.

[nicobistolfi]

⚠️ Incomplete

Progress: [#########-] 90%
ETA: ~5 minutes

• The coding agent exited successfully but no pull request was created for vigilante/issue-456-fix-false-no-pull-request-was-created-loop-when-a-pr-already-exists-for-the-issue-branch.
• New commits were pushed to the branch but no PR was opened.
• Next step: Vigilante will attempt to rerun the session in the existing worktree to continue from the current state.

"Progress saved — not done yet."

[nicobistolfi]

🧢 Vigilante Session Start

Progress: [##--------] 20%
ETA: ~25 minutes

• Vigilante launched this implementation session in /home/zantez/git/vigilante/.worktrees/vigilante/issue-456 from existing remote branch origin/vigilante/issue-456-fix-false-no-pull-request-was-created-loop-when-a-pr-already-exists-for-the-issue-branch.
• Diff summary against main: internal/runner/session.go | 51 ++++++++++++++++++++++++++++++++++++++++
  internal/runner/session_test.go | 52 +++++++++++++++++++++++++++++++++++++++++
  2 files changed, 103 insertions(+)
• Current stage: handing the issue off to the configured coding agent (Codex) to continue the existing implementation.
• Common issue-comment commands: @vigilanteai resume retries a blocked session after the underlying problem is fixed, and @vigilanteai cleanup removes the local session state for this issue.

"Make it simple, but significant."

[nicobistolfi]

🕹️ Coding Agent Launched: Codex

[██░░░░░░░░] 20%
ETA: ~25 minutes

• Continuing from the existing issue branch and reviewing the current session.go / test changes against the issue's requested behavior.
• I’m verifying whether Vigilante should reconcile an already-open PR before declaring the session incomplete.
• Next: confirm the exact failure mode, tighten the implementation only where needed, and run targeted Go validation.

Issue-comment commands:

• @vigilanteai resume resumes a blocked session after the underlying problem is fixed.
• @vigilanteai cleanup removes local session state for this issue.

"Make it simple, but significant."

[nicobistolfi]

🧭 Implementation Plan

[███░░░░░░░] 30%
ETA: ~20 minutes

• Confirm the remaining false-positive path in the daemon scan: incomplete sessions marked commits_without_pr are still rerun without reconciling branch PR state.
• Add a minimal recovery step before incomplete-session rerun so an existing PR flips the session back into success/PR-maintenance instead of redispatching implementation.
• Extend Go tests to cover that scan-time recovery path, then run focused formatting, tests, and vetting on the touched packages.

"Tight scope, sharp fix."