---
title: "Проверка автоматической сборки"
id: "581"
type: "page"
slug: "automated-build"
published_at: "2026-06-03T14:29:15+00:00"
modified_at: "2026-10-04T10:20:48+00:00"
url: "https://pastukhov.com/agents/agent/docs/validation/automated-build"
markdown_url: "https://pastukhov.com/agents/agent/docs/validation/automated-build.md"
excerpt: "build — это просто описательное имя для любого действия, которое выполняется автоматически по определённым событиям.…"
---

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

[https://pastukhov.com/agents/agent/docs/validation/automated-build.md](https://pastukhov.com/agents/agent/docs/validation/automated-build.md)

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

![Автоматическая проверка обновлений файлов проекта](https://pastukhov.com/wp-content/uploads/2026/06/automated-build-validation.png)Это даёт почти неограниченную гибкость для автоматической проверки вывода модели, правок проекта и навыков. Даже там, где нужна ручная проверка, сборки помогают: можно поручить модели заранее подготовить список «горячих точек» для проверки или подробный отчёт с инструкциями для ручного разбора.

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

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

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

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

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

Сборки настраиваются в `.pastukhov/build.yml`. Каждая сборка задаёт команду, события, по которым она запускается, и необязательные параметры: задержку, тайм-аут, нормализацию путей. Есть два типа: сборки **command** — просто выполняют команду оболочки, и сборки **prompt** — проверка, управляемая ИИ (описана в руководстве [Автоматические сборки промптов](/agents/agent/docs/validation/prompt-builds)
).

```
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** на вкладке «Ошибки» или «Предупреждения» в диалоге вывода. Либо просто скопируйте и вставьте вывод вручную. Сборки конфигурации по умолчанию скрыты из интерфейса, чтобы не создавать визуального шума, — вы увидите их, только когда есть проблемы.

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

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

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

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

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

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

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

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

Полная справка по сборкам — на странице [Сборка и развёртывание](/agents/agent/docs/build-deploy)
, цикл обратной связи Автоисправления — в [Автоисправлении](/agents/agent/docs/autofix)
, мониторинг ошибок во время работы — в [Мониторинге вывода развёртывания](/agents/agent/docs/validation/deploy-output)
.

**[← Проверка изменений git](/agents/agent/docs/validation/git-change)**

**[Автоматические сборки промптов →](/agents/agent/docs/validation/prompt-builds)**