Summary

Vigilante's daemon is burning excessive GitHub REST quota by repeatedly polling deleted issues and by fetching the same PR and issue state multiple times per scan for active successful sessions. The immediate fix is to stop treating dead issues as live, collapse redundant per-scan lookups, and reduce unnecessary polling churn without adding an HTTP caching mechanism.

Problem

• The daemon keeps polling blocked sessions whose backing GitHub issues now return HTTP 410 (deleted). These sessions remain in the active monitoring set and are retried every scan indefinitely.
• For active successful sessions with open PRs, each scan performs multiple redundant GitHub reads for the same PR and issue. The current flow repeatedly calls gh pr list, gh pr view for full details, gh pr view again for baseRefName, and gh api repos/.../issues/... even when the session state has not materially changed.
• The daemon has also shown tight-loop polling behavior for active issues and PRs, contributing to unnecessary REST API consumption.
• This waste is large enough to exhaust GitHub's REST core limit. Recent daemon behavior hit the 5000 requests/hour ceiling and had to pause.

Context

• Repository: aliengiraffe/vigilante.
• Recent access-log analysis showed the majority of logged commands were gh calls, with a large failure bucket dominated by repeated lookups for deleted issues.
• The same analysis showed repeated PR maintenance calls for active sessions, including duplicated PR-detail and issue-detail fetches in the same maintenance cycle.
• The current daemon scan loop runs on a fixed cadence and re-evaluates sessions every scan. Some state that only changes on meaningful transitions is still being re-fetched from GitHub multiple times in the same cycle.
• Do not implement an HTTP caching mechanism for this issue. Specifically, do not add ETags, If-None-Match, or a generalized response cache as the solution.

Desired Outcome

• Deleted or otherwise permanently unavailable issues stop being polled as active sessions after Vigilante confirms they are no longer actionable.
• A single daemon scan does not fetch the same PR or issue details repeatedly for the same session when the data can be reused within that scan.
• Active session maintenance still works, but it uses materially fewer GitHub REST calls than the current behavior.
• Polling cadence or state transitions should avoid tight-loop rechecks for unchanged active work, but the implementation should stay within Vigilante's existing polling model unless a narrower event-driven trigger already exists locally.
• Out of scope: implementing a general-purpose caching layer, conditional GitHub requests, or a webhook-based architecture migration in this issue.

Implementation Notes

• Treat deleted issue responses such as HTTP 410 as a terminal state for session monitoring. Finalize, close, or otherwise remove those sessions from the active polling set in a way that preserves enough local state for operator visibility and auditability.
• Review the daemon paths that currently re-fetch issue and PR state on every scan, especially the closed-issue cleanup path, PR maintenance path, resume/blocked-session evaluation path, and label-sync path.
• Collapse redundant same-scan fetches so one GitHub lookup can feed the rest of the decision-making for that session when possible.
• If baseRefName is required, fetch it as part of a single PR-details retrieval path instead of issuing separate gh pr view calls for full details and base-ref details.
• If assignee resolution or similar scan-global state is being re-fetched independently for each watch target, reduce that duplication within the existing control flow.
• Keep the implementation explicit and local to the daemon/session-management flow. Do not introduce a generalized cache abstraction as a workaround.

Acceptance Criteria

• Sessions whose GitHub issues are confirmed deleted or permanently unavailable are transitioned out of the active polling set and no longer trigger repeated gh api repos/.../issues/... calls on subsequent scans.
• A daemon scan for an active successful session with an open PR does not issue duplicate PR-detail lookups for the same PR in the same cycle when one lookup is sufficient.
• PR base-branch information is not fetched through a second dedicated GitHub call when it can be obtained through the primary PR-details lookup path.
• Same-scan issue-detail lookups for a session are deduplicated where the state is already available locally from an earlier lookup in that scan.
• The daemon no longer exhibits the recently observed tight-loop polling pattern for unchanged active sessions at the current default scan configuration.
• The reduced GitHub traffic preserves existing behavior for PR maintenance, blocked-session recovery, issue cleanup/finalization, and label synchronization.

Testing Expectations

• Add regression tests covering deleted-issue sessions so they stop being retried after a confirmed terminal GitHub response.
• Add tests covering PR maintenance to verify one scan reuses PR details instead of performing multiple equivalent GitHub calls for the same PR.
• Add tests covering any base-branch lookup changes so maintenance still uses the correct base branch.
• Add tests for session finalization and status visibility so dead sessions are no longer treated as active while historical/debug state remains intact where appropriate.
• Add or update tests around label sync, blocked-session recovery, and success-session maintenance to ensure the reduced call pattern does not regress behavior.

Operational / UX Considerations

• The daemon should remain understandable to operators: when Vigilante stops monitoring a deleted issue, the persisted session state should make that outcome clear instead of silently disappearing.
• Access-log output should remain useful for diagnosing GitHub usage after this fix; if the current logging misses some polling paths, tighten observability enough to validate the reduction in API traffic.
• Keep compatibility with the existing polling daemon model and session persistence format unless a targeted schema change is required for terminal deleted-issue handling.