От правил прозы к механическим замкам: усиление защиты группы агентов Claude Code

Любой, кто использует агентов для программирования более нескольких недель, сталкивался с этим: в системном сообщении указано правило, агент его читает, и в тот самый момент, когда это правило должно сыграть роль, агент всё равно выполняет запрещённое действие и сообщает об успехе. Перефразирование правила, изменение регистра букв или добавление слова «ВАЖНО» редко помогает надолго. В этой статье приводится история обновлений open-source плагина Claude Code — blackgoat-agentskills — на протяжении пятнадцати версий, и показан подход, который выбрали его разработчики: когда действующее письменное указание нарушается, его заменяют на что-то, что необходимо выполнить или открыть. К концу вы сможете определить, какие из ваших собственных правил для агентов остаются лишь желаниями, и узнать несколько конкретных способов превратить их в реальные ограничения.

Начальная точка: команда специалистов

Плагин организует работу над программным обеспечением с использованием команды специализированных агентов. Список включает анализ требований, проектирование архитектуры и планирование; две роли разработчиков; тестирование, проверку кода и аудит безопасности; инженерию выпуска; а также мета-инженера, задачей которого является редактирование действий других агентов. Оркестратор, работающий в основной сессии Claude Code, распределяет задания между ними. Каждый специалист работает в своем изолированном контексте и возвращает структурированный документ с информацией о передаче задания, а не текст чата в свободной форме.

Версия 1.0.0 включала тринадцать персон и пять конвейеров обработки, охватывающих этапы открытия (/bgpdd-discovery), планирования (/bgpdd-plan), использования упрощенного пути (/bgpdd-lite), создания (/bgpdd-build) и доставки (/bgpdd-shipping). Помимо этого была предоставлена команда для исправления ошибок с использованием одного агента, набор методологических инструментов, которые агенты загружали только при необходимости, средства для оценки и одна ранняя детерминистическая проверка — барьер покрытия, подтверждающий, что каждое обязательное требование соответствует успешно пройденному тесту.

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

Разделение агента, который пытался выполнять три задачи

Первой проблемой была не непослушность, а перегрузка. Персонаж-тестер Куинн имел три режима: анализ поведения устаревших функций в процессе исследования, тестирование новых версий и проверка готовности к выпуску. Сведение всех трех функций в одну персону привело к появлению инструкций объемом около 5 000 слов, и в результате агент показывал посредственные результаты при выполнении каждой задачи.

В версии 1.1.0 роль была разделена на три части. Эхо занимается обратной инженерией существующего поведения в процессе исследования. Вера отвечает за список проверок перед выпуском. У Куинна осталась только одна обязанность — тестирование версии.

В этом же обновлении были внесены два важных исправления, которые стоит скопировать. Каждому агенту был установлен временной лимит в четыре минуты на выполнение команд в оболочке, поскольку процессы застревали из-за неработоспособных задач. Теперь этапы, отмеченные как связанные с безопасностью, проходят параллельную проверку со стороны Cipher — специалиста по аудиту безопасности — наряду с обычной проверкой кода.

Общий урок знаком с командами из числа людей: роль, включающая несколько нерелевантных обязанностей, сопровождается расплывчатым описанием задач. Для агента на основе ЯИИ это размытие является буквальным, поскольку каждая дополнительная инструкция конкурирует за внимание в одном и том же контексте.

Чистый отчет, который на самом деле не был чистым

Обновление 1.2.0 было запущено в результате сборки, включавшей пять этапов, которая сообщала о успехе, скрывая при этом длинный список проблем:

• четыре скрипта проверки, которые ни один скрипт пакета, ни ни одна задача CI так и не вызывали
• утверждения настолько формальные, что ни один из этапов проверки никогда не отклонял что-либо

отчет о тестировании, в котором позиции отмечены как «ПРОШЛИ», поскольку файл существовал, при этом добавлены выдуманные детали

три этапа были задокументированы, пока решение рецензента о «Требуется изменение» все еще действовало

Неприятно то, что правила уже охватывали каждый из этих случаев. Правило «Зеленый цвет — не доказательство» было активным. Журнал блокирующих факторов также был активен. Модель прочитала их и продолжила работу.

Ответом стал первый набор проверяемых предусловий проекта:

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

Для фиксации этапа необходимо прочитать два файла: вердикт последнего рассмотрения должен быть «Утверждено» и датироваться позже, чем изменения, а массив блокирующих факторов должен быть пустым.

