Plugin Governance and Release Confidence
These notes explain what a plugin must declare about its data, permissions, deployment effects, maturity, and security evidence.
The declarations make review possible before installation and again before an update becomes active. Server owners can see what changed, what the plugin may access, and how much confidence the available testing actually supports.
Plugin Capabilities and Fallbacks
Plugins describe which framework capabilities they require, prefer, or can optionally use. ADK can derive much of this from the typed functions and schemas the plugin actually uses, then asks the developer only about meaning that cannot be inferred safely.
For example, an event may require inventory transfer, prefer precise lighting, and optionally use positional audio. If precise lighting is unavailable, the plugin can use a declared simpler presentation without gaining direct access to the game renderer.
Plugin Data Requirements
Plugins must declare all data they collect, store, expose, transmit, display, retain, erase, and share. The declaration gives framework, admins, Kestrel surfaces, privacy policies, and ADC features a clear source of truth. Missing or invalid declarations can limit activation, disable persistence, block ADC sharing, restrict Kestrel surfaces, or force local-only mode. This ensures framework authority over privacy, persistence, egress, disclosure, and runtime enforcement. The manifest is not just documentation. It enforces compliance.
Plugin Impact on Server Behavior
Plugins must describe how they change gameplay, players, server settings, and other systems. This helps admins decide if a plugin is safe to use. It also shows what changes might happen on their server.
Helping A Plugin Ecosystem Stay Healthy
ADK is designed to track dependency pressure, compatibility, security findings, update health, and signs that an important plugin may no longer be maintained. Administrators and developers could see the evidence and likely consequences before a neglected dependency becomes a wipe-night surprise.
Any intervention would remain proportional and human-reviewed. ADK could warn, contact a maintainer, identify compatible alternatives, or prepare a migration or compatibility plan, but popularity would never bypass safety rules and the framework would not seize third-party code.
Plugin Release Confidence Service
This service checks if a plugin is ready for release. It combines developer claims with independent test results. The system uses this to decide if a plugin can move to public channels. The decision is only advice. Admins control final safety rules.
Plugin Security Analysis Service
This service checks plugin files for security problems. It tells developers, reviewers, and admins what it finds. The findings are facts, not final decisions. They do not replace runtime safety or human review. The service only checks immutable plugin files. It publishes clear results for each file. It does not make runtime decisions. It does not control activation or release choices. It only provides evidence for others to use.
Declared Plugin Measurement
Plugins must describe what they measure, why they measure it, who or what it concerns, where it may go, and how long it may remain. ADK can disable an undeclared analytics path while leaving unrelated plugin gameplay working.
For example, a minigame may report one local round-duration total without receiving permission to upload each player's movement history.
Assemble Plugin Logic From Safe Blocks
This developer tool assembles triggers, queries, rules, and intents from registered visual blocks. It exports the same declarative plugin artifacts that ordinary development tools use, and it can rehearse trigger paths in a sandbox. It is a fast Lego-like scaffold builder, not a replacement for a full programming IDE.