Skip to content
docsv0.34.0

PluginsComponent

The Plugins section as a Milpa Component: its state is the plugins table and the capability catalogue. Read-only in this slice — it declares no actions, so any interaction is refused by contract. Toggling and installing are governed operations (`plugins.enable`, `capabilities:enable`) and enter as actions when their slice lands, not as buttons wired around them.

PluginsComponent::__construct()

public function __construct(Milpa\Admin\Data\PluginsSource $source):

Parameters

Parameters of __construct()
NameTypeDescription
$sourceMilpa\Admin\Data\PluginsSource

PluginsComponent::contract()

public static function contract(): Milpa\Live\ValueObjects\ComponentContract

The contract: no props, a read-only state, and ONE action that is a button for an operation. This section showed the capability catalogue and could not enable anything — the panel could look and not install, so an app that declines the agent could see what it might grow and had no way to grow it. `enable` does NOT carry an effect profile, and that is the design: it names `capabilities:enable`, which already declares that it downloads third-party code, that its authority is privileged and that its reversibility is manual recovery. A copy here would be a second source of truth about one act, and the gate reads the operation's — so the copy could only ever be the wrong one (greenhouse decisions/0220).

PluginsComponent::mount()

public function mount(array $props, Milpa\Live\ValueObjects\ComponentContext $context): Milpa\Live\ValueObjects\StateSnapshot

Mounts with the current snapshot of the plugin registry and the declared list.

Parameters

Parameters of mount()
NameTypeDescription
$propsarray
$contextMilpa\Live\ValueObjects\ComponentContext

PluginsComponent::handle()

public function handle(Milpa\Live\ValueObjects\InteractionRequest $request): Milpa\Live\ValueObjects\InteractionResult

The section does not RUN the operation, and that is not a limitation — it is the seam. `capabilities:enable` is governed: over HTTP it answers `428` with a confirmation token before it does anything, and only a second request carrying that token proceeds. A component that called the handler would step around the very ceremony the panel exists to present. So the action is DECLARED here — so the catalogue, the renderer and any gate can see what this button is — and the act itself travels the operation's own surface. Anything else is still refused, by name.

Parameters

Parameters of handle()
NameTypeDescription
$requestMilpa\Live\ValueObjects\InteractionRequest