V roce 2026 vytvořil podnikový tým agenta, který četl lístky na správu incidentů, generoval z nich pitvy a automaticky vytvářel položky oprav. Druhý agent ve stejném týmu sledoval nové pracovní položky a otevíral návrhy PR pro každou z nich, aby pomohl vývojářům začít. Vývojář zkontroloval jeden z těchto PR, shledal ho rozumným, schválil ho a sloučil se s hlavní větví.

**Problém byl v tom, že změna byla zcela vymyšlená.**

Agent vynalezl věrohodně vypadající opravu problému, který neexistoval způsobem, který popisoval. Změna narušila skutečný výrobní scénář. Všiml si toho skutečný zákazník. Došlo k výpadku.

To je důvod, proč existuje ústava EDD.

Ústava je jeden soubor, který řídí každou netriviální změnu kódové základny. Definuje, jak hotová změna vypadá, jaké důkazy musí nést, co musí zahrnovat rozsah auditu a jak se mohou vyvíjet samotná pravidla. Každý agent a každý člověk, který se dotkne repo, jej nahraje při každé relaci. Lišta se pouze zvedá.

Tento příspěvek prochází ústavou krok za krokem: incident, který ji motivoval, otázka týkající se designu, na kterou odpovídá, jak je strukturována, jak byla napsána (a co jsme na začátku udělali špatně), jak fungují změny a jak se celá sada rozvine do nového repozitáře.

Krok 1 - Co to je

Incident je nejjasnějším možným příkladem režimu selhání, kterému má EDD zabránit. Agent neměl halucinace náhodně. Vytvořil koherentní, čitelný, profesionálně formátovaný PR. Vývojář, který jej zkontroloval, udělal to, co vývojáři: přečetli záměr, shledali záměr věrohodným a schválili ho. Mezerou nebyla pozornost. Mezerou byla absence důkazů. Nic v procesu kontroly nevyžadovalo, aby agent prokázal, že problém, o kterém tvrdil, že má opravit, skutečně existoval, že oprava řešila skutečné chování nebo že změna nic nevrátila.

EDD odpovídá na tuto mezeru jediným tvrdým požadavkem: pokud to agent nemůže dokázat, úkol není dokončen. Důkaz není souhrn. Důkaz není tvrzení o důvěře. Důkaz je artefakt, který lze nezávisle ověřit – neúspěšný test, výstup ze skeneru, snímek obrazovky před/po, rozdíl v plánu. PR nese artefakt nebo je PR neúplné.

Ústava je k dispozici na adrese `docs/metodology/CONSTITUTION.md`. Každý agent AI nakonfigurovaný v projektu jej načte při každé relaci prostřednictvím svého vlastního zaváděcího souboru. Tělo je neutrální vůči agentům: žádné názvy nástrojů, žádná syntaxe specifická pro platformu. Definuje devět základních principů, tvrdá omezení se stabilními slim ID, 10-krokovou implementační smyčku, dimenze auditu, kritéria přijímání důkazů pro každý typ změny, triviální omezení pro práci s nízkým rizikem a doložku o dodatcích.

Každé pevné omezení má slug jako `[HC-EVIDENCE-BEFORE]` a deklaruje tři věci: pruh (co musí být pravda), ověření (jak se kontroluje dodržování) a zdroj vzoru (který instrukční soubor rozpracovává pokyny k implementaci).

Smyčka o 10 krocích je srdcem provozu: definujte hotovo, napište test, který prokáže mezeru, sledujte, jak selže, zachyťte předchozí důkazy, implementujte, sledujte, jak test prošel, zachyťte následné důkazy, ověřte dokumenty, auditujte napříč deklarovanými dimenzemi a poté kontrolu člověkem. Kroky 1 až 4 proběhnou před jakoukoli úpravou implementace. Nařízení je ústavní, protože tento incident přesně ukazuje, co se stane, když tomu tak není.

Jako další pojistku si EDD vypůjčuje základní princip od TDD: před zahájením práce musí být prokázáno, že scénář selhal. Důkaz, který projde na konci změny, není sám o sobě dostatečným důkazem – pokud test také prošel před změnou, agent možná opravil něco, co nebylo nikdy porušeno. Toto je specifický režim selhání v pracovních postupech podporovaných umělou inteligencí: agent vygeneruje věrohodně znějící opravu, ověření je náhodou splněno a změna se odešle, jako by vyřešila skutečný problém. Požadavek na zdokumentovaný stav selhání před zahájením implementace tuto mezeru uzavírá. Krok před důkazy není jen základní linií pro srovnání – je to důkaz, že řešený problém byl skutečný.