Исправление критической проблемы проходит повторные тестирования и рассмотрение, вместо того чтобы просто добавляться в конец процесса.

Каждая строка с результатом «PASS» должна содержать точную команду, которая была выполнена, и её полный текст вывода.

Вместе с этим были внесены два изменения в процесс. Все деlegации начали выполняться в фоновом режиме, поскольку одна из блокирующих деlegаций делала Orchestrator недоступным на протяжении всего времени выполнения, из-за чего длительная фаза становилась неотличимой от застоя. Кроме того, теперь каждый агент создает свой файл вывода в начале и заполняет его по частям, так как прерванное выполнение уничтожало всё созданное ранее.

Первое предпосылочное условие заслуживает особого внимания. Проверка, которая никогда ранее не давала сбоев, — это проверка, которой нет причин доверять; это та же идея, что и наблюдение за тем, как новый тест становится красным прежде чем стать зеленым, но применённая к самому инструменту.

Выпуск 2.0.0: преобразование инструкций в программы

Предпосылочные условия версии 1.2 были улучшением, но они всё ещё представляли собой текст. «Выполнить два чтения файлов» — это инструкция, и в одном из последующих тестов Orchestrator выполнил три этапа подряд, несмотря на отрицательные результаты проверок запросов на изменения.

В то же время возникли ещё две проблемы. Один из этапов разработки интерфейса Vue оказался на уровне 51 000 символов в загрузочном контенте, поскольку один разработчик совмещал работу над схемами, API и интерфейсом, а созданный им интерфейс плохо справлялся с функциями пагинации, текстовыми полями ввода и автодополнением. В то же время параллельная работа разработчиков над одной веткой приводила к тому, что они постоянно меняли версию кода, поэтому при каждой проверке приходилось заново анализировать всю изменяющуюся разницу между версиями.

Порог коммита превращается в скрипт

check_commit_gate.py теперь выполняет ту же работу, что раньше делал текстовый запрос. Он считывает токен с решением, проверяет, что обзор новее предыдущей версии кода, сверяется с списком препятствий, а затем сам выполняет коммит. Именно этот последний момент имеет большое значение: поскольку коммиты совершает только скрипт, обойти проверку становится очевидно — коммит просто не происходит.

Разделение разработчиков по областям

Mason занимается задачами backend, а Nova — задачами UI. Каждая задача маркируется на этапе планирования, поэтому её направление к соответствующему разработчику происходит автоматически, без необходимости принятия решения со стороны Orchestrator позже.

Больше нет параллельных разработчиков

Механизм параллельной обработки полностью устранён. Один разработчик работает над одной задачей, что означает наличие только одного изменения для проверки.

Принцип, лежащий в основе всего последующего

Собственные инструкции репозитория получили дополнительное правило. Перефразируя: если существующее правило нарушается, его не следует переформулировать или выделить жирным шрифтом; его нужно преобразовать в автоматический контрольный механизм. Любое правило, требующее от агента воздержаться в момент, когда он больше всего хочет продолжить работу, должно подкрепляться объектом, который необходимо запустить или открыть.

Это основная идея всего проекта, которая применима гораздо шире, чем только к этому плагину. Если посмотреть на собственный файл CLAUDE.md или инструкции агента, правила, которые с наибольшей вероятностью приведут к ошибкам, — это именно те, что требуют сдержанности под давлением: не принимайте решения пока, не пропускайте тесты, не отмечайте задачу как выполненную. Чтобы узнать больше о том, что должно содержаться в этом файле, ознакомьтесь с нашим руководством по созданию эффективного файла CLAUDE.md.

Определение того, что считается доказательством

Во второй части версии 2.0.0 рассматривалась более тонкая проблема. Наборы тестов на передачу данных указывают лишь на то, какие функции проверялись, но ничего не говорят о том, что было проигнорировано. Например, хост тестов внутри процесса не может показать, что именно получает настоящий клиент через сеть: формат сериализованного ответа, порядок выполнения промежуточных компонентов, настройки среды. Агенты отмечали функции как «проверенные» на основе одного теста единицы и уверенного заявления.

Три уровня доказательств

В проекте были определены три уровня:

• Уровень 1 — это тест единицы.
• Уровень 2 передает запросы через реальную цепочку обработки приложения, но с использованием транспортного слоя, находящегося в памяти.
• Уровень 3 наблюдает за работающим приложением извне с помощью настоящего клиента.

