Инструменты

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

Массовый анализ кодовой базы, граф зависимостей, архитектурная визуализация, генерация тестов, документации и .epf обработок.

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

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)

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

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

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

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

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

Параметры:

dump_path: путь к каталогу выгрузки (содержит ExchangePlans/); обязателен, если не указан base
plan: опциональный фильтр, показать только план обмена с этим именем
format: формат вывода, text (по умолчанию) или json
base: имя базы, если подключено несколько; источник выгрузки при отсутствии dump_path

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

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

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 (полный список встроенных правил).

Действия 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 провайдера)

Подавление проверок прагмами 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.

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

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

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

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

Утилита ibcmd должна быть доступна в PATH. Если она недоступна, сверка пропускается, а обычное сравнение конфигураций работает как всегда.

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

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

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

Назад Инструменты Расширенной версии Далее Справочник CLI

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

bulk_analyze

update_helper

check_query (v2.25.0)

check_bsl_api (v2.27.0)

explain_rls (v2.27.0)

explain_exchange_plan (v2.27.0)

code_analyze → dependency_graph

code_analyze → call_hierarchy

code_analyze → arch_boundary (v2.22.0)

code_analyze → find_modules (v2.23.0)

code_analyze → graph_query (v2.23.0)

code_analyze → goto_definition (v2.25.0)

code_analyze → find_references (v2.25.0)

code_read → dossier

code_read → report_structure (v2.25.0)

code_read → report_search (v2.25.0)

code_search → semantic

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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