# Руководство пользователя

Автор: Радзивиллович Сергей (prepod2003@yandex.ru, Telegram: @Prepod2003, ТГ канал: edt_ai_1c)

## Что такое плагин

MCP:RSV Server — плагин для 1C:EDT, встраивающий MCP-сервер (Model Context Protocol) прямо в среду разработки. Плагин даёт ИИ-ассистентам (Claude Code, Cursor, Windsurf, Roo Code, Gemini CLI, Qwen Code) прямой доступ к конфигурациям 1С: метаданным, коду, формам, справке платформы, валидации и даже отладчику.

Плагин запускает HTTP-сервер на `127.0.0.1:8770` внутри EDT. ИИ-ассистент подключается по протоколу MCP (JSON-RPC 2.0 over HTTP) и получает 25 инструментов, распределённых по 3 профилям.

Все данные обрабатываются локально — код конфигурации не передаётся в интернет. Сервер работает прямо внутри IDE, без внешних серверов и SaaS-посредников.

## Быстрый старт

### Требования

- 1C:EDT 2025.2
- Java 17 (Azul Zulu 17)
- ИИ-ассистент: Claude Code, Cursor, Windsurf, Roo Code, Gemini CLI, Qwen Code или VS Code + Copilot

### Установка

1. Скачать ZIP-архив `edt-rsv-repository-3.0.0-SNAPSHOT.zip` из релизов
2. В EDT: Справка → Установить новое ПО...
3. Добавить... → Архив... → выбрать скачанный ZIP
4. Отметить MCP:RSV Server → Далее → Готово
5. Перезапустить EDT
6. Проверить: `curl http://localhost:8770/health`

### Подключение ИИ-ассистента

Claude Code (файл `~/.claude/claude_desktop_config.json`):

    {
      "mcpServers": {
        "1c-rsv": {
          "url": "http://127.0.0.1:8770/mcp",
          "transport": "http"
        }
      }
    }

Cursor / Windsurf (файл `.cursor/mcp.json`):

    {
      "mcpServers": {
        "1c-rsv": {
          "url": "http://127.0.0.1:8770/mcp"
        }
      }
    }

Roo Code (VS Code) (файл `.roo/mcp.json` или настройки Roo Code):

    {
      "mcpServers": {
        "1c-rsv": {
          "type": "streamable-http",
          "url": "http://127.0.0.1:8770/mcp"
        }
      }
    }

Gemini CLI (глобально `~/.gemini/settings.json`, или для проекта `.gemini/settings.json`):

    {
      "mcpServers": {
        "1c-rsv": {
          "httpUrl": "http://127.0.0.1:8770/mcp",
          "trust": true
        }
      }
    }

> Для Gemini CLI используется ключ `httpUrl` (не `url`). Глобальный конфиг `~/.gemini/settings.json` подключает MCP-сервер во всех проектах сразу.

Qwen Code CLI (глобально `~/.qwen/settings.json`, или для проекта `.qwen/settings.json`):

    {
      "mcpServers": {
        "1c-rsv": {
          "httpUrl": "http://127.0.0.1:8770/mcp"
        }
      }
    }

> Сервер автоматически согласует версию MCP-протокола с клиентом — совместим как с новыми (2025-11-25), так и со старыми (2024-11-05) клиентами.

### Файл правил для ИИ-ассистента

В комплекте с плагином поставляется файл правил — инструкции, которые учат ИИ-ассистента правильно работать с 1С через MCP. Файл правил:

- Запрещает ИИ читать/редактировать BSL- и MDO-файлы напрямую — только через инструменты MCP
- Объясняет профили и их ограничения
- Учит следовать паттернам конкретной конфигурации (использовать методы БСП, а не платформенные примитивы)
- Обеспечивает управление знаниями — результаты исследований сохраняются между сессиями
- Экономит токены — инструменты вызываются только при необходимости

Скопируйте содержимое `CLAUDE.md` из комплекта в файл правил вашего ИИ-ассистента:

ИИ-ассистент | Файл правил | Расположение
--- | --- | ---
Claude Code | `CLAUDE.md` | Корень проекта
Cursor | `.cursor/rules/rules.mdc` | Корень проекта
Windsurf | `.windsurfrules` | Корень проекта
Roo Code | `.roo/rules/rules.md` | Корень проекта
Gemini CLI | `GEMINI.md` | Корень проекта
Qwen Code | `.qwen/rules` | Корень проекта
Cline | `.clinerules` | Корень проекта

Содержимое правил одинаковое для всех ИИ-ассистентов — меняется только расположение файла.

При работе с проектом ИИ-ассистент автоматически создаст в папке `.ai/` два файла:

Файл | Назначение
--- | ---
`.ai/project-knowledge.md` | Знания о конфигурации: тип, версия, паттерны кода, ключевые модули
`.ai/current-task.md` | Текущая задача: план, статус шагов, хронология

> Рекомендация: добавьте `.ai/` в `.gitignore` или оставьте `project-knowledge.md` в репозитории — он может быть полезен всей команде.

## Лицензирование

### Тарифные планы

MCP:RSV Server распространяется по подписке. Доступны три тарифа:

Тариф | Инструментов | Доступные группы
--- | --- | ---
Аналитик | 13 | Анализ метаданных, Анализ кода, Поиск и навигация
Разработчик | 21 | + Редактирование кода и отладка, Валидация, Сборка и управление (вкл. экспорт)
Архитектор | 24 | + Редактирование метаданных (~140 операций), Юнит-тесты YAxUnit, Сценарное тестирование Vanessa

Подписка платная. Информация об оформлении и оплате — в Telegram-канале @edt_ai_1c.

### Пробный период — бесплатно

При первом запуске EDT после установки автоматически открывается диалог активации. Нажмите «Получить пробный период» — плагин активируется с тарифом Архитектор на 14 дней.

### Активация подписки

1. Оформите подписку на нужный тариф — подробности в Telegram-канале @edt_ai_1c
2. Получите код активации (формат: `ACT-DEV-XXXXXXXX`)
3. В EDT откройте Окно → Настройки → MCP:RSV Server → Лицензия → нажмите «Активировать новый код...»
4. Введите код → нажмите «Активировать»

Привязка к компьютеру происходит автоматически.

### Привязка к компьютеру

Лицензия привязывается к конкретному компьютеру через Machine ID — технический идентификатор, формируемый из аппаратных характеристик устройства.

При переустановке операционной системы или смене компьютера Machine ID изменится. В этом случае введите тот же самый код активации на новой машине: лицензия автоматически перенесётся с сохранением оставшегося срока и тарифа. Дополнительный код для этого получать не нужно.

Если автоматический перенос не сработал (например, лицензия числится заблокированной или её срок уже истёк) — напишите в поддержку:

- Telegram: @Prepod2003
- Email: prepod2003@yandex.ru

### Управление лицензией

Окно → Настройки → MCP:RSV Server → Лицензия

Поле | Описание
--- | ---
Статус | АКТИВНА / ИСТЕКЛА / НЕ АКТИВИРОВАН
Тариф | Аналитик / Разработчик / Архитектор
Действует до | Дата окончания подписки
ID компьютера | Технический идентификатор для поддержки
Файл лицензии | Путь к локальному кэшу (`~/.edt-rsv/license.json`)

### Продление подписки

По истечении срока MCP-сервер перестанет запускаться. Для продолжения:

1. Приобретите новый код активации
2. Введите через «Активировать новый код...» на странице лицензии

## Интерфейс управления в EDT

### Индикатор в строке состояния

В нижней строке состояния EDT появляется значок MCP:RSV Server с цветным индикатором:

Цвет | Значение
--- | ---
Зелёный | Сервер работает, инструменты доступны
Серый | Сервер не запущен

При наведении отображается порт, количество активных инструментов и URL для подключения.

### Контекстное меню (клик по индикатору)

1. Управление сервером: Запустить / Перезапустить / Остановить

2. Профили — быстрое переключение набора инструментов:

- Аналитик [3 группы] — 13 инструментов
- Разработчик [6 групп] — 22 инструмента
- Архитектор [все группы] — 25 инструментов

Активный профиль отмечен галочкой. При переключении реестр инструментов мгновенно перезагружается — перезапуск EDT не требуется.

> Профиль и тариф — разные вещи. Тариф лицензии — это потолок доступа, определяемый подпиской. Профиль — пользовательская настройка в рамках тарифа. Например, пользователь с тарифом «Архитектор» может выбрать профиль «Аналитик», чтобы ограничить набор инструментов для ИИ.

3. Группы инструментов — тонкая настройка. Каждая группа имеет чекбокс для включения/отключения независимо от профиля.

### Страница настроек

Окно → Настройки → MCP:RSV Server — порт сервера (1024–65535, по умолчанию 8770) и управление группами.

## Что умеет плагин — примеры запросов

Главное преимущество MCP-сервера — вы общаетесь с ИИ-ассистентом на естественном языке. Не нужно знать имена инструментов и их параметры. Просто опишите задачу — ассистент сам подберёт нужные инструменты.

### Аналитик — изучение конфигурации

Знакомство с конфигурацией:

> «Расскажи, что это за конфигурация — тип, версия, какие подсистемы есть, сколько объектов»

> «Покажи все справочники, в имени которых есть "Контрагент"»

> «Какие реквизиты у документа РеализацияТоваровУслуг? Покажи табличные части с колонками»

Анализ кода:

> «Проанализируй подсистему Продажи — какие объекты входят, как связаны, где основная логика»

> «Покажи структуру модуля менеджера справочника Номенклатура — какие методы, экспортные ли»

> «Кто вызывает метод ПересчитатьСумму в документе ЗаказКлиента? Покажи цепочку вызовов»

> «Что изменилось в модуле объекта документа ЗаказКлиента с прошлого коммита?»

Поиск по коду:

> «Найди все места, где используется справочник Номенклатура — включая СправочникСсылка и СправочникОбъект»

> «Найди в коде все обращения к регистру ЦеныНоменклатуры»

Справка платформы:

> «Найди в справке платформы какие параметры принимает ВычислитьВыражениеСГруппировкойМассив»

> «Покажи документацию по типу HTTPСоединение — конструктор, методы, свойства»

> «Какие есть функции языка запросов 1С для работы с датами?»

Формы и справка:

> «Покажи, как выглядит форма списка справочника Партнеры — хочу увидеть картинку»

> «Прочитай встроенную справку документа ЗаказКлиента»

### Разработчик — код, валидация, отладка

Написание кода:

> «Найди в конфигурации примеры использования Запрос.Выполнить и напиши аналогичный метод для выборки цен по номенклатуре»

> «Добавь в модуль объекта документа ЗаказКлиента процедуру ПроверитьЗаполнение, которая проверяет наличие строк в табличной части»

> «Замени метод ПересчитатьИтоги в модуле формы — вместо прямого расчёта используй вызов серверной функции»

> «В большом общем модуле УчётНДФЛ найди строку, где формируется удержанный налог, покажи её с соседними и поправь» — `find` находит место по тексту в модуле на десятки тысяч строк, не вычитывая его целиком, и отдаёт точные номера строк для правки.

Валидация:

> «Проверь ошибки в документе ЗаказКлиента и исправь автоматически где возможно»

> «Покажи все ошибки уровня ERROR в проекте — топ-10 самых частых»

Проверка запросов 1С (`validate_query`):

> «Проверь синтаксис этого запроса: ВЫБРАТЬ Наименование ИЗ Справочник.Номенклатура ГДЕ ЭтоГруппа = ЛОЖЬ»

> «В процедуре ПодготовитьЗапросПоТоварам модуля менеджера отчёта ОстаткиТоваров есть запрос — прочитай его и прогони через validate_query»

> «Пройдись по менеджер-модулю отчёта Продажи — там несколько запросов в разных процедурах, проверь каждый, покажи ошибки с номерами строк»

> «Проверь запрос из набора данных НаборПродаж в схеме компоновки отчёта АнализПродаж — это DCS, передай isDcs=true»

> «Напиши метод ПолучитьТоварыПоАртикулу(ПрефиксАртикула) с запросом к справочнику Товары и параметром отбора. Перед тем, как вставить в модуль менеджера, проверь запрос через validate_query»

Отладка:

> «Поставь точку останова в ПриСозданииНаСервере документа ЗаказКлиента и покажи значение Объект.Партнер, когда я открою документ»

> «Покажи все переменные в текущей точке останова»

> «Вычисли выражение Объект.Товары.Количество() в контексте отладки»

Сборка:

> «Обнови информационную базу из проекта»

> «Очисти кэш и пересобери проект — в валидации ложные ошибки»

Внешние обработки и отчёты:

> «Собери внешнюю обработку ПроверкаКурсов в файл D:/Обмен/ПроверкаКурсов.epf»

> «Выгрузи отчёт АнализПродаж в .erf — путь спросишь у меня»

### Архитектор — создание объектов, форм, отчётов

Создание объектов:

> «Создай справочник Товары с реквизитами Наименование (Строка 150), Артикул (Строка 25) и Цена (Число 15,2). Добавь табличную часть Характеристики с колонками Наименование и Значение. Создай форму элемента и установи её основной»

> «Создай документ ЗаказПоставщику с реквизитами Контрагент (СправочникСсылка.Контрагенты), Склад, Сумма и табличной частью Товары (Номенклатура, Количество, Цена, Сумма)»

