Описание инструментов MCP:RSV Server
MCP-сервер MCP:RSV Server предоставляет 25 инструментов для работы с 1С:EDT через AI-ассистента. Инструменты доступны в трёх профилях в зависимости от вашей роли. Все инструменты работают с любыми типами проектов: конфигурации, расширения, внешние обработки и внешние отчёты.
Профили определяют, какие инструменты видит AI-ассистент:
| Профиль | Назначение | Инструментов | Группы |
|---|---|---|---|
| Аналитик | Изучение конфигурации без внесения изменений | 13 | 3 группы (только чтение) |
| Разработчик | Повседневная разработка: анализ + запись кода + валидация + код-ревью + экспорт | 22 | 6 групп |
| Архитектор | Полный контроль: создание объектов, форм, отчётов СКД, юнит-тесты | 25 | 9 групп |
Каждый следующий профиль включает все инструменты предыдущего.
Профиль «Аналитик» — 13 инструментов
Профиль для изучения и документирования конфигураций 1С. Аналитик может исследовать структуру метаданных, читать код, искать зависимости, просматривать формы и справку — без возможности что-либо изменить.
Анализ метаданных (8 инструментов)
Группа для изучения структуры конфигурации: какие объекты есть, из чего они состоят, как выглядят формы, что написано в справке платформы.
Возвращает версию установленной 1C:EDT, номер сборки, дату, а также информацию о Java и операционной системе. Полезно для диагностики и проверки совместимости.
Возвращает список всех проектов, открытых в текущем рабочем пространстве EDT. Каждый проект содержит имя, путь на диске и признак — является ли он проектом 1С. Используйте этот инструмент первым, чтобы узнать точные имена проектов для передачи в другие инструменты.
Возвращает перечень объектов конфигурации с фильтрацией по типу и имени. Поддерживает около 39 типов объектов: справочники, документы, регистры (сведений, накопления, бухгалтерии, расчёта), планы счетов, планы видов характеристик, планы видов расчёта, бизнес-процессы, задачи, перечисления, обработки, отчёты, общие модули, подсистемы, роли и другие.
Для каждого объекта возвращается имя, синоним, количество реквизитов и форм. Поддерживается пагинация — для больших конфигураций всегда указывайте фильтр по типу или маску имени.
Возвращает полную структуру конкретного объекта: все реквизиты с типами данных, табличные части с колонками, список форм, команд и модулей. Для разных типов объектов возвращаются специфичные поля — например, у справочников видна иерархия и владельцы, у документов — тип нумерации, у регистров — измерения и ресурсы.
Подсистемы и поиск в меню. Для подсистемы в ответе поля content (FQN включённых объектов), children (полные пути вложенных подсистем) и parent (путь к родителю). Для любого объекта в ответе поле subsystems — массив полных путей подсистем, в которых он упомянут. Один вызов get_object_details Document.Заказ — и агент сразу отвечает пользователю: «этот документ в разделе Продажи → Документы». В параметре objectName принимается путь Subsystem.A.Subsystem.B.Subsystem.C на любую глубину вложенности.
Подробности типов. Тип реквизита показывается с деталями: длина строки (Строка(100), причём Строка(0) — неограниченная длина), разрядность и точность числа (Число(15,2)), состав даты (дата / время / дата и время), пометка индексирования и полный перечень вариантов составного типа. У плана видов характеристик в составе виден отдельный пункт «Тип значения характеристик» (characteristicValueType) и привязанный справочник дополнительных значений (characteristicExtValues). Помогает при разборе ошибок обновления базы — видно, у какого реквизита не задана длина строки и какой индексируется.
Параметры выбора. У реквизита ссылочного типа в составе видны «Параметры выбора» (choiceParameters — постоянный отбор фиксированным значением) и «Связи параметров выбора» (choiceParameterLinks — отбор, зависящий от другого реквизита строки, например подчинённый справочник по владельцу). Те же настройки задаются через edit_metadata, так что агент сначала читает уже настроенное, а потом аккуратно меняет.
Предопределённые элементы, субконто, состав обмена, XDTO. Чтение симметрично записи — агент видит, что уже настроено, а не только создаёт с нуля. Для плана счетов в ответе видны предопределённые счета и субсчета (predefined) с видом счёта и кодом, назначенные каждому счёту виды субконто (extDimensionTypes) и лимит субконто. Для плана обмена — состав (content): какие объекты входят в обмен и с какой авторегистрацией изменений, плюс признак распределённой ИБ (distributedInfoBase). Для XDTO-пакета — пространство имён, типы объектов с их свойствами (тип, кратность, форма представления в XML) и типы значений.
Секционирование схемы компоновки. Для отчётов и объектов с макетом схемы компоновки по умолчанию возвращается компактная карта (наборы данных, поля, длина запроса, варианты отчёта), а не всё полотно целиком. Детали дозапрашиваются точечно: dcsInclude — что развернуть, dcsDataSet — конкретный набор данных, dcsVariant — один вариант отчёта. Очень длинный запрос читается частями параметрами dcsQueryLimit / dcsQueryOffset — как длинный документ по страницам, без потери символов на стыках.
Возвращает общие свойства конфигурации: имя, версию, режим совместимости, список подсистем и статистику по количеству объектов каждого типа. Позволяет быстро понять, с какой конфигурацией вы работаете.
Показывает управляемую форму объекта в двух форматах:
- Картинка (PNG) — визуальное представление формы, как она выглядит в 1С.
- Структура (JSON) — полное дерево элементов формы: группы, поля, таблицы с колонками, кнопки, декорации, командные панели формы и таблиц, контекстные меню.
У каждой кнопки указывается связанная команда (стандартная команда платформы или пользовательская), локализованный заголовок, подсказка и установленная картинка. Удобно искать элементы по описанию пользователя — например, «кнопка отмены поиска» → узел с командой CancelSearch.
Расположение элементов: у каждого узла указан порядковый номер внутри родителя (position), направление раскладки группы (childrenGroup: вертикально/горизонтально), положение заголовка, представление кнопки, секция в командной панели. Агент может точно понять, что идёт за чем, и указать место для вставки нового элемента.
Пагинация для больших форм: параметры depth, subtree, maxElements позволяют получать форму частями. На формах типовых конфигураций с сотнями элементов можно сначала взять верхний уровень (depth=1), потом раскрыть нужную ветку (subtree=ПанельКоманд) — без перегрузки контекста.
Запрос динамического списка: по каждому динамическому списку формы структура показывает его имя, основную таблицу и текст запроса. Короткий запрос приходит целиком, очень длинный — читается частями, как длинный документ по страницам. Агент сначала читает действующий запрос списка, а потом аккуратно дорабатывает его (например, добавляет соединение и поле), ничего не теряя.
Полноценный синтаксис-помощник, доступный AI-ассистенту. Покрывает тысячи топиков:
- API платформы — все типы (Запрос, ТаблицаЗначений, HTTPСоединение и сотни других), их методы, свойства, конструкторы. Поддерживается точечная нотация: Запрос.Выполнить, HTTPСоединение.Получить.
- Встроенный язык — ключевые слова (Если, Для, Пока, Попытка), базовые типы (Число, Строка, Дата, Булево).
- Язык запросов — ВЫБРАТЬ, ИЗ, ГДЕ, СОЕДИНЕНИЕ, ОБЪЕДИНИТЬ, ИТОГИ, ВЫРАЗИТЬ, ПОДОБНО и все агрегатные функции.
- Директивы компиляции — &НаСервере, &НаКлиенте, &НаСервереБезКонтекста и другие.
- Аннотации расширений — &Вместо, &После, &Перед, &ИзменениеИКонтроль.
- Функции СКД — около 130 функций языка выражений системы компоновки данных.
- Справочник форматной строки (typeName=ФорматнаяСтрока) — overlay-статья плагина с параметрами ЧН, ЧДЦ, ДФ, БИ, Л и примерами. Восполняет пробел встроенной документации EDT (там справка по функции Формат отсылает на ИТС). Данные сверены с официальным международным порталом документации 1С:Предприятие.
Поиск работает без учёта регистра и понимает как русские, так и английские имена.
Читает справку, заложенную разработчиками конфигурации в объект метаданных. Это те самые HTML-страницы, которые открываются по кнопке «?» в пользовательском интерфейсе 1С. Дополнительно возвращает комментарий из описания объекта, синоним и список подсистем. Позволяет аналитику получить содержательное описание объекта без погружения в код.
Анализ кода (4 инструмента)
Группа для чтения и исследования BSL-кода: просмотр модулей, чтение методов, анализ цепочек вызовов, сравнение с предыдущими версиями.
Возвращает перечень всех BSL-модулей в проекте с указанием типа (модуль объекта, менеджера, формы, общий модуль), размера в байтах и количества строк. Поддерживает фильтрацию по типу модуля, объекту-владельцу и сортировку по размеру — удобно для поиска самых крупных модулей.
Единый инструмент чтения кода: заменяет отдельные инструменты карты методов, чтения метода и чтения модуля целиком. Работает через штатную модель 1С:EDT — возвращает точные сигнатуры с типами параметров, директивы компиляции, признак «Асинх» и принадлежность к областям, а не приблизительный текстовый разбор. Четыре операции:
- outline — карта модуля: все процедуры и функции с сигнатурами, типами параметров, признаком экспортности, номерами строк и областями (#Область), а также переменные модуля (Перем).
- readMethod — полный текст одной процедуры или функции по имени, с документирующим комментарием и описанием типов параметров. Большой метод можно читать фрагментом по номерам строк.
- readModule — исходный код модуля целиком или по диапазону строк.
- find — поиск текста или регулярного выражения внутри одного модуля: возвращает номера строк совпадений и метод, в котором они находятся. Незаменимо для больших модулей — нужное место находится без чтения всего модуля.
- help — встроенный путеводитель: какая операция подходит для задачи.
Типовой путь: сначала outline для обзора структуры, затем readMethod для нужного метода — без чтения лишних строк. В большом модуле: find находит строку по содержимому → readMethod или readModule показывает её с контекстом.
Единые номера строк. Номера строк во всех операциях чтения и в записи кода — абсолютные, в одном масштабе: номер из ответа одной операции подставляется в другую без пересчёта. Параметр withLineNumbers печатает номера прямо в тексте кода — удобно для последующей точечной правки.
Одним вызовом собирает всю релевантную информацию. Четыре вида цели анализа:
- Объект метаданных —
Catalog.Номенклатура,Document.Х, любой регистр, план видов характеристик, бизнес-процесс и т.д. Возвращает структуру, реквизиты, табличные части, модули, методы, иерархию вызовов, ссылки в коде. - Форма —
Catalog.Х.Form.ФормаСписка,Document.Х.Form.ФормаДокумента. Возвращает дерево элементов, реквизиты формы с типами, параметры, пользовательские и стандартные команды, обработчики событий, путь к модулю. Поддерживает пагинацию (formDepth,formSubtree,formMaxElements) для больших форм. - Общий модуль —
CommonModule.ХилиОбщийМодуль.Х. - Путь к .bsl-модулю — для случаев, когда нужен контекст конкретного файла.
Три режима глубины: minimal (метаданные + список модулей), standard (+ структура методов, по умолчанию), full (+ исходный код + иерархия вызовов + ссылки). Заменяет 5–7 последовательных вызовов отдельных инструментов. Оптимальный первый шаг перед работой с незнакомым объектом или формой.
Точный разбор кода и компактная схема компоновки. Карта методов в контексте строится по той же штатной модели 1С:EDT, что и code_structure — с типами параметров, директивами и областями, без приблизительного текстового разбора. На больших отчётах схема компоновки выводится компактной картой (наборы данных, количество полей, длина запроса, варианты) вместо полного полотна запросов — ответ не переполняет контекст даже у скромных моделей, а детали при необходимости дозапрашиваются через get_object_details.
Сравнивает текущее состояние BSL-модуля с предыдущей версией из системы контроля версий. Три режима:
- summary — сводка: какие методы добавлены, изменены, удалены.
- unified — полный diff в формате git.
- methods — построчный diff для каждого изменённого метода отдельно.
code_search объединяет полнотекстовый поиск, поиск ссылок на объект, поиск ссылок на метод, переход к определению, иерархию вызовов и встроенную справку. Перед каждым вызовом достаточно указать operation:
- textSearch — полнотекстовый поиск по BSL-коду с поддержкой wildcards (*, ?) и точных совпадений по слову.
- objectReferences — все ссылки на объект метаданных с учётом всех форм обращения: Справочники.X, СправочникСсылка.X, СправочникМенеджер.X и т.д. Без ложных совпадений по префиксу.
- methodReferences — все ссылки на конкретный метод модуля. Точечнее, чем objectReferences — ищет именно вызовы метода, не упоминания.
- resolveSymbol — переход к определению метода (как F12 в редакторе кода). Возвращает путь к модулю, сигнатуру с параметрами, исходный код, doc-комментарий.
- callHierarchy — кто вызывает метод (incoming) или кого вызывает он сам (outgoing), с рекурсивным обходом до 3 уровней вглубь.
- help — встроенная справка: topic=workflow — путеводитель «какая операция подходит для моего сценария», topic=<имя_операции> — детальное описание с примерами.
Авто-определение области поиска. Если не указан projectName — плагин сам выбирает разумный scope на основе модели зависимостей 1С:EDT: для объекта основной конфигурации ищет в самой конфе и во всех её расширениях / внешних обработках; для объекта расширения — в проекте-владельце и его «сёстрах» по родительской конфе. Решает проблему «AI-агент ищет не там, где нужно».
Контролируемый размер ответа. Пагинация во всех операциях (limit 1–500, offset) и режим compact=true. Даже на 350 000 совпадений в большой типовой конфигурации инструмент возвращает первые 20 + статистику + топ-5 файлов + признак «есть ещё».
Понимание контекста. При анализе callHierarchy outgoing отделяет реальные вызовы от ключевых слов BSL (Если, Возврат) и слов в строках-комментариях. Простые присваивания вида Менеджер = Документы.Заказ; и последующие Менеджер.Метод() распознаются — у вызова появляются viaVariable, targetObject, resolvedTarget.
Подробный разбор возможностей и результаты тестирования на типовой «1С:Комплексная автоматизация» 2.5 (12 сценариев, 22 100 токенов на весь набор) — в руководстве пользователя.
Профиль «Разработчик» — добавляет 9 инструментов
К 13 инструментам аналитика добавляются инструменты для редактирования кода, отладки, валидации, код-ревью, управления сборкой и экспорта внешних обработок. Всего у разработчика 22 инструмента.
Редактирование кода и отладка (2 инструмента)
Записывает BSL-код в модуль объекта метаданных. Поддерживает 6 режимов записи для разных задач:
| Режим | Назначение |
|---|---|
| replace | Замена всего модуля целиком (для пустых или очень маленьких модулей) |
| replaceLines | Замена диапазона строк (для точечных правок) |
| replaceMethod | Замена одного метода по имени (самый безопасный способ изменить метод) |
| append | Добавление кода в конец модуля |
| insertBefore | Вставка перед указанной строкой |
| insertAfter | Вставка после указанной строки |
Безопасность:
- По умолчанию работает в режиме симуляции (dryRun=true) — показывает, что изменится, без реальной записи.
- Автоматически создаёт резервную копию модуля перед записью.
- Блокирует запись, если удаляется более 50% строк модуля (защита от случайной потери кода).
- Проверяет базовую структуру BSL (парность Процедура / КонецПроцедуры, Функция / КонецФункции, Если / КонецЕсли) до записи — повреждённый код в файл не попадает.
- Привязка к содержимому строки. Замена диапазона строк (replaceLines) требует параметра expectedFirstLine — ожидаемого текста первой заменяемой строки; для вставки (insertBefore / insertAfter) то же делает expectedLine. Если номер строки устарел (выше по модулю что-то поменялось и нумерация сдвинулась) и фактическая строка не совпала с ожидаемой — правка отклоняется с понятным объяснением, а не выполняется вслепую. Это исключает «тихую» порчу соседнего кода. Для метода надёжнее всего replaceMethod — он адресуется по имени и не зависит от номеров строк.
Встроенная валидация EDT (автомат). После успешной записи (не dry-run) плагин сам дожидается полной валидации EDT по записанному файлу и возвращает её результат в том же ответе, в поле validation. AI-ассистенту не нужно отдельно звать get_validation_errors — в ответе записи уже лежат маркеры, разнесённые на три группы:
- errors — блокирующие ошибки: код не скомпилируется. Обязательно исправить.
- warnings — семантические предупреждения EDT. Сюда попадают вещи вроде Новый Строка;, обращения к несуществующим глобальным функциям, недопустимые конструкции. Часто реальная ошибка — агент смотрит по checkId и решает.
- codeStyle — рекомендации стиля: короткое имя переменной, метод вне #Область, использование не рекомендуемых методов. Исправлять необязательно.
Плюс счётчики errorCount / warningCount / codeStyleCount и подсказка hint с градацией: где обязательно править, где посмотреть и решить, где можно пропустить. Агент не «тупит» на кодстайле и перестаёт «тихо проскакивать» реальные семантические ошибки, которые EDT помечает мягким уровнем. Цикл «записал → проверил → исправил» замыкается без обращения к пользователю.
Важно: в поле validation попадают только маркеры по записанному файлу, а не весь проект. Посторонние старые ошибки демо-конфигурации не засоряют ответ. Для серии быстрых правок валидацию можно выключить параметром validateAfterWrite=false и позвать её вручную в конце через get_validation_errors.
Автоактивация модуля в расширении. При записи кода в модуль заимствованного объекта расширения (например, &После("ОбработкаПроведения") в модуль документа) плагин сам включает участие этого модуля в расширении — ту самую галочку на вкладке «Расширение» в редакторе объекта в EDT. Без этого получался «тихий баг»: файл модуля на диске, валидация зелёная, а в 1С:Предприятии код не срабатывает. Результат включения возвращается в поле moduleActivation. Для модулей основной конфигурации, модулей форм и native-модулей расширения активация не применяется — агенту возвращается notApplicable с пояснением, никаких изменений.
Полноценный отладчик с 16 действиями:
- Запуск и завершение — запуск клиента 1С в режиме отладки, завершение сессии.
- Пошаговое выполнение — шаг через строку, вход в метод, выход из метода.
- Точки останова — добавление, удаление, включение/отключение, условные точки останова.
- Инспекция — чтение переменных, стек вызовов, вычисление произвольных BSL-выражений.
Типичный сценарий: list_applications → launch → addBreakpoint → пользователь выполняет действие в 1С → getState → getVariables → stepOver → resume.
Валидация (3 инструмента)
Группа для работы с результатами проверок EDT: ошибки, предупреждения, автофиксы, проверка запросов, код-ревью BSL по стандартам разработки 1С.
Возвращает ошибки и предупреждения из EDT. Для каждой показывает текст на русском, файл, номер строки, начало и конец проблемного участка, тип проверки, есть ли автофикс (Quick Fix), готовую строку подавления // @skip-check … и подробное описание из каталога проверок. Поддерживает автоматическое применение официальных Quick Fix через отдельный режим.
Область выборки (параметр scope):
- session (по умолчанию) — показывает ошибки только в файлах, изменённых в текущей сессии EDT (через инструменты MCP или вручную в редакторе). AI видит ровно то, что сам наработал, и не отвлекается на тысячи старых ошибок демо-конфигурации.
- object — ошибки конкретного объекта метаданных (с objectName=FQN).
- project — все ошибки проекта (осознанный запрос для полного скана, например перед релизом).
- all — все ошибки всех открытых проектов workspace.
Дефолт severity = ERROR — возвращаются только реальные ошибки, предупреждения не засоряют ответ. Нужны — передавайте явно.
Надёжная синхронизация. Xtext-парсер коммитит маркеры асинхронно через внутренний ExecutorService, который не ловится стандартными ожиданиями сборки. Инструмент подписывается на события обновления маркеров через официальный API EDT и ждёт «тишины» в потоке — самый надёжный способ синхронизации. Плюс retry-цикл до 3 попыток сбора. Ситуация «AI записал модуль, в EDT появился красный крестик, а инструмент возвращает 0» закрыта.
На крупных конфигурациях (ERP, УТ, БП) первый вызов на свежеоткрытом проекте больше не зависает — в режиме session читаются только маркеры свежих файлов, выдача практически мгновенная даже при десятках тысяч маркеров в проекте.
Два канала маркеров. Одновременно читает Eclipse IMarker.PROBLEM (синтаксис Xtext, сборщики) и EDT-нативные маркеры через IMarkerManager (все проверки фреймворка checks: качество кода БСП, BSL, формы, метаданные). Дубликаты автоматически дедуплицируются.
Пропускает текст запроса через тот же механизм разбора языка запросов 1С, который работает внутри редактора EDT. Результат такой же, как если бы программист вставил этот запрос в модуль и открыл в редакторе — те же подчёркивания, те же сообщения об ошибках.
Что ловится:
- Все синтаксические ошибки — опечатки в ключевых словах (ВЫБРАТ, СГРУПИРОВАТЬ, УПОРЯДИЧИТЬ), недопустимые токены, незакрытые и лишние скобки, незакрытые строковые литералы, оборванные выражения (ПО Остатки.Товар = без правой части).
- Типовые проверки языка запросов — неверные имена псевдонимов (с точкой или пробелом), проблемы с агрегатными функциями, несогласованные ветки CASE ... КОГДА ... ТОГДА, ошибки в BETWEEN.
- Проверки для запросов СКД (при isDcs=true) — корректность блоков {ВЫБРАТЬ ...} и {ГДЕ ...}, несоответствие полей между основной выборкой и блоками настроек, неправильное использование параметров виртуальных таблиц.
Что в ответе. По каждой ошибке — уровень (ERROR / WARNING / INFO), текст на русском, номер строки и колонки, смещение от начала текста и длина проблемного фрагмента, код диагностики для программной идентификации. AI-ассистент сразу указывает на проблемное слово и предлагает исправление — без обращения к пользователю.
Поддержка обоих языков: обычные запросы 1С и запросы СКД через параметр isDcs=true. Разные парсеры — разный набор диагностик.
Типичный сценарий: AI-ассистент перед тем, как вставить запрос в модуль через write_module_source, проверяет его через validate_query, при необходимости исправляет и перепроверяет — в код попадает уже чистый запрос.
Как вы вызываете инструмент. Отдельного «автоматического» запуска сейчас нет — вы просите AI-ассистента проверить запрос, он вызывает validate_query. Типичные промпты:
- «Проверь запрос: ВЫБРАТЬ Т.Артикул ИЗ Справочник.Товары КАК Т» — AI сразу пропускает текст через инструмент.
- «В процедуре ПодготовитьЗапросПоТоварам в модуле менеджера отчёта ОстаткиТоваров есть запрос — проверь его» — AI читает метод, извлекает строку запроса, прогоняет проверку.
- «Пройдись по менеджер-модулю отчёта Продажи — там несколько запросов в разных процедурах, проверь каждый» — AI собирает структуру модуля и проверяет каждый литерал.
- «Проверь запрос из схемы компоновки отчёта ОстаткиТоваров» — AI читает текст из набора данных схемы и вызывает инструмент с параметром для запросов СКД.
- «Напиши метод выборки товаров с артикулом на "А", проверь запрос перед тем, как вставлять в модуль» — AI пишет, сам проверяет, исправляет, и только потом записывает.
Как поставить проверку «на автомат» через AI. Если не хотите каждый раз говорить «проверь запрос», добавьте в настройки своего AI-ассистента правило вида:
В Claude Code это пишется в CLAUDE.md проекта, в Cursor — в «Rules for AI», в Windsurf — в memories / правилах. Сильные модели (Claude Sonnet 4+, GPT-4o+ и аналоги) такое правило соблюдают стабильно. Слабые могут забывать — им надёжнее напомнить про проверку прямым промптом.
Полностью встроенная автоматика (по аналогии с тем, как write_module_source уже сам возвращает ошибки валидации EDT в поле validation ответа) запланирована на будущий релиз: плагин сам будет находить запросы в записываемом BSL и в наборах данных СКД, проверять их и возвращать результат в том же ответе — агенту не придётся помнить про отдельный вызов.
Чего инструмент пока не делает. Не проверяет существование конкретной таблицы (Справочник.Товары) или поля (Товары.Артикул) в вашей конфигурации — это требует полного контекста проекта и в EDT доступно только в редакторе запросов. Также пока не подключены стилистические проверки 1С-сообщества (соединение с подзапросом, отсутствие индекса у временной таблицы и т. п.). Оба слоя запланированы на следующие релизы.
Автоматическое код-ревью модуля или всего проекта: магические числа, устаревшие методы (Сообщить, ТекущаяДата), код вне области, общий модуль без программного интерфейса, лишняя директива компиляции, пустой блок кода, когнитивная и цикломатическая сложность, вложенный тернарный оператор, хардкод файловых путей и сетевых адресов и другие проверки. Это не ошибки компиляции (их ловит get_validation_errors), а замечания к качеству кода — то, что обычно отмечает старший разработчик при вычитке.
Работает на отдельном бесплатном компоненте. Анализ выполняет компонент MCP:RSV Code Review — самостоятельный плагин EDT, который ставится один раз (см. раздел руководства). Движок анализа — open-source BSL Language Server команды 1c-syntax (лицензия LGPL-3.0); мы его встраиваем, не модифицируя. Если компонент не установлен, инструмент честно сообщит об этом и даст ссылку на установку.
Область проверки. Один модуль по имени объекта (objectName вида CommonModule.X, Document.Y) с указанием типа модуля (moduleType: модуль объекта, менеджера, формы, команды…) или по пути (modulePath). Без указания модуля — ревью всего проекта. Параметр limit ограничивает число замечаний в ответе.
Что в ответе. Сводка (total, errors, warnings, info) и список замечаний: файл, номер строки, важность, код диагностики, текст на русском, ссылка на описание. AI-ассистент сразу видит, что и где улучшить, и может предложить или внести исправления.
Набор проверок настраивается галочками на странице Параметры → MCP:RSV → Код-ревью — те же настройки действуют и на ручное ревью в EDT, и на ответ агенту. Подробно с примерами и скриншотами — в руководстве пользователя.
Сборка и управление (4 инструмента)
Запускает обновление информационной базы 1С из проекта EDT. Поддерживает инкрементальное и полное обновление.
Удаляет скомпилированные файлы и кэш EDT, при необходимости запускает полную пересборку. Помогает при ложных ошибках валидации и устаревших данных.
Возвращает список зарегистрированных информационных баз для проекта с их идентификаторами, типами и состоянием обновления. Основное назначение — получить applicationId, который требуется для запуска отладчика и обновления базы.
Собирает проект внешней обработки или отчёта из EDT в готовый бинарный файл .epf / .erf, который можно сразу открыть в 1С. Один вызов — готовый файл за 1–2 секунды.
- Платформа 1С определяется автоматически по версии проекта
- Расширение файла выбирается автоматически: .epf для обработок, .erf для отчётов
- В редком сценарии, когда в одном проекте лежит несколько объектов (две обработки, или отчёт рядом с обработкой), параметр objectName указывает, какой именно собирать. Расширение автоматически подбирается по типу выбранного объекта. Если objectName не указан при нескольких объектах в проекте — плагин сразу возвращает ошибку со списком доступных имён, а не собирает произвольный первый объект.
- Проверено на Windows; на Linux и macOS должно работать — но прогона пока не было.
Профиль «Архитектор» — добавляет 3 инструмента (~140 операций)
К 22 инструментам разработчика добавляются конструктор конфигурации (создание объектов метаданных, форм, схем компоновки данных и расширений), инструмент для запуска юнит-тестов YAxUnit с автоматической отладкой и инструмент сценарного UI-тестирования Vanessa. Всего у архитектора 25 инструментов.
edit_metadata — Конструктор конфигурации
Единый инструмент для создания и настройки объектов метаданных, форм, макетов печатных форм и отчётов. Содержит около 140 операций, организованных в 10 областей. Все изменения выполняются через нативные сервисы EDT — после операций не нужно вручную перезагружать формы или обновлять дерево объектов.
Встроенная справка
У инструмента есть собственный справочник, который AI-ассистент запрашивает при необходимости:
help— список всех операций с кратким описаниемhelp topic=<операция>— подробная справка по конкретной операции с примерамиhelp topic=types— каталог типов данных для реквизитовhelp topic=objectTypes— список всех типов объектов, которые можно создатьhelp topic=formTypes— типы формhelp topic=propertyValues— форматы значений свойствhelp topic=workflow— типичный сценарий работы от создания объекта до обработчиковhelp topic=matrixWorkflow— рабочий сценарий для матричных отчётов (товары × месяцы)help topic=composerWorkflow— обработка или отчёт с композитором настроек на форме: отборы, группировки, BSL-код инициализацииhelp topic=dynamicListSettings— динамический список на форме: создание, настройка как отчёта, смена запроса и колонокhelp topic=characteristicExtValuesWorkflow— план видов характеристик с дополнительными значениями: подчинённый справочник, привязка, тип значения
AI-ассистенту не нужно знать внутреннее устройство EDT — он спрашивает у инструмента, что доступно, и получает готовые примеры.
Объекты метаданных (18 операций)
Создаёт любой объект метаданных со всеми свойствами по умолчанию (такими же, как при создании через мастер EDT). Поддерживаемые типы (более 30): справочники, документы, обработки, отчёты, перечисления, регистры (сведений, накопления, бухгалтерии, расчёта), планы счетов, планы видов характеристик и расчёта, бизнес-процессы, задачи, планы обмена, общие модули, общие формы, общие команды, подсистемы, роли, константы, параметры сеансов, регламентные задания, функциональные опции, определяемые типы, XDTO-пакеты, подписки на события и другие. При создании регистров можно сразу задать измерения, ресурсы и документы-регистраторы. Для справочников, документов, обработок и отчётов — сразу же реквизиты и табличные части с колонками (параметры attributes и tabularSections). Для общих модулей — флаги контекста исполнения (server, serverCall, clientManagedApplication, privileged, global, returnValuesReuse и др.) прямо в вызове: агент получает модуль с нужными галочками, без ручной правки в EDT. Для подписки на событие — источник (один тип или массив типов), имя события (ОбработкаПроведения / Posting, ПриЗаписи / OnWrite и т.д.) и обработчик ОбщийМодуль.Метод; сразу после создания в указанный общий модуль автоматически дописывается процедура-заглушка с правильной сигнатурой (первым параметром идёт Источник, остальные — по описанию события) и пометкой Экспорт — агенту остаётся только написать тело. Для подсистем поддерживается путь с родителем: Subsystem.Продажи.Subsystem.Документы создаёт «Документы» как вложенную подсистему внутри «Продажи», на любую глубину вложенности. Для HTTP-сервиса — корневой URL (rootURL) и сразу массив URL-шаблонов через urlTemplates, каждый шаблон со своими HTTP-методами и именами обработчиков: пустой сервис → готовый REST-API за один вызов, с процедурами-заглушками в модуле сервиса. Всё создаётся одним вызовом — справочник с пятью реквизитами не требует шести отдельных запросов. Обязательные параметры для специфичных типов проверяются на входе — например, функциональная опция не создастся без ссылки на константу-хранилище; подписка — без указания события, которое реально есть у всех указанных источников.
Изменение свойств объекта: иерархия, тип кода, длина кода, длина наименования (descriptionLength), проведение, формы по умолчанию, периодичность регистра, картинка подсистемы и т.д. Картинки принимаются в двух форматах: стандартные (CreateFolder) и общие картинки конфигурации (CommonPicture.МояКартинка). Поддерживает и ссылочные свойства: owners — сделать справочник подчинённым (например, плану видов характеристик), characteristicExtValues — привязать к плану видов характеристик справочник дополнительных значений характеристик, extDimensionTypes — связать план счетов с планом видов характеристик, где описаны виды субконто (вместе с maxExtDimensionCount — лимит видов субконто на счёт), distributedInfoBase — пометить план обмена как распределённую информационную базу (РИБ). Пакетный режим, русские и английские значения. При неизвестном имени свойства инструмент подсказывает самые близкие по написанию существующие свойства — защита от опечаток и созвучных имён.
Добавление реквизитов на объекты всех типов, у которых они вообще бывают: справочники, документы, обработки, отчёты, все 4 вида регистров, планы счетов, планы видов характеристик и расчёта, бизнес-процессы, задачи, планы обмена. Тип данных можно не указывать — по умолчанию ставится Строка длиной 10, как при нажатии кнопки «+ Реквизит» в EDT. Принимаются все примитивы (включая ХранилищеЗначения, ДвоичныеДанные, УникальныйИдентификатор, ТабличныйДокумент), ссылочные типы и определяемые типы (DefinedType.X / ОпределяемыйТип.X). Имена типов работают и по-русски, и по-английски. Пакетный режим. Идемпотентно: повторный вызов с тем же именем не создаёт дубль — возвращается alreadyExists: true и skipped: [...]. Если при повторе переданы другие свойства (длина, тип, заголовок), существующий реквизит не переписывается молча — в ответе появляется propertyMismatch с парами requested / existing и подсказкой, что для обновления свойств используется setObjectProperty. То же поведение у addTabularSection, addTabularSectionAttribute, addEnumValue, addRegisterField.
Создание табличной части сразу с колонками. Тип колонки опциональный — как в addObjectAttribute.
Добавление колонок в уже существующую табличную часть. Тот же унифицированный формат типов.
Задаёт тип значения у уже существующего элемента: тип значения характеристик плана видов характеристик, тип реквизита или колонки табличной части, измерения либо ресурса регистра, значения константы. Принимает один тип или составной (несколько типов сразу) с уточнением длины строки, разрядности и точности числа, состава даты. В расширении ссылочные типы (CatalogRef.X и подобные) заимствуются автоматически.
Меняет тип уже существующего реквизита без удаления и пересоздания — сохраняет его порядок в списке и все ссылки на него. Решает типичную задачу «поменяй тип реквизита Артикул на число» одним действием, без потери привязок на формах и в коде.
Удаление реквизита объекта. Работает как правый клик → «Удалить» в дереве объектов EDT плюс автоматически чистит связанные элементы форм: поля, которые ссылались на удалённый реквизит, убираются со всех форм объекта. После операции формы валидны, обновление конфигурации базы данных проходит без ошибок. Поддерживаются справочники, документы, планы видов характеристик, задачи, бизнес-процессы, планы обмена, регистры (для ресурсов и измерений регистра — отдельная операция removeRegisterField).
Удаление табличной части целиком вместе со всеми её реквизитами. Все таблицы на формах объекта, привязанные к этой ТЧ, удаляются со всеми колонками автоматически. Если нужно убрать только один реквизит, оставив ТЧ — используйте removeTabularSectionAttribute.
Удаление одного реквизита (колонки) табличной части. Саму ТЧ оставляет. Колонки таблиц на формах, ссылавшиеся на удалённый реквизит, убираются автоматически — сама таблица и остальные колонки остаются.
Удаление объекта метаданных целиком — со всеми реквизитами, табличными частями, формами, командами, макетами. Перед удалением плагин автоматически чистит входящие ссылки: при удалении регистра он снимается со всех документов, где был указан как регистратор; при удалении документа очищается список его регистров-движений; объект убирается из состава всех подсистем. По правилам безопасности эта операция требует явного подтверждения от пользователя — AI-ассистент не вызывает её самостоятельно «для порядка» и обязан перечислить, что именно будет удалено и какие ссылки разорвутся, прежде чем выполнять.
Создание объектной команды (Catalog/Document/... — кнопка «Добавить → Команда» в дереве объекта в EDT). Одной операцией: объект Command в дереве владельца + файл CommandModule.bsl со стандартной заглушкой Процедура ОбработкаКоманды(ПараметрКоманды, ПараметрыВыполненияКоманды) (русский ScriptVariant) или CommandProcessing(...) (английский) — тело пустое, заполняется через write_module_source. Принимает параметры команды: commandParameterType (FQN-строка или массив для составного типа), parameterUseMode (Single/Multiple), group (группа размещения), representation, picture, tooltip, modifiesData, shortcut. Имя картинки проверяется до записи: при опечатке плагин возвращает success=false с подсказкой о близких именах в реестре платформы. Дальше команду можно положить в командную панель или навигационную панель формы через addFormCommandInterfaceItem. Общая команда (CommonCommand) создаётся через createObject с тем же набором параметров.
Обратная операция к createObjectCommand: удаление команды объекта или общей команды (CommonCommand). Стирает CommandModule.bsl с диска и убирает ссылку из .mdo-файла владельца. Если команда размещена в командной панели или навигационной панели какой-то формы (через addFormCommandInterfaceItem) — перед удалением её нужно убрать из формы операцией removeFormCommandInterfaceItem, иначе ссылка в форме станет битой.
Переименование справочника, документа, формы, реквизита, табличной части и других элементов конфигурации — тем же механизмом, что «Рефакторинг → Переименовать» в EDT. Вместе с именем обновляются файлы и папки проекта, синоним (если он совпадал с именем), ссылки в других объектах, пути к данным на формах; заимствованные копии в расширениях переименовываются синхронно. Попытка сменить имя через setObjectProperty тоже выполняется как полноценное переименование — проект не расходится сам с собой.
Заполнение справочной информации объекта — той самой, что пользователь 1С:Предприятия открывает кнопкой «?» (F1) в формах справочника, документа, отчёта. AI описывает, как работать с объектом, обычным текстом или markdown, а плагин превращает это в страницу справки в фирменном стиле платформы: заголовки, списки, таблицы, ссылки, оглавление. Работает для всех прикладных объектов и для конфигурации в целом, поддерживает многоязычные конфигурации и включение раздела в общее содержание справки.
Создание предопределённых элементов: элементы и группы справочников, счета и субсчета планов счетов, виды характеристик, виды расчёта. Вся иерархия (группа с вложенными элементами, счёт с субсчетами) создаётся одним вызовом. Для счетов можно сразу задать вид (активный / пассивный / активно-пассивный) и признак забалансового. Повторный вызов ничего не дублирует.
Удаление предопределённого элемента — элемента или группы справочника, счёта плана счетов (вместе с его субсчетами), вида характеристик или расчёта. Обратная операция к addPredefined: создание, чтение и удаление предопределённых элементов работают симметрично, так что агент свободно правит уже настроенный объект, а не только создаёт с нуля.
Специализированные объекты (19 операций)
Добавление и удаление полей всех 4 видов регистров (сведений, накопления, бухгалтерии, расчёта): ресурсы, измерения, реквизиты. А также признаки учёта и признаки учёта субконто для плана счетов (тип по умолчанию — Булево, как в мастере EDT). Вид поля задаётся на русском или английском. Для реквизитов/ресурсов/измерений тип данных опциональный (по умолчанию Строка длиной 10).
Добавление значений в перечисление. Одиночный и пакетный режим.
Включение и исключение объектов из состава подсистемы. Идемпотентно.
Назначение прав роли на объект метаданных целиком или на его вложенный элемент: реквизит (Catalog.Клиенты.Attribute.Паспорт), табличную часть (Document.Заказ.TabularSection.Товары), колонку ТЧ (Document.Заказ.TabularSection.Товары.Attribute.Цена), команду объекта (Catalog.Товары.Command.ОткрытьОтчёт), измерение или ресурс регистра. Одним вызовом можно, например, закрыть отдельному реквизиту с персональными данными право просмотра для роли оператора, оставив доступ ко всему справочнику в целом. Набор допустимых прав для каждого типа цели платформа определяет сама. Русские и английские имена прав (Чтение/Read, Добавление/Insert и др.). Пакетный режим, идемпотентно.
Задаёт состав определяемого типа (ОпределяемыйТип) одним вызовом. Принимает массив FQN входящих типов: ["CatalogRef.Пользователи", "CatalogRef.ВнешниеПользователи"]. После этого определяемый тип можно указывать как тип реквизита через type: "DefinedType.X".
Дописывает процедуру-заглушку обработчика в общий модуль по уже существующей подписке. При создании подписки через createObject заглушка пишется автоматически, если общий модуль уже существует. Отдельный вызов нужен, когда модуль создали позже подписки, либо когда изменилось имя метода в обработчике и нужна свежая заглушка. Плагин сам берёт из подписки источник, событие и обработчик, вычисляет сигнатуру и пишет процедуру. Идемпотентно: если метод уже есть, возвращается handlerAlreadyExists: true и ничего не меняется. Параметр force: true перезаписывает существующий блок Процедура…КонецПроцедуры свежей заглушкой. Режим предпросмотра (dryRun: true) возвращает планируемую сигнатуру без записи.
Субконто на счетах плана счетов. Назначает предопределённому счёту (или субсчёту) вид субконто — то, что в EDT редактируется в табличной части «Виды субконто» счёта; обратная операция убирает его. Субконто можно пометить оборотным (turnover). После назначения по счёту в движениях документа заполняется аналитика (СубконтоДт/СубконтоКт), а в отчётах доступны итоги в разрезе субконто. Виды субконто берутся из плана видов характеристик, связанного с планом счетов через setObjectProperty extDimensionTypes; число субконто на счёт ограничено свойством maxExtDimensionCount. Если чего-то не хватает (не задан план видов характеристик, нет такого счёта или вида субконто, превышен лимит) — операция честно сообщает об этом и подсказывает, что сделать, а не оставляет счёт в половинном состоянии. Идемпотентно: повторное назначение того же вида субконто не дублируется.
Состав плана обмена. Наполняет состав плана обмена — указывает, какие справочники, документы и регистры участвуют в обмене, и задаёт каждому авторегистрацию изменений: Allow (изменения объекта автоматически попадают в очередь на выгрузку узлам) или Deny. Объекты добавляются по одному или списком: единый параметр content с общей авторегистрацией autoRecord, либо массив items с разной авторегистрацией по объектам. Повторное добавление того же объекта не дублирует строку, а обновляет его авторегистрацию; обратная операция убирает объект из состава (сам объект не удаляется). После наполнения в плане обмена можно заводить узлы и регистрировать изменения для обмена данными. Распределённая ИБ (РИБ) включается через setObjectProperty distributedInfoBase.
XDTO-пакеты: типы и свойства
XDTO-пакет создаётся через createObject XDTOPackage и наполняется целиком одной серией команд — раньше пакет можно было только создать пустым, а содержимое набивалось вручную в EDT. Типы сразу работают во встроенном языке через ФабрикаXDTO: по ним можно создавать объекты, заполнять свойства, сериализовать в XML и читать обратно — типовой сценарий обмена данными.
setXdtoNamespace — пространство имён пакета (URI).
addXdtoObjectType — тип объекта (структура со свойствами). Можно указать базовый тип-наследование.
addXdtoValueType — тип значения (простой тип на базе примитива XSD, аналог typedef с ограничениями).
addXdtoProperty — свойство типа объекта: тип-примитив XSD (строка, число, дата, булево…), ссылка на другой тип этого же пакета или явное пространство имён; кратность (lowerBound/upperBound — необязательное, список) и форма представления в XML (элемент, атрибут, текст).
removeXdtoType / removeXdtoProperty — удаление отдельного типа (с его свойствами) или свойства. Создание, чтение и изменение содержимого работают симметрично.
HTTP-сервисы (4 операции)
Добавление и удаление URL-шаблонов внутри HTTP-сервиса. Шаблон — это путь, по которому сервис принимает входящие запросы, например /users/{id}; параметры в фигурных скобках доступны обработчику через ПараметрыURL. Удаление шаблона забирает с собой все его HTTP-методы.
HTTP-методы внутри URL-шаблона: GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD и другие. При создании метода в модуль HTTP-сервиса автоматически дописывается процедура-заглушка обработчика с правильной сигнатурой и пометкой Экспорт — после обновления информбазы сервис уже отвечает (пустым ответом), тело обработчика дописывается через write_module_source.
Формы (26 операций)
Создаёт форму через встроенный генератор EDT. Все типы: форма элемента, списка, выбора, группы, записи регистра, общая. Параметр setAsDefault=true назначает форму основной.
Реквизиты формы (фильтры, временные таблицы, динамические списки). Колонки можно добавлять в существующие реквизиты-таблицы без пересоздания.
Удаление реквизита формы по имени. Параметр deleteDataItems переключает поведение: при true (по умолчанию) удаляется и сам реквизит, и связанные элементы формы — таблица с колонками и поля, которые на него ссылались; при false сами элементы остаются на форме с сохранёнными привязками к удалённому реквизиту. В ответе появляется поле preservedDataPaths со списком сохранённых ссылок (Table:ТаблицаСводка → /Сводка, FormField:Колонка1 → /Сводка/Колонка1 и т.д.) — полезно для типичного сценария «удалить реквизит и пересоздать его с другой структурой колонок» за два вызова, без необходимости пересоздавать таблицу и поля вручную.
Таблица динамического списка со всеми свойствами, которые появляются у таблицы списка в мастере EDT: строка поиска, автообновление, быстрый отбор над колонками, режим отображения «Список». Список создаётся из справочника, документа или регистра либо из произвольного запроса; колонки задаются вручную или подбираются автоматически по полям источника. Готовый список настраивается как отчёт — отбор, порядок, группировка, условное оформление, выбранные и вычисляемые поля, параметры; у него можно поменять запрос, основную таблицу, ключи и режимы работы, а также добавлять, переименовывать и удалять колонки. Путь колонки принимается и привычным Список.Поле, и ровно так, как он показан в просмотре формы — [Список, Поле]. В расширении все объекты, на которые опирается запрос списка (основная таблица и таблицы соединений), заимствуются автоматически. Типовой сценарий — в справке через help topic=dynamicListSettings.
Элементы формы
addField — поле на форме. По умолчанию вид определяется автоматически по типу реквизита (строка → поле ввода), но можно сразу задать конкретный вид параметром fieldType: поле HTML-документа (в нём отображается размеченный HTML и работает встроенный JavaScript — удобно для дашбордов и нестандартного интерфейса), текстового, табличного или форматированного документа, поле картинки, календарь, поле периода, индикатор, полосу регулирования, диаграмму, графическую и географическую схему и другие. Плагин проверяет, что выбранный вид совместим с типом реквизита (календарь — для даты, HTML-поле — для строки и т.д.); при несовместимости — ранний отказ со списком доступных видов, поле не создаётся.
addGroup — группа: обычная, страницы, страница, группа колонок, командная панель, группа кнопок
addButton — кнопка с пользовательской командой формы ИЛИ со стандартной командой платформы (PostAndClose, Write, Copy, SetDeletionMark, Generate и др.) — достаточно указать standardCommand, обработчик в модуле формы не нужен, поведение знает сама платформа. Для 22 самых частых стандартных команд (проведение, запись, копирование, перечитать, пометка на удаление, обновить, найти, справка, старт бизнес-процесса, сформировать отчёт и др.) иконка и режим «картинка + текст» проставляются автоматически — кнопка сразу выглядит как в типовых конфигурациях, без отдельного вызова. Поддерживаются параметры расположения (parent, position: top/bottom/индекс).
addTable — таблица для табличной части или реквизита-таблицы формы. Колонки подбираются автоматически из источника данных (как при drag-and-drop ТЧ на форму в EDT) или задаются явно. В автогенерации имена полей получают префикс имени ТЧ — ТоварыКоличество, УслугиКоличество — как делает мастер «Добавить форму» в EDT. Две табличные части с одноимёнными колонками на одной форме не создают коллизии имён.
addDecoration — надпись для заголовков и пояснений
addRadioButton — переключатель (точки или тумблер) с произвольными вариантами
Универсальная установка свойств любого элемента: видимость, доступность, заголовок, цвет, шрифт, картинка, представление, расположение заголовка, размеры, выравнивание, направление раскладки и десятки других. Свойством view можно сменить вид уже существующего поля — сделать его полем HTML-документа, картинки, календарём, индикатором и т.д. (тот же набор видов, что у fieldType при создании, с той же проверкой совместимости с типом реквизита). Пакетный режим: за один вызов можно установить сразу несколько свойств одного элемента. Для кнопок — защита от типичной ошибки «установил картинку, а её не видно»: если указывается только picture на кнопке с текстом и дефолтным режимом представления, операция возвращает предупреждение с подсказкой, какой representation задать. При установке format или editFormat (форматная строка для числовых, датовых и булевых полей) в ответе появляется поле formatHelp — короткая подсказка с типовой ловушкой (параметр ЧН не указан — ноль скрывается; ЧН=0 — ноль показывается как «0») и указатель на справочник get_platform_docs typeName=ФорматнаяСтрока.
Поиск среди 763 стандартных картинок EDT по имени. Для общих картинок конфигурации (из раздела «Общие → Общие картинки») поиск не нужен — используйте формат CommonPicture.ИмяКартинки напрямую в setProperty или setObjectProperty.
Создаёт обработчик команды кнопки с правильной директивой. Поддерживает обычные формы и заимствованные (обработчики Перед, После, Вместо).
Назначает обработчик события на форму или элемент формы — ПриОткрытии, ПриСозданииНаСервере, ПриИзменении, ОбработкаВыбора и десятки других. Имя процедуры-обработчика подставляется автоматически по правилам платформы (например, ИмяПоляПриИзменении) либо задаётся явно. Если процедуры-обработчика ещё нет в модуле формы — в неё автоматически дописывается заглушка с правильной сигнатурой по описанию события и нужной директивой компиляции (&НаКлиенте, &НаСервере). Агент после назначения сразу получает рабочий каркас, в который остаётся вписать тело.
Добавляет ссылку на существующую команду в командный интерфейс формы — в навигационную панель (горизонтальная линейка ссылок под заголовком формы, выше штатной командной панели) или в панель команд формы (кнопки команд рядом с автокомандной панелью). Принимает FQN команды любого вида: объектная (Catalog.X.Command.Y / Document.X.Command.Y), общая (CommonCommand.Y), стандартная команда формы (Form.StandardCommand.Refresh). Параметр group задаёт группу размещения внутри панели; visible и index — видимость и порядок. Категория группы должна совпадать с типом панели (для navigation — FormNavigationPanel*, для commandBar — FormCommandBar*); иначе плагин сразу вернёт понятную ошибку, не оставляя форму в битом состоянии. Сама команда должна существовать в проекте до этого вызова — создаётся через createObjectCommand или createObject CommonCommand.
Обратная операция: убирает ссылку на команду из командного интерфейса формы. Сама команда (объектная или общая) при этом не удаляется — стирается только её пункт в выбранной панели.
Меняет одно из свойств существующего пункта-ссылки в панели формы: group (группа размещения), visible (видимость) или index (позиция в группе). Категория новой группы должна соответствовать типу панели (как и в addFormCommandInterfaceItem); иначе плагин откажет до записи.
Добавляет на любую форму (обработки, отчёта, общей формы, формы документа) реквизит-композитор настроек компоновки данных с UI-таблицами — как галочка «Настройки на форме» в мастере EDT, но доступно не только отчётам. Ставит сразу: реквизит типа КомпоновщикНастроек, таблицу «Структура» (дерево группировок), группу пользовательских настроек и привязку ExtInfo формы. Опциональный параметр standardItems регулирует, какие UI-таблицы вывести: только структура (по умолчанию), алиас full — полный набор (группировки + отборы + сортировка + условное оформление), либо произвольный список. Ответ операции содержит готовый BSL-пример для обработчика ПриСозданииНаСервере — с корректной передачей схемы через временное хранилище и правильным вызовом ПолучитьМакет в зависимости от того, где лежит макет (обработка / справочник / отчёт / общий). Полный сценарий сборки от объекта до BSL-кода формирования результата — в справочнике через help topic=composerWorkflow.
Макеты печатных форм (8 операций)
Полная поддержка создания макетов — от пустого объекта до готовой печатной формы, без переключения в EDT. Макеты можно создавать у справочников, документов, обработок, отчётов, а также как общие макеты конфигурации.
Создание макета. Поддерживаемые типы: табличный документ (по умолчанию), текстовый документ, схема компоновки данных, макет оформления компоновки, двоичные данные, активный документ, HTML-документ, географическая схема, графическая схема, внешняя компонента. Принимает русские имена типов (Табличный, Текстовый, СКД, Двоичные данные, …) и английские.
Установка содержимого одной ячейки табличного макета: текст, цвет текста и фона, шрифт (жирный/курсив/подчёркнутый/размер/имя), горизонтальное и вертикальное выравнивание, пометка ячейки как параметра (для подстановки данных при печати).
Объединение диапазона ячеек табличного макета (от столбца A строки N до столбца B строки M).
Пакетное заполнение макета одним вызовом: массив ячеек, массив объединений, ширины колонок, высоты строк, именованные области (Шапка, СтрокаТовара, Подвал — на эти имена ссылается код печати через Макет.ПолучитьОбласть("Шапка")). За один вызов можно собрать целый бланк.
Задаёт именованную область макета для отдельного вызова Макет.ПолучитьОбласть("ИмяОбласти") в коде печатной формы. Принимает три формы описания: прямоугольник ячеек (от строки/колонки на N строк/колонок), диапазон строк (с какой по какую) или диапазон столбцов (с какого по какой). Полезно, когда макет уже собран в EDT вручную или другим инструментом, а нужно лишь добавить новую именованную область без полной перерисовки через drawTemplate.
Типичный сценарий печатной формы: один createObject + один addTemplate + один drawTemplate со всеми ячейками, объединениями и областями — готовый макет, идентичный нарисованному вручную в EDT. Код вывода печатной формы пишется обычным write_module_source.
Расширения (6 операций)
Полная поддержка работы с расширениями конфигурации:
Создаёт сам проект расширения — так же, как мастер EDT: имя, префикс имён, назначение (адаптация / дополнение / исправление), синоним и привязка к базовой конфигурации. Единственная конфигурация рабочей области выбирается базой автоматически. Сразу после создания в расширении работают заимствование объектов и создание собственных — AI проходит путь «создал расширение → заимствовал → доработал» без участия человека.
Заимствовать один объект из базовой конфигурации. По умолчанию — только сам объект. С параметром recursive=true — объект вместе со всеми дочерними элементами (реквизиты, табличные части, формы, команды).
Заимствовать несколько объектов базы одним вызовом по явному списку — например, пять справочников и два документа. Альтернатива многократному вызову adoptObject и альтернатива recursive=true, когда хочется именно эти объекты без их форм и реквизитов. В ответе — результат по каждому объекту отдельно (заимствован, уже был, не удалось). Ошибка на одном объекте не прерывает обработку остальных.
Заимствовать конкретный дочерний элемент: реквизит, табличную часть, форму, команду, измерение, ресурс.
Заимствовать элемент внутри заимствованной формы (главный реквизит, команду, параметр).
Включает участие модуля заимствованного объекта в расширении — ту самую галочку «Объектный модуль» / «Модуль менеджера» / «Модуль набора записей» / «Модуль команды» / «Модуль значения» на вкладке «Расширение» в редакторе объекта в EDT. Без этой галочки файл модуля на диске есть, но платформа при исполнении в 1С:Предприятии его игнорирует. Параметр moduleType задаёт, какой именно модуль включаем. Операция идемпотентна. Отдельно вызывать нужно редко: обычно при записи кода через write_module_source активация происходит автоматически.
При добавлении реквизитов со ссылочными типами инструмент автоматически заимствует связанные объекты. При записи кода в модуль заимствованного объекта через write_module_source — автоматически включается нужная галочка участия модуля в расширении.
Расширения в информационной базе (.cfe) (3 операции)
Подключение готовых расширений (.cfe) — движок тестов YAxUnit, оснастки, инструменты — прямо в информационную базу проекта, без импорта исходников в рабочую область. Раньше это делалось руками через «Управление расширениями конфигурации»; теперь — одним вызовом.
Подключает готовое расширение к информационной базе проекта. Источник — локальный файл .cfe, прямая ссылка или GitHub-репозиторий (берётся последний релиз). Повторный вызов безопасен: существующее расширение с этим именем штатно обновляется на месте. Расширение живёт в базе — в проекты рабочей области ничего не добавляется, исходники не появляются. Отключать базу или закрывать EDT не нужно.
Показывает все расширения информационной базы — и установленные этой операцией, и опубликованные из проектов рабочей области.
Удаляет расширение из информационной базы по имени.
Отчёты СКД (48 операций)
Полный цикл работы с отчётами на схеме компоновки данных: всё, что отчёт умеет в платформе, собирается через MCP без открытия редактора СКД вручную. Схему можно не только собрать с нуля, но и править точечно — у каждого элемента схемы есть набор «создать / изменить / удалить». Все операции работают не только для отчётов: схема компоновки и её наполнение (наборы данных, параметры, группировки, отборы, сортировки и т.д.) доступны также в макетах обработок, справочников, документов, планов счетов, бизнес-процессов, задач и планов обмена — везде, где в 1С бывают макеты типа «Схема компоновки данных». Для не-отчётов указывается имя макета через параметр templateName. Внешние отчёты .erf поддержаны наравне с обычными. После каждой операции предпросмотр в открытом редакторе СКД обновляется сразу — перезапускать EDT не нужно.
Схема и наборы данных
createReportSchema — создание схемы с готовым скелетом (источник данных, вариант настроек, автополе).
addDataSet / setDataSetProperty / removeDataSet — добавить, изменить (имя, источник, текст запроса) или удалить набор данных. При удалении набора связанные с ним связи убираются автоматически, при переименовании — переключаются на новое имя.
addDataSetField / removeDataSetField — поля набора данных. Для набора «из кода» (внешнего) добавление поля сразу дописывает соответствующую колонку в процедуру отчёта — поле не «теряется».
Правка запроса набора
addQueryField / removeQueryField — добавить или убрать одно поле в выборке запроса, не переписывая весь текст запроса. Остальные части (отборы, упорядочивание, группировки) остаются нетронутыми.
addQueryCondition — добавить одно условие в отбор запроса.
Связи наборов данных
addDataSetLink / setDataSetLinkProperty / removeDataSetLink — связать два набора данных по полю (типичный случай: продажи в одном наборе, реквизиты организаций в другом, связь по «Организация»), изменить или удалить связь. Раньше связь можно было только создать — теперь полный цикл.
Параметры схемы
addSchemaParameter — добавить параметр (тип, длина, выражение по умолчанию, признак списка значений).
setSchemaParameter — изменить уже созданный параметр (тип, длина, выражение, флаги). Меняются только переданные поля.
removeSchemaParameter — удалить параметр.
moveSchemaParameter — поменять параметры местами (направление Up/Down или явная позиция).
Вычисления и итоги
addCalculatedField / setCalculatedField / removeCalculatedField — вычисляемое поле (выражение над другими полями): добавить, изменить выражение, удалить.
addTotalField / setTotalField / removeTotalField — итог-ресурс с агрегацией (Сумма, Количество, Максимум и др.): добавить, изменить выражение или группировки, удалить.
addUserField — пользовательское поле-выражение.
Структура настроек
addSettingsGroup — группировка (обычная, детальные записи, вложенная, внутри таблицы/диаграммы).
addSettingsTable — кросс-таблица с группировками по строкам и колонкам.
addSettingsChart — диаграмма с точками и сериями.
addSettingsSelectedField / removeSettingsSelectedField / clearSettingsSelectedFields — управление выводимыми полями, в т.ч. очистка всего списка одной командой.
removeSettingsItem — удаление группировки, таблицы или диаграммы.
Отборы, сортировка, оформление
addSettingsFilter / removeSettingsFilter — элемент отбора (20+ типов сравнения): добавить или удалить.
addSettingsFilterGroup — группа отборов (И/ИЛИ/НЕ).
addSettingsOrder / removeSettingsOrder — сортировка: добавить или удалить.
addConditionalAppearance / setConditionalAppearance / removeConditionalAppearance — условное оформление с полным набором параметров (формат, цвета, шрифт, отступы и др.): добавить, изменить, удалить.
setDataSetFieldAppearance — постоянное оформление поля набора (например, формат числа).
Варианты отчёта
addSettingsVariant — новый вариант отчёта.
cloneSettingsVariant — скопировать вариант целиком (со всеми группировками, отборами и оформлением) под новым именем.
setSettingsVariantProperty — переименовать вариант или сменить его заголовок.
removeSettingsVariant — удалить вариант (последний удалить нельзя).
Любую настройку (группировку, отбор, сортировку, оформление) можно адресовать конкретному варианту — многовариантные отчёты собираются полностью через MCP.
Значения параметров, вывод, быстрые настройки
setSettingsParameter / removeSettingsParameter — задать или снять значение параметра в настройках отчёта.
setOutputParameter — параметры вывода (заголовок отчёта, макет оформления, тип диаграммы и др.). Русские и английские названия.
setSettingsItemUserMode — вынести любую настройку (отбор, сортировку, оформление, группировку, поле, параметр) в шапку отчёта быстрыми настройками или, наоборот, спрятать. Агент сразу собирает отчёт с удобной шапкой.
Восстановление
repairReportSchema — перечитать схему компоновки данных с диска и обновить её содержимое в проекте. Нужно, если в редакторе СКД превью пустое или deploy в инфобазу выдаёт «Неизвестный объект метаданных», хотя файл .dcs существует и непустой. Идемпотентна.
Пример создания минимального отчёта — 6 вызовов: создание объекта, схемы, набора данных с запросом, ресурса, группировки и заголовка. Сложный отчёт из десятков операций можно отправить одним пакетным вызовом — плагин выполнит их по очереди и вернёт общий итог, а повторный вызов с тем же именем элемента не создаёт дубль.
Общее (2 операции)
Перемещение элемента в другой контейнер на конкретную позицию.
Удаление элемента по имени.
Сервис (1 операция)
Дожидается, пока все ранее запланированные записи проекта на диск завершатся. У EDT есть внутренние очереди записи — edit_metadata вносит изменения в модель, а реальная запись в .mdo и .bsl файлы происходит асинхронно. Обычные сценарии этого не требуют — операции ждут синхронизации сами. syncExport нужен в редких случаях: после серии быстрых правок перед запуском сборки проекта, перед коммитом в git из внешнего инструмента, перед чтением только что записанного файла каким-то скриптом за пределами плагина. Возвращает количество дождавшихся записей и время ожидания.
Пакетные режимы
Большинство операций поддерживают создание нескольких элементов за один вызов — передавайте массив вместо одиночного элемента. Это позволяет, например, создать справочник с 10 реквизитами, табличной частью и формой за 3–4 вызова вместо 15.
createObject принимает сразу реквизиты (attributes) и табличные части с колонками (tabularSections) — полноценный справочник или документ создаётся одним вызовом.
adoptObjects — пакетное заимствование нескольких объектов из базы в расширение по явному списку (альтернатива рекурсивному режиму, когда не нужно тянуть формы и реквизиты).
Режим предпросмотра (dryRun)
К любой операции можно добавить параметр dryRun=true — плагин выполнит её внутри транзакции и откатит: в ответе виден полный результат (что было бы создано, какие реквизиты, поля, формы), а в проекте ничего не меняется. Полезно для перепроверки сложных пакетных вызовов и уточнения правильности типов (CatalogRef.X, ОпределяемыйТип.Y) — ошибка резолва типа в режиме предпросмотра не испортит проект.
Режим работает для всех операций конструктора метаданных (создание/модификация объектов, реквизитов, форм, элементов формы, макетов, отчётов СКД). Не поддерживается для adoptObject/adoptObjects/adoptChild и удаления реквизитов/табличных частей — эти операции по устройству платформы используют отдельные механизмы, которые нельзя откатить. При передаче dryRun в такую операцию плагин возвращает внятное пояснение вместо молчаливого применения.
Что пока не реализовано
- Декорация-картинка (пока только надписи).
yaxunit_tests — Юнит-тесты YAxUnit
Полный цикл AI-разработки 1С: ассистент сам пишет юнит-тесты, прогоняет их, разбирает упавшие через отладчик и правит код — без единого клика мышью со стороны пользователя. Между правкой кода и итоговым отчётом проходит только время выполнения 1С:Предприятия и самих тестов.
Один MCP-инструмент с режимами run и debug. Стартует 1С:Предприятие через штатную Run Configuration EDT, передаёт расширению YAxUnit JSON-конфиг прогона, парсит JUnit XML и возвращает Markdown-отчёт. В режиме отладки точки останова, поставленные через launch_debugger, срабатывают как обычно — ассистент сам смотрит переменные, вычисляет произвольные BSL-выражения, делает шаги по коду.
- Запуск — фильтры по расширениям, общим модулям, конкретным тестам, тестовым наборам, тегам и контекстам исполнения (Server/Client/ExternalConnection).
- Отладка — режим mode=debug, при срабатывании точки останова возвращается status=Pending; ассистент управляет сессией через launch_debugger (getState/getVariables/evaluate/resume), затем перезванивает yaxunit_tests за финальным отчётом.
- Автообновление информбазы — параметр updateBeforeLaunch=true (по умолчанию) синхронизирует базу с проектом перед запуском, чтобы 1С не показала модальное окно «Обновить конфигурацию?», блокирующее автономную работу.
- Pending-механизм — если прогон не уложился в окно ожидания, 1С не убивается, ассистент перезванивает с теми же параметрами и забирает результат когда тот появится.
- Встроенная справка для AI — параметр help со значениями topics / writing / assertions / setup / events / advanced: ассистент по запросу подгружает короткий тематический туториал по YAxUnit и пишет тесты по правилам, даже если изначально не знаком с фреймворком.
- Reactive-подсказка при пустом результате — если прогон вернул 0 тестов (типичная ошибка: процедуры написаны, но не зарегистрированы в ИсполняемыеСценарии), Markdown-отчёт сразу выдаёт три самые частые причины и указатель на help=writing для шаблона теста.
- Требования — в EDT настроена Run Configuration для проекта; расширение YAxUnit (.cfe, Apache 2.0) подключено к информбазе. Подробное руководство пользователя — в разделе «Юнит-тесты YAxUnit» руководства.
vanessa — Сценарное UI-тестирование (Vanessa Automation)
Вторая половина полного цикла тестирования. Если yaxunit_tests проверяет код изнутри, то vanessa проверяет программу снаружи, глазами пользователя: открывает формы, нажимает кнопки, заполняет поля, сверяет результат — и говорит, какой шаг сценария упал и почему. Сценарий пишется обычным текстом на русском (Gherkin: «Дано… Когда… Тогда…»), AI составляет его сам, без программирования.
Инструмент обвязывает фреймворк Vanessa Automation: при первом запуске сам скачивает и ставит его, поднимает 1С в режиме тестирования, прогоняет .feature-сценарии и возвращает понятный Markdown-отчёт — сколько сценариев прошло, какой шаг сломался, текст ошибки 1С, скриншот падения (если включён). Долгий прогон не обрывается: инструмент возвращает «идёт в фоне» с идентификатором сессии, повторный вызов забирает готовый отчёт — ровно как у yaxunit_tests.
- run — прогон сценариев. Фильтр по тегам (tags / ignoreTags), путь к сценариям (featurePath, по умолчанию каталог features проекта). Перед прогоном база обновляется автоматически тем же механизмом, что у sync_database — без модального окна «Обновить конфигурацию?».
- Скриншот при падении — снимок экрана в момент, когда шаг сценария упал: видно, что реально было на экране (не та форма, неожиданный диалог, окно ошибки платформы) — вместо догадок по тексту ошибки. По умолчанию выключено (обычный прогон не нагружается снимками); включается просьбой «прогони со скриншотами». В кадр попадает именно окно 1С, а не весь рабочий стол. Готовый снимок прикладывается к отчёту — агент его открывает и показывает либо описывает. Если сценарий упал без снимка, отчёт сам подсказывает, что падение можно переснять со скриншотом — и агент предложит это вам, прежде чем запускать повторный прогон (сам, без спроса, не перезапускает).
- steps — словарь шагов Gherkin: поиск по словам и категориям, список самых используемых шагов по статистике реальных проектов. Каждый шаг возвращается готовой строкой для вставки в сценарий. Читается прямо из установленной Vanessa — без запуска 1С и без расхода лицензий.
- checkSyntax — проверка .feature до прогона: каждый шаг сверяется со словарём установленной Vanessa без запуска 1С, ответ мгновенный. Для неопознанных шагов называет файл, строку и предлагает похожие настоящие шаги.
- Просмотр вживую — keepOpen=true не закрывает 1С после прогона, stepDelaySeconds замедляет шаги, чтобы видеть, как открываются формы и нажимаются кнопки. Окна, оставленные «на посмотреть», следующий прогон закрывает сам.
- Честность по лицензии — каждый прогон держит два сеанса 1С (менеджер тестирования + клиент). При нехватке лицензий в ответе — дословное сообщение платформы и признак licenseLimit; зависший старт инструмент снимает сам и возвращает понятную ошибку вместо вечного ожидания.
- Связка с юнит-тестами — оба инструмента ходят в одну информационную базу и используют общий цикл обновления и фонового ожидания: один объект проверяется и кодом (yaxunit_tests), и интерфейсом (vanessa). Подробное руководство — в разделе «Сценарное тестирование Vanessa» руководства.