Ir al contenido

El CLI de un vistazo

El CLI microlab ofrece por terminal todo lo que puede hacer un usuario en la app de escritorio: gestionar el catálogo (micros, escenarios, mocks, ajustes), arrancar y parar escenarios, observar estado y logs, e importar/exportar. UI y CLI comparten el mismo motor a través del registro de operaciones, así que no divergen.

El CLI necesita el motor compilado (npm run build:electron).

Ventana de terminal
node bin/microlab.js <comando> # directo
npm run cli -- <comando> # vía npm (nota el separador --)
microlab <comando> # si registraste el global con npm link
FlagEfecto
--jsonSalida JSON en una línea, para scripts. Los errores salen por stderr como {"error": "..."}.
-p, --project <ruta>Raíz del proyecto MicroLab (la carpeta con .microlab/).
-V, --versionVersión.
-h, --helpAyuda (todos los subcomandos la tienen).
CódigoSignificado
0Éxito.
1Error de ejecución (la operación falló).
2Error de uso (comando/flags inválidos).
3El comando requiere un motor vivo y no lo hay.
4Timeout (por ejemplo esperando a que los micros estén healthy).
5Requiere un plan de pago que la cuenta no tiene.

Si el proyecto configura login, el CLI (capacidad cli), el MCP (mcp) y el copiloto (chat) son de pago e independientes. El entitlement se obtiene iniciando sesión en la app al menos una vez. En proyectos sin login, el CLI no tiene restricciones. Ver Capacidades.

Los micros son procesos hijos del motor, así que algo debe seguir vivo tras microlab start. El CLI resuelve cada comando así:

  1. Si hay un motor vivo (la app abierta o el daemon headless que el propio CLI lanza), el comando se ejecuta contra él por HTTP: el CLI ve y gobierna el mismo estado que la UI.
  2. Si no lo hay, las operaciones sin estado (catálogo, mocks en disco, ajustes, paquetes) se ejecutan in-proc sobre .microlab/. Las que exigen estado vivo fallan con exit 3.

microlab start lanza el daemon automáticamente si hace falta; microlab daemon stop lo apaga.