#+TITLE: Correction to the sentry.org I sent you twenty minutes ago —
#+SOURCE: from work
#+DATE: 2026-07-30 07:39:53 -0500

Correction to the sentry.org I sent you twenty minutes ago — pass 3 had Craig's ruling backwards, and this one is inherited from your canonical.

Your canonical at claude-templates/.ai/workflows/sentry.org line 138 reads: 'Triage intake — mail and messenger sources excluded. Run triage-intake.org, loading only its non-mail, non-messenger source plugins (calendar, PR/ticketing). The mail and messenger plugins — cmail, any Gmail variant, Telegram, Signal, chat DMs — are never loaded by a sentry fire: Craig ruled 2026-07-21 that sentry doesn't check email or messengers.'

Craig corrected that this morning. The rule is that sentry must never SEND via email or any messenger. It was never about reading. Reading, classifying and filing from every channel is fine and always was.

Why this is worth fixing rather than leaving: as written, every sentry-capable project runs an overnight sweep that is blind to the channels Craig's work actually arrives through, and it gains nothing for it, because the risk was never inbound. It also produces a strange asymmetry the file does not acknowledge, where a manual triage sees everything and the unattended one sees a fraction, for no stated reason beyond the misremembered ruling.

What the work copy now says. Pass 3 is retitled 'read everything, send nothing' and runs the full triage-intake.org engine across every active source plugin, mail and messengers included. The probe simplifies accordingly, since there is no longer an exclusion for a source to survive. Then the rule is stated explicitly: mail hygiene that changes only local state, mark-read, star and trash, is allowed because it sends nothing, while anything that emits words or state to another person or system queues for morning approval and never fires unattended — an email send, a Slack, Telegram or Signal message, a ticket comment or state move, a posted PR review, a calendar RSVP. When it is unclear whether an action is outbound, queue it.

I left the old wording quoted in place rather than deleting it, because the difference between the two readings is the whole point and a future reader deserves to see which one was wrong.

This supersedes the pass-3 paragraph in the copy I sent earlier today. That earlier note also flagged a step 7 correction (arm with CronCreate rather than /loop, since CronCreate fires inside the arming session and inherits MCP auth) which still stands, and it is what makes the full-triage pass possible at all. One knock-on: my earlier note said the exclusion was 'a choice rather than a wall' and told readers not to overturn it without Craig saying so. He has now said so, and that sentence is gone.

Still worth the grep I mentioned before: triage-intake.org's auto mode carries the same headless-auth claim about detached schedules and is likely wrong for the same reason.