[sonichi]

Summary

Bumps the menu-bar app's checkWatcher() Timer cadence from 30s → 5 min (Timer.scheduledTimer(withTimeInterval: 300.0, ...) in Sutando/main.swift:241). Per Chi 2026-05-14 23:15Z (y to the proposal at https://discord.com/channels/1485653766404444352/1499520683267592432).

Why

With Claude Code's Monitor tool now driving watch-tasks-stream.sh as the canonical persistent watcher (PR #693 retired the legacy one-shot watch-tasks.sh), the menu-bar Timer is purely a safety net for:

• Monitor crashes
• Session-restart races
• tmux pane death

30s polling was overkill. 5 min keeps recovery in human-interactive territory (worst-case lag = ~5 min before auto-restart) while cutting 12× the menu-bar wake-ups → less battery, less log noise.

What this PR doesn't change

• checkWatcher() body — idle-check, watcherKeystrokesQueued() guard, watcher keystroke send all unchanged
• pgrep -f watch-tasks substring match — still matches both the legacy script name (gone) and the current watch-tasks-stream.sh
• Health-check Timer (30 min) — separate cadence, unrelated

Test plan

• swiftc -O compile clean (verified locally)
• Reviewer to confirm worst-case 5 min stale window is acceptable for the watcher safety-net use case
• Manual smoke test: kill watch-tasks-stream.sh → wait 5 min → confirm menu-bar nudges Claude Code with watcher keystroke

Tradeoff

A voice task landing the moment Monitor dies waits up to 5 min before the safety net kicks in. Mitigation: Monitor is persistent + has its own keepalive against tmux session lifetime, so this scenario is rare.

🤖 Generated with Claude Code

[sonichi]

LGTM with 1 dead-code nit.

Strengths:

• Surgical: 1-line behavior change, body of checkWatcher() untouched.
• Comment block thoroughly preserves Chi's 2026-04-18 design context + names the new tradeoff explicitly.
• pgrep -f watch-tasks substring still matches the current watch-tasks-stream.sh (verified via live pgrep -fl watch-tasks → matches bash src/watch-tasks-stream.sh).

Nit — dead code (not blocking): inner throttle at main.swift:458 is Date().timeIntervalSince(lastWatcherAlert) < 120 — that's 120s, but the outer Timer now fires every 300s. Two consecutive ticks are always ≥300s apart, so the throttle never gates anything anymore. PR body says "60s" but the actual throttle is 120s; both are subsumed by the new 300s cadence. Could either drop the throttle entirely or document why it's still useful (e.g. for the case where checkWatcher() is invoked from another path).

Tradeoff acknowledged: worst-case 5min stale window before safety-net kicks in. Reasonable since Monitor is the primary watcher with its own keepalive — this is a backstop. PR body already calls this out.

Build verified locally on the diff. No regressions visible. Cleared to merge from my read.