docs: spec the silent-until-signal monitor policy

An in-session monitor loop (sentry, auto triage-intake, auto inbox-zero) fires the model every interval and narrates a full turn even when nothing changed, so a session fills with quiet-fire noise. The spec settles the fix as a policy, not a watcher: detect first, and on an empty check collapse to one labelled heartbeat line, spending a full turn only on a real item. Keeping detection in-session dissolves the MCP-auth split (triage's sources need the session's auth, which a detached watcher can't reach), so it applies uniformly across all three loops. DRAFT, decisions resolved live. Links a [#B] build task.

1 files changed, 2 insertions, 6 deletions

diff --git a/todo.org b/todo.org
index 4459dbf..03d209d 100644
--- a/todo.org
+++ b/todo.org
@@ -184,13 +184,9 @@ From the sentry live trial (2026-07-20): triage-intake self-activates in every p
 Awaiting Craig's deep read of the spec (DRAFT → READY gate). Two decisions still open in the spec (declaration format details, whether interactive adopts the same gate). On READY, spec-response decomposes the 5 phases into build tasks. Supersedes Fire 1's triage-probe approval-queue item, which was the narrower probe-only framing.
 
 ** TODO [#B] Silent-until-signal for in-session monitor loops :feature:spec:
-Craig-approved proposal from .emacs.d (2026-07-20). In-session cron/loop monitors surface a visible LLM turn on every fire even when nothing changed, filling a long session with "quiet fire" / "no new items" noise. The rulesets sentry live trial demonstrated it directly — fires 3-8 were walls of no-op lines.
+Spec: [[file:docs/specs/2026-07-20-silent-until-signal-monitors-spec.org][docs/specs/2026-07-20-silent-until-signal-monitors-spec.org]] (DRAFT, ID af592bd6-d3e6-47e2-8804-2a287b4d9303). Decisions resolved live with Craig 2026-07-20; awaiting his deep read for DRAFT → READY.
 
-Pattern: split silent shell-level detection from LLM judgment. A watcher (systemd user timer, backgrounded loop, or the Monitor tool) diffs the source against a seen-list every N minutes with zero output on an empty check; only a genuinely new item surfaces (drops a handoff into inbox/, the inbox-boundary stop-hook surfaces it at the next boundary). The watcher-owned seen-list replaces the in-anchor Dispositioned list.
-
-Apply to: auto inbox-zero (roam-inbox monitor — the originating case), auto triage-intake (same shape), and sentry (a quiet fire collapses to a one-line heartbeat — "sentry checked HH:MM, nothing" — instead of a full per-pass digest; only a fire that did or queued something writes a full digest — Craig's explicit ask).
-
-Cross-workflow shared-asset change (triage-intake.org, inbox.org, sentry.org all in rulesets), warrants a spec like the triage-source-activation one. Open questions: watcher mechanism (systemd timer vs in-session background vs Monitor tool), where the seen-list lives, passive inbox-drop vs paging. Overlaps the sentry cluster ([[file:todo.org::*Sentry vNext passes][Sentry vNext passes]], [[file:todo.org::*Triage source activation][Triage source activation]]).
+Craig-approved proposal from .emacs.d (2026-07-20), demonstrated by the sentry live trial (fires 3-8 were walls of no-op lines). Reframed live from a watcher *mechanism* to a *policy*: an in-session monitor fire detects first, and on an empty check collapses to one labelled heartbeat line (=<workflow> at HH:MM: nothing=) instead of a full turn; only a real item earns the full surface-and-judge turn. Keeping detection in-session dissolves the MCP-auth split (triage's Gmail/Slack/Linear need session auth), so it applies uniformly to sentry, auto triage-intake, and auto inbox-zero. No external watcher, no new seen-list. Five build phases in the spec (sentry heartbeat first — separable and highest-value). Overlaps the sentry cluster ([[file:todo.org::*Sentry vNext passes][Sentry vNext passes]], [[file:todo.org::*Triage source activation][Triage source activation]]).
 
 ** TODO [#D] Research: MCP for device locations shared with you :feature:
 From .emacs.d (2026-07-20, rulesets-owned research). Is there a Google Maps MCP (or similar) that reports the locations of devices sharing their location with you? If none exists, research how hard it would be to build one. (Google's location-sharing has no official public API; likely needs investigation of unofficial routes or a different provider.)