Was die CLI dir gibt
Die zero-Binary ist die gesamte Entwicklungs-Toolchain. Es gibt keinen separaten Paketmanager, Formatter, Linter oder Test-Runner – alles sind Subkommandos von zero. Das hält die Oberfläche klein und vorhersehbar, und genau darum geht es.
Eine kurze Übersicht der Befehle, die du am häufigsten anfassen wirst:
| Befehl | Was er tut |
|---|---|
zero check | Quellcode typprüfen, ohne ein Executable zu erzeugen. |
zero run | In einem Schritt kompilieren und ausführen. |
zero build | Zu einem nativen Executable kompilieren. |
zero test | Die Test-Targets eines Pakets ausführen. |
zero fix | Strukturierte Repair-Pläne anwenden oder anzeigen. |
zero explain | Die Prosa-Erklärung zu einem Diagnose-Code nachschlagen. |
zero new | Ein neues Paket gerüstartig erzeugen. |
zero --version | Die Version der Toolchain ausgeben. |
Jedes davon akzeptiert --json, um maschinenlesbare Ausgabe statt menschenfreundlichem Text zu liefern.
zero check
Das Arbeitstier. zero check führt die statischen Checks des Compilers durch – Parsing, Typprüfung, Capability- und Effekt-Inferenz, Erkennung fehlender Imports – und hält vor der Code-Generierung an. Es ist schnell, und das ist wichtig, weil Agenten und Editoren es ständig aufrufen.
zero check hello.0
Saubere Ausgabe (nichts gedruckt, Exit 0) heißt: die Datei ist wohlgeformt. Fehler kommen standardmäßig als menschenlesbarer Text. Mit --json bekommst du die strukturierte Form, die Agenten konsumieren:
zero check hello.0 --json
{
"ok": false,
"diagnostics": [
{
"code": "NAM003",
"message": "unknown identifier",
"line": 3,
"repair": { "id": "declare-missing-symbol" }
}
]
}
Die Form der Diagnostik ist in JSON-Diagnostik ausführlich dokumentiert. Beachte das stabile code-Feld – NAM003 bedeutet immer „unknown identifier", unabhängig von der Compiler-Version.
Du kannst check auch auf ein Paketverzeichnis statt eine einzelne Datei richten:
zero check ./my-package
Es liest zero.json, läuft den Quellbaum durch und meldet jedes Problem in jedem Target.
zero run
run kompiliert und führt in einem Schritt aus. Am besten, wenn du an einem kleinen Programm iterierst und dir keine Binary auf der Platte erzeugen willst.
zero run hello.0
Entspricht zero build mit anschließendem Aufruf der erzeugten Binary, nur dass das Artefakt weggeworfen wird. stdout deines Programms wird an das stdout deines Terminals weitergereicht – die world.out.write-Aufrufe deines Programms landen auf dem Bildschirm.
Wenn dein Programm Argumente braucht, übergib sie nach einem --:
zero run greet.0 -- Alice
Die Runtime gibt dem Programm Zugriff auf diese Argumente über dieselbe World-Capability, die auch I/O zugänglich macht.
zero build
Wenn du ein Artefakt willst, nutze build:
zero build hello.0
Der Compiler erzeugt ein natives Executable neben deiner Quelldatei (oder im Build-Verzeichnis des Pakets, wenn du in einem Paket arbeitest). Du kannst es wie jedes andere Programm starten – eine separate Runtime ist nicht nötig, weil Zero-Binaries in sich geschlossen sind.
Zero-Binaries sind klein. Das Designziel des Projekts sind Executables unter 10 KB für triviale Programme, erreicht durch das Umgehen der LLVM-Toolchain und das direkte Emittieren kompakter Codepfade.
zero test
Die Test-Targets eines Pakets ausführen:
zero test
Tests liegen neben dem Quellcode unter src/, als Test-Targets im zero.json des Pakets deklariert. Der Runner findet sie, führt sie aus und gibt Pass/Fail aus. Mit --json ist die Ausgabe pro Test strukturiert – Name, Status, Dauer, mitgeschriebene Diagnostik – für Agenten und CI-Tooling.
Zero-Pakete erklärt, wie man Test-Targets in zero.json deklariert.
zero fix
fix konsumiert die Repair-Metadaten, die check --json erzeugt. Es kommt in zwei Modi:
zero fix --plan --json # strukturierten Plan anzeigen, nicht anwenden
zero fix # den Plan in-place anwenden
Ein Plan sieht etwa so aus (die Form ist beispielhaft):
{
"diagnostic": { "code": "NAM003", "line": 3 },
"plan": {
"id": "declare-missing-symbol",
"edits": [
{ "kind": "insert", "line": 1, "text": "fun answer() -> i32 { return 42 }\n" }
]
}
}
Die Idee ist, dass ein Agent den Plan holt, entscheidet, ob er ihm vertraut, und ihn entweder direkt anwendet oder an einen höheren Reasoning-Schritt übergibt. Pläne sind Daten; Agenten müssen keine Prosa interpretieren, um zu handeln.
zero explain
explain ist die Prosa-Seite des Diagnosesystems:
zero explain NAM003
Es gibt eine menschenlesbare Erklärung des Fehlercodes aus – was er bedeutet, warum der Compiler ihn ausgibt, wie typische Fixes aussehen. Nützlich, wenn:
- Ein Mensch debuggt und eine längere Antwort als die Inline-Meldung will.
- Ein Agent auf einen Diagnose-Code stößt, der nicht in seinen Trainingsdaten war, und mehr Kontext braucht.
Der Code selbst ist über Compiler-Versionen hinweg stabil, sodass zwischengespeicherte Erklärungen gültig bleiben.
zero new
Ein frisches Paket gerüstartig erzeugen:
zero new cli hello
Das erstellt ein Verzeichnis hello/ mit einem zero.json-Manifest und einem src/main.0-Startpunkt. Das erste Argument (hier cli) wählt ein Template – in diesem Fall eine ausführbare Kommandozeilen-App. Zero-Pakete erklärt das Layout im Detail.
Die --json-Gewohnheit
Fast jeder Befehl unterstützt --json. Wenn du Tooling, ein Agenten-Harness oder eine CI-Pipeline um Zero baust, setze standardmäßig auf die JSON-Form. Sie ist:
- Stabil. Das Schema ist versioniert, und das Team behandelt es als Vertrag.
- Vollständig. Du bekommst Felder, die in der menschlichen Ausgabe fehlen (präzise Spans, Repair-Plan-IDs, Daten zum Abhängigkeitsgraphen).
- Parsbar. Kein Regex über englische Prosa, um eine Zeilennummer herauszuziehen.
Für Menschen lass --json weg – am Terminal willst du den formatierten Text.
Weitere nützliche Befehle
Ein paar seltener verwendete Befehle, die man kennen sollte:
zero graph --json– gibt den Abhängigkeitsgraphen eines Pakets als strukturierte Daten aus. Nützlich, um zu verstehen, was wovon abhängt, und für Agenten, die über Aufrufstellen nachdenken wollen.zero size --json– meldet die On-Disk-Größe kompilierter Artefakte, aufgeschlüsselt nach Target. Hilfreich, wenn dir der Binär-Footprint wichtig ist (was ein Designziel von Zero ist).zero --version– gibt die Version der Toolchain aus. Pinne das irgendwo, wenn du im Team arbeitest – Zero ist pre-1.0 und Breaking Changes kommen tatsächlich.
Als Nächstes: Zero-Pakete
Eine einzelne .0-Datei ist okay für Hello-World. Echte Projekte nutzen Pakete mit einem zero.json-Manifest und einem src/-Verzeichnis. Zero-Pakete zeigt, wie man eines aufsetzt, und erklärt jedes Feld.
Häufig gestellte Fragen
Was sind die wichtigsten Befehle der Zero CLI?
Die Kernkommandos sind zero check (Typprüfung einer Datei oder eines Pakets), zero run (kompilieren und ausführen), zero build (zu einem Executable kompilieren), zero test (Tests ausführen), zero fix (vorgeschlagene Repairs anwenden) und zero explain (einen Diagnose-Code nachschlagen). Jeder akzeptiert einen --json-Flag für maschinenlesbare Ausgabe.
Was macht zero check?
zero check?zero check <datei-oder-paket> führt die statischen Checks des Compilers durch – Parsing, Typprüfung, Capability- und Effekt-Analyse – ohne ein Executable zu erzeugen. Es ist der schnellste Weg zu wissen, ob dein Code wohlgeformt ist. Mit --json gibt es strukturierte Diagnostik aus, die Agenten konsumieren können.
Was ist der Unterschied zwischen zero run und zero build?
zero run und zero build?zero run <datei> kompiliert und führt das Programm in einem Schritt aus, wie go run oder cargo run. zero build kompiliert und hält an, sodass eine native Binary übrigbleibt, die du ausliefern oder später aufrufen kannst. Nutze run beim Iterieren; nutze build, wenn du ein Artefakt willst.
Wie funktioniert zero fix --plan?
zero fix --plan?Wenn zero check --json eine Diagnostik mit einem repair-Feld meldet, liefert zero fix --plan --json den strukturierten Plan zurück, den ein Agent zur Behebung anwenden kann. Der Plan ist Daten – Edit-Operationen am Quellcode – nicht englische Anweisungen. Ein Agent kann ihn programmatisch anwenden oder verwerfen.
Was macht zero explain?
zero explain?zero explain <code> schlägt die menschenlesbare Erklärung zu einem stabilen Diagnostik-Code wie NAM003 nach. Es ist der Prosa-Begleiter zur JSON-Diagnostik – nützlich, wenn ein Mensch debuggt, und ein Weg für einen Agenten, Kontext nachzuholen, wenn er den Code aus dem Training nicht kennt.
