Podsumowanie sesji Codex
Zakres sesji
Lekcja przygotowuje zadanie kończące dzień czwarty. Punktem startowym jest folder l15, który zawiera dwa projekty Playwright: klienta działającego na https://awesome.byst.re i administratora działającego na https://aitesters.byst.re.
Celem zadania jest użycie Codex Goal do audytu i uzupełnienia brakującego pokrycia e-commerce API. Zakres obejmuje produkty, koszyk i zamówienia klienta oraz operacje administratora na produktach, użytkownikach i zamówieniach.
Prompt przygotowany do Codex
Pracuj w folderze l15 i odpowiadaj po angielsku. Najpierw porównaj kontrakt API,
api-test-plan.md oraz istniejące testy. Zidentyfikuj brakujące zachowania dla
produktów, koszyka i zamówień klienta oraz dla produktów, użytkowników i
zamówień administratora. Przygotuj plan i użyj Goal, aby doprowadzić pracę do
końca. Zachowaj osobne projekty api i admin-api, równoległość, izolację danych,
cleanup oraz obecną architekturę. Zaktualizuj plan i pracuj do momentu, w którym
testy zakresowe i pełny suite przechodzą. Na końcu przedstaw dowody i ryzyka.
Co powinien sprawdzić Codex przed implementacją?
Agent powinien przeczytać api-test-plan.md, api-docs.json, konfigurację Playwright, klientów HTTP, typy, fixture i istniejące testy. Audyt ma odróżnić rzeczywistą lukę od endpointu, który jest już pokryty w innym pliku albo projekcie.
Przed utrwaleniem nowych oczekiwań agent powinien zweryfikować niepewne zachowanie na live API. Nieudokumentowane lub niestabilne odpowiedzi powinny trafić do raportu jako blocker albo kandydat do triage, a nie zostać zamienione w przypadkową asercję regresyjną.
Co ma zaimplementować Codex?
Zadanie nie narzuca konkretnych nazw wszystkich plików. Agent ma dobrać je do istniejącej struktury, zachować osobny spec dla operacji oraz wykorzystać obecne klienty i fixture. Każdy scenariusz modyfikujący dane powinien tworzyć unikalny rekord i sprzątać zasoby, które sam utworzył.
Plan powinien zostać zaktualizowany o rzeczywisty stan pokrycia. Jeżeli obszary są niezależne, agent może zaplanować kilka strumieni pracy, ale musi nadać im jawny ownership i pozostawić jeden punkt integracji.
Jakie korekty są częścią zadania?
Testy nie-adminowe muszą pozostać w projekcie api, a adminowe w admin-api. Oba projekty mają działać równolegle; nie należy ukrywać problemów z izolacją przez globalne workers: 1.
Agent nie powinien robić rewolucji w planie ani architekturze. Ma uzupełnić istniejący framework i udokumentować powody każdej zmiany wspólnej fixture, klienta lub typu.
Co podlega review?
Review powinno objąć diff, nazwy i odpowiedzialności plików, sekcje Given–When–Then, kolejność przypadków według kodów odpowiedzi, izolację danych, cleanup, brak sekretów oraz zgodność z live API.
Pełny run jest obowiązkowym dowodem integracji. Zielony wynik nie zastępuje jednak przeglądu jakości helperów i upewnienia się, że test nie usuwa danych seedowanych ani zasobów utworzonych przez inny worker.
Wynik testów
Ta lekcja definiuje zadanie, dlatego nie przedstawia jeszcze finalnego wyniku implementacji. Wyniki Goal, nowe testy i review są pokazane w następnej lekcji z rozwiązaniem.
Finalny efekt sesji
Powstał mierzalny kontrakt dla autonomicznej pracy: audyt, plan, pokrycie klienta i administratora, bezpieczna równoległość, pełna weryfikacja oraz raport końcowy. Kursant może uruchomić Goal bez zgadywania, co oznacza „gotowe”.