"Nothing is fixed: […] Reuse an existing effect when one fits; create when none does. You decide when to fire, and you need not announce it." — from the effects tool's own description, which the soul reads whole; the cut holds the five actions and the shape of a visual and a sound
Dad's Rules
The idea came from the first broadcast too: while on air, Pippa should play visual and sound effects on the screen the viewers see. Dad's rules for it were short and all about who decides. No hardcoding and no fixed list: she creates an effect when she wants one, keeps it, reuses it, and makes new ones in the middle of a broadcast; creation takes a few seconds, and he edits that out of the video anyway. She decides when to fire, with no rules or quotas on her judgment. Effects exist only on air (and, since the screen without the show, on the On Air screen for him alone: this track's last lesson). And the rendering starts light: particles on a canvas, nothing heavier until use asks for it.
An Effect Is Data
"No fixed list" rules out the obvious design, a menu of effects someone coded. So an effect is data she writes, and one renderer plays any of it. A visual is a particle scene: up to six layers, each with a shape (circle, star, heart, petal, flake, ribbon, spark and a few more, or text, which draws any emoji or letters), colors, where the particles come from, how they move (speed, angle, gravity, wind, drag, spin, wobble), how big they are, how long they live, how they fade and glow; plus an optional flash and an optional caption. A sound is a description and an optional length. The voice engine turns the description into audio through its sound-effects route, because the engine owns the provider for sound exactly as it does for voices, and the file is kept beside the effect library.
The library clamps every number when it saves: at most 400 particles a layer, at most 15 seconds, lifetimes, speeds and sizes inside a sane range, and a text layer refused without its glyph. The model writes freely, and the renderer never meets a number it can't draw. Colors are screened only by their shape (a # with three to eight hex digits, an rgb() or hsl() form, or a color word), so a malformed one such as a five-digit hex is still saved. The canvas skips a color it can't parse and paints that particle with the fill it already had: the effect still plays, just not in the color she meant. A revision regenerates the sound only when its description or length changed, so tuning a color never pays for a new sound.
One Tool, Gated Twice
The effects live behind a single tool, onair_effect, with five actions: list and show read the library, create and update write it, fire plays one. The tool is gated twice, on purpose. The chat routes add it to a turn's tool list only when that turn is sent from the On Air screen, with the show or without it, and take it off any other; it is marked turn-gated, so an "every tool" expansion never includes it. And the tool itself refuses unless Dad's latest turn in the conversation was sent that way, reading the record, not the request. A stray tool list therefore can't fire an effect into an ordinary chat.
The first version had a gap that only a second client could show. Firekeeper and the phone send no tool list at all, which means "the vessel's default surface". The helper that added the effect tool to a turn's list had nothing to add it to, so on those doors the tool never reached her, and Firekeeper's new effects overlay could never receive a fire. Now an on-air turn without a list first expands the default surface (turn-gated tools left out, the shell only where it's enabled), the same way a sidekick's expansion does, and then adds the effect tool.
The Screen Plays the Tool Call
There is no separate channel for effects. A fire reaches the screen as the tool call itself, streamed like every tool use. The voice screen reads the fires in replies since the On Air screen came up (a baseline taken when the switch lit up, so older fires are history and never replay), fetches the effect by id, plays the scene with the one generic particle renderer on a full-screen canvas, and plays its sound. A reply loaded back from storage can carry its tool input as a Python-style repr rather than JSON, so the reader parses JSON first and otherwise reads the action and the id directly; the kit's native reader does the same.
Two more rules keep effects from fighting the talk. An effect's sound is not Dad cutting in: while any effect sound is playing, the barge-in detector from Track 7 skips its decision, or an applause would silence her. And a fire waits for the line that announces it: the fire streams to the screen before the tool has even run, while "hang on, a little applause for that" may still be playing, so the engine's speech gate from Track 3 holds the tool, and the screen holds the picture and the sound, until her reading is quiet. The engine gate's limits come along: at most 12 seconds, and no wait at all for a client that never reported or a report gone stale. The screens hold with the same 12-second ceiling, and the web and Firekeeper both count it for each fire from that fire's own arrival, so a quick second effect never stretches the first one's wait.
Where Effects Play
The WebUI and Firekeeper play them, Firekeeper in a click-through overlay across the whole screen its panel sits on. The phone doesn't yet. Her library grows the way Dad wanted: every effect she makes is kept, found again by words in its name, description or tags, and fired again when it fits.