--- title: "Сборка и развёртывание" id: "344" type: "page" slug: "build-deploy" published_at: "2026-05-19T11:30:45+00:00" modified_at: "2026-06-13T00:52:52+00:00" url: "https://pastukhov.com/code/docs/build-deploy" markdown_url: "https://pastukhov.com/code/docs/build-deploy.md" excerpt: "В Pastukhov Code “сборка” — это автоматический валидатор, который проверяет действия ИИ. Несмотря на название,…" --- # Сборка и развёртывание [https://pastukhov.com/code/docs/build-deploy.md](https://pastukhov.com/code/docs/build-deploy.md) ## Что такое сборки? В Pastukhov Code “сборка” — это автоматический валидатор, который проверяет действия ИИ. Несмотря на название, сборкам не нужно компилировать что-либо или создавать бинарный вывод — им просто нужно выполнить команду и сообщить об ошибках и предупреждениях в структурированном формате, который может распознать [парсер сборок](/code/docs/build-deploy#build-parser) . Думайте о сборках как о контрольных точках качества. Каждая из них — это отдельная автоматическая проверка, которая запускается при изменении соответствующих файлов. Компилятор, обнаруживающий синтаксические ошибки — это сборка. Линтер, отмечающий неиспользуемые переменные — это сборка. Тестовый раннер, падающий на утверждении — это сборка. Сканер безопасности, находящий уязвимости — тоже сборка. Всё это одно и то же — команда, создающая структурированный вывод ошибок. Сборки настраиваются в файле `.pastukhov/build.yml` в корне вашего проекта. Каждая сборка определяет команду для выполнения, файлы для отслеживания и правила парсинга в `.pastukhov/build.parser`, которые извлекают ошибки и предупреждения из вывода команды. Когда ИИ изменяет ваш проект, Pastukhov Code обнаруживает изменения файлов и автоматически запускает соответствующие сборки. Настоящая сила заключается в [AutoFix](/code/docs/autofix) . Когда AutoFix включён, любые ошибки и предупреждения от ваших сборок автоматически передаются модели ИИ как сообщения чата. Модель видит точный вывод ошибок, понимает, что пошло не так, и пытается исправить — что снова запускает сборки, создавая обратную связь. Чем больше сборок вы добавите, тем больше автоматической валидации получает модель, и тем лучше становятся ваши результаты. ## Конфигурация сборок Сборки определяются в файле `.pastukhov/build.yml`. Каждая сборка — это именованная задача с командой оболочки, шаблонами файлов для отслеживания и дополнительными настройками. Вам не нужно создавать или редактировать этот файл вручную — используйте кнопку **Исправить build.yml с помощью ИИ** (значок sparkle) в заголовке панели сборок, чтобы попросить ИИ настроить сборки для вашего проекта. ``` build: task-name: path: "src/" # Рабочая директория для команды command: "npm run check" # Команда оболочки для выполнения delay: 3 # Секунды ожидания перед запуском (по умолчанию: 3) timeout: 60 # Максимальное время выполнения в секундах (по умолчанию: 60) watch: "*.ts *.js" # Шаблоны файлов или имена сборок (разделённые пробелом или запятой), или `chat` для отслеживания текущего завершения чата commandOutput: "" # Путь к дополнительному файлу вывода (необязательно) ignore: [] # Regex-шаблоны для фильтрации из ошибок/предупреждений replacements: # Поиск/замена в путях вывода - find: "/tmp/build" replace: "/project" stopStrings: [] # Строки, которые немедленно прерывают сборку startSound: "" # Звук при запуске сборки (встроенный или пользовательский) endSound: "" # Резервный звук при завершении сборки (используется, когда не задан специфичный звук результата) successSound: "" # Звук при успешной сборке (переопределяет endSound) warningSound: "" # Звук при завершении с предупреждениями (переопределяет endSound) errorSound: "" # Звук при неудачной сборке (переопределяет endSound) soundVolume: 1.0 # Громкость 0-1 для звуков сборки ``` Каждая настройка управляет определённой частью жизненного цикла сборки: - **path** — Рабочая директория, в которой выполняется команда. По умолчанию — корень проекта - **command** — Команда оболочки для выполнения. Это может быть любая команда, доступная в вашей среде - **delay** — Секунды ожидания после обнаружения изменения файла перед запуском. Это предотвращает частые сборки, когда несколько файлов изменяются одновременно. По умолчанию — 3 секунды - **timeout** — Максимальное время выполнения в секундах. Если команда превышает это время, она прерывается. По умолчанию — 60 секунд - **watch** — Glob-шаблоны файлов (например, `*.ts *.js`) или имена родительских сборок (например, `server-build,client-copy`). При отслеживании другой сборки эта сборка запускается только после успешного завершения родительской - **commandOutput** — Путь к дополнительному файлу вывода для парсинга. Некоторые инструменты записывают результаты в файлы вместо stdout (например, JetBrains inspectcode создаёт XML). Укажите этот файл, и парсер извлечёт из него ошибки - **ignore** — Regex-шаблоны для фильтрации из ошибок и предупреждений. Используйте это для подавления известных ложных срабатываний или шума от конкретных инструментов - **replacements** — Пары поиска/замены, которые переназначают пути в выводе. Это необходимо, когда сборки запускаются во временных директориях (контейнеры Docker, изолированные папки сборок), чтобы места ошибок указывали на ваши фактические файлы проекта - **stopStrings** — Строки, которые немедленно прерывают сборку при обнаружении в выводе (например, `"The operation was canceled"`) - **startSound** — Звук для воспроизведения при запуске сборки (встроенное имя вроде `"complete"` или пользовательский звук из `.pastukhov/sounds/`) - **endSound** — Резервный звук для воспроизведения при завершении сборки. Используется, когда не заданы специфичные звуки результата - **successSound** — Звук для воспроизведения при успешной сборке. Имеет приоритет над `endSound` - **warningSound** — Звук для воспроизведения при завершении с предупреждениями. Имеет приоритет над `endSound` - **errorSound** — Звук для воспроизведения при неудачной сборке. Имеет приоритет над `endSound` - **soundVolume** — Громкость звуков сборки (0-1, по умолчанию 1.0) Сборки могут объединяться в цепочки для создания упорядоченных пайплайнов. Вместо отслеживания файлов сборка может отслеживать другую сборку: ``` build: compile: command: "dotnet build" watch: "*.cs" test: command: "dotnet test --no-build" watch: compile # Запускается только после успешной компиляции ``` Система сборок отслеживает файлы вашего проекта с помощью мониторов файловой системы. Когда файл, соответствующий шаблону `watch` сборки, изменяется, система запускает таймер обратного отсчёта для `delay` этой сборки. Если больше соответствующих файлов изменяются во время отсчёта, таймер сбрасывается. После завершения отсчёта выполняется команда сборки. Если файлы изменяются во время выполнения сборки, запущенная сборка отменяется и перезапускается с новыми изменениями. Вывод сборки сохраняется в `.pastukhov/build/` с тремя файлами на задачу: `{task-name}.output.txt` (полный вывод команды), `{task-name}.errors.txt` (распарсенные ошибки) и `{task-name}.warnings.txt` (распарсенные предупреждения). Вам не нужно создавать или редактировать `build.yml` вручную. Файл `.pastukhov/README.md` документирует полный формат — просто попросите модель ИИ добавить или изменить сборки для вас, и она использует эту документацию для правильной настройки. ## Файлы парсеров Pastukhov Code использует три файла парсеров для извлечения ошибок и предупреждений из текстового вывода. Все три имеют одинаковый формат и полностью самодокументированы встроенными комментариями — вам не нужно редактировать их вручную. Если вы добавляете пользовательские валидаторы с незнакомым форматом вывода, или если ваше развёрнутое приложение создаёт ошибки в формате, который парсер не распознаёт, просто попросите модель ИИ обновить парсер для вас. Самый простой способ исправить шаблоны парсера — прямо из вывода: выделите текст в любой области вывода сборки, развёртывания или скрипта, и появится плавающая кнопка **Исправить парсер**. Нажмите её, и ИИ получит выделенный текст вместе с правильно отформатированным запросом на обновление соответствующего файла парсера — вводить ничего не нужно. ### Формат парсера Каждый файл парсера содержит блоки `[ERROR]` и `[WARNING]`. Внутри каждого блока строки — это regex-шаблоны, которые парсер пытается сопоставить последовательно с выводом команды: - **Строки комментариев**, начинающиеся с `#`, игнорируются — файлы парсеров используют их для документации, что сопоставляет каждый шаблон - **Однострочные шаблоны** — Regex, который должен точно сопоставить одну строку вывода. Парсер пытается следующий шаблон на следующей строке - **Многострочные шаблоны** — Обёрнуты в `{{...}}`, сопоставляют ноль или более последовательных строк, соответствующих внутреннему regex. Именно так вы захватываете контекст с отступом после заголовка ошибки, стек-трейсы или любой многострочный вывод ошибок Вот конкретный пример, показывающий, как шаблоны захватывают ошибку TypeScript с её контекстом с отступом: ``` # Ошибки TypeScript [ERROR] .*\.ts.* # Сопоставляет строку, содержащую путь к .ts файлу Error.* # Сопоставляет строку, начинающуюся с "Error" {{^\s+}} # Сопоставляет ноль или более строк, начинающихся с пробелов (контекст) [/ERROR] ``` Парсер работает, перебирая строки вывода. В каждой позиции он пытается применить шаблоны каждого блока `[ERROR]` по порядку. Когда все шаблоны в блоке сопоставляются последовательно, эти строки извлекаются как одна ошибка, и парсер переходит к следующим. Блоки `[WARNING]` работают идентично. Это означает, что шаблоны, которые появляются раньше в файле, имеют приоритет — парсер прекращает попытки дополнительных блоков, как только находит сопоставление. Парсер автоматически перезагружает свои правила при изменении файла, поэтому изменения вступают в силу немедленно без перезапуска. ### build.parser Файл `.pastukhov/build.parser` извлекает ошибки и предупреждения из вывода команд сборки. Он поставляется с шаблонами для распространённых компиляторов и инструментов — C# (MsBuild, CSC), TypeScript, Svelte, Vite, Python (ruff) и ReSharper — но вы можете добавить шаблоны для любого инструмента, который использует ваш проект. ``` # Ошибки C# - формат MsBuild с путём к файлу и (строка,кол)->(строка,кол) CSxxxx: [ERROR] \[MsBuild\].*\(\d+,\d+\)-\>\(\d+,\d+\)\s+CS\d+\:.* [/ERROR] # Ошибки Python ruff (коды F/E) - с расположением файла и контекстом [ERROR] [A-Z]\d+\s+(\[\*\]\s+)?.* \s*--\>.* {{^\s+.*|\d+\s+\|.*}} [/ERROR] # Предупреждения C# [WARNING] \(\d+,\d+\): warning [/WARNING] ``` ### deploy.parser Файл `.pastukhov/deploy.parser` извлекает ошибки и предупреждения из вывода времени выполнения вашего развёрнутого приложения. Он обрабатывает распространённые шаблоны ошибок времени выполнения — необработанные исключения, стек-трейсы, сбои подключения к базе данных, коды ошибок HTTP и сбои приложений — на разных платформах: ``` # Необработанные исключения (полный стек-трейс) [ERROR] Unhandled exception\. {{\S.*}} [/ERROR] # Уровень лога ошибок ASP.NET (Serilog/ILogger) [ERROR] ^err\:.* {{^\s+\S.*}} [/ERROR] # Внутренние ошибки сервера HTTP 500 [ERROR] .*status code 500 [/ERROR] # Ошибки отказа в подключении [ERROR] Connection refused [/ERROR] # Исключения SQL базы данных [ERROR] SqlException\:.* {{^\s+\S.*}} [/ERROR] # Уровень лога предупреждений [WARNING] ^warn\:.* {{^\s+\S.*}} [/WARNING] ``` ### output.parser Файл `.pastukhov/output.parser` — это универсальный парсер для вывода обычных скриптов — ошибки оболочки, стек-трейсы Python, исключения Node.js, сбои npm и другие распространённые форматы ошибок. Он используется при парсинге вывода, который не попадает в категории сборок или развёртываний: ``` # Команда оболочки не найдена [ERROR] .*command not found [/ERROR] # Стек-трейсы Python [ERROR] ^Traceback \(most recent call last\)\: {{.*}} [/ERROR] # npm ERR! [ERROR] ^npm ERR\!.* [/ERROR] # Предупреждения Python [WARNING] .*Warning\:.* {{^\s+.*}} [/WARNING] ``` ## Валидация конфигурации 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, предупреждает о неизвестных свойствах (ожидает `variables`) - `providers.yml` — Синтаксис YAML, предупреждает о неизвестных свойствах провайдеров и окружений - `*.parser` — Парность блоков (`[ERROR]`/`[/ERROR]`), валидность regex, шаблоны вне блоков Сообщения об ошибках и предупреждениях ссылаются на соответствующий раздел в `.pastukhov/README.md`, чтобы вы могли найти правильный формат: ``` Error: build.yml - 'lint': Missing required field 'command' or 'prompt' (see .pastukhov/README.md#buildyml) Warning: deploy.yml - 'staging': Unknown property 'restart' (see .pastukhov/README.md#deployyml) Warning: skills.yml - 'my-skill': Missing 'enabled' property (see .pastukhov/README.md#skillsyml) ``` Ничего настраивать не нужно — просто редактируйте файлы конфигурации, и валидация запускается автоматически при сохранении. Исправьте любые ошибки, и валидация очистится при следующей проверке. ## Конфигурация развёртывания Развёртывания настраиваются в файле `.pastukhov/deploy.yml`. Pastukhov Code поддерживает два метода развёртывания: **debug** для локальной разработки и **docker** для развёртываний удалённых контейнеров. ### Развёртывание debug (локальное) Развёртывания debug запускают ваше приложение непосредственно на локальной машине. Это самый распространённый метод во время разработки: ``` deploy: my-app: method: "debug" # Обязательно: должно быть "debug" os: "linux" # "linux" или "windows" (по умолчанию: "linux") path: "./server" # Путь к файлам приложения command: "dotnet run" # Команда для запуска приложения delay: 3 # Задержка перед запуском (по умолчанию: 3) timeout: 60 # Максимальное время выполнения (по умолчанию: 60) watch: "build-app" # Имена сборок (разделённые пробелом или запятой), или `chat` shallowCopy: true # Копировать только изменённые файлы (по умолчанию: true) url: "https://app.example.com/" # Необязательный URL для кнопки ссылки startSound: "" # Звук при запуске развёртывания (встроенный или пользовательский) endSound: "" # Звук при завершении развёртывания (встроенный или пользовательский) soundVolume: 1.0 # Громкость 0-1 для звуков развёртывания environment: # Переменные окружения для процесса - APP_KEY=your-key - APP_DB=/path/to/database ``` Ключевые настройки: - **watch** — Список имён сборок (разделённый пробелами или запятыми) или `chat` для запуска при завершении пользовательского чата. Развёртывание запускается или перезапускается автоматически, когда все перечисленные сборки завершаются успешно - **shallowCopy** — Когда включено, копирует только изменённые файлы в директорию развёртывания при каждом перезапуске, что значительно быстрее полного копирования - **url** — Необязательный URL вашего развёрнутого приложения. Отображается в интерфейсе как кликабельная кнопка, которая открывает приложение в новой вкладке браузера - **environment** — Переменные окружения, передаваемые развёрнутому процессу - **startSound** — Звук для воспроизведения при запуске развёртывания (встроенное имя вроде `"complete"` или пользовательский звук из `.pastukhov/sounds/`) - **endSound** — Звук для воспроизведения при завершении развёртывания - **soundVolume** — Громкость звуков развёртывания (0-1, по умолчанию 1.0) ### Развёртывание Docker (удалённое) Развёртывания Docker отправляют ваше приложение на удалённый сервер как контейнер. Это полезно для окружений staging и production: ``` deploy: my-docker: method: "docker" # Обязательно: должно быть "docker" os: "linux" host: "server.com" # Удалённый хост username: "deploy" # Имя пользователя SSH sshKeyPath: "~/.ssh/key" # Путь к ключу SSH sshPort: 22 # Порт SSH (по умолчанию: 22) imageName: "app:latest" # Имя образа Docker containerName: "myapp" # Имя контейнера dockerfilePath: "./Dockerfile" buildContext: "." # Контекст сборки (по умолчанию: ".") buildArgs: # Аргументы сборки Docker - NODE_ENV=production environmentVariables: # Переменные окружения контейнера - PORT=3000 - DATABASE_URL=postgresql://... portMappings: # Соответствия портов Хост:Контейнер "8080": "3000" volumeMappings: # Соответствия томов Хост:Контейнер "/var/log/app": "/app/logs" networks: # Сети Docker - myapp-network pullLatestImage: true # Загружать базовый образ перед сборкой (по умолчанию: true) removeExistingContainer: true # Удалять старый контейнер перед развёртыванием (по умолчанию: true) healthCheckPath: "/" # Конечная точка проверки здоровья (по умолчанию: "/") healthCheckInterval: 30 # Интервал проверки здоровья в секундах (по умолчанию: 30) healthCheckRetries: 3 # Повторы проверки здоровья (по умолчанию: 3) localSourcePath: "." # Локальный путь для развёртывания remoteWorkDir: "/tmp/deploy" # Удалённая рабочая директория excludePaths: # Пути для исключения из rsync - ".git" - "node_modules" - ".pastukhov" ``` Вывод развёртывания сохраняется в `.pastukhov/deploy/` — `{deploy-name}.log` для вывода времени выполнения, плюс отладочные логи на стороне клиента по адресу `{domain}.log` (автоматически обрезаются до 100МБ). Вам не нужно создавать или редактировать `deploy.yml` вручную. Файл `.pastukhov/README.md` полностью документирует оба метода развёртывания — просто попросите модель ИИ настроить или изменить вашу конфигурацию развёртывания, и она обработает детали. ## Управление сборками и развёртываниями **Панель состояния** внизу экрана обеспечивает управление и мониторинг в реальном времени как для сборок, так и для развёртываний. Она обновляется автоматически через живые соединения — обновление не требуется. ### Управление сборками Вкладка **Сборки** показывает все настроенные сборки как аккордеон-список. Каждый элемент отображает своё имя, значок состояния и значки количества ошибок/предупреждений. - **Пересобрать** — Наведите курсор на любую завершённую сборку, чтобы открыть кнопку пересборки. Нажмите её для ручного запуска новой сборки (отключено во время выполнения сборки) - **Просмотр вывода** — Нажмите имя сборки, чтобы открыть полный вывод в диалоге с тремя вкладками: **Журнал** (исходный вывод, последние 2000 строк), **Ошибки** (распарсенные ошибки, красные подсветки), **Предупреждения** (распарсенные предупреждения, жёлтые подсветки) - **Переход к ошибкам** — Нажмите на значок количества ошибок или предупреждений, чтобы открыть диалог вывода непосредственно на этой вкладке - **Копировать** — Копирует содержимое текущей вкладки в буфер обмена - **Отправить в чат** — Отправляет ошибки или предупреждения ИИ как сообщение, обёрнутое в блок кода `build.log`. Для предупреждений добавляется “исправь предупреждения, не игнорируй их”. Контент ограничен первыми 20КБ В заголовке панели сборок также есть кнопка **Исправить build.yml с помощью ИИ** (значок sparkle) рядом с кнопкой редактирования build.yml. Она добавляет запрос во ввод чата, прося ИИ настроить автоматические сборки для вашего проекта, используя `.pastukhov/README.md` как справочник. В диалогах вывода сборок и разделах ошибок/предупреждений панели сборок выделение любого текста открывает плавающую кнопку **Исправить парсер**. Нажатие на неё отправляет выделенный текст ИИ с запросом на обновление `build.parser` — поэтому вам не нужно вручную вводить запросы на исправление парсера. Сборки, завершившиеся без проблем, автоматически сворачиваются. Сборки с ошибками или предупреждениями остаются развёрнутыми, чтобы вы могли немедленно их устранить. ### Управление развёртываниями Вкладка **Развёртывания** показывает каждое настроенное развёртывание с его именем, состоянием и кнопками действий: - **Запустить** — Запускает приложение. Вывод времени выполнения начинает транслироваться в реальном времени - **Остановить** — Корректно shuts down запущенное приложение - **Перезапустить** — Останавливает и немедленно запускается снова (также запускается автоматически, когда отслеживаемые сборки завершаются) - **Открыть URL** — Если URL настроен в `deploy.yml`, кнопка открывает ваше развёрнутое приложение в новой вкладке браузера - **Просмотр вывода** — Открывает диалог с вкладками Журнал, Ошибки и Предупреждения, как диалог вывода сборок. Вывод развёртывания парсится в реальном времени с помощью `deploy.parser` — ошибки времени выполнения, такие как необработанные исключения, сбои подключения к базе данных и ошибки HTTP 500, обнаруживаются и подсвечиваются. Выделение текста в выводе открывает плавающую кнопку **Исправить парсер** для обновления `deploy.parser` Вы можете изменить размер панели состояния или полностью свернуть её для получения большего пространства на экране. На мобильных устройствах панели сборок и развёртываний располагаются вертикально под основным контентом. ## Творческие сборки Термин “сборка” — это просто название. Вы можете создавать сборки, которые делают всё что угодно, что создаёт структурированный вывод ошибок. Вот несколько примеров, выходящих за рамки традиционной компиляции: ### Линтеры и форматтеры ``` build: eslint: path: "client/" command: "npx eslint src/ --format stylish" watch: "*.ts *.svelte" ruff: path: "src/" command: "ruff check ." watch: "*.py" ``` ### Проверщики типов ``` build: typecheck: path: "client/" command: "npx tsc --noEmit" watch: "*.ts" ``` ### Тестовые раннеры ``` build: tests: path: "server/" command: "dotnet test --no-build" watch: compile ``` ### Сканеры безопасности ``` build: audit: path: "./" command: "npm audit" watch: "package.json" ``` ### Пользовательские валидаторы проекта Вы можете написать собственные скрипты валидации, которые проверяют специфические для проекта правила — соглашения об именовании, требуемые структуры файлов, соответствие API-контрактам или любой инвариант, который должен поддерживать ваш проект. Пока скрипт выводит ошибки в формате, который может сопоставить парсер, он работает как сборка. Если формат вывода вашего валидатора не распознаётся, попросите модель ИИ добавить соответствующие шаблоны в `build.parser`. Каждая добавленная сборка увеличивает количество автоматической обратной связи, которую получает модель ИИ через AutoFix. Проект со сборкой компилятора, сборкой линтера, сборкой проверщика типов и сборкой тестового раннера даёт модели четыре независимые проверки качества — каждая обнаруживает разные категории проблем, которые другие могут пропустить. ## Автоматическая пересборка и AutoFix Когда ИИ изменяет файлы вашего проекта, Pastukhov Code обнаруживает изменения и автоматически запускает соответствующие сборки. Вам не нужно запускать никаких команд или нажимать кнопки — весь цикл валидации работает самостоятельно. Вот автоматический рабочий процесс: 1. **ИИ изменяет файлы** — Модель вносит изменения в код вашего проекта 2. **Запуск сборок** — Pastukhov Code обнаруживает изменения файлов и запускает соответствующие сборки после их настроенных задержек 3. **Парсинг вывода** — Парсер сборок извлекает ошибки и предупреждения из вывода каждой сборки 4. **AutoFix проверяет результаты** — Если какие-либо сборки создали ошибки, AutoFix оборачивает их в блок кода markdown и отправляет как сообщение чата модели ИИ. Для предупреждений добавляется “исправь предупреждения, не игнорируй их” 5. **ИИ исправляет проблемы** — Модель видит вывод ошибок, понимает, что пошло не так, и вносит исправления 6. **Перезапуск сборок** — Исправления вызывают новые изменения файлов, которые перезапускают цикл 7. **Успех** — Когда все сборки проходят без ошибок, цикл завершается, и ваше приложение развёртывается повторно Этот цикл обратной связи работает полностью без вашего участия. AutoFix обрабатывает только тогда, когда нет активной сессии ИИ, проверяет дубликаты ошибок в последних 10 сообщениях для предотвращения бесконечных циклов и уважает лимит параллельности. Вы можете наблюдать за этим на панели сборок и в истории чата или просто проверить позже, чтобы увидеть результаты. [Узнайте больше о конфигурации и ограничениях AutoFix](/code/docs/autofix) **[← Файлы](/code/docs/files)** **[Git →](/code/docs/git)**