Требование, для удовлетворения которого необходим уровень 3, никогда не может быть выполнено с помощью сертификата уровня 2. В описании навыка четко указана эта асимметрия: наблюдение в процессе выполнения разрешено для опровержения утверждений относительно работы приложения, но никогда не для их доказательства.

Поверхности верификации, выбираемые на этапе планирования

На каждом этапе проекта во время планирования присваивается тег поверхности верификации, и этот тег определяет, какие доказательства потребуются на последующих этапах. Для API-поверхности требуется ответ, полученный вне процесса выполнения, а также документ OpenAPI, к которому можно действительно получить доступ. Для UI-поверхности требуется отрендеренный результат. Назначение тестового клиента, работающего внутри процесса, такого как WebApplicationFactory или supertest, в качестве средства передачи данных считается сбоем на этапе проверки, а не умным ускорением процесса.

Запись данных с использованием устройств для обнаружения подделок

Доказательства собираются в виде записи захвата: команда выполняется через тихий оберточный процесс, который сохраняет результат вместе с автоматически создаваемым вспомогательным файлом. В этот вспомогательный файл записываются параметры команды, рабочая директория, идентификатор процесса, временные метки, реальный код выхода, а также хэши обоих файлов. Система Gates пересчитывает эти хэши, поэтому изменение записи захвата позже нарушает процедуру проверки.

Этот стандарт затем распространился на все ситуации, где утверждение ранее формулировалось в виде предложения. Запись о покрытии, содержащая лишь текст «PASS, done», отмечается как UNEVIDENCED и считается непокрытой. Агенты безопасности и запуска обязаны завершать каждую строку своих проверок, указывая на соответствующую запись захвата. Каждому элементу предоставляется честный способ выхода из ситуации: если проверка не может быть выполнена, результат отмечается как BLOCKED, никогда не как PASS, и должно указываться, чего не хватает. Как говорится в проекте, «проверено» — это описание, а не доказательство.

Заблокированный вариант выхода имеет такое же значение, как и строгие правила. Если у агента есть только варианты «Успех» или «Неудача», на него оказывается давление, побуждающее придумать результат «Успех». Наличие законного третьего состояния снимает значительную часть этого давления.

Проверка проверщиков: версия 2.1.0

Инструмент проверки метаданных, добавленный во время процедуры усиления безопасности, обнаружил две навыки, описания которых в формате YAML не парсились без ошибок. bgpdd-verify так и не был зарегистрирован с момента выпуска, а doubt-driven-development не регистрировался ни разу с момента первой коммит-записи. До появления этого инструмента полная проверка плагина показала его полную соответствие всем восемнадцати критериям.

Исправления в этой версии устраняют несоответствия между тем, что проверка, по-видимому, должна была проверить, и тем, что она на самом деле проверяла:

• Теперь проверка на наличие ошибок выполняется в первую очередь при каждой проверке: файлы анализируются до прочтения любого текста.
• Записи в журнале Gate теперь связаны между собой с помощью хэша, что позволяет обнаруживать внесение, изменение или удаление записей.
• Отметка о завершении этапа теперь осуществляется с помощью скрипта, а не путем ввода трех символов моделью.
• Клиент-зонд, записанный в результате захвата, должен находиться в списке разрешенных реальных клиентов.
• Доказательством отрендеренного интерфейса теперь является реальное изображение: оно не должно быть пустым, содержать правильные магические байты и быть свежее измененных файлов. Это было внесено после того, как выяснилось, что скриншот.png длиной ноль байт удовлетворял старым требованиям.
• Текст вердикта, отображаемый в примере внутри рамок или под заголовком добавления, игнорируется при определении результата проверки. Ранее иллюстративный блок незаметно заменял настоящий запрос на изменения.

Пример скриншота служит хорошим напоминанием о том, что агенты оптимизируют свои действия с учётом того, что именно проверяется. Если проверка заключается в наличии «файла с таким именем», рано или поздно появится файл размером нуль байт.

Путь устранения ошибок, основанный на записанных доказательствах

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

В версии 2.2.1 этот процесс был перестроен в шесть этапов с проверкой между каждым из них:

• Отчёт об ошибке, который должен пройти проверку на соответствие стандартам.
• Запись ситуации с кодом ошибки, сделанная тестировщиком до любых изменений в коде, чтобы фиксировать сбой.
• Шаг маршрутизации, определяемый скриптом, а не моделью, который выбирает между быстрым путём решения, полным путём или передачей проблемы на более высокий уровень.

Само исправление.

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

