dev-docs-reviewlisted

# Code Review fazy zadania ## Wykonanie Ustal `sciezka` (folder zadania w `docs/active/`, np. z argumentu `$1`) i `faza` (numer fazy, np. z argumentu `$2`; jeśli nie podano — pierwsza faza z niezaznaczonymi checkboxami `Weryfikacja:` lub ostatnia ukończona przez `/dev-docs-execute`). URUCHOM workflow toolem Workflow: ``` Workflow({scriptPath: ".claude/workflows/dev-docs-review-wf.js", args: {sciezka, faza}}) ``` Po zakończeniu workflow streść użytkownikowi wynik: severity gate (BLOKUJE / ZASTRZEŻENIA / CZYSTE), liczniki findingów (P1/P2/P3, w tym OPERATOR), wynik E2E (passed/failed/skipped), ścieżkę zapisanego raportu. **NIE wykonuj procedury ręcznie** — mechanika (routing reviewerów + adversarial verify / delegacja IU do builderów) żyje w workflow; sekcje referencyjne poniżej są używane PRZEZ workflow, nie przez Ciebie. Skład reviewerów ustala **routing domenowy** (workflow, nie Ty): rdzeń — `security`, `spec-compliance`, `simplicity`, `test-coverage` — odpala się zawsze; `performance`, `architecture`, `typescript` i `e2e` tylko gdy ich domena jest w fazie obecna (flagi warstw od context-packagera). Brak flag = pełny skład (fail-open). Kogo pominięto, widać w sekcji `## Przebieg review` raportu. ### 1. Walidacja - Sprawdź czy folder `$1/` istnieje - Sprawdź zmiany w git: `git status --short` - Jeśli folder nie istnieje → poinformuj użytkownika i zakończ ### 2. Przygotowanie kontekstu Przeczytaj dokumentację zadania z `$1/`: - Plan zadania (cele, wymagania, kryteria