First-party plugin architecture

First-party integrations are ordinary Rust crates built independently from the Stackie host. A package exports a semantic descriptor and implements FirstPartyPlugin. The descriptor declares compatibility, entitlement, platforms, contributions, owned namespaces, and narrow host capabilities. Build inclusion does not grant runtime subscription entitlement.

Multiple plugins may deliberately share one product module, or each may declare a different catalog-backed module for separate subscription tiers. Unknown module strings fail closed; a plugin descriptor cannot invent a paid feature. Changing a plugin’s tier therefore changes catalog policy and its descriptor, not host-side integration logic.

This contract is for trusted, statically linked first-party Rust code. A capability lease prevents new host-mediated operations after revocation; it is not an in-process security sandbox and cannot erase a filesystem path or immutable configuration value already returned to plugin memory. First-party plugins must stop direct I/O when revoked. Untrusted or dynamically loaded plugins require a future out-of-process boundary with brokered filesystem operations rather than this API.

Stackie Cloud issues short-lived Ed25519-signed entitlement snapshots bound to the current organization, user, authenticated CLI device token, catalog version, and exact package-capability manifest. Released daemons accept only embedded allowlisted public keys. Authentication loss, expiry, signature or binding mismatch, and revocation fail closed. The host revokes activation capability leases before stopping affected plugins; persistent data is preserved.

Plugin activation receives an immutable PluginPackageContext bound to the descriptor identity. Unsupported packages can still compile and report typed platform availability without starting a fallback implementation.