Новый рецензент, после чего происходит проверка перед коммитом.

Для нестабильных багов может потребоваться N зеленых запусков от N разных процессов, поскольку четыре успешных запуска из пяти не означают, что баг устранен. Кроме того, инструмент сборки вообще не может выполнять коммиты.

Маршруты для небольших изменений

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

Дополнения:

• /bg — входная точка, которая классифицирует каждый запрос и направляет его именно в один канал обработки.
• /bgpdd-quick — для изменений, затрагивающих менее трех файлов. Он не создает агентов; он запрашивает краткую запись из трех строк, фиксирует одну проверку и завершает работу через шлюз, осуществляющий коммит.
• Постоянно активный хук сессии, позволяющий обычной чат-сессии знать о существовании каналов обработки.
• Пакет для ревью: рецензенту передаётся сам разничный файл в отформатированном и хешированном виде, а не пути к файлам в рабочей деревне, где уже внесённые исправления выглядят как текущее состояние, а удалённые строки остаются невидимыми.

Последний момент ценен даже без использования агентов. Ревью файлов в их окончательном виде скрывает изменения, тогда как ревью разничного файла показывает их.

Использование аудитов для поиска следующего шлюза

Версия 2.4.0 была выпущена после аудита версии 2.3, в ходе которого было выявлено шесть проблем с метриками Blocker. Примеры: агенты безопасности и запуска по-прежнему могли отмечать результат проверки как «ПРОХОДИТ» без каких-либо подтверждающих доказательств, к тому же ничто не сравнивало код выхода из записи данных с кодом в её sidecar. В фикстчере для интеграции плагина даже была запись, у которой sidecar отличался по дате на 223 дня.

Эти исправления связывают утверждения с файлами. Каждая выполненная проверка в этих отчетах теперь указывает название зафиксированного результата; его сопроводительный файл должен присутствовать, иметь совпадающий хэш и соответствовать коду завершения, указанному в строке. Любой механизм обработки результата также сравнивает его содержимое со своим сопроводительным файлом. Журнал блокировок получил структурированную схему с указанием уровня серьезности и объема задачи. Команда также измерила стоимость обработки триггера — примерно 1,77 доллара и 250 секунд на одну операцию в то время — и использовала этот показатель для определения частоты их выполнения.

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

The fixes split evidence directories by producer, made UI milestones stop and ask the user when no browser is available instead of looping, and insisted, without exceptions, that a capture match the command its note says was executed. Wake-up payloads were slimmed by moving rationale out of the core persona text into references, without losing any rules. The changelog also gained a "Known, not fixed" section, because a commit gate that would accept an entirely forged evidence base is a limit that should be documented rather than hidden.

From checking afterwards to refusing beforehand

Up to release 2.5.0 every gate ran after the fact, and the model still decided whether to run it. A rule like "do not commit by hand while a lane is active" can still be read and ignored.

Ответом стал хук PreToolUse, который блокирует вызовы инструментов до их выполнения. Он запрещает:

• ручное выполнение команды git commit при активном режиме работы
• изменение уже существующего файла тестов в процессе устранения ошибки
• запуск подагента до того, как входные данные будут обработаны
• ручные изменения в любом файле, созданном системой

Чтобы определить, активен ли режим работы, хук проверяет файлы состояния на диске и считает их актуальными в течение 12 часов; он никогда не доверяет информации, предоставляемой моделью о собственном состоянии. Кроме того, он прерывает работу при любой внутренней ошибке. Это осознанный компромисс: защитный механизм, прерывающий сессии, будет деинсталирован, а деинсталированный механизм ничего не будет контролировать.

В этой версии также был добавлен драйвер, который выполняет следующий обязательный шаг вместо того, чтобы полагаться на Orchestrator для его запоминания, а также валидатор для передачи заданий агентам. Валидатор проверяет наличие указанных путей, подтверждает, что файлы, отмеченные как изменённые, действительно присутствуют в отчёте о различиях, и выявляет противоречия, такие как статус BLOCKED рядом с строкой blockers, где указано «None».

Обработка работы между функциями

До версии 2.6.0 у нескольких типов рутинных инженерных задач вообще не было методологии: речь идёт о обновлении зависимостей, внедрении фич-флагов, написании задач в фоновом режиме, добавлении возможностей для мониторинга и изменении спецификаций API. Агенты решали эти задачи импровизированно. Команда, отвечающая за быструю разработку, также предполагала команды тестирования для проекта.

