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

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

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

Что именно ищется#

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

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

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

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

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

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

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

Еженедельная очистка технического долга#

Существующий технический долг не блокирует процесс разработки, но и не должен оставаться навсегда. Откройте проект в Quality Control, раскройте Anti-slop и включите Еженедельная очистка технического долга. Раз в неделю Coroid сканирует основную ветку проекта и создаёт небольшие задачи по очистке для найденного технического долга, по несколько файлов за раз. Количество открытых задач по очистке не превышает значения, указанного в параметре Открытые задачи одновременно (по умолчанию два), чтобы очистка не мешала основной работе. Для каждого изменения предусмотрена функция отмены.

Настройки очистки задаются для каждого проекта. Расписание указано в Factory, там же сказано, что управление осуществляется через Quality Control; изменяйте его здесь, а не там.

Ранее в Новая работа была доступна шаблонная задача «Еженедельная очистка технического долга». Созданное на её основе расписание продолжает работать и отображается под соответствующим переключателем; приостановите его в Factory, если очистка технического долга заменяет эту задачу.

Включение функции#

В Quality Control, выберите настройки организации или проекта и включите Anti-slop. Это добавляет пять обязательных требований:

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

Изменение вступает в силу немедленно: следующий запуск проекта или всех проектов, следующих общим настройкам, включает эту проверку. Настройки строки определяют дисциплину изменений, которая объединяет правила блокировки и оценки; отключение функции сохраняет эти настройки для следующего включения.

Выбор дисциплины изменений#

Дисциплина указывает агенту-разработчику, насколько далеко может простираться изменение:

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

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

Подстройка под вашу кодовую базу#

• Переопределения правил — откройте правило в разделе Anti-slop, чтобы задать ему режим блокировки, предупреждения, только отчета или остановки для настроек организации или конкретного проекта.
• Наборы правил — ваши собственные шаблоны, запрещенные импорты и зависимости, ограничения по размеру файлов или результаты уже используемых инструментов (SARIF). Каждая сохраненная версия становится новой версией набора правил, а проверка использует выбранную версию.
• Карантин — шаблоны, которые больше не должны копироваться; для каждого указывается замена. Агентам запрещено распространять такие шаблоны, а новые копии помечаются как ошибочные.
• Исключенные пути — в разделе Quality Control → Anti-slop указываются сгенерированные или сторонние файлы, которые не проверяются на наличие ошибок anti-slop; по одному шаблону на строку (dist/**, vendor/**). Используйте их для результатов сборки: если размер измененного файла превышает лимит сканера в 512 КиБ, проверка невозможна.
• Файл репозитория — .coroid/anti-slop.yml в репозитории может содержать правила и исключения generated/, vendor/, node_modules/ и __generated__/ директорий. Файл считывается с базового уровня изменения, поэтому изменение не может ослабить собственные правила, а его редактирование требует утверждения.
• Файлы блокировок и каталоги переводов — anti-slop учитывает изменения в них, но не читает их содержимое. Каталоги — это файлы .coroid/i18n.json указывает в начале изменения; проверка Глобализация считывает именно их. Собственное правило, называющее эти файлы, также будет их учитывать.

Новые зависимости#

Иногда модели предлагают пакет, которого на самом деле не существует — часто это комбинация двух реальных названий. Злоумышленники регистрируют такие названия на npm и PyPI, чтобы при следующей установке запускался их код; такая атака называется slopsquatting. Cloud Security Alliance описывает её: почти каждый пятый из 2,23 миллиона образцов кода, упомянутых в исследовании, содержал хотя бы один несуществующий пакет.

Anti-slop проверяет каждую новую зависимость, добавляемую в изменение, в package.json, файле требований или pyproject.toml:

• Блокирующие — пакет, которого нет в публичном реестре, или такой, который OSV помечает как вредоносный. Изменение возвращается агенту-разработчику до того, как вы его увидите.
• Рекомендательные — пакет, опубликованный менее 30 дней назад, имеющий очень мало загрузок, название которого отличается на одну-две буквы от популярного пакета, или npm-пакет, запускающий код при установке. PyPI-пакет с помеченной как вредоносная версией также относится к этой категории, так как Coroid не знает, какую версию устанавливает требование.

Если реестр недоступен, в результатах проверки будет указано об этом, и система определит, какие пакеты можно проверить. Изменение при этом не блокируется.

Какие названия проверяет Coroid#

Запрос названия отправляется в публичный реестр, поэтому владелец или администратор решает, какие названия могут покидать Coroid, в разделе Quality Control → Anti-slop → Проверка новых зависимостей. Это правило применяется ко всем проектам в организации.

• Публичные npm и PyPI, если репозиторий не указывает другой реестр — все новые зависимости проверяются, за исключением случаев, когда .npmrc, файл требований, pip.conf, uv.toml, Pipfile или настройки Python-инструментов, размещенные рядом с манифестом или в родительской папке, указывают другой реестр или индекс. При выборе этого варианта вам нужно подтвердить, что частный реестр не настроен вне репозиториев — например, в настройках пользователя или CI, — и система зафиксирует время и автора подтверждения. Scoped npm-пакеты (@scope/name) проверяются только там, где .npmrc указывает публичный реестр для своего диапазона.
• Только если репозиторий указывает публичный реестр — значение по умолчанию. Пакет проверяется только тогда, когда .npmrc устанавливает registry=https://registry.npmjs.org/, в файле требований указана ровно одна --index-url https://pypi.org/simple строка, или зависимость в Poetry указывает на источник pypi.org. Большинство репозиториев не используют ни один из этих вариантов, поэтому большинство новых зависимостей не проверяются.
• Отключено — названия не проверяются, и вымышленные пакеты не выявляются.

Только названия новых зависимостей покидают Coroid. Они отправляются в registry.npmjs.org и pypi.org, в api.npmjs.org для получения данных о количестве загрузок npm-пакетов, а также в api.osv.dev (с версией npm) для отчетов о вредоносных пакетах. Ваш код никогда не отправляется. Результаты хранятся до одних суток, чтобы одно и то же имя не проверялось повторно при каждом изменении.

Результаты и принятие решений#

Результаты задачи отображаются в её Качество разделе в Factory. Если агент-разработчик устранил блокирующие результаты до того, как изменение попало на проверку, раздел открывается с Обнаружено anti-slop до проверки, правила, которые были применены, а также под Показать, где и когда, файл и строку каждого результата, а также проверку, которая его выявила. В Factory, в разделе Технический долг, учитываются временные решения, обнаруженные до проверки за последние 30 дней, и владельцам и администраторам показываются проекты, в которых их ещё не проверяют, вместе с Включить anti-slop.

Чтобы принять результат, укажите причину и срок действия; принятие регистрируется для конкретного результата. Агенты не могут принимать собственные результаты. Если агент утверждает, что тест дал ошибочный результат и меняет его, рецензент должен одобрить такое изменение перед тем, как проверка пройдёт.

Оценка правил#

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

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

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

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