ActivationSafetyInterface

Contesta si una MUTACIÓN del grafo de plugins —apagar uno, o encender/registrar uno nuevo— dejaría a este host sin poder arrancar. Las dos direcciones porque el invariante es uno solo: el grafo nunca se deja ABIERTO por una mutación (greenhouse decisions/0178). Apagar quita un proveedor; agregar trae un `requires` — ambos pueden abrir el grafo, y ambos se juzgan aquí ANTES de commitear, no en el arranque. ── POR QUÉ EXISTE ────────────────────────────────────────────────────────────────────────────── Porque apagar puede ser irreversible EN LA PRÁCTICA aunque no lo sea en la teoría. Si el perfil del host requiere una capacidad que sólo ese plugin provee, el resolver bloquea el siguiente arranque — correctamente, un grafo abierto no debe arrancar— y a partir de ahí `plugins.enable` tampoco corre, porque necesita que el host arranque. Quien lo apagó se queda sin la herramienta con que lo encendería. Pasó de verdad, probando otra cosa: apagar un plugin dejó un host inarrancable y hubo que reencenderlo escribiendo directo en su base de datos. No es un caso hipotético ni raro — es lo que pasa la primera vez que alguien apaga el plugin equivocado. ── POR QUÉ ES UN CONTRATO Y NO UNA COMPROBACIÓN DIRECTA ──────────────────────────────────────── Sólo el host sabe qué perfil tiene que satisfacer. Un paquete que resolviera el grafo por su cuenta tendría que adivinar ese perfil, y un perfil inventado bloquearía arranques que hoy funcionan o dejaría pasar los que no. Así que se pregunta a quien sí sabe, y si nadie contesta —un host que no declara perfil— la operación sigue como antes: no saber no autoriza a inventar.

abstract public function blockingReasonWithout(string $pluginName): ?string

El motivo por el que apagar `$pluginName` dejaría el grafo bloqueado, o `null` si no lo haría. Devuelve el MOTIVO y no un booleano a propósito: quien recibe la negativa necesita saber qué capacidad se quedaría sin proveedor para decidir qué instalar antes. Un `false` lo obliga a ir a buscarlo, y la información ya estaba aquí.

Parameters

abstract public function blockingReasonWith(string $newPluginClass): ?string

El motivo por el que AGREGAR `$newPluginClass` al grafo lo dejaría bloqueado, o `null` si cerraría. La otra mitad de {@see self::blockingReasonWithout()}: registrar/encender un plugin trae sus `requires`, y si ninguno de los plugins que el próximo arranque cargaría —más este— provee una de esas capacidades, el grafo queda ABIERTO y el host deja de arrancar. Se juzga aquí, antes de tocar `config/plugins.php`, para que la incoherencia se atrape en el gate y no en el siguiente boot (greenhouse decisions/0178). Devuelve el MOTIVO —qué capacidad se quedaría sin proveedor— por la misma razón que su simétrico: quien recibe la negativa necesita saber qué proveedor instalar antes. Falla cerrado: si no se puede leer la metadata del plugin o resolver el grafo, contesta con un motivo bloqueante en vez de `null` — no poder comprobar no es haber comprobado.

Parameters