Skip to content
docsv0.24.0

AppDoctor

Explica el estado arquitectónico de una app SIN arrancarla. ── POR QUÉ SIN ARRANCARLA ────────────────────────────────────────────────────────────────────── Porque el caso que más falta hace es justo aquel en el que la app no arranca. Medido en una app de ejemplo con una capacidad sin proveedor: `plugins:list`, `validate` y `test` caídas —las quince herramientas del agente— y una sola línea de error como todo el dato disponible. La herramienta que explica por qué algo no arranca no puede necesitar que arranque; si la necesita, la diagnosis muere con el paciente. ── NO CALCULA NADA NUEVO ─────────────────────────────────────────────────────────────────────── El resolver ya produce un reporte completo —qué falta, qué choca, qué se degrada, a qué lección lleva cada error, y qué acciones lo arreglarían— y el arranque conserva de todo eso la primera línea, como mensaje de una excepción. Esto es el mismo cálculo con el reporte entero puesto en las manos de quien pregunta. La mayor parte de lo que a un agente le falta para operar un framework no es capacidad nueva: es que lo que el sistema ya sabe le llegue.

AppDoctor::diagnose()

public function diagnose(array $pluginClasses, ?string $raiz = null): Milpa\DevTools\Doctor\DoctorReport

Diagnostica la app formada por estas clases de plugin. Recibe las clases y no la ruta de un `config/plugins.php` porque de dónde salen es convención del host: este paquete no puede decidir cómo se declara una app sin volverse su dueño.

Parameters

Parameters of diagnose()
NameTypeDescription
$pluginClasseslist<string>tal como el host las declara
$raiz(null | string)la raíz de la app, si se quiere diagnosticar TAMBIÉN su `hostProfile` y lo que sus paquetes instalados proveen. Sin ella se diagnostica sólo el grafo de plugins contra un perfil permisivo — que es lo que hacía siempre, y por eso una app tumbada por una `requiredCapabilities` sin proveedor salía con «nada que recomendar»