Shell 1.11.0: alerts — a module flashes every dashboard listening on one of six channels

A module that sees something a tech must act on now (a timer overrun, a meter
past its limit, timecode gone) raises an alert on a channel, 1–6, and every
dashboard listening to that channel flashes: the menu bar — brought out for
the duration if it was hidden — and a frame round the screen alternate between
the level's two colours, with the alert's text bold across the bar. Low fades
slowly, medium faster, critical snaps with no fade and floods the board behind
the tiles too, in a muted cut that shows faintly through the tile panels
without costing their content any contrast.

Server: the hub. One alert per channel (a new one replaces the last), timed
out server-side (1–600 s, 15 by default, 0 = held until cleared), broadcast
over the shell stream as `alert` / `alert-clear`; GET /api/alerts for a
dashboard that opens or reconnects mid-alert; POST /api/alerts and
DELETE /api/alerts/<n>, open like a layout save. Modules raise from their
server entry with shell.alert() / shell.clearAlert() or from a tile with
moduleApi.alert() / moduleApi.clearAlert(); a module's alerts end when it
stops. Colours live as alerts.colors in the data directory's proddash.json.

Dashboard: the Layouts menu gains a folded Alerts row with six numbered
toggles; the channel list saves with the layout, local and named (the server
keeps it in a saved layout). Admin: a folded Alerts section with two colour
pickers per level, a swatch running each level's cadence, and a Test row.

Docs: docs/ALERTS.md (the feature), a "Raising alerts" section in the module
guide, README. Tools: tools/alert.js raises/clears/lists from the command
line; tools/alerts.test.js drives it all end to end.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/ALERTS.md

