Building and Activating Plugins

The Plugin Activation Gate is a Brain service. It decides if a plugin can run. It checks validation results, capabilities, host settings, and policies. Blocked plugins stay installed but do not run. Activation allows invocation under runtime rules. It does not allow direct changes to authoritative state. The service only uses resolved administrative or governance decisions. It never makes new decisions. It preserves plugin configuration. It does not remove or alter installed plugins unless policy says otherwise. Normal unload stops new work, lets the plugin finish work already admitted to it, and waits until its independent outputs have crossed framework boundaries.

Example: A plugin may remain installed after Brain blocks activation, and installation alone does not allow it to change authoritative state.

The proposed Shadow Plugin Validation service describes how participating game servers could safely test new plugin versions using real gameplay data before release. Server owners would have to opt in explicitly to beta testing.

Before distribution, plugins would be scanned for malware and run under strict restrictions that prevent them from changing gameplay, server state, or external systems. The service would check whether each plugin behaves as declared and whether its changes match the expected update.

This design could give independent plugin developers realistic testing conditions, helping them find and fix problems before releasing a new version.

Returned test data would be stripped of information that could identify individual players or participating servers.

The Plugin Compilation Pipeline is the Brain service that validates and prepares plugin code before activation. It only handles validation and preparation. It does not run gameplay logic in the hot path. It cannot let unsafe code bypass framework rules. It creates runtime descriptors and diagnostics. The pipeline does not change anything in the live game. It validates plugin material and prepares for safe execution. It produces evidence, rejection diagnostics, and lowered descriptors for activation and execution. It does not execute plugin gameplay logic in the hot path. It does not let signatures, source layout, or generated code bypass mandatory framework safety rules.

This service controls what external systems plugins can talk to. It validates each request, limits resource use, and records outcomes. Unknown routes are rejected instead of granted. This keeps the system secure and stable.

A runtime artifact is a compiled and validated plugin. It shows what the plugin can do and how it is checked for safety. The artifact does not define storage or build methods. It only gives identity, entry points, capabilities, and validation evidence. This contract helps systems understand plugin limits and permissions. It does not create new authority owners.

This optional developer tool prepares a small but deliberately varied set of isolated tests instead of trying every possible combination. When a test fails reliably, it can remove unrelated inputs until it finds a much smaller example that still causes the same failure.

For example, a failure involving many plugins and thousands of events might be reduced to two plugin versions, one delayed reply, and two events in a particular order. The minimized case can then become a permanent regression test. The tool runs only when a developer, administrator, or internal qualification campaign explicitly starts it; it is not a production background service.