Инструменты Профессиональной версии

Включает все инструменты Расширенной, плюс глубокий анализ всей кодовой базы, архитектурная визуализация, автогенерация документации, генерация тестов и .epf обработок, навигация по типовым конфигурациям, структурный diff расширений .cfe. Большинство возможностей требуют предварительного построения кэша или разовой генерации.

Пути к выгрузкам в v2.30.0

Каталоги и имена файлов, которые инструмент получает в параметрах вызова, теперь ограничены выгрузками зарегистрированных баз. Прежде несколько инструментов принимали произвольный путь и могли прочитать, записать или удалить что-то за пределами предполагаемого каталога; теперь такой путь разрешается только внутри каталога выгрузки, зарегистрированного флагом --dump. Проверка идёт до первого открытия файла, когда путь приводится к каноническому виду, символьные ссылки в нём раскрываются, а результат обязан совпадать с зарегистрированным каталогом или лежать внутри него, поэтому и .., и абсолютный путь мимо всех выгрузок, и ссылка наружу отклоняются до чтения. Внутри разрешённого каталога обращения к файлам вдобавок удерживаются средствами операционной системы, которая проверяет каждый элемент пути на своей стороне, хотя часть разбора выгрузки и служебные кэши по-прежнему открывают уже проверенный путь напрямую. Мы рекомендуем обновиться всем, кто работает на Профессиональной и Корпоративной версиях.

Ограничение затрагивает explain_exchange_plan, autodoc, archviz, typicalconfigs, explain_rls, code_review, update_helper, epfgen, testgen, code_read и выбор базы в инструменте hub. У code_read при этом параметра с путём нет вовсе, он добирается до выгрузки только через зарегистрированную базу, а инструмент hub есть лишь в Корпоративной сборке, так что на Профессиональной ни в том, ни в другом менять в своих вызовах нечего. Чаще всего оно незаметно, потому что вызовы с параметром base и разовые запуски через собственные флаги оператора (--autodoc-out, --testgen-output, --epfgen-output, --typicalconfigs-output) работают как прежде. Заметным оно становится там, где путь передавался абсолютным и вёл за пределы зарегистрированных выгрузок: такой вызов теперь отклоняется.

Чтобы вызов, работавший раньше, продолжил работать, укажите нужный каталог при запуске сервера флагом --dump, и тогда он сам и всё, что лежит внутри него, снова разрешены. В мультибазовом режиме имя в --dump ИМЯ=ПУТЬ должно совпадать с именем базы из --base. Относительный путь принимает только explain_exchange_plan и только когда администратор настроил корневой каталог сравнения флагом --exchange-compare-root; у остальных инструментов относительного маршрута нет.

Отдельно стоит проверить два сценария, где путь по своей природе живёт вне рабочей выгрузки. Помощник обновления обычно сравнивает вашу конфигурацию с выгрузкой поставки вендора, которая лежит в стороне, поэтому либо зарегистрируйте её как базу, либо пользуйтесь разовым запуском --update-helper с флагами --vendor-new и --vendor-old, который ограничением не затронут. Сравнение расширения с базовой конфигурацией через code_review действия base_vs_ext тоже часто выполнялось по рабочему каталогу разработчика, а разового запуска у этого действия нет, поэтому каталог расширения придётся зарегистрировать.

bulk_analyze

Профессиональная

Массовый анализ кодовой базы 1С

Комплексный анализ всей кодовой базы: антипаттерны, дубли кода, мертвый код, аудит безопасности, метрики качества. Требует предварительного построения кэша командой --build-bulkanalysis.

Действия:

• action: "summary" - сводка по всей кодовой базе: количество модулей, находок по категориям, общий балл техдолга
• action: "findings" - антипаттерны и ошибки кода (30 правил): неоптимальные запросы, утечки ресурсов, устаревшие конструкции
• action: "duplicates" - дубли кода (MinHash + LSH): похожие фрагменты в разных модулях с процентом совпадения
• action: "deadcode" - мертвый код: неиспользуемые процедуры, переменные, параметры
• action: "security" (устарело) - аудит безопасности BSL (11 правил SEC): SQL-инъекции, небезопасные вызовы, утечки данных. Устаревший алиас, используйте action: "findings" с category: "security"
• action: "metrics" - метрики качества: LOC, цикломатическая сложность, глубина вложенности, балл техдолга (0-100)
• action: "trends" - динамика показателей между запусками анализа

Параметры:

• cvss_format - формат отчёта при action=findings + category=security: auto (по умолчанию, группировка по CVSS-критичности), grouped (всегда CVSS-группировка), flat (плоский список)
• include_suppressed - включить в ответ находки, подавленные через audit:ignore: они показываются помеченными, отдельной секцией, а не скрываются. Для: findings, security (v2.23.0)

У находок безопасности приводятся оценки CVSS (вектор, балл и уровень критичности) рядом со ссылками на CWE и OWASP, что помогает приоритизировать исправления (v2.23.0).

Подавление находок прямо в коде через комментарий // audit:ignore ПРАВИЛО -- причина (построчно) или блоком // audit:ignore-begin ... // audit:ignore-end; поддерживается срок действия [expires ГГГГ-ММ-ДД]. Подавленные находки не учитываются в сводках по умолчанию, помечаются в SARIF массивом suppressions[] и возвращаются по флагу include_suppressed (v2.23.0).

В аудите безопасности (category: "security") рядом со ссылками на CWE и OWASP приводятся справочные сопоставления находок с мерами ГОСТ Р 57580.1 и приказа ФСТЭК России N 21. Это справочная информация для оценки и приоритизации; она не является сертификацией или подтверждением соответствия (v2.22.0, уточнено в v2.23.0).

Правило SEC006 даёт меньше ложных срабатываний (v2.23.0).

Требует: --dump + --build-bulkanalysis (предварительное построение кэша)

update_helper

Профессиональная

Сравнение конфигураций / помощник обновления

Сравнение конфигураций (2-way или 3-way) для подготовки к обновлению: что изменилось между вашей доработанной конфигурацией и поставкой вендора. Анализ выполняется асинхронно: действие analyze ставит задачу в очередь и сразу возвращает job_id, а статус и итоговый отчёт забираются отдельными действиями.

Действия:

• action: "analyze" - поставить сравнение конфигураций (2-way или 3-way) в очередь и вернуть job_id
• action: "summary" - статус задачи: queued / running / done / error с прогрессом (progress_pct)
• action: "get_report" - итоговый отчёт сравнения (когда status=done)

Параметры:

• dump_path + vendor_new (обязательны для analyze) - выгрузка вашей конфигурации и новой поставки вендора
• vendor_old - старая поставка вендора; если задана, выполняется 3-way сравнение (иначе 2-way)
• format - формат отчёта: markdown (по умолчанию), text, json, html, pdf
• job_id (обязателен для summary и get_report) - идентификатор задачи из analyze

check_query (v2.25.0)

Профессиональная

Семантическая проверка запроса 1С по метаданным

