Summary

Reduce noisy daemon logs by shifting routine polling and command execution logs from low-level raw command output toward higher-signal, event-oriented messages. Successful gh api ... issues/.../comments polling currently floods the daemon log with large, repetitive payloads that make it harder to understand actual state transitions, operator actions, and failures.

Problem

• Vigilante currently logs command execution at the runner layer for every shell command.
• This includes successful high-frequency polling calls such as gh api repos/<repo>/issues/<n>/comments.
• Successful polling logs include raw GitHub API response bodies, which are large and repetitive and do not help explain what Vigilante decided.
• The resulting daemon log is noisy and makes it harder to identify meaningful events such as issue dispatch, blocked sessions, resume detection, cleanup actions, PR maintenance, and failures.

Context

• internal/environment/environment.go implements LoggingRunner, which logs command start, command ok, and command failed for all commands.
• internal/app/app.go also emits higher-level daemon events such as scan start, issue selection, blocked/resume events, cleanup, and PR maintenance.
• Comment polling occurs during cleanup and resume processing via ghcli.ListIssueComments(...).
• Today these two logging styles stack on top of each other, but the low-level command logs often dominate the file and hide the more useful high-level messages.

Desired Outcome

• Routine daemon logs emphasize meaningful workflow events instead of raw command traffic.
• Successful polling and other high-volume low-value commands no longer dump large raw outputs into the normal daemon log.
• Failures still retain enough diagnostic detail to debug command-level problems.
• Developers still have a path to detailed command logs when needed, but normal operation is easier to read.

Non-goals:

• Do not remove all command-level logging unconditionally if it is still useful for debugging.
• Do not weaken failure diagnostics to the point where debugging provider, git, or GitHub command failures becomes difficult.
• Do not redesign the entire logging system in this issue unless necessary.

Implementation Notes

• Keep the distinction between:
  • high-level workflow/event logs for normal operation
  • detailed command logs for debugging/failure analysis
• Reasonable approaches may include one or more of:
  • suppressing command ok output bodies for successful high-volume commands such as gh api ... comments
  • logging summaries instead of raw payloads, for example whether a resume or cleanup command was detected
  • only logging full command output on failures
  • adding a debug/verbose mode for raw command tracing
  • filtering or classifying commands by noise level before logging
• Preserve enough context in failures to diagnose command name, target repo/issue, and a summarized output/error.

Acceptance Criteria

• Normal daemon logs no longer include large raw response payloads for successful issue-comment polling.
• Resume/cleanup polling is represented by concise, high-signal messages or existing higher-level events instead of repetitive raw API payloads.
• Important workflow events remain visible in normal logs, including dispatch, blocked/resume actions, cleanup, PR maintenance, and scan summaries.
• Command failures still include enough information for debugging.
• If detailed raw command tracing is retained, it is gated behind an explicit debug/verbose mechanism or similarly intentional path.

Testing Expectations

• Add or update tests for the logging behavior in internal/environment and any higher-level log summarization introduced.
• Cover successful command logging so noisy payloads are suppressed or summarized as intended.
• Cover failure logging so useful diagnostics are preserved.
• If a debug/verbose mode is added, test both normal and verbose behavior.

Operational / UX Considerations

• Optimize logs for fast operator comprehension during long-running daemon use.
• Prefer structured, searchable summaries over truncated raw JSON blobs.
• Avoid logging data that is large, repetitive, or likely to obscure the actual reason Vigilante did something.