PluginsManagerBootStrategy

Delegates the kernel's plugin phase to a host-grade plugins manager (milpa/plugin's `PluginsManager` or any {@see PluginsManagerInterface}): registry-driven activation, resolver gate, two-layer caches, environment-gated tool registration and `EventSubscriberInterface` auto-subscription all happen INSIDE the manager — this strategy never re-implements them (Ola 7 D1). Routes are intentionally NOT collected here: a host on this strategy assembles its route table outside the kernel (attribute scanning is a host concern), so {@see PluginBootResult::$routes} stays empty and the kernel's router boots empty. Commands ARE collected, exactly as {@see InlinePluginBootStrategy} collects them. That sentence used to read "routes and commands", and the exclusion of commands rode in on the conjunction: the reason given —attribute scanning belongs to the host— is true of routes and of nothing else. A route is DISCOVERED by scanning; an operation is DECLARED by a plugin that already booted, and there is nothing left for a host to decide about it. The cost of the silent half of that sentence was measurable: `milpa/plugin` shipped seven plugin-management operations that no host on this strategy could ever see.

public function __construct(Milpa\Interfaces\Plugin\PluginsManagerInterface $manager, string $pluginsPath):

Parameters

public function bootPlugins(Milpa\Runtime\Boot\BootContext $context): Milpa\Runtime\Boot\PluginBootResult

Hands the plugin phase to the manager and collects the operations the booted plugins declare. The manager decides WHAT boots — registry, resolver gate, caches, environment gating; this method never second-guesses it. What it does afterwards is read: every booted plugin that declares commands or operations contributes them to the kernel's command table.

Parameters