Plugin lifecycle

Every mutation is a revisioned command carrying a unique command_id and expected_revision. An exact replay returns the recorded result. A stale revision fails before mutation.
| Command | Effect |
|---|---|
install |
Resolve, verify, and store an exact image digest disabled |
update |
Verify a new immutable artifact and reconcile replacement |
enable |
Approve desired availability; on-demand may remain stopped |
disable |
Remove runtime demand and reconcile teardown |
pin / unpin |
Add or remove administrative keep-running demand |
uninstall |
Remove installation while retaining private data |
purge_data |
Explicitly delete retained plugin-private data |
reset_quarantine |
Clear operator-reviewed quarantine state |
Desired and observed state
Section titled “Desired and observed state”Host distinguishes what was requested from what is running. A plugin may be enabled but pending because a required dependency, permission, resource budget, or provider is unavailable. The why view explains active demand and blockers.
Compatible shadow replacement can cut a broker binding over atomically without restarting consumers. Incompatible replacement moves affected consumers to pending until a compatible provider returns.
Quarantine
Section titled “Quarantine”Repeated or policy-significant failure can quarantine a plugin generation. Inspect events and a support bundle before resetting. Reconnecting Click does not itself quarantine plugins; lifecycle state is durable Host authority.