Проверки на предотвращение ошибок

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

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

На что она обращает внимание#

Правила сгруппированы по категориям. Каждое правило либо блокирует, даёт рекомендации или фиксирует информацию.

• Тесты — целевые или пропущенные тесты, удалённые тесты, убранные или ослабленные утверждения, тесты, которые не могут завершиться ошибкой.
• Отключения — новые запреты на линтеры, игнорирования типов и any приведения типов.
• Сборка и CI — удалённые или нейтрализованные шаги тестов, пониженные пороги, режим «прохождение без тестов».
• Доказательства выполнения тестов — кэшированные результаты, выдаваемые за фактический запуск, нулевое количество выполненных тестов, частичный запуск, указанный как завершённый.
• Продуктивный код — остатки режима отладки, заглушки, моковые данные, примечания для людей, тестовый код, попавший в релиз.
• Обработка ошибок — скрытые ошибки, альтернативные варианты, маскирующие сбои, разрешения с открытым доступом без проверки.
• Комментарии, Архитектура, Зависимости, Область изменений, Безопасность, Кэширование и журнал действий агента — запись того, что сделал агент, например редактирование теста сразу после его сбоя.

Страница каждого правила в Качество → Проверки → Anti-slop показывает, что он проверяет и почему это важно.

Блокирует только те элементы, которые были добавлены в ходе изменения.#

В большинстве репозиториев уже присутствуют некоторые из этих шаблонов. Проверка Anti-slop классифицирует каждый результат в одну из трёх групп:

• Добавленные — новые в рамках данного изменения.
• Изменённые — уже существующие, находящиеся в строке или функции, которые затронуло изменение.
• Существующие — находящиеся в других частях репозитория.

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

Добавление в политику#

Откройте политику в Качество → Политики и выберите Добавить пресет Anti-slop. Он добавляет пять требований:

1. Тесты по-прежнему подтверждают корректность изменения.
2. Ничего незавершённого или предназначенного только для тестов не попадает в релиз.
3. Нет нового структурного технического долга.
4. Изменение остаётся в рамках области и соответствует стилю кодовой базы.
5. Новые зависимости являются реальными и надёжными.

Опубликуйте политику, и следующий запуск каждого привязанного проекта включит эту проверку.

Выбор стиля обработки изменений#

Этот стиль определяет, насколько далеко может зайти агент-разработчик при обработке изменения:

• Хирургический — только то, что требуется по спецификации; другие проблемы лишь отмечаются, но не исправляются.
• Сбалансированный (по умолчанию) — также исправляет небольшие ошибки в строках, которые затронуло изменение.
• Восстановительный — также устраняет найденные проблемы в функциях, которые затронуло изменение.

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

Адаптация под вашу кодовую базу#

• Переопределения правил — отключите правило или заставьте его давать рекомендации вместо блокировки в настройках проверки.
• Наборы правил — ваши собственные шаблоны, запрещённые импорты и зависимости, ограничения по размеру файлов или результаты уже используемых инструментов (SARIF). Наборы версионируются; политика привязывается к конкретной версии.
• Карантин — шаблоны, которые больше не должны копироваться, каждый со своей заменой. Агентам запрещается их распространять, а новые копии помечаются как таковые.
• Файл репозитория — .coroid/anti-slop.yml в репозитории позволяет добавлять правила и исключать сгенерированные или сторонние пути. Он читается исходя из базы изменения, поэтому изменение не может ослабить собственные правила, а его редактирование требует одобрения.

Результаты и исключения#

Результаты отображаются в Качество → Результаты, причем они фильтруются по типу проверки. Чтобы принять конкретный результат, укажите причину его игнорирования — такое решение будет зафиксировано именно для этого результата. Агенты не могут игнорировать собственные результаты. Если агент заявляет, что тест дал ошибочный результат и вносит соответствующие изменения, рецензент должен одобрить эти правки перед тем, как проверка будет считаться пройденной.

Правила-судьи#

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

Ваши собственные агенты#

Те же правила могут направлять агентов, которых вы запускаете самостоятельно:

• Скачать фрагмент кода AGENTS.md, на вкладке Технический долг вкладке Качество → Проверки → Anti-slop, предоставляет информацию о дисциплине изменений в проекте, списке временно заблокированных элементов и основных правилах в виде раздела, который можно вставить в инструкции для ваших агентов.
• Через Coroid MCP сервер anti_slop_rules описывает вашу опубликованную политику и anti_slop_scan сканирует ветку синхронизированного проекта в режиме только для чтения.