> «Создай регистр накопления ОстаткиТоваров с измерениями Номенклатура и Склад, ресурсом Количество, регистратор — ПриходнаяНакладная»

Работа с формами:

> «Добавь на форму элемента справочника Товары группу "Основное" с полями Наименование и Артикул, и группу "Цены" с полем Цена»

> «Добавь кнопку "Рассчитать итоги" на форму документа ЗаказКлиента и создай для неё обработчик на сервере»

> «Подбери стандартную картинку для подсистемы Склад и установи её»

> «Добавь на форму таблицу динамического списка по регистру ОстаткиТоваров»

> «Положи на форму обработки поле HTML-документа ПревьюОтчёта во всю ширину»

> «В поле Характеристика показывай только характеристики выбранной в строке Номенклатуры» — настройка «Связей параметров выбора» (отбор по соседнему реквизиту строки, типичный случай — подчинённый справочник); работает и для поля формы, и для реквизита объекта/табличной части.

> «В поле Папка разреши выбирать только группы» — «Параметры выбора» (постоянный отбор фиксированным значением).

Макеты и печатные формы:

> «Создай документу Накладная макет печати с шапкой (номер, дата, контрагент), строками товаров и итогом по сумме»

> «Сделай отчёт продаж товаров по месяцам: слева список товаров, сверху Январь/Февраль/Март, в ячейках суммы, снизу итоги по каждому месяцу»

> «Добавь справочнику Контрагенты макет визитки и именованную область ДанныеКонтакта»

Типы данных и определяемые типы:

> «Добавь справочнику Контрагенты реквизит Фото типа ХранилищеЗначения»

> «Создай определяемый тип ПользовательСистемы из Справочник.Пользователи и Справочник.ВнешниеПользователи, и добавь его реквизитом документу Поручение»

> «Добавь в регистр накопления ТоварыНаСкладах реквизит Комментарий» — реквизиты теперь работают во всех 4 видах регистров

Планы видов характеристик:

> «Сделай у плана видов характеристик ДополнительныеРеквизиты тип значения — строка 150 и булево»

> «Поменяй тип реквизита Артикул справочника Товары на число 12,0 — не удаляй и не пересоздавай его»

> «Собери дополнительные значения характеристик: создай справочник ЗначенияСвойств, подчини его плану видов характеристик ДополнительныеРеквизиты и привяжи как дополнительные значения»

Планы счетов, планы обмена, XDTO:

> «Свяжи план счетов Хозрасчетный с планом видов характеристик ВидыСубконто и назначь счёту 41 «Товары» субконто Номенклатура» — план счетов заработает с аналитикой, движения можно заполнять по субконто

> «Наполни план обмена ОбменСФилиалами: Номенклатуру и Контрагентов с авторегистрацией, документ Заказ — без авторегистрации»

> «Собери XDTO-пакет ОбменДанными: пространство имён http://my/exchange, тип объекта Контрагент со свойствами Наименование (строка) и ИНН (строка)» — типы сразу работают через ФабрикуXDTO

Отчёты СКД:

> «Создай отчёт ПродажиПоКонтрагентам с группировкой по контрагентам и сортировкой по сумме»

> «Добавь в отчёт условное оформление: если сумма больше 100000, выделить строку жёлтым»

> «Добавь в отчёт отбор по периоду и контрагенту»

> «В отчёте ПродажиПоКонтрагентам переименуй набор данных и убери лишний отбор по складу, остальное не трогай» — точечная правка готовой схемы, без пересборки

> «Свяжи в отчёте набор Продажи с набором РеквизитыОрганизаций по полю Организация»

> «Сделай у отчёта второй вариант "Продажи по номенклатуре" — скопируй текущий и поменяй группировку на номенклатуру»

> «Вынеси в шапку отчёта быстрые настройки: период и отбор по организации»

Расширения:

> «Заимствуй документ ЗаказКлиента в расширение и добавь реквизит КодПроекта»

> «В моё расширение заимствуй документ ПоступлениеТоваров и допиши в его объектный модуль «После Обработки проведения» — создавай движения в регистр ДопДДС» — плагин сам включит нужную галочку в расширении, код заработает в предприятии без ручной правки в EDT

Подписки на события:

> «Подпиши проведение документов ЗаказКлиента и РеализацияТоваров на обработчик ОбщийМодульПодписок.ПриПроведенииЗаказа» — одна подписка на два документа, в общем модуле появится процедура-заглушка с правильными параметрами

> «Создай серверный общий модуль ВызовСервера с разрешённым вызовом с клиента» — модуль сразу с нужными галочками контекста исполнения

HTTP-сервисы:

> «Создай HTTP-сервис УправлениеПользователями с корневым URL users, шаблонами /list (GET ПолучитьСписок, POST Создать) и /users/{id} (GET Получить, DELETE Удалить)» — за один вызов появятся сервис, шаблоны, методы и заглушки обработчиков в модуле сервиса

> «Добавь в HTTP-сервис ИнтеграцияERP шаблон /orders/{id} с методами GET и PUT»

Права и подсистемы:

> «Создай роль ТолькоЧтениеСклад с правами Чтение и Просмотр на все складские справочники»

> «Включи документ ЗаказПоставщику в подсистему Закупки»

Тестирование — юнит-тесты и сценарии Vanessa:

> «Напиши юнит-тест на функцию РасчётСкидки из ОбщегоНазначенияСервер: скидка 10% от 1000 должна быть 100. Прогони и покажи результат» — код проверяется кодом, отчёт через пару секунд

> «Напиши сценарий Vanessa: открыть список Контрагентов, создать элемент с наименованием "Тест", записать и проверить, что он появился в списке. Прогони» — интерфейс проверяется как живым пользователем

> «Я добавил в Заказ функцию расчёта суммы со скидкой и кнопку "Пересчитать" на форме. Напиши юнит-тест на функцию и сценарий Vanessa на кнопку, прогони и то, и другое» — полный цикл: и логика, и интерфейс одним заданием. Подробнее — разделы «Юнит-тесты» и «Сценарное тестирование Vanessa»

## Профили и группы инструментов

### Профиль «Аналитик» — 13 инструментов

Профиль только для чтения. Для изучения и документирования конфигураций без внесения изменений.

#### Анализ метаданных (8 инструментов)

Инструмент | Описание
--- | ---
`show_edt_version` | Версия и сборка EDT, информация о JVM и ОС
`list_workspace_projects` | Список проектов в текущем workspace
`list_metadata_objects` | Каталог объектов метаданных с фильтрацией по типу и имени
`get_object_details` | Полная структура объекта: реквизиты, табличные части, формы, команды. Типы — с подробностями: длина строки (Строка(100), Строка(0) — неограниченная), разрядность и точность числа (Число(15,2)), состав даты, индексирование, состав составного типа; у плана видов характеристик — тип значения характеристик и дополнительные значения. Большие отчёты СКД — компактной картой с дозапросом деталей и чтением длинного запроса частями.
`get_config_properties` | Свойства конфигурации: версия, подсистемы, статистика объектов
`get_form_image` | Визуализация формы — PNG-картинка или полное JSON-дерево элементов (включая командные панели, позиции, картинки и представление кнопок). Пагинация для больших форм. По каждому динамическому списку показывает его имя, основную таблицу и текст запроса (длинный читается частями).
`get_platform_docs` | Синтаксис-помощник: API платформы, язык запросов, директивы, функции СКД
`get_object_help` | Встроенная справка объекта (HTML-документация по кнопке «?»)

`get_platform_docs` — полноценный синтаксис-помощник для ИИ. Покрывает тысячи топиков: все типы платформы (Запрос, ТаблицаЗначений, HTTPСоединение...) с методами, свойствами и конструкторами. Язык запросов, директивы компиляции, аннотации расширений, ~130 функций СКД. Поиск без учёта регистра, русские и английские имена, точечная нотация (`Запрос.Выполнить`).

#### Анализ кода (4 инструмента)

Инструмент | Описание
--- | ---
`list_modules` | Все BSL-модули проекта с типом, размером, количеством строк
`code_structure` | Карта модуля и методов (`outline`, в т.ч. переменные модуля), тело метода по имени (`readMethod`), модуль целиком или диапазон (`readModule`), поиск текста/regex внутри модуля с номерами строк (`find`) — через штатную модель 1С:EDT: точные сигнатуры, типы параметров, области
`ai_context` | Умный сборщик контекста — метаданные объекта, дерево формы с реквизитами и командами, код модуля, вызовы за один запрос
`diff_module` | Сравнение модуля с версией из git (summary / unified / methods)

`ai_context` — заменяет 5–7 отдельных вызовов. Принимает четыре вида цели: объект метаданных (`Catalog.Х`, `Document.Х`, регистры, ChartOf*, BusinessProcess, Task и др.), форма (`Catalog.Х.Form.ФормаСписка` — возвращает дерево элементов, реквизиты с типами, команды, обработчики), общий модуль или путь к .bsl-файлу. Три режима: `minimal` (быстрый обзор), `standard` (для большинства задач), `full` (максимум: код + вызовы + ссылки). Для больших форм поддерживается пагинация дерева. Типы реквизитов и измерений/ресурсов показываются с подробностями (длина строки, точность числа, состав даты, индексирование, составной тип; тип значения характеристик у плана видов характеристик); схема компоновки больших отчётов выводится компактно, детали дозапрашиваются. Лучший первый шаг при работе с незнакомым объектом или формой.

#### Поиск и навигация (1 инструмент)

Инструмент | Описание
--- | ---
`code_search` | Единая точка входа для всех задач поиска по коду 1С: шесть операций (`textSearch`, `objectReferences`, `methodReferences`, `resolveSymbol`, `callHierarchy`, `help`) под одним инструментом. Авто-определение области поиска по дереву проектов, защита от ложных совпадений по префиксу, пагинация. Подробнее — раздел «Поиск по коду».

### Профиль «Разработчик» — 22 инструмента

К 13 инструментам аналитика добавляются инструменты для редактирования кода, отладки, валидации и сборки.

#### Редактирование кода и отладка (2 инструмента)

Инструмент | Описание
--- | ---
`write_module_source` | Запись BSL-кода (6 режимов: replace, replaceLines, replaceMethod, append, insertBefore, insertAfter)
`launch_debugger` | Полноценная отладка 1С — 16 действий (запуск, breakpoints, пошаговое выполнение, переменные, evaluate)

`write_module_source` — по умолчанию работает в режиме симуляции (`dryRun=true`). Автоматический бэкап перед каждой записью, проверка базовой структуры BSL (парность `Процедура`/`КонецПроцедуры`, `Функция`/`КонецФункции`, `Если`/`КонецЕсли`), блокировка при удалении >50% строк. Замена диапазона строк требует ожидаемого текста первой строки (`expectedFirstLine`): если номера сдвинулись, правка отклоняется, а не портит соседний код. Для изменения метода надёжнее всего `replaceMethod` — адресуется по имени, не зависит от номеров строк.

Встроенная валидация EDT сразу в ответе записи. После успешной записи (не dry-run) `write_module_source` сам дожидается полной валидации EDT по записанному файлу и возвращает её результат в том же ответе, в поле `validation`: список ошибок с текстом/строкой/файлом, счётчики `errorCount`/`warningCount`, готовая подсказка «3 ошибок в записанном файле. Исправь их перед продолжением» или «0 ошибок — код корректен». AI-ассистенту не нужно отдельно звать `get_validation_errors` — ошибки уже в ответе. Цикл «записал → проверил → исправил → записал ещё раз» замыкается без обращения к пользователю и без дополнительного вызова инструмента. Попадают только ошибки по записанному файлу — посторонние старые ошибки демо-конфигурации не засоряют ответ. Для серии быстрых правок валидацию можно выключить параметром `validateAfterWrite=false` и позвать её вручную в конце.

#### Валидация (3 инструмента)

Инструмент | Описание
--- | ---
`get_validation_errors` | Ошибки и предупреждения EDT. По умолчанию показывает только файлы, изменённые в текущей сессии (режим `session`) — без посторонних старых ошибок. Умеет ждать «тишины» от асинхронного коммита маркеров и отдаёт полную инфо по каждой ошибке (текст, файл, строка, описание, автофикс).
`validate_query` | Проверка запросов 1С через настоящий парсер языка запросов — тот же, что в редакторе EDT. Ловит все синтаксические ошибки (опечатки в ключевых словах, лишние/пропущенные скобки, незакрытые литералы), типовые проверки языка и структурные ошибки СКД. Поддерживает обычные запросы и запросы СКД (`isDcs=true`).
`code_review` | Автоматическое код-ревью BSL по стандартам разработки 1С: магические числа, устаревшие методы, сложность кода, хардкод путей и адресов, code smells. Работает на бесплатном компоненте MCP:RSV Code Review (движок — open-source BSL Language Server, 1c-syntax). Ревью одного модуля или всего проекта. Подробно — раздел «Код-ревью BSL».

`get_validation_errors` — по умолчанию режим `scope=session` и `severity=ERROR`. Показывает только реальные ошибки и только в тех файлах, которые AI или вы сами трогали в текущей сессии EDT. Для полного скана проекта перед релизом — `scope=project`. Для одного объекта — `scope=object + objectName`. На крупных базах (ERP, УТ, БП) работает мгновенно — не тянет десятки тысяч старых маркеров. Жалоба «AI правит, в EDT крест, а инструмент возвращает 0» закрыта — инструмент надёжно дожидается, пока EDT доварит маркеры на свежезаписанный файл.

