Ce que la CLI vous offre
Le binaire zero constitue toute la chaîne d'outils de développement. Il n'y a pas de gestionnaire de paquets, de formateur, de linter ou de lanceur de tests séparé — ce sont toutes des sous-commandes de zero. Ça garde la surface petite et prévisible, ce qui est précisément l'objectif.
Un petit menu des commandes que vous toucherez le plus :
| Commande | Ce qu'elle fait |
|---|---|
zero check | Vérifie les types du code source sans produire d'exécutable. |
zero run | Compile et exécute en une étape. |
zero build | Compile vers un exécutable natif. |
zero test | Lance les cibles de test d'un package. |
zero fix | Applique ou prévisualise des plans de réparation structurés. |
zero explain | Consulte l'explication en prose d'un code de diagnostic. |
zero new | Échafaude un nouveau package. |
zero --version | Affiche la version de la chaîne d'outils. |
Chacune d'elles accepte --json pour émettre une sortie lisible par machine au lieu d'un texte formaté pour les humains.
zero check
Le cheval de bataille. zero check exécute les vérifications statiques du compilateur — parsing, vérification des types, inférence des capacités et effets, détection des imports manquants — et s'arrête avant la génération de code. C'est rapide, ce qui compte parce que les agents et les éditeurs l'appellent en permanence.
zero check hello.0
Une sortie propre (rien d'affiché, code de sortie 0) signifie que le fichier est bien formé. Les erreurs sortent en texte lisible par défaut. Ajoutez --json et vous obtenez la forme structurée que les agents consomment :
zero check hello.0 --json
{
"ok": false,
"diagnostics": [
{
"code": "NAM003",
"message": "unknown identifier",
"line": 3,
"repair": { "id": "declare-missing-symbol" }
}
]
}
La forme du diagnostic est entièrement documentée dans Diagnostics JSON. Remarquez le champ code stable — NAM003 signifie toujours « identifiant inconnu », quelle que soit la version du compilateur.
Vous pouvez aussi pointer check sur un dossier de package plutôt que sur un seul fichier :
zero check ./mon-package
Il lit zero.json, parcourt l'arborescence des sources et signale chaque problème sur chaque cible.
zero run
run compile et exécute en une étape. Idéal quand vous itérez sur un petit programme et que vous ne tenez pas à produire un binaire sur disque.
zero run hello.0
Équivaut à exécuter zero build puis à invoquer le binaire produit, sauf que l'artefact est jeté. La sortie standard de votre programme est redirigée vers le stdout de votre terminal — les appels world.out.write de votre programme atterrissent à l'écran.
Si votre programme attend des arguments, passez-les après un -- :
zero run greet.0 -- Alice
Le runtime donne au programme accès à ces arguments via la même capacité World qui expose les E/S.
zero build
Quand vous voulez un artefact, utilisez build :
zero build hello.0
Le compilateur produit un exécutable natif à côté de votre fichier source (ou sous le dossier de build du package si vous travaillez dans un package). Vous pouvez le lancer comme n'importe quel autre programme — pas de runtime séparé nécessaire, parce que les binaires Zero sont autonomes.
Les binaires Zero sont petits. L'objectif de conception du projet est des exécutables de moins de 10 Ko pour des programmes triviaux, obtenus en sautant la chaîne d'outils LLVM et en émettant directement des chemins de code compacts.
zero test
Lance les cibles de test d'un package :
zero test
Les tests vivent à côté du code source sous src/, déclarés comme des cibles de test dans le zero.json du package. Le lanceur les découvre, exécute chacun et émet pass/fail. Avec --json, la sortie est structurée par test — nom, statut, durée, diagnostics capturés — pour les agents et les outils de CI.
Packages Zero couvre la façon de déclarer des cibles de test dans zero.json.
zero fix
fix consomme les métadonnées de réparation que check --json produit. Il existe en deux modes :
zero fix --plan --json # affiche le plan structuré, n'applique pas
zero fix # applique le plan sur place
Un plan ressemble à quelque chose comme ça (la forme est illustrative) :
{
"diagnostic": { "code": "NAM003", "line": 3 },
"plan": {
"id": "declare-missing-symbol",
"edits": [
{ "kind": "insert", "line": 1, "text": "fun answer() -> i32 { return 42 }\n" }
]
}
}
L'idée, c'est qu'un agent récupère le plan, décide s'il lui fait confiance, et soit l'applique directement, soit le confie à une étape de raisonnement de plus haut niveau. Les plans sont des données ; les agents n'ont pas à interpréter de la prose pour agir.
zero explain
explain est le versant prose du système de diagnostics :
zero explain NAM003
Il affiche une explication lisible par un humain du code d'erreur — ce qu'il signifie, pourquoi le compilateur l'émet, à quoi ressemblent les corrections typiques. Utile quand :
- Un humain débogue et veut une réponse plus longue que le message inline.
- Un agent tombe sur un code de diagnostic absent de ses données d'entraînement et veut plus de contexte.
Le code lui-même est stable d'une version à l'autre du compilateur, donc les explications mises en cache restent valides.
zero new
Échafaude un nouveau package :
zero new cli hello
Ça crée un dossier hello/ avec un manifeste zero.json et un src/main.0 de départ. Le premier argument (cli ici) choisit un template — une appli en ligne de commande exécutable dans ce cas. Packages Zero explique l'arborescence en détail.
L'habitude --json
Presque toutes les commandes supportent --json. Si vous construisez de l'outillage, un harness d'agent ou un pipeline de CI autour de Zero, prenez l'habitude de la forme JSON par défaut. Elle est :
- Stable. Le schéma est versionné et l'équipe le traite comme un contrat.
- Complète. Vous obtenez des champs qui ne sont pas dans la sortie pour humains (étendues précises, identifiants de plans de réparation, données du graphe de dépendances).
- Parseable. Pas de regex sur de la prose anglaise pour extraire un numéro de ligne.
Pour les humains, laissez --json de côté — le texte formaté est ce que vous voulez dans un terminal.
Autres commandes utiles
Quelques commandes moins fréquentes qu'il vaut le coup de connaître :
zero graph --json— émet le graphe de dépendances d'un package sous forme de données structurées. Utile pour comprendre ce qui dépend de quoi, et pour les agents qui veulent raisonner sur les sites d'appel.zero size --json— rapporte la taille sur disque des artefacts compilés, ventilée par cible. Pratique quand l'empreinte binaire vous importe (ce qui est un objectif de conception de Zero).zero --version— affiche la version de la chaîne d'outils. Épinglez-la quelque part si vous travaillez en équipe — Zero est pré-1.0 et des changements cassants atterrissent.
La suite : packages Zero
Un seul fichier .0 convient pour hello-world. Les vrais projets utilisent des packages avec un manifeste zero.json et un dossier src/. Packages Zero montre comment en échafauder un et explique chaque champ.
Questions fréquentes
Quelles sont les principales commandes de la CLI Zero ?
Les commandes principales sont zero check (vérification de types d'un fichier ou d'un package), zero run (compile et exécute), zero build (compile vers un exécutable), zero test (lance les tests), zero fix (applique les réparations proposées) et zero explain (consulte un code de diagnostic). Chacune accepte un drapeau --json pour une sortie lisible par machine.
Que fait zero check ?
zero check ?zero check <fichier-ou-package> exécute les vérifications statiques du compilateur — parsing, vérification des types, analyse des capacités et effets — sans produire d'exécutable. C'est la façon la plus rapide de savoir si votre code est bien formé. Avec --json, il émet des diagnostics structurés consommables par les agents.
Quelle est la différence entre zero run et zero build ?
zero run et zero build ?zero run <fichier> compile et exécute le programme en une étape, comme go run ou cargo run. zero build compile le programme et s'arrête, en laissant un binaire natif que vous pouvez livrer ou invoquer plus tard. Utilisez run pendant l'itération ; utilisez build quand vous voulez un artefact.
Comment fonctionne zero fix --plan ?
zero fix --plan ?Quand zero check --json rapporte un diagnostic avec un champ repair, zero fix --plan --json renvoie le plan structuré qu'un agent peut appliquer pour le résoudre. Le plan est de la donnée — des opérations d'édition sur la source — pas des instructions en anglais. Un agent peut choisir de l'appliquer ou de le rejeter de manière programmatique.
Que fait zero explain ?
zero explain ?zero explain <code> consulte l'explication lisible par un humain pour un code de diagnostic stable comme NAM003. C'est le pendant en prose du diagnostic JSON — utile quand un humain débogue, et un moyen pour un agent de récupérer du contexte quand il ne reconnaît pas le code depuis son entraînement.
