10X WORKFLOW // MODUŁ 3 // 5 LEKCJI

MODUŁ 3 // JAKOŚĆ

Najpierw ryzyka, nie pliki

Jakość w 10x Workflow: pięć lekcji o tym, jak chronić najgroźniejsze scenariusze testem, którego asercja realnie pada - plan testów, wyrocznia i mutacja, warstwy hooków, przelot E2E i debugowanie z dowodów. Zielony test, który nie pada po zepsuciu, niczego nie pilnuje.

Skrót modułu · pięć lekcji w 30 sekund

„Najpierw ryzyka, nie pliki - chroń najgroźniejsze scenariusze testem, którego asercja realnie pada."

- fundament 10x Workflow
LEKCJA 01 Diuna · Fremeni

Plan testów - co zabija projekt najpierw?

„Pustynia zabija w znanej kolejności: najpierw pragnienie, potem burza, na końcu czerw. Kto wychodzi z siczy bez tej mapy, nie wraca."

- nauka Fremenów, przed wyjściem z siczy
PRAWDOPODOBIEŃSTWO → WPŁYW → CHRONIONE NAJPIERW TEST-PLAN.MD RYZYKO = AWARIA U USERA
RYS. 01 // MAPA RYZYK: WPŁYW × PRAWDOPODOBIEŃSTWO

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".

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

Pytanie
co zabija projekt najpierw?
Gwarancja
najgroźniejsze scenariusze chronione najpierw
Artefakt
test-plan.md w context/foundation/
Narzędzia
/10x-test-plan → łańcuch: research → plan → implement
CEL:

kluczowy, zanim powstanie pierwszy test - kolejność pisania testów wyznacza mapa ryzyk, nie struktura katalogów.

LEKCJA 02 Problem trzech ciał · Eksperyment

Od planu do testów - skąd test wie, co jest poprawne?

„Nie pytaj teorii, czy ma rację. Zepsuj układ i patrz, czy przyrząd krzyknie - pomiar rozstrzyga, nie wiara."

- protokół eksperymentu, dziennik zespołu badawczego
UKŁAD: ZEPSUTY CELOWO PRZYRZĄD = TEST CZERWIEŃ WYROCZNIA: Z WYMAGAŃ, NIE Z KODU ZIELONY, KTÓRY NIE PADA, NICZEGO NIE PILNUJE
RYS. 02 // MUTATION CHECK: ZEPSUJ I POTWIERDŹ CZERWIEŃ

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ą mirroruje - przyklepie każdy bug, który już tam mieszka. Stąd anti-patterny 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.

Pytanie
skąd test wie, co jest poprawne?
Gwarancja
asercja, która realnie pada na zepsutym kodzie
Artefakt
test chroniący ryzyko + potwierdzona czerwień
Narzędzia
/10x-tdd, mutation / deliberate-break check
CEL:

kluczowy przy każdym teście pisanym przez agenta - wyrocznia pochodzi z wymagań, a dowodem jakości testu jest jego czerwień na zepsutym kodzie.

LEKCJA 03 Star Wars · Tarcze deflektorowe

Hooki i triggery - co łapie błąd, zanim go zobaczysz?

„Najpierw pracuje tania osłona zewnętrzna, potem deflektory, na końcu pancerz. Ogień, który dochodzi do kadłuba, to porażka wszystkich warstw."

- oficer sekcji tarcz, odprawa przed bitwą
KOD PRE-PUSH PRE-COMMIT PER-EDIT // NAJTAŃSZA DRYF ŁAPANY SEKUNDY PO POWSTANIU IM DALEJ OD KODU, TYM DROŻSZY BŁĄD
RYS. 03 // BŁĄD GAŚNIE NA NAJTAŃSZEJ WARSTWIE

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żej kosztuje jego zestrzelenie.

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 fazy dolatuje już tylko to, czego żadna warstwa nie mogła złapać wcześniej.