`validate_query` — запускает настоящий разбор текста запроса, как если бы вы открыли его в редакторе EDT. Подхватывает те же подчёркивания и сообщения. В ответе по каждой ошибке — уровень (ERROR / WARNING / INFO), текст на русском, точные координаты (строка, колонка, смещение и длина проблемного фрагмента) и код диагностики. Этого достаточно, чтобы AI сразу указал на проблемное слово и предложил исправление. Параметр `isDcs=true` переключает на парсер DCS — проверяются блоки `{ВЫБРАТЬ ...}` / `{ГДЕ ...}` и параметры виртуальных таблиц. Типичный сценарий: AI проверяет запрос перед `write_module_source`, исправляет и перепроверяет — в код попадает уже чистый запрос. Ограничение: не проверяет существование конкретных таблиц и полей в вашей конфигурации (это требует полного контекста проекта и в EDT есть только в редакторе запросов) — запланировано на будущие релизы.

Как вы запускаете проверку. Отдельной «автоматической» привязки к другим инструментам пока нет — вы просто просите AI-ассистента проверить запрос. Дальше AI сам решает, передавать ли готовый текст или сначала прочитать его из модуля/схемы СКД. Частые формулировки: «проверь запрос: …», «в процедуре N модуля M есть запрос — проверь его», «пройдись по менеджер-модулю отчёта X и проверь каждый запрос», «проверь запрос из схемы компоновки отчёта Y», «напиши метод выборки …, проверь запрос перед вставкой в модуль». Примеры — в разделе «Разработчик — код, валидация, отладка».

Можно поставить на автомат через настройки AI. Если не хочется каждый раз говорить «проверь запрос», пропишите в правилах своего AI-ассистента (в Claude Code — `CLAUDE.md` проекта, в Cursor — Rules for AI, в Windsurf — memories): «перед каждым `write_module_source`, если в коде есть строковый литерал с запросом (присваивание `Запрос.Текст = "…"` или аналогичное), сначала вызови `validate_query` на извлечённый текст; если есть ошибки — исправь и перепроверь, только потом записывай модуль». Сильные модели соблюдают такое правило стабильно.

Встроенная автоматика на уровне плагина — запланирована на будущий релиз. По аналогии с тем, как `write_module_source` уже сам возвращает ошибки EDT в поле `validation` ответа, плагин будет сам извлекать QL-литералы из записываемого BSL (и `queryText` из DCS-наборов данных) и возвращать проверку запросов в том же ответе — агенту не придётся помнить про отдельный вызов.

#### Сборка и управление (4 инструмента)

Инструмент | Описание
--- | ---
`sync_database` | Обновление информационной базы из проекта EDT
`rebuild_project` | Очистка кэша и пересборка проекта
`list_applications` | Список зарегистрированных информационных баз (нужен для отладчика)
`export_object` | Экспорт внешней обработки/отчёта в бинарный .epf/.erf файл

`export_object` — собирает проект внешней обработки или отчёта в готовый бинарный файл .epf / .erf, который можно сразу открыть в 1С. Платформа 1С и тип файла определяются автоматически, один вызов. (Проверено на Windows; на Linux и macOS должно работать — но прогона пока не было.)

### Профиль «Архитектор» — 25 инструментов

К 22 инструментам разработчика добавляются конструктор конфигурации, юнит-тесты YAxUnit и сценарное тестирование Vanessa.

#### Редактирование метаданных (1 инструмент, ~140 операций)

Инструмент | Описание
--- | ---
`edit_metadata` | Единый конструктор: создание объектов, реквизитов, форм, элементов, отчётов СКД, расширений

#### Юнит-тесты YAxUnit (1 инструмент)

Инструмент | Описание
--- | ---
`yaxunit_tests` | Прогон юнит-тестов YAxUnit (run / debug), автообновление информбазы, Markdown-отчёт, встроенная справка для AI по написанию тестов. Подробно — раздел «Юнит-тесты YAxUnit».

#### Сценарное тестирование Vanessa (1 инструмент)

Инструмент | Описание
--- | ---
`vanessa` | Сценарное UI-тестирование через Vanessa Automation: прогон `.feature`-сценариев (Gherkin), словарь шагов (`steps`), проверка синтаксиса до запуска (`checkSyntax`), автоустановка Vanessa и автообновление информбазы. Подробно — раздел «Сценарное тестирование Vanessa».

## Конструктор конфигурации — edit_metadata

Единый инструмент для создания и настройки объектов метаданных, форм, макетов печатных форм и отчётов. Содержит около 140 операций в 10 областях. Все изменения выполняются через нативные сервисы EDT — результат идентичен ручному созданию в конструкторе.

### Дерево операций

edit_metadata (~140 операций) │ ├── Объекты метаданных (18 операций) │ ├── createObject / removeObject — создание объекта (30+ типов) и удаление целиком │ ├── renameObject — переименование объекта/формы/реквизита/ТЧ как «Рефакторинг → Переименовать» (синоним, ссылки, файлы, заимствованные копии) │ ├── setObjectProperty — свойства объекта (подсказки при опечатках, проверка имени картинки) │ ├── setHelp — справочная информация объекта (кнопка «?»/F1) из markdown или текста │ ├── addObjectAttribute / removeObjectAttribute — реквизиты объекта (удаление с очисткой полей форм) │ ├── addPredefined / removePredefined — предопределённые элементы (группы/элементы справочников, счета планов счетов, виды характеристик и расчёта) и их удаление │ ├── addTabularSection / removeTabularSection — табличные части целиком │ ├── addTabularSectionAttribute / removeTabularSectionAttribute — колонки табличной части │ ├── setValueType — тип значения характеристик плана видов характеристик; тип реквизита, колонки ТЧ, измерения/ресурса регистра, значения константы (один или составной, с длиной/точностью/составом даты) │ ├── changeAttributeType — смена типа существующего реквизита без удаления, с сохранением порядка и ссылок │ ├── setBaseProject — привязка проекта внешних обработок/отчётов к базовой конфигурации │ └── createObjectCommand / removeCommand — объектные команды Catalog/Document/... с заглушкой ОбработкаКоманды │ ├── Специализированные объекты (19 операций) │ ├── addRegisterField / removeRegisterField — поля всех 4 видов регистров + признаки учёта и субконто плана счетов │ ├── addRecorder / removeRecorder — документы-регистраторы существующего регистра │ ├── addEnumValue — значения перечислений │ ├── addSubsystemContent / removeSubsystemContent — состав подсистем │ ├── setRoleRight — права ролей (русские и английские имена) │ ├── setDefinedTypeTypes — состав определяемого типа │ ├── addEventSubscriptionHandler — дописать процедуру-заглушку обработчика подписки на событие │ ├── addAccountExtDimensionType / removeAccountExtDimensionType — виды субконто предопределённому счёту плана счетов (оборотное субконто, лимит) │ ├── addExchangePlanContent / removeExchangePlanContent — состав плана обмена с авторегистрацией изменений (Allow/Deny) │ └── setXdtoNamespace, addXdtoObjectType, addXdtoValueType, addXdtoProperty, removeXdtoType, removeXdtoProperty — содержимое XDTO-пакета: пространство имён, типы объектов/значений и их свойства │ ├── Формы (26 операций) │ ├── createForm — создание (элемент, список, выбор, общая, запись регистра) │ ├── addFormAttribute / addFormAttributeColumn — реквизиты формы и колонки таблицы-реквизита │ ├── removeFormAttribute / removeFormAttributeColumn — удаление реквизита формы или одной колонки (с очисткой связанных элементов) │ ├── addDynamicListTable — таблица динамического списка из объекта или произвольного запроса; настройка как у отчёта (отбор, порядок, группировка, оформление, выбранные/вычисляемые поля, параметры), смена запроса/основной таблицы/ключей; колонки по пути Список.Поле или [Список, Поле] из просмотра формы; в расширении источники запроса заимствуются автоматически │ ├── addField, addGroup, addButton — элементы формы (addField с видом поля через fieldType — HTML-документ, картинка, календарь и др.; addButton со стандартной командой сразу с иконкой платформы) │ ├── addTable — таблица для ТЧ или реквизита-таблицы (колонки авто или вручную) │ ├── addDecoration, addRadioButton — декорации и переключатели │ ├── setProperty — свойства элементов формы пакетно (цвета, шрифты, картинки, размеры; проверка имени картинки) │ ├── listPictures — поиск среди 763 стандартных картинок │ ├── addEventHandler — обработчик события на форму или элемент (ПриОткрытии, ПриИзменении и т.д.) │ ├── addCommandHandler — обработчик кнопки + процедура-заглушка в Module.bsl │ ├── setupSettingsComposerOnForm — композитор настроек на форме (реквизит + таблицы UI + BSL-пример) │ ├── addFormConditionalAppearance / listFormConditionalAppearance / removeFormConditionalAppearance — условное оформление формы (подсветка строки, поля, колонки по условию) │ ├── removeFormCommand — удалить команду формы и её кнопки (чистка сирот и дублей) │ ├── addFormCommandInterfaceItem — ссылка на команду в навигационной панели/панели команд формы │ ├── removeFormCommandInterfaceItem — убрать ссылку │ └── setFormCommandInterfaceItemProperty — группа размещения, видимость, индекс пункта │ ├── Макеты печатных форм (8 операций) │ ├── addTemplate — создание макета (табличный, текстовый, СКД и др.) │ ├── setTemplateCell — содержимое ячейки (текст, шрифт, цвет, выравнивание) │ ├── mergeTemplateCells — объединение диапазонов ячеек │ ├── setTemplateArea — именованная область макета (для Макет.ПолучитьОбласть) │ ├── addTemplateDrawing / listTemplateDrawings / removeTemplateDrawing — рисунки в табличном макете (факсимиле, печати, вшитые картинки) │ └── drawTemplate — пакетное заполнение (ячейки, ширины, именованные области) │ ├── Расширения (6 операций) │ ├── createExtensionProject — создание проекта расширения с привязкой к базовой конфигурации │ ├── adoptObject — заимствовать один объект из базы (опц. рекурсивно с дочерними элементами) │ ├── adoptObjects — заимствовать несколько объектов явным списком одним вызовом │ ├── adoptChild — заимствовать дочерний элемент │ ├── adoptFormItem — заимствовать элемент формы │ └── adoptModule — включить участие модуля заимствованного объекта в расширении │ ├── Расширения в информационной базе (.cfe) (3 операции) │ ├── installExtension — подключить готовое расширение к базе (файл, ссылка или GitHub-релиз) │ ├── listExtensions — список расширений информационной базы │ └── uninstallExtension — удалить расширение из базы по имени │ ├── HTTP-сервисы (4 операции) │ ├── addUrlTemplate / removeUrlTemplate — URL-шаблоны внутри сервиса (пути вида /users/{id}, параметры в фигурных скобках) │ └── addHttpServiceMethod / removeHttpServiceMethod — HTTP-методы (GET/POST/PUT/DELETE/...) с автозаглушкой обработчика в модуле сервиса │ ├── Отчёты СКД (48 операций) │ ├── createReportSchema, repairReportSchema — создание схемы и восстановление при рассинхроне │ ├── addDataSet, setDataSetProperty, removeDataSet — наборы данных (запрос, объект, объединение) │ ├── addDataSetField, removeDataSetField — поля набора данных │ ├── addQueryField, removeQueryField, addQueryCondition — точечная правка запроса набора │ ├── addDataSetLink, setDataSetLinkProperty, removeDataSetLink — связи наборов данных │ ├── addSchemaParameter, setSchemaParameter, removeSchemaParameter, moveSchemaParameter — параметры схемы │ ├── addCalculatedField, setCalculatedField, removeCalculatedField — вычисляемые поля │ ├── addTotalField, setTotalField, removeTotalField — итоги (ресурсы) │ ├── addSettingsGroup/Table/Chart, removeSettingsItem — группировки, таблицы, диаграммы │ ├── addSettingsSelectedField, removeSettingsSelectedField, clearSettingsSelectedFields — выводимые поля │ ├── addSettingsFilter, addSettingsFilterGroup, removeSettingsFilter — отборы (с группами И/ИЛИ/НЕ) │ ├── addSettingsOrder, removeSettingsOrder — сортировки │ ├── addConditionalAppearance, setConditionalAppearance, removeConditionalAppearance, setDataSetFieldAppearance — оформление │ ├── addSettingsVariant, cloneSettingsVariant, setSettingsVariantProperty, removeSettingsVariant — варианты отчёта │ ├── setSettingsParameter, removeSettingsParameter, setOutputParameter — значения параметров и вывод │ └── setSettingsItemUserMode, addUserField — быстрые настройки в шапку, пользовательские поля │ ├── Общее (2 операции) │ ├── moveItem — перемещение элементов формы │ └── removeItem — удаление элементов формы │ └── Сервис (1 операция) └── syncExport — дождаться завершения всех запланированных записей проекта на диск

### Ключевые возможности

Картинки. Свойства `setObjectProperty` и `setProperty` принимают как стандартные картинки EDT (763 шт., поиск через `listPictures`), так и общие картинки конфигурации в формате `CommonPicture.ИмяКартинки`.

Пакетный режим. Большинство операций поддерживают создание нескольких элементов за один вызов. Справочник с 10 реквизитами, табличной частью и формой — за 3–4 вызова вместо 15. `createObject` умеет сразу создавать реквизиты и табличные части (с их колонками), так что полноценный справочник или документ собирается одним вызовом.

