aboutsummaryrefslogtreecommitdiff
path: root/inbox
diff options
context:
space:
mode:
authorCraig Jennings <c@cjennings.net>2026-07-20 11:24:46 -0500
committerCraig Jennings <c@cjennings.net>2026-07-20 11:24:46 -0500
commit492514dce5feaa0b0a5a6ce61c121f91b0f28821 (patch)
treeccdeb9b0cbfcd47fac47af249a0eb870b81a8f43 /inbox
parent39642c0cc26ccc9075bb8da0565e627abe412a0e (diff)
downloadrulesets-492514dce5feaa0b0a5a6ce61c121f91b0f28821.tar.gz
rulesets-492514dce5feaa0b0a5a6ce61c121f91b0f28821.zip
docs(todo): file the silent-until-signal proposal and a location-MCP research task
Two .emacs.d handoffs. The silent-until-signal monitor pattern (Craig-approved) files as a [#B] spec candidate — it's a cross-workflow shared-asset change across triage-intake, inbox, and sentry, and the sentry live trial just demonstrated the noise problem it solves. The device-location MCP question files as a [#D] research task.
Diffstat (limited to 'inbox')
-rw-r--r--inbox/PROCESSED-2026-07-20-1059-from-.emacs.d-proposal-craig-approved-2026-07-20.org19
-rw-r--r--inbox/PROCESSED-2026-07-20-1059-from-.emacs.d-research-is-there-a-google-maps-mcp-or.org5
2 files changed, 24 insertions, 0 deletions
diff --git a/inbox/PROCESSED-2026-07-20-1059-from-.emacs.d-proposal-craig-approved-2026-07-20.org b/inbox/PROCESSED-2026-07-20-1059-from-.emacs.d-proposal-craig-approved-2026-07-20.org
new file mode 100644
index 0000000..4934cdf
--- /dev/null
+++ b/inbox/PROCESSED-2026-07-20-1059-from-.emacs.d-proposal-craig-approved-2026-07-20.org
@@ -0,0 +1,19 @@
+#+TITLE: PROPOSAL (Craig-approved 2026-07-20): silent-until-signal pa
+#+SOURCE: from .emacs.d
+#+DATE: 2026-07-20 10:59:59 -0500
+
+PROPOSAL (Craig-approved 2026-07-20): silent-until-signal pattern for in-session monitor loops — apply to auto triage-intake, auto inbox-zero, and sentry.
+
+Problem: in-session cron/loop monitors surface a visible LLM turn on every fire even when nothing changed, so a long session fills with 'no new items' / 'quiet fire' noise. A background subagent does NOT fix it — it notifies on every completion, including the empty ticks.
+
+Proposed pattern — split silent detection from LLM judgment:
+- A shell-level watcher (systemd user timer, or a backgrounded loop) does detection silently: diff the source (roam inbox, or triage sources) against a seen-list every N minutes, producing ZERO output on an empty check.
+- Only a genuinely new item surfaces — the watcher drops a handoff into the project inbox/, and the existing inbox-boundary stop-hook surfaces it at the next natural boundary. The LLM then does the implement-vs-file/route judgment, only when there's something.
+- The watcher-owned seen-list replaces the in-anchor 'Dispositioned' list.
+
+Apply to:
+- auto inbox-zero (the roam-inbox monitor) — the case this came from (.emacs.d session, 2026-07-20).
+- auto triage-intake — same shape (silent scan, surface only real items).
+- sentry — quiet fires should collapse to JUST the check-time, a one-line heartbeat ('sentry checked HH:MM, nothing'), not a full per-pass digest. An all-quiet night becomes a short timestamp list instead of a wall of SKIP/no-op lines; only a fire that actually did or queued something writes a full digest. (Craig's explicit ask.)
+
+Why rulesets: triage-intake.org, inbox.org, and sentry.org all live in rulesets, and the detection/judgment split is generic. Open questions for the rulesets session: watcher mechanism (systemd timer vs in-session background vs the Monitor tool); where the seen-list lives; passive inbox-drop vs paging.
diff --git a/inbox/PROCESSED-2026-07-20-1059-from-.emacs.d-research-is-there-a-google-maps-mcp-or.org b/inbox/PROCESSED-2026-07-20-1059-from-.emacs.d-research-is-there-a-google-maps-mcp-or.org
new file mode 100644
index 0000000..20aaae1
--- /dev/null
+++ b/inbox/PROCESSED-2026-07-20-1059-from-.emacs.d-research-is-there-a-google-maps-mcp-or.org
@@ -0,0 +1,5 @@
+#+TITLE: Research: is there a Google Maps MCP (or similar) that can r
+#+SOURCE: from .emacs.d
+#+DATE: 2026-07-20 10:59:58 -0500
+
+Research: is there a Google Maps MCP (or similar) that can report the locations of devices that are sharing their location with you? If none exists, research how hard it would be to build one. (Captured in the shared roam inbox, routed here since it's rulesets-owned research.)