Валидация автоматической сборки

⚠️ build — это просто описательное имя для любого действия, автоматически выполняемого на определённых событиях. Эти действия не должны генерировать никакого бинарного вывода — единственное требование — предоставлять логи, которые можно автоматически парсить для ошибок и предупреждений.

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

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

Валидация автоматической сборки — ядро конвейера валидации Pastukhov Code. Вместо ожидания, пока модели вызовут npm test или dotnet build, автоматические сборки запускаются при каждом изменении файла, которое ИИ делает в соответствующих папках — компилирование, линтинг, проверка типов и тестирование вашего кода без какого-либо вмешательства. Необработанный вывод сборки затем парсится в структурированные ошибки и предупреждения (используя гибкие правила парсинга, которые вы можете легко обновить), которые поступают обратно в чат в конце с использованием функции AutoFix и панель сборки для немедленного ручного обзора. Вам не нужно ждать окончания чата, чтобы просмотреть ошибки и отправить свой отзыв — именно для этого существует очередь сообщений. Просто отправьте свой отзыв и уходите — он будет автоматически отправлен в чат в конце.

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

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

Конфигурация сборки

Сборки настроены в .pastukhov/build.yml. Каждая сборка определяет команду, какие события её запускают, и необязательные настройки для задержки, тайм-аута и нормализации пути. Существуют два типа: сборки command (выполнение оболочки) и сборки prompt (валидация, управляемая ИИ — описана в руководстве Автоматические сборки промптов).

build:
  task-name:
    path: "src/"              # Рабочий каталог для команды
    command: "npm run check"  # Команда оболочки для выполнения
    delay: 3                 # Секунды ожидания перед запуском (по умолчанию: 3)
    timeout: 60              # Максимальное время выполнения в секундах (по умолчанию: 60)
    watch: "*.ts *.js"      # Глобальные маски файлов или имена сборок (разделены пробелом или запятой), или `chat` для мониторинга текущего завершения чата
    commandOutput: ""         # Путь к дополнительному файлу вывода (необязательно)
    ignore: []                # Регулярные выражения для фильтрации из ошибок/предупреждений
    replacements:             # Найти/заменить в путях вывода
      - find: "/tmp/build"
        replace: "/project"
    stopStrings: []           # Строки, которые немедленно прерывают сборку
    display: always           # Видимость UI: always, errors, warnings, never
    autofix: always           # Участие AutoFix: always, errors, warnings, never
    startSound: ""            # Звук при запуске сборки (встроенный или пользовательский)
    endSound: ""              # Звук при завершении сборки (встроенный или пользовательский)
    soundVolume: 1.0          # Громкость 0-1 для звуков сборки

Триггеры сборки

Поле watch поддерживает три типа триггеров:

Глобальные маски файлов — Glob-паттерны вроде *.ts *.svelte. Сборка следит за папкой path на соответствующие изменения файлов и выполняет команду относительно неё, запуская после настроенной задержки
Имена родительских сборок — Ссылка на другую сборку по имени. Эта сборка запускается только после успешного завершения родительской, включая упорядоченные конвейеры
chat — Особый триггер, который срабатывает, когда сессия чата пользователя завершается. Доступен для всех типов сборок и развёртываний

Сборка может следить за изменениями файлов, родительскими сборками или завершениями чата — каждая сборка следит точно за одним типом события. Если вам нужна сборка для активации на комбинации событий, дублируйте её с разными командами watch. Это намеренно: сборки с одной ответственностью легче отлаживать и мониторить. Для сокращения дублирования используйте родительско-дочернюю схему: создайте несколько легковесных родительских сборок no-op, каждая следит за одним типом события, затем имейте одну дочернюю сборку, следящую за всеми ними — она запускается, когда любая родительская завершается, выполняя вашу команду только один раз. Установите display: never на родительских сборках, чтобы скрыть их с панели сборки.

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

⚠️ watch: chat включает автоматический запуск сборок в конце любого инициированного пользователем (не субагентом) чата. Используйте это для тяжёлой валидации, которая не должна перезапускаться при каждом обновлении файла — сборки промптов, аудиты безопасности, дорогостоящий анализ или всё, что занимает слишком много времени для триггеров наблюдения за файлами.

