Auto-respond to PR status changes (#201)

[dhilgaertner]

Summary

• Detects PR transitions into changesRequested / checksFailing by comparing each polling cycle's PRStatus against the previous one — piggybacks on the existing 60s GitHub GraphQL query, no new API calls or scopes.
• When the user opts in (Settings → Notifications → Auto-respond), Crow types a short prompt into the session's managed Claude Code terminal asking Claude to fetch the review/logs (gh/glab) and address them. Crow doesn't fetch review bodies or CI logs itself — that keeps the implementation simple and avoids fragile log parsing.
• Fires a macOS notification on every transition (gated by the existing notification settings) so the user is informed even with auto-respond off.
• Dedupe key is (sessionID, kind, headSha) so re-runs on the same commit don't re-fire; auto-rearms when the rule clears (approved → changesRequested again, or new commit also fails).
• Both opt-in toggles default off — typing into a terminal unprompted is intrusive.
• First poll never fires (matches the existing previousReviewRequestIDs first-fetch gate) so existing PR state isn't replayed at startup.

Implementation

• New PRStatusTransition value type + pure PRStatus.transitions(from:to:...) helper in CrowCore — keeps the comparison logic unit-testable.
• Added headSha to PRStatus (populated from a new headRefOid field on ViewerPR / GraphQL).
• Two new NotificationEvent cases (changesRequested, checksFailing) — they automatically inherit NotificationSettings's per-event sound/system-notification toggles.
• New AutoRespondSettings struct on AppConfig (separate from NotificationSettings because auto-respond is an action, not a notification).
• New AutoRespondCoordinator in the main target — finds the session's managed terminal via Terminal.isManaged and sends via TerminalManager.shared.send(id:text:), the same path crow send uses.
• IssueTracker.applyPRStatuses rewritten to track previousPRStatus[sessionID] and emit transitions through a new onPRStatusTransitions closure (mirrors onNewReviewRequests).
• NotificationManager.notifyPRTransition reuses the same gate logic as notifyReviewRequest.

Closes #201

Test plan

• make build succeeds
• make test — all 127 CrowCore tests + 31 root CrowTests + every other package suite pass
• New PRStatus transitions test suite (14 tests) covers: first-observation never fires, single-fire on transition, no-op on repeat poll, no-fire when rule clears, simultaneous transitions, dedupe key shape (with vs without SHA)
• Existing ViewerPR test helpers updated for new headRefOid field
• Manual smoke (recommend running once after merge): enable Respond to failed CI checks, push a CI-breaking commit on a session-linked PR, verify notification fires within ~60s and prompt appears in the managed terminal; re-run CI on same SHA → no second prompt; push new failing SHA → second prompt fires; disable toggle → notification only

🤖 Generated with Claude Code

[dgershman]

Code & Security Review

Critical Issues

None found.

Security Review

Strengths:

• Auto-respond toggles default off — good security posture for a feature that types into a terminal unsolicited.
• Dedupe key design (sessionID|kind / sessionID|kind|headSha) prevents replay attacks from re-polling the same state.
• The coordinator checks for both a managed terminal AND an initialized surface before dispatching — prevents sending to stale/orphaned terminals.
• No new API scopes or tokens — piggybacks on the existing gh/glab GraphQL payload and delegates review/CI log fetching to Claude, keeping the Crow app's privilege boundary unchanged.
• The headRefOid field is sourced from GitHub's GraphQL schema, not user input, so no injection risk from SHA values.
• Prompt text is constructed with string interpolation of PR numbers/URLs (already validated upstream via ProviderManager.parseTicketURLComponents), not raw user input.

Concerns:

• None significant. The prompts injected into the terminal are deterministic and constructed from trusted state (session metadata, PR metadata from GitHub API).

Code Quality

Well done:

• Clean separation: PRStatusTransition is a pure value type in CrowCore, PRStatus.transitions(from:to:...) is a pure function — both are unit-testable without any UI/AppState dependency.
• 14-test suite (PRStatusTransitionTests) thoroughly covers the transition matrix: first-observation gate, directional transitions, no-ops, simultaneous transitions, and dedupe key semantics.
• AutoRespondSettings is separate from NotificationSettings — correct modeling since auto-respond is an action, not a notification.
• Forward-compatible Codable with decodeIfPresent + defaults on AppConfig, AutoRespondSettings, and PRStatus.
• Re-arm logic in applyPRStatuses (lines 1326–1334 of IssueTracker.swift) correctly clears emitted keys when the triggering condition clears, so future re-entries fire as expected.
• The settingsProvider closure pattern on AutoRespondCoordinator means Settings UI toggles take effect on the next transition without explicit wiring — simple and correct.
• NotificationSettingsView cleanly adds the auto-respond section with appropriate explanatory caption text.
• Prompt construction in AutoRespondPrompts.build handles both GitHub and GitLab providers with appropriate CLI hints.

Minor observations (non-blocking):

• AutoRespondPrompts.build uses transition.prNumber.map(String.init) for the inline comments hint but falls back to "<number>" as a placeholder when prNumber is nil (line 82). In practice prNumber is always populated from ViewerPR.number, so this is a safe defensive path rather than a real concern.
• The failedCheckNames.prefix(5) truncation in the prompt (line 95) is a nice touch to avoid overwhelming Claude with a massive list.

Summary Table

Priority	Issue
Green	Consider adding an integration test that exercises the full IssueTracker.applyPRStatuses → onPRStatusTransitions → AutoRespondCoordinator.handle pipeline end-to-end (currently each piece is tested in isolation, which is fine)
Green	The AutoRespondCoordinator could log when a transition is skipped due to the toggle being off (currently it silently continues) — helpful for debugging "why didn't auto-respond fire?"

Recommendation: Approve — this is a well-structured, defensively coded feature with good test coverage, appropriate opt-in defaults, and no security concerns. The pure/stateful split keeps the logic testable and the implementation stays within Crow's existing privilege boundary by delegating review/CI log fetching to Claude.