Ze všech tvrdých omezení, která prošla ústavou, dvě zachytily více defektů než všechny ostatní dohromady a jsou pravděpodobně tím nejdůležitějším vylepšením, které EDD provádí v jakémkoli pracovním postupu podporovaném umělou inteligencí: „[HC-EVIDENCE]“ a „[HC-EVIDENCE-INTEGRITY]“. Oba jsou deklarovány v `.github/copilot-instructions.md` - dychtivě načítaném souboru, který je v kontextu agenta při každé relaci.

`[HC-EVIDENCE]` vyžaduje, aby každá PR obsahovala skutečné artefakty před a po – nikoli popisy toho, co by artefakty ukazovaly, nikoli shrnutí toho, co se agent domnívá, že se stalo, ale nezpracovaný výstup. `[HC-EVIDENCE-INTEGRITY]` jde dále: vyžaduje, aby důkazy v PR bylo možné vysledovat zpět k práci, která byla skutečně provedena. Ověřuje, že PR obsahuje to, co říká, že obsahuje.

Společně tato dvě omezení zachytila ​​stovky chyb generovaných umělou inteligencí, než se dostali ke kontrole. Způsob selhání, před kterým se chrání, není halucinace v jasném smyslu. Jedná se o jemnější chování: agent označí úkol za splněný, napíše sebevědomý PR popis a zahrne to, co lze považovat za důkaz – ale důkazy byly složeny, nikoli zachyceny. Agent popsal, jak by měl výstup vypadat, spíše než spuštění příkazu a včetně skutečného výstupu.

`[HC-EVIDENCE-INTEGRITY]` je specificky účinný při zachycení toho, co by se dalo nazvat vzorem „To jsem nemohl udělat“. Agent, který čelí těžkému nebo neznámému úkolu, bude někdy tvrdit, že úkol je nemožný nebo mimo rozsah, místo aby se o to pokusil. Nárok je často koncipován jako omezení – nástroj, který neexistuje, omezení bránící přístupu, prostředí, které operaci nepodporuje. `[HC-EVIDENCE-INTEGRITY]` odhaluje toto: pokud agent tvrdí, že úkol nelze provést, PR musí prokázat, že se o úkol skutečně pokusil a že překážka je skutečná. "Nelze spustit testovací sadu" vyžaduje výstup terminálu zobrazující selhání, nikoli prohlášení, že k selhání došlo. Bez tohoto požadavku je agentovo vyhýbání se obtížné práci v době kontroly neviditelné a úkol se odešle neúplný, jako by byl hotový.

Krok 2 – Jak jsme se sem dostali

Ústava není nahromaděním získaných zkušeností. Je to odpověď na jednu designovou otázku položenou na začátku: jak přinutíte agenta umělé inteligence, aby pokaždé prokázal svou práci způsobem, který nelze obejít a nezávisí na tom, že se člověk nezapomene zeptat?

Odpověď na tuto otázku si vynutila rozklad. Důkaz vyžaduje vědět, jak hotovo vypadá, než se zahájí implementace – z toho vznikl dokumentační krok. Důkaz vyžaduje test, který selže před změnou a projde po – což vedlo k neúspěšné/úspěšné testovací disciplíně. Důkaz vyžaduje stav před stavem, který byl zachycen předtím, než se implementace čehokoli dotkla – což vytvořilo požadavek na předběžný důkaz. Důkaz vyžaduje nezávislý audit, který zachytí to, co důkazy při změně nemohou – který vytvořil dimenze auditu. A důkaz musí přežít recenzní proces, aniž by byl změkčen – to vytvořilo tvrdé omezení, že lidský recenzent je poslední bránou a jedinou bránou, kterou nelze automatizovat.

Výsledkem je 10kroková smyčka. Každý krok existuje, protože jeho odstraněním vznikne díra, kterou může projít neověřená práce. Smyčka není kontrolní seznam. Je to kauzální řetězec.

