Captain quiet-mode: suspend the monitor loop + dispatch for off-hours (no overnight agent firing)

[gregberns]

Problem

A Captain & Crew deployment has no clean off-hours / quiet mode. The captain (a long-lived claude --remote-control session) keeps itself alive and monitoring via a recurring health-tick (today a /loop cron that re-invokes the captain every ~12 min). Each tick the captain checks the fleet and, when it finds ready work or a parked crew, nudges/dispatches to the crews. Overnight this means:

• the scheduled tick keeps firing (a "notification" that re-invokes the captain), and
• every tick can re-trigger crew agents (nudges, dispatch), so agents keep firing all night even when the operator is away and wants the fleet idle.

The operator's ask: a way to put the captain into quiet mode for off-hours without tearing down the crews (their sessions + the daemon stay up), then resume cleanly the next day.

Current manual workaround (what a captain does by hand today)

1. CronDelete the captain's /loop health-tick (stops the captain from being re-invoked / nudging).
2. harmonik supervise pause (daemon stops dispatching new beads; in-flight completes).
3. Leave all crew + daemon processes alive.
4. On resume: harmonik supervise resume + re-arm the /loop health-tick.

This works but is ad-hoc, easy to get wrong, and the captain has to remember all the levers.

Proposed

A first-class captain quiet-mode control, e.g.:

• harmonik captain quiet (or supervise quiet) — suspends the captain's monitor cadence AND pauses daemon dispatch in one step; crews + daemon stay alive; in-flight work completes.
• harmonik captain resume — re-enables dispatch and the monitor cadence atomically.
• Optional: a schedule (e.g. quiet 19:00–08:00 local) so it's automatic, and a status surface (harmonik captain status showing quiet vs active).

Notes / open questions

• Should quiet-mode also signal crews to stop self-driven monitor loops (so a crew with a background monitor doesn't keep dispatching to a paused daemon and spin)? Crews currently self-re-invoke via monitors; a quiet signal on the bus they honor would close that gap.
• Keeper interaction: quiet-mode should not fight the session-keeper's context-window restarts.

🤖 Generated with Claude Code

[gregberns]

Tracked in our ledger as hk-rl4b (Fleet sleep/wake initiative, P1). A research seed landed 2026-06-17: token-burn inventory + sleep/wake design + genuine-drain guard, at docs/ideas/fleet-sleep-wake-research.md. Next step: a kerf 'fleet-sleep' work to turn it into an implementation plan. (Not part of the GH bug-fix lane — that lane is the two P1 bugs #7/#8.)