Community dependency helper and package roadmap

Rullst (v12 and the v13 prerelease line) does not define a runtime RullstPackage plugin ABI, execute third-party generators, discover a private package registry, or register routes automatically. Community integrations are ordinary Rust crates selected through Cargo and reviewed like any other dependency.

Current cargo rullst pkg boundary

The CLI provides two small local manifest helpers:

cargo rullst pkg add rullst-auth
cargo rullst pkg list
cargo check

pkg add:

• accepts only ASCII Cargo names of at most 64 bytes beginning with rullst- or rullst_ and ending in an alphanumeric character;
• parses Cargo.toml as TOML and inserts the dependency into the real [dependencies] table using the installed CLI’s version (an exact = requirement for a prerelease such as =13.0.0-alpha.4); in a virtual workspace manifest ([workspace] without [package]), which cannot declare [dependencies], it uses [workspace.dependencies] instead, and members opt in with rullst-auth = { workspace = true };
• leaves an existing dependency and its features/version unchanged;
• does not contact a registry, execute code, edit routes, or run a scaffold.

The subsequent cargo check performs normal Cargo resolution and compilation. A prefix is only a naming filter; it is not proof that a crate is official, safe, compatible, maintained, or endorsed by Rullst. Review the crate source, publisher, checksum, license, advisories, feature graph and release policy before adding it.

pkg list reads dependency keys from that same table and prints those with the same Rullst prefix (--json prints them as versioned rullst.cli-pkg.v1 JSON). It is not a vulnerability, license or provenance scan; use the repository’s audit and dependency-policy tooling for those questions.

Integrating a community crate today

A community crate can expose ordinary Axum routers, Tower layers, SQLx types or constructors. The host application initializes it explicitly and mounts only the capabilities it intends to trust:

#![allow(unused)]
fn main() {
use axum::Router;

fn community_router() -> Router { Router::new() }
fn application_router() -> Router {
    Router::new().nest("/community", community_router())
}
}

Authentication, authorization, tenant policy, secrets, migrations, shutdown, telemetry and failure handling remain visible application responsibilities.

Future package protocol

A first-class extension protocol remains roadmap work; the v13 source does not include one. It should not be declared stable until the repository has all of the following:

• a versioned manifest and compatibility contract;
• explicit capability permissions for routes, storage, network and secrets;
• deterministic lifecycle and failure semantics without runtime reflection;
• package ownership, provenance and revocation policy;
• compile/runtime conformance tests and safe uninstall/upgrade behavior;
• a decision on whether untrusted extensions require a real Wasm sandbox with enforceable CPU, memory and I/O limits.

Until that contract exists, documentation and packages must not claim that RullstPackage.toml, RullstPackage, automatic route registration, or third-party generator execution are implemented APIs. See the capability ledger and the roadmap for the preserved vision.