#+TITLE: sentry.org: the arming mechanism was wrong, and it made sent
#+SOURCE: from work
#+DATE: 2026-07-30 07:36:49 -0500

sentry.org: the arming mechanism was wrong, and it made sentry unusable as documented.

Sending the edited .ai/workflows/sentry.org from the work project. The canonical needs the same change so every sentry-capable project gets it.

What was wrong. Entry step 7 said to arm with /loop, and justified it by saying a detached schedule hits a headless-auth wall for MCP. That reasoning is sound for a system cron or at job spawning a fresh headless agent, but it is not what we actually use. CronCreate schedules a prompt inside the arming session, so MCP auth is inherited. The work project proved this overnight on 2026-07-28/29: cron-driven triage sweeps read Gmail, Slack, Linear and both calendars for hours.

The practical cost of the error: I told Craig this morning that I could not arm sentry because /loop had to come from him. That was wrong, and it is the second time the doc's stated mechanism diverged from his actual practice, which has been at or cron with each round scheduling the next.

What changed:

1. Step 7 rewritten for CronCreate, documenting both shapes. Recurring, where the single-runner lock covers overlap. And self-rescheduling one-shots, which is Craig's established practice and makes serialization structural rather than lock-dependent, with the interval measured from end-of-fire rather than wall clock.
2. Three constraints added that the file did not carry and that decide how sentry can be used at all. CronCreate jobs are session-only and in-memory, so sentry survives exactly as long as the session that armed it and closing the terminal ends it. Fires run inside that session, hence the inherited auth. Recurring jobs auto-expire after seven days.
3. Stop Sentry now says CronList then CronDelete, with a check that no sentry job survives, rather than 'stop the /loop (ScheduleWakeup stop)'.
4. The overview and the interval trigger reworded off loop language.

One thing I deliberately did not change, and it is worth a second opinion. Pass 3 excludes mail and messenger sources on Craig's 2026-07-21 ruling. My first draft of the new section asserted that inherited auth means the pass is no longer restricted, which silently overturned that ruling by inferring a technical cause for a policy decision. I caught it and replaced it with a note saying the exclusion is a choice rather than a wall, so nobody reasons from 'sentry cannot reach Gmail'. If the canonical wants the exclusion revisited now that the auth story is clear, that is Craig's call rather than a doc edit.

Companion file to reconcile: nothing in the same directory references the arming mechanism, but a grep for '/loop' across the templates would be worth running, since triage-intake.org's auto mode carries the same headless-auth claim in its 'Trigger and delivery' section and is likely wrong for the same reason.