Specifikace First

Základní princip

NIKDY nepíšeme kód bez předchozí specifikace. Tento princip je fundamentální pro kvalitu našich projektů.

Evidence & review: Každá specifikace musí uvádět zdroj (source: meeting:<datum>#<timestamp> nebo email:<message-id>) a musí projít ruční kontrolou architektem/PM proti záznamu. AI agenti mohou návrh napsat, ale bez manuálního potvrzení se nic neimplementuje.

graph LR
    A[Požadavky] --> B[Specifikace]
    B --> C{Review}
    C -->|Schváleno| D[Implementace]
    C -->|Změny| B
    D --> E[Validace]
    E --> F{Odpovídá spec?}
    F -->|Ano| G[Deploy]
    F -->|Ne| D

Proč Specifikace First?

Problém bez specifikace	Řešení se specifikací
Nedorozumění mezi analytiky a vývojáři	Jednoznačná pravda ve spec.yaml
Scope creep	Změny musí projít proposal procesem
Nekonzistentní výstupy	Validace proti JSON Schema
Těžko testovatelné	Gherkin akceptační kritéria
Obtížná údržba	Dokumentace je specifikace

Obsah sekce

Kapitola	Popis
Struktura specifikací	Adresářová struktura a typy specifikací
Formát spec.yaml	Kompletní formát specifikačního souboru
Akceptační kritéria	Gherkin formát pro QA
Validace a životní cyklus	Pravidla validace a workflow

---

➡️ Pokračujte na Struktura specifikací.