В этой версии было добавлено пять навыков для этих областей, каждый из которых сопровождается контрактом выполнения и проверкой, анализирующей этот контракт. Теперь детектор стека предлагает команду проверки и замороженные тестовые элементы из репозитория, после чего человек их подтверждает вместо того, чтобы процесс выбирал их автоматически. Для этапов API билд-гейт также выполняет сравнение по формату OpenAPI, что означает, что изменения, нарушающие существующую структуру, не могут быть внесены без письменного обоснования. Каждый раз, когда при выборе дизайна существовало по меньшей мере два варианта, требуется создание ADR, а инструмент lint проверяет, что дизайн-реестр на него ссылается. Наконец, каждая методология получила «Карточку быстрого просмотра»: пять правил, важных при изменениях в трех или меньше файлах, причем каждое правило содержит ссылку на соответствующий раздел, что позволяет использовать краткую карточку вместо полного контракта.

Преобразование уроков до того, как они станут привычками

Выпуск 2.6.2 стал результатом настоящей битвы. Куинн четыре раза передавала задачи на решение той же проблемы среды, что привело к расходу около 1,2 миллиона токенов. Статус «Завершено» указывал на объект, все еще содержащий маркеры задач. А возобновление работы существующего агента фиксировалось как совершенно новая задача, что увеличивало объем логов.

Механизм обучения выделил три урока и преобразовал каждый из них в контрольный пункт перед их сохранением. Задачи, объекты которых все еще содержат временные структуры, теперь не проходят проверку. Возобновление работы агента записывается как отдельная операция. А когда препятствие может быть устранено только человеком — например, из-за отсутствующих учетных данных или сервиса, который отказывается запускаться — процесс останавливается, и его можно возобновить только при явном указании команды человеком. Именно это остановление могло бы сэкономить большую часть этих 1,2 миллиона токенов.

Обнаружение тестов, которые тестируют самих себя

Версия 2.7.0 устранила одно из наиболее тревожных обнаружений. В реальном проекте из двадцати спецификаций Playwright, сгенерированных различными каналами тестирования, тринадцать оказались фальшивыми. В таких спецификациях функция, находящаяся на тестировании, переимплементировалась либо напрямую, либо внутри вызова page.evaluate, после чего проверялась против собственной копии. Подобный тест каждый раз без проблем показывает результат «КРАСНЫЙ», а затем «ЗЕЛЕНЫЙ», и механизм контроля цветов не может его обнаружить, поскольку тавтология проходит оба этапа.

check_test_authenticity.py теперь запускается при каждом фиксировании результата «КРАСНЫЙ» в любом канале, где создаются тесты. Он ищет четыре типа фальшивых спецификаций:

• спецификация, которая не импортирует ничего из кода продакшена
• встроенная переимплементация кода, находящегося на тестировании
• оценка исходного текста
• синтетический DOM вместо реального приложения

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

Уроки из другого инструмента для ревью кода

Для версии 2.7.1 разработчики изучили систему открытого анализа кода Alibaba, точность которой, согласно отчетам, составляет примерно 34% при использовании публичных тестовых данных по сравнению с 7–16% при анализе кода с помощью Claude Code без дополнительных инструментов при использовании идентичных моделей. Эти показатели следует рассматривать как оценку проектом результатов этих тестов в определенный момент времени, а не как независимые данные. Интересным было то, что критерии оценки обеих систем были практически идентичны. Различия заключались в структуре: фиксированный список файлов, которые обязательно должны учитываться, файлы, сгенерированные в процессе работы, удалялись до того, как ревизор увидит изменения, существовал лимит по размеру, а также этап проверки фактов, при котором нарушение могло быть отклонено только по одной из двух указанных причин.

Два инцидента тестирования попали в одну версию продукта. Безголовое тестирование без репозитория Git в своих настройках начало поиск такого репозитория по всей машине и обратилось к настоящему инструменту отслеживания проблем. Ещё одна операция по исправлению ошибок с использованием плагинов обошлась в 11,06 долларов, но не привела к созданию тестов, способных выявить ошибки в баговой версии, что означает, что никто не заметит отката исправления.

Результаты внесённых изменений:

• Система проверки коммитов отклоняет запросы на утверждение, если в разделе обзора присутствуют нерешённые критические или важные находки. Фактически вердикт формируется на основе этих находок, а регулярное выражение подтверждает его корректность.
• Если для каждого файла в diff нет отдельной строки обзора, коммит отклоняется.
• Пакет обзора удаляет файлы-замки, минифицированные файлы и все генерированные файлы на любой глубине, указывает, что было удалено, и отклоняет diff’ы длиной более 1500 строк, если только человек не напишет соответствующее разрешение.

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

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

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

