Spark can now do more than publish isolated stories or open structured contribution portals. MB709 introduces its first active ambient action family: a short, contextual Stage Cue that lets Mediabot add a little movement to a channel when the conversation already has genuine momentum.

This is not a timer that throws random messages into quiet rooms. It is a deliberately guarded runtime lane designed to act rarely, naturally, and transparently — with enough defensive layers to disappear instantly when the moment is no longer appropriate.

From observation to action

The new momentum lane watches activity metadata over a bounded window. A Stage Cue candidate can exist only when all reviewed conditions are met:

• Spark is enabled for the channel;
• the dedicated +SparkAction chanset is also enabled;
• at least three distinct humans have recently participated;
• at least six human lines exist in the ten-minute activity window;
• the channel has paused for between 45 and 180 seconds;
• the dedicated action cooldown has expired;
• no game, pending conversational AI response, flood suppression, or active Spark event conflicts with delivery.

The selected action is generated through Mediabot’s provider-neutral AI layer and delivered as one bounded IRC ACTION. Mediabot remains the only actor: it does not impersonate a participant, select a human target, or manufacture participation on anyone’s behalf.

In other words, Spark does not create momentum. It notices momentum, waits for breathing room, and may add one small theatrical gesture when the room can actually carry it. 🎭

Two keys, checked twice 🔐

Active channel behaviour deserves stronger authorization than passive observation. MB709 therefore uses two independent opt-in levels:

1. the channel must have both +Spark and +SparkAction;
2. the process must have both SPARK_SEND_ARMED=1 and SPARK_ACTION_SEND_ARMED=1.

The sample configuration keeps the new action arm disabled by default. Existing installations gain no new public behaviour merely by updating their source or applying the schema migration.

Authorization is also checked late. Runtime state is evaluated before generation and checked again immediately before the sender reaches IRC transport. A candidate is rejected if the bot disconnected, left the channel, entered flood suppression, started a game, began another AI response, lost either chanset, or had its process arm removed in the meantime.

Any fresh public activity also invalidates an in-flight ambient opportunity. Spark would rather miss a cue than walk over a human conversation.

Safe content and private boundaries

The sender accepts only the reviewed Stage Cue structure and constructs the CTCP frame itself. Generated control characters are rejected, reply size remains bounded, and a candidate cannot switch event families between generation and delivery.

Conversation text stays behind the private in-memory generation boundary. Operational logs contain metadata only, using dedicated markers for:

• momentum candidates;
• redacted AI outcomes such as ready, no content, or revoked;
• sender outcomes such as sent or blocked;
• the final delivered ambient event.

This gives operators useful observability without copying channel conversation into diagnostic evidence.

Deployment controls and pacing ⏳

MB709 adds an idempotent database migration for the SparkAction chanset and documents the operational sequence. The reviewed defaults are:

• activity window: 600 seconds;
• minimum humans: 3;
• minimum lines: 6;
• eligible pause: 45–180 seconds;
• action probe interval: 30 seconds;
• action cooldown after delivery: 1,200 seconds.

Ambient delivery is recorded as delivered, not engaged. That distinction matters: an action appearing successfully in a channel is a transport outcome, while genuine human participation remains a separate product signal.

Validation results ✅

The complete MB709 source round passed every required gate:

• targeted Spark, action, VDM, DTC, and compatibility regressions: 649/649;
• fast development lane: 6,591/6,591;
• final full suite: PASS, executed exactly once in 220 seconds;
• dev migration and dedicated pilot opt-in: PASS;
• process configuration and real /proc runtime identity: PASS;
• IRC startup, login, and channel readiness from the application log: PASS;
• fatal runtime gate: zero matches;
• product-reference boundary gate: zero matches;
• source immutability through the full and commit flow: PASS.

The final commit contains exactly 40 files with 1,627 insertions and 68 deletions:

3f97d65 — MB709: give Spark guarded channel actions — Lumos Maxima ✨
VERSION: 3.4dev-20260828_094343

The commit was pushed to origin/master, the upstream state was verified, and the worktree finished clean.

What happens next?

The development pilot proved migration, configuration, startup, and runtime safety, but its network was too quiet to produce a meaningful natural candidate during the observation window. That absence is not being presented as a live product result.

The next step is a deliberately narrow deployment on a more active pilot channel. It will collect real indicators before any wider rollout:

• natural candidate frequency;
• ready, no-content, and revoked generation outcomes;
• sent versus safely blocked actions;
• confirmed deliveries;
• delay between human activity and an eligible cue;
• cooldown behaviour;
• revocations caused by renewed conversation or conflicting runtime activity.

Only that evidence will tell us whether Spark feels present without becoming noisy. The spell is implemented, tested, and guarded; now it has to prove that it understands the room. ✨📜