Pastukhov Code > Документация > Сборка и развёртывание

Технологии извлечения и анализа данных

Сборка и развёртывание

Что такое сборки?

В Pastukhov Code “сборка” — это автоматический валидатор, который проверяет действия ИИ. Несмотря на название, сборкам не нужно компилировать что-либо или создавать бинарный вывод — им просто нужно выполнить команду и сообщить об ошибках и предупреждениях в структурированном формате, который может распознать парсер сборок.

Думайте о сборках как о контрольных точках качества. Каждая из них — это отдельная автоматическая проверка, которая запускается при изменении соответствующих файлов. Компилятор, обнаруживающий синтаксические ошибки — это сборка. Линтер, отмечающий неиспользуемые переменные — это сборка. Тестовый раннер, падающий на утверждении — это сборка. Сканер безопасности, находящий уязвимости — тоже сборка. Всё это одно и то же — команда, создающая структурированный вывод ошибок.

Сборки настраиваются в файле .pastukhov/build.yml в корне вашего проекта. Каждая сборка определяет команду для выполнения, файлы для отслеживания и правила парсинга в .pastukhov/build.parser, которые извлекают ошибки и предупреждения из вывода команды. Когда ИИ изменяет ваш проект, Pastukhov Code обнаруживает изменения файлов и автоматически запускает соответствующие сборки.

Настоящая сила заключается в 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

← Файлы

Git →