---
title: "Валидация автоматической сборки"
id: "581"
type: "page"
slug: "automated-build"
published_at: "2026-06-03T14:29:15+00:00"
modified_at: "2026-06-13T00:52:52+00:00"
url: "https://pastukhov.com/code/docs/validation/automated-build"
markdown_url: "https://pastukhov.com/code/docs/validation/automated-build.md"
excerpt: "⚠️ build — это просто описательное имя для любого действия, автоматически выполняемого на определённых событиях.…"
---

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

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

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

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

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

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

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

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

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

Сборки настроены в `.pastukhov/build.yml`. Каждая сборка определяет команду, какие события её запускают, и необязательные настройки для задержки, тайм-аута и нормализации пути. Существуют два типа: сборки **command** (выполнение оболочки) и сборки **prompt** (валидация, управляемая ИИ — описана в руководстве [Автоматические сборки промптов](/code/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           # Участие 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](/code/docs/autofix)
.

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

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

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

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

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

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

Для полной справки по функциям сборки см. [Сборка и развёртывание](/code/docs/build-deploy)
. Для цикла обратной связи AutoFix см. [AutoFix](/code/docs/autofix)
. Для мониторинга ошибок runtime см. [Мониторинг вывода развёртывания](/code/docs/validation/deploy-output)
.

**[← Валидация изменений git](/code/docs/validation/git-change)**

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