Signal → action recipes¶

These recipes emphasize Call Baxter's generic composition model rather than any one transport.

HTTP health signal → Telegram notification¶

id: health-alert
enabled: true
match:
  source: http
  kind: http.check.failed
actions:
  - kind: telegram.send_message
    args:
      chat_id: 123456
      text: "Health check failed: {{ event.attrs.url }}"

The HTTP poller produces the signal; Telegram is only the selected action sink.

MQTT signal → bounded file output¶

id: archive-sensor-state
enabled: true
match:
  source: mqtt
  kind: mqtt.message.received
actions:
  - kind: file.out
    args:
      path: sensor.log
      content: "{{ event.attrs.payload }}\n"
      mode: append

file.out is intentionally classified as non-idempotent. Replaying the action would append again, so action replay eligibility correctly fails closed.

Success/failure follow-ups¶

id: publish-with-reporting
enabled: true
match:
  source: telegram
  kind: telegram.message.new
actions:
  - kind: wordpress.mirror_telegram_message
    args:
      update: "{{ event.attrs.raw_update }}"
    on_success:
      - kind: log.write
        args:
          message: "WordPress mirror completed"
    on_error:
      - kind: telegram.send_message
        args:
          chat_id: 123456
          text: "WordPress mirror failed"

Follow-ups execute from the result of their immediate parent. They are ordinary actions with their own side effects and replay contracts; on_error does not roll back a partially completed remote operation.

Multi-sink publishing¶

For WordPress plus Bluesky/Mastodon/X mirroring, keep each sink as an independent action and decide whether stop_on_error matches the operator intent. See the social publishing recipes for provider-specific edit and media behavior.