@@ -0,0 +1,132 @@
+# ProdDash Alerts
+
+A module that sees something a tech must act on *now* — a timer overrun,
+a meter past its limit, timecode gone — raises an **alert**, and every
+dashboard listening to its channel flashes until it is over. This page is
+the whole feature: what an operator sees and sets, and what a module does
+to raise one. The module-side contract also lives in the
+[Module Guide](MODULE-GUIDE.md#raising-alerts), which is the authority on
+how modules are written.
+
+## What an alert looks like
+
+On a dashboard that listens to the alert's channel:
+
+- The **menu bar** flashes between two colours, with the alert's text in
+  bold across its middle (and a small boxed number saying which channel it
+  came on). If the bar was hidden — by its notch, or because the screen is
+  in fullscreen — it comes out for the alert and goes back when it ends.
+- A **frame round the whole screen** flashes with it, so a fullscreen wall
+  where the bar is the only chrome still carries the flash to its edges.
+- For **low** and **medium**, that is all: the tiles and the board they sit
+  on are left alone. A **critical** alert floods the **board behind the
+  tiles** as well — in a muted cut of its two colours, mixed well toward the
+  page background and showing faintly through the tiles' own panels — so
+  the flash reaches the middle of a screen the tiles cover entirely, while
+  everything written on a tile keeps its contrast. A module's content is
+  never recoloured.
+
+The **level** sets the cadence. The two colours each level flashes between
+are the admin's choice (below).
+
+| Level | Cadence | For |
+| --- | --- | --- |
+| **Low** | a slow fade between the two colours, about three seconds a cycle; bar and frame only | something to know about |
+| **Medium** | a faster fade, about one second a cycle; bar and frame only | something to deal with soon |
+| **Critical** | no fade — the colours snap, twice a second; bar, frame and the board behind the tiles | something to deal with now |
+
+When several alerts a dashboard listens to are on at once, the bar shows
+the most severe (the newest among equals) and a **+1** says how many more
+there are.
+
+## Channels
+
+There are **six channels**, numbered 1 to 6, and nothing else: a channel
+carries no meaning of its own. A booth gives them meaning — "1 is the
+stage, 2 is video, 3 is the lobby" — by pointing modules at them (a module
+that raises alerts makes its channel an admin setting) and by choosing
+which channels each dashboard listens to.
+
+**Choosing channels:** on the dashboard, open the Layouts menu (the grid
+icon) and the **Alerts** row — it says which channels this screen listens
+to and opens to six numbered buttons that toggle them. The choice is part
+of the arrangement, like the grid size and auto-hide: it saves with this
+browser's layout and with a named layout on the server, so a booth that
+loads its "Stage" layout gets the stage's channels with it. A fresh
+dashboard listens to nothing.
+
+## One alert per channel
+
+A channel shows one alert at a time. A new alert on a channel replaces
+whatever was on it, whoever raised it; clearing a channel ends whatever is
+on it. Two modules pointed at one channel will talk over each other — give
+them channels of their own.
+
+An alert ends when its **duration** runs out (1 to 600 seconds; 15 when the
+module gives none), or when the module that raised it clears it early, or
+when that module stops (a disable, an uninstall, a config save that re-inits
+it): a module's alerts never outlive it. A module may hold an alert **until
+cleared** (duration 0) for a condition it will notice ending — timecode
+lost, a feed down — and clear it when the condition does.
+
+## Admin → Alerts
+
+The admin page's **Alerts** section (folded by default, near the bottom)
+holds two colour pickers per level — the two colours that level flashes
+between — with a swatch beside each row running that level's cadence, so a
+pair can be judged before it is tried. A change saves when the picker
+closes and reaches every open dashboard at once. The row below sends a
+**test alert** of any level on any channel: eight seconds of whatever the
+dashboards listening to that channel will see.
+
+The colours are kept as `alerts.colors` in the data directory's
+`proddash.json` (see the README's *Where settings are kept*); they hold
+across restarts and updates. The defaults are a blue pair for low, amber
+for medium and red against near-black for critical.
+
+## For module authors
+
+Raise from the server entry, which is where a condition is usually noticed
+— `shell.alert({ channel, level, text, duration })` and
+`shell.clearAlert(channel)` on the `shell` object `init()`, `routes()` and
+`tiles()` receive — or from a tile with `moduleApi.alert(...)` and
+`moduleApi.clearAlert(...)`, which go through the server. The fields, what
+each is for, and the rules that keep alerts worth looking at (raise on the
+transition, make it a setting, it is not a status) are in the
+[Module Guide](MODULE-GUIDE.md#raising-alerts).
+
+## The HTTP API
+
+Everything above rides on three public routes and two admin ones. They are
+open to anything that can reach ProdDash, like a module's own routes:
+an alert is a flash on screens in this building and nothing more.
+
+| Route | Does |
+| --- | --- |
+| `GET /api/alerts` | `{ channels: 6, levels, colors: { low: [a, b], … }, active: [ … ] }` — what is flashing and the colours. Dashboards read it on load and whenever their stream reconnects. |
+| `POST /api/alerts` | `{ channel, level, text, duration?, source? }` as `application/json`. Answers `200 { ok, alert }` or `400 { error }` saying what was wrong. `source` is the module id (anything else is recorded as `api`). |
+| `DELETE /api/alerts/<channel>` | Ends the alert on that channel. `{ ok, cleared }` — `cleared` is false when nothing was on it. |
+| `POST /api/admin/alerts` | `{ colors: { low: [a, b], medium: [a, b], critical: [a, b] } }` — a missing or malformed colour takes its default. Behind the admin PIN. |
+| `POST /api/admin/alerts/test` | `{ level, channel }` — an eight-second test alert. Behind the admin PIN. |
+
+Open dashboards learn of changes over the shell stream (`/api/events`):
+`alert` carries an alert as raised (`{ id, channel, level, text, source,
+startedAt, duration, endsAt, remainingMs }` — a browser counts down from
+`remainingMs`, so the clocks need not agree), `alert-clear` carries
+`{ channel, id }` when one ends, and `alerts-config` carries `{ colors }`
+when the admin changes them.
+
+## Trying it
+
+With ProdDash running, from the repo:
+
+```bash
+node tools/alert.js -c 1 -l critical "LTC lost"
+```
+
+raises a critical alert on channel 1 for the default 15 seconds; `-d 0`
+holds it, `node tools/alert.js -c 1 --clear` ends it, `--list` shows what
+is on. Open a dashboard, choose channel 1 in its Layouts menu → Alerts, and
+watch; a second browser listening to channel 2 should stay quiet. The admin
+page's **Test** buttons do the same from the browser.
+`node tools/alerts.test.js` runs the server's side of all this end to end.

docs/MODULE-GUIDE.md

@@ -437,6 +437,8 @@ export default function create({ root, moduleApi }) {
 | `fetch(path, opts)` | `fetch` scoped to your server routes: `fetch('/state')` hits `/api/modules/<id>/state`. |
 | `sse(path, handlers)` | An `EventSource` scoped the same way, **with auto-reconnect** (see below). Returns a handle with `close()`. |
 | `setStatus(state, msg)` | Drives the tile's status dot: `'ok'`, `'connecting'` or `'error'`, plus a hover message. Call it honestly — during a live service the dot is how an operator spots a dead feed. |
+| `alert(opts)` | Flash every dashboard listening to an alert channel — `{ channel, level, text, duration }`, see **Raising alerts**. Returns a promise. A module with a server entry raises from there (`shell.alert`) instead. |
+| `clearAlert(channel)` | End the alert on a channel early. Returns a promise. |
 | `header.addButton(…)` | Put a small button in the tile's own title bar (see below). |
 | `header.addMenu(…)` | Put a dropdown menu button there (see below). |
 
@@ -600,6 +602,9 @@ module.exports = {
 - `shell.port` is the port ProdDash is serving on — what you need to read
   another module's routes over loopback (`http://127.0.0.1:${shell.port}/api/
   modules/<id>/…`). Never guess it.
+- `shell.alert(opts)` flashes every dashboard listening to an alert channel
+  and `shell.clearAlert(channel)` ends one early — see **Raising alerts**.
+  Alerts your module raised end when it stops.
 - Handlers get plain Node `(req, res)`. On a prefix route, `req.wildcard` is
   the matched remainder (leading `/` included) and `req.search` is the query
   string (with `?`, or `''`) — so a proxy rebuilds the upstream path as
@@ -704,6 +709,72 @@ per-client `res.write` in try/catch (drop the client on failure). The
 `propresenter-now-next` module is the reference implementation of this
 pattern.
 
+## Raising alerts
+
+An alert is for the thing a tech must act on *now*, whichever tile they
+happen to be looking at — a timer that has overrun, a meter past its limit,
+timecode that has gone quiet mid-service. Every dashboard that listens to
+the alert's channel flashes: its menu bar (brought out for the duration,
+even if it was hidden) and a frame round the whole screen alternate between
+the level's two colours, with your text bold across the middle of the bar.
+The shell owns all of that — the colours (Admin → Alerts), the cadence,
+which screens listen (each dashboard's Layouts menu → Alerts) — so a module
+only has to say what happened. [docs/ALERTS.md](ALERTS.md) has the
+operator's side.
+
+Raise one from your server entry, where the condition is usually noticed:
+
+```js
+init({ config, log, shell }) {
+  // …when timecode drops:
+  shell.alert({ channel: config.alertChannel, level: 'critical', text: 'LTC lost', duration: 0 });
+  // …and when it is back:
+  shell.clearAlert(config.alertChannel);
+}
+```
+
+or from a tile, through the shell's server:
+
+```js
+await moduleApi.alert({ channel: 2, level: 'medium', text: 'Service over by 5:00', duration: 20 });
+```
+
+| Field | Meaning |
+| --- | --- |
+| `channel` | `1`–`6`. Which dashboards flash: each listens to the channels its operator chose in the Layouts menu. A channel carries no meaning of its own — the booth decides that "1 is the stage, 2 is video" — so **make yours an admin setting** (`configSchema`, `type: "number"`, `min: 1`, `max: 6`) rather than hard-coding one. |
+| `level` | `low` — a slow fade between the two colours, for something to know about; `medium` — a quicker pulse, for something to deal with soon; `critical` — no fade, the colours snap, and the board behind the tiles floods with a muted cut of them too, for something to deal with now. |
+| `text` | What happened, in a few words — 80 characters at most (more is cut, whitespace is collapsed). It is shown as given, so write it the way it should read on a wall: `SPL 102 dB — over limit`, not `spl_over_limit`. |
+| `duration` | Seconds, 1 to 600; `15` when omitted. `0` holds the alert until you clear it — for a condition you will *notice ending* (timecode lost, a feed down) and clear; a one-off event takes a duration. |
+
+Both return the alert as raised (`{ id, channel, level, text, source,
+startedAt, duration, endsAt, remainingMs }`) and throw — reject, on the
+client — with a one-line reason when the input is refused. That is a bug
+in your module, not something to show the operator.
+
+What to know:
+
+- **One alert per channel.** A new alert on a channel replaces whatever was
+  on it, whoever raised it; `clearAlert(channel)` ends whatever is on it.
+  Two modules on one channel talk over each other — one more reason the
+  channel is admin config.
+- **Your alerts end when you stop.** A disable, an uninstall or a config
+  save that re-inits you clears every alert your module raised, held ones
+  included. If the condition is still true, raise it again from `init()`.
+- **Raise on the transition, not the state.** `if (over && !wasOver)
+  shell.alert(…)` — an alert re-raised on every poll restarts its timer and
+  flashes for ever. Clear it, or let it expire, when the condition ends.
+- **Make alerting a setting**, and the threshold too: a `switch` in
+  `configSchema`, off by default unless alerting is the module's reason to
+  exist. A screen that flashes for nothing teaches a room to ignore it.
+- **It is not a status.** The tile's dot (`setStatus`) says how *you* are;
+  an alert says what the *room* must do. An unreachable upstream turns the
+  dot red; it raises an alert only if that is something a tech has to act on
+  during the service, and the operator switched that on.
+- Alerts reach the server over `POST /api/alerts` — what `moduleApi.alert`
+  calls, with your module id as `source` — which anything on the network may
+  use too; `node tools/alert.js -c 1 -l critical "LTC lost"` raises one from
+  the command line while you build (`--clear`, `--list`).
+
 ## Working with other modules
 
 Modules don't import each other. When one needs what another knows, it reads
@@ -961,6 +1032,10 @@ client-side failures (a tile that fails to start says so in the tile).
 - `GET /api/modules/<id>/...` — your routes, `curl`-able. For SSE:
   `curl -N http://localhost:24500/api/modules/<id>/stream`.
 - `GET /api/admin/state` — enabled flags, health, mount errors.
+- `GET /api/alerts` — what is flashing, and the colours. `node tools/alert.js
+  -c 1 -l critical "LTC lost"` raises one without a module (`--clear`,
+  `--list`); a dashboard shows it once channel 1 is chosen in its Layouts
+  menu → Alerts.
 
 **Mock upstreams** (so you can develop without the real gear):