Mediabot can now isolate one unruly plugin resource without closing the whole spellbook.

MB752 adds a deliberately manual, exact and reversible quarantine layer to Mediabot’s API v3 plugin platform. When one command, event, shared job or HTTP callback misbehaves, an Owner can contain that single resource on one channel while the rest of the package—and every unrelated channel—keeps running normally.

One faulty spell, one precise ward 🎯

Earlier milestones gave the API v3 runtime a diagnostic lantern and a bounded memory of failures. MB752 turns that operational evidence into a safe human decision point. A quarantine entry identifies an exact tuple: the resource kind, its manifest-declared name and the target channel. Channel matching follows IRC’s RFC1459 casemapping rules.

This is not a disguised global kill switch. Quarantining hello-v3 / command / v3hello / #test does not disable the package, silence another command or affect another channel. The registry belongs to the currently loaded plugin instance, is bounded to 64 entries and accepts only declared resources. Set and release operations are idempotent, so repeating an operator command cannot multiply or corrupt state.

Containment also covers work already in flight 🕸️

The important part is not merely storing a quarantine flag. Mediabot enforces the ward before new plugin work begins and checks it again at the boundaries where deferred work could otherwise escape: event and job dispatch, command and job output, and HTTP completion callbacks. A late operator decision can therefore contain queued or in-flight activity before it reaches IRC or re-enters plugin code.

The four supported resource kinds are command, event, job and http_callback. Quarantine survives a disable/enable cycle of the same loaded instance; unloading and reloading deliberately creates a fresh instance and drops the in-memory registry.

Evidence and action remain separate 🧠⚖️

MB751’s failure ledger records bounded operational evidence. MB752 does not turn that evidence into automatic punishment. No exception count, failure streak or threshold can quarantine a resource by itself. Only an authenticated Owner may add or remove an entry.

Releasing a resource also leaves its failure history untouched. That separation matters: the Pensieve keeps the facts, while the operator decides whether to raise or lower the ward. There is no bulk reset, durable quarantine, automatic restart or global disable hidden behind the feature.

Partyline operations 🕯️

The mutation commands are Owner-only and target one exact resource:

.plugins quarantine hello-v3 command v3hello #test
.plugins unquarantine hello-v3 command v3hello #test

Bounded, detached views remain available for diagnosis:

.plugins quarantines hello-v3
.plugins doctor hello-v3
.plugins failures hello-v3
.plugins why hello-v3 #test

The quarantine view renders at most ten entries from the 64-entry registry. The doctor reports an otherwise operational package as limited (quarantined_resources), without exposing exceptions, secrets, configuration values, database handles or live plugin objects.

A live trial in the Great Hall 🦉

The final pilot used an ephemeral Owner account over Partyline and an ephemeral IRC client connected directly to teuk.org:6667—no ZNC and no manual intervention. The #v3hello command was exercised on #test before quarantine, during quarantine and after release.

• Before quarantine, the command call counter increased normally.
• With the exact command/channel tuple quarantined, four seconds of silence were observed and the counter did not move.
• The ward remained active across a disable/enable cycle.
• After exact release, the command executed again.
• The separate failure history remained unchanged.
• The plugin, policy, quarantine entry and ephemeral Owner were all removed after the pilot.
• The development service and source tree remained unchanged throughout.

Sealed by the test chamber 🧪✅

• 19,948 / 19,948 tests passed
• 982 / 982 test files passed
• 24 files in the exact commit scope
• No service restart during the final gate

The complete suite ran once, immediately before commit, with visible progress. The staged digest was identical before and after the suite, the running service kept the same PID and restart count, and the repository finished clean and synchronized with origin/master.

MB752 changes no private configuration, database data or schema. It activates no plugin and no channel automatically. The milestone was committed and pushed as b66fbb6a21045b145dc03bbf6d44e2f8d60c7510:

MB752: bind unruly API v3 spells with reversible quarantine wards 🪄🛡️

Why this milestone matters 🏰✨

A plugin platform becomes trustworthy not only when it can load more features, but when operators can understand and contain them without collateral damage. MB750 made decisions explainable. MB751 preserved bounded failure evidence. MB752 completes the operational loop with a precise, reversible human control.

The spellbook stays open. The healthy magic keeps flowing. Only the troublesome incantation waits behind the ward. 🔮

Mediabot v3 development milestone MB752 · 20 September 2026