Она запускается только когда завершены более высокоуровневые конвейеры: сначала обрабатываются все очередные сообщения пользователя (они всегда заходят в чат до всего остального), и конвейер AutoFix полностью завершён без оставшихся ошибок или предупреждений. Нет смысла запускать тяжёлые операции в “грязном” состоянии — эти проблемы будут автоматически исправлены вашим отзывом или конвейером AutoFix.

Управление отображением и AutoFix

Каждая сборка имеет два поля управления, которые определяют её поведение в UI и с AutoFix:

display — Управляет тем, когда сборка появляется на панели сборки: always (по умолчанию), errors (только когда существуют ошибки), warnings (ошибки или предупреждения) или never (скрыто)
autofix — Управляет тем, будет ли AutoFix направлять ошибки этой сборки ИИ: always (по умолчанию), errors, warnings или never. Используйте never для сборок, вывод которых требует ручного обзора, например, сборки промптов, тесты безопасности, анализ высокого уровня

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

Цепочки сборки

Сборки могут быть объединены в цепочку путём наблюдения за другими сборками вместо файлов. Система автоматически разрешает зависимости и запускает сборки в правильном порядке:

build:
  compile:
    command: "dotnet build"
    watch: "*.cs"

  inspect:
    command: "jb inspectcode Code.sln -f=Xml --verbosity=ERROR -o=bin/inspectcode.xml"
    commandOutput: "/tmp/code/builds/inspect/bin/inspectcode.xml"
    watch: compile        # Запускается только после успешной компиляции

  test:
    command: "dotnet test --no-build"
    watch: compile        # Запускается только после успешной компиляции

Парсер сборки

Вывод сборки хранится в .pastukhov/build/ с тремя файлами на задачу: {task-name}.output.txt (полный вывод команды), {task-name}.errors.txt (спарсенные ошибки) и {task-name}.warnings.txt (спарсенные предупреждения).

Парсер сборки преобразует необработанный вывод команды в структурированные ошибки и предупреждения. Он читает .pastukhov/build.parser, который использует блоки [ERROR]/[/ERROR] и [WARNING]/[/WARNING], содержащие последовательные регулярные паттерны. Парсер автоматически перезагружается, когда файл изменяется — перезапуск не нужен.

⚠️ Не пытайтесь редактировать файлы парсера вручную — попросите ИИ-модель сделать это за вас. Самый простой способ: выберите любой непарсенный текст в выводе сборки (Панель сборки или диалог вывода) и кликните на плавающую кнопку Fix parser — она отправляет выбранный текст ИИ с правильно отформатированным промптом для обновления build.parser. В качестве альтернативы, используйте .pastukhov/README.md как ссылку в чате.

Формат парсера

Строки комментариев, начинающиеся с #, игнорируются
Однострочные паттерны — Регулярное выражение, которое должно точно соответствовать одной строке вывода
Многострочные паттерны — Обёрнуты в {{...}}, соответствуют нулю или более последовательным строкам, следующим за внутренним регулярным выражением

# Ошибки TypeScript с отступным контекстом
[ERROR]
.*\.ts.*              # Соответствует строке, содержащей путь .ts файла
Error.*               # Соответствует строке, содержащей "Error"
{{^\s+}}              # Соответствует нулю или более строк, начинающимся с пробелов
[/ERROR]

# Ошибки компилятора C# (формат MsBuild)
[ERROR]
\[MsBuild\].*\(\d+,\d+\)->\(\d+,\d+\)\s+CS\d+\:.*
[/ERROR]

# Ошибки Python ruff
[ERROR]
[A-Z]\d+\s+(\[\*\]\s+)?.*
\s*-->.*
{{^\s+.*|\d+\s+\|.*}}
[/ERROR]

# Предупреждения
[WARNING]
\(\d+,\d+\): warning
[/WARNING]

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

Замены путей

Сборки часто запускаются во временных каталогах, поэтому пути ошибок не соответствуют вашим фактическим файлам проекта. Поле replacements перемапливают пути:

build:
  client-build:
    path: "client/"
    command: "npm run build"
    watch: "*.ts *.svelte"
    replacements:
      - find: "/tmp/code/builds/client-build"
        replace: "/project/client"

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

Валидация конфигурации

Pastukhov Code автоматически валидирует все конфигурационные файлы .pastukhov/ при сохранении. Девять валидаторов запускаются при каждом сохранении, каждый нацелен на конкретный конфигурационный файл:

build.yml — Синтаксис YAML, требует command или prompt, предупреждает о неизвестных свойствах
deploy.yml — Синтаксис YAML, предупреждает о неизвестных свойствах
project.yml — Синтаксис YAML, требует name, предупреждает о неизвестных свойствах
hooks.yml — Синтаксис YAML, предупреждает о неизвестных типах событий и свойствах
mcp.yml — Синтаксис YAML, предупреждает о неизвестных ключах верхнего уровня и свойствах сервера
skills.yml — Синтаксис YAML, предупреждает, если enabled отсутствует
environments.yml — Синтаксис YAML, предупреждает о неизвестных свойствах
providers.yml — Синтаксис YAML, предупреждает о неизвестных свойствах провайдера и окружения
*.parser — Проверка пар ([ERROR]/[/ERROR]), действительность регулярных выражений, паттерны вне блоков

Результаты валидации появляются на Панели сборки вместе с вашими обычными сборками. Сообщения об ошибках ссылаются на соответствующий раздел в .pastukhov/README.md, чтобы вы могли найти правильный формат.

⚠️ Ошибки и предупреждения валидации конфигурации исключены из конвейера AutoFix намеренно, чтобы предотвратить загрязнение существующих чатов, не связанных с конфигурациями Pastukhov Code. В случае проблем с валидацией конфигурации, создайте свежий чат, кликните на бейджи ошибок/предупреждений на панели сборки, затем кнопку Send на вкладках ошибок и предупреждений в диалоге вывода. Или скопируйте/вставьте вывод вручную, если это вам удобнее. Сборки конфигурации также скрыты по умолчанию из UI для минимизации визуального шума — вы увидите их только когда существуют проблемы валидации.

Цикл обратной связи AutoFix

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

Обработка только в idle — AutoFix внедряет ошибки только когда нет активной ИИ-сессии, предотвращая конфликты
Осведомленность о зависимостях — AutoFix проверяет, что все родительские сборки завершены перед обработкой ошибок дочерней сборки
Приоритет ошибок — Ошибки отправляются перед предупреждениями. AutoFix не будет касаться предупреждений, пока все ошибки не будут решены
Обнаружение дубликатов — Проверяет последние 10 сообщений на идентичное содержание для предотвращения бесконечных циклов
Режим Autofix — Поле autofix каждой сборки контролирует её участие: always, errors, warnings или never

⚠️ Предупреждения автоматически исправляются особым образом — они всегда приходят с требованием исправить, а не игнорировать их. В противном случае модели часто пропускали бы их как неважные.

Эффективные паттерны валидации

Наслаивайте множественные контрольные качества для комплексного покрытия. Каждая сборка ловит разные категории проблем:

Чем больше автоматизированных сборок у вас есть — тем выше качество финального результата вы получаете. Это напрямую переводится в экономию вашего времени и получение лучшего кода и UI автоматически. Не ленитесь в этой части, экспериментируйте больше с различными способами расширения автоматизированной валидации. Даже когда речь идёт о ручной валидации, вы всегда можете упростить свою жизнь полуавтоматическим подходом — заставьте сборки промптов обнаруживать потенциальные ошибки и предупреждения, затем просмотрите их сначала вместо перепроверки всего с нуля после каждого обновления.

Компилятор + линтер + проверка типов + тесты — Четыре независимые проверки, каждая ловит то, что упускают другие. Чем больше сборок вы добавляете, тем больше автоматического отклика получает AutoFix
Объединяйте сборки в порядке зависимостей — Сначала компилируйте, затем линтуйте, затем тестируйте. Каждый шаг запускается только когда предыдущий успешен, избегая каскадного шума
Добавьте паттерны парсера для ваших инструментов — Если вывод вашей сборки не парсится правильно, попросите ИИ-модель добавить паттерны в build.parser. Парсер автоматически перезагружается при сохранении
Используйте замены путей для контейнеризованных сборок — Если сборки запускаются в Docker или временных каталогах, отобразите пути обратно к вашему проекту, чтобы местоположения ошибок были точными
Установите display: never для шумных сборок — Держите панель сборки чистой, скрывая сборки, вывод которых вам редко нужно инспектировать вручную

Для полной справки по функциям сборки см. Сборка и развёртывание. Для цикла обратной связи AutoFix см. AutoFix. Для мониторинга ошибок runtime см. Мониторинг вывода развёртывания.

← Валидация изменений git

Автоматические сборки промптов →