Офлайн семантическая проверка текста запроса 1С по метаданным выгрузки. Дополняет синтаксическую проверку запроса из Открытой версии (code_execute с action: "validate"): сверяет существование таблиц и полей, разыменование через точку по ссылочным типам, применимость виртуальных таблиц. Живая база 1С не нужна.

Это отдельный инструмент верхнего уровня, а не действие консолидированного code_execute, потому что на вход принимает текст запроса, а не ссылку на объект или модуль.

Параметры:

• query (обязательный) - текст запроса на языке запросов 1С
• base - имя базы, если подключено несколько
• db_target - целевая СУБД для меток критичности: postgres, mssql, postgres_pro_1c, tantor
• format - формат вывода: text (по умолчанию) или json

Правила проверки: QRY031 сообщает о поле, которого нет у объекта метаданных; QRY032 ловит некорректное разыменование через точку, когда поле после точки отсутствует у типа, на который ссылается предыдущее поле. Проверка существования полей охватывает 8 видов объектов: Справочник, Документ, регистры сведений и накопления, планы счетов и видов характеристик, Задача, БизнесПроцесс.

Без выгрузки выполняется только синтаксическая и структурная проверка. Полная проверка существования таблиц и полей включается запуском сервера с флагами --dump и --enable-query-resolve.

Требует: --dump + --enable-query-resolve для проверок существования (без них только синтаксис)

check_bsl_api (v2.27.0)

Профессиональная

Проверка API платформы в коде BSL

Офлайн проверка текста модуля BSL по загруженному синтаксическому корпусу платформы 1С. Проверяется именно API платформы, а не стиль кода: в отличие от check_bsl (пустые блоки Исключение, транзакции, неиспользуемые переменные и прочие code smells) и от bsl_syntax_help (справочник только ищет по корпусу), этот инструмент сверяет вызовы с тем же корпусом. Живая база 1С и выгрузка не нужны.

Это отдельный инструмент верхнего уровня, а не действие check_bsl, потому что на вход принимает текст модуля, а не ссылку на объект.

Находит два вида проблем:

• API001: вызовы устаревших глобальных методов платформы. Если корпус содержит версию признания устаревшим и рекомендуемую замену, они приводятся в сообщении.
• API010 (рекомендательно): вызовы без префикса, которых нет в загруженном корпусе платформы. Формулировка привязана к корпусу («не найдено в загруженном корпусе платформы»), потому что отсутствие в корпусе не доказывает, что метода не существует (возможна опечатка или символ из другой версии платформы). Это всегда предупреждение, а не ошибка.

Параметры:

• code (обязательный): исходный текст модуля BSL
• format: формат вывода, text (по умолчанию) или json

Границы проверки: точечные вызовы вида Объект.Метод не проверяются, потому что тип приёмника не выводится; конструкторы, число и типы аргументов, значения системных перечислений вне области. Существование сверяется только по точным картам корпуса, нечёткий поиск не используется. Без загруженного корпуса (флаг --update-syntax) проверки существования и устаревания пропускаются, и в выводе явно отмечается, что корпус недоступен, чтобы тишина не читалась как успешная проверка.

Требует: обновлённый синтаксический корпус платформы (--update-syntax); без него проверки пропускаются с явной отметкой о недоступности корпуса

explain_rls (v2.27.0)

Профессиональная

Разбор прав и RLS ролей (офлайн, по выгрузке)

Офлайн разбор дерева Roles/ выгрузки конфигурации: по каждой роли показывает матрицу прав, шаблоны ограничений роли и дословные тексты ограничений доступа на уровне записей (RLS). Живая база 1С не нужна, читается только выгрузка.

Это разбор структуры, а не аудитор и не симулятор. Вывод строго структурный: (роль, объект, право, значение, текст ограничения или пусто), считанный из XML. Право, выданное без ограничения на уровне записей, помечается отдельно (значение true, без ограничения) как структурный факт.

Параметры:

• dump_path: путь к каталогу выгрузки (содержит Roles/); обязателен, если не указан base
• role: опциональный фильтр, показать только роль с этим именем
• object: опциональный фильтр, показать только этот объект метаданных (например Справочник.Контрагенты)
• with_restrictions_only: показать только права, несущие ограничение RLS (по умолчанию выключено)
• format: формат вывода, text (по умолчанию) или json
• base: имя базы, если подключено несколько; источник выгрузки при отсутствии dump_path

Границы: инструмент не выносит вердикт о доступе конкретного пользователя, потому что в выгрузке нет ни пользователей, ни параметров сеанса; не вычисляет эффективные права по набору ролей; не интерпретирует смысл языка ограничений, текст условия показывается дословно. Роль, чей Rights.xml не удалось разобрать (или он слишком большой, или недоступен), попадает в примечания и не выдаётся за чистую.

Требует: выгрузку конфигурации (параметр dump_path или база, подключённая через --dump)

explain_exchange_plan (v2.27.0)

Профессиональная

Обмен 1С: разбор, сравнение и карта (офлайн, по выгрузке)

Что изменилось в v2.30.0. Параметр dump_path больше не принимает произвольный каталог. В версиях с v2.27.0 по v2.29.3 инструмент читал любой каталог, внутри которого находился подкаталог ExchangePlans, а теперь путь разрешается только двумя способами: абсолютный путь принимается, если он совпадает с каталогом выгрузки зарегистрированной базы или лежит внутри него, а относительный путь принимается, если администратор настроил корневой каталог сравнения флагом --exchange-compare-root. Значения, которые прежние версии принимали, теперь отклоняются с сообщением «Путь к выгрузке отклонён», поэтому жёстко прописанный в скрипте абсолютный путь к выгрузке перестанет работать, пока вы либо не зарегистрируете эту выгрузку как базу флагом --dump, либо не настроите корневой каталог сравнения и не перепишете вызов на относительный путь внутри него. Абсолютный путь внутри корневого каталога сравнения тоже отклоняется, потому что абсолютные пути разрешаются только через зарегистрированную базу.

Инструмент работает офлайн по выгрузке конфигурации и умеет три режима, которые выбираются параметром mode. Живая база 1С не нужна ни в одном из них.

mode: plan (по умолчанию)

Разбор дерева ExchangePlans/ выгрузки: по каждому плану обмена показывает имя, синоним, флаг распределённой информационной базы (РИБ, DistributedInfoBase), включение расширений конфигурации, имена ссылок на шаблоны и состав, то есть какие объекты входят в план, плюс дословный токен авторегистрации AutoRecord.

Инструмент показывает, как обмен настроен, а не то, что реально синхронизировалось. Реквизиты самого объекта плана обмена смотрите через get_object_structure. Это разбор структуры, а не аудитор и не симулятор: данные берутся из ExchangePlans/Имя.xml и ExchangePlans/Имя/Ext/Content.xml.

Токен AutoRecord (Deny или Allow) показывается дословно, как нейтральный факт, без вывода о синхронизации: в РИБ все объекты состава могут иметь Deny и всё равно переноситься составом конфигурации.

