Building and Activating Plugins

ADK is intended to include web services, workers, administration tools, connectors, and other programs that can run outside the main game server. Those programs depend on operating systems, runtimes, libraries, and signing keys that will change and occasionally develop security problems.

Each deployable service therefore carries a maintenance profile. It records what the service was built from, which security notices affect it, how quickly important fixes should be considered, what must be retested after a change, and which known-safe version can be restored if an update goes badly.

For example, if a web library used by Kestrel receives a serious security warning, ADK can identify the affected builds, prepare and test a replacement, notify the administrator, and retain a safe rollback. It does not pretend that every update is harmless, nor does it seize an offline server because its owner chose to remain offline. The owner keeps that choice and the corresponding responsibility.

ADK normally checks plugin requests carefully every time they run. If one exact operation has repeatedly passed the same tests, and measurements show that some repeated checks have a real performance cost, ADK may prepare a shorter route that omits only those named checks.

This is never a blanket trusted plugin switch. The permission applies to one operation in one exact plugin build and environment. For example, a compiled operation may stop rechecking a unit conversion that the compiler has already proven, while authority, isolation, credentials, destructive actions, resource limits, and host safety remain protected. A changed dependency, configuration, game build, anomaly, or expired proof returns the operation to its ordinary guarded route automatically.

The Plugin Activation Gate is a Brain service that decides whether 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. 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 checks and prepares plugin code before activation. It produces the information ADK needs to load the plugin, along with clear evidence when a plugin passes or an explanation when it is rejected.

The pipeline does not run gameplay logic or change the live game. Signatures, source layout, and generated code must all pass the same framework safety rules; none of them can provide a shortcut around those checks.

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 the checked, compiled form of a plugin that ADK can load. It identifies the plugin, the parts that may run, the capabilities it has been granted, and the evidence that it passed validation.

This package does not decide how data is stored or how the plugin is built. It gives the rest of ADK one clear description of what the compiled plugin is and what it is permitted to do.

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 removes unrelated inputs until it finds a much smaller example that still causes the same failure.

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

It can also measure what ADK's protections actually cost. The same workload can run with the complete safety profile, with one protection removed at a time, and against a stripped-down test-only baseline that keeps only the non-negotiable rules required to protect the computer and test environment. This shows whether a safeguard costs almost nothing, needs optimization, or adds more complexity than its benefit justifies. The stripped version can never become a live-server plugin.