coworker/selfwake.py already reserves the hook:
KIND_EVENT = "event" # wake when a named connector/webhook event fires (Phase 3)
Timer (sleep_for/sleep_until) and on-completion wakes work today; the event kind has no producer or ingestion path. This makes any monitoring use case polling-only: an automation on a */10 cron means a detected emergency can sit up to 10 minutes before the agent even looks.
Field test that motivated this: a heatstroke (熱中症) watch — a local monitor process fuses a SwitchBot Hub 2 (temperature/humidity → WBGT) with live Pixel Watch heart rate through a deterministic risk state machine, and raises transitions like 平常→警報 the moment they happen. The monitor knows instantly; OpenWorker finds out on the next cron tick. The same shape applies to CI watchers, inbox monitors, and any external process that already knows when something changed.
Sketch:
POST /v1/wake-events {"name": "heatguard.transition", "payload": {...}} on the loopback API (launch-token gated like everything else)- a session/automation registers interest via the existing wake-store path (
wake_on_event("heatguard.transition")), persisted like timer wakes
- delivery reuses the busy→steer / idle→background-turn machinery that timer wakes and channel subscriptions already use — no new session semantics
- events with no subscriber land in the unrouted store (or are dropped with a count), so a misconfigured producer is visible
The scheduler tick and due()/complete_job() plumbing look reusable as-is; the new surface is the ingestion endpoint + subscription records + (optionally) an event trigger kind on automations, so a task can be "run when X fires" instead of cron-only.
Happy to build this behind a PR if the shape sounds right — the heatstroke deployment is a ready-made end-to-end test.
🤖 Generated with Claude Code
coworker/selfwake.pyalready reserves the hook:Timer (
sleep_for/sleep_until) and on-completion wakes work today; the event kind has no producer or ingestion path. This makes any monitoring use case polling-only: an automation on a*/10cron means a detected emergency can sit up to 10 minutes before the agent even looks.Field test that motivated this: a heatstroke (熱中症) watch — a local monitor process fuses a SwitchBot Hub 2 (temperature/humidity → WBGT) with live Pixel Watch heart rate through a deterministic risk state machine, and raises transitions like 平常→警報 the moment they happen. The monitor knows instantly; OpenWorker finds out on the next cron tick. The same shape applies to CI watchers, inbox monitors, and any external process that already knows when something changed.
Sketch:
POST /v1/wake-events {"name": "heatguard.transition", "payload": {...}}on the loopback API (launch-token gated like everything else)wake_on_event("heatguard.transition")), persisted like timer wakesThe scheduler tick and
due()/complete_job()plumbing look reusable as-is; the new surface is the ingestion endpoint + subscription records + (optionally) aneventtrigger kind on automations, so a task can be "run when X fires" instead of cron-only.Happy to build this behind a PR if the shape sounds right — the heatstroke deployment is a ready-made end-to-end test.
🤖 Generated with Claude Code