Odtud vyvstala otázka: jaké kategorie selhání může agent vytvořit, které smyčka standardně nezachytí? To způsobilo tvrdá omezení. Mlčení bezpečnostního lintu, zatímco byla pravidla snížena, vytvořilo `[HC-SECURITY-LINT]`. Selhání kódování znaků v nasazeném artefaktu vytvořilo `[HC-ASCII-PUNCT]`. Každý HC uzavírá specifickou třídu selhání specifickým automatickým ověřením. Pravidla, která nemohla pojmenovat ověření, byla odmítnuta: pokud nelze kontrolu zautomatizovat, je pravidlo aspirační, nikoli ústavní.

Poslední designová otázka zněla: kdo řídí samotnou ústavu? Odpověď je ráčna. Ústava může být jen přísnější. Dodatky musí nést důkaz, že se chování agenta zlepšuje nebo udržuje. Podlaha se nikdy nepohne dolů. To znamená, že ústavě lze časem důvěřovat způsobem, který průvodce životním stylem nemůže: každá verze je přísnější než ta předchozí.

Krok 3 – Jak je strukturován

Ústava sleduje třívrstvou architekturu.

**Vrstva 1: Kanonické tělo.** Jeden soubor, `docs/metodology/CONSTITUTION.md`. Toto je zdroj pravdy. Je neutrální vůči agentům: nepředpokládá, který nástroj AI se používá. Definuje principy, pevná omezení, smyčku, dimenze auditu, kritéria přijímání důkazů, omezení triviality a klauzuli o sebezdokonalování. Když tělo překročí zhruba 250 řádků, pravidla, která se vztahují na konkrétní vzor cesty, se rozdělí do souborů s rozsahem cesty, přičemž v těle zůstane jednořádkový ukazatel.

**Vrstva 2: Zavaděče agentů.** Každý nakonfigurovaný agent dostane přesně jeden zaváděcí soubor v umístění, které agent dychtivě načítá. Pro GitHub Copilot je to `.github/copilot-instructions.md`. Pro Clauda je to `CLAUDE.md`. Zavaděč importuje nebo vloží tělo ústavy v závislosti na tom, co platforma aktuálně podporuje. Nakladač je mechanicky vyroben z kanonického těla; není ručně upravován. Pokud projekt používá tři nástroje umělé inteligence, existují tři zaváděcí soubory, které všechny vykreslují stejný ústavní obsah.

**Vrstva 3: Pravidla v rozsahu cesty.** Některá pravidla platí pouze pro určité typy souborů. Pravidla přístupnosti a lokalizace se vztahují na soubory JSX a CSS, nikoli na šablony infrastruktury. Tato pravidla žijí v instrukčních souborech s frontmatter globem:

Agent načte tyto soubory pouze tehdy, když se dotkne odpovídající cesty. To udržuje rozpočet kontextu dychtivé zátěže napjatý (základní pravidla jsou vždy přítomna, specializovaná pravidla se načítají na vyžádání) a zabraňuje tomu, aby se na úpravě šablony Bicep objevily pokyny pro usnadnění.