Идемпотентность конструктора метаданных. Добавление реквизитов, табличных частей, колонок, значений перечисления, полей регистра и прав роли с тем же именем повторно не создаёт дубль — возвращается `alreadyExists: true`, ничего не меняется. В пакетном режиме совпавшие имена попадают в `skipped`, новые — в `created`, агент получает полную картину. Это позволяет безопасно прерывать генерацию и продолжать — повторные вызовы после остановки не плодят одноимённых элементов в `.mdo`.

Режим предпросмотра. К любой операции конструктора метаданных можно добавить параметр `dryRun=true` — плагин выполнит её в транзакции и откатит. В ответе будет видно, что получилось бы (созданные реквизиты, формы, элементы), но в проекте ничего не меняется. Полезно для перепроверки сложных пакетных вызовов или когда неуверен в правильности типа. Не применяется только к операциям заимствования и удаления реквизитов/ТЧ — там плагин честно говорит, что режим предпросмотра невозможен.

Реквизиты по умолчанию. Тип реквизита можно не указывать — поставится Строка длиной 10, ровно как при нажатии кнопки «+ Реквизит» в EDT. Работает для всех объектов с реквизитами (справочники, документы, все 4 вида регистров, планы счетов, планы видов характеристик и расчёта, бизнес-процессы, задачи, планы обмена).

Типы данных. Принимаются русские и английские имена — `Строка`/`String`, `Число`/`Number`, `ХранилищеЗначения`/`ValueStorage`, `ДвоичныеДанные`, `УникальныйИдентификатор`, ссылочные (`CatalogRef.X`/`СправочникСсылка.X`), а также определяемые типы (`DefinedType.X`/`ОпределяемыйТип.X`).

Расширения. При добавлении реквизитов со ссылочными типами инструмент автоматически заимствует связанные объекты. При записи кода через `write_module_source` в модуль заимствованного объекта (объектный, менеджера, набора записей и т.д.) плагин автоматически включает участие этого модуля в расширении — ту самую галочку на вкладке «Расширение» в редакторе объекта в EDT. Без неё файл модуля на диске есть, но платформа при исполнении его игнорирует — получался тихий баг. Теперь не нужно лазить в EDT после каждой записи кода в заимствованный модуль. Если модуль нужно включить без записи кода (например, чтобы унаследовать базовое поведение as-is) — отдельная операция `adoptModule`.

Подписки на события. Подписка создаётся одним вызовом `createObject`: источник (один тип или массив), имя события (`ОбработкаПроведения` / `Posting`, `ПриЗаписи` / `OnWrite` и т.д.) и обработчик `ОбщийМодуль.Метод`. Сразу после создания в общий модуль автоматически дописывается процедура-заглушка с правильной сигнатурой — первым параметром идёт Источник, остальные берутся из описания события, в конце стоит `Экспорт`. Агенту остаётся написать только тело. Если общий модуль создали позже подписки или изменилось имя метода — отдельная операция `addEventSubscriptionHandler` допишет заглушку по готовой подписке.

Общие модули. У `createObject` общего модуля теперь есть параметры-флаги контекста исполнения: `server`, `serverCall`, `clientManagedApplication`, `clientOrdinaryApplication`, `externalConnection`, `privileged`, `global` и `returnValuesReuse` (с русскими алиасами «НеИспользовать» / «НаВремяВызова» / «НаВремяСеанса»). Агент явно указывает, какой модуль ему нужен — «серверный с вызовом с клиента», «клиент-серверный без экспортных вызовов» и т.д. — и получает модуль с правильными галочками сразу, без ручной правки в EDT.

Макеты печатных форм. Полный цикл сборки макета: создание объекта, рисование ячеек с оформлением, объединения, ширины колонок, именованные области (`Шапка`, `СтрокаТовара`, `Подвал`). `drawTemplate` делает всё одним пакетным вызовом — готовый макет, идентичный нарисованному вручную в EDT.

Отчёты СКД. Полный цикл: схема, наборы данных, параметры, ресурсы, группировки, таблицы, диаграммы, отборы, сортировки, условное оформление, варианты настроек. Минимальный отчёт — 6 вызовов. В справке есть готовый рабочий сценарий для матричных отчётов («товары × месяцы»). Схему можно не только собрать с нуля, но и править точечно — у каждого элемента есть «создать / изменить / удалить»: переименовать набор, поменять формулу итога, убрать лишний отбор, не пересобирая отчёт целиком.

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

Варианты отчёта. Вариант можно добавить, скопировать целиком под новым именем (со всеми группировками, отборами и оформлением), переименовать и удалить. Любую настройку можно адресовать конкретному варианту — многовариантные отчёты («Продажи по организациям» и «Продажи по номенклатуре») собираются полностью через MCP.

Быстрые настройки и точечная правка запроса. Любую настройку (отбор, сортировку, оформление, параметр) можно вынести в шапку отчёта быстрыми настройками или спрятать — пользователю не придётся лезть в «Изменить вариант…». А чтобы добавить в запрос набора одно поле или условие, больше не нужно передавать весь текст запроса заново — есть точечные операции, остальной запрос остаётся нетронутым.

Схема компоновки — не только для отчётов. Схему компоновки данных (с запросом, группировками, ресурсами, отборами) теперь можно создавать не только в отчётах, но и в обработках, справочниках, документах, планах счетов, бизнес-процессах, задачах и планах обмена — везде, где в 1С бывают макеты типа «Схема компоновки данных». Открывается типовой сценарий «обработка с настраиваемыми отборами»: AI собирает в обработке макет со схемой, форму с реквизитом-композитором и кнопкой «Сформировать» — пользователь в режиме предприятия задаёт отборы и группировки сам.

HTTP-сервисы. Полный цикл сборки сервиса из 1С: сам сервис с корневым URL, URL-шаблоны вида `/users/{id}`, HTTP-методы (GET, POST, PUT, DELETE, PATCH и другие). Можно собирать по частям («добавь шаблон, добавь метод»), а можно одним вызовом `createObject` — пустой сервис превращается в готовый REST-API со всеми шаблонами, методами и заглушками обработчиков за один проход. В модуле сервиса автоматически появляется процедура с правильной сигнатурой на каждый HTTP-метод и пометкой `Экспорт` — после обновления информбазы сервис уже отвечает (пустым ответом), тело обработчика дописывается обычной фразой агенту через `write_module_source`.

Композитор настроек на форме. Операция `setupSettingsComposerOnForm` одним вызовом добавляет на любую форму (обработки, отчёта, общей формы) реквизит типа КомпоновщикНастроек, UI-таблицы настроек (дерево группировок, отборы, сортировка, условное оформление — через параметр `standardItems`; алиас `full` = все четыре) и привязку ExtInfo формы. Работает как галочка «Настройки на форме» в мастере EDT, но доступно не только для отчётов. В ответе возвращается готовый BSL-пример для обработчика `ПриСозданииНаСервере` — с корректной инициализацией композитора из макета со схемой. Полный пошаговый сценарий — в справочнике через `help topic=composerWorkflow`.

Подсистемы и поиск объекта в меню. Типовой вопрос пользователя: «в каком разделе интерфейса найти этот документ/отчёт?». Один вызов `get_object_details` на объект даёт поле `subsystems` со всеми полными путями подсистем, в которых он числится. Агент сразу отвечает: «этот документ лежит в разделе Продажи → Документы». Для самой подсистемы `get_object_details` возвращает `content` (включённые объекты), `children` (вложенные подсистемы) и `parent` (путь к родителю). В имени принимается полный путь `Subsystem.A.Subsystem.B` на любую глубину. Бонусом: `createObject` с тем же форматом пути сразу создаёт новую подсистему как вложенную — раньше через плагин иерархию не собрать было.

Расширяемый справочник платформы. Встроенная документация EDT по некоторым темам только отсылает на 1С:ИТС без конкретики — например, параметры форматной строки `ЧН`, `ЧДЦ`, `ДФ`, `БИ` там не описаны. Плагин дополняет синтаксис-помощник собственным слоем справок: `get_platform_docs typeName=ФорматнаяСтрока` возвращает полный справочник параметров с типовыми кейсами, сверенный с официальным международным порталом 1С:Предприятие. А `setProperty` при установке свойств `format`/`editFormat` сразу возвращает маяк `formatHelp` с короткой подсказкой про самую частую ловушку (`ЧН` не указан — ноль скрывается; `ЧН=0` — ноль показывается как «0») и указателем на справочник. Механизм расширяемый — в будущем таким же способом можно дополнять и другие темы.

Динамические списки на форме. Список создаётся из справочника, документа, регистра или произвольного запроса — колонки подбираются автоматически из полей запроса или объекта-источника. Доступна полная настройка как у отчёта (отбор, порядок, группировка, условное оформление, выбранные и вычисляемые поля, параметры), смена запроса, основной таблицы, ключей и режимов работы, а также добавление, переименование и удаление колонок. Колонку можно добавить по пути в обоих видах — `Список.Поле` и ровно так, как путь показан в просмотре формы (`[Список, Поле]`); в ответе возвращаются фактические имена созданных колонок. Сам текст запроса списка виден в просмотре формы через `get_form_image` (длинный — читается частями). В расширении объекты-источники запроса заимствуются автоматически. Сценарий — `help topic=dynamicListSettings`.

Планы видов характеристик — тип значения и дополнительные значения. Операция `setValueType` задаёт «Тип значения характеристик» плана видов характеристик, а также тип реквизита, колонки табличной части, измерения или ресурса регистра и значение константы — один тип или составной, с уточнением длины строки, точности числа и состава даты. `changeAttributeType` меняет тип уже существующего реквизита без удаления и пересоздания — порядок и ссылки на реквизит сохраняются. Отдельно собирается механизм «дополнительных значений»: через `setObjectProperty` справочник делается подчинённым плану видов характеристик (свойство `owners`) и указывается как «Дополнительные значения характеристик» (свойство `characteristicExtValues`). Готовый сценарий «создать справочник значений → подчинить плану видов характеристик → привязать как дополнительные значения → включить в тип значения» — в справке через `help topic=characteristicExtValuesWorkflow`. В расширении ссылочные типы при установке заимствуются автоматически.

Виды поля формы. Раньше поле на форме всегда было обычным «полем ввода». Теперь можно задать конкретный вид: поле HTML-документа, текстового, табличного или форматированного документа, поле картинки, календарь, поле периода, индикатор, полосу регулирования, диаграмму, графическую и географическую схему и другие. Достаточно сказать «положи на форму поле HTML-документа» — вид задаётся при создании параметром `fieldType` или меняется у существующего поля свойством `view`. Особенно полезно поле HTML-документа: в нём отображается размеченный HTML и работает встроенный JavaScript — удобно для дашбордов и нестандартного интерфейса прямо на форме обработки. Плагин проверяет совместимость вида с типом реквизита (календарь — для даты, HTML-поле — для строки) и при несоответствии честно сообщает, какие виды доступны, а не оставляет форму в неожиданном состоянии.

Планы счетов с субконто. План счетов поддерживается вместе с субконто — аналитикой на счетах. Плагин связывает план счетов с планом видов характеристик, где описаны виды субконто (свойство `extDimensionTypes`), и назначает конкретному счёту или субсчёту его виды субконто — то, что в конфигураторе настраивается в табличной части «Виды субконто» счёта (операция `addAccountExtDimensionType`, можно пометить субконто оборотным). Благодаря этому документ проводится в хозрасчётный регистр и пишет движения со счетами дебета и кредита, суммой и аналитикой по субконто. Если чего-то не хватает (не задан план видов характеристик, нет такого счёта или вида субконто, превышен лимит) — плагин сразу честно сообщает, что сделать. Назначенные субконто и предопределённые счета видны и при чтении через `get_object_details`; настройки можно менять и удалять (`removeAccountExtDimensionType`, `removePredefined`).

Планы обмена с составом. План обмена наполняется составом одной серией команд: операция `addExchangePlanContent` указывает, какие справочники, документы и регистры участвуют в обмене, и задаёт каждому авторегистрацию изменений — `Allow` (изменения автоматически попадают в очередь на выгрузку узлам) или `Deny`. Объекты добавляются по одному или списком с разной авторегистрацией; повторное добавление обновляет авторегистрацию, обратная операция убирает объект из состава. План обмена помечается как распределённая ИБ (РИБ) свойством `distributedInfoBase`. После наполнения в нём можно заводить узлы и регистрировать изменения. Состав виден и при чтении через `get_object_details`.

XDTO-пакеты. XDTO-пакет создаётся и наполняется целиком через агента: пространство имён (`setXdtoNamespace`), типы объектов со свойствами (`addXdtoObjectType`) и типы значений на базе XSD (`addXdtoValueType`), а каждому типу объекта — свойства (`addXdtoProperty`) с типом-примитивом, ссылкой на другой тип пакета, кратностью (необязательное, список) и формой представления в XML (элемент, атрибут, текст). Раньше пакет можно было только создать пустым. Готовые типы сразу работают во встроенном языке через `ФабрикаXDTO` — по ним создаются объекты, заполняются свойства, сериализуются в XML и читаются обратно. Содержимое видно при чтении и меняется симметрично (`removeXdtoType`, `removeXdtoProperty`).

### Встроенная справка

У инструмента есть собственный справочник, который ИИ-ассистент запрашивает при необходимости:

- `help` — список всех операций
- `help topic=<операция>` — подробная справка с примерами
- `help topic=types` — каталог типов данных для реквизитов
- `help topic=objectTypes` — типы объектов, которые можно создать
- `help topic=formTypes` — типы форм
- `help topic=workflow` — типичный сценарий работы от создания объекта до обработчиков
- `help topic=matrixWorkflow` — рабочий сценарий для матричных отчётов (товары × месяцы)
- `help topic=composerWorkflow` — обработка или отчёт с композитором настроек на форме: отборы, группировки, BSL-код инициализации
- `help topic=dynamicListSettings` — настройка динамического списка на форме: запрос, отбор, порядок, оформление, выбранные поля
- `help topic=characteristicExtValuesWorkflow` — план видов характеристик с дополнительными значениями: подчинённый справочник, тип значения, привязка

ИИ-ассистенту не нужно знать внутреннее устройство EDT — он спрашивает у инструмента, что доступно, и получает готовые примеры.

## Поиск по коду — code_search

Единая точка входа для всех задач поиска по коду 1С. `code_search` объединяет семь операций под одним инструментом — от текстового поиска до семантической навигации по вызовам и поиска по схемам компоновки данных — и заменяет несколько разрозненных инструментов с разной семантикой ответа. Слабая модель ИИ выбирает операцию по чёткому списку, не путаясь между похожими инструментами, и получает структурированный ответ в едином формате. Работает в проектах конфигурации, расширений и DT-проектах внешних обработок и отчётов — и одинаково быстро на тяжелейших конфигурациях масштаба ERP.

### Возможности

Семь операций под одним вызовом:

Операция | Что делает
--- | ---
`textSearch` | Полнотекстовый поиск по BSL-коду. Поддерживает wildcards `*` и `?`, точные совпадения по слову (без ложных срабатываний на префиксе).
`objectReferences` | Все ссылки на объект метаданных с учётом всех форм обращения: `Справочники.X`, `СправочникСсылка.X`, `СправочникМенеджер.X`, `СправочникОбъект.X` и аналогично для документов, регистров, перечислений.
`methodReferences` | Все ссылки на конкретный метод модуля. Точечнее, чем `objectReferences` — ищет именно вызовы метода, не упоминания.
`resolveSymbol` | Переход к определению метода (как F12 в редакторе кода). Возвращает путь к модулю, сигнатуру с параметрами и значениями по умолчанию, исходный код метода целиком, doc-комментарий.
`callHierarchy` | Кто вызывает метод (`incoming`) или кого вызывает он сам (`outgoing`), с рекурсивным обходом до 3 уровней вглубь. Строится настоящим графом EDT (как Ctrl+Alt+H) — только реальные, подтверждённые моделью кода ссылки, включая вызовы из схем компоновки и запросов динамических списков. Формат `chains` отдаёт цепочки вызовов плоским списком («ОбработкаПроведения → ЗаписатьДвижения → Записать») — читается сразу, без разбора дерева. Полезно перед изменением метода — оценить, что сломается.
`dcsSearch` | Поиск по схемам компоновки данных объекта: тексты запросов наборов, поля, параметры, вычисляемые поля, варианты отчёта с отборами и оформлением, связи наборов. Каждое совпадение с точным адресом — какая схема, область, узел, а для текста запроса ещё и номер строки. На отчёте ERP с запросом в сотни строк — доли секунды.
`help` | Встроенная справка: `topic=workflow` — путеводитель «какая операция подходит для моего сценария», `topic=<имя_операции>` — детальное описание с примерами.

Авто-определение области поиска. Если не указан проект — плагин сам выбирает разумную область на основе модели зависимостей 1С:EDT: для объекта основной конфигурации ищет в самой конфе и во всех её расширениях / внешних обработках; для объекта расширения или внешней обработки — в проекте-владельце и его «сёстрах» по родительской конфе. Это решает классическую проблему «ИИ-агент ищет не там, где нужно». Например, общий модуль одного расширения вызывается из соседнего расширения — без авто-определения области эту ссылку легко пропустить.

Защита от ложных совпадений. При поиске ссылок на объект учитываются границы слова: `InformationRegister.КурсыВалют` не путается с `КурсыВалютРасчетовПоДоговорам` или `КурсыВалютЦБ`, даже если они есть в той же конфигурации.

Понимание контекста. При анализе вызовов метода (`callHierarchy outgoing`) инструмент отделяет реальные вызовы от ключевых слов BSL (`Если`, `Возврат`, `Тогда`) и слов в строках-комментариях. Простые присваивания вида `Менеджер = Документы.Заказ;` и последующие `Менеджер.Метод()` распознаются — у вызова появляются поля `viaVariable`, `targetObject` (FQN объекта `Document.Заказ`), `resolvedTarget`.

Контролируемый размер ответа. Пагинация во всех операциях, возвращающих коллекцию (`limit` 1–500, `offset`), и режим `compact=true` для экономии контекста. Даже на 350 000 совпадений в большой типовой конфигурации инструмент по умолчанию возвращает первые 20 и подсказывает «есть ещё страницы, сужай запрос». ИИ-агент не «захлёбывается» в данных.

### Результаты тестов

Инструмент проверен на 12 сценариях в условиях, максимально близких к реальной работе 1С-программиста: типовая «1С:Комплексная автоматизация» 2.5 (~10 758 объектов метаданных) + 5 расширений + 1 внешняя обработка. Все тесты выполнял ИИ-агент, который не знает заранее структуру проекта — действует как программист, увидевший задачу впервые.

Для каждого теста замерялось время работы инструмента и размер ответа в токенах — это важно потому, что у ИИ-агентов есть лимит контекста (обычно от 128 000 до 1 000 000 токенов на всю задачу). Чем меньше ответ — тем больше места остаётся под собственно работу.

Сводная таблица всех 12 тестов:

Тест | Что искали | Время | Размер ответа
--- | --- | --- | ---
A1 | Определение метода БСП (`resolveSymbol` на `ОбщегоНазначения.СообщитьПользователю`) | 0,014 с | ~1 800 токенов
A2 | Все ссылки на справочник Контрагенты (837 совпадений в 362 файлах, вернулись первые 20) | 28,4 с | ~2 700 токенов
A3 | Конкретный редкий идентификатор `ИмяЛистаДляДаты` (2 совпадения) | 6,0 с | ~370 токенов
B1 | Кто вызывает метод (между расширениями — соседние extension попали в scope автоматически) | 6,0 с | ~830 токенов
B2 | Что вызывает метод (отсев комментариев, ключевых слов, параметров) | 0,004 с | ~630 токенов
B3 | Дерево вызовов рекурсивно на 3 уровня вглубь | 0,018 с | ~1 170 токенов
C1 | Защита от ложных совпадений по префиксу (`КурсыВалют` ≠ `КурсыВалютРасчетов`) | 6,6 с | ~2 900 токенов
C2 | Очень частое слово `Возврат` (352 189 совпадений в 14 377 файлах — вернулись первые 20) | 25,7 с | ~1 800 токенов
C3 | Поиск по шаблону `GoogleSheets*` (wildcards) | 0,020 с | ~430 токенов
C4 | Внешняя обработка как объект поиска (правильный нулевой результат) | 5,7 с | ~270 токенов
D | Полная архитектура механизма «Длительные операции» БСП за 3 вызова | ~12 с | ~9 200 токенов

Совокупно за 12 тестов: ~85 секунд работы инструмента и ~22 100 токенов в контексте ИИ-агента. Это 17 % от стандартного бюджета в 128 000 токенов — то есть ИИ-агенту остаётся 83 % контекста на собственно решение задачи программиста.

#### Подробнее по каждому тесту

A1 — определение метода БСП. Один вызов `resolveSymbol` на `ОбщегоНазначения.СообщитьПользователю`. На выходе: путь к модулю, полная сигнатура с параметрами и значениями по умолчанию, исходный код метода целиком, doc-комментарий с примерами использования, признак экспортного метода. Программист одним вызовом получает всё, что нужно для понимания метода — не нужно открывать модуль вручную и искать процедуру глазами.

A2 — все ссылки на справочник Контрагенты. Поиск без указания проекта — инструмент сам определил область. Найдено 837 совпадений в 362 файлах, в ответ ушли первые 20 в виде «проект:файл:строка: текст», 13 разных шаблонов поиска (`Catalog.Контрагенты`, `Справочники.Контрагенты`, `СправочникСсылка.Контрагенты`, `СправочникМенеджер.Контрагенты` и т. д.), топ-5 файлов по числу упоминаний и признак «есть ещё страницы». В большой конфигурации легко тысяча упоминаний одного объекта — инструмент не «свалил» контекст агента, а отдал по делу.

A3 — конкретный редкий идентификатор. Программист помнит имя `ИмяЛистаДляДаты`, но не помнит где. Один вызов `textSearch` — два точных совпадения: определение функции в одном расширении и одно её использование в том же модуле. Идеальный случай — программист получил ровно то, что искал, без лишнего шума.

B1 — кто вызывает мой метод (между расширениями). Прежде чем менять метод `СопоставитьСтроку` в общем модуле своего расширения, программист хочет понять, кто его вызывает — может, в другом расширении на него тоже завязан код. Метод определён в расширении `ДопДДС`, а вызывают его 5 тестовых процедур в другом расширении — `Тест2`. Инструмент сам это понял и поискал в обоих расширениях, потому что они «соседи» по дереву зависимостей. Если бы инструмент искал только в одном расширении, программист подумал бы «никто метод не вызывает, можно безопасно менять» — и сломал бы тесты, не заметив этого.

B2 — что вызывает мой метод. Тот же метод, направление `outgoing`. На выходе — 11 реальных вызовов (`Структура`, `ПустаяСсылка`, `ВРег`, `СокрЛП`, `НайтиКандидатовВНаименовании`, `ПолучитьОсновноеНаправлениеДеятельности` и т. д.). При этом инструмент не принял за вызовы: ключевые слова `Если` / `Возврат` / `Тогда`, слова из строк-комментариев и параметры самой функции. Чистый список реальных зависимостей — на нём можно строить картину «что сломается, если это поменять».

B3 — раскрой все вызовы вглубь на 3 уровня. Тот же метод, `depth=3`. На выходе — дерево вызовов: уровень 1 — `ПолучитьОсновноеНаправлениеДеятельности`; уровень 2 (что вызывает он) — `НайтиПоНаименованию`, `ЗначениеЗаполнено`, `СоздатьНаправлениеДеятельности`; уровень 3 (что вызывает `СоздатьНаправлениеДеятельности`) — `СоздатьЭлемент`, `СокрЛП`, `Записать`. Повторяющиеся вызовы помечены `recursive=true`, чтобы не разворачивать одно и то же дважды. Видна вся «глубина» — от верхнего метода до низкоуровневых операций с объектом — за 18 миллисекунд.

C1 — защита от ложных срабатываний по префиксу. Программист ищет ссылки на регистр сведений `КурсыВалют`, но в конфигурации есть похожие `КурсыВалютРасчетовПоДоговорам`, `КурсыВалютЦБ`. Инструмент вернул 24 совпадения — все до одного точно `КурсыВалют`, без похожих имён. Серьёзная проблема обычного текстового поиска (через `grep` сюда попали бы все имена, начинающиеся с этих букв) здесь решена — `code_search` понимает границы слова.

C2 — поиск служебного слова в большой конфигурации. Поиск слова `Возврат` — это служебное слово BSL, его очень много. Найдено 352 189 совпадений в 14 377 файлах. Инструмент не пытается отдать программисту 352 тысячи строк — это «убило» бы контекст агента. Вместо этого вернулись первые 20 совпадений + общая статистика + топ-5 файлов с наибольшим числом совпадений (например, в `ДокументооборотСКонтролирующимиОрганами/ObjectModule.bsl` — 3 623 совпадения) + признак `hasMore=true`. Программист видит цифры и понимает «я ищу слишком общее, надо сузить».

C3 — поиск по шаблону (wildcards). Поиск всего, что начинается с `GoogleSheets`. Два совпадения: `ДопДДС_ИнтеграцияGoogleSheets.ЗаписатьСопоставленияИДанные` и `ДопДДС_ИнтеграцияGoogleSheets.СоздатьНаправлениеДеятельности`. Wildcards работают как ожидается: `*` — любая последовательность символов, `?` — один символ.

C4 — внешняя обработка как объект поиска. Поиск ссылок на внешнюю обработку `БюджетДДС`. Ноль совпадений — и это правильный результат: внешние обработки используются как самостоятельные файлы и в коде конфигурации на них напрямую не ссылаются. Инструмент это корректно показал, не выдав ошибку и не накопав ложных совпадений. Граничный случай отработан правильно.

