Ausgabe und Exit-Codes

Standard ist eine kompakte, lesbare Ausgabe, bei Listen eine Tabelle. Beispiel workban task list --mine:

#42  in_progress  workban   Login-Redirect nach Magic Link fixen    claude-code  fix/auth-redirect-loop  läuft 22m
#39  done         screenway Slider-Animation auf Safari             codex        feat/slider             1h 12m

Hinweise und Warnungen gehen auf stderr, etwa dass eine neuere Version verfügbar ist oder welche lokalen Pfade die CLI aus einem Text entfernt hat.

Jeder Befehl akzeptiert --json und gibt dann genau ein JSON-Objekt auf stdout aus, nichts anderes. Meldungen und Fehler gehen auf stderr.

workban task create "…" --start --json
# stdout:
{ "id": "…", "number": 42, "status": "in_progress", "url": "https://workban.de/t/42?w=bergx2", … }

Bei --json oder ohne Terminal gibt es keine interaktiven Fragen. Fehlt eine Pflichtangabe, bricht die CLI mit Exit-Code 2 ab, statt an einer Eingabeaufforderung zu hängen. Jede Antwort zu einem Task enthält url, damit ein Agent den Link in seiner Zusammenfassung nennen kann.

stdout enthält { "error": { "code", "message", "details" } } im selben Format wie die API. Der Exit-Code richtet sich nach der Art des Fehlers, siehe Exit-Codes.

{ "error": { "code": "forbidden", "message": "Keine Berechtigung für task.delete (Rolle: member)" } }

Verbindungsfehler und die Antworten 502, 503 und 504 (etwa während ein Deploy den Web-Container tauscht) wiederholt die CLI bis zu dreimal mit 0,5, 1,5 und 3 Sekunden Abstand, auch bei Schreibzugriffen. Das ist sicher, weil die wichtigen Befehle wiederholbar sind: task create erkennt einen offenen Task zum Branch, move auf denselben Status ändert nichts, claim und start lassen sich wiederholen. Nur ein Kommentar könnte im Extremfall doppelt ankommen.

Agenten können sich auf diese Codes verlassen und müssen stderr nicht auswerten. Die Hooks enden immer mit 0, siehe hook.