Сам вывод этого режима не менялся: для пути, который по новым правилам по-прежнему разрешается, ответ совпадает с ответом прежних версий байт в байт.

mode: diff (v2.30.0)

Сравнение двух планов обмена в двух формах. Один и тот же план в двух выгрузках сравнивается, когда заданы dump_path, dump_path_b и plan, а два разных плана в одной выгрузке сравниваются, когда заданы plan и plan_b. Если не задано ни dump_path_b, ни plan_b, вызов отклоняется ещё до чтения файлов, потому что непонятно, что с чем сравнивать.

В ответ попадают только изменившиеся поля, а именно синоним, комментарий, признак РИБ, включение расширений конфигурации и имена ссылок на шаблоны, плюс разница состава с разделением на добавленные и удалённые объекты, изменения токена AutoRecord и число совпавших позиций. Признак clean выставляется только тогда, когда оба плана найдены, поля не менялись, состав удалось сравнить, разница пуста и ни по одной из выгрузок нет ни одного примечания. Примечания при этом собираются по всему каталогу ExchangePlans/, а не по сравниваемому плану, поэтому нечитаемый или пропущенный соседний план в той же выгрузке снимает clean, хотя разница остаётся пустой. Если различий не видно, а clean нет, причина будет в списке примечаний.

План, которого нет в одной из выгрузок, ошибкой не считается и за отсутствие различий не выдаётся: сторона помечается как ненайденная, а списки разницы остаются пустыми. Так же инструмент ведёт себя ещё в четырёх случаях: когда состав в выгрузке не задан и отбор объектов определяет формат обмена, когда файл состава есть, но прочитать его не удалось, когда состав усечён по лимиту и когда в нём есть повторяющиеся объекты. Всего таких причин пять, и каждая названа словами рядом со стороной, к которой относится.

mode: map (v2.30.0)

Карта обмена по выгрузке, в которую входят планы обмена, регламентные задания вместе с расписанием, подписки на события и признаки обмена в коде. Расписание регламентного задания показывается не выборочно: в ответ попадают все атрибуты элемента Schedule и все его непосредственные вложенные элементы в том порядке, в каком они лежат в выгрузке. Объявления пространств имён (xmlns) пропускаются, а у вложенного элемента, внутри которого есть своя структура, показывается только собранный из неё текст без разбивки на подэлементы, так что расписание с вложенностью глубже одного уровня читается как строка. Всего берётся не больше 512 полей, считая атрибуты и элементы вместе, и при срабатывании этого предела в ответе появляется примечание «расписание усечено по лимиту числа полей».

Признаки обмена в коде ищутся по семи семействам, это регистрация изменений (registration), сообщения обмена (messages), узлы плана обмена (nodes), признак загрузки обмена (dataexchange), сериализация данных (serialization), файловый обмен (files) и внешние соединения (connections). Каждый признак ищется и в русском, и в английском написании, например ОбменДанными и DataExchange, поэтому конфигурация, написанная на английском встроенном языке, тоже попадает в выдачу, а не выглядит как база без обмена.

Параметр verbs добавляет свои признаки к тому, что уже ищется, а не заменяет собой семейство. Без family поиск идёт по всем семи семействам и по переданным признакам сразу, а вместе с family по одному выбранному семейству и по ним же, поэтому сочетание family и verbs выборку расширяет, а не сужает. Найденное по своим признакам выделяется в отдельную группу «Свои признаки, переданные в вызове» и платформенным семействам не приписывается. Признаки ищутся буквально, принимается не больше двадцати штук длиной до 64 символов, а о том, сколько признаков отброшено и по какой причине, сказано в примечании. Когда заданы и family, и verbs, число найденных строк посчитано по семейству вместе со своими признаками, и это тоже названо в примечании.

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

Параметры

• dump_path: путь к каталогу выгрузки (содержит ExchangePlans/); абсолютный путь только к зарегистрированной базе, относительный только внутри настроенного корневого каталога сравнения
• plan: опциональный фильтр, показать только план обмена с этим именем
• mode: режим работы, plan (по умолчанию), diff или map (v2.30.0)
• dump_path_b: вторая выгрузка для mode: "diff", разрешается по тем же правилам, что и dump_path (v2.30.0)
• plan_b: второй план для mode: "diff" в пределах одной выгрузки; по умолчанию совпадает с plan (v2.30.0)
• family: для mode: "map" оставить одно семейство признаков из семи перечисленных выше (v2.30.0)
• verbs: для mode: "map" свои признаки, которые ищутся вместе с семействами, а не вместо них (v2.30.0)
• format: формат вывода, text (по умолчанию) или json
• base: имя базы, если подключено несколько; источник выгрузки при отсутствии dump_path

Границы: инструмент не подключается к живой базе и не показывает рантайм обмена. Таблицы регистрации изменений, список и состояние узлов, номера сообщений, очередь ошибок и конфликты РИБ вне области, потому что их нет в выгрузке. Отсутствие Content.xml это не пустой состав, а признак того, что отбор задаёт формат (планы на универсальном формате обмена). Файл Content.xml, который не удалось разобрать (или он слишком большой, или отклонён проверкой безопасности), даёт статус «состав неизвестен» и не выдаётся за чистый. Найденный в коде признак обмена говорит о том, что конструкция встречается в модуле, а не о том, что она выполняется.

Требует: выгрузку конфигурации, зарегистрированную флагом --dump, либо относительный путь внутри каталога, заданного флагом --exchange-compare-root

exchange_drops (v2.30.0)

Профессиональная

Осмотр каталогов файлового обмена 1С

Показывает, что лежит в каталоге файлового обмена: имена, размеры, даты изменения и возраст файлов. Отвечает на вопрос, идёт ли файловый обмен и как давно там лежат файлы, без подключения к базе и без расширения 1С, поэтому годится и там, где база недоступна.

Содержимое файлов инструмент не читает: сообщения обмена это данные клиента, и он берёт только то, что отдаёт lstat, то есть имя, размер, дату изменения и признак каталога или ссылки. Абсолютный путь к настроенному каталогу в ответ не попадает, имена показываются относительно него.

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

Каталог задаёт администратор флагом --exchange-drop-root или переменной окружения MCP_1C_EXCHANGE_DROP_ROOT. Пока каталог не настроен, инструмент вообще не регистрируется и не появляется в списке инструментов, так что AI-ассистент его не увидит.

Параметры:

• subdir: относительный подкаталог внутри настроенного каталога обмена; абсолютный путь не принимается
• stale_after_minutes: порог в минутах, добавляет в ответ число файлов старше порога (по умолчанию 0). При нулевом пороге в текстовом ответе счётчика нет, а в формате json поля stale_after_minutes и stale_count присутствуют всегда и равны нулю
• max_entries: предел числа показанных записей, 0 означает значение по умолчанию 500; запрошенное значение свыше 200000 уменьшается до предела, о чём говорится в примечании
• max_depth: предел вложенности обхода, 0 означает значение по умолчанию 2; запрошенное значение свыше 64 уменьшается до предела, о чём говорится в примечании
• format: формат вывода, text (по умолчанию) или json

