From edb545db727861f21052ca5111db1d949ebf030a Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Mon, 15 Jun 2026 10:36:22 -0500 Subject: feat(inbox): define monitor-inbox as a 15-min loop with clean-tree gates MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Redefine "monitor the inbox" as the explicit behavior Craig wants: run one process-inbox pass now, then loop process-inbox every 15 minutes. The 15-minute loop was previously an opt-in background recipe; it's now the defined meaning of the phrase. Gate the workflow at both ends on a clean worktree and a green full-suite run. Starting on a dirty tree lets the per-item auto-commit sweep up unrelated changes; starting on a red suite hides whether the monitor broke anything. On a dirty tree, offer to commit in discrete batches; on a red suite, offer to investigate — never start until both are satisfied, and leave the tree clean and green when the loop stops. Add the no-approvals execute criteria: an accepted item self-applies only when agreed (passed the value gate and Skeptical Review), quick (under ~15 min including verification), and solo (no decision needed from Craig). All three commit and push at the end of the item; miss any and it files or, for shared-asset and convention changes, parks. Broaden the Skeptical Review to run on every arriving task and file, not only shared-asset proposals — a core right/complete/simpler pass on everything, with the cross-project battery added for changes that sync to consuming projects. --- .ai/workflows/INDEX.org | 2 +- .ai/workflows/monitor-inbox.org | 52 ++++++++++++++++++------ .ai/workflows/process-inbox.org | 29 +++++++------ claude-templates/.ai/workflows/INDEX.org | 2 +- claude-templates/.ai/workflows/monitor-inbox.org | 52 ++++++++++++++++++------ claude-templates/.ai/workflows/process-inbox.org | 29 +++++++------ 6 files changed, 116 insertions(+), 50 deletions(-) diff --git a/.ai/workflows/INDEX.org b/.ai/workflows/INDEX.org index 95fe37d..42119b4 100644 --- a/.ai/workflows/INDEX.org +++ b/.ai/workflows/INDEX.org @@ -46,7 +46,7 @@ This index must list every =.org= file in =.ai/workflows/= except this one and e - Triggers: "clean up todo.org", "clean-todo", "tidy the todo file", "archive the done items in todo.org", "run the todo cleanup" - =process-inbox.org= — evaluate each inbox item against a three-question value gate (advances an existing TODO / improves the project / serves the mission), then implement, fold, file, defer, or reject per source (Craig / project handoff / script). Auto-invoked by startup when inbox is non-empty. Source-aware rejection flow: handoff rejections write a response back via =inbox-send= naming the failed gate question and any reconsideration condition. - Triggers: "process inbox", "process the inbox", "handle the inbox", "what's in inbox", "what's in the inbox", "let's clear the inbox", "let's process the inbox items" -- =monitor-inbox.org= — the cadence + act-vs-file + reply layer over process-inbox: check =inbox-status= at every task boundary, decide act-now (just do it) vs file (ask, file = option 1), and confirm back to handoff senders. Includes the opt-in background-monitor =/loop= recipe. +- =monitor-inbox.org= — the cadence + act-vs-file + reply layer over process-inbox: "monitor the inbox" runs a pass now then loops process-inbox every 15 min; gates on a clean tree + green suite at both ends; in no-approvals mode auto-executes only agreed + quick + solo items (else files or parks); also the ambient =inbox-status= task-boundary check and the reply-to-sender discipline. - Triggers: "monitor the inbox", "watch the inbox", "respond to the handoffs", "handle the handoffs" - =inbox-zero.org= — route the *global roam inbox* (=~/org/roam/inbox.org=) to owning projects by =:= heading prefix. Distinct from =process-inbox.org= (the project's own =inbox/= dir). The current session claims only its own prefixed items, files them into =todo.org=, removes them from the shared inbox, and leaves foreign/unowned items. Every scan reports the total item count plus how many appear related to this project. v1 is single-destination (prefix-claim only); domain-aware whole-inbox routing is deferred. Called read-only from startup (count + offer) and as a wrap-up Step 3 sub-step. - Triggers: "inbox zero", "empty the inbox", "process the roam inbox", "triage my roam inbox" diff --git a/.ai/workflows/monitor-inbox.org b/.ai/workflows/monitor-inbox.org index 1639f3b..4912a2b 100644 --- a/.ai/workflows/monitor-inbox.org +++ b/.ai/workflows/monitor-inbox.org @@ -8,18 +8,35 @@ Keep the project's =inbox/= responsive: notice handoffs on a cadence, triage eac The gap this closes: handoffs that arrive mid-session used to sit unseen until the user asked or the next startup ran. A handoff the sender can't see being handled trains them to escalate around the inbox channel. +* Preconditions — before starting + +Never begin inbox monitoring on a dirty worktree or with a failing test suite. A dirty tree means the auto-commit at the end of an executed item sweeps up unrelated changes; a red suite means you can't tell whether the monitor broke something. At the start of the workflow, check both: + +1. =git status --porcelain= is empty (clean worktree). +2. A full test run is all green (=make test= here, or the project's full-suite command). + +If the worktree is *dirty*: offer to commit the pending changes in discrete, logical batches before starting. If the suite is *red*: offer to investigate the failures first. Surface the blocker with inline numbered options per =interaction.md= and wait — monitoring does not start until the tree is clean and the suite is green. + * When to Use This Workflow Trigger phrases: -- "monitor the inbox" / "watch the inbox" -- "respond to the handoffs" / "handle the handoffs" +- "monitor the inbox" / "watch the inbox" — *the defined meaning:* run one process-inbox pass now, then loop process-inbox every 15 minutes (see Cadence). Not an opt-in extra — the phrase *is* the loop. +- "respond to the handoffs" / "handle the handoffs" — a single pass now, no loop. -Cadence auto-trigger (the main mechanism — see Cadence below): check at every task boundary during a session, not only when asked. +Cadence auto-trigger (ambient, always on): check at every task boundary during a session, even when no loop is running — see Cadence below. * Cadence — how often to check -*Default: check at every task boundary.* After finishing a unit of work, before reporting back or asking "what's next," run the cheap status check: +*"Monitor the inbox" = run now, then loop every 15 minutes.* When Craig says monitor or watch the inbox, do one process-inbox pass over any pending handoffs immediately, then start the loop: + +#+begin_src +/loop 15m check the inbox with inbox-status and run process-inbox.org over any pending handoffs +#+end_src + +Each firing runs the cheap =inbox-status= check first and only does a full process-inbox pass when items are pending. The loop is the monitoring; it runs until Craig stops it or the session ends. Honor the Preconditions gate before the first pass and the Close-out gate when the loop stops. + +*Ambient task-boundary check (always on, even without a loop).* After finishing a unit of work, before reporting back or asking "what's next," run the cheap status check: #+begin_src bash .ai/scripts/inbox-status -q @@ -31,14 +48,6 @@ Exit 1 means handoffs are pending — list them (drop =-q=) and process per proc *Mid-task arrivals.* If a handoff lands while you're mid-task and it's urgent (blocks the current work, or is time-sensitive), surface it right away. Otherwise batch it to the next task boundary so the current work isn't thrashed. -*Unattended / background monitoring (opt-in).* When the user is working elsewhere and wants rulesets handoffs handled without being present, run a polling loop: - -#+begin_src -/loop 15m check the inbox with inbox-status and process any handoffs per process-inbox.org -#+end_src - -This is opt-in, not the default — continuous polling has a cost, and most handoffs aren't urgent. Pick an interval matched to how fast handoffs actually arrive (a burst of cross-project work warrants a tighter loop; a quiet day warrants none). - * The act-vs-file decision Every accepted handoff (one that clears process-inbox's value gate) is then either acted on now or filed as a task. The rule, and how to surface it: @@ -75,6 +84,16 @@ Pick a number. *Always ask if you're unsure* which side of the line an item falls on. Decisiveness on clear act-now items is the point of the rule; the ask is for genuine ambiguity and for filing. +** Executing in no-approvals mode + +When Craig has put the session in no-approvals mode, an accepted item may be implemented automatically — but only when all three of these hold: + +1. *Agreed* — you've run the value gate and the full Skeptical Review and concluded the change should be done, not merely that it's harmless. +2. *Quick* — the whole implementation, including verification, is under ~15 minutes. +3. *Solo* — you can carry it end to end without a decision from Craig. Manual verification you perform yourself is fine; needing Craig to choose an option, approve a design, or resolve an ambiguity is not. + +All three → implement it, verify, then commit and push at the end of that item (the Step 0 reconcile and pre-push check from =commits.md= still run). Miss any one and it doesn't self-apply: a shared-asset or convention change needs Craig's decision, so it fails *solo* and routes to process-inbox's defer-and-stage park; an oversized item fails *quick* and gets filed. + * Replying to handoffs A handoff came from another project's agent (or the user). Close the loop: @@ -89,6 +108,15 @@ Cross-project boundary: never act on a file under another project's =.ai/= scope =.ai/scripts/inbox-status= lists unprocessed handoffs and exits nonzero when any are pending. Exclusions match the wrap-up sanity check (=.gitkeep=, =lint-followups.org=, =PROCESSED-*=). Exit 0 = clean, 1 = pending, 2 = no inbox/ or bad usage. Use =-q= for the count-only form the cadence check calls. +* Close out — before finishing + +End the workflow the way it started: clean worktree, green suite. Before stopping the loop or reporting the pass done: + +1. Commit or revert everything left in the worktree — nothing uncommitted remains. +2. Run the full test suite once more and confirm all green. + +If either can't be satisfied — a half-done item, a failure introduced during the pass — surface it rather than leaving it. The next monitor run assumes a clean, green starting state (the Preconditions gate), so handing it a dirty tree or a red suite breaks the next run before it begins. + * Living Document Tune the cadence if task-boundary checking proves too frequent or too sparse in practice. Refine the act-vs-file criteria as edge cases recur. If the background-monitor loop becomes a common pattern, capture the interval that worked. The decision rule itself — act-now is silent, filing asks with file-as-option-1, ambiguity asks — is the stable core (set by Craig, 2026-05-30). diff --git a/.ai/workflows/process-inbox.org b/.ai/workflows/process-inbox.org index 86df4c2..af406ee 100644 --- a/.ai/workflows/process-inbox.org +++ b/.ai/workflows/process-inbox.org @@ -33,24 +33,29 @@ Every inbox item passes through three questions. One *yes* is enough to accept. Three *no*s means reject. The rejection isn't lazy — an idea that doesn't help any current task, doesn't improve the system, and doesn't serve the mission is genuine noise, and accepting it inflates =todo.org= without payoff. -* The Skeptical Review (change proposals) +* The Skeptical Review (every arriving task and file) -The value gate decides whether an item is worth taking. This review decides whether the proposed change is *right*. It applies to any item proposing a change to shared assets — template workflows, rules, skills, scripts, anything synced to consuming projects — and to any substantive convention change. FYIs, replies, and routine task filings skip it. +The value gate decides whether an item is worth taking. This review decides whether what it proposes is *right*, *complete*, and *as simple as it should be*. Run it on every task and file that arrives in the inbox — not only shared-asset change proposals. Pure FYIs and replies that ask for nothing skip it. -Approach the file with curiosity and skepticism. It arrived from one project's context; you're evaluating it for all of them. Work through, in writing: +Approach the file with curiosity and skepticism. Work through, in writing — the core pass on every item: -1. Does this make sense for *all* consuming projects, or just the sender's situation? -2. Does it conflict with any existing instruction — workflows, skills, rules, protocols, CLAUDE.md? -3. How does it change a common activity Craig performs — better, worse, or differently than the sender assumed? +1. Is the request actually right — does it do what it claims, and is the claim correct for this project? +2. Is it complete, or does it leave a gap — an unhandled case, a missing step, an untested path? +3. Should it be simpler? 4. Can it be enhanced to be more effective than as proposed? -5. Should it be simpler? -6. Plus at least three more questions specific to this change — e.g. what breaks for artifacts already using the old shape, what tooling interacts with it, what's underspecified, what does the sender's worked example not exercise? +5. Does it conflict with any existing instruction — workflows, skills, rules, protocols, CLAUDE.md? -Output: a short summary of the thinking and a recommendation (accept as-is / accept with named changes / reject), surfaced to Craig for approval before applying. +When the item proposes a change to shared assets — template workflows, rules, skills, scripts, anything synced to consuming projects — or to a substantive convention, add the cross-project battery. It arrived from one project's context; you're evaluating it for all of them: -** In a no-approvals session: defer and stage +6. Does this make sense for *all* consuming projects, or just the sender's situation? +7. How does it change a common activity Craig performs — better, worse, or differently than the sender assumed? +8. Plus at least three more questions specific to this change — what breaks for artifacts already using the old shape, what tooling interacts with it, what's underspecified, what the sender's worked example doesn't exercise. -Behavior-changing proposals still don't self-apply when Craig has put the session in no-approvals mode. Run the review, prepare the edits in =working//= (a patch file or the worked-out diff), file a =[#B]= VERIFY carrying the decision package, and reply to the sender that it's parked. The sender's local stopgap (per =cross-project.md='s propagation process) means the delay costs nothing — the canonical update is about durability, not speed. +Output: a short summary of the thinking and a recommendation (do it / do it with named changes / file / reject). For shared-asset and convention changes the recommendation is surfaced to Craig for approval before applying; for ordinary tasks and files it feeds the act-vs-file and no-approvals-execute decision (=monitor-inbox.org=). + +** In a no-approvals session: shared-asset changes defer and stage + +Shared-asset and convention changes still don't self-apply when Craig has put the session in no-approvals mode — they need his decision, so they fail the *solo* test in monitor-inbox's executing-in-no-approvals criteria. Ordinary tasks and files that pass the review and are quick + solo execute under that criteria instead; this defer-and-stage path is for the shared-asset and convention changes that don't qualify. Run the review, prepare the edits in =working//= (a patch file or the worked-out diff), file a =[#B]= VERIFY carrying the decision package, and reply to the sender that it's parked. The sender's local stopgap (per =cross-project.md='s propagation process) means the delay costs nothing — the canonical update is about durability, not speed. Wording-only fixes — no consuming project acts differently — may proceed even then, logged in the session log. @@ -100,7 +105,7 @@ For each inbox file: 1. *Read it.* For substantive proposals (org files with TODO entries, design notes, multi-section docs), the full read is the right move. For short FYIs and one-liner asks, skim. 2. *Identify the shape.* Is it an instruction, a question, a proposal, an FYI, or a handoff? Shapes guide disposition. 3. *Apply the value gate.* Three questions above. One yes → candidate accept. Three nos → candidate reject. -4. *Run the Skeptical Review* (section above) on any accepted item that proposes a shared-asset or convention change, before classifying. Its summary + recommendation rides along to Phase C; in a no-approvals session its defer-and-stage path replaces implement-now for behavior-changing proposals. +4. *Run the Skeptical Review* (section above) on the item before classifying — the core pass on every accepted task and file, plus the cross-project battery when it proposes a shared-asset or convention change. Its summary + recommendation rides along to Phase C; in a no-approvals session it gates whether the item self-applies (quick + solo + agreed, per =monitor-inbox.org=) or, for shared-asset and convention changes, defers and stages. 5. *Within accept, classify:* - *Implement now* — small, scoped, clear, no design call required. The work is the disposition. - *Fold into existing TODO* — the item extends a task already filed; update the TODO body and link the inbox content if substantive. diff --git a/claude-templates/.ai/workflows/INDEX.org b/claude-templates/.ai/workflows/INDEX.org index 95fe37d..42119b4 100644 --- a/claude-templates/.ai/workflows/INDEX.org +++ b/claude-templates/.ai/workflows/INDEX.org @@ -46,7 +46,7 @@ This index must list every =.org= file in =.ai/workflows/= except this one and e - Triggers: "clean up todo.org", "clean-todo", "tidy the todo file", "archive the done items in todo.org", "run the todo cleanup" - =process-inbox.org= — evaluate each inbox item against a three-question value gate (advances an existing TODO / improves the project / serves the mission), then implement, fold, file, defer, or reject per source (Craig / project handoff / script). Auto-invoked by startup when inbox is non-empty. Source-aware rejection flow: handoff rejections write a response back via =inbox-send= naming the failed gate question and any reconsideration condition. - Triggers: "process inbox", "process the inbox", "handle the inbox", "what's in inbox", "what's in the inbox", "let's clear the inbox", "let's process the inbox items" -- =monitor-inbox.org= — the cadence + act-vs-file + reply layer over process-inbox: check =inbox-status= at every task boundary, decide act-now (just do it) vs file (ask, file = option 1), and confirm back to handoff senders. Includes the opt-in background-monitor =/loop= recipe. +- =monitor-inbox.org= — the cadence + act-vs-file + reply layer over process-inbox: "monitor the inbox" runs a pass now then loops process-inbox every 15 min; gates on a clean tree + green suite at both ends; in no-approvals mode auto-executes only agreed + quick + solo items (else files or parks); also the ambient =inbox-status= task-boundary check and the reply-to-sender discipline. - Triggers: "monitor the inbox", "watch the inbox", "respond to the handoffs", "handle the handoffs" - =inbox-zero.org= — route the *global roam inbox* (=~/org/roam/inbox.org=) to owning projects by =:= heading prefix. Distinct from =process-inbox.org= (the project's own =inbox/= dir). The current session claims only its own prefixed items, files them into =todo.org=, removes them from the shared inbox, and leaves foreign/unowned items. Every scan reports the total item count plus how many appear related to this project. v1 is single-destination (prefix-claim only); domain-aware whole-inbox routing is deferred. Called read-only from startup (count + offer) and as a wrap-up Step 3 sub-step. - Triggers: "inbox zero", "empty the inbox", "process the roam inbox", "triage my roam inbox" diff --git a/claude-templates/.ai/workflows/monitor-inbox.org b/claude-templates/.ai/workflows/monitor-inbox.org index 1639f3b..4912a2b 100644 --- a/claude-templates/.ai/workflows/monitor-inbox.org +++ b/claude-templates/.ai/workflows/monitor-inbox.org @@ -8,18 +8,35 @@ Keep the project's =inbox/= responsive: notice handoffs on a cadence, triage eac The gap this closes: handoffs that arrive mid-session used to sit unseen until the user asked or the next startup ran. A handoff the sender can't see being handled trains them to escalate around the inbox channel. +* Preconditions — before starting + +Never begin inbox monitoring on a dirty worktree or with a failing test suite. A dirty tree means the auto-commit at the end of an executed item sweeps up unrelated changes; a red suite means you can't tell whether the monitor broke something. At the start of the workflow, check both: + +1. =git status --porcelain= is empty (clean worktree). +2. A full test run is all green (=make test= here, or the project's full-suite command). + +If the worktree is *dirty*: offer to commit the pending changes in discrete, logical batches before starting. If the suite is *red*: offer to investigate the failures first. Surface the blocker with inline numbered options per =interaction.md= and wait — monitoring does not start until the tree is clean and the suite is green. + * When to Use This Workflow Trigger phrases: -- "monitor the inbox" / "watch the inbox" -- "respond to the handoffs" / "handle the handoffs" +- "monitor the inbox" / "watch the inbox" — *the defined meaning:* run one process-inbox pass now, then loop process-inbox every 15 minutes (see Cadence). Not an opt-in extra — the phrase *is* the loop. +- "respond to the handoffs" / "handle the handoffs" — a single pass now, no loop. -Cadence auto-trigger (the main mechanism — see Cadence below): check at every task boundary during a session, not only when asked. +Cadence auto-trigger (ambient, always on): check at every task boundary during a session, even when no loop is running — see Cadence below. * Cadence — how often to check -*Default: check at every task boundary.* After finishing a unit of work, before reporting back or asking "what's next," run the cheap status check: +*"Monitor the inbox" = run now, then loop every 15 minutes.* When Craig says monitor or watch the inbox, do one process-inbox pass over any pending handoffs immediately, then start the loop: + +#+begin_src +/loop 15m check the inbox with inbox-status and run process-inbox.org over any pending handoffs +#+end_src + +Each firing runs the cheap =inbox-status= check first and only does a full process-inbox pass when items are pending. The loop is the monitoring; it runs until Craig stops it or the session ends. Honor the Preconditions gate before the first pass and the Close-out gate when the loop stops. + +*Ambient task-boundary check (always on, even without a loop).* After finishing a unit of work, before reporting back or asking "what's next," run the cheap status check: #+begin_src bash .ai/scripts/inbox-status -q @@ -31,14 +48,6 @@ Exit 1 means handoffs are pending — list them (drop =-q=) and process per proc *Mid-task arrivals.* If a handoff lands while you're mid-task and it's urgent (blocks the current work, or is time-sensitive), surface it right away. Otherwise batch it to the next task boundary so the current work isn't thrashed. -*Unattended / background monitoring (opt-in).* When the user is working elsewhere and wants rulesets handoffs handled without being present, run a polling loop: - -#+begin_src -/loop 15m check the inbox with inbox-status and process any handoffs per process-inbox.org -#+end_src - -This is opt-in, not the default — continuous polling has a cost, and most handoffs aren't urgent. Pick an interval matched to how fast handoffs actually arrive (a burst of cross-project work warrants a tighter loop; a quiet day warrants none). - * The act-vs-file decision Every accepted handoff (one that clears process-inbox's value gate) is then either acted on now or filed as a task. The rule, and how to surface it: @@ -75,6 +84,16 @@ Pick a number. *Always ask if you're unsure* which side of the line an item falls on. Decisiveness on clear act-now items is the point of the rule; the ask is for genuine ambiguity and for filing. +** Executing in no-approvals mode + +When Craig has put the session in no-approvals mode, an accepted item may be implemented automatically — but only when all three of these hold: + +1. *Agreed* — you've run the value gate and the full Skeptical Review and concluded the change should be done, not merely that it's harmless. +2. *Quick* — the whole implementation, including verification, is under ~15 minutes. +3. *Solo* — you can carry it end to end without a decision from Craig. Manual verification you perform yourself is fine; needing Craig to choose an option, approve a design, or resolve an ambiguity is not. + +All three → implement it, verify, then commit and push at the end of that item (the Step 0 reconcile and pre-push check from =commits.md= still run). Miss any one and it doesn't self-apply: a shared-asset or convention change needs Craig's decision, so it fails *solo* and routes to process-inbox's defer-and-stage park; an oversized item fails *quick* and gets filed. + * Replying to handoffs A handoff came from another project's agent (or the user). Close the loop: @@ -89,6 +108,15 @@ Cross-project boundary: never act on a file under another project's =.ai/= scope =.ai/scripts/inbox-status= lists unprocessed handoffs and exits nonzero when any are pending. Exclusions match the wrap-up sanity check (=.gitkeep=, =lint-followups.org=, =PROCESSED-*=). Exit 0 = clean, 1 = pending, 2 = no inbox/ or bad usage. Use =-q= for the count-only form the cadence check calls. +* Close out — before finishing + +End the workflow the way it started: clean worktree, green suite. Before stopping the loop or reporting the pass done: + +1. Commit or revert everything left in the worktree — nothing uncommitted remains. +2. Run the full test suite once more and confirm all green. + +If either can't be satisfied — a half-done item, a failure introduced during the pass — surface it rather than leaving it. The next monitor run assumes a clean, green starting state (the Preconditions gate), so handing it a dirty tree or a red suite breaks the next run before it begins. + * Living Document Tune the cadence if task-boundary checking proves too frequent or too sparse in practice. Refine the act-vs-file criteria as edge cases recur. If the background-monitor loop becomes a common pattern, capture the interval that worked. The decision rule itself — act-now is silent, filing asks with file-as-option-1, ambiguity asks — is the stable core (set by Craig, 2026-05-30). diff --git a/claude-templates/.ai/workflows/process-inbox.org b/claude-templates/.ai/workflows/process-inbox.org index 86df4c2..af406ee 100644 --- a/claude-templates/.ai/workflows/process-inbox.org +++ b/claude-templates/.ai/workflows/process-inbox.org @@ -33,24 +33,29 @@ Every inbox item passes through three questions. One *yes* is enough to accept. Three *no*s means reject. The rejection isn't lazy — an idea that doesn't help any current task, doesn't improve the system, and doesn't serve the mission is genuine noise, and accepting it inflates =todo.org= without payoff. -* The Skeptical Review (change proposals) +* The Skeptical Review (every arriving task and file) -The value gate decides whether an item is worth taking. This review decides whether the proposed change is *right*. It applies to any item proposing a change to shared assets — template workflows, rules, skills, scripts, anything synced to consuming projects — and to any substantive convention change. FYIs, replies, and routine task filings skip it. +The value gate decides whether an item is worth taking. This review decides whether what it proposes is *right*, *complete*, and *as simple as it should be*. Run it on every task and file that arrives in the inbox — not only shared-asset change proposals. Pure FYIs and replies that ask for nothing skip it. -Approach the file with curiosity and skepticism. It arrived from one project's context; you're evaluating it for all of them. Work through, in writing: +Approach the file with curiosity and skepticism. Work through, in writing — the core pass on every item: -1. Does this make sense for *all* consuming projects, or just the sender's situation? -2. Does it conflict with any existing instruction — workflows, skills, rules, protocols, CLAUDE.md? -3. How does it change a common activity Craig performs — better, worse, or differently than the sender assumed? +1. Is the request actually right — does it do what it claims, and is the claim correct for this project? +2. Is it complete, or does it leave a gap — an unhandled case, a missing step, an untested path? +3. Should it be simpler? 4. Can it be enhanced to be more effective than as proposed? -5. Should it be simpler? -6. Plus at least three more questions specific to this change — e.g. what breaks for artifacts already using the old shape, what tooling interacts with it, what's underspecified, what does the sender's worked example not exercise? +5. Does it conflict with any existing instruction — workflows, skills, rules, protocols, CLAUDE.md? -Output: a short summary of the thinking and a recommendation (accept as-is / accept with named changes / reject), surfaced to Craig for approval before applying. +When the item proposes a change to shared assets — template workflows, rules, skills, scripts, anything synced to consuming projects — or to a substantive convention, add the cross-project battery. It arrived from one project's context; you're evaluating it for all of them: -** In a no-approvals session: defer and stage +6. Does this make sense for *all* consuming projects, or just the sender's situation? +7. How does it change a common activity Craig performs — better, worse, or differently than the sender assumed? +8. Plus at least three more questions specific to this change — what breaks for artifacts already using the old shape, what tooling interacts with it, what's underspecified, what the sender's worked example doesn't exercise. -Behavior-changing proposals still don't self-apply when Craig has put the session in no-approvals mode. Run the review, prepare the edits in =working//= (a patch file or the worked-out diff), file a =[#B]= VERIFY carrying the decision package, and reply to the sender that it's parked. The sender's local stopgap (per =cross-project.md='s propagation process) means the delay costs nothing — the canonical update is about durability, not speed. +Output: a short summary of the thinking and a recommendation (do it / do it with named changes / file / reject). For shared-asset and convention changes the recommendation is surfaced to Craig for approval before applying; for ordinary tasks and files it feeds the act-vs-file and no-approvals-execute decision (=monitor-inbox.org=). + +** In a no-approvals session: shared-asset changes defer and stage + +Shared-asset and convention changes still don't self-apply when Craig has put the session in no-approvals mode — they need his decision, so they fail the *solo* test in monitor-inbox's executing-in-no-approvals criteria. Ordinary tasks and files that pass the review and are quick + solo execute under that criteria instead; this defer-and-stage path is for the shared-asset and convention changes that don't qualify. Run the review, prepare the edits in =working//= (a patch file or the worked-out diff), file a =[#B]= VERIFY carrying the decision package, and reply to the sender that it's parked. The sender's local stopgap (per =cross-project.md='s propagation process) means the delay costs nothing — the canonical update is about durability, not speed. Wording-only fixes — no consuming project acts differently — may proceed even then, logged in the session log. @@ -100,7 +105,7 @@ For each inbox file: 1. *Read it.* For substantive proposals (org files with TODO entries, design notes, multi-section docs), the full read is the right move. For short FYIs and one-liner asks, skim. 2. *Identify the shape.* Is it an instruction, a question, a proposal, an FYI, or a handoff? Shapes guide disposition. 3. *Apply the value gate.* Three questions above. One yes → candidate accept. Three nos → candidate reject. -4. *Run the Skeptical Review* (section above) on any accepted item that proposes a shared-asset or convention change, before classifying. Its summary + recommendation rides along to Phase C; in a no-approvals session its defer-and-stage path replaces implement-now for behavior-changing proposals. +4. *Run the Skeptical Review* (section above) on the item before classifying — the core pass on every accepted task and file, plus the cross-project battery when it proposes a shared-asset or convention change. Its summary + recommendation rides along to Phase C; in a no-approvals session it gates whether the item self-applies (quick + solo + agreed, per =monitor-inbox.org=) or, for shared-asset and convention changes, defers and stages. 5. *Within accept, classify:* - *Implement now* — small, scoped, clear, no design call required. The work is the disposition. - *Fold into existing TODO* — the item extends a task already filed; update the TODO body and link the inbox content if substantive. -- cgit v1.2.3