Useful additions.
A narrow trust boundary.

Local recipe boundary

Declarative JSON only

Community contributions may propose server identity, supported platforms, fixed install sources, executable and argument fields, ports, persistent paths, backup coverage, and IDs for capabilities already implemented by Server Rock.

Unknown behavior-bearing fields, unsafe paths, symlinks, shell snippets, arbitrary package commands, Python, and lifecycle hooks are rejected. A manifest may select an existing reviewed adapter; it cannot add a new executable adapter.

Support status

Importable is not verified

Imported or locally maintained recipes must be labeled as community content until their host fit, lifecycle, network exposure, backup and restore behavior, and update path have been checked. The catalog and its validator check metadata and adapter compatibility only; they do not certify every host or game version.

Game binaries, mods, assets, and provider services keep their own terms. Read the third-party notices before distributing those materials.

What a future plugin API would require

Plugins would run as separate processes behind a documented, versioned local API. Each plugin would receive an explicitly selected profile and a small capability set, such as reading status, requesting a lifecycle action, or returning a settings form.

Credentials would stay out of plugin configuration. Short-lived, scoped capabilities would travel over an authenticated local channel, with timeouts, payload limits, action logging, disable controls, and clean removal.

Privileged work remains reviewed

Network access, host changes, root-level installation, and arbitrary host commands require operator approval and a separately reviewed workflow. They are not silently granted by a recipe or plugin package.

Publisher signatures and immutable artifact verification are not available in the current extension-manifest validator. They must be implemented and verified before a public extension index describes signature checks as available.

1. Keep recipe manifests and future plugin code in a separate community repository or clearly separated directory with a published schema and compatibility policy.
2. Choose and state a license for each contribution type. Preserve attribution and required notices; a pull request does not grant permission to relicense a contribution as proprietary controller code.
3. Disclose original work, copied upstream material, dependencies, and licenses. Decline submissions whose provenance cannot be established.

4. Validate each package before import or distribution and show publisher, version, requested capabilities, source, compatibility, and verification status.
5. Keep official support distinct from community availability.
6. For a public index, publish immutable artifacts with hashes and verify publisher signatures before installation. Do not promise this check until it exists.

Local recipe pack

Contributors can add declarative manifests that select shipped capabilities. Server Rock retains the controller source, adapter implementations, and privileged workflows.

Community plugin (future)

A separately licensed executable could use a documented external API. Server Rock retains the controller process, credentials, update-signing keys, and host privilege broker.

Official catalog

Reviewed recipe data and verified compatibility claims can ship in a signed Server Rock release. That does not certify third-party game binaries, mods, or provider services.