Верхние границы max_entries и max_depth объявлены ещё и в схеме инструмента (200000 и 64), поэтому клиент, который сверяет аргументы со схемой, откажет в вызове со слишком большим значением до отправки, и уменьшения с примечанием вы не увидите. Само уменьшение работает у клиентов, которые схему не проверяют.

Обход ограничен по числу записей и по вложенности, и оба предела сообщаются в ответе. Встреченная при обходе символьная ссылка показывается, но внутрь неё обход не идёт; ссылка, названная в subdir, раскрывается, и обход идёт по каталогу назначения, если он остаётся внутри настроенного каталога.

Когда обход был усечён, потому что достигнут предел числа записей, достигнут предел вложенности или подкаталог не удалось прочитать, возраст самого старого файла и счётчик устаревших посчитаны только по показанным записям. В текстовом выводе это видно прямо в строках, которые превращаются в «самый старый файл среди показанных» и «файлов старше N мин среди показанных», а в примечании названо, каким параметром поднять предел. В формате json тот же факт несёт поле aggregates_partial.

Ответ в формате json содержит exists, список entries с полями name, is_dir, is_symlink, size, modified и age_seconds, признаки усечения capped, cap, depth_limited, depth и unreadable_subdirs, а также aggregates_partial, oldest_name, oldest_age_seconds, stale_after_minutes, stale_count и notes.

Границы: инструмент не открывает файлы и поэтому ничего не говорит об их содержимом, об узлах обмена и о том, что именно передавалось. Общий размер каталога и общее число файлов не считаются намеренно: когда сработал предел числа записей, список является началом выборки, и любой «итого» по нему был бы неверен. Возраст считается от даты изменения файла, так что копирование, распаковка архива или перенос каталога, обновляющие дату, обнуляют возраст.

Требует: настроенный каталог обмена (--exchange-drop-root или MCP_1C_EXCHANGE_DROP_ROOT); без него инструмент отсутствует в списке

code_analyze → dependency_graph

Профессиональная

Граф зависимостей объектов

Визуализация связей между модулями конфигурации. Требует предварительного построения кэша командой --build-depgraph.

Параметры:

• object (обязательный) - имя объекта метаданных для анализа зависимостей
• direction - направление обхода: reverse (кто зависит от объекта), forward (от кого зависит объект), both
• depth - глубина обхода графа (1-3)
• format - формат вывода: text, json, mermaid
• edge_types - оставить только связи указанных типов: movement, query, call, subscription и др. (по умолчанию все типы) (v2.22.0)
• min_risk - оставить только связи с риском не ниже указанного: low, medium, high (помогает быстрее находить значимые зависимости в больших графах) (v2.22.0)
• path_glob - ограничить анализ объектами, путь которых в выгрузке подходит под glob (поддерживает *, **, ?); удобно сузить граф до одной подсистемы или каталога (v2.23.0)

Учёт движений регистров полнее: помимо декларативных движений регистраторов учитываются и наборы записей, формируемые программно в коде (v2.22.0).

Имена объектов с выгрузок, созданных на macOS, корректно сопоставляются с узлами графа (нормализация Unicode NFD при загрузке) (v2.23.0).

Требует: --dump + --build-depgraph (предварительное построение кэша)

code_analyze → call_hierarchy

Профессиональная

Иерархия вызовов метода

Кто вызывает метод и кого вызывает он сам (callers/callees): трассировка на уровне методов по всей конфигурации. Помогает оценить влияние правки и проследить цепочки вызовов. Для зависимостей на уровне объектов метаданных используйте dependency_graph.

Параметры:

• method (обязательный) - метод в форме Объект.Метод или Тип.Объект.Метод, например ОбщийМодуль.Расчёты.Пересчитать
• direction - reverse (кто вызывает), forward (кого вызывает), both
• depth - глубина обхода (по умолчанию 2)
• format - text (дерево вызовов) или json

Результат неполный по дизайну: учитываются только квалифицированные вызовы вида Модуль.Метод(); вызовы без префикса и динамические (Выполнить/ЗапуститьМетод) не отражаются.

Требует: --dump + --build-depgraph (граф зависимостей)

code_analyze → arch_boundary (v2.22.0)

Профессиональная

Анализ нарушений границ подсистем (ARCH001)

Находит обращения к служебным общим модулям одной подсистемы из других подсистем, то есть использование внутренней реализации подсистемы в обход её публичного программного интерфейса. Помогает поддерживать чистую модульную архитектуру конфигурации. Анализ выполняется по запросу (опционально, по умолчанию выключен).

Параметры:

• min_confidence - минимальная достоверность находок: high (по умолчанию, только точные нарушения) или medium (также вызовы широко используемых инфраструктурных служебных модулей)
• limit - максимум находок в выводе (по умолчанию 100)
• format - text (по умолчанию) или json

Анализ работает по дереву подсистем дампа: если в дампе нет подсистем, выводится явное уведомление, а не пустой результат.

Требует: --dump + --enable-depgraph (граф зависимостей)

code_analyze → find_modules (v2.23.0)

Профессиональная

Поиск модулей по пути и структурным фильтрам

Быстрый поиск файлов модулей по индексу путей выгрузки: по glob-шаблону пути или по структурным фильтрам. Помогает ориентироваться в большой конфигурации, не обходя полное дерево метаданных.

Параметры:

• path_glob - glob по пути файла относительно корня выгрузки (поддерживает *, **, ?), например Documents/**/*.bsl
• file_ext - фильтр по расширению файла, например .bsl (альтернатива path_glob)
• category - фильтр по категории объекта (русское каноническое имя, например Документ)
• module_type - фильтр по виду модуля, например МодульОбъекта, МодульМенеджера, МодульФормы
• path_depth - фильтр по точной глубине пути (число сегментов)

В ответе возвращается не более 200 путей; общее число совпадений сообщается полностью.

Требует: --dump + --enable-depgraph (индекс путей)

code_analyze → graph_query (v2.23.0)

Профессиональная

Структурные запросы к графу зависимостей

Структурные запросы к графу зависимостей в формате JSON: ищите узлы и пути по шаблону, а не обходите граф от одного объекта. Работает на встроенном кэше графа, без внешних зависимостей.

Параметры:

• query (обязательный) - объект запроса: match (узлы и рёбра), where (дополнительные условия), return с формой результата shape: rows, nodes, count, shortest_paths
• format - формат вывода: json или text

Примеры запросов: какие документы делают движения по конкретному регистру; общие модули, которые никто не вызывает; кратчайшие пути вызовов между двумя объектами; модули с большим числом входящих вызовов; вызовы в обход границ подсистем.

Запрос ограничен по размеру (узлов до 6, рёбер до 5, глубина обхода до 3), это защищает от тяжёлых обходов и держит ответ компактным.

Требует: --dump + --enable-depgraph (граф зависимостей)

code_analyze → goto_definition (v2.25.0)

Профессиональная

Переход к объявлению метода

Место объявления процедуры или функции по выгрузке: модуль, строка, сигнатура и признак Экспорт. Разбор офлайн по выгрузке (--dump), живая база 1С не нужна.

