From 24ca58d764dbcc2bad57a914a10e9e9b89a3f66e Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Tue, 23 Jun 2026 23:06:46 -0400 Subject: feat(inbox): consolidate three inbox workflows into one engine I merged process-inbox, monitor-inbox, and inbox-zero into one inbox.org engine. A shared core (value gate, skeptical review, disposition ladder, reply discipline, capture-guard, priority-scheme check) holds the logic that used to be duplicated and cross-referenced across the three files. Each mode (process, monitor, roam) references the core by name instead of restating it. Every trigger phrase still works, now routing to a mode, so there's nothing to relearn. I added the interactive auto inbox zero mode: ask for an interval, run roam mode on /loop, acknowledge-only on an empty cycle, surface a find to a queue gated on a yes. The fully-unattended /schedule pass stays vNext, tracked separately. I repointed every live caller (INDEX, protocols, startup Phase C, wrap-up Step 3, triage-intake, broadcast) at inbox.org and its modes, then deleted the three old files. triage-intake and no-approvals stay separate by design. The value gate, dispositions, capture-guard, and reply discipline all behave as before. Built from the Ready spec. Workflow-integrity and sync-check pass on both the canonical and mirror trees, the stale-reference grep is clean, and the full suite is green. Claude-Session: https://claude.ai/code/session_017PtX1nt1rtYVATuzmzBS4f --- claude-rules/emacs.md | 2 +- claude-rules/todo-format.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) (limited to 'claude-rules') diff --git a/claude-rules/emacs.md b/claude-rules/emacs.md index 907a981..ae4f7cb 100644 --- a/claude-rules/emacs.md +++ b/claude-rules/emacs.md @@ -32,4 +32,4 @@ This replaces the quit → relaunch → re-find-and-load-files cycle for most ed The reload caveats above are about pushing changes *into* the daemon. The inverse hazard: a tool that edits a file *on disk* while the daemon has an indirect buffer cloned from it. org-capture works through such a buffer, and a disk write (a hand edit, a `git pull` that fast-forwards the file, a `sed`/Write) reverts the base buffer underneath the capture. The capture is left on stale state, can no longer finalize with `C-c C-c`, and a freshly-typed item can be lost or written back against post-edit content. Orphaned `CAPTURE-*` buffers piling up as Craig retries is the visible symptom. -The roam inbox (`~/org/roam/inbox.org`) is the live case — Craig captures into it constantly, and inbox-zero's Phase D edits it. Before a disk write to a file the daemon may be capturing into, check first: `.ai/scripts/capture-guard ` exits non-zero (and names the buffer) when a live capture is cloned from ``, and exits 0 — safe — when there's no capture or no reachable Emacs. Same principle as the reload rule, one layer out: leave the daemon's live buffers authoritative rather than yanking the file from under them. +The roam inbox (`~/org/roam/inbox.org`) is the live case — Craig captures into it constantly, and the inbox workflow's roam mode (Phase D) edits it. Before a disk write to a file the daemon may be capturing into, check first: `.ai/scripts/capture-guard ` exits non-zero (and names the buffer) when a live capture is cloned from ``, and exits 0 — safe — when there's no capture or no reachable Emacs. Same principle as the reload rule, one layer out: leave the daemon's live buffers authoritative rather than yanking the file from under them. diff --git a/claude-rules/todo-format.md b/claude-rules/todo-format.md index b9e93bb..895526f 100644 --- a/claude-rules/todo-format.md +++ b/claude-rules/todo-format.md @@ -24,8 +24,8 @@ guessing: The section is mandatory. A `todo.org` without it leaves `[#A]` and the tags undefined, so task-audit can't enforce a vocabulary, task-review can't grade -against agreed semantics, and process-inbox can't file new tasks correctly -(its Phase B.1 already checks for this scheme). Each project defines the +against agreed semantics, and the inbox workflow can't file new tasks correctly +(its priority-scheme check already gates on this scheme). Each project defines the scheme its own way; the floor is that priorities and tags are both spelled out under the header. -- cgit v1.2.3