Summary

Vigilante needs a stronger escape hatch for issues that are effectively stuck and should be restarted as a brand-new GitHub issue instead of resumed or redispatched in place. Add a recreate workflow that duplicates the original issue into a new one, closes the old issue as not planned, and cleans up the old PR/branch artifacts so execution can restart cleanly from a fresh issue number.

Problem

• Some issues become effectively stuck even after cleanup or redispatch, and the cleanest operator action is to abandon the old issue and start over from a newly created duplicate.
• Vigilante currently supports resume, cleanup, and redispatch, but it does not support a full “recreate this issue as a fresh one” workflow.
• Operators currently have to perform several error-prone manual steps themselves: duplicate the issue, close the old one, clean up or close related PRs, and remove stale branches.

Context

• Repository: aliengiraffe/vigilante
• Current control surfaces already include:
  • GitHub issue comments such as @vigilanteai resume and @vigilanteai cleanup
  • local CLI commands such as vigilante resume --repo <owner/name> --issue <n>, vigilante cleanup --repo <owner/name> --issue <n>, and vigilante redispatch --repo <owner/name> --issue <n>
• The current README explicitly says vigilante redispatch does not delete remote pull requests or remote branches, so recreate is a distinct and more destructive workflow.
• The requested new triggers are:
  • GitHub comment command: @vigilanteai recreate
  • local CLI command: vigilante recreate --repo <owner/name> --issue <n>
• The user intent for recreate is: create a new duplicate issue, close the previous issue as not planned, and remove the stale PR/branch state from the abandoned attempt.
• GitHub issue/PR lifecycle constraints should be handled explicitly in implementation. If GitHub does not support truly deleting a PR, Vigilante should perform the nearest correct destructive-safe equivalent and document it clearly rather than guessing.

Desired Outcome

• Operators can trigger a full issue recreation flow either from the GitHub issue thread with @vigilanteai recreate or locally with vigilante recreate --repo <owner/name> --issue <n>.
• Vigilante creates a new issue that duplicates the old issue's relevant content and clearly links the old and new issues.
• Vigilante closes the old issue with state reason not planned after the new issue is successfully created.
• Vigilante tears down the stale implementation artifacts associated with the old issue, including remote branch cleanup and PR closure/deletion behavior as supported by GitHub.
• Non-goal: silently mutating or deleting issue history without leaving an audit trail.

Implementation Notes

• Add a new top-level CLI command vigilante recreate --repo <owner/name> --issue <n> with usage/help/completion support matching the existing control commands.
• Add GitHub comment detection for @vigilanteai recreate alongside the existing control-comment parsing.
• Define the recreation flow order explicitly. A reasonable sequence is:
  • validate the target repo/issue is watched and eligible
  • inspect current local session, PR, and branch state for the issue
  • create the replacement issue using the original issue title/body and any needed metadata/linkage
  • post cross-links so humans can see which new issue replaced which old one
  • close the original issue with GitHub state reason not planned
  • close or otherwise retire any old PR tied to the original issue
  • delete the stale remote branch when safe
  • clean local session/worktree/branch artifacts for the old issue
• Be explicit about PR handling. If GitHub does not allow true PR deletion, implement closure plus branch cleanup and document that as the canonical behavior.
• Ensure the new issue is eligible for future Vigilante dispatch as a fresh issue rather than inheriting blocked local state from the old one.
• Preserve the execution audit trail by leaving clear comments on the old issue and, when useful, the replacement issue.
• Consider whether labels, assignee, and native GitHub issue type should be copied to the recreated issue so the replacement behaves like the original work item.

Acceptance Criteria

• Vigilante exposes a new local command vigilante recreate --repo <owner/name> --issue <n>.
• Vigilante recognizes @vigilanteai recreate as a GitHub issue comment control command.
• Running the recreate flow creates a new GitHub issue that duplicates the original issue's relevant title/body content and links the old and new issues.
• After the replacement issue is created successfully, Vigilante closes the original issue with state reason not planned.
• The recreate flow retires stale PR state for the original issue, using true deletion where supported or explicit PR closure where GitHub does not support deletion.
• The recreate flow deletes the stale remote branch for the abandoned issue attempt when it is safe to do so.
• The recreate flow cleans up local session/worktree/branch artifacts for the abandoned issue so the old state cannot interfere with the new issue.
• The new issue is left in a state that can be picked up by Vigilante as a fresh execution candidate.
• Help text, docs, and shell completions are updated to include recreate and its GitHub comment trigger.
• Automated tests cover both the CLI-triggered and GitHub-comment-triggered recreate paths, including issue duplication, old-issue closure, and artifact cleanup behavior.

Testing Expectations

• Add or update CLI parsing/help/completion tests for vigilante recreate --repo <owner/name> --issue <n>.
• Add or update GitHub command-detection tests for @vigilanteai recreate.
• Add workflow tests covering the successful recreation path, including new issue creation, old issue closure with not planned, PR retirement, remote branch deletion, and local cleanup.
• Add failure-path tests for partial failures, such as replacement issue creation failure, PR closure failure, branch deletion failure, or GitHub API limitations.
• Verify that the recreated issue can be dispatched later as a fresh issue without inheriting stale session state from the original issue.

Operational / UX Considerations

• This is a destructive operator action compared with resume or redispatch, so the comments/logging should make the consequences explicit.
• Keep an audit trail in GitHub by cross-linking the original and recreated issues and explaining what happened.
• If any part of PR retirement or branch deletion cannot be completed, Vigilante should report the partial failure clearly instead of pretending the recreation fully succeeded.
• The recreate behavior should be narrowly scoped to the target issue and its associated artifacts; it must not affect unrelated PRs, branches, or sessions.