Salta ai contenuti

La CLI a colpo d'occhio

La CLI microlab offre dal terminale tutto ciò che un utente può fare nell’app desktop: gestire il catalogo (micro, scenari, mock, impostazioni), avviare e fermare scenari, osservare stato e log, e importare/esportare. UI e CLI condividono lo stesso motore tramite il registro di operazioni, quindi non divergono.

La CLI ha bisogno del motore compilato (npm run build:electron).

Ventana de terminal
node bin/microlab.js <comando> # diretto
npm run cli -- <comando> # via npm (nota il separatore --)
microlab <comando> # se hai registrato il globale con npm link
FlagEffetto
--jsonOutput JSON su una riga, per gli script. Gli errori escono su stderr come {"error": "..."}.
-p, --project <percorso>Radice del progetto MicroLab (la cartella con .microlab/).
-V, --versionVersione.
-h, --helpAiuto (tutti i sottocomandi ce l’hanno).
CodiceSignificato
0Successo.
1Errore di esecuzione (l’operazione è fallita).
2Errore d’uso (comando/flag non validi).
3Il comando richiede un motore attivo e non c’è.
4Timeout (per esempio in attesa che i micro siano healthy).
5Richiede un piano a pagamento che l’account non ha.

Se il progetto configura l’accesso, la CLI (capacità cli), il MCP (mcp) e il copilota (chat) sono a pagamento e indipendenti. L’entitlement si ottiene accedendo all’app almeno una volta. Nei progetti senza accesso, la CLI non ha restrizioni. Vedi Capacità.

I micro sono processi figli del motore, quindi qualcosa deve restare attivo dopo microlab start. La CLI risolve ogni comando così:

  1. Se c’è un motore attivo (l’app aperta o il daemon headless che la CLI stessa avvia), il comando si esegue contro di lui via HTTP: la CLI vede e governa lo stesso stato dell’UI.
  2. Se non c’è, le operazioni senza stato (catalogo, mock su disco, impostazioni, pacchetti) si eseguono in-proc su .microlab/. Quelle che esigono uno stato attivo falliscono con exit 3.

microlab start avvia il daemon automaticamente se serve; microlab daemon stop lo spegne.