Проверка автоматической сборки

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

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

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

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

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

Визуального шума тоже меньше — вы видите, как модель выполняет задачи, а не как она раз за разом запускает линтеры и сборщики. Чтобы модель не дублировала эту работу, добавьте в 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           # Участие Автоисправление: always, errors, warnings, never
    startSound: ""            # Звук при запуске сборки (встроенный или пользовательский)
    endSound: ""              # Звук при завершении сборки (встроенный или пользовательский)
    soundVolume: 1.0          # Громкость 0-1 для звуков сборки

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

Поле watch определяет, по какому событию запускается сборка. Вариантов три:

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

Каждая сборка следит ровно за одним типом события — файлами, родительскими сборками или завершением чата. Если нужно срабатывание на комбинацию событий, продублируйте сборку с разными watch: так каждую проще отлаживать и контролировать. Чтобы не дублировать, используйте схему «родитель — ребёнок»: создайте несколько лёгких родительских сборок (no-op), каждая следит за своим событием, а одна дочерняя следит за всеми ними — она запустится, когда завершится любая из родителей, и выполнит команду один раз. Родительские сборки скройте с панели с помощью display: never.

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

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

Такая сборка запускается, только когда завершены все более высокоуровневые конвейеры: сначала обрабатываются все отложенные сообщения пользователя (они всегда заходят в чат первыми), а конвейер Автоисправления полностью завершён без оставшихся ошибок и предупреждений. Запускать тяжёлые операции в «грязном» состоянии бессмысленно — проблемы в любом случае будут исправлены вашим отзывом или Автоисправлением.

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

У каждой сборки есть два поля, которые определяют её поведение в интерфейсе и с Автоисправлением:

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

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

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

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

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/ тремя файлами: {имя-задачи}.output.txt (полный вывод команды), {имя-задачи}.errors.txt (разобранные ошибки) и {имя-задачи}.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 Agent автоматически проверяет все конфигурационные файлы .pastukhov/ при каждом сохранении. Всего девять проверок, каждая отвечает за свой файл:

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

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

⚠️ Ошибки и предупреждения проверки конфигурации намеренно исключены из конвейера Автоисправления — чтобы не засорять существующие чаты, не связанные с настройками Pastukhov Agent. Если проверка нашла проблему, создайте свежий чат, кликните на бейдж ошибок/предупреждений на панели сборки, а затем кнопку Send на вкладке «Ошибки» или «Предупреждения» в диалоге вывода. Либо просто скопируйте и вставьте вывод вручную. Сборки конфигурации по умолчанию скрыты из интерфейса, чтобы не создавать визуального шума, — вы увидите их, только когда есть проблемы.

Цикл обратной связи Автоисправление

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

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

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

Эффективные приёмы проверки

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

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

Компилятор + линтер + проверка типов + тесты — четыре независимые проверки, каждая ловит то, что упускают другие. Чем больше сборок, тем больше откликов получает Автоисправление;
Выстраивайте сборки по зависимостям — сначала компиляция, затем линтер, затем тесты. Каждый шаг запускается после успеха предыдущего, без каскадного шума;
Добавляйте паттерны парсера для своих инструментов — если вывод не разбирается, попросите модель дополнить build.parser. Парсер сам перезагрузится при сохранении;
Используйте замены путей для контейнерных сборок — если сборки работают в Docker или временных папках, отобразите пути обратно к проекту, чтобы координаты ошибок были точными;
Скрывайте шумные сборки (display: never) — держите панель сборки чистой, пряча сборки, чей вывод редко нужен вручную.

Полная справка по сборкам — на странице Сборка и развёртывание, цикл обратной связи Автоисправления — в Автоисправлении, мониторинг ошибок во время работы — в Мониторинге вывода развёртывания.

← Проверка изменений git

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