D — полное понимание механизма «Длительные операции» БСП. Самая сложная задача: программист только что услышал про механизм длительных операций в БСП и хочет понять — а как это работает в коде моей конфигурации? Какие методы вызывать? Какой шаблон использования? Три вызова: (1) `objectReferences` на `CommonModule.ДлительныеОперации` — узнать, какие методы этого модуля вызываются и где (~6 с, ~2 600 токенов; сразу виден список ключевых методов `ВыполнитьВФоне`, `ВыполнитьФункцию`, `ЗаданиеВыполнено`, `ОтменитьВыполнениеЗадания` и топ-5 модулей, чаще всего использующих этот механизм); (2) `resolveSymbol` на главную серверную функцию `ДлительныеОперации.ВыполнитьВФоне` — её исходный код целиком (175 строк) и полный комментарий с примером использования из 4 шагов: как объявить экспортную процедуру, как запустить на сервере, как подключить обработчик ожидания на клиенте, как обработать результат (~5 мс, ~4 700 токенов); (3) `resolveSymbol` на парный клиентский метод `ДлительныеОперацииКлиент.ОжидатьЗавершение`, упомянутый в комментарии серверной функции — её код целиком (~2 мс, ~1 900 токенов). На выходе программист (или ИИ-агент за него) понимает: что главная функция запуска — `ВыполнитьВФоне`, какие у неё параметры, какой шаблон вызова, какая клиентская процедура её обрабатывает, какая структура у callback-уведомления о завершении, и имеет готовый пример из 4 шагов, который можно прямо скопировать. До появления `code_search` такая задача требовала десятка ручных переходов по коду или открытия документации БСП. Самый показательный сценарий ради которого инструмент создавался.

#### Главные выводы

1. Скорость предсказуемая. Точечные операции (определение метода, иерархия вызовов уже разобранного метода) работают за миллисекунды. Полнотекстовый поиск по большой конфигурации — единицы или десятки секунд, в пределах MCP-таймаута.
2. Размер ответа всегда контролируем. Даже на 352 000 совпадений инструмент по умолчанию возвращает 20 первых и сообщает, что есть ещё.
3. Семантический поиск без ложных совпадений. Поиск ссылок на объект учитывает все формы обращения и не путает похожие имена.
4. Понимание границ. Слова `Если`, `Возврат` — это не методы; слова в комментариях — не вызовы. На таких чистых данных ИИ-агент уверенно делает выводы.
5. Авто-определение области поиска. Если программист не указал, в каком проекте искать — инструмент сам выбирает разумную область: основная конфигурация и её зависимые расширения. Это решает классическую проблему «ИИ-агент ищет не там, где нужно».

## Отладка через ИИ-агента — launch_debugger

Инструмент `launch_debugger` позволяет ИИ-агенту отлаживать код 1С так же, как это делает разработчик в EDT:

- Точки останова — настоящие BSL breakpoints, видимые отладчику EDT. Поддержка условных точек останова
- Запуск отладки — клиент 1С запускается в режиме отладки одной командой
- Пошаговое выполнение — шаг через строку, вход в метод, выход из метода
- Чтение переменных — локальные переменные метода + все реквизиты формы (Объект, ЭтаФорма, Элементы)
- Вычисление выражений — любое BSL-выражение в контексте точки останова
- Стек вызовов — текущая строка, метод, цепочка вызовов
- Управление выполнением — продолжить, приостановить, завершить

### Все 16 действий

Группа | Действия | Описание
--- | --- | ---
Сессия | `launch`, `status`, `terminate` | Запуск отладки, статус сессий, завершение
Выполнение | `resume`, `stepOver`, `stepInto`, `stepReturn`, `suspend` | Пошаговое выполнение
Состояние | `getState`, `getVariables`, `getVariable`, `evaluate` | Стек вызовов, переменные, вычисление
Breakpoints | `listBreakpoints`, `addBreakpoint`, `removeBreakpoint`, `toggleBreakpoint` | Управление точками останова

### Примеры вычислений через evaluate

Выражение | Результат
--- | ---
`Объект.Партнер` | `"Дальстрой"` (СправочникСсылка.Партнеры)
`Объект.Товары.Количество()` | `"5"` (Число)
`1 + 2 + 3` | `"6"` (Число)
`"Привет" + " мир!"` | `"Привет мир!"` (Строка)
`Объект.Дата` | `"01.10.2022 12:00:00"` (Дата)

### Типичный сценарий

Попросите ассистента:

> «Поставь точку останова в ПриСозданииНаСервере документа ЗаказКлиента и покажи значение Объект.Партнер, когда я открою документ»

Агент поставит breakpoint, дождётся остановки, вычислит выражение и вернёт результат с типом.

## Внешние обработки и отчёты

Все инструменты плагина работают с проектами внешних обработок (.epf) и внешних отчётов (.erf) наравне с обычными конфигурациями и расширениями. Вы можете полностью создать внешнюю обработку в EDT с помощью ИИ-ассистента и получить готовый бинарный файл для открытия в 1С.

### Полная поддержка всех инструментов

Для проектов внешних обработок и отчётов доступно всё то же, что и для обычных конфигураций:

- Конструктор форм — создание форм, реквизитов, полей, кнопок, обработчиков событий
- Работа с кодом — чтение и запись BSL-модулей, проверка синтаксиса
- Анализ — структура объектов, список модулей, иерархия вызовов
- Контекст объекта (`ai_context`) — понимает имена как на английском (`ExternalDataProcessor.МояОбработка`), так и на русском (`ВнешняяОбработка.МояОбработка`)

### Экспорт в бинарный файл

Инструмент `export_object` собирает проект внешней обработки или отчёта в готовый бинарный файл .epf / .erf, который можно сразу открыть в 1С. ИИ-ассистент спросит у вас, куда сохранить файл, и выполнит экспорт одним вызовом. Платформа 1С и тип файла (по типу объекта) определяются автоматически — никаких настроек и ручных путей не требуется. Весь процесс занимает 1–2 секунды.

Пример промпта:

> «Собери мою внешнюю обработку `ПроверкаКурсов` в файл `D:/Отчёты/Передача/ПроверкаКурсов.epf`»

Проверено на Windows. На Linux и macOS должно работать — платформа 1С и шаги сборки кросс-платформенные — но прогона на этих системах пока не было; если пользуетесь — напишите, как себя ведёт.

## Юнит-тесты YAxUnit — полный цикл AI-разработки

С версии 4.0.0 ИИ-агент в 1С:EDT умеет не только писать код и менять метаданные, но и сам прогонять юнит-тесты, и сам разбираться с упавшими через отладчик. Цикл «правка кода → прогон тестов → пошаговая отладка → результат» теперь замыкается без человека: ни одного клика мышью между правкой и отчётом.

Доступно в профиле Архитектор. Один MCP-инструмент — `yaxunit_tests`.

### Простыми словами — что это такое

Юнит-тест — это маленькая процедура на BSL, которая запускает другую процедуру (например, расчёт скидки или формирование цены) с заранее известными входными данными и проверяет, что результат именно такой, какой ожидался. Если что-то поменялось в коде и расчёт стал неправильным — тест «падает» и сразу показывает, где проблема.

Это как блокнот рядом с калькулятором с записанными правильными ответами («2+2 должно быть 4», «скидка 10% от 1000 должна быть 100»). Только вместо того чтобы каждый раз сверять руками — за вас это делает программа: за пару секунд прогоняет сотни таких проверок и говорит, всё ли в порядке.

В 1С-сообществе для этого используется YAxUnit — бесплатный фреймворк юнит-тестов под лицензией Apache 2.0. Это де-факто стандарт. Подключается к вашей информационной базе как обычное расширение конфигурации (`.cfe`).

### Что в итоге получается — пример полного цикла

Допустим, у вас в общем модуле есть функция расчёта скидки, и в ней спрятан баг — забыли деление на 100, поэтому скидка 10% от 1000 даёт 10000 вместо 100. Вы попросили ИИ-агента написать тест и прогнать. Что произойдёт:

1. Агент сам напишет тестовый модуль с правильной структурой YAxUnit (общий модуль с процедурой `ИсполняемыеСценарии` и набором проверок).
2. Агент сам обновит конфигурацию информационной базы — вам не нужно нажимать «Обновить конфигурацию», диалог не появится.
3. Агент сам запустит 1С:Предприятие в специальном режиме «прогон тестов».
4. Агент сам прочитает отчёт и покажет вам результат: «3 теста прошли, 1 упал — ожидали 100, получили 10000».
5. Агент сам поставит точку останова на нужной строке, перезапустит 1С в режиме отладки, остановится в ней, покажет вам значения переменных, проверит правильную формулу, найдёт баг.
6. Агент сам поправит код, заново прогонит тесты, покажет: «все 4 прошли».

Между шагом 1 и шагом 6 — ни одного клика мышью с вашей стороны. Вы только дали задание словами и проверили итоговый отчёт.

### Что нужно установить (один раз)

Сам плагин MCP:RSV Server вы уже установили в EDT. Дополнительно нужно поставить расширение YAxUnit в ту информационную базу, где будут идти тесты.

1. Скачайте последний релиз с github.com/bia-technologies/yaxunit/releases — нужен файл вида `YAxUnit-25.12.cfe` (или новее).
2. Откройте 1С:Предприятие на нужной информационной базе.
3. Главное меню → Все функции → Стандартные → Управление расширениями конфигурации → Добавить → выберите скачанный `.cfe`-файл.
4. Снимите флаг «Безопасный режим» (расширению нужен полный доступ).
5. Перезагрузите информационную базу.

В EDT в Run Configuration вашего проекта (Run → Run Configurations → 1C:Enterprise) должна быть настроена связка с этой информационной базой — обычно она уже есть, иначе её достаточно создать стандартным мастером EDT один раз.

### Примеры запросов к ИИ-ассистенту

Написать первый тест и прогнать:

> «Создай в моём расширении общий модуль с одним простым тестом, проверяющим что 2+2=4. Прогони тест и покажи результат.»

Покрыть тестами существующую функцию:

> «У меня в общем модуле `ОбщегоНазначенияСервер` есть функция `РасчётСкидки`. Напиши на неё 3 теста: для скидки 10%, для скидки 50% и для случая когда сумма равна нулю. Прогони и покажи результаты.»

Разобраться с упавшим тестом через отладчик:

> «Прогони все мои тесты в режиме отладки. Если что-то упадёт — останови выполнение в момент падения, посмотри значения переменных и скажи мне, в чём причина.»

Прогнать только конкретный тест:

> «Прогони только тест `Тест_РасчётСкидкиДля10Процентов` из модуля `ПростыеТесты` и покажи результат.»

Циклическая работа над багом:

> «У меня тест `Тест_РасчётСкидки` падает. Найди причину через отладчик, исправь код, прогоняй тесты заново до тех пор, пока всё не станет зелёным.»

### Встроенная справка для ИИ — даже слабая модель справится

Не каждая модель ИИ хорошо знает синтаксис YAxUnit. Поэтому в инструмент встроена справка по 5 темам — ассистент может подгрузить её по запросу, не перегружая контекст:

Тема | Что внутри
--- | ---
`writing` | Как написать первый тест: общий модуль, точка входа `ИсполняемыеСценарии`, AAA-схема (Arrange/Act/Assert), минимальный шаблон
`assertions` | Каталог проверок `ЮТест.ОжидаетЧто(...)`: `Равно`, `НеРавно`, `Истина`, `Содержит`, `Имеет`, `ВыбрасываетИсключение` и др.
`setup` | Подключение расширения YAxUnit (`.cfe`) к информбазе пошагово
`events` | Setup/teardown: `ПередКаждымТестом`, `ПослеТестовогоНабора` и контексты
`advanced` | Указатели на публичную документацию YAxUnit для продвинутых тем (моки, стабы, проверки против информбазы, RPC-режим, Allure-отчёты)

На практике это значит: даже если ваш ИИ-агент «никогда не слышал про YAxUnit», он сам попросит у инструмента справку и напишет тест по правилам. Если тест случайно написан неправильно (например, забыли зарегистрировать процедуру в `ИсполняемыеСценарии`) и прогон вернёт «0 тестов» — в Markdown-отчёте сразу появится подсказка: «вызови `help=writing` для шаблона». Так ассистент не зависает в догадках, а сам себя направляет.

### Сколько времени занимает прогон

Один-два теста на простой функции — около 5–10 секунд (большую часть занимает старт самой 1С:Предприятия). Сам прогон тестов — миллисекунды. Если у вас уже сотни тестов — полный прогон обычно укладывается в минуту-две.

Если ассистент не дождался завершения за отведённое время — 1С не убивается, инструмент возвращает «Pending». Ассистент перезвонит позже и заберёт результат, когда тот появится. Никаких подвисших окон и потерянных прогонов.

### Что в итоге

Вместо ручного цикла «правка → открыть обработку YAxUnit в 1С → нажать «Запустить» → прочитать отчёт → переключиться в EDT → поставить точку останова → перезапустить базу → ...» вы делаете один запрос словами, и ассистент проходит весь цикл сам. Подходит для покрытия нового кода тестами, для рефакторинга со страховкой (тесты ловят регрессии), для быстрого поиска причины бага через отладчик.

Юнит-тесты — то, чем серьёзная разработка 1С отличается от «написал, проверил руками, забыл». С версии 4.0.0 эта практика наконец становится доступной автоматически, без рутины.

## Сценарное тестирование интерфейса — Vanessa Automation

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

Доступно в профиле Архитектор. Один MCP-инструмент — `vanessa`. Вместе с юнит-тестами YAxUnit он замыкает тестирование с двух сторон сразу.

### Простыми словами — что это такое

Vanessa Automation — это бесплатный инструмент для автоматического тестирования интерфейса 1С. Он умеет сам «кликать» в работающей программе: открыть нужную форму, нажать кнопку, заполнить поле, проверить, что в таблице появилась строка. То, что обычно тестировщик делает руками, Vanessa делает по заранее записанному сценарию — и так каждый раз одинаково, без усталости.

