Najpierw ryzyka, nie pliki

Fremeni nie wychodzą z siczy z listą rzeczy do zrobienia - wychodzą z mapą tego, co zabija. Pustynia jest przewidywalna w swojej wrogości: każde zagrożenie ma znaną wagę i znaną częstość. Plan testów przenosi ten rygor na projekt: zamiast pokrywać pliki po kolei, mapuje ryzyka na osi wpływ × prawdopodobieństwo, a każde ryzyko opisuje jako awarię u usera - „koszyk gubi pozycje przy odświeżeniu", nie „brak testów w cart.ts".

Plan testów zaczyna od mapy tego, co zabija projekt, a nie od listy plików: mapuje ryzyka na osi wpływ × prawdopodobieństwo, a każde ryzyko opisuje jako awarię u usera - „koszyk gubi pozycje przy odświeżeniu", nie „brak testów w cart.ts".

Wejście: działający produkt i PRD. Wyjście: context/foundation/test-plan.md - mapa ryzyk pocięta na etapy rolloutu, od najgroźniejszych scenariuszy w dół. Mechanizm: /10x-test-plan orkiestruje dowiezienie testów, nie pisze ich sam - każdy etap prowadzi przez łańcuch (research → plan → implement), a ponowne uruchomienie wznawia od następnego etapu zamiast zaczynać od zera.

W „Problemie trzech ciał" spory rozstrzyga eksperyment: teoria, której nie da się zmierzyć, jest tylko opinią. Test ma tę samą naturę - to, co poprawne, musi znać z wyroczni zbudowanej z wymagań i researchu, nie z kodu, który sprawdza. Test odczytujący oczekiwaną wartość z implementacji tylko ją powiela - przyklepie każdy bug, który już tam mieszka. Stąd antywzorce do wytępienia: asercje spisane z kodu, snapshoty bez zrozumienia, mocki testujące mocki.

To, co poprawne, test musi znać z wyroczni zbudowanej z wymagań i researchu, nie z kodu, który sprawdza. Asercja spisana z implementacji tylko ją powiela - przyklepie każdy bug, który już tam mieszka; stąd antywzorce do wytępienia: asercje spisane z kodu, snapshoty bez zrozumienia, mocki testujące mocki.

Wejście: jedno ryzyko z test-plan.md. Wyjście: test, którego asercja realnie pada na zepsutym kodzie. Mechanizm: mutation check - zepsuj chronione zachowanie celowo i potwierdź czerwień; jeśli przyrząd nie krzyczy po sabotażu, niczego nie mierzy. /10x-tdd wymusza tę kolejność od początku: czerwony test przed kodem, zieleń jako dowód, refactor na osłoniętym gruncie.

Krążownik nie przyjmuje ognia na pancerz kadłuba - od tego są tarcze deflektorowe, warstwa za warstwą, od najtańszej na zewnątrz po najdroższą przy poszyciu. Obrona jakości działa tak samo i jest uporządkowana według kosztu: per-edit (lint i typecheck sekundy po zapisie) → pre-commit → pre-push. Im dalej błąd doleci, tym droższe jest jego zestrzelenie.

Obrona jakości jest uporządkowana według kosztu: per-edit (lint i typecheck sekundy po zapisie) → pre-commit → pre-push. Im później błąd zostanie wykryty, tym droższa jest jego naprawa.

Wejście: reguły jakości projektu - lint, typecheck, szybkie testy. Wyjście: hooki zapięte na zdarzenia - per-edit, pre-commit i pre-push, każdy z własnym budżetem czasu. Mechanizm: self-checking pipeline - dryf jest wykrywany sekundy po powstaniu, w tle, bez udziału człowieka; do końca etapu dolatuje już tylko to, czego żadna warstwa nie mogła złapać wcześniej.

Rocinante nie dowiodła, że lata, na schematach w doku - dowiodła tego lotem testowym: silniki, nawigacja, kadłub i załoga naraz, w próżni. Test E2E to ten sam manewr: przelot przez wszystkie moduły naraz - UI, API, dane - dokładnie tam, gdzie mock by skłamał. Obowiązuje zasada najtańszego testu dającego sygnał: jeśli unit wystarcza, E2E jest przepychem; jeśli unit kłamie, E2E jest jedynym uczciwym pomiarem. Celem jest sygnał, nie coverage.

Test E2E to przejście przez wszystkie moduły naraz - UI, API, dane - dokładnie tam, gdzie mock by skłamał. Obowiązuje zasada najtańszego testu dającego sygnał: jeśli unit wystarcza, E2E jest przepychem; celem jest sygnał, nie coverage.

Wejście: działająca aplikacja i ryzyko z planu, którego nie pokryje nic tańszego. Wyjście: testy Playwright + seed test przygotowujący dane pod przelot. Mechanizm: /10x-e2e prowadzi ryzyko przez plan → generate → review → verify na uruchomionej aplikacji, multimodalnie - agent czyta DOM i patrzy na zrzuty ekranu jednocześnie, więc widzi też to, czego selektor nie złapie.

Pielgrzymi w drodze do Grobowców Czasu docierają do prawdy tylko dlatego, że każdy opowiada własną historię - żadna z osobna niczego nie wyjaśnia, wszystkie naraz wskazują to samo miejsce. Debugowanie z agentem działa identycznie: synteza dowodów z wielu źródeł - Sentry z produkcji, wrangler logs z backendu, konsola i network z Playwrighta - zamiast mistrzostwa w jednym narzędziu.

Debugowanie z agentem to synteza dowodów z wielu źródeł naraz - Sentry z produkcji, wrangler logs z backendu, konsola i network z Playwrighta - zamiast mistrzostwa w jednym narzędziu. Żadne źródło z osobna niczego nie wyjaśnia; wszystkie naraz wskazują to samo miejsce.

Wejście: objaw - błąd u usera, czerwony test, alert. Wyjście: diagnoza poparta dowodami i naprawa przypięta testem, żeby regresja nie wróciła. Mechanizm: zbierz odczyty wszystkich przyrządów naraz i szukaj przecięcia opowieści; po drodze wytęp połykanie błędów - try/catch zwracający 200 to zamiatanie dowodów (OWASP A10:2025), przez które następna diagnoza zaczyna od zera.