🧬 pulse

fleet cell edits HEARTBEAT.md
   │  (PostToolUse hook)
   ▼
proxy /heartbeat-changed
   │
   ▼
~/.cells/pulse-inbox/  ← Mac-side queue, survives pulse hibernating
   │  every ~60s
   ▼
[cells-pulse cell] claude --print runs the pulse skill:
   drain inbox → translate prose → cron lines
   save-schedule → writes /etc/cron.d/pulse-schedules
   render → refresh state/heartbeats.md digest
   render-dashboard → writes this page
   │
   ▼
/etc/cron.d/pulse-schedules  ← Linux cron evaluates every minute
   │  matched lines fire
   ▼
cron-fire.sh wraps:  cells talk --await <cell> "<msg>"
   │  times the call, logs latency + exit code
   ▼
/root/.cells/logs/cron-fires.log

Push for schedule updates, pull for firing. When a cell edits its HEARTBEAT.md, a hook pushes the change to pulse via the proxy. Pulse drains that inbox every ~60s, parses prose like "every weekday at 8am" into a 5-field crontab line, and writes it into /etc/cron.d/pulse-schedules. From there Linux cron is the fire engine — pulse is just the prose-to-cron compiler.

Cron is evaluated in Mountain time. Pulse's cell is pinned to America/Denver, so 0 8 * * * means 8am MDT/MST and DST is handled by the OS. Prose with explicit UTC times gets converted.

State survives hibernation. The inbox is Mac-side (~/.cells/pulse-inbox/); cells can push schedule updates even while pulse-cc is asleep, and pulse drains the backlog when it wakes. Per-cell parsed schedules live at pulse-cache/<cell>.json; the firing record is the cron-fires log inside the pulse cell.

Latency is the cell's response time. cells talk waits for the receiving cell to actually ack the message (default 180s timeout). A small latency means the cell was running and responsive. A latency near 180s usually means the talk timed out — the cell may have been hibernating and failed to wake. The "missed" status above means cron should have fired but no log entry showed up at all.

← fleet