Сравнение не было односторонним. В документах с 51 правилом для разных языков другого инструмента не было ничего, касающегося C#, Vue, PowerShell или SQL; для этих языков используется универсальный чек-лист, и именно эти технологии покрываются функциями этого плагина.

При втором прочтении было сформулировано три правила точности в разделе 2.7.2, добавленных до того, как возникла необходимость в них из-за ошибок. Рецензент может прочитать любой файл для понимания контекста, но выводы ограничиваются файлами, входящими в состав пакетного diff; замечания по другим файлам становятся примечанием вне рамок задачи для Orchestrator. Методология работы с базами данных получила правило против внедрения кода с явным списком элементов, о которых никогда не следует сообщать, таких как параметризованные связи и статические операторы, поскольку ложные результаты для корректного кода заставляют рецензентов пропускать настоящие проблемы. Кроме того, методология безопасности теперь требует структуры из пяти разделов для документов по безопасности, причем каждая категория OWASP в них должна иметь либо ссылку, либо обоснованный ответ «Не применимо», поскольку оставление строки пустой не является вердиктом.

Текущее состояние проекта

На момент написания этого текста плагин содержит 16 персон агентов, 45 навыков и 32 скрипта контроля, включая 1 656 самопроверок. Все эти скрипты являются детерминистскими и не включают вызовы больших языковых моделей; они выполняются перед каждой версией плагина. Набор тестов включает 69 случаев, разделенных на четыре уровня; при оценке сравниваются результаты работы плагина с включенным и отключенным функционалом на основе скрытых тестов, а не проверяется, активирована ли конкретная опция. С момента первой версии было сделано 119 коммитов, добавивших примерно 67 000 строк кода.

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

Основные выводы

• Рассматривайте нарушение правила во время его действия как отчет об ошибках, связанных с этим правилом, и исправляйте его с помощью контрольного пункта, а не более строгих формулировок.
• Позвольте скриптам выполнять необратимые действия, такие как сохранение изменений, чтобы пропущенная проверка оставляла видимый признак отсутствия действий вместо беззвучного их прохождения.
• Определите уровни доказательств и требуйте сохранения хешированного вывода команды вместо простой фразы «проверено».
• Обеспечьте агентам законный результат BLOCKED, чтобы придумать результат PASS никогда не было самым простым решением.
• Докажите работоспособность каждого контрольного пункта, наблюдая за его сбоем при умышленном нарушении, а также проведите аудит самих контрольных пунктов, поскольку проверки часто сводятся к проверке названий и наличия файлов.
• Блокируйте опасные вызовы инструментов до их выполнения, но настройте защиту так, чтобы она редко срабатывала, чтобы никто не был склонен её удалять.

Примените тест на удаление к сгенерированным тестам: если удаление кода из продакшена не нарушит работу теста, этот тест бесполезен.

Метод заключается в цикле: наблюдайте за запуском, находите инструкцию, которая была проигнорирована, заменяйте её на что-то, что обязательно должно быть выполнено или открыто, и снова наблюдайте за следующим запуском.

Связанные материалы

• Где должны находиться инструкции Claude Code: CLAUDE.md, правила путей или хуки — Узнайте, почему Claude Code рассматривает CLAUDE.md как контекст, как его сокращать, как ограничивать правила по пути, как перемещать шаги, обязательные к выполнению, в хуки, и как проверять, что на самом деле загружается.
• Практический пособие по созданию эффективного файла CLAUDE.md — Узнайте 21 конкретное, проверяемое правило для сокращения объема файла CLAUDE.md, чтобы Claude Code оставался надежным, предсказуемым и заслуживающим доверия во время длительных сессий.
• Обучение Claude Code работе с вашим NestJS Monorepo: маршрутизация, правила и навыки — Как настроить CLAUDE.md, правила, навыки и разрешения так, чтобы Claude Code помещал код в соответствующий сервис NestJS и соблюдал стандарты вашей команды.
• Применение правил агентов в коде: PreToolUse, PostToolUse и функции Stop Hooks — Узнайте, почему авторизация агентов LLM должна находиться в функциях вызова инструментов с детерминированным поведением, как безопасно отклонять вызовы и как обернуть диспетчер без рекурсии.