У 2026 році корпоративна команда створила агента, який зчитував квитки керування інцидентами, генерував з них аутоморфологію та автоматично створював елементи ремонту. Другий агент із тієї ж команди спостерігав за новими робочими елементами та відкрив чернетки PR для кожного з них, щоб допомогти розробникам розпочати роботу. Розробник переглянув одну з цих рекламних заяв, визнав її розумною, схвалив, і її об’єднали з основною гілкою.

**Проблема полягала в тому, що зміна була повністю сфабрикованою.**

Агент винайшов правдоподібне вирішення проблеми, яка не існувала в описаному вигляді. Зміна регресувала до реального сценарію виробництва. Помітив реальний клієнт. Стався збій.

Ось чому існує Конституція EDD.

Конституція — це єдиний файл, який керує кожною нетривіальною зміною кодової бази. Він визначає, як виглядає завершена зміна, які докази вона має містити, що має охоплювати масштабний аудит і як можуть розвиватися самі правила. Кожен агент і кожна людина, яка торкається репо, завантажує його під час кожного сеансу. Планка тільки тріскається вгору.

У цьому дописі крок за кроком розповідається про конституцію: інцидент, який спонукав її, питання дизайну, на які вона відповідає, як вона структурована, як вона була написана (і що ми помилилися на початку), як працюють поправки та як повний комплект розгортається в новому репо.

Крок 1 - Що це таке

Цей інцидент є найяскравішою ілюстрацією того, що режим відмови EDD призначений для запобігання. У агента не виникли галюцинації випадково. Це створило послідовний, читабельний, професійно оформлений PR. Розробник, який перевірив його, зробив те, що роблять розробники: вони прочитали намір, визнали намір правдоподібним і схвалили. Розрив не був уважністю. Прогалиною була відсутність доказів. Ніщо в процесі перегляду не вимагало від агента демонстрації того, що проблема, яку він заявляв про вирішення, насправді існувала, що виправлення стосувалося реальної поведінки або що зміна нічого не регресувала.

EDD усуває цю прогалину єдиною жорсткою вимогою: якщо агент не може довести це, завдання не виконано. Доказ – це не підсумок. Доказ не є впевненим твердженням. Доказом є артефакт, який можна перевірити незалежно: невдалий тест, вихід сканера, знімок екрана до/після, відмінність плану. PR містить артефакт або PR є неповним.

Конституція живе за адресою `docs/methodology/CONSTITUTION.md`. Кожен агент ШІ, налаштований у проекті, завантажує його під час кожного сеансу через власний файл завантажувача. Тіло є агентно-нейтральним: немає назв інструментів, немає синтаксису для певної платформи. Він визначає дев’ять основоположних принципів, жорсткі обмеження зі стабільними ідентифікаторами слизняків, 10-етапний цикл реалізації, параметри аудиту, критерії прийнятності доказів для кожного типу змін, тривіальні виключення для роботи з низьким рівнем ризику та положення про поправки.

Кожне жорстке обмеження має слаг на кшталт `[HC-EVIDENCE-BEFORE]` і оголошує три речі: панель (що має бути істинним), перевірку (як перевіряється дотримання) і джерело шаблону (який файл інструкцій розробляє вказівки щодо впровадження).

10-кроковий цикл — це операційне серце: визначте виконано, напишіть тест, який підтверджує прогалину, спостерігайте за його невдачею, охоплюйте попередні докази, впроваджуйте, спостерігайте за проходженням тесту, охоплюйте післядокази, перевіряйте документи, перевірка заявлених параметрів, а потім перевірка людьми. Кроки з 1 по 4 виконуються перед будь-яким редагуванням реалізації. Наказ є конституційним, оскільки цей інцидент показує, що саме відбувається, коли це не так.