Параметры:

• method (обязательный) - метод в форме Объект.Метод или Тип.Объект.Метод, например ОбщийМодуль.Расчёты.Пересчитать
• format - text или json

Разбор эвристический: анализируются объявления Процедура / Функция в модулях объекта из выгрузки. Динамически формируемые имена, переопределения в расширениях (&Вместо / &Перед / &После) и методы вне указанного объекта не отражаются.

Требует: --dump + --enable-depgraph

code_analyze → find_references (v2.25.0)

Профессиональная

Поиск мест вызова метода

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

Параметры:

• method (обязательный) - метод в форме Объект.Метод или Тип.Объект.Метод, например ОбщийМодуль.Расчёты.Пересчитать
• format - text или json
• path_glob - ограничить поиск объектами, путь которых в выгрузке подходит под glob (поддерживает *, **, ?)

Результат неполный по дизайну: учитываются только квалифицированные вызовы вида Модуль.Метод(); вызовы без префикса и динамические не отражаются.

Требует: --dump + --enable-depgraph

code_read → dossier

Профессиональная

Полное досье объекта одним вызовом

Структура + где используется (used_by) + движения по регистрам (movements) + связанные объекты (related) одним вызовом. Богаче, чем context: значения перечислений и граф связей. Для лёгкого обзора достаточно context.

Параметры:

• object_type + object_name (обязательны) - тип и имя объекта
• depth - глубина графа связей (по умолчанию 1)
• sections - подмножество секций досье (структура, used_by, movements, related)
• format - markdown или json

При отсутствии графа зависимостей возвращается только структура объекта (degraded-режим).

Требует: --dump + --enable-depgraph (для секций графа)

code_read → report_structure (v2.25.0)

Профессиональная

Структура схемы компоновки данных (СКД) отчёта

Структура схемы компоновки данных отчёта из выгрузки: наборы данных (запрос, объект, объединение), параметры и наблюдаемые поля. Анализ read-only, по выгрузке (--dump), живая база 1С не нужна.

Параметры:

• object_name - имя отчёта; если не указано, возвращается список отчётов, у которых есть схема компоновки
• template - подстрока пути макета, если у отчёта несколько схем компоновки (.dcs); по умолчанию выбирается основная DataCompositionSchema.xml
• format - формат вывода: markdown (по умолчанию) или json
• base - имя базы, если подключено несколько

Требует: --dump

code_read → report_search (v2.25.0)

Профессиональная

Поиск по схемам компоновки данных отчётов

Поиск по схемам компоновки данных всех отчётов выгрузки: найти отчёты по имени набора, поля, параметра или ресурса, не открывая каждую схему вручную. Анализ read-only, по выгрузке (--dump).

Параметры:

• filter (обязательный) - строка поиска по схемам компоновки данных отчётов
• search_in - область поиска: dataset, field, parameter, resource или all (по умолчанию all); resource ищет среди полей набора данных
• format - формат вывода: markdown (по умолчанию) или json
• base - имя базы, если подключено несколько

Требует: --dump

code_search → semantic

Профессиональная

Семантический поиск по коду

Устаревший вариант: используйте code_search action=text mode=semantic. Прежний action=semantic будет полностью удалён в одной из будущих мажорных версий.

Поиск по смыслу, а не по тексту. Находит связанный код даже если названия отличаются. Требует флага --enable-semantic при запуске.

Режимы:

• mode: "semantic" - чистый векторный поиск (LSA, Randomized SVD)
• mode: "hybrid" - комбинация BM25 + векторный поиск для максимальной точности

Требует: --dump + --enable-semantic

Архитектурная визуализация

Профессиональная

Mermaid-диаграммы архитектуры конфигурации

Команда --build-archviz строит Mermaid-диаграммы трёх уровней архитектуры: иерархия подсистем и их вложенность, связи документов с регистрами накопления, сведений и бухгалтерии, бизнес-процессы с точками маршрута и BSL-обработчиками.

Опционально диаграммы экспортируются в SVG или JSON. Поддерживается фильтрация по конкретной подсистеме или категории объектов, ограничение количества узлов и пакетный экспорт всех режимов сразу.

Пример запуска:

mcp-1c-pro --build-archviz \
  --arch-viz all \
  --output-dir ./diagrams \
  --dump /path/to/dump

Параметры:

• --build-archviz запустить генерацию диаграмм и выйти
• --arch-viz режим: subsystems, doc-reg, bp или all
• --output-format формат: mermaid, svg или json (по умолчанию mermaid)
• --output-dir каталог для записи файлов (обязателен при --arch-viz all)
• --filter-subsystem ограничить рамки одной подсистемой (рекурсивно по вложенным)
• --filter-category ограничить тип объектов (Документ, РегистрНакопления и т. п.)
• --max-nodes максимум узлов на диаграмме (по умолчанию 100)
• --show-handlers показывать BSL-обработчики на диаграммах бизнес-процессов (по умолчанию включено)

При ответе свыше 1 MiB (env MCP_ARCHVIZ_BUDGET_BYTES) сервер сохраняет артефакт в локальный кэш и возвращает manifest {path, size_bytes, sha256, mime_type}, а AI-клиент читает файл напрямую.

Действия MCP-сервера:

• action: "generate" Профессиональная - построить или обновить кэш диаграмм (подсистемы, Документ-Регистр, бизнес-процессы, JSON)
• action: "get_subsystems" Профессиональная - Mermaid-диаграмма иерархии подсистем
• action: "get_doc_reg" Профессиональная - Mermaid-диаграмма «Документ → Регистр»
• action: "get_bp" Профессиональная - Mermaid-диаграммы бизнес-процессов
• action: "get_json" Профессиональная - JSON-граф архитектуры

Требует: --dump

Настройка LLM провайдера

Профессиональная

Учётные данные YandexGPT или GigaChat для LLM-функций

Четыре функциональности Профессиональной редакции используют внешние LLM API для обогащения результатов: Автогенерация документации (--build-autodoc), Генерация тестов (--build-testgen), Генерация .epf обработок (--build-epfgen) и Навигация по типовым конфигурациям (--build-typicalconfigs).

Поддерживаются два провайдера: YandexGPT (по умолчанию, выбирается флагом --autodoc-provider yandexgpt) и GigaChat (--autodoc-provider gigachat). Учётные данные читаются из переменных окружения и должны быть заданы до запуска.

Переменные окружения:

# YandexGPT (по умолчанию)
export YANDEXGPT_API_KEY=AQVN...
export YANDEXGPT_FOLDER_ID=b1g...

# GigaChat
export GIGACHAT_CLIENT_ID=...
export GIGACHAT_CLIENT_SECRET=...

Где взять учётные данные:

• YandexGPT сервисный аккаунт Yandex Cloud с ролью ai.languageModels.user, API-ключ выпускается в консоли Yandex Cloud, идентификатор каталога указан там же на странице каталога
• GigaChat регистрация в портале разработчика Сбера, после этого выпускаются Client ID и Client Secret для авторизации