Самое удобное: сценарий пишется обычным текстом на русском, в формате Gherkin — пошагово, фразами «Дано… Когда… Тогда…». Не код, а почти человеческое описание того, что должен сделать пользователь:

> Дано Я подключаю клиента тестирования «Главный»
> Когда Я открываю форму списка справочника «Контрагенты»
> И Я нажимаю на кнопку «Создать»
> И Я заполняю поле «Наименование» значением «ООО Ромашка»
> И Я нажимаю на кнопку «Записать и закрыть»
> Тогда Я вижу в списке строку «ООО Ромашка»

Vanessa прочитает такой сценарий, повторит все шаги в настоящей 1С и скажет, на каком шаге что-то пошло не так. А главное — сценарий пишет сам ИИ-агент. Вы говорите словами, что проверить, агент составляет `.feature`-файл, а плагин его прогоняет.

### Что в итоге получается — пример полного цикла

Допустим, вы добавили в документ новый реквизит и кнопку на форме, и хотите убедиться, что пользователь сможет создать документ, заполнить поле и провести его. Вы попросили ИИ-агента написать сценарий и прогнать. Что произойдёт:

1. Агент сам составит `.feature`-сценарий из правильных шагов Vanessa (он сверяется со встроенным словарём шагов, чтобы не выдумывать формулировки).
2. Агент сам проверит сценарий на опечатки ещё до запуска 1С — это мгновенно и не тратит лицензии.
3. Агент сам обновит конфигурацию информационной базы — диалог «Обновить конфигурацию?» не появится.
4. Если Vanessa Automation ещё не установлена — плагин сам её скачает и поставит при первом запуске.
5. Агент сам поднимет 1С в режиме тестирования и прогонит сценарий — на экране формы будут реально открываться, кнопки нажиматься.
6. Агент сам прочитает отчёт и покажет результат: «сценарий пройден» или «упал на шаге «Я нажимаю кнопку Провести» — кнопка не найдена».

Между заданием словами и итоговым отчётом — ни одного клика мышью с вашей стороны.

### Что нужно (один раз)

Отдельно качать и устанавливать Vanessa Automation не нужно — плагин делает это сам при первом прогоне (скачивает последний релиз и ставит). Нужно только следующее:

- Настроенная конфигурация запуска. В EDT у проекта должна быть готовая конфигурация запуска 1С:Предприятия (меню Запустить → Конфигурации запусков → 1С:Предприятие). Через неё Vanessa и заходит в базу — точно так же, как при обычном запуске программы или прогоне юнит-тестов. Обычно она уже есть; если её нет, сначала создайте конфигурацию запуска — иначе прогон не состоится, и плагин вернёт понятную ошибку со списком доступных конфигураций.
- Пользователь и пароль для входа в эту базу задаются один раз прямо в конфигурации запуска — оттуда плагин их и берёт. Отдельно вводить логин при каждом прогоне не нужно.
- Лицензия 1С минимум на два сеанса. Каждый прогон Vanessa держит два — менеджер тестирования и клиент, который «нажимает кнопки». На учебной лицензии разработчика при открытой EDT слотов может не хватить — тогда инструмент честно скажет об этом (признак `licenseLimit`), и достаточно закрыть лишние сеансы 1С. Лицензия уровня ПРОФ/КОРП снимает ограничение.

### Почему открываются два окна 1С

Когда вы запускаете прогон, на экране появляются две сессии (два окна) 1С — так и должно быть. Каждая отвечает за своё:

- Первая сессия — «менеджер тестирования». В ней открывается специальная обработка Vanessa, которая всем дирижирует. Эта сессия заходит в базу сама, под пользователем из конфигурации запуска — окна входа с логином и паролем вы не увидите.
- Вторая сессия — «клиент тестирования». Её запускает обработка из первой сессии. Именно в этой второй сессии и происходит всё «живое»: открываются формы, нажимаются кнопки, заполняются поля — то есть реально выполняются шаги вашего теста.

Проще говоря: первая сессия — режиссёр, вторая — актёр, который выполняет сценарий на сцене.

> ⚠ При самом первом запуске — нажмите «Да» в окнах безопасности.
> Когда обработка Vanessa открывается в этой базе впервые, 1С показывает два окна «Предупреждение безопасности»:
> 1) «Открывается «Vanessa Automation single» из файла …, разрешить открывать данный файл?»
> 2) «Модуль «Vanessa Automation single» … выполняет подключение исполнимого бинарного файла «WScript.Shell» … разрешить подключать исполнимые бинарные файлы?»
> В обоих нужно вручную нажать «Да». Это разовое действие для конкретной базы и конфигурации запуска: после подтверждения при следующих прогонах в этой же базе эти окна больше не появятся.

### Что происходит за кулисами — пошагово

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

1. Агент пишет тест. ИИ-агент составляет текстовый `.feature`-файл (сценарий на русском) и кладёт его в каталог проекта. Это его зона ответственности: понять задачу, сказанную словами, и превратить её в правильные шаги Vanessa. Всё остальное ниже делает сам плагин.
2. Агент запускает прогон. Агент вызывает инструмент `vanessa` (операция `run`) и передаёт ему путь к этому файлу. С этого момента управление берёт на себя плагин.
3. Плагин выбирает, в какую базу заходить. Прогон идёт через конфигурацию запуска 1С вашего проекта — ту же, что и при обычном запуске программы.
   - Если конфигурация запуска одна — плагин берёт её автоматически, ничего указывать не надо.
   - Если их несколько — можно сразу сказать агенту, какую использовать («прогони на конфигурации Демо-база»), и агент передаст её название плагину.
   - Если название не задано, а выбор неоднозначен — плагин вернёт агенту список доступных конфигураций, чтобы выбрать нужную.
4. Плагин находит (или скачивает) Vanessa. Сама Vanessa — это один файл-обработка `vanessa-automation-single.epf`. Плагин ищет его в папке `~/.edt-rsv/vanessa/` (в профиле пользователя). Если файла там нет — плагин сам скачивает последний релиз с GitHub и кладёт его туда. Отдельно ставить ничего не нужно. (Что делать, если скачать автоматически не вышло, — см. блок ниже.)
5. Плагин запускает первую сессию 1С — «дирижёра». Он стартует 1С с особыми параметрами запуска, которые делают сразу две вещи: (1) при старте автоматически открывают ту самую обработку Vanessa — вручную её открывать не нужно; (2) передают ей путь к служебному файлу настроек прогона. Этот файл настроек плагин формирует сам: в нём путь к вашему `.feature`, режим прогона, куда писать отчёт и прочие параметры. Вам этот файл трогать не нужно.
6. Обработка запускает «проигрыватель сценариев». Открывшись, обработка Vanessa читает файл настроек, находит указанный в нём `.feature` и запускает свой внутренний механизм, который проигрывает сценарий шаг за шагом — примерно как медиаплеер проигрывает запись.
7. Поднимается вторая сессия — «актёр». На первом же шаге, который что-то делает в интерфейсе, Vanessa сама запускает вторую сессию 1С (клиент тестирования). Именно в ней реально открываются формы и нажимаются кнопки. Почему окон два — см. выше.
8. Формируется отчёт, и плагин его читает. Когда сценарий отработал, Vanessa записывает результат прогона в файл отчёта во временную рабочую папку, и обе сессии 1С закрываются сами. Плагин сам находит и читает этот отчёт и возвращает агенту понятный итог: пройдено или упало, а если упало — на каком именно шаге и почему. Искать файлы отчёта руками вам не нужно — агент сразу покажет результат словами.

Если прогон долгий, плагин не «зависает» в ожидании: он отдаёт агенту промежуточный ответ «идёт прогон», а агент чуть позже сам забирает готовый отчёт — 1С при этом не прерывается.

Кто за что отвечает:

Кто | За что отвечает
--- | ---
Вы | Сказать словами, что проверить и (если в базе есть пользователи) под каким логином. Один раз — настроить конфигурацию запуска и при первом прогоне нажать «Да» в окнах безопасности.
ИИ-агент | Написать `.feature`-сценарий из правильных шагов, запустить инструмент `vanessa`, показать вам итоговый отчёт.
Плагин | Выбрать конфигурацию запуска, скачать или найти Vanessa, сформировать файл настроек, поднять 1С, дождаться отчёта, прочитать его и вернуть агенту.
Vanessa | Открыться в первой сессии, проиграть сценарий, поднять вторую сессию, выполнить шаги в интерфейсе, записать отчёт.

Где какие файлы лежат:

Файл | Где | Кто его создаёт
--- | --- | ---
Сценарий `.feature` | Каталог вашего проекта (по умолчанию подкаталог `features`) | ИИ-агент (или вы)
Обработка `vanessa-automation-single.epf` | `~/.edt-rsv/vanessa/` (в профиле пользователя) | Плагин (скачивает с GitHub)
Файл настроек прогона | Временная рабочая папка | Плагин (перед запуском)
Отчёт о прогоне | Та же временная папка | Vanessa (плагин его читает и отдаёт агенту)

> ⚠ Если автоматически скачать Vanessa не удалось (нет интернета или закрыт доступ к GitHub) — плагин честно об этом сообщит. Тогда скачайте обработку вручную: откройте страницу последнего релиза VASingle на GitHub, скачайте ZIP-ассет `vanessa-automation-single.<версия>.zip` (внутри один файл обработки), распакуйте из него `vanessa-automation-single.epf` и положите его в папку `~/.edt-rsv/vanessa/` (создайте её, если её нет). При следующем прогоне плагин найдёт файл на месте и скачивать ничего не будет.

### Под каким пользователем заходит вторая сессия

Тут есть важная тонкость. Первая сессия заходит по пользователю из конфигурации запуска, а вот вторая сессия (где идут шаги) логинится по тому, что написано в самом тексте теста — в шаге подключения клиента. Логин из конфигурации запуска сюда не подставляется: так устроена сама Vanessa.

В файле сценария за это отвечает первая строка — шаг подключения клиента:

- Если в базе нет пользователей (или вход выполняется под пользователем операционной системы) — логин и пароль оставляют пустыми:

  > Дано Я подключаю TestClient «Главный» логин «» пароль «»

- Если база требует пользователя — логин и пароль пишут прямо в шаг:

  > Дано Я подключаю TestClient «Главный» логин «Администратор» пароль «»

### Где лежит файл сценария и как указать в нём логин

Тест — это обычный текстовый файл сценария на языке Gherkin с расширением `.feature`. Его пишет ИИ-агент (или вы сами) и кладёт в каталог проекта — по умолчанию в подкаталог `features`; при необходимости путь к файлу или каталогу можно задать параметром.

Раз это просто текст, нужный логин и пароль для второй сессии можно прописать тремя способами — выбирайте удобный:

- Отредактировать файл руками — открыть `.feature` и дописать в шаг подключения нужный логин и пароль.
- Просто сказать агенту, под каким логином и паролем прогнать тест — и агент сам впишет их в шаг подключения.
- Не знаете, какой пользователь нужен? Так и скажите — агент должен сам спросить, под каким пользователем 1С и с каким паролем прогонять, прежде чем запускать.

### Откуда агент берёт правильные шаги

У Vanessa — фиксированный словарь шагов: шаг, придуманный «своими словами», не сработает и завалит прогон. Чтобы агент не угадывал, у инструмента есть операция `steps` — встроенный словарь: поиск шага по словам, обзор категорий («окна», «таблицы», «поля»…) и список самых часто используемых шагов. Каждый шаг возвращается готовой строкой для вставки в сценарий. Словарь читается прямо из установленной Vanessa — без запуска 1С и без расхода лицензий.

А операция `checkSyntax` проверяет готовый `.feature`-файл ещё до прогона: каждый шаг сверяется со словарём, и если в шаге опечатка — инструмент сразу называет файл, строку и предлагает похожие настоящие шаги. Это экономит время и лицензии: незачем запускать два сеанса 1С, чтобы узнать про опечатку.

Готовить агенту примеры сценариев заранее не нужно. Всё, что нужно для написания теста, агент берёт из самого инструмента: операция `steps` даёт словарь шагов, а встроенная справка инструмента содержит готовый пример сценария и подсказки по типовым шагам (подключение клиента, открытие формы, нажатие кнопки). Поэтому даже агент, который никогда не видел ваших тестов, составит сценарий правильно. Если же вы хотите разобраться в языке Gherkin сами, на сайте Vanessa Automation есть подробная документация и примеры.

### Скриншот при падении сценария

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

По умолчанию снимки не делаются — обычный прогон ими не нагружается. Включить просто: скажите агенту «прогони со скриншотами», и он снимет экран, если какой-то шаг упадёт.

Но даже если вы заранее не попросили скриншот, вы про него не забудете: при падении плагин сам сообщает агенту, что это место можно переснять со снимком экрана. Агент в таком случае предложит вам это — и перезапустит тест со скриншотом только с вашего согласия, сам по себе повторный прогон затевать не будет.

В кадр попадает именно окно 1С в момент падения (а не весь рабочий стол с посторонними окнами). Готовый снимок прикладывается к результату прогона — агент откроет его и покажет либо опишет вам, что увидел.

> «Прогони сценарий проведения заказа. Если упадёт — сделай скриншот и покажи, что было на экране.»

### Примеры запросов к ИИ-ассистенту

Первый сценарий — создание элемента:

> «Напиши сценарий Vanessa: открыть список справочника Контрагенты, создать новый элемент с наименованием «Тест», записать и проверить, что он появился в списке. Прогони и покажи результат.»

Проверить новую кнопку на форме:

> «Я добавил на форму документа Заказ кнопку «Заполнить по остаткам». Напиши сценарий: открыть новый заказ, нажать эту кнопку, проверить что табличная часть Товары заполнилась. Прогони.»

Посмотреть прогон вживую:

> «Прогони сценарий медленно и не закрывай 1С после завершения — хочу своими глазами увидеть, как открываются формы и нажимаются кнопки.»

(для этого у инструмента есть параметры `keepOpen` — не закрывать 1С после прогона, и `stepDelaySeconds` — пауза между шагами.)

Проверить сценарий на ошибки до запуска:

> «Проверь все мои `.feature`-файлы на правильность шагов, не запуская 1С. Если где-то выдуманный шаг — покажи где и предложи правильный.»

### Связка с юнит-тестами — полная автоматизация тестирования

Юнит-тесты и сценарное тестирование — не альтернативы, а две половины одного целого. Они работают в связке: оба инструмента ходят в одну информационную базу, обновляют её перед прогоном единым механизмом (без диалогов) и используют общий цикл фонового ожидания. Один и тот же объект можно проверить с двух сторон:

| Юнит-тесты YAxUnit | Сценарные тесты Vanessa
--- | --- | ---
Что проверяет | Код изнутри — правильно ли считает функция | Интерфейс снаружи — открывается ли форма, работает ли кнопка
Угол зрения | Глазами программиста | Глазами пользователя
Как пишется | Процедуры на BSL | Текстовый сценарий на русском (Gherkin)
Инструмент | `yaxunit_tests` | `vanessa`

Пример связки одним заданием:

> «Я добавил в документ Заказ функцию расчёта итоговой суммы со скидкой и кнопку «Пересчитать» на форме. Напиши юнит-тест на саму функцию (скидка 10% от 1000 = 900) и сценарий Vanessa, который открывает заказ, заполняет товары, нажимает «Пересчитать» и проверяет сумму на форме. Прогони и то, и другое, покажи оба отчёта.»

Агент прогонит юнит-тест (проверит формулу) и сценарий Vanessa (проверит, что кнопка на форме реально пересчитывает) — и вернёт два отчёта. Так замыкается полный цикл разработки: правка → проверка кода → проверка интерфейса — без единого клика мышью.

### Что в итоге

Сценарное тестирование интерфейса долго оставалось уделом отдельных тестировщиков: нужно знать фреймворк, держать в голове словарь шагов, вручную поднимать сеансы тестирования. Теперь это делает ИИ-агент по заданию словами: сам пишет сценарий из правильных шагов, сам ставит Vanessa, сам поднимает 1С, сам читает отчёт. В паре с юнит-тестами вы получаете полную проверку и кода, и интерфейса — то, что раньше было доступно только командам с выделенным QA.

## Код-ревью BSL — автоматическая проверка качества кода

Юнит-тесты и Vanessa проверяют, что код работает правильно. Код-ревью проверяет другое — насколько код хорошо написан: нет ли магических чисел, устаревших методов, слишком сложных и запутанных процедур, хардкода путей и адресов. Это то, что обычно делает старший разработчик, вычитывая чужой код: «вот тут вынеси число в константу», «здесь метод слишком сложный, разбей на части», «этот метод устарел, используй новый».

В плагине это инструмент `code_review` (профиль Разработчик). Он работает на отдельном бесплатном компоненте MCP:RSV Code Review, который ставится в EDT один раз.

### Простыми словами — что это такое

Код-ревью — это автоматический «вычитыватель» кода. Он читает ваш BSL-модуль и выдаёт список замечаний по стандартам разработки 1С: где что можно улучшить, с указанием строки и понятным пояснением. Не ошибки, из-за которых код не запустится (это ловит обычная валидация EDT), а именно замечания к качеству — то, что делает код чище, понятнее и ближе к стандартам.

Например, на обычном общем модуле он может выдать:

> стр. 108 — Магические числа: создайте константу с понятным названием, присвойте ей значение «2» и используйте эту константу вместо магического числа.
> стр. 213 — Синтаксическая конструкция вида «Если…Тогда…ИначеЕсли…» должна содержать ветвь «Иначе».
> стр. 87 — Длина строки 124 превышает максимально допустимую 120.

Каждое замечание сразу на русском, с номером строки. В EDT по двойному клику открывается нужная строка модуля.

### Отдельный плагин, который ценен сам по себе

MCP:RSV Code Review — это самостоятельный бесплатный плагин для 1С:EDT. Его можно поставить отдельно, без основного платного плагина, и он будет работать сам по себе: правый клик по любому модулю или проекту → MCP:RSV → Проверить код — и вы получаете список замечаний прямо в EDT, без всякого ИИ-агента.

Правый клик в модуле → MCP:RSV → Проверить код. Замечания появляются в панели снизу.

Результаты выводятся в отдельную панель «MCP:RSV Code Review» со сводкой (сколько ошибок, предупреждений, информационных) и списком замечаний. Двойной клик по замечанию переходит к нужной строке кода.

Панель результатов: модуль, сводка по замечаниям и список с номерами строк. В шапке честно указан движок — BSL Language Server (1c-syntax).

То есть даже бесплатно, в одиночку, этот компонент полезен любому 1С-разработчику: проверить свой модуль на соответствие стандартам можно в пару кликов. А владельцы основного платного плагина MCP:RSV Server получают сверху то же самое через ИИ-агента — инструментом `code_review`: агент сам прогоняет ревью и сам разбирает замечания. Один и тот же компонент работает на две стороны: руками в EDT — для всех, через агента — для платных.

### На базе BSL Language Server (1c-syntax)

Сам анализатор кода — не наш. Это известный в 1С-сообществе open-source проект BSL Language Server команды 1c-syntax (Алексей Сосновый, Никита Федкин и контрибьюторы), под лицензией GNU LGPL-3.0. Мы его упаковываем и встраиваем в EDT, не изменяя сам движок. Тексты лицензий и атрибуция входят в дистрибутив компонента; ссылки на исходники движка указаны прямо в интерфейсе (в панели результатов и на странице настроек).

### Как установить компонент (один раз)

> ⚠ Компонент большой — около 100 МБ. Внутри лежит сам движок анализа со всеми зависимостями, поэтому установка идёт заметно дольше обычного плагина (может занять несколько минут). Это нормально. Зато ставится он один раз и надолго: в отличие от основного плагина MCP:RSV Server, который часто обновляется, компонент код-ревью обновлять каждый раз не нужно — он живёт сам по себе и при обновлениях основного плагина не перекачивается.

Установка — стандартным механизмом EDT «Установить новое ПО»:

1. Скачайте установочный ZIP (всегда актуальная версия по постоянной ссылке):
   ⬇ MCP-RSV-CodeReview.zip
2. В 1С:EDT откройте меню Справка → Установить новое ПО… (в английском интерфейсе — Help → Install New Software).
3. Нажмите Добавить… (Add) → Архив… (Archive) и выберите скачанный ZIP-файл.
4. Отметьте галочкой категорию MCP:RSV Code Review → Далее (Next) → примите условия лицензии → Готово (Finish).
5. Дождитесь окончания установки (она долгая из-за размера) и перезапустите EDT.

После перезапуска в контекстном меню любого BSL-модуля появится пункт MCP:RSV → Проверить код, а в настройках (Окно → Параметры → MCP:RSV → Код-ревью) — страница со списком проверок.

### Какие проверки выполняются и как их настроить

Набор диагностик настраивается галочками на странице Параметры → MCP:RSV → Код-ревью. По умолчанию включены проверки по стандартам разработки 1С (когнитивная и цикломатическая сложность, устаревшие методы, магические числа, общий модуль без программного интерфейса, хардкод путей и адресов и др.), а часть стилевых и контекстных проверок — выключена, чтобы не зашумлять отчёт. Эти же настройки действуют и на ИИ-агента: сняли галочку — агент через `code_review` эту проверку тоже не увидит. Настройка одна на оба способа.

Параметры → MCP:RSV → Код-ревью. Сверху — включённые по умолчанию проверки, снизу — выключенные (их можно включить галочкой). Изменения применяются сразу, без перезапуска EDT.

#### Почему часть галочек снята по умолчанию

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

- Стилевые и форматирование — превышение длины строки, отсутствие пробелов вокруг операторов, лишние пустые строки, точка с запятой, несколько операторов в одной строке, повторяющиеся литералы и т.п. Они встречаются массово даже в типовых конфигурациях 1С и обычно тонут в сотнях однотипных замечаний, не давая пользы при ревью через агента.
- Контекстные — например «неиспользуемая локальная переменная» или «передача параметров между клиентом и сервером». При ревью одного модуля движок не видит контекста всей конфигурации и может ошибаться: скажем, присваивание свойству формы `Модифицированность` он принимает за неиспользуемую переменную и предлагает её удалить, хотя это рабочий код. Чтобы агент не «исправлял» ложные замечания, такие проверки по умолчанию выключены.

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

### Как это работает через ИИ-агента

Если у вас установлен основной плагин MCP:RSV Server, код-ревью становится доступно и через ИИ-агента — инструментом `code_review`. Агент сам находит установленный компонент, прогоняет на нём анализ и разбирает замечания. Можно проверить один модуль или весь проект; в ответ агент получает структурированный список замечаний (файл, строка, важность, код диагностики, текст) и может сразу предложить исправления.

Проверить конкретный модуль:

> «Сделай код-ревью общего модуля `ОбщегоНазначенияСервер`. Покажи замечания и предложи, что исправить в первую очередь.»

Проверить и сразу поправить:

> «Прогони код-ревью модуля менеджера документа Заказ. Вынеси магические числа в константы, разбей слишком сложные методы и убери устаревшие вызовы — затем перепроверь.»

Ревью всего проекта:

> «Сделай код-ревью всего моего расширения и собери сводку: сколько замечаний, какие самые частые, с каких лучше начать.»

### Что в итоге

Код-ревью замыкает картину качества: юнит-тесты и Vanessa следят, чтобы код работал, а `code_review` — чтобы он был написан по стандартам 1С. Бесплатный компонент полезен сам по себе любому разработчику (проверка модуля в пару кликов прямо в EDT), а вместе с основным плагином та же проверка идёт через ИИ-агента, который не только покажет замечания, но и сам их исправит. Ставится компонент один раз и надолго — дальше работает в фоне.

Репозиторий компонента: github.com/prepod2003/mcp-rsv-codereview · движок: github.com/1c-syntax/bsl-language-server

## Рекомендации по работе с ИИ-ассистентом

### Выбор модели

Для серьёзной разработки 1С рекомендуются топовые модели: Claude Opus, Claude Sonnet. Они лучше понимают контекст 1С, следуют правилам и реже галлюцинируют.

При работе с бесплатными или средними моделями (Claude Haiku, GPT-4o-mini, Gemini Flash):

- Контролируйте процесс жёстче — модель чаще будет игнорировать правила
- Для чтения и анализа средние модели подходят, для записи кода — контроль обязателен

### Контроль галлюцинаций

Даже топовые модели могут «выдумывать» методы платформы 1С. Для минимизации:

1. Синтаксис-помощник — пусть ИИ проверяет сигнатуры через `get_platform_docs`
2. Примеры из проекта — ИИ должен искать аналогичный код в конфигурации (3–5 примеров)
3. Встроенная справка — `get_object_help` помогает понять бизнес-логику без домыслов
4. Проверка запросов — `validate_query` до вставки в код
5. Цикл валидации — после каждой записи кода: `get_validation_errors` → исправление → повторная проверка до 0 ошибок ERROR

### Планирование

Для сложных задач обязательно:

1. Попросите ИИ составить план реализации
2. Зафиксируйте план в `.ai/current-task.md`
3. Обновляйте статус после каждого шага
4. При новой сессии — ИИ сначала прочитает план и продолжит с нужного места

### Что контролировать

- Режим записи — `replaceMethod` для одного метода, а не `replace` для всего модуля
- dry-run — каждая запись начинается с `dryRun: true`
- Паттерны конфигурации — ИИ ищет примеры в проекте, а не генерирует «по памяти»
- Методы БСП — в типовых конфигурациях ИИ использует обёртки БСП, а не платформенные примитивы

### Автобэкап

Плагин автоматически создаёт резервную копию модуля перед каждой записью:

- Бэкапы хранятся в `~/.edt-rsv/backups/`
- Максимум 5 бэкапов на каждый модуль, старые удаляются автоматически
- Для восстановления: скопируйте `.bsl.bak` файл на место модуля или используйте его содержимое как `source` для `write_module_source`

## Технические характеристики

Параметр | Значение
--- | ---
Инструментов | 25 в 9 группах
Профилей | 3 (Аналитик, Разработчик, Архитектор)
Протокол | MCP Streamable HTTP (2025-11-25 / 2024-11-05)
Порт по умолчанию | 8770 (настраиваемый, 1024–65535)
Формат ответов | JSON (все инструменты)
ИИ-ассистенты | Claude Code, Cursor, Windsurf, Roo Code, Gemini CLI, Qwen Code
Совместимость | 1C:EDT 2025.2, Java 17
Установка | Справка → Установить новое ПО → Архив

MCP:RSV Server — самый функциональный MCP-сервер для работы ИИ-ассистентов с 1С:EDT