Як додатковий запобіжний захід, EDD запозичив основний принцип із TDD: перед початком роботи необхідно довести, що сценарій не працює. Доказ, який пройшов наприкінці зміни, сам по собі не є достатнім доказом: якщо тест також пройшов перед зміною, можливо, агент виправив щось, що ніколи не було зламано. Це особливий режим збою в робочих процесах за допомогою штучного інтелекту: агент генерує правдоподібне виправлення, перевірка виконується, а зміна надсилається так, ніби вона вирішила справжню проблему. Вимагання задокументованого стану несправності перед початком реалізації закриває цю прогалину. Крок до доказів — це не просто базова лінія для порівняння — це доказ того, що проблема, яку вирішують, була реальною.

З усіх жорстких обмежень, які постали через конституцію, два виявили більше дефектів, ніж усі інші разом узяті, і вони, мабуть, є єдиним найважливішим оновленням, яке EDD робить для будь-якого робочого процесу за допомогою штучного інтелекту: `[HC-EVIDENCE]` і `[HC-EVIDENCE-INTEGRITY]`. Обидва оголошені в `.github/copilot-instructions.md` - файлі, який активно завантажується, і знаходиться в контексті агента під час кожного сеансу.

`[HC-EVIDENCE]` вимагає, щоб кожен PR містив фактичні артефакти до і після - не описи того, що показуватимуть артефакти, не підсумки того, що, на думку агента, сталося, а вихідні дані. `[HC-EVIDENCE-INTEGRITY]` йде далі: він вимагає, щоб докази в PR можна було відстежити до фактично виконаної роботи. Він підтверджує, що PR містить те, що він містить.

Разом ці два обмеження виявили сотні помилок, створених штучним інтелектом, перш ніж вони дійшли до розгляду. Режим невдачі, від якого вони захищаються, не є галюцинацією в очевидному сенсі. Це більш тонка поведінка: агент відзначає виконання завдання, пише впевнений PR-опис і включає те, що читається як доказ, але докази були складені, а не зафіксовані. Агент описав, як має виглядати вихід, а не запускав команду та включав фактичний результат.

`[HC-EVIDENCE-INTEGRITY]` особливо ефективно вловлює те, що можна назвати шаблоном "Я не міг цього зробити". Агент, який стикається зі складним або незнайомим завданням, іноді стверджуватиме, що завдання неможливе або виходить за межі його компетенції, замість того, щоб спробувати його виконати. Твердження часто оформляють як обмеження - інструмент, якого не існує, обмеження, яке перешкоджає підходу, середовище, яке не підтримує операцію. `[HC-EVIDENCE-INTEGRITY]` висвітлює це: якщо агент стверджує, що завдання неможливо виконати, PR має показати докази того, що завдання справді було виконано, а перешкода справжня. «Мені не вдалося запустити набір тестів» вимагає вихід терміналу, який показує помилку, а не заяву про те, що сталася помилка. Без цієї вимоги ухилення агента від складної роботи буде невидимим під час перевірки, і завдання надсилатиметься невиконаним, наче воно виконане.

Крок 2 - Як ми сюди потрапили

Конституція не є накопиченням вивчених уроків. Це відповідь на одне питання щодо дизайну, поставлене на початку: як змусити агента штучного інтелекту щоразу доводити свою роботу таким чином, який неможливо обійти та не залежить від того, що людина пам’ятає запитати?

Відповідь на це питання викликала декомпозицію. Доказ вимагає знати, як виглядає зроблене перед початком впровадження - це стало етапом документування. Для підтвердження потрібен тест, який провалиться до зміни та пройдений після, що спричинило дисципліну про непрохідний/прохідний тест. Для доказу потрібен попередній стан, який було зафіксовано до того, як реалізація торкнулася чогось, що створило вимогу попередніх доказів. Для доказу потрібен незалежний аудит, який виявляє те, що не може бути підтверджене кожною зміною – це сформувало параметри аудиту. І доказ має витримати процес рецензування без пом’якшення – це створило жорстке обмеження, що рецензент є останніми воротами та єдиними воротами, які не можуть бути автоматизовані.

У результаті виходить петля з 10 кроків. Кожен крок існує, тому що його видалення створює дірку, через яку може пройти неперевірена робота. Цикл не є контрольним списком. Це причинно-наслідковий ланцюг.

Звідси виникло запитання: які категорії збоїв може створити агент, які цикл не вловлює за замовчуванням? Це породило жорсткі обмеження. Безшумний лінт під час зниження рівня правил створив `[HC-SECURITY-LINT]`. Помилка кодування символів у розгорнутому артефакті спричинила «[HC-ASCII-PUNCT]». Кожен HC закриває певний клас відмови за допомогою певної автоматизованої перевірки. Правила, які не могли назвати перевірку, були відхилені: якщо перевірка не може бути автоматизована, правило є бажаним, а не конституційним.

Останнім питанням проекту було: хто керує самою конституцією? Відповідь - тріскачка. Конституція може бути тільки жорсткішою. Поправки повинні містити докази того, що поведінка агента покращується або зберігається. Підлога ніколи не опускається. Це означає, що конституції можна довіряти з часом так, як не можна довіряти посібнику зі стилю життя: кожна версія суто сильніша за попередню.

Крок 3 - Як це структуровано

Конституція має тришарову архітектуру.

**Рівень 1: Канонічний корпус.** Один файл, `docs/methodology/CONSTITUTION.md`. Це джерело правди. Він агентно-нейтральний: він не робить припущень щодо того, який інструмент ШІ використовується. Він визначає принципи, жорсткі обмеження, цикл, параметри аудиту, критерії прийняття доказів, виключення тривіальності та положення про самовдосконалення. Коли тіло перевищує приблизно 250 рядків, правила, які застосовуються до конкретного шаблону шляху, розкладаються у файли з областю шляху, із однорядковим покажчиком, що залишається в тілі.

**Рівень 2: Завантажувачі агентів.** Кожен налаштований агент отримує рівно один файл завантажувача в місці, яке агент охоче завантажує. Для GitHub Copilot це `.github/copilot-instructions.md`. Для Клода це `CLAUDE.md`. Завантажувач імпортує або вбудовує тіло конституції залежно від того, що наразі підтримує платформа. Завантажувач механічно рендериться з канонічного тіла; це не відредаговано вручну. Якщо в проекті використовуються три інструменти штучного інтелекту, є три файли завантажувача, усі вони відображають однаковий конституційний вміст.

**Рівень 3: правила з областю шляху.** Деякі правила застосовуються лише до певних типів файлів. Правила доступності та локалізації застосовуються до файлів JSX і CSS, а не до шаблонів інфраструктури. Ці правила живуть у файлах інструкцій із глобусом frontmatter:

Агент завантажує ці файли лише тоді, коли торкається відповідного шляху. Це зберігає обмежений бюджет контексту завантаження (основні правила завжди присутні, спеціалізовані правила завантажуються на вимогу) і запобігає появі вказівок щодо доступності під час редагування шаблону Bicep.

Допоміжні файли доповнюють структуру: елементи команд `/constitute` у `.github/prompts/`, папки для кожної функції в `docs/methodology/features/`, сценарії оцінки в `docs/methodology/eval/scenarios/` та `verify-sequence.yaml` у корені сховища, що визначає порядок шлюзів CI.

Крок 4 - Як ми це написали

**Контекст — це все. Те, що не в контексті, мертве для агента.**

Це єдине найважливіше розуміння щодо написання конституції розвитку, керованого ШІ. Правило, яке існує у файлі, який агент ніколи не завантажує, не існує. Жорстке обмеження, приховане в документі, який завантажується лише тоді, коли торкається певного шляху до файлу, не є жорстким обмеженням для будь-якого іншого шляху. Конституція завжди має бути в контексті, і все, що завжди має застосовуватися, має бути там.

Це обумовлює три авторські рішення:

**Оптимізація токенів не підлягає обговоренню.** Канонічна частина містить менше 300 рядків і 8 тисяч токенів. Кожна поправка має підтримувати або покращувати ефективність маркерів – багатослівні правила, які виконують те, що можуть стислі, відхиляються лише на цих підставах. Це не перевага стилю. Це обмеження навантаження. Якщо конституція перевищує бюджет, агенти в менших контекстних вікнах починають її скорочувати, а усічені правила не є правилами.

**Умовне завантаження через frontmatter.** Правила, які застосовуються лише до певних типів файлів, вилучаються з канонічного тіла та до файлів інструкцій із областю шляху з оголошенням glob frontmatter. Інструкції щодо доступності та локалізації завантажуються лише тоді, коли агент торкається JSX або CSS. Вказівки інфраструктури завантажуються лише тоді, коли агент торкається біцепса. Канонічне тіло зберігає однорядковий покажчик. Агент завантажує файл із областю шляху лише тоді, коли він доречний. Це не просто ефективність – це запобігає появі вказівок щодо доступності як відволікання під час редагування інфраструктури, що навчає агента ігнорувати їх.

У цьому проекті не використовуються файли правил, розділені на передній матеріал, оскільки структура досить мала, щоб повністю завантажуватись у контексті – один розробник, зосереджена область, мінімальний набір правил. Для великих команд обчислення змінюється. Проект корпоративного масштабу, який зараз виконує EDD, має 75 жорстких обмежень щодо безпеки, відповідності, доступності та специфічних для платформи вимог. Вбудовування всіх 75 в один файл швидкого завантаження призвело б до того, що конституція значно перевищить бюджет контексту для більшості агентів. Розділення Frontmatter зберігає канонічне тіло менше ніж 250 рядків — підсумковий вказівник на домен — і відкладено завантажує повну деталь правила лише тоді, коли агент торкається відповідних шляхів. Статура залишається швидкою і сухою. Правила залишаються повними. Вартість токена залишається обмеженою.

**Поправки як одиниці зміни.** Поправка до Конституції не є зміною слова у файлі розцінки. Це набір із трьох артефактів: точна дельта правила, механізм перевірки, який виловлюватиме майбутні порушення, і сценарій поведінкової оцінки, який доводить, що поведінка агента покращилася. Усі три кораблі разом в одному PR. Поправка атомарна. Часткові поправки, які обіцяють додати верифікацію пізніше, відхиляються - пізніше не приходить, а правило, що не перевіряється, є прикрасою.

**Напишіть evals і рубрики, перш ніж ви подумаєте, що вони вам потрібні.** eval - це тріскачка. Без нього поправки приймаються добросовісно, ​​а конституція дрейфує. Рубрика оцінює поведінку агента за реалістичними сценаріями. Кожне нове правило створює принаймні один сценарій. Рубрика створює числову оцінку. Поправка приймається, лише якщо оцінка робочого дерева відповідає або перевищує базову лінію.

**Документуйте, що ви можете, а що не можете покрити. Не обманюйте себе щодо покриття.**

На початку жорстке обмеження доступності оголосило, що нові інтерактивні поверхні інтерфейсу користувача вимагають покриття e2e a11y за допомогою axe-core. Це відчувалося всебічно. На практиці це було наївно. axe-core обробляє значущу підмножину WCAG - він виловлює відсутні мітки, структуру орієнтирів, порядок фокусування та контраст у випадках, коли DOM повністю відтворено, а кольори розпізнано. Він не вловлює логіку сповіщень програми зчитування з екрана, шаблони когнітивного навантаження, складні контракти клавіатури віджетів або проблеми з контрастом, пов’язані з градієнтами та вузлами зображень SVG, де неможливо вирішити обчислений колір.

Наявність `[HC-A11Y-GATE]` з axe-core під час перевірки не означає, що помилки a11y відсутні. Це означає, що певний набір правил axe-core працює проти відрендереного DOM. Різниця має величезне значення в заявах про PR-висвітлення.

Виправленням було розкладання. Замість «axe-core clean» верифікацію було переписано, щоб перерахувати, які критерії успіху WCAG детерміновано охоплює набір правил axe-core (1.1.1 для нетекстового вмісту, 1.3.1 для інформації та зв’язків, 1.4.3 для контрасту, де це можливо, 4.1.2 для імені/ролі/значення) і які мають нульове автоматизоване покриття (1.3.3 сенсорні характеристики, 2.4.6 семантика заголовків і міток, усі зрозумілі критерії 3.x). У розділі про відомі прогалини параметра аудиту тепер чітко зазначено: axe-core обробляє ці критерії; для них потрібне ручне сканування. PR-рецензенти бачать фактичне висвітлення, а не фальшивий підсумок.

Більш широкий принцип: для кожної перевірки документуйте, що вона виявляє, а що ні. "Security lint passs" не означає, що кодова база безпечна. "axe-core clean" не означає, що відповідає WCAG 2.2 AA. Назвіть розрив. Зареєструйте його в розмірі аудиту. Потрібне ручне сканування поверхні зазору. Не дозволяйте автоматизованій перевірці замінити людське судження, яке вона не може замінити.

Крок 5 - Як ми пишемо поправки

Поправки майже ніколи не починаються як пропозиції поправок. Вони починаються як жуки.

Виявляється помилка. Виправлення застосовано. Перед надсиланням `/reflect` задає одне запитання: чи це одноразовий випадок, чи чогось не вистачає в структурі, що могло б виявити цей клас помилок? Якщо відповідь одноразова, виправлення відправляється, і це кінець. Якщо відповідь полягає в тому, що чогось не вистачає, саме тоді викликається `/constitute`.

**/reflect -> gap -> шлях поправки.** `/reflect` перевіряє виправлення та класифікує його: прогалина в структурі (жоден з правил не охоплює цей клас помилок) або прогалина перевірки (правило існувало, але автоматизована перевірка його не виконувала). Обидва шляхи ведуть до `/constitute`. Розрив конституції створює новий HC. Проміжок у верифікації створює більш сувору перевірку існуючого HC - зазвичай це новий підрозділ параметрів аудиту, нове правило сканера або новий сценарій оцінки.

**Три необхідні артефакти.** `/constitute` відмовляється продовжувати без усіх трьох в одному PR:

• **Дельта правила.** Точна зміна тексту, класифікована: нове правило, змінене формулювання, переміщення (заміна та видалення старого), витіснення (підняття планки зі старим у якості мінімального) або переміщення. Дублікати відкидаються відразу.
• **Механізм перевірки.** Конкретний шлюз, який виловить майбутнє порушення – ім’я тесту, ідентифікатор правила lint, підрозділ параметрів аудиту, перевірка коду виходу сканера або поведінковий сценарій оцінки. Він повинен існувати під час фіксації. Правила без виявлених порушень є декоративними.
• **Сценарій Eval.** Зберігається в `docs/methodology/eval/scenarios/<id>.md`. Описує реалістичну ситуацію, коли старе правило призводить до неправильної поведінки агента, а нове правило дає правильну відповідь, яку можна оцінити.

**Храповик.** Після схвалення всіх трьох артефактів поправка застосовується до гілки. Eval суперечить правилам основної гілки та правилам робочого дерева. Рубрика оцінює обидва. Pass вимагає робочого дерева >= main у кожному сценарії. Регресія блокує поправку, доки формулювання не буде виправлено. Храповий механізм необов’язковий для очевидних поправок: вони все ще можуть викликати тонкі регресії, а eval є єдиним механізмом, який ловить їх, перш ніж вони приземляться.

**Ретроактивна перевірка.** Поправка миттєво виправляє правило для нового коду: діапазон відмінностей `/audit` означає, що нова робота відповідає новим вимогам з моменту появи поправки. Попередньо існуючий код, який порушує нове правило, обробляється окремою перевіркою PR, яка ставиться в чергу через `/rollout`. Сайт виправлення не потребує вбудованого виправлення кожного попередньо існуючого екземпляра. Це зробило б поправки непомірно дорогими. Замість цього: новий код одразу відповідає новому плану, старий код стоїть у черзі на розгортання, а інформаційний звіт про очищення містить власні докази того, що існуючі випадки вирішено.

Чотири дійсні тригери для `/constitute` це: помилка, інцидент, post mortem і новий договірний стандарт. Пропозиції у формі «ми, ймовірно, повинні...» без жодного з чотирьох тригерів, відхиляються та натомість направляються до `/reflect`.

Крок 6 - Як ми це розгортаємо

Portable Methodology Kit (`EDD - Portable Methodology Kit.md`) — це окремий документ, який ви передаєте будь-якому агенту штучного інтелекту з інструкціями щодо запуску `/begin`. Агент перевіряє сховище, запускає проход виявлення, підтверджує виявлені значення разом з вами в одній таблиці, запитує лише те, на що відкриття не може відповісти, і створює мінімально життєздатні каркаси для вашого проекту. Один сеанс для встановлення повної інфраструктури EDD.

Те, як ви його розгортаєте, повністю залежить від того, чи починаєте ви заново, чи переносите його в існуючу кодову базу. Ці два шляхи досить різні, щоб розглядати їх окремо.

**Грінфілд.** У новому проекті внесіть у конституцію кожне правило, яке тільки можете придумати, з першого дня. У вас немає попереднього коду для аудиту, немає командних практик, які потрібно захистити, немає існуючих PR-повідомлень для дідуся. Ціна суворості в перший день майже нульова. Додайте всі жорсткі обмеження, усі параметри аудиту, усі правила з областю шляху. Потім запустіть цикл. Те, що ви швидко виявите, полягає в тому, де конституція створює тертя: тривалий час створення, тому що кожна зміна запускає повний аудит, набори тестів, які повільні, оскільки планка охоплення встановлена ​​надто високою для поточної складності, бюджети маркерів, які обмежені, оскільки канонічний текст занадто багатослівний. Строгість першого дня виявляє ці проблеми під час розробки, а не у виробництві. Потім ви оптимізуєте: посилюєте ворота збірки, регулюєте правила покриття, обрізаєте конституційне тіло до мінімуму. Ви стабілізуєте все одразу, не зачіпаючи клієнтів і не порушуючи роботу команди. Короткострокова вартість — це трохи повільніший перший спринт. Довгострокова перевага — це конституція, яка пройшла стрес-тестування з першого коміту.

**Браунфілд.** Існуюча кодова база має наявну команду, існуючі практики та існуючі PR, які не дотримувалися EDD. Розгортання тут є поступовим і має бути додатковим, а не руйнівним. Мета першого місяця полягає не в тому, щоб модифікувати кожне минуле рішення, а в тому, щоб почати генерувати заставу, яка робить EDD надійною: один параметр аудиту, який фіксує щось реальне, одне жорстке обмеження, яке автоматизує перевірку перегляду, яку команда вже робила вручну, один цикл внесення змін від кінця до кінця. Використовуйте існуючі сигнали якості команди як вихідний матеріал. Якщо команда вже має правило lint для безпеки, додайте `[HC-SECURITY-LINT]` і направте його на існуючий шлюз - нічого не зміниться для розробників, але тепер конституційний запис відображає те, що шлюз фактично виконує.

Кардинальне правило на застарілих територіях таке: завойовуйте союзників, перш ніж перемагати в суперечках. Не проштовхуйте повну конституцію, яка стосується кожної області кодової бази, протягом першого тижня. Почніть з того аспекту, який найбільше цікавить команду – як правило, безпеки чи надійності. Покажіть, що процес внесення поправок усуває реальну прогалину, яку вони бачили раніше. Нехай тріскачка складеться звідти. Команда, яка бачила, як EDD виявила одну реальну помилку, яка проскочила через їхній існуючий процес, звільнить місце для наступного правила. Команда, яка стикається з EDD як документом, який повідомляє їм, що вони робили все неправильно, обійде його.

**Що це відкриває.** Причиною для проходження розгортання, незалежно від того, чи це територія, яка знаходиться на ґрунті, чи ні, не є статутний документ. Це те, що конституція дозволяє після того, як верифікаційний механізм запрацює.

Якість виробничого коду та швидкість доставки поєднуються разом таким чином, що є справді суперечливим, якщо ви цього не бачили. Інженери припиняють перемикання контексту, щоб налагодити регресії, які міг би вловити цикл. Цикли перегляду скорочуються, оскільки PR несуть докази, а не пояснення. Аудит виконується автоматично та позначає проблеми, які виявив би найдосвідченіший рецензент, звільняючи рецензента зосередитись на архітектурних рішеннях, які насправді вимагають його оцінки.

Найяскравіший доказ цього: новий інженер, який приєднується до команди, маючи повний доступ до структури, специфікації функцій і циклу, може зробити внесок продуктивної якості в основний протягом 48 годин після свого першого дня. Не зміна іграшок. Not a documentation update. Реальна характеристика, з доказами, пройшовши повний аудит. Це не випадковість і не особливо незвичайний інженер. Огорожі дають змогу будь-якому кваліфікованому розробнику працювати за стандартом якості команди з першого дня, оскільки стандарт якості записаний, перевіряється та впроваджується автоматично, а не переноситься як інституційне знання в головах того, хто довше працює.

Саме такої форми він досягає: команда, де штучний інтелект виконує перевірку, огорожі вловлюють класи відмов, які інакше проскочили б під час перевірки коду, а інженери витрачають час на роздуми над проблемами, які насправді потребують інженерної оцінки.

Це було перевірено в різних масштабах — спочатку соло-проекти, потім команди середнього розміру, а потім організації корпоративного масштабу. Механіка тримається всіх трьох. Вартість розгортання інша (окремий розробник може пропустити реєстри вимог і змагальну перевірку між постачальниками; вони потрібні команді підприємства). Порядок внесення поправок інший (для сольного проекту між викликами `/constitute' можуть тривати тижні; корпоративна команда з кількома агентами, які беруть участь, запускає їх щотижня). Але основний цикл, храповий механізм і вимога до доказів поводяться однаково незалежно від розміру команди. Рівень якості лише підвищується, і механізм перевірки тримає його там, незалежно від того, хто виявився найдосвідченішим рецензентом у кімнаті цього тижня.

ШІ гачки

Конституція керує поведінкою агента через завантажений контекст. Хуки примушують його виконувати в момент дії, до того, як робота вже виконана і PR ще відкрито. Без хуків порушення виявляється на перевірці: агент уже написав код, PR є, і його виправлення означає повторну роботу. З хуками перехоплення відбувається до будь-якого натискання клавіші.

**І Claude Code, і GitHub Copilot запускають хук під час підказки про надсилання.** Коли надходить нове завдання, хук запускається до того, як агент щось зробить. Його завдання: перевірити, чи завдання є нетривіальним, а потім переключити список завдань у цикл `/wow` — 10-етапну послідовність EDD, яку агент повинен виконати, перш ніж щось відправляти.

Агент, який досяг кроку 5, не виконавши кроки 1-4, порушив цикл. Гачок встановлює послідовність на початку сеансу, а не після факту.

**Claude Code** додатково запускає хук перед викликом інструменту перед будь-яким записом файлу, командою терміналу або операцією git. Комміт не можна спробувати, якщо кроки циклу не виконано.

**GitHub Copilot** додатково запускає гачок для створення PR. Перш ніж завершити PR-опис, хук запускає `/audit` у режимі самоперевірки, виявляючи порушення параметрів, відсутні докази та порожні плани тестування, перш ніж рецензент побачить чернетку. Те, що потрапляє до рецензента, вже попередньо перевірено.

**Codex та інші агенти** не мають рідної поверхні гачка на момент написання цієї статті. Резервний варіант — це бот-спостерігач CI, який коментує PR одразу після створення та позначає порушення. Це блокатор зворотного ходу, а не ворота першої поверхні - робота вже виконана до того моменту, коли він спрацьовує, тому це не заважає переробці, яку усувають гаки.

У проекті з активними хуками порушення виправляються всередині під час сеансу. Агент виявляє прогалину, створює докази та включає їх із самого початку. Огляд крапель часу. Переробка зникає. Конституція переходить від документа, який читає агент, до обмеження, в якому агент працює в режимі реального часу.

Додаток - Повна Конституція

Нижче наведено фактичний `CONSTITUTION.md` із цього проекту — повністю автономний проект розробника, що працює на основі штучного інтелекту. Він керує кожною нетривіальною зміною, внесеною до цієї кодової бази. Це не шаблон чи ілюстрація. Це живий документ, який завантажує кожен агент під час кожного сеансу.