Если переменные не заданы, бинарник завершит работу с ошибкой вида --autodoc-provider=yandexgpt требует переменные окружения YANDEXGPT_API_KEY и YANDEXGPT_FOLDER_ID (или аналогично для GigaChat).

Запуск без LLM:

• --testgen-llm-disable генерация только скелетов YAxUnit/Vanessa без LLM-комментариев
• --epfgen-llm-disable генерация бандлов .epf без LLM-обогащения
• --typicalconfigs-llm-disable индексация подсистем без описаний (Markdown-файлы будут пустыми)
• У --build-autodoc отдельного флага отключения LLM нет: автогенерация документации полностью построена на ответах модели и без API-ключей не запускается

Автогенерация документации

Профессиональная

Markdown-описания объектов через YandexGPT или GigaChat

Команда --build-autodoc формирует отдельный Markdown-файл для каждого объекта конфигурации с описанием назначения, реквизитов, табличных частей и связей с другими объектами.

Поддерживаются провайдеры YandexGPT и GigaChat. Результаты кэшируются: повторный запуск регенерирует только изменившиеся объекты, если не задан --autodoc-regen.

Пример запуска:

mcp-1c-pro --build-autodoc \
  --dump /path/to/dump \
  --autodoc-out ./docs/auto \
  --autodoc-provider yandexgpt

Параметры:

• --build-autodoc запустить генерацию документации и выйти
• --autodoc-out каталог для autodoc Markdown-файлов (по умолчанию docs/auto)
• --autodoc-provider LLM-провайдер: yandexgpt или gigachat
• --autodoc-model модель провайдера (например, yandexgpt-lite)
• --autodoc-kinds виды объектов через запятую: all либо Document,Catalog,AccumulationRegister,InformationRegister,Report,DataProcessor
• --autodoc-regen игнорировать кэш и перегенерировать все объекты
• --autodoc-concurrency размер пула воркеров (по умолчанию 4)
• --autodoc-max-input-tokens лимит входных токенов на объект (модуль усекается, по умолчанию 6000)
• --autodoc-rps лимит запросов в секунду к LLM-провайдеру (по умолчанию 5.0)

При ответе свыше 1 MiB (env MCP_AUTODOC_BUDGET_BYTES) сервер сохраняет артефакт в локальный кэш и возвращает manifest {path, size_bytes, sha256, mime_type}, а AI-клиент читает файл напрямую.

Действия MCP-сервера:

• action: "generate" Профессиональная - сгенерировать Markdown-документацию через LLM (нужен настроенный провайдер)
• action: "regenerate" Профессиональная - перегенерировать всё, игнорируя кэш
• action: "summary" Профессиональная - сводка по сгенерированным файлам
• action: "find" Профессиональная - найти Markdown-файл по имени объекта

Требует: --dump + API-ключ выбранного LLM-провайдера (см. Настройка LLM провайдера)

Генерация тестов

Профессиональная

Автоматическая генерация YAxUnit и Vanessa-тестов

Команда --build-testgen анализирует BSL-модули конфигурации и формирует scaffold-тесты YAxUnit для экспортированных процедур и функций (правила TG001-TG019), Vanessa .feature сценарии для taint-находок с критичностью CVSS не ниже Medium (правило TG020), а также файл manifest.json с итогами прогона.

Доступна как разовая генерация (--build-testgen) либо в режиме MCP-сервера (--enable-testgen) для интерактивных запросов от AI-ассистента.

Пример запуска:

mcp-1c-pro --build-testgen \
  --dump /path/to/dump \
  --testgen-framework auto \
  --testgen-output ./tests

Параметры:

• --build-testgen запустить разовую генерацию тестов и выйти
• --enable-testgen включить testgen в режиме MCP-сервера
• --testgen-output каталог для записи тестовых файлов (по умолчанию <dump>/.testgen-output)
• --testgen-framework фреймворк: yaxunit, vanessa, both или auto (выбирается по типу объекта)
• --testgen-rules подмножество правил TG001..TG020 через запятую
• --testgen-regen игнорировать кэш и перегенерировать все тесты
• --testgen-taint-regressions эмитировать Vanessa-регрессии по taint-находкам (правило TG020)
• --testgen-include-bsp генерировать тесты для модулей БСП/SSL
• --testgen-concurrency число параллельных воркеров (по умолчанию min(CPU, 8))
• --testgen-llm-disable отключить обогащение через LLM (работает без API-ключей)
• --testgen-emit-sarif путь для SARIF 2.1.0 отчёта по testgen
• --testgen-audit-trail путь к audit log testgen (по умолчанию <dump>/.testgen-audit.log)
• --testgen-vendor-baseline путь к vendor-baseline дампу для фильтрации стандартных модулей

Действия MCP-сервера (--enable-testgen):

• action: "generate" Профессиональная - генерация тестов по всей кодовой базе (нужен dump_path)
• action: "summary" Профессиональная - сводка: число тестов, покрытие, ошибки
• action: "findings" Профессиональная - список сгенерированных тестов (с фильтрами)
• action: "manifest" Профессиональная - прочитать manifest.json последней генерации

Требует: --dump + API-ключ LLM-провайдера или флаг --testgen-llm-disable (см. Настройка LLM провайдера)

Генерация .epf обработок

Профессиональная

Designer-compatible XML+BSL бандлы внешних обработок 1С

Команда --build-epfgen формирует Designer-compatible XML+BSL бандлы для всех 6 видов внешних обработок 1С: ПечатнаяФорма, ЗаполнениеОбъекта, СозданиеСвязанныхОбъектов, Отчет, ДополнительнаяОбработка, ДополнительныйОтчет. Каждый бандл соответствует БСП-контракту и готов к загрузке Конфигуратором.

Опционально формируются скрипты pack.cmd / pack.sh для сборки бинарного .epf. В config-aware режиме при наличии Configuration.xml LLM может предлагать имена реквизитов, согласованные с метаданными целевой конфигурации.

Доступна как разовая генерация (--build-epfgen) либо в режиме MCP-сервера (--enable-epfgen) для интерактивных запросов от AI-ассистента.

Пример запуска:

mcp-1c-pro --build-epfgen \
  --epfgen-spec ./bundles.yaml \
  --epfgen-pack

Параметры:

• --build-epfgen запустить разовую генерацию бандлов и выйти
• --enable-epfgen включить epfgen в режиме MCP-сервера
• --epfgen-spec путь к YAML/JSON-файлу со списком бандлов (обязательный для --build-epfgen)
• --epfgen-output каталог для записи бандлов и manifest.json
• --epfgen-config-path путь к Configuration.xml для config-aware режима
• --epfgen-regen игнорировать кэш и перегенерировать все бандлы
• --epfgen-pack дополнительно генерировать pack.cmd / pack.sh для сборки .epf через Конфигуратор
• --epfgen-emit-tests эмитировать sibling YAxUnit-тесты через testgen API
• --epfgen-suggest-attrs LLM-подсказки имён реквизитов (требует config-aware + LLM)
• --epfgen-concurrency число параллельных воркеров (по умолчанию min(CPU, 8))
• --epfgen-llm-disable отключить обогащение через LLM (работает без API-ключей)
• --epfgen-emit-sarif путь для SARIF 2.1.0 отчёта
• --epfgen-audit-trail путь к epfgen audit log
• --epfgen-platform-version целевая версия 1С (по умолчанию 8.3.10); контролирует версию формата MDClasses XML