Strukturu doplňují podpůrné soubory: těla příkazů `/constitute` v `.github/prompts/`, složky pro jednotlivé funkce v `docs/metodology/features/`, scénáře eval v `docs/metodology/eval/scenarios/` a `verify-sequence.yaml` v kořenovém adresáři úložiště.yaml`

Krok 4 – Jak jsme to napsali

**Kontext je všechno. Co není v kontextu, je pro agenta mrtvé.**

Toto je nejdůležitější poznatek o psaní ústavy pro vývoj řízený umělou inteligencí. Pravidlo, které existuje v souboru, který agent nikdy nenačte, neexistuje. Pevné omezení skryté v dokumentu, který se načte pouze tehdy, když se dotknete konkrétní cesty k souboru, není pevným omezením pro žádnou jinou cestu. Ústava musí být vždy v kontextu a musí tam žít vše, co vždy musí platit.

To vede ke třem autorským rozhodnutím:

**Optimalizace tokenů je nesmlouvavá.** Kanonické tělo cíle pod 300 řádků a 8 000 tokenů. Každý pozměňovací návrh musí zachovat nebo zlepšit efektivitu tokenu – podrobná pravidla, která dosahují toho, co mohou stručná, jsou zamítnuta pouze z těchto důvodů. Nejedná se o preferenci stylu. Je to omezení zatížení. Pokud ústava překročí rozpočet, agenti v menších kontextových oknech ji začnou zkracovat a zkrácená pravidla nejsou žádná pravidla.

**Podmíněné načítání prostřednictvím frontmatteru.** Pravidla, která se vztahují pouze na určité typy souborů, jsou vyňata z kanonického těla a do souborů instrukcí v rozsahu cesty s deklarací frontmatter glob. Pokyny pro usnadnění a lokalizaci se načtou pouze tehdy, když se agent dotkne JSX nebo CSS. Navádění infrastruktury se načte pouze tehdy, když se agent dotkne Bicepsu. Kanonické tělo udržuje jednořádkový ukazatel. Agent načte soubor s rozsahem cesty pouze tehdy, když je to relevantní. Nejde jen o efektivitu – zabraňuje tomu, aby se pokyny týkající se dostupnosti objevily jako rušivé prvky při úpravě infrastruktury, což trénuje agenta, aby je ignoroval.

Tento projekt nepoužívá soubory pravidel oddělené frontmatterem, protože konstituce je dostatečně malá, aby se načetla zcela v kontextu – jeden vývojář, zaměřený rozsah, štíhlá sada pravidel. U větších týmů se počet mění. Projekt podnikového měřítka, který v současné době provozuje EDD, má 75 tvrdých omezení napříč požadavky na zabezpečení, shodu, dostupnost a platformu. Vložení všech 75 do jednoho souboru dychtivého načtení by u většiny agentů posunulo ústavu daleko za kontextový rozpočet. Rozdělení Frontmatteru udržuje kanonické tělo pod 250 řádky – souhrnný ukazatel na doménu – a líně načte úplné podrobnosti pravidla pouze tehdy, když se agent dotkne odpovídajících cest. Ústava zůstává rychlá a štíhlá. Pravidla zůstávají kompletní. Cena tokenu zůstává omezena.

**Dodatky jako jednotky změny.** Dodatek k ústavě není změna slova v souboru markdown. Jedná se o balíček tří artefaktů: přesná delta pravidel, ověřovací mechanismus, který zachytí budoucí porušení, a scénář hodnocení chování, který dokazuje, že se chování agentů zlepšuje. Všechny tři lodě společně ve stejném PR. Novela je atomová. Dílčí pozměňovací návrhy, které slibují přidat ověření později, jsou zamítnuty - později nepřijde a neověřitelným pravidlem je dekorace.

**Napište evals a rubriky, než si myslíte, že je potřebujete.** Eval je ráčna. Bez něj jsou pozměňovací návrhy přijímány v dobré víře a ústava se mění. Rubrika hodnotí chování agenta v realistických scénářích. Každé nové pravidlo vytváří alespoň jeden scénář. Rubrika vytváří číselné skóre. Změna projde pouze tehdy, pokud skóre pracovního stromu dosáhne nebo překročí základní linii.

**Dokumentujte, co můžete a nemůžete zakrýt. O pokrytí si nelži.**

Na začátku tvrdé omezení dostupnosti deklarovalo, že nové interaktivní povrchy uživatelského rozhraní vyžadují pokrytí e2e a11y pomocí axe-core. Tohle mi přišlo komplexní. V praxi to bylo naivní. axe-core zpracovává smysluplnou podmnožinu WCAG – zachycuje chybějící popisky, strukturu orientačních bodů, pořadí zaostření a kontrast v případech, kdy je DOM plně vykreslen a barvy jsou vyřešeny. Nezachycuje logiku oznámení čtečky obrazovky, vzory kognitivní zátěže, složité kontrakty na klávesnici widgetů ani problémy s kontrastem zahrnující přechody a uzly obrázků SVG, kde nelze vypočítanou barvu vyřešit.

Mít `[HC-A11Y-GATE]` s axe-core v ověření neznamená, že chyby a11y jsou nulové. To znamená, že specifická sada pravidel axe-core běží proti vykreslenému DOM. Rozdíl je enormně důležitý v nárocích na pokrytí PR.

Opravou byl rozklad. Namísto „axe-core clean“ bylo ověření přepsáno tak, aby vyjmenovalo, která kritéria úspěšnosti WCAG sada pravidel pro axe-core deterministicky pokrývá (1.1.1 pro netextový obsah, 1.3.1 pro informace a vztahy, 1.4.3 pro kontrast, kde je rozlišitelné, 4.1.2 pro jméno/role/hodnotu) a která mají 21.3 automatické záhlaví senzoru sémantika štítků, všechny 3.x Srozumitelná kritéria). Sekce známých mezer dimenze auditu nyní výslovně uvádí: axe-core tato kritéria zpracovává; u nich je vyžadováno ruční skenování. PR recenzenti vidí skutečné pokrytí, nikoli falešně důvěryhodné shrnutí.

Širší princip: u každého ověření zdokumentovat, co zachytí a co ne. "Security lint pass" neznamená, že kódová základna je bezpečná. "axe-core clean" neznamená, že vyhovuje WCAG 2.2 AA. Pojmenujte mezeru. Přihlaste se do dimenze auditu. Vyžadujte ruční skenování povrchu mezery. Nedovolte, aby automatická kontrola nahradila lidský úsudek, který nemůže nahradit.

Krok 5 – Jak píšeme pozměňovací návrhy

Změny téměř nikdy nezačínají jako pozměňovací návrhy. Začínají jako brouci.

Objeví se brouk. Oprava je použita. Před odesláním si `/reflect` klade jednu otázku: je to jednorázové, nebo v ústavě chybí něco, co by zachytilo tuto třídu selhání? Pokud je odpověď jednorázová, oprava se odešle a to je konec. Pokud odpověď zní, že něco chybí, je vyvoláno `/constitute`.

**Cesta /reflect -> mezera -> změna.** `/reflect` prozkoumá opravu a klasifikuje ji: mezera v konstituci (žádné pravidlo nepokrývalo tuto třídu selhání) nebo mezera v ověřování (pravidlo existovalo, ale žádná automatická kontrola ho nevynucovala). Obě cesty vedou k `/constitute`. Konstituční mezera vytváří nový HC. Ověřovací mezera vede k přísnějšímu ověření stávajícího HC – obvykle nová podsekce dimenze auditu, nové pravidlo skeneru nebo nový scénář hodnocení.

**Tři požadované artefakty.** `/constitute` odmítá pokračovat bez všech tří ve stejném PR:

• **Pravidlo delta.** Přesná změna textu, klasifikace: nové pravidlo, upravené znění, přemístění (nahradit a odstranit staré), nahrazení (zvýšit laťku se starým jako podlaha) nebo přemístění. Duplikáty jsou odmítnuty na první pohled.
• **Mechanismus ověření.** Konkrétní brána, která zachytí budoucí porušení – název testu, ID pravidla lint, podsekce dimenze auditu, kontrola výstupního kódu skeneru nebo scénář hodnocení chování. Musí existovat v době odevzdání. Pravidla bez zjistitelných porušení jsou dekorativní.
• **Eval scénář.** Uloženo v `docs/metodology/eval/scenarios/<id>.md`. Popisuje realistickou situaci, kdy staré pravidlo vytváří nesprávné chování agenta a nové pravidlo vytváří správnou odpověď, kterou lze skórovat.

**Ráčka.** Po schválení všech tří artefaktů se změna aplikuje na pobočku. Eval běží proti pravidlům hlavní větve a pravidlům pracovního stromu. Rubrika boduje obojí. Pass vyžaduje v každém scénáři pracovní strom >= main. Regrese novelu zablokuje, dokud nebude znění opraveno. Západka není volitelná pro zjevné úpravy: stále mohou produkovat jemné regrese a eval je jediný mechanismus, který je zachytí, než přistanou.

**Retroaktivní sweep.** Dodatek opravuje pravidlo pro nový kód okamžitě: Rozsah rozdílu `/audit` znamená, že nová práce splňuje novou hranici od okamžiku, kdy dojde k úpravě. Již existující kód, který porušuje nové pravidlo, je zpracován samostatným zametacím PR ve frontě přes `/rollout`. Místo opravy nemusí opravit každou již existující instanci. To by učinilo úpravy neúměrně drahými. Místo toho: nový kód se okamžitě shodne s novým pruhem, starý kód je ve frontě zavádění a sweep PR nese svůj vlastní důkaz, že již existující instance jsou vyřešeny.

Čtyři platné spouštěče pro `/constitute` jsou: chyba, incident, pitva a nový smluvní standard. Návrhy ve tvaru "pravděpodobně bychom měli..." bez žádného ze čtyř spouštěčů jsou odmítnuty a místo toho přesměrovány na `/reflektovat`.

Krok 6 – Jak to rozbalíme

Portable Methodology Kit (`EDD - Portable Methodology Kit.md`) je samostatný dokument, který předáte jakémukoli agentovi AI s pokynem ke spuštění `/begin`. Agent zkontroluje repo, spustí zjišťovací průchod, potvrdí s vámi zjištěné hodnoty v jediné tabulce, zeptá se pouze na to, na co zjišťování nemůže odpovědět, a vydá minimální životaschopné lešení pro váš projekt. Jedno sezení pro vybudování plné infrastruktury EDD.

To, jak jej rozbalíte, zcela závisí na tom, zda začínáte znovu, nebo jej zavádíte do existující kódové základny. Tyto dvě cesty jsou natolik odlišné, že je lze léčit samostatně.

**Greenfield.** U nového projektu vložte každé pravidlo, na které si vzpomenete, do ústavy prvního dne. Nemáte žádný již existující kód k auditu, žádné týmové postupy k ochraně, žádné existující PR pro dědečka. Náklady na přísnost v první den jsou téměř nulové. Přidejte všechna pevná omezení, všechny dimenze auditu, všechna pravidla v rozsahu cesty. Poté spusťte smyčku. Rychle zjistíte, kde konstituce vytváří třenice: vytvářejte časy, které se zvětšují, protože každá změna spouští úplný audit, testovací sady, které jsou pomalé, protože laťka pokrytí je nastavena příliš vysoko na současnou složitost, rozpočty tokenů, které jsou napjaté, protože kanonické tělo je příliš podrobné. Přísnost prvního dne tyto problémy odhaluje ve vývoji, nikoli ve výrobě. Poté optimalizujete: dotáhněte stavební brány, upravte pravidla krytí, ořízněte ústavní těleso na minimum. Stabilizujete vše najednou, bez ovlivnění zákazníků, bez přerušení týmu. Krátkodobé náklady jsou o něco pomalejší první sprint. Dlouhodobý zisk je konstituce, která byla zátěžově testována od prvního commitu.

**Brownfield.** Existující kódová základna má existující tým, stávající postupy a existující PR, které se neřídily EDD. Rozvíjení je zde přírůstkové a musí být aditivní, nikoli rušivé. Cílem prvního měsíce není dovybavit každé minulé rozhodnutí – je to začít generovat kolaterál, díky kterému je EDD důvěryhodný: jedna dimenze auditu, která zachytí něco skutečného, ​​jedno pevné omezení, které automatizuje kontrolní kontrolu, kterou tým již prováděl ručně, jeden cyklus úprav od konce do konce. Použijte stávající signály kvality týmu jako surovinu. Pokud tým již má pravidlo lint pro zabezpečení, přidejte `[HC-SECURITY-LINT]` a nasměrujte jej na stávající bránu – pro vývojáře se nic nemění, ale nyní ústavní záznam odráží to, co brána skutečně vynucuje.

Základní pravidlo v brownfieldu zní: získat spojence, než vyhrát argumenty. Během prvního týdne neprosazujte úplnou konstituci, která se dotkne každé oblasti kódové základny. Začněte s dimenzí, na které už tým nejvíce záleží – obvykle bezpečnost nebo spolehlivost. Ukažte, že proces pozměňovacích návrhů zaceluje skutečnou mezeru, kterou již viděli. Nechte ráčnu složit odtud. Tým, který viděl EDD zachytit jednu skutečnou chybu, která proklouzla jejich stávajícím procesem, uvolní místo pro další pravidlo. Tým, který se setká s EDD jako s dokumentem, který jim říká, že všechno dělali špatně, ho obejde.

**Co to odemkne.** Důvodem, proč projít rozbalováním, ať už na zelené louce nebo brownfieldu, není ústavní dokument. Je to to, co umožňuje ústava, jakmile je ověřovací aparát spuštěn.

Kvalita výrobního kódu a rychlost dodávky se skládají dohromady způsobem, který je skutečně kontraintuitivní, pokud jste to neviděli. Inženýři zastaví přepínání kontextu, aby ladili regrese, které by smyčka zachytila. Kontrolní cykly se zkracují, protože PR nesou důkazy místo vysvětlení. Audit probíhá automaticky a označí problémy, které by zachytil nejzkušenější recenzent, což mu umožňuje soustředit se na architektonická rozhodnutí, která skutečně vyžadují jeho úsudek.

Nejjasnější důkaz toho: nový inženýr, který se připojí k týmu, s plným přístupem ke konstituci, specifikacím funkcí a smyčce, může do 48 hodin od prvního dne zařadit příspěvek k funkci v produkční kvalitě. Žádná výměna hračky. Nejedná se o aktualizaci dokumentace. Skutečná vlastnost s důkazy, která prošla úplným auditem. Není to náhoda a není to nijak zvlášť neobvyklý inženýr. Zábradlí umožňuje jakémukoli kvalifikovanému vývojáři pracovat na týmovém standardu kvality od prvního dne, protože standard kvality je zapsán, ověřitelný a vynucován automaticky, nikoli jako institucionální znalost v hlavách toho, kdo tam byl nejdéle.

To je tvar, kterého dosahuje: tým, kde AI dělá ověřovací dřinu, ochranné zábradlí zachycuje třídy selhání, které by jinak proklouzly kontrolou kódu, a inženýři tráví čas přemýšlením nad problémy, které ve skutečnosti vyžadují technický úsudek.

To bylo ověřeno v různých měřítcích – nejprve sólové projekty, poté středně velké týmy a poté organizace podnikového rozsahu. Mechanika drží napříč všemi třemi. Náklady na rozbalení jsou různé (samostatný vývojář může přeskočit registry požadavků a kontrolu protivníků napříč dodavateli; potřebuje je podnikový tým). Kadence změn je odlišná (sólový projekt může trvat týdny mezi vyvoláním `/constitute`; podnikový tým s více přispívajícími agenty je spouští týdně). Ale základní smyčka, ráčna a požadavek na důkazy se chovají stejně bez ohledu na velikost týmu. Podlaha kvality jde pouze nahoru a ověřovací mašinérie ji tam udržuje, aniž by byla závislá na tom, kdo je ten týden v místnosti nejzkušenějším recenzentem.

AI háčky

Konstituce řídí chování agenta prostřednictvím načteného kontextu. Háky to prosazují v okamžiku akce, než je práce již hotová a PR je již otevřené. Bez háčků je porušení zachyceno při kontrole: agent již napsal kód, existuje PR a jeho náprava znamená opakování práce. U háčků dojde k zachycení před jakýmkoli stisknutím klávesy.

**Claude Code i GitHub Copilot spustí háček při okamžitém odeslání.** Když přijde nový úkol, hák se spustí dříve, než agent cokoli udělá. Jeho úkol: zkontrolovat, zda úkol není triviální, poté znovu zapojit seznam úkolů do smyčky `/wow` - sekvence 10 kroků EDD, kterou musí agent před odesláním čehokoli dodržet.

Agent, který dosáhne kroku 5, aniž by dokončil kroky 1-4, narušil smyčku. Hák vytvoří sekvenci na začátku relace - ne po faktu.

**Claude Code** navíc spustí háček před voláním nástroje před jakýmkoli zápisem souboru, příkazem terminálu nebo operací git. O potvrzení se nelze pokusit, pokud nebyly splněny kroky smyčky.

**GitHub Copilot** navíc spouští háček pro vytváření PR. Než je popis PR dokončen, spustí hák `/audit` v režimu sebekontroly – zachytí porušení dimenzí, chybějící důkazy a prázdné testovací plány, než člověk vůbec uvidí koncept. To, co se dostane k recenzentovi, je již předem prověřeno.

**Codex a další agenti** nemají v době psaní tohoto textu žádný nativní povrch háku. Záložní je robot pro sledování CI, který komentuje PR ihned po vytvoření a označí porušení. Je to zpětná klapka, ne brána prvního povrchu - práce je již hotová, když vystřelí, takže nebrání přepracování, které háky eliminují.

U projektu s aktivními háčky jsou porušení opravena přímo během relace. Agent zachytí mezeru, vytvoří důkazy a zahrne je od začátku. Čas kontroly klesá. Přepracování zmizí. Konstituce se přesune z dokumentu, který agent čte, na omezení, ve kterém agent působí v reálném čase.

Dodatek - Úplná ústava

Následuje skutečná `CONSTITUTION.md` z tohoto projektu - jediný vývojářský, plně autonomní vývojový projekt s podporou umělé inteligence. Řídí všechny netriviální změny provedené v této kódové základně. Toto není šablona ani ilustrace. Toto je živý dokument načtený každým agentem při každé relaci.