Pytanie
co łapie błąd, zanim go zobaczysz?
Gwarancja
dryf wykryty sekundy po powstaniu, nie na końcu fazy
Artefakt
hooki per-edit / pre-commit / pre-push w repo
Narzędzia
hooki (PostToolUse, pre-commit, pre-push), lint, typecheck
CEL:

kluczowy przy pracy z agentem, który generuje kod szybciej, niż czytasz - błąd ma zgasnąć na najtańszej warstwie, zanim dotknie historii gita.

LEKCJA 04 The Expanse · Lot testowy Rocinante

Testy E2E - czy całość naprawdę leci?

„Makieta w doku nie powie ci, czy statek leci. Wyprowadź go, odpal silniki i czytaj przyrządy w locie."

- mechanik pokładowy, przed lotem testowym
UI API DANE SEED: DANE POD PRZELOT E2E TYLKO TAM, GDZIE MOCK BY SKŁAMAŁ PEŁNY PRZELOT, NIE DOK
RYS. 04 // LOT TESTOWY: PRZEZ WSZYSTKIE MODUŁY, NIE W DOKU

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. Coverage nie jest celem - celem jest sygnał.

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.

Pytanie
czy całość naprawdę leci?
Gwarancja
przelot end-to-end tam, gdzie unit by skłamał
Artefakt
testy Playwright + seed test
Narzędzia
/10x-e2e, Playwright CLI/MCP (DOM + vision)
CEL:

kluczowy dla ścieżek krytycznych - logowanie, płatność, zapis danych - E2E tylko tam, gdzie mock by skłamał, nie do gonienia coverage.

LEKCJA 05 Hyperion · Pielgrzymi

Debugowanie - co mówią wszystkie przyrządy naraz?

„Każdy z nas niesie inną opowieść i żadna z osobna niczego nie wyjaśnia. Prawda leży tam, gdzie opowieści się przecinają."

- zasada pielgrzymów, w drodze do Grobowców Czasu
SENTRY WRANGLER LOGS CONSOLE NETWORK PRZECIĘCIE OPOWIEŚCI DIAGNOZA ŻADNE ŹRÓDŁO SAMO NIE WYSTARCZA TRY/CATCH → 200 = POŁKNIĘTY DOWÓD
RYS. 05 // WIELE OPOWIEŚCI, JEDNA DIAGNOZA

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.

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.

Pytanie
co mówią wszystkie przyrządy naraz?
Gwarancja
diagnoza z dowodów, nie z przeczucia
Artefakt
diagnoza + test przypinający naprawę
Narzędzia
Sentry MCP, wrangler logs, Playwright console/network
CEL:

kluczowy, gdy objaw i przyczyna mieszkają w różnych warstwach - diagnozę stawia przecięcie źródeł, nie pierwsze podejrzenie.

DALEJ Jakość domyka blok · 10xBuilder

Dalej: blok domknięty

BLOK 10XBUILDER // FUNDAMENT → ŁAŃCUCH → JAKOŚĆ

Jakość domyka blok 10xBuilder. Fundament stawia rampę, łańcuch lata jednostkami pracy, skalowanie podnosi rygor i autonomię, a jakość pilnuje, żeby to, co lata, nie spadało.

moduł 1
10xdevs-fundament.pages.dev - od pomysłu do rampy startowej
moduł 2 // csc
10xdevs-csc.pages.dev - pięć skoków jednej jednostki pracy
skalowanie
10xdevs-skalowanie.pages.dev - quality gates, goal, loops
MODUŁ 4 // LEGACY

Dalej gra toczy się w cudzym kodzie: 10xArchitect otwiera moduł o legacy - zastane systemy, brak testów, archeologia decyzji. Wszystko, czego jakość nauczyła na własnym kodzie, wraca tam ze zdwojoną stawką.

zapowiedź
legacy (M4, 10xArchitect) - praca w zastanych systemach
zasada
w legacy test chroniący zachowanie powstaje, zanim ruszy refactor

„Blok 10xBuilder domknięty: rampa, łańcuch, tarcza. Dalej lata się w cudzym kodzie."

- fundament 10x Workflow