Параметр rule_id (в YAML/JSON-спецификации бандла, а также в MCP-вызове epfgen.generate) принимает идентификаторы из набора EG001-EG020 (полный список встроенных правил).

Изменения спецификации бандла в v2.30.0

Два параметра элемента specs теперь объявлены в схеме инструмента, поэтому AI-ассистент их видит и может осмысленно заполнить. Параметр form_name задаёт имя управляемой формы для тех видов обработок, которые её требуют, и по умолчанию это Главная; пустое значение отключает выпуск формы для правил, допускающих вариант без неё. Параметр print_template_name задаёт имя макета печати и влияет на выбор правила для вида ПечатнаяФорма.

Имена name и form_name теперь проверяются по правилам имён объектов 1С: допустимы буквы, цифры и подчёркивание, не более 80 символов, а пробелы, точки и разделители пути отклоняются. Пустое имя бандла тоже стало ошибкой, тогда как раньше оно давало файл с именем вида DataProcessor..xml. Спецификации, где имя содержит точку или пробел, придётся поправить.

Ключи элемента specs, которых нет в схеме, теперь отбрасываются. Прежде они доходили до генератора, хотя ни один клиент не мог узнать о них из схемы, и меняли содержимое обработки. Вызов по-прежнему выполняется успешно и сообщения об ошибке не возвращает, но такой ключ больше ни на что не влияет, поэтому обработка соберётся со значениями по умолчанию. Проверьте свои вызовы на vid, safe_mode, permissions, platform_version, output_table, skd_scheme, empty_form, has_form, output_pdf, bsp_version, no_form, minimal, print_template_kind, wizard_pages и import_format. Вместо vid пользуйтесь объявленным kind, он работает как прежде, а остальные параметры остаются доступны в файле спецификации при разовом запуске --build-epfgen. Отдельно обратите внимание на safe_mode: обработка, для которой безопасный режим отключали через MCP-вызов, теперь генерируется с включённым безопасным режимом.

Каталог output_dir должен быть каталогом выгрузки зарегистрированной базы или его подкаталогом, как описано в разделе Пути к выгрузкам. Собственный флаг оператора --epfgen-output под это ограничение не подпадает, а документированное значение по умолчанию <текущий каталог>/.epfgen-output теперь работает и в режиме MCP-сервера, а не только в разовом запуске. Ответ действия generate больше не заканчивается абсолютным путём к manifest.json.

Действия MCP-сервера (--enable-epfgen):

• action: "generate" Профессиональная - генерация .epf-бандлов по спецификации
• action: "summary" Профессиональная - сводка последней сборки
• action: "findings" Профессиональная - постраничный список результатов по бандлам
• action: "manifest" Профессиональная - прочитать manifest.json последней сборки
• action: "validate" Профессиональная - разбор спецификаций без эмиссии файлов

Требует: --epfgen-spec для разовой генерации + API-ключ LLM-провайдера или флаг --epfgen-llm-disable (см. Настройка LLM провайдера)

Навигация по типовым конфигурациям

Профессиональная

Автоматическая классификация семейства типовой и индекс подсистема ↔ объект

Команда --build-typicalconfigs определяет семейство типовой конфигурации по сигнатурам метаданных и строит двусторонний индекс подсистема ↔ объект для AI-навигации. Поддерживается распознавание основных линеек: Бухгалтерия предприятия 3.0, Зарплата и управление персоналом 3.1, Управление торговлей 11, Розница, Комплексная автоматизация и ERP.

Объекты классифицируются по правилам TC001-TC020 на shared (БСП/SSL), bp_specific, zup_specific, ut_specific и retail_specific. Поверх классификации детектируются кастомные доработки заказчика поверх типовой конфигурации.

В результате формируется набор артефактов: index.json (подсистема → объекты), reverse.json (объект → подсистемы), manifest.json с метаданными о версии платформы и обнаруженном семействе, а также по одному .md файлу на каждую подсистему с LLM-обогащённым описанием.

В режиме MCP-сервера (--enable-typicalconfigs) AI-ассистент получает доступ к единому tool typicalconfigs с действиями detect (определить семейство), subsystems (список подсистем), lookup (найти объект по имени), reverse_lookup (из объекта в подсистемы) и extension_points (точки расширения).

Пример запуска (разовая индексация):

mcp-1c-pro --build-typicalconfigs \
  --typicalconfigs-dump-path ./dump \
  --typicalconfigs-output ./typicalconfigs-output \
  --typicalconfigs-llm-disable

Пример запуска (MCP-сервер с включённой навигацией):

mcp-1c-pro --enable-typicalconfigs \
  --base main=https://erp.example.com \
  --dump main=./dump

Параметры:

• --build-typicalconfigs запустить разовую индексацию и выйти
• --enable-typicalconfigs включить typicalconfigs в режиме MCP-сервера
• --typicalconfigs-output каталог для index.json, reverse.json, manifest.json и per-subsystem .md файлов
• --typicalconfigs-dump-path путь к dump-каталогу (обязателен при --build-typicalconfigs)
• --typicalconfigs-regen игнорировать кэш и регенерировать индекс
• --typicalconfigs-llm-disable отключить обогащение через LLM (описания подсистем останутся пустыми)
• --typicalconfigs-concurrency размер пула воркеров (по умолчанию min(CPU, 8), значение 0 означает auto)
• --typicalconfigs-emit-sarif путь для SARIF 2.1.0 отчёта
• --typicalconfigs-audit-trail путь к audit log по операциям typicalconfigs
• --typicalconfigs-max-subsystems cap для очень больших дампов (по умолчанию 500); подсистемы свыше cap получают статус truncated
• --typicalconfigs-platform-version целевая версия 1С (по умолчанию 8.3.10)

Требует: API-ключ LLM-провайдера или флаг --typicalconfigs-llm-disable (см. Настройка LLM провайдера)

С версии v2.30.0 параметр dump_path в MCP-вызове должен указывать на каталог выгрузки зарегистрированной базы или его подкаталог, как описано в разделе Пути к выгрузкам; собственный флаг оператора --typicalconfigs-output под это ограничение не подпадает. Тогда же изменилось действие параметра regen в MCP-вызове: он больше не удаляет каталог .cache/typicalconfigs целиком, а убирает внутри него только файл archviz.json, поэтому посторонние файлы, если вы их там держали, теперь переживают регенерацию.

Подавление проверок прагмами typconf:ignore

Чтобы выборочно отключить классификацию или проверки typicalconfigs на уровне отдельной строки или процедуры, используйте комментарии-прагмы в BSL-коде:

// Отключить проверку для конкретной строки:
ВыполнитьСлужебнуюЛогику(); // typconf:ignore

// Отключить проверки в пределах процедуры целиком:
Процедура КастомнаяОбработка() Экспорт
    // typconf:ignore
    // ...тело процедуры...
КонецПроцедуры

Прагма typconf:ignore действует только в области, где она объявлена (на текущей строке или в текущей процедуре) и не отключает классификацию объекта в целом.

code_review: ревью расширений

Профессиональная

Консолидированный инструмент с двумя действиями: review_extension (CFEDiff, структурный diff двух версий .cfe) и base_vs_ext (сверка основной конфигурации с расширением)

Точность и полнота сравнения повышены (v2.19.0): в результатах меньше нераспознанных объектов.

review_extension: структурный diff двух версий расширения .cfe

Замена ручному diff или git-diff бинарных .cfe (которые показывают только «файл изменён»). CFEDiff распаковывает оба расширения, разбирает структуру и выдаёт Markdown-отчёт с детальным сравнением BSL-кода, форм и метаданных.

Для кого:

• 1С-разработчики, работающие с расширениями типовых конфигураций (yaxunit, BIA-Standard и т. д.)
• DevOps-команды с CI/CD pipeline для расширений
• Team leads на code review для PR с изменениями .cfe

Способ 1. Через Claude Code (MCP-инструмент)

В режиме MCP-сервера действие code_review.review_extension принимает пути к двум .cfe и возвращает Markdown-отчёт прямо в чате.

Пример вызова:

{
  "action": "review_extension",
  "base_path": "/repo/master/MyExt.cfe",
  "head_path": "/repo/feature/MyExt.cfe",
  "format": "markdown"
}

Способ 2. CLI для CI и pre-commit

Подкоманда review бинарника mcp-1c-pro запускается из CI или git-hook:

mcp-1c-pro review base.cfe head.cfe --format markdown -o diff.md
echo "exit code: $?"  # 0 = no diff, 1 = diff found, 2 = error

Подходит для:

• pre-commit hook: блокирует PR, если BSL-diff превышает порог
• GitHub Actions / GitLab CI: оставляет рендер diff комментарием на PR
• daily backup-diff: что изменилось со вчера

Готовый шаблон GitHub Actions см. в docs/cfediff/example-workflow.yml репозитория mcp-1c-advanced.

Опциональные флаги

• --format markdown|json|text формат вывода (по умолчанию markdown)
• --ignore-* (11 флагов) фильтры технического шума: trailing whitespace, line endings, BOM, UUID-порядок и т. д.
• --no-watermark убрать водяной знак Trial (доступно только для verified-paid лицензий)
• --diagnostic добавить диагностический zip-пакет (для тикетов поддержки)
• --bug-report PII-safe tar.gz для GitHub-issue submission
• --enable-ibcmd экспериментальная валидация через ibcmd (8.3.27+, опционально)

Что внутри Markdown-отчёта

# CFEDiff
**Base:** path/to/base.cfe (SHA-256 ...)
**Head:** path/to/head.cfe (SHA-256 ...)

## Сводка
- Добавлено: 8 объектов
- Удалено:   1 объект
- Изменено:  9 объектов
- BSL-строк (+/-): 7065 / 238

## Изменённые объекты

### CommonModule РГП_ГлобальныйПоискВызовСервера
@@ -1,20 +1,122 @@
+// @skip-check bsl-legacy-check-pragma-for-unused-method - Баг ЕДТ
 #Область ОбработчикиСобытий
 ...

## Активные фильтры
- IgnoreTrailingWhitespace
- IgnoreLineEndings
...

Поддерживаемые форматы экспорта

CFEDiff умеет читать оба формата:

• Canonical Designer экспорт через 1С Designer DESIGNER /DumpCfg (8.3.x)
• ibcmd-Mac/Linux экспорт через ibcmd config export (8.3.27+)

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

• Trial (14 дней) полный функционал + watermark с датой истечения лицензии
• Pro / verified-paid чистый вывод без watermark, флаг --no-watermark доступен
• Advanced (без Pro) запуск review вернёт subcommand requires Pro edition + exit 2

Текущие ограничения

• Structural diff форм для расширений, выгруженных через ibcmd config export, использует hash-fallback (изменилась форма / не изменилась). Детальный структурный diff форм работает на canonical-выгрузке из Designer.
• Опциональная ibcmd-валидация (флаг --enable-ibcmd, по умолчанию выключена) представляет собой best-effort слой сверки через официальную CLI ibcmd. Сейчас она всегда завершается информационным предупреждением (IBCMD_NOT_AVAILABLE) и не выполняет canonical-сравнение через config export; результат diff от неё не зависит и не блокируется (exit code не меняется).
• Foreign-UUID naming некоторые ChildObjects (CommonModule, заимствованные из других расширений) отображаются как UUID, а не по имени.

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

Действие code_review.base_vs_ext сравнивает основную конфигурацию (XML-дамп) с расширением (XML-дамп) и показывает: собственные объекты расширения с property-level составом и подписками; для заимствованных объектов: переопределённые свойства, добавленные реквизиты и табличные части, перехваты &Вместо / &ИзменениеИКонтроль относительно базы.

Параметры:

• ext_dump (обязательный) - каталог XML-дампа расширения
• base (имя базы) или base_dump (каталог дампа основной конфигурации) - без дампа базы выводятся только собственные объекты расширения
• format - markdown (по умолчанию), json или text

Доступно с v2.17.0.

С версии v2.30.0 каталоги ext_dump и base_dump должны быть каталогом выгрузки зарегистрированной базы или его подкаталогом, как описано в разделе Пути к выгрузкам. Это самое заметное ограничение из всех, потому что расширение обычно выгружают в рабочий каталог разработчика, а запуска из командной строки у этого действия нет. Если сверка перестала работать, зарегистрируйте каталог выгрузки расширения флагом --dump при запуске сервера. На действие review_extension это не распространяется: оно по-прежнему принимает произвольные пути к файлам .cfe.

«Второе мнение»: независимая сверка результатов сравнения

Необязательная рекомендательная проверка, которая не блокирует работу, а лишь обращает внимание на возможные расхождения. Независимо пересчитывает результат сравнения через официальную утилиту 1С ibcmd и сопоставляет его с основным результатом.

Возможность командной строки. Включается флагом перед файлами:

• mcp-1c-pro review --enable-ibcmd <base.cfe> <head.cfe>

Утилита ibcmd ищется в трёх местах по порядку: по значению переменной окружения MCP_1C_IBCMD_PATH, если она задана; затем по имени ibcmd в каталогах PATH; затем в известных каталогах установки платформы 1С. Третий шаг добавлен в версии 2.33.0, до неё просматривались только первые два. Если утилита не найдена, сверка пропускается, а обычное сравнение конфигураций работает как всегда.

Доступно с v2.19.0. Только в командной строке.

Цена: см. тарифы для актуальной стоимости Pro-лицензии.

Подкоманда review. Требует Pro или Trial-лицензию.