Astronomical event triggers (meteor showers, eclipses, moon phases, aurora)

claude-bot commented

2026-07-07 17:37:50 +00:00

Contributor

Goal

Extend the event calendar with sky/astronomical occurrences so the lights can mark meteor-shower peaks, solar/lunar eclipses, full moons, and (optionally) aurora alerts.

Why it's valuable

Iris already computes solstices and equinoxes via the computed recurrence registry — astronomical events are a natural, on-theme extension of a system that already tracks the sky, with no new architecture.

Sketch

Add new entries to the computed function registry (e.g. major annual meteor showers with known peak dates, eclipse tables, full-moon dates).
Optional live layer for aurora (e.g. NOAA Kp-index) gated behind a config flag, following the same optional-source pattern as Calendarific.
Ship default built-in schemes for these events (e.g. shimmer/twinkle for meteor showers, deep red for a lunar eclipse).

Acceptance criteria

Meteor showers, eclipses, and full moons resolve as calendar events
At least one resolvable built-in scheme per new event type
Optional aurora source is env-gated and off by default

Proposed enhancement (brainstorm follow-up).

## Goal Extend the event calendar with sky/astronomical occurrences so the lights can mark meteor-shower peaks, solar/lunar eclipses, full moons, and (optionally) aurora alerts. ## Why it's valuable Iris already computes solstices and equinoxes via the `computed` recurrence registry — astronomical events are a natural, on-theme extension of a system that already tracks the sky, with no new architecture. ## Sketch - Add new entries to the `computed` function registry (e.g. major annual meteor showers with known peak dates, eclipse tables, full-moon dates). - Optional live layer for aurora (e.g. NOAA Kp-index) gated behind a config flag, following the same optional-source pattern as Calendarific. - Ship default built-in schemes for these events (e.g. shimmer/twinkle for meteor showers, deep red for a lunar eclipse). ## Acceptance criteria - [ ] Meteor showers, eclipses, and full moons resolve as calendar events - [ ] At least one resolvable built-in scheme per new event type - [ ] Optional aurora source is env-gated and off by default Proposed enhancement (brainstorm follow-up).

claude-bot added the

labels

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

claude-bot added this to the v1.1.0 milestone

2026-07-15 15:32:57 +00:00

claude-bot referenced this issue

2026-09-04 23:36:11 +00:00

Eclipse events need an ephemeris and a visibility model, not a date table #126

rbrooks referenced this issue from a commit

2026-09-04 23:43:55 +00:00

Put meteor showers, full moons and aurora on the calendar (#20)

claude-bot referenced this issue from a pull request that will close it,

2026-09-04 23:45:40 +00:00

Put meteor showers, full moons and aurora on the calendar (#20) #127

claude-bot closed this issue

2026-09-04 23:55:59 +00:00

claude-bot referenced this issue from a commit

2026-09-04 23:56:00 +00:00

Put meteor showers, full moons and aurora on the calendar (#20) (#127)

claude-bot commented

2026-09-04 23:56:09 +00:00

Author

Contributor

Landed in #127 (squash-merged to main).

What shipped

Seven meteor showers as fixed multi-day spans. Earth crosses the same debris stream at the same orbital position each year, so the peak moves by at most a day and a lookup table would be maintenance for no accuracy. Spans rather than single days because the peak is a few hours inside several active nights — a one-day event would usually miss it.
Eleven named full moons, computed from astral rather than tabulated. That matters for #61: they add nothing to the lookup-table horizon and keep working indefinitely.
Aurora (AURORA_ENABLED, off by default) polling NOAA's planetary K-index, showing an aurora scheme above AURORA_MIN_KP and restoring the scheduled scheme when it subsides. Edge-triggered so a continuing storm doesn't restart the effect every fifteen minutes and stutter the strip.
Explicit per-event built-in schemes for all eleven, differentiated by the character of each shower and moon.

Two things worth recording

The moon tests assert astronomy, not dates — that each returned day really is full, that gaps are whole synodic months, that the answer moves year to year. A function returning a fixed date would pass a weaker test, and this is exactly the kind of code that looks right while being wrong.

One of my own test premises was wrong: I asserted consecutive named moons are 28–31 days apart, and May 2026 has two full moons (the 1st and the 31st). Picking one per calendar month necessarily skips one, so that gap is two synodic months. The test now asserts whole synodic multiples and documents the blue-moon case.

Eclipses are not in this — split to #126. They need an ephemeris and a per-observer visibility calculation: a lunar eclipse over the Indian Ocean means nothing to a roofline in Texas, and solar totality varies over a few hundred kilometres. A worldwide eclipse event would be wrong most of the time, and that's a heavier dependency than the image should carry after #60. It deserved its own decision rather than a guess inside this one.

Verified: ruff clean, mypy clean, 610 tests passing, CI green.

Landed in #127 (squash-merged to `main`). **What shipped** - **Seven meteor showers** as fixed multi-day spans. Earth crosses the same debris stream at the same orbital position each year, so the peak moves by at most a day and a lookup table would be maintenance for no accuracy. Spans rather than single days because the peak is a few *hours* inside several active nights — a one-day event would usually miss it. - **Eleven named full moons**, computed from `astral` rather than tabulated. That matters for #61: they add nothing to the lookup-table horizon and keep working indefinitely. - **Aurora** (`AURORA_ENABLED`, off by default) polling NOAA's planetary K-index, showing an aurora scheme above `AURORA_MIN_KP` and restoring the scheduled scheme when it subsides. Edge-triggered so a continuing storm doesn't restart the effect every fifteen minutes and stutter the strip. - Explicit per-event built-in schemes for all eleven, differentiated by the character of each shower and moon. **Two things worth recording** The moon tests assert *astronomy*, not dates — that each returned day really is full, that gaps are whole synodic months, that the answer moves year to year. A function returning a fixed date would pass a weaker test, and this is exactly the kind of code that looks right while being wrong. One of my own test premises was wrong: I asserted consecutive named moons are 28–31 days apart, and May 2026 has two full moons (the 1st and the 31st). Picking one per calendar month necessarily skips one, so that gap is two synodic months. The test now asserts whole synodic multiples and documents the blue-moon case. **Eclipses are not in this** — split to #126. They need an ephemeris *and* a per-observer visibility calculation: a lunar eclipse over the Indian Ocean means nothing to a roofline in Texas, and solar totality varies over a few hundred kilometres. A worldwide eclipse event would be wrong most of the time, and that's a heavier dependency than the image should carry after #60. It deserved its own decision rather than a guess inside this one. Verified: `ruff` clean, `mypy` clean, 610 tests passing, CI green.

claude-bot referenced this issue

2026-09-05 00:52:15 +00:00

Two effect IDs don't mean what the code says they mean #132

rbrooks referenced this issue from a commit

2026-09-05 00:56:14 +00:00

Make two effect IDs mean what their comments claim (#132)

claude-bot referenced this issue

2026-09-05 00:56:27 +00:00

Make two effect IDs mean what their comments claim (#132) #133