В 2026 году корпоративная команда создала агента, который считывает заявки на управление инцидентами, генерирует на их основе заключения и автоматически создает элементы ремонта. Второй агент в той же команде следил за новыми рабочими задачами и открывал черновые PR для каждого из них, чтобы помочь разработчикам начать работу. Разработчик рассмотрел один из этих 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 шагов. Каждый шаг существует, потому что его удаление создает дыру, через которую могут пройти недоказанные работы. Цикл — это не контрольный список. Это причинно-следственная цепочка.

Отсюда возник вопрос: какие категории сбоев может генерировать агент, которые цикл не отлавливает по умолчанию? Это привело к жестким ограничениям. Security lint молчал, пока правила были понижены, и выдал `[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, а не к шаблонам инфраструктуры. Эти правила хранятся в файлах инструкций с глобусом:

Агент загружает эти файлы только тогда, когда он касается соответствующего пути. Это позволяет ограничить бюджет контекста активной загрузки (основные правила всегда присутствуют, специализированные правила загружаются по требованию) и предотвращает появление рекомендаций по доступности при редактировании шаблона 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. Поправка является атомарной. Частичные поправки, обещающие добавить проверку позже, отвергаются - позже не приходит, а непроверяемое правило - украшение.

**Пишите оценки и критерии до того, как почувствуете, что они вам нужны.** Оценка — это храповик. Без этого поправки принимаются добросовестно, и конституция дрейфует. Рубрика оценивает поведение агентов в реалистичных сценариях. Каждое новое правило порождает как минимум один сценарий. Рубрика дает числовой балл. Поправка принимается только в том случае, если оценка рабочего дерева соответствует базовому уровню или превышает его.

**Задокументируйте, что вы можете и не можете охватить. Не лгите себе о страховом покрытии.**

Вначале жесткое ограничение доступности гласило, что новые интерактивные поверхности пользовательского интерфейса требуют покрытия e2e a11y с использованием axe-core. Это казалось всеобъемлющим. На практике это было наивно. axe-core обрабатывает значимое подмножество WCAG — он улавливает недостающие метки, структуру ориентиров, порядок фокуса и контрастность в тех случаях, когда DOM полностью визуализируется и цвета разрешаются. Он не улавливает логику объявлений программы чтения с экрана, шаблоны когнитивной нагрузки, сложные контракты клавиатуры виджетов или проблемы контрастности, связанные с градиентами и узлами изображений SVG, где вычисленный цвет не может быть решен.

Наличие `[HC-A11Y-GATE]` с axe-core при проверке не означает, что ошибок a11y нет. Это означает, что конкретный набор правил Axe-Core работает с визуализированным DOM. Эта разница имеет огромное значение в заявлениях о PR-открытии.

Исправлением стало разложение. Вместо «чистки ядра топора» проверка была переписана, чтобы перечислять, какие критерии успеха WCAG детерминированно охватывает набор правил axe-core (1.1.1 для нетекстового контента, 1.3.1 для информации и связей, 1.4.3 для контраста, где это можно разрешить, 4.1.2 для имени/роли/значения) и которые не имеют автоматического покрытия (1.3.3 сенсорные характеристики, 2.4.6 заголовки и метки). семантика, все из 3.х, понятные критерии). В разделе «Известные пробелы» измерения аудита теперь прямо указано: axe-core обрабатывает эти критерии; Для них требуется ручное сканирование. Рецензенты по связям с общественностью видят фактическое освещение событий, а не фальшивое резюме.

Более широкий принцип: для каждой проверки документируйте, что она обнаруживает, а что нет. «Пропуск проверки безопасности» не означает, что база кода безопасна. «Очистка ядра топора» не означает соответствие WCAG 2.2 AA. Назовите пробел. Зарегистрируйте это в измерении аудита. Требуется ручное сканирование поверхности зазора. Не позволяйте автоматической проверке заменить человеческое суждение, которое она не может заменить.

Шаг 5 – Как мы пишем поправки

Поправки почти никогда не начинаются с предложений по поправкам. Они начинаются как ошибки.

Всплывает ошибка. Исправление применяется. Перед отправкой `/reflect` задает один вопрос: это единичный случай или в конституции отсутствует что-то, что могло бы выявить этот класс ошибок? Если ответ одноразовый, исправление будет отправлено, и на этом все. Если ответ таков: чего-то не хватает, тогда вызывается `/constitute`.

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

**Три требуемых артефакта.** `/constitute` отказывается работать без всех трёх в одном PR:

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

**Храповик.** После того как все три артефакта одобрены, поправка применяется к ветке. Оценка выполняется в соответствии с правилами основной ветки и правилами рабочего дерева. Рубрика оценивается по обоим критериям. Для прохождения требуется рабочее дерево >= main в каждом сценарии. Регрессия блокирует поправку до тех пор, пока формулировка не будет зафиксирована. Храповик не является обязательным для очевидных поправок: они все равно могут вызывать тонкие регрессии, и оценка — единственный механизм, который улавливает их до того, как они приземлятся.

**Ретроактивная развертка.** Поправка немедленно фиксирует правило для нового кода: область различий `/audit` означает, что новая работа соответствует новой планке с момента вступления поправки в силу. Существующий ранее код, нарушающий новое правило, обрабатывается отдельным PR очистки, поставленным в очередь через `/rollout`. Сайту исправлений не обязательно исправлять каждый уже существующий экземпляр в режиме реального времени. Это сделало бы поправки непомерно дорогими. Вместо этого: новый код сразу же соответствует новой планке, старый код находится в очереди на развертывание, а PR очистки содержит собственные доказательства того, что ранее существовавшие экземпляры решены.

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

Шаг 6 – Как мы его разворачиваем

Portable Methodology Kit (EDD — Portable Methodology Kit.md) — это автономный документ, который вы передаете любому агенту ИИ с инструкцией по запуску «/begin». Агент проверяет репозиторий, запускает этап обнаружения, подтверждает обнаруженные значения с вами в одной таблице, запрашивает только то, на что обнаружение не может ответить, и выдает минимальную жизнеспособную структуру для вашего проекта. Один сеанс для поддержки всей инфраструктуры EDD.

То, как вы его развернете, полностью зависит от того, начинаете ли вы с нуля или вносите его в существующую кодовую базу. Эти два пути настолько различны, что их можно рассматривать отдельно.

**Greenfield.** В новом проекте в первый же день включите в конституцию все правила, которые только придет вам в голову. У вас нет уже существующего кода для аудита, нет командных практик, которые нужно защищать, нет существующих PR для дедушки. Цена строгости в первый день практически равна нулю. Добавьте все жесткие ограничения, все измерения аудита, все правила на уровне пути. Затем запустите цикл. Вы быстро обнаружите, где конституция создает трения: время сборки резко увеличивается, потому что каждое изменение вызывает полный аудит, наборы тестов работают медленно, потому что планка покрытия установлена ​​​​слишком высоко для текущей сложности, бюджеты токенов ограничены, потому что каноническое тело слишком многословно. Строгость первого дня выявляет эти проблемы в разработке, а не в производстве. Затем вы оптимизируете: ужесточаете параметры сборки, корректируете правила покрытия, сводите конституционное тело к минимуму. Вы стабилизируете все сразу, не затрагивая клиентов и не расстраивая команду. Краткосрочные издержки — немного более медленный первый спринт. Долгосрочная выгода — это конституция, прошедшая стресс-тестирование с самого первого коммита.

**Браунфилд.** Существующая кодовая база имеет существующую команду, существующие практики и существующие PR, которые не соответствуют EDD. Развертывание здесь является постепенным и должно быть дополнительным, а не разрушительным. Цель первого месяца не в том, чтобы модифицировать все прошлые решения, а в том, чтобы начать генерировать обеспечение, которое делает EDD заслуживающим доверия: одно измерение аудита, которое фиксирует что-то реальное, одно жесткое ограничение, которое автоматизирует проверку, которую команда уже выполняла вручную, один цикл поправок от начала до конца. Используйте существующие сигналы качества команды в качестве исходного материала. Если у команды уже есть правило lint для безопасности, добавьте «[HC-SECURITY-LINT]» и укажите его на существующий шлюз — для разработчиков ничего не изменится, но теперь конституционная запись отражает то, что на самом деле обеспечивает шлюз.

Основное правило в браунфилде гласит: прежде чем выигрывать споры, завоевывайте союзников. Не продвигайте полную конституцию, которая затрагивает все области кодовой базы, в первую неделю. Начните с измерения, которое уже больше всего волнует команду — обычно это безопасность или надежность. Покажите, что процесс внесения поправок закрывает реальный пробел, который они видели раньше. Пусть соединение храповика оттуда. Команда, которая увидела, как EDD обнаружила одну реальную ошибку, которая проскользнула через существующий процесс, освободит место для следующего правила. Команда, которая воспринимает EDD как документ, в котором говорится, что они все делают неправильно, обойдет его стороной.

**Что он открывает.** Причина, по которой необходимо пройти этап развертывания, будь то новый или уже существующий проект, не является конституционным документом. Это то, что позволяет конституция, как только заработает механизм проверки.

Качество производственного кода и скорость доставки сочетаются друг с другом таким образом, что это действительно противоречит здравому смыслу, если вы этого не видели. Инженеры прекращают переключение контекста, чтобы отладить регрессии, которые мог бы обнаружить цикл. Циклы проверок сокращаются, поскольку ОР содержат доказательства, а не объяснения. Аудит выполняется автоматически и выявляет проблемы, которые мог бы обнаружить самый опытный проверяющий, что позволяет этому проверяющему сосредоточиться на архитектурных решениях, которые на самом деле требуют его суждения.

Ярчайшее доказательство этого: новый инженер, присоединяющийся к команде, с полным доступом к конституции, спецификации функций и циклу, может внести вклад в качественную функцию, проверенную в основной версии, в течение 48 часов с первого дня работы. Не игрушечная смена. Не обновление документации. Реальная особенность, с доказательствами, проходящая полную проверку. Это не случайность и не какой-то особенно необычный инженер. Ограждения позволяют любому квалифицированному разработчику с первого дня работать в соответствии со стандартами качества команды, поскольку стандарт качества записан, проверяем и применяется автоматически, а не хранится в виде институциональных знаний в головах тех, кто работает там дольше всех.

Это та форма, которую он достигает: команда, в которой ИИ занимается проверкой, ограждения ловят классы ошибок, которые в противном случае ускользнули бы от проверки кода, а инженеры тратят время на размышления над проблемами, которые на самом деле требуют инженерного решения.

Это было проверено в разных масштабах: сначала индивидуальные проекты, затем средние команды, а затем и организации масштаба предприятия. Механика держится на всех трех. Стоимость развертывания различна (одиночный разработчик может пропустить реестры требований и состязательную проверку между поставщиками; они нужны корпоративной команде). Периодичность внесения изменений различна (в индивидуальном проекте между вызовами `/constitute` могут пройти недели; корпоративная команда с несколькими участвующими агентами запускает их еженедельно). Но основной цикл, храповик и требования к доказательствам ведут себя одинаково независимо от размера команды. Минимальный уровень качества только повышается, и механизм проверки удерживает его на этом уровне вне зависимости от того, кто окажется самым опытным рецензентом в комнате на этой неделе.

AI-хуки

Конституция управляет поведением агента через загруженный контекст. Хуки обеспечивают его выполнение в момент действия, до того, как работа уже завершена и PR уже открыт. Без хуков на ревью ловится нарушение: агент уже написал код, PR есть, и исправить его — значит переделать работу. При использовании хуков перехват происходит до нажатия клавиши.

**И Claude Code, и GitHub Copilot используют перехват при отправке запроса.** При поступлении новой задачи перехват срабатывает до того, как агент что-либо сделает. Его задача: проверить, является ли задача нетривиальной, а затем пересоединить список задач в цикл `/wow` — 10-шаговую последовательность EDD, которой агент должен следовать перед отправкой чего-либо.

Агент, достигший шага 5, не выполнив шаги 1–4, нарушил цикл. Перехватчик устанавливает последовательность в начале сеанса, а не постфактум.

**Claude Code** дополнительно запускает перехватчик перед вызовом инструмента перед любой записью файла, командой терминала или операцией git. Невозможно выполнить фиксацию, если шаги цикла не были выполнены.

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

**Кодекс и другие агенты** на момент написания этой статьи не имеют встроенной поверхности крючка. Резервным вариантом является бот-наблюдатель CI, который комментирует запросы на запросы сразу после их создания и отмечает нарушения. Это ограничитель обратного хода, а не ворота первой поверхности — к моменту срабатывания работа уже завершена, поэтому он не предотвращает доработку, которую устраняют крючки.

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

Приложение – Полная Конституция

Далее следует фактический `CONSTITUTION.md` из этого проекта - полностью автономный проект с поддержкой искусственного интеллекта, созданный одним разработчиком. Он управляет всеми нетривиальными изменениями, вносимыми в эту кодовую базу. Это не шаблон и не иллюстрация. Это действующий документ, загружаемый каждым агентом в каждом сеансе.