Inbound triggers & rule engine #32

New issue

Open

opened 2026-07-07 17:39:15 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-07-07 17:39:15 +00:00

Contributor

Goal

Introduce an inbound-event abstraction and a small rule engine so external signals can drive the lights: an inbound webhook, a sports team's game/win, a CI build failing, an AQI threshold, a Twitch go-live, etc.

Why it's valuable

Iris has outbound webhooks only. Adding inbound triggers is a force multiplier — one abstraction unlocks a whole class of "react to X" features (weather, sports, home automation) instead of hard-coding each. This is the shared substrate the weather-reactive and astronomical/aurora features can plug into.

Why it's a v2 bet

It introduces a new "event source" concept alongside the calendar and a rule/priority model for reconciling triggered states with the scheduled scheme — that's an architecture decision, not just a feature. Worth a design note before implementation.

Sketch

Event sources: the calendar is one source; add inbound webhook + pollers (sports/AQI/etc.) as others.
Rules: when <source/condition> then <scheme/modifier> for <duration>, priority <n>, reconciled against the scheduled scheme (temporary override with auto-revert, reusing quick-push semantics).
Inbound webhook endpoint with a shared secret / HMAC verification (mirror the outbound signing).
Guardrails: rate limiting, precedence rules, and an audit trail for every triggered change.

Acceptance criteria

A documented event-source + rule abstraction (design note first)
Inbound webhook endpoint with signature verification
At least one non-webhook source (e.g. a poller) proving the abstraction
Triggered overrides reconcile with and revert to the schedule
Audit entries + rate limiting; tests

Design note

Land the abstraction so weather-reactive schemes and aurora alerts become event sources rather than bespoke integrations.

Proposed enhancement (brainstorm follow-up).

## Goal Introduce an inbound-event abstraction and a small rule engine so external signals can drive the lights: an inbound webhook, a sports team's game/win, a CI build failing, an AQI threshold, a Twitch go-live, etc. ## Why it's valuable Iris has **outbound** webhooks only. Adding inbound triggers is a force multiplier — one abstraction unlocks a whole class of "react to X" features (weather, sports, home automation) instead of hard-coding each. This is the shared substrate the weather-reactive and astronomical/aurora features can plug into. ## Why it's a v2 bet It introduces a new "event source" concept alongside the calendar and a rule/priority model for reconciling triggered states with the scheduled scheme — that's an architecture decision, not just a feature. Worth a design note before implementation. ## Sketch - **Event sources**: the calendar is one source; add inbound webhook + pollers (sports/AQI/etc.) as others. - **Rules**: `when <source/condition> then <scheme/modifier> for <duration>, priority <n>`, reconciled against the scheduled scheme (temporary override with auto-revert, reusing quick-push semantics). - Inbound webhook endpoint with a shared secret / HMAC verification (mirror the outbound signing). - Guardrails: rate limiting, precedence rules, and an audit trail for every triggered change. ## Acceptance criteria - [ ] A documented event-source + rule abstraction (design note first) - [ ] Inbound webhook endpoint with signature verification - [ ] At least one non-webhook source (e.g. a poller) proving the abstraction - [ ] Triggered overrides reconcile with and revert to the schedule - [ ] Audit entries + rate limiting; tests ## Design note Land the abstraction so weather-reactive schemes and aurora alerts become event sources rather than bespoke integrations. Proposed enhancement (brainstorm follow-up).

claude-bot added the

labels

2026-07-07 17:39:47 +00:00