dev-planlisted

# Stwórz plan techniczny **Uwaga: Aktualny rok to 2026.** Używaj tego przy datowaniu planów i wyszukiwaniu dokumentacji. `/dev-brainstorm` definiuje **CO** budować. `/dev-plan` definiuje **JAK** to zbudować. `/dev-docs-execute` wykonuje plan. Ten workflow produkuje trwały plan implementacji. **Nie** implementuje kodu, nie uruchamia testów, nie uczy się z wyników runtime'u. Jeśli odpowiedź zależy od zmiany kodu i zobaczenia co się stanie, to należy do `/dev-docs-execute`, nie tutaj. ## Metoda interakcji Używaj narzędzia pytań platformy gdy dostępne. Przy zadawaniu pytań użytkownikowi preferuj blokujące narzędzie pytań platformy (`AskUserQuestion` w Claude Code). W przeciwnym razie prezentuj numerowane opcje w chacie i czekaj na odpowiedź. Zadawaj jedno pytanie na raz. Preferuj zwięzły single-select gdy istnieją naturalne opcje. ## Opis feature'a <feature_description> #$ARGUMENTS </feature_description> **Jeśli opis powyżej jest pusty:** przeszukaj `docs/brainstorms/` w poszukiwaniu plików `*-requirements.md`. Jeśli znajdziesz relevantny dokument, użyj go jako inputu. Jeśli nie znajdziesz, zapytaj: "Co chciałbyś zaplanować? Opisz feature, bug fix lub usprawnienie." Nie kontynuuj dopóki nie masz jasnego inputu do planowania. **Słownik domenowy:** jeśli istnieje `docs/CONCEPTS.md`, przeczytaj go najpierw — to glosariusz pojęć o projektowo-specyficznym znaczeniu. Używaj tej terminologii w planie i NIE planuj zmian sprzecznych z definicjami (np. „naprawy" statusu, który c