{
  "skill_name": "ai-edt-tools",
  "evals": [
    {
      "id": 1,
      "prompt": "Покажи структуру модуля CommonModules/ОбщегоНазначения/Module.bsl в проекте МойПроект",
      "expected_output": "Список всех процедур и функций модуля с сигнатурами, номерами строк, флагами Экспорт и директивами компиляции",
      "expectations": [
        "Вызван инструмент get_module_structure с параметром projectName=\"МойПроект\"",
        "Передан параметр modulePath=\"CommonModules/ОбщегоНазначения/Module.bsl\"",
        "Ответ содержит список методов с номерами строк и флагами Экспорт",
        "Перед вызовом проверена доступность EDT MCP сервера (get_edt_version)"
      ]
    },
    {
      "id": 2,
      "prompt": "Найди все ошибки уровня CRITICAL в проекте МойПроект для документа РеализацияТоваровУслуг",
      "expected_output": "Список критических ошибок EDT по объекту Document.РеализацияТоваровУслуг с кодами проверок и расположением",
      "expectations": [
        "Вызван инструмент get_project_errors с параметром projectName=\"МойПроект\"",
        "Передан параметр severity=\"CRITICAL\"",
        "Передан параметр objects содержащий \"Document.РеализацияТоваровУслуг\"",
        "Ответ содержит коды проверок (checkId) и расположение ошибок"
      ]
    },
    {
      "id": 3,
      "prompt": "Найди все места где вызывается метод ПолучитьДанныеКлиента в проекте МойПроект",
      "expected_output": "Список всех вызывающих мест метода ПолучитьДанныеКлиента с путями к файлам и номерами строк",
      "expectations": [
        "Вызван инструмент get_method_call_hierarchy с параметром methodName=\"ПолучитьДанныеКлиента\"",
        "Передан параметр direction=\"callers\"",
        "Передан параметр projectName=\"МойПроект\"",
        "Ответ содержит пути к BSL-файлам и номера строк вызовов"
      ]
    }
  ]
}

# AI-EDT: Исследование модели / Исходный код BSL

> Снимок каталога инструментов AI-EDT из его docs (`docs/tools/README.ru.md`) на ревизии
> `4fb31770`, снят 28.07.2026. На момент снятия 118 имен сходились с реестром групп `ToolCategory.java`.
> Снимок НЕ канон и НЕ полон: рабочее дерево проекта уходит вперед (пример - `find_dead_code`, есть в коде,
> нет ни в реестре групп, ни в docs). Актуальный набор инструментов сессии - `tools/list`, каталог операций
> фасада - `operation=help`. Обновлять пересборкой из docs проекта, а не правкой руками.

## Исследование модели

Семантическая модель EDT, документация платформы, объекты метаданных и связи между ними.

| Инструмент | Режим | Назначение |
|---|---|---|
| `get_content_assist` | Чтение | Возвращает подсказки EDT и сведения о типах в позиции BSL. |
| `get_platform_documentation` | Чтение | Ищет методы, свойства и конструкторы типов платформы 1С. |
| `get_metadata_objects` | Чтение | Получает список объектов метаданных с фильтрами. |
| `get_metadata_details` | Чтение | Возвращает реквизиты, табличные части, формы и другие свойства объектов. |
| `find_references` | Чтение | Ищет семантические ссылки на объект в метаданных, формах, ролях и BSL. |
| `object_summary` | Чтение | Формирует компактную сводку по объекту конфигурации. |
| `semantic_metadata_search` | Чтение | Ищет объекты по смысловому описанию, а не только по имени. |
| `list_subsystems` | Чтение | Показывает подсистемы и их состав. |
| `dcs_search` | Чтение | Ищет элементы и выражения в схемах компоновки данных. |
| `docs_lookup` | Фасад · Чтение | Объединяет документацию платформы и встроенную справку объектов 1С. |

## Исходный код BSL

Чтение, изменение и семантическая навигация по модулям.

| Инструмент | Режим | Назначение |
|---|---|---|
| `read_module_source` | Чтение | Читает BSL-модуль целиком или по диапазону строк. |
| `write_module_source` | Изменение | Записывает модуль. Режимы шире, чем replace / append / searchReplace: есть `replaceMethod` (заменяет метод вместе с его ведущей шапкой), `replaceLines` (с проверкой `expectedText`), `insertBefore` / `insertAfter`, `replaceMethods` (несколько методов атомарно). **Перед первой записью в модуль прочитать `rules/edt-bsl-write-safety.md`: голый `replace` перезаписывает модуль целиком и затирает чужой код.** |
| `get_module_structure` | Чтение | Возвращает методы, области, параметры и контексты выполнения. |
| `list_modules` | Чтение | Показывает BSL-модули проекта с фильтрами. |
| `search_in_code` | Чтение | Выполняет текстовый или regex-поиск по BSL. |
| `read_method_source` | Чтение | Читает конкретную процедуру или функцию. |
| `get_method_call_hierarchy` | Чтение | Ищет вызывающие или вызываемые методы. |
| `go_to_definition` | Чтение | Разрешает символ и возвращает место определения. |
| `get_symbol_info` | Чтение | Возвращает hover/type information в позиции BSL. |
| `validate_query` | Чтение | Проверяет синтаксис и семантику запроса 1С. |
| `code_search` | Фасад · Чтение | Объединяет поиск, ссылки, определения, hierarchy и content assist. |

# AI-EDT: Диагностика и проблемы / Аналитика конфигурации / Безопасность и доступ

> Снимок каталога инструментов AI-EDT из его docs (`docs/tools/README.ru.md`) на ревизии
> `4fb31770`, снят 28.07.2026. На момент снятия 118 имен сходились с реестром групп `ToolCategory.java`.
> Снимок НЕ канон и НЕ полон: рабочее дерево проекта уходит вперед (пример - `find_dead_code`, есть в коде,
> нет ни в реестре групп, ни в docs). Актуальный набор инструментов сессии - `tools/list`, каталог операций
> фасада - `operation=help`. Обновлять пересборкой из docs проекта, а не правкой руками.

## Диагностика и проблемы

Ошибки проекта, сводки, статический анализ и состояние самого MCP-сервера.

| Инструмент | Режим | Назначение |
|---|---|---|
| `get_problem_summary` | Чтение | Группирует проблемы по проектам и уровню важности. |
| `get_project_errors` | Чтение | Возвращает детальные проблемы EDT с фильтрами. |
| `code_review` | Чтение | Запускает анализ BSL через настроенный BSL Language Server. |
| `get_mcp_history` | Чтение | Показывает историю последних MCP-вызовов. Запись несет `arbitratedBy` (`tool` / `signal`), `deliveryStatus` (`delivered` / `failed`), у сигнала - `signalType` и `signalNote`; в `stats` - `interrupted` и `undelivered` поверх `success` и `failure`. |
| `self_status` | Чтение | Диагностирует состояние сервера, служб EDT и очереди вызовов. С 0.2.26 перечисляет ВСЕ запущенные экземпляры AI-EDT с их портами, рабочими областями и открытыми проектами - на машине с несколькими EDT только так и понять, какая из них ответила. |
| `diagnostics` | Фасад · Чтение | Объединяет ошибки, сводки, валидацию и справку по проверкам. |

## Аналитика конфигурации

Высокоуровневый анализ структуры и последствий изменений.

| Инструмент | Режим | Назначение |
|---|---|---|
| `dependency_graph` | Чтение | Строит граф зависимостей объектов метаданных. |
| `detect_query_anti_patterns` | Чтение | Ищет производительные и структурные проблемы запросов. |
| `project_metrics` | Чтение | Рассчитывает метрики проекта и состава конфигурации. |
| `compare_configurations` | Чтение | Сравнивает две конфигурации или проекта EDT. Переименования спариваются ДО классификации: объект с равным содержанием (имя и его зеркала - uuid, синоним, идентификаторы типов - вне доказательства) читается как `renamed`, а не удаленный и добавленный; изменившееся сверх того парой не становится. Вложения сравниваются по содержимому, смена типа реквизита видна на `level=attribute`. |
| `impact_analysis` | Чтение | Оценивает последствия изменения или удаления объекта. |
| `extension_diff` | Чтение | Сравнивает расширение с основной конфигурацией. |
| `list_interceptors` | Чтение | Показывает перехватчики методов расширения. |
| `insights` | Фасад · Чтение | Объединяет метрики, графы, сравнение и анализ влияния. |

## Безопасность и доступ

Аудит прав и потенциально чувствительных данных.

| Инструмент | Режим | Назначение |
|---|---|---|
| `audit_role_rights` | Чтение | Анализирует права ролей на объекты конфигурации. |
| `find_rls_violations` | Чтение | Ищет подозрительные или неполные ограничения RLS. |
| `sensitive_data_scan` | Чтение | Ищет потенциальные секреты и персональные данные в коде и метаданных. |
| `security_audit` | Фасад · Чтение | Объединяет аудит ролей, RLS и sensitive-data scan. |

# AI-EDT: Обозначения / Ключевые фасады

> Снимок каталога инструментов AI-EDT из его docs (`docs/tools/README.ru.md`) на ревизии
> `4fb31770`, снят 28.07.2026. На момент снятия 118 имен сходились с реестром групп `ToolCategory.java`.
> Снимок НЕ канон и НЕ полон: рабочее дерево проекта уходит вперед (пример - `find_dead_code`, есть в коде,
> нет ни в реестре групп, ни в docs). Актуальный набор инструментов сессии - `tools/list`, каталог операций
> фасада - `operation=help`. Обновлять пересборкой из docs проекта, а не правкой руками.

## Обозначения

| Метка | Значение |
|---|---|
| **Чтение** | Не должен изменять проект или информационную базу. |
| **Изменение** | Записывает исходники, метаданные, настройки или файлы проекта. |
| **Выполнение** | Запускает EDT/1С, тесты, запросы или код в живой сессии. |
| **Опасно** | Может удалить, импортировать, перезаписать или синхронизировать данные. |
| **Смешанный** | Поведение зависит от выбранной операции или параметров вызова. |
| **Фасад** | Единая точка входа для нескольких родственных операций. |
| **Workshop** | Высокоуровневый конструктор сложного артефакта. |

## Ключевые фасады

Фасады уменьшают размер `tools/list`: вместо набора родственных standalone-инструментов агент видит одну точку входа и выбирает действие через параметр `operation`.

У большинства фасадов встроена справка:

```json
{
  "operation": "help"
}
```

Для подробностей конкретной операции используется `topic`:

```json
{
  "operation": "help",
  "topic": "text_search"
}
```

### `code_search` - поиск и навигация по коду

Операции: `text_search`, `object_references`, `method_references`, `resolve_symbol`, `call_hierarchy`, `symbol_info`, `content_assist`, `outgoing_structures`, `help`.

Используйте фасад для исследования BSL и модели перед изменениями. 
Все операции только читают проект.

У `call_hierarchy` есть `depth`: он уходит дальше непосредственных соседей, до пяти уровней, циклы отбрасываются, а не обходятся по кругу.

У `text_search` `projectName` НЕОБЯЗАТЕЛЕН: без него ищутся все открытые проекты с исходниками, а ответ называет их поименно. Это важно, когда рядом лежат конфигурация и ее расширения - пустой ответ по одному проекту читается как "такого текста нет вообще". Явно названный несуществующий проект остается ошибкой.

### `launch_debugger` - полный цикл отладки

Объединяет запуск/Attach, line и exception breakpoints, `run_to_line`, ожидание suspend, чтение и изменение переменных, stepping, resume, terminate, evaluation и profiling.

Большинство операций требует действующей конфигурации запуска EDT; операции с кадрами требуют приостановленного потока.

`action=launch` открывает в запускаемом клиенте внешнюю обработку или отчет: `externalObjectName` называет объект, `externalObjectProject` - проект внешних объектов, когда это не тот проект, который запускается. Имя, которое не разрешается, останавливает запуск ДО обновления базы, и ответ несет `nothingWasLaunchedOrUpdated`. Произвольного пути к `.epf` у запуска нет - объект разрешается только из проекта внешних объектов, поэтому готовый бинарник сперва заводится в проект через `external_object_workshop operation=import_external_object`, и это ЕДИНСТВЕННЫЙ маршрут.

Среда открывает такой объект, СОБИРАЯ его, поэтому у проекта внешних объектов должна быть включена
генерация дампа. На свежесозданном проекте она выключена, и клиент тогда стартует с пустым экраном.
Запуск отказывает и называет проект; `enableExternalObjectDump=true` включает генерацию для этого
проекта и продолжает запуск.

`debugServerPort` дает запуску свой порт отладочного сервера (1..65535). На машине один порт по
умолчанию на все запущенные среды, и второй начавший отладку получает окно «порт уже используется» -
это способ разойтись. Сохраненная конфигурация запуска не меняется.

Успех ставится только по НАБЛЮДАЕМОЙ живой цели отладки. Отказ называет увиденное - запуск не
создан, завершился сразу, все цели завершены, цель не появилась за десять секунд - и перечисляет
модальные окна, открывшиеся во время запуска.

`action=wait_for_break` ждет **не больше 50 секунд** и 50 по умолчанию, под всеми четырьмя именами
довода (`timeoutSeconds`, `timeoutMs`, `waitSeconds`, `timeout`): один запрос дольше не живет, и
просьба на 300 секунд раньше возвращалась ошибкой транспорта вместо ответа. Урезанное ожидание несет
`timeoutCapped` и `waitedSeconds`; точки останова остаются расставленными, так что ждать дальше -
это следующий вызов.

`action=get_variables` помечает записи, для которых API переменных не отдал значения, полем
`valueNotReturnedByVariables` и считает их: значения читаются по одному - `expandPath=<имя>` (он при
промахе вычисляет имя) или `action=evaluate`. Переменная с пустой строкой не помечается: пустое
значение - это ответ.

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

### `diagnostics` - диагностика и валидация

Операции: `get_project_errors`, `get_problem_summary`, `revalidate_objects`, `clean_project`, `validate_for_export`, `get_check_description`, `help`.

`marker_corrections` стоит рядом с ними отдельным инструментом: он применяет к найденной проблеме то
штатное исправление, которое предлагает сама проверка. Работает в два шага - сначала список доступных
исправлений для находки, затем применение выбранного по его описанию из списка. Нужны `projectName` и
`checkId`. Это не "починить все": исправление есть не у каждой проверки.


### `project_admin` - проекты и рабочее пространство


`list_subsystems` стоит отдельного упоминания: он отдает подсистемы иерархией вместе с составом
(FQN входящих объектов) и признаком, есть ли на диске `CommandInterface.cmi`. Плоский список имен от
`get_metadata_objects` этого не показывает. Наличие или отсутствие `.cmi` инструмент подает как факт,
а не как ошибку - трактовку смотреть в правиле `edt-zip-export-pitfalls.md`.
Три операции требуют оговорки:

- **`resync_to_disk`** сбрасывает модель объектов из памяти EDT на диск. Звать ПЕРЕД
  `update_database` и перед экспортом конфигурации: именно рассинхрон памяти и диска дает класс
  ошибок "валидно в EDT, падает в ИБ" и `zip:///` not-found. Ссылки в `Configuration.mdo` он при
  этом не чистит - это другой дефект. Подробности в правиле `edt-zip-export-pitfalls.md`.
- **`delete_project`** разрушительна. По умолчанию (`deleteContent=false`) проект только
  отключается от рабочей области, файлы остаются на диске и импортируются обратно;
  `deleteContent=true` стирает и файлы.
- **`restart_edt`** перезапускает или гасит саму EDT, внутри которой работает плагин. После нее
  сервер отвечает не сразу.
- **`answer_dialog`** нажимает названную кнопку модального окна, на котором стоит EDT: такое
  окно держит workbench, и снаружи это неотличимо от зависания. Читать окно - `self_status`
  либо поля `blockedByDialog` и `dialogs` в ответе долгой операции со `status=Pending`;
  нажимать - назвав кнопку в `button`. Само по себе не нажимается ничего, а имя, не совпавшее
  ни с одной кнопкой или совпавшее с несколькими, отвергается.


Операции: `list_projects`, `list_configurations`, `get_configuration_properties`, `create_project`, `delete_project`, `resync_to_disk`, `restart_edt`, `answer_dialog`, `list_subsystems`, `help`.

Часть операций изменяет рабочее пространство или перезапускает EDT.

**История вызовов.** `get_mcp_history` отдает список последних вызовов, урезанный до нескольких сотен
знаков на запись: буфер живет в куче самой среды. Полный текст лежит рядом на диске - довод `entryId`
из записи списка отдает ОДИН вызов целиком, с полными доводами и полным ответом, замаскированными так
же, как в журнале. Запись, которой в кладовой больше нет, получает названный отказ, а не урезанную
копию под видом полной; `entryId` вместе с `clear` отвергается. Что хранится на диске, задается на
странице настроек в группе «Call history on disk»: хранить ли полный текст, сколько дней хранить (14
по умолчанию, ноль - до предела размера) и в какой папке. При выключенной записи вызовов на диск не
пишется ничего.

### `infobase_admin` - жизненный цикл информационной базы

Объединяет `get_applications`, `read_event_log`, `create_infobase`, `delete_infobase`, `set_infobase_credentials`, `create_launch_config`, `start_client`, `update_database`, `branch_infobase`, `sync_control` и встроенную справку. С `dryRun=true` ничего не запускается: ответ несет состояние обновления (`updateState`), признак `wouldUpdate`, готовность базы (`readiness`) и ее проблемы (`readinessProblems`). Прогон не записывается, база не занимается. Состав изменений по объектам так недостижим, и ответ говорит это в `composition`.

`branch_infobase` связывает ветку git с приложением проекта, после чего `update_database` отказывается обновлять базу, привязанную к другой ветке. У проекта-РАСШИРЕНИЯ привязка лежит в самом расширении, а не в конфигурации, которую оно расширяет.

`read_event_log` (с 0.2.27) читает журнал регистрации ФАЙЛОВОЙ базы - кто входил, что проводилось, что платформа отвергла, - с отбором по `from` / `to` / `event` / `user` / `severity`. Серверная база и однофайловый SQLite-формат `1Cv8.lgd` отвечают именованным отказом, а не пустым списком.

**`start_client`** запускает клиент 1С:Предприятие из конфигурации запуска EDT, без отладчика.
Плагин прямо просит звать его ВМЕСТО сборки командной строки `1cv8.exe` руками: версия runtime,
база, вид клиента и пользователь берутся из настроек среды, а не собираются агентом по памяти.

**`create_launch_config`** привязывает СУЩЕСТВУЮЩУЮ базу к проекту - создать ее заранее должен
`create_infobase`. Привязка идет как несинхронизированная, поэтому сразу после нее
`get_applications` честно сообщит, что базу нужно обновить.

**`delete_infobase`** по умолчанию убирает базу только из списка EDT; `deleteContent=true`
удаляет и каталог `.1CD` с диска - необратимо. **`set_infobase_credentials`** хранит пароль
зашифрованным, в ответ отдает лишь признак `passwordStored`, в журнал пароль не попадает.


`update_database` по проекту-РАСШИРЕНИЮ обновляет базу той конфигурации, которую расширение расширяет, и `applicationId` для этого не нужен: без него берется приложение по умолчанию - свое, затем родительское. Отказ называет тех держателей базы, кого сервер видит (клиенты, запущенные EDT, и соседние экземпляры AI-EDT), и честно говорит, кого он видеть не может.

### `config_io` - импорт и экспорт

Объединяет `export_configuration_to_xml`, `import_configuration_from_xml`, `export_object` и `export_common_picture`.

Сюда же относятся два входа для бинарников, и у обоих есть аналог среди скилов набора - выбор зависит
от того, нужен ли на выходе EDT-проект:

- **`import_configuration_from_binary`** принимает `.cf` или `.cfe` одним файлом и разворачивает его в
  НОВЫЙ проект EDT: бинарник грузится во временную базу, выгружается в Designer-XML и импортируется
  оттуда, временная база потом удаляется. Существующее имя проекта отвергается, чужую базу инструмент
  не трогает. Запускает толстый клиент, поэтому нужен доступный runtime платформы, а на большой
  конфигурации занимает минуты. Если проект EDT не нужен, а нужны просто исходники - это `v8unpack-cf`,
  он распаковывает бинарник без платформы. `1c-db-load-cf` сюда НЕ подходит: он грузит `.cf` в базу,
  а не разбирает его на файлы.
- **`unpack_external_binary`** превращает внешнюю обработку или отчет (`.epf` / `.erf`) в Designer-XML,
  который затем скармливается `import_configuration_from_xml`. Нужен, когда файл пришел со стороны и
  проекта под него еще нет. База, названная в `projectName` / `applicationId`, только предоставляет
  процесс Конфигуратора - ее конфигурация не читается и не меняется. Целые конфигурации и расширения
  инструмент НЕ принимает: их конвертация означала бы загрузку в базу поверх того, что там лежит.
  Разобрать `.epf` без EDT и без платформы умеет скил `1c-epf-dump`.


### `insights` - аналитика конфигурации

Операции: `project_metrics`, `dependency_graph`, `compare_configurations`, `compare_three_way`, `detect_query_anti_patterns`, `generate_health_snapshot`, `impact_analysis`, `object_summary`, `semantic_metadata_search`, `help`.

`compare_three_way` сравнивает открытый проект с новой поставкой И с поставкой, от которой обе произошли, - это и есть обновление на поддержке. Двух сторон там мало: у доработанной конфигурации отличается почти все, а важно, КТО изменил. Отвечает числом узлов, сколькими различаются, сколько односторонних, ИМЕНАМИ измененных объектов на каждой стороне и списком проблем с пометкой блокирующих. Решения по объектам (`decisions`) записываются на сравнение и выгружаются в файл, который EDT читает обратно. **По умолчанию только читает.** `intent=MERGE` применяет решения к проекту - НЕОБРАТИМО; без решений отклоняется, а проверку выполняет само окружение и при блокирующей проблеме останавливается до записи (пройти дальше - отдельное значение `MERGE_IGNORING_PROBLEMS`, не флаг). Поле `merged` говорит, что произошло на самом деле, а не о чем попросили.

`describe_db_tables` (доступен и отдельным именем) показывает, во что объект превращается в базе
данных: основную таблицу, по одной на каждую табличную часть, виртуальные таблицы регистра (остатки,
обороты, срезы) с их параметрами, таблицу изменений, перерасчеты регистра расчета. Имена таблиц и полей
отдаются на двух языках, с типами, готовыми к подстановке после `ИЗ`. Звать ДО написания запроса: за
один вызов видно все, что можно выбрать, вместо перебора имен по одному через `validate_query`.

Все операции только читают проект.

### `security_audit` - аудит безопасности

Операции: `audit_role_rights`, `find_rls_violations`, `sensitive_data_scan`, `help`. Читают проект все, КРОМЕ одной.

`audit_role_rights mode=orphans` - единственная пишущая: перечисляет права роли на объекты, которых в конфигурации больше нет, и при `apply=true` их удаляет. Решение трехзначное - удаляется только то, про что удалось доказать, что объекта нет; неразрешенное перечисляется отдельным списком и не трогается. Под пресетом без права записи `apply=true` отклоняется.

### `workspace_marks` - метки рабочего пространства

Объединяет `get_tags`, `get_objects_by_tags`, `get_bookmarks`, `get_tasks` и встроенную справку.

### `docs_lookup` - документация платформы и объектов

Объединяет `get_platform_documentation`, `get_object_help`, `system_enum_values` и встроенную справку фасада.

`system_enum_values` отвечает на вопрос, что можно написать после точки: `ВидДвиженияНакопления` -> `Приход`, `Расход`. Ошибка здесь не ловится редактором - неизвестный член системного перечисления это ошибка времени исполнения. Значения приходят с обоими именами, поле `valuesFrom` называет тип, из которого прочитано (он НЕ совпадает с тем, что спросили: значения лежат на парном типе-менеджере).

`get_object_help` читает встроенную справку объекта конфигурации - те страницы, что открываются
кнопкой "?" в интерфейсе. Отвечает markdown, язык выбирается параметром. Ценность для агента не в
самой справке, а в том, что она объясняет БИЗНЕС-СМЫСЛ объекта; читать ее стоит до правки чужой
типовой, чтобы не переделать то, что работает как задумано.


### `yaxunit_tests` - запуск и отладка YAxUnit

Поддерживает обычный запуск и debug-режим. Требует установленного расширения YAxUnit и конфигурации запуска целевой ИБ.

Прогон асинхронный: инструмент опрашивает запуск ограниченное время (по умолчанию 60 секунд) и
отдает отчет в формате JUnit. Если за окно опроса запуск не закончился, ответ будет **Pending** -
это не ошибка, надо позвать тот же инструмент с теми же аргументами еще раз.


### `edit_metadata` - универсальный конструктор метаданных

Содержит около 160 операций, разбитых на домены:

- объекты и их вложенные элементы;
- специализированные типы метаданных;
- командный интерфейс;
- HTTP- и SOAP-сервисы;
- управляемые формы;
- макеты;
- карта маршрута бизнес-процесса;
- расширения;
- СКД;
- общие пакетные и служебные операции.

Поддерживает `dryRun`, пакетное выполнение и `operation=help`. Полный список следует получать из встроенной справки, поскольку это самая быстро меняющаяся часть API.

Три вещи, которые из общего списка не видны:

- **`extend_object_type`** (с 0.2.26) добавляет тип объекту, ЗАИМСТВОВАННОМУ расширением, со состоянием `Extended`, не трогая унаследованные. Для такого объекта `set_object_type` не подходит в принципе: состав типов заимствованного объекта живет в блоке расширения, а не в обычном свойстве, и `set_object_type` там писал в никуда, отвечая "применено".
- **`operation=help topic=parameters`** (с 0.2.28) отдает полные правила тех параметров, чье описание в схеме сокращено до одной строки. Параметров не убавилось - убавилось прозы в каталоге, который клиент возит с собой в каждой сессии.

- **`copy_object`** копирует объект в другой проект как СОБСТВЕННЫЙ, а не заимствованный. Разница с
  `extension_workshop borrow_object` принципиальная: заимствование ПЕРЕХВАТЫВАЕТ типовой объект,
  копирование его ПОВТОРЯЕТ. Для объекта, который в основной конфигурации уже есть, нужно
  заимствование. Копированием занимается сама EDT, поэтому идентификаторы, неконфликтующее имя,
  членство в подсистемах и описания типов она берет на себя; выбранное ею имя возвращается в ответе -
  оно не обязано совпадать с исходным. Ссылки на объекты, которых в целевом проекте нет, НЕ
  разрешаются, поэтому копию после переноса надо валидировать.

### `dcs_workshop` - схема компоновки данных

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

`repair_schema` (через фасад - `edit_metadata operation=repair_report_schema`) восстанавливает схему из `.dcs` в модель, когда макет в EDT открывается с «Схема недоступна», а файл цел. Доводы: `projectName`, `objectName`, `templateName` (по умолчанию - основная схема владельца на языке конфигурации), `overwriteModel`, `dryRun`. Файл не изменяется. `outcome`: `restored` (в модели схемы не было), `matched` (модель уже совпадает с файлом, ничего не изменено), `refused_model_differs` (в модели другая схема - заменяется только с `overwriteModel=true`, и тогда ее сериализация пишется в `backupPath` рядом с `.dcs`), `replaced`, `file_changed` (файл изменился между чтением и подключением - повторить), `no_template`, `no_file`. `success=true` только при `confirmed=true` - модель после фиксации сериализуется в байты файла, иначе `confirmation` называет причину. `dryRun=true` решает и отвечает, ничего не меняя.

### `mxl_workshop` - табличный макет MXL

Управляет областями, ячейками, объединением, оформлением, шириной, высотой и рисунками табличного документа. Поддерживает preview через `dryRun`.

`format_cells` задает на диапазоне перенос текста (`textPlacement`), поворот (`textOrientation`), высоту строки, ширину и автоширину колонки и вес колонки при распределении ширины. Формат ищется среди существующих и добавляется, только если такого нет: в `.mxl` форматы общие и адресуются индексом.

### `extension_workshop` - расширения конфигурации

Объединяет установку, удаление, просмотр и экспорт расширений, lifecycle-сценарии, сравнение с основной конфигурацией и список перехватчиков, а также заимствование: `borrow_object`, `borrow_child`, `borrow_form_item`, `borrow_module`, `borrow_objects`.

Операции над УСТАНОВЛЕННЫМ в базу расширением (`install_extension`, `uninstall_extension`,
`list_extension`) идут через платформу, поэтому у них три условия сразу: доступный runtime,
сохраненные учетные данные (`set_infobase_credentials`) и НЕзаблокированная база - запущенный
клиент 1С держит ее и не дает работать. Удаление расширения из базы разрушительно.
`list_interceptors` и `extension_diff` работают с исходниками расширения и платформы не требуют.


**С 0.2.26 заимствование дописывает связку с типовым объектом** - `extendedConfigurationObject` у корня и в блоке расширения, плюс отметку переопределения модуля. Без нее расширение не переопределяет ничего, а EDT молчит: до этой правки заимствование отвечало успехом, и проект выглядел здоровым. Отсюда три следствия для агента:

- заимствование, которое не смогло дописать связку, **больше не отвечает успехом** - оно называет причину; руками `.mdo` не править;
- **повторный вызов чинит** объект, заимствованный прежней сборкой (раньше второй вызов коротко отвечал "уже заимствовано");
- `borrow_module` **требует `moduleType`** там, где у объекта модулей несколько: у общего модуля отметка лежит в `module`, у справочника - в `objectModule` / `managerModule`, у регистра - в `recordSetModule`. Не назвали вид - отказ перечислит те, что есть.
- `borrow_form_item` заимствует ФОРМУ, которая несет элемент: у элемента формы своего адреса в модели нет. Форму называют доводом `formName` рядом с владельцем либо полным адресом в `objectFqn` (`Catalog.X.Form.ФормаЭлемента`); без названной формы вызов отказывает и не заимствует ничего. То же у `edit_metadata operation=adopt_form_item`, где форму называют `childKind=Form` и `name`.

### `xdto_workshop` - XDTO-пакеты

Создает пакеты, пространства имен, типы объектов, свойства и типы значений XDTO.

### `external_object_workshop` - внешние отчеты и обработки

Создает исходную структуру внешнего отчета или обработки и возвращает созданные артефакты проекта.

`import_external_object` добавляет `.epf` / `.erf` в существующий контейнер: `targetProjectName`, `inputPath`, `baseProjectName` (конфигурация; по умолчанию родитель контейнера), `applicationId` (когда у конфигурации несколько приложений - см. `get_applications`). Бинарник преобразуется через Конфигуратор базы этого приложения, как в `unpack_external_binary`: EDT отпускает базу и берет ее обратно; отказ отпустить - отказ импорта (`infobaseNotReleased`), отказ вернуть - поле `reconnectError` в ответе при любом исходе импорта. Ответ несет `hostProject` и `infobaseName`.

### `support_registry` - реестр поддержки поставщика

Читает, от каких конфигураций поставщика происходит эта, с их релизами, сколько объектов в каждом
режиме поддержки, какие правила среда применит на следующем обновлении, и режим одного объекта
вместе с объектами, которые среда потребует изменить вместе с ним. Операции: `status`,
`list_objects`, `object_mode`, `snapshot_modes`, `restore_modes`, `help`.

Режим - это то, что ОБЪЯВЛЕНО для объекта (`ChangesNotAllowed`, `ChangesAllowed`, `CANCELLED`), а не
утверждение, что объект изменен; на второй вопрос отвечает `compare_three_way`. Расхождение этих
двух и есть опасное место: объект изменен, а режим остался `ChangesNotAllowed` - следующее
обновление поставщика затрет доработку.

`object_mode` принимает адрес потомка (`Catalog.Товары.Attribute.Автор`) и вложенной подсистемы
(`Subsystem.А.Subsystem.Б`); зависимые объекты названы адресами, а не идентификаторами, и страница
берет `offset` и `limit` (`dependentsTotal`, `dependentsShown`, `dependentsMore`). Когда объект
числится в режиме `ChangesAllowed`, а редактировать его нельзя, ответ объясняет расхождение.

`snapshot_modes` записывает в файл, какой объект какой режим держал - этим объединение и делается
обратимым: обновление берет модель поддержки из поставки, и никакое правило объединения этому не
мешает. `restore_modes` возвращает записанное обратно и единственный здесь меняет конфигурацию:
без `apply=true` он только сообщает, что сделал бы.

### `external_data_source_workshop` - внешние источники данных

Создает внешний источник данных, таблицы, поля и связанные параметры подключения.

# AI-EDT: ошибки, троттлинг и грабли

Накопленный практикой разбор сигналов и обходов. Каталог инструментов - остальные файлы `references/`.
Имена сверялись с реестром проекта на ревизии `4fb31770` (28.07.2026); полноты снимок не гарантирует -
актуальный набор сессии смотреть в `tools/list`.

Принцип: НЕ ретраить вслепую, читать тег и текст сообщения. Лимиты повторов и терминальное поведение заданы
в `rules/mcp-tool-priority.md` (раздел "Троттлинг и ошибки") - здесь числа не повторяются, чтобы не разошлись.

## Реакция на сигналы в ответе

| Сигнал в ответе | Что значит | Действие |
|-----------------|-----------|----------|
| `Pending` + `runKey` | долгая операция (find_references на крупном объекте, yaxunit, export_object) | повторить ТОТ ЖЕ вызов с тем же `runKey` и параметрами (фильтры не менять) - заберет финал |
| `cancelled` в ответе | обход остановлен клиентом (`notifications/cancelled`) или кнопкой оператора: `find_dead_code`, `detect_query_anti_patterns`, `sensitive_data_scan`, `find_rls_violations`, `project_metrics`, `dependency_graph`, `semantic_metadata_search`, `find_references` останавливаются на границе и отдают найденное | не читать пустой список как «находок нет» - в ответе написано, что обход остановлен. У `project_metrics` рядом стоит `partial=true` и `unscannedModules`, числа являются нижней границей, а разделы `objects`, `errors`, `forms`, шаг которых не выполнялся, отсутствуют, а не равны нулю |
| timeout на большом конфиге | нет фильтра либо Xtext-индекс не успел | сузить `metadataType` / `fileMask`; для find_references - `skipBsl=true` либо `timeoutSeconds=60` + retry |
| `BSL model is not available ... indexed` | семантическая модель НЕ построена ЛИБО неверный `modulePath`/FQN | сперва проверить путь: неверный дает ту же ошибку, а модель работает и на модулях 25k+ строк. Если правда не построена - `Read` (`src/.../ObjectModule.bsl`), `Grep` точечно |
| `propertyMismatch` (+ `mismatches`) | объект уже есть, свойства не совпали | НЕ ретраить create/add; пройти `set_object_property` по каждому из `mismatches` |
| `requiresCascadeForms` (+ `affectedForms`) | удаление поля затронет формы | посмотреть preview, подтвердить деструктив, повторить с `cascadeForms=true` |
| `mxlApiNotFound` / `rightsApiNotFound` / `adoptServiceNotFound` / `exportApiNotFound` | несовместимый EDT runtime | НЕ циклить; сообщить пользователю, предложить GUI-fallback |
| `dcsFactoryMethodNotFound` (+ `triedMethods`) | СКД-операция не нашла нужный EDT factory-метод | структурная диагностика, не ошибка реализации; сообщить, предложить GUI-fallback для настройки СКД |
| `kindMismatch` (export_object) | outputPath не совпал с типом объекта | поправить `.epf` vs `.erf` по nature |
| `RuntimeCoreException: Файл не обнаружен 'zip:///...'` | экспорт в ИБ: нет исходника (.cmi/.form/.mdo) | правило `edt-zip-export-pitfalls.md`: создать минимальный валидный + `clean_project` |
| tool disabled / not found | пресет скрыл инструмент либо его нет в сборке | НЕ обходить; сказать пользователю (сменить пресет, обновить плагин) |
| `401 Unauthorized` от `/mcp` при живом `/health` | включен флажок Require bearer token (по умолчанию выключен), а клиент не передает bearer-токен или передает не тот | токен - на странице Window > Preferences > AI-EDT, поле Bearer token; прописать в конфигурацию клиента заголовком `Authorization: Bearer <токен>`, либо снять флажок на той же странице (сервер на всех интерфейсах требует токен всегда). Без токена сервер не отвечает никому, обходить нечем. `404` с текстом про `/mcp` на `/register` или `/.well-known/...` - клиент после `401` ищет OAuth-сервер; лечится тем же токеном |
| любой "not available" в начале сессии | сервер `ai-edt` не отвечает - причина пока неизвестна | `get_edt_version` как проба. Ошибка связи или timeout - `self_status` НЕ вызывать (он на том же сервере), диагноз "ai-edt недоступен". Сервер ответил, но операция не прошла - уточнить через `self_status`. Разбор случаев и что при этом можно продолжать - `rules/mcp-tool-priority.md`, раздел "Когда инструменты недоступны" |

## Троттлинг (анти-циклы)

Числовые лимиты заданы в `rules/mcp-tool-priority.md`, раздел "Троттлинг и ошибки" - единственный источник,
здесь не дублируются, чтобы значения не разошлись. Смысл: цикл редактирования - одна итерация по одному
файлу или задаче; после 2 неудачных попыток исправить одну и ту же ошибку одним подходом подход меняется, а
не повторяется.

## Самокоррекция по тексту ошибки

Инструменты подсказывают сами: неверное enum-значение возвращает "did you mean" со списком валидных,
пропущенный обязательный параметр - "X is required. Example: ...". Читать текст ошибки, а не гадать.
Токены операций нормализуются: camelCase и snake_case работают оба.

## Сверять существование фичи ДО ручного обхода

Частая ошибка: агент городит ручной обход (правка `.mdo`/`.form` через Write, Python-скрипт, десятки
парных вызовов) того, что в плагине УЖЕ ЕСТЬ. Перед любым ручным обходом:

1. `edit_metadata operation=help` - каталог операций.
2. `edit_metadata operation=help topic=availability` - что доступно на текущем runtime.
3. Профильный фасад: `project_admin`, `infobase_admin`, `config_io`, `diagnostics`, `insights`,
   `security_audit`, `docs_lookup`, `extension_workshop`, соответствующий `*_workshop`.

Массовое создание - `edit_metadata batch=true` с массивом `operations` (38 ролей = ОДИН вызов, не 38 пар).
Внешние обработки - `external_object_workshop` + `edit_metadata` по FQN. Правка форм - form-операции
`edit_metadata`, а не Write в `.form`.

## Большие конфигурации (УХ, ERP, УТ) - частичная индексация

- Поиск по всему проекту БЕЗ фильтра дает timeout. Всегда сужать: `metadataType` (`commonModules`,
  `documents`, ...) либо `fileMask`.
- СНАЧАЛА пробовать `get_module_structure` / `read_method_source` - они работают на модулях 25k+ строк и
  дают точные границы методов дешево по токенам. НЕ уходить в Grep+Read превентивно из-за размера модуля.
  Падать в `Read`/`Grep` только при ФАКТИЧЕСКОЙ ошибке "BSL model is not available".
- Номера строк из grep по BSL - строка совпадения, а НЕ граница метода. Границы брать из
  `read_method_source`.
- Путь модуля при кириллице в имени: `Glob` капризничает на цифрах и кавычках в пути, надежнее
  `Bash find -ipath "*Фрагмент*ManagerModule.bsl"`.

## sync_control - синхронизация EDT и ИБ

Решение принимает EDT: сравнивает UUID конфигурации проекта с `configurationUUID` в baseline
`%APPDATA%\.1cedt\ib-sync\ss\<UUID-ИБ>\index.idx`. Не совпало или baseline нет - выгрузка ПОЛНАЯ.

- `operation=status` - read-only, предсказывает FULL/INCREMENTAL для следующего обновления ИБ и причину.
- `operation=diagnose` - read-only, по КАЖДОМУ baseline: `equalityState` + `predictedUpdateState`. Все
  NOT_EQUAL при "импорт: изменений нет" означает разошедшиеся подписи ресурсов (типично после переимпорта
  ДТ: контент тот же, подписи сдвинулись) - дельта считается как весь конфиг и срывается в FULL. Глубже
  `status`, который может дать оптимистичный INCREMENTAL по любому подходящему baseline.
- `operation=suppress` (`enabled=true/false`, обратимо) - гейтит ТОЛЬКО фоновую авто-синхронизацию. Явные
  и принудительные действия (ручное "Обновить конфигурацию ИБ", "Обновить конфигурацию перед экспортом" при
  .cfe-экспорте, pre-launch диалог) НЕ гейтит.
- `operation=mark_synchronized` - пересчитывает SHA-256 всех ресурсов как текущее состояние и пишет
  baseline: EDT считает ИБ равной проекту, дельта нулевая.
- `operation=reseed_baseline` (`infobaseUuid` из status + `confirm=true`) - перештамповывает
  `configurationUUID` в baseline под UUID проекта, сохраняя подписи ресурсов.

**Железное правило: `mark_synchronized` и `reseed_baseline` - ТОЛЬКО по явной команде пользователя, НИКОГДА
автономно.** Обе делают EDT уверенной, что ИБ равна проекту; если реальная дельта есть, EDT молча пропустит
настоящие изменения. Только пользователь знает, что не менялось. `status` / `diagnose` / `suppress`
безопасны.

## Грабля .cfe-экспорта расширения в файловую ИБ (падение на 4 ГБ)

Диалог EDT "Сохранить конфигурацию в файл" форсит "Обновить конфигурацию перед экспортом" (серый и
отмеченный чекбокс, когда ИБ не равна проекту) -> full -> ConfigSave основной конфигурации > 4 ГБ. Лимит
файлового режима действует на ОДИН внутренний файл внутри `.1CD`; дело в размере КОНФИГУРАЦИИ (основная плюс
поставщика плюс макеты), а не данных. GUID в тексте ошибки - UUID конфигурации, не таблица данных.
`suppress` не спасает.

Обход: EDT -> выгрузить расширение в XML-файлы -> Конфигуратор: Расширения -> Загрузить конфигурацию из
файлов + F7 (обновление только расширения) -> Сохранить расширение в файл (.cfe). Насовсем лечит
клиент-серверная ИБ.

## Анти-паттерны edit_metadata

- В extension-проекте при создании CommonModule НЕ передавать `privileged=true` и НЕ комбинировать
  `global=true` с `server=true` - early-fail.
- В EventSubscription `handler` передавать полной формой `CommonModule.X.Method` либо короткой
  `X.Method` (префикс добавится сам), но НЕ просто `Method` - невозможно резолвить.
- `delete_metadata_object` НЕ резолвит FQN XDTOPackage - чистка через файловую систему.

## Данных живой базы у плагина нет

**У AI-EDT нет доступа к данным информационной базы - ни в отладке, ни вне ее.** Инструменты `browse_data`,
`execute_query` и объединявший их фасад `data_access` из плагина удалены (в тестах это зафиксировано строкой
`data_access removal dropped execute_query, browse_data and data_access`). Их имена еще встречаются в старых
заметках - звать их бесполезно, ответом будет "unknown tool".

Единственный маршрут к данным живой базы - **скил `1c-mcp-toolkit` (обработка по HTTP)**. Из приостановленной debug-сессии плагин отдает состояние исполнения:
`get_variables`, `set_variable`, `evaluate_expression`, `get_stack` - это про переменные и выражения текущего
кадра, а не про таблицы базы.

**Исключение, появившееся в 0.2.27, - журнал регистрации.** `infobase_admin operation=read_event_log`
читает журнал ФАЙЛОВОЙ базы прямо из плагина. Это не обход правила выше: журнал лежит файлами рядом с
базой и читается без платформы, тогда как таблицы базы по-прежнему недоступны. Серверная база (журнал на
сервере) и однофайловый SQLite-формат `1Cv8.lgd` отвечают ИМЕНОВАННЫМ отказом - пустой список над базой,
полной событий, читался бы как "событий нет".

## Заимствованный объект: два места, где ответ раньше врал

**`set_object_type` на САМОМ заимствованном объекте НЕ ПИШЕТ НИЧЕГО и отвечает `applied:true`.**
Речь именно о составе типов объекта; смена типа его РЕКВИЗИТА через child-FQN
(`ownerFqn=<владелец>.Attribute.<имя>`) работает и запрету не подлежит. Замерено:
файл не менялся, проверка тремя каналами. Состав типов заимствованного объекта живет в блоке расширения
(`extension/typeExtension`), обычного свойства типа у него нет вовсе. Правильный инструмент -
**`edit_metadata operation=extend_object_type`** (с 0.2.26): ДОБАВЛЯЕТ тип со состоянием `Extended`,
унаследованные (`Checked`) не трогает. Семантика замены сюда не подходит в принципе - заменять нечего.

**Заимствование до 0.2.26 не дописывало связку** с типовым объектом, и расширение молча ничего не
переопределяло при нулевых ошибках проекта. Теперь связка пишется, а заимствование, которое не смогло ее
дописать, отвечает отказом с причиной. Объект, заимствованный старой сборкой, **чинится повторным вызовом
`borrow_*`** - руками `.mdo` не править.

## Изоляция тяжелых выборок и баги плагина

Оба сюжета описаны в `rules/mcp-tool-priority.md` (разделы "Экономия контекста" и "Баги плагина AI-EDT") -
здесь не дублируются. Коротко: тяжелые выборки уводить в субагента (модель для BSL-разведки - Sonnet или
выше), а найденный дефект плагина заносить строкой в свой кросс-сессионный инбокс обратной связи
(отдельный файл вне репозитория, чтобы находки не терялись между сессиями).

# AI-EDT: Информационная база и запуск / Отладка и профилирование

> Снимок каталога инструментов AI-EDT из его docs (`docs/tools/README.ru.md`) на ревизии
> `4fb31770`, снят 28.07.2026. На момент снятия 118 имен сходились с реестром групп `ToolCategory.java`.
> Снимок НЕ канон и НЕ полон: рабочее дерево проекта уходит вперед (пример - `find_dead_code`, есть в коде,
> нет ни в реестре групп, ни в docs). Актуальный набор инструментов сессии - `tools/list`, каталог операций
> фасада - `operation=help`. Обновлять пересборкой из docs проекта, а не правкой руками.

## Информационная база и запуск

Работа с приложениями, информационными базами, расширениями, тестами и живыми данными.

> [!CAUTION]
> Инструменты этой группы могут запускать 1С, изменять ИБ или перезаписывать конфигурацию. Перед операциями **Опасно** сделайте резервную копию.

| Инструмент | Режим | Назначение |
|---|---|---|
| `get_applications` | Чтение | Показывает приложения и информационные базы проекта. |
| `list_configurations` | Чтение | Возвращает клиентские и Attach-конфигурации запуска EDT. |
| `update_database` | Опасно | Обновляет конфигурацию информационной базы. С `statusOnly=true` читает отслеживаемые обновления вместо запуска: `updates[]` с `runKey`, состоянием и прогрессом, отбор по `projectName`; ничего не запускает и не забирает готовый результат, ключ чужого вида работы отвергается. |
| `debug_launch` | Выполнение | Запускает клиент или подключается к серверу отладки 1С. `startupOption` - строка `/C` для клиента (autostart, /Execute, адрес отладчика), пишется в копию конфигурации запуска, сохраненная не меняется; Attach-конфигурация и уже запущенный без них сеанс ее отвергают. `waitForEndpoint` с `endpointTimeoutSeconds` (1..50, по умолчанию 20) превращают ответ в отчет готовности: GET на адрес, готово когда итоговый статус ниже 500, не больше пяти перенаправлений, одно чтение не дольше 5 секунд; неответивший адрес - отказ, клиент НЕ останавливается. Те же доводы у `start_client` фасада `infobase_admin`. |
| `run_yaxunit_tests` | Выполнение | Запускает YAxUnit и читает JUnit-отчет. |
| `yaxunit_tests` | Фасад · Выполнение | Единая точка запуска и отладки тестов YAxUnit. |
| `vanessa` | Выполнение | Запускает сценарии Vanessa Automation и снимает форму в работающей 1С. Сценарий берется файлом (`featurePath`), текстом (`scenarioText`) или собирается из `formToOpen` - тогда шаг открытия задается `openStep`, у формы списка, формы объекта и формы расширения он свой. Шагу открытия нужны типы интерфейсного тестирования: они есть только в клиенте, запущенном менеджером тестирования (`testManager`), иначе шаг отвечает `Тип не определен (ТестируемаяГруппаФормы)`. Клиент для шага запуска называется `testClient`, порт - `testClientPort`, пользователь базы - `infobaseUser` (пароль отвергается). Результат читается из файлов `<uuid>-result.json`, которые Vanessa называет сама. Снимок делает внешняя программа, по умолчанию IrfanView. |
| `create_launch_config` | Изменение | Создает конфигурацию запуска EDT. |
| `create_infobase` | Опасно | Создает информационную базу и связывает ее с проектом. |
| `delete_infobase` | Опасно | Удаляет информационную базу. |
| `install_extension` | Опасно | Устанавливает расширение в информационную базу. |
| `uninstall_extension` | Опасно | Удаляет расширение из информационной базы. |
| `list_extension` | Чтение | Показывает установленные расширения. |
| `import_configuration_from_xml` | Опасно | Импортирует XML конфигурации с возможной перезаписью проекта. |
| `export_configuration_to_xml` | Изменение | Экспортирует конфигурацию в XML. |
| `export_extension` | Изменение | Экспортирует расширение конфигурации. |
| `set_infobase_credentials` | Опасно | Изменяет сохраненные учетные данные подключения к ИБ. |
| `sync_control` | Опасно | Управляет направлением и состоянием синхронизации проект ↔ ИБ. |
| `resync_to_disk` | Опасно | Принудительно синхронизирует модель EDT на диск. |
| `restart_edt` | Опасно | Перезапускает выбранный экземпляр EDT. |
| `delete_project` | Опасно | Удаляет проект из рабочего пространства. |
| `self_upkeep` | Чтение | Сообщает, опубликована ли на update site сборка плагина новее установленной. |
| `infobase_admin` | Фасад · Смешанный | Объединяет жизненный цикл ИБ и обновление конфигурации. |

> Данных информационной базы плагин не отдает: `browse_data`, `execute_query` и фасад `data_access` из него
> удалены. Запрос к живой базе - только через скил `1c-mcp-toolkit`.
>
> Исключение - журнал регистрации ФАЙЛОВОЙ базы: он лежит файлами рядом с ней и читается
> `infobase_admin operation=read_event_log` без платформы и без запущенной базы. Таблицы базы
> по-прежнему недоступны, серверная база и формат `1Cv8.lgd` отвечают именованным отказом.

## Отладка и профилирование

Полный цикл управления приостановленной BSL-сессией.

| Инструмент | Режим | Назначение |
|---|---|---|
| `set_breakpoint` | Выполнение | Устанавливает строковую точку останова BSL. |
| `remove_breakpoint` | Выполнение | Удаляет точку останова. |
| `list_breakpoints` | Чтение | Показывает активные точки останова. |
| `wait_for_break` | Выполнение | Ожидает приостановку и возвращает поток, стек и кадры. |
| `get_variables` | Чтение | Читает переменные выбранного кадра стека. |
| `step` | Выполнение | Выполняет step over, step into или step out. |
| `resume` | Выполнение | Продолжает выполнение приостановленного потока. |
| `evaluate_expression` | Выполнение | Вычисляет BSL-выражение в контексте кадра. |
| `debug_yaxunit_tests` | Выполнение | Запускает тесты YAxUnit в режиме отладки. |
| `debug_status` | Чтение | Возвращает активные debug targets, потоки и состояние suspend. |
| `start_profiling` | Выполнение | Включает или выключает замер производительности. |
| `get_profiling_results` | Чтение | Возвращает измерения по модулям и строкам. |
| `launch_debugger` | Фасад · Выполнение | Объединяет запуск, breakpoints, stepping, variables и profiling. |
| `run_to_line` | Выполнение | Продолжает выполнение до выбранной строки. |
| `set_exception_breakpoint` | Выполнение | Настраивает остановку по исключениям. |
| `set_variable` | Выполнение | Изменяет значение переменной приостановленного кадра. |
| `terminate_launch` | Выполнение | Завершает выбранный debug launch. |

**Открытый редактор виднее файла.** `read_module_source` отдает несохраненные правки редактора и помечает это в ответе; `write_module_source` при таком редакторе отказывает. То есть прочитанное и записанное относятся к одному состоянию, а не к разным.

# AI-EDT: Редактирование метаданных / Конструкторы и мастерские / Формы и экспорт

> Снимок каталога инструментов AI-EDT из его docs (`docs/tools/README.ru.md`) на ревизии
> `4fb31770`, снят 28.07.2026. На момент снятия 118 имен сходились с реестром групп `ToolCategory.java`.
> Снимок НЕ канон и НЕ полон: рабочее дерево проекта уходит вперед (пример - `find_dead_code`, есть в коде,
> нет ни в реестре групп, ни в docs). Актуальный набор инструментов сессии - `tools/list`, каталог операций
> фасада - `operation=help`. Обновлять пересборкой из docs проекта, а не правкой руками.

## Редактирование метаданных

Точечный рефакторинг объектов и их реквизитов.

| Инструмент | Режим | Назначение |
|---|---|---|
| `rename_metadata_object` | Изменение | Переименовывает объект или вложенный элемент с каскадным refactoring. |
| `delete_metadata_object` | Опасно | Удаляет объект или вложенный элемент после preview/confirm. |
| `add_metadata_attribute` | Изменение | Добавляет реквизит поддерживаемому объекту метаданных. |

Эти три инструмента сохранены для совместимости и также доступны как операции `edit_metadata`.

## Конструкторы и мастерские

Высокоуровневое создание метаданных и сложных файлов EDT.

| Инструмент | Режим | Назначение |
|---|---|---|
| `edit_form` | Workshop · Изменение | Изменяет элементы, реквизиты, команды и события управляемой формы. |
| `edit_metadata` | Фасад · Изменение | Универсальный конструктор метаданных с пакетным и dry-run режимами. |
| `dcs_workshop` | Workshop · Изменение | Создает и изменяет схемы компоновки данных. Набор Object требует `dataObjectName` на `add_dataset` и на `add_union_item` (на другом типе набора довод отвергается). `add_total` пишет `dataPath` из выражения, явный довод перекрывает. `add_appearance` строит фильтр из `field` и `conditionValue` - частичное условие отвергается с названным доводом; `appearance` строкой `Имя=Значение;...`, JSON-объект или массив отвергаются. Те же доводы у алиаса `edit_metadata operation=add_conditional_appearance`. |
| `mxl_workshop` | Workshop · Изменение | Создает и редактирует табличные макеты MXL. |
| `extension_workshop` | Workshop · Смешанный | Управляет расширениями и перехватчиками. |
| `xdto_workshop` | Workshop · Изменение | Создает и изменяет XDTO-пакеты. |
| `external_object_workshop` | Workshop · Изменение | Создает внешние отчеты и обработки. |
| `external_data_source_workshop` | Workshop · Изменение | Создает внешние источники данных и их таблицы. |

## Формы и экспорт

Представление форм, встроенная справка и перенос артефактов.

| Инструмент | Режим | Назначение |
|---|---|---|
| `get_form_structure` | Чтение | Возвращает реквизиты, элементы, команды и события формы. |
| `get_form_screenshot` | Смешанный | Делает PNG-снимок формы; при `savePath` записывает файл на диск. |
| `get_object_help` | Чтение | Читает встроенную HTML-справку объекта метаданных. |
| `export_object` | Изменение | Экспортирует выбранный объект конфигурации. |
| `diff_module` | Чтение | Сравнивает версии BSL-модуля. |
| `ai_context` | Чтение | Собирает метаданные и структуру модулей объекта одним вызовом. |
| `get_command_interface` | Чтение | Возвращает командный интерфейс конфигурации или подсистемы. |
| `validate_for_export` | Чтение | Проверяет готовность объектов к экспорту. |
| `export_common_picture` | Изменение | Экспортирует общую картинку конфигурации. |
| `config_io` | Фасад · Смешанный | Объединяет импорт и экспорт конфигурации и отдельных артефактов. |

# AI-EDT: Проект и конфигурация / Метки и задачи / Составные операции для агента / Без назначенной группы / Пресеты и видимость

> Снимок каталога инструментов AI-EDT из его docs (`docs/tools/README.ru.md`) на ревизии
> `4fb31770`, снят 28.07.2026. На момент снятия 118 имен сходились с реестром групп `ToolCategory.java`.
> Снимок НЕ канон и НЕ полон: рабочее дерево проекта уходит вперед (пример - `find_dead_code`, есть в коде,
> нет ни в реестре групп, ни в docs). Актуальный набор инструментов сессии - `tools/list`, каталог операций
> фасада - `operation=help`. Обновлять пересборкой из docs проекта, а не правкой руками.

## Проект и конфигурация

Сведения о рабочем пространстве, конфигурации и состоянии валидации.

| Инструмент | Режим | Назначение |
|---|---|---|
| `get_edt_version` | Чтение | Возвращает версию запущенной EDT. |
| `list_projects` | Чтение | Показывает проекты текущего рабочего пространства. |
| `get_configuration_properties` | Чтение | Возвращает основные свойства конфигурации 1С. |
| `clean_project` | Выполнение | Очищает маркеры и запускает полную перевалидацию проекта. |
| `revalidate_objects` | Выполнение | Повторно проверяет выбранные объекты по FQN. |
| `get_check_description` | Чтение | Читает встроенное описание проверки EDT по ее идентификатору. |
| `project_admin` | Фасад · Смешанный | Управляет проектами, конфигурациями запуска и синхронизацией с диском. |

## Метки и задачи

Навигационные метки AI-EDT и стандартные маркеры рабочего пространства.

| Инструмент | Режим | Назначение |
|---|---|---|
| `get_tags` | Чтение | Возвращает метки проекта и количество назначенных объектов. |
| `get_objects_by_tags` | Чтение | Ищет объекты метаданных по выбранным меткам. |
| `get_bookmarks` | Чтение | Читает закладки рабочего пространства EDT. |
| `get_tasks` | Чтение | Возвращает TODO/FIXME и другие task-маркеры. |
| `workspace_marks` | Фасад · Чтение | Объединяет теги, объекты по тегам, закладки и задачи. |

## Составные операции для агента

Один вызов вместо нескольких последовательных обращений.

| Инструмент | Режим | Назначение |
|---|---|---|
| `generate_health_snapshot` | Чтение | Формирует снимок здоровья проекта, валидации и зависимостей. |
| `code_template` | Чтение | Возвращает готовый BSL-фрагмент по встроенному шаблону. |
| `generate_event_handlers` | Изменение | Создает заготовки обработчиков событий объекта или формы. |
| `extension_lifecycle` | Смешанный | Выполняет составной сценарий работы с расширением. |

## Без назначенной группы

Эти инструменты зарегистрированы в `McpHttpEndpoint.declareAllTools()`, но в текущем исходном `ToolCategory` для них нет группы. Они остаются вызываемыми и не получают отдельный checkbox в дереве Tools. Canonical скрывает их явно, однако групповые ограничения других пресетов, включая Read-only, не могут их отключить.

> **ВНИМАНИЕ, следствие для агента.** Пресет Read-only ниже описан как "отключает запись" - но на
> инструменты БЕЗ группы он не действует, а среди них есть изменяющие (например `create_project`). Значит
> Read-only НЕ является гарантией безопасности: под ним возможны изменения рабочего пространства. Перед
> деструктивной операцией полагаться не на пресет, а на явное подтверждение пользователя. Дефект занесен в
> инбокс плагина.

| Инструмент | Режим | Логичное размещение | Назначение |
|---|---|---|---|
| `create_project` | Изменение | Проект и конфигурация | Создает новый проект EDT. |
| `get_outgoing_structures` | Чтение | Исследование модели | Возвращает исходящие структурные ссылки объекта метаданных: типы, владельца, родителя и другие зависимости. |

> [!WARNING]
> Это расхождение конфигурации, а не особенность каталога. Его стоит устранить в `ToolCategory` и зафиксировать тестом покрытия.

## Пресеты и видимость

| Пресет | Что видит и может вызывать агент |
|---|---|
| **Canonical** | Фасады перечислены в `tools/list`; покрываемые ими standalone-инструменты скрыты, но остаются вызываемыми. |
| **All Tools** | Показывает весь зарегистрированный набор. |
| **Read-only** | Отключает запись, отладку, запуск и обновление ИБ. |
| **Editing** | Разрешает чтение и изменение, но отключает группу отладки. |
| **Debug & Test** | Разрешает чтение, запуск, отладку и тесты; отключает изменения и опасные операции. |
| **Code Review** | Оставляет чтение и анализ BSL без записи и запуска. |
| **Custom** | Использует вручную выбранные состояния инструментов. |

Состояния отдельного инструмента:

- **listed** - отображается в `tools/list` и вызывается;
- **callable-hidden** - скрыт из списка, но прямой вызов разрешен;
- **disabled** - вызов отклоняется сервером.

---

[↑ В начало](#каталог-инструментов-ai-edt)

# AI-EDT: типовые сценарии работы

> Накопленный практикой порядок вызовов. Каталог инструментов - остальные файлы `references/`.
> Имена сверялись с реестром проекта на ревизии `4fb31770` (28.07.2026); полноты снимок не гарантирует.
>
> **Синтаксис.** Сценарии ниже записаны короткими standalone-именами (`find_references`, `search_in_code`,
> `get_project_errors`, `debug_launch`, `go_to_definition`, `get_method_call_hierarchy`). Под пресетом
> Canonical эти имена скрыты из `tools/list`, хотя и остаются вызываемыми, поэтому канонический вызов - через
> фасад:
>
> | Короткое имя в сценарии | Канонический вызов |
> |---|---|
> | `search_in_code` | `code_search operation=text_search` |
> | `find_references` | `code_search operation=object_references` |
> | `go_to_definition` | `code_search operation=resolve_symbol` |
> | `get_method_call_hierarchy` | `code_search operation=call_hierarchy` |
> | `get_project_errors`, `revalidate_objects`, `clean_project`, `validate_for_export` | `diagnostics operation=<то же имя>` |
> | `debug_launch` | `launch_debugger action=launch` |
> | `set_breakpoint` | `launch_debugger action=add_breakpoint` |
> | `remove_breakpoint`, `list_breakpoints`, `set_exception_breakpoint`, `run_to_line`, `wait_for_break`, `get_variables`, `set_variable`, `resume`, `debug_status`, `start_profiling`, `get_profiling_results` | `launch_debugger action=<то же имя>` |
> | `evaluate_expression` | `launch_debugger action=evaluate` |
> | `step mode=over/into/out` | `launch_debugger action=step_over` / `step_into` / `step_out` |
> | `terminate_launch` | `launch_debugger action=terminate` |
> | `get_applications`, `update_database` | `infobase_admin operation=<то же имя>` |
> | `sync_control` | проще напрямую: `sync_control operation=status`. Через фасад действие идет отдельным параметром: `infobase_admin operation=sync_control syncOperation=status` |
> | `get_tags`, `get_objects_by_tags`, `get_bookmarks`, `get_tasks` | `workspace_marks operation=<то же имя>` |
>
> Старые имена (`debug_launch`, `set_breakpoint`, `terminate_launch`) фасад отладчика принимает и как алиасы,
> но канонические - из таблицы. Полный список действий - `launch_debugger action=help`.
>
> Инструменты без фасада (`write_module_source`, `validate_query`, `read_method_source`,
> `get_module_structure`, `ai_context` и другие) вызываются по имени.

## Typical Workflows

### Анализ незнакомого модуля
1. `get_module_structure` - получить список методов
2. `read_method_source` - прочитать нужные методы
3. `get_method_call_hierarchy` - понять, откуда вызываются

### Поиск использований объекта метаданных
1. `find_references` - все ссылки на объект (код, формы, роли, подсистемы)
2. `search_in_code` - дополнительный текстовый поиск если нужно

### Проверка качества после изменений
1. `revalidate_objects` - перевалидировать измененные объекты
2. `get_project_errors` с фильтром по объектам - получить ошибки
3. `get_check_description` - понять суть ошибки и как исправить
4. `ask_1c_ai` (1c-naparnik) - обязательная проверка качества после любого изменения BSL, включая код,
   записанный через `write_module_source`, и стабы, созданные операциями `edit_metadata`

### Валидация запросов
1. `validate_query` - проверить текст запроса на синтаксис и семантику
2. `validate_query` с `dcsMode=true` - проверить запрос СКД

### Обновление и тестирование
1. `get_applications` - получить ID приложения
2. `validate_for_export` - ОБЯЗАТЕЛЬНО до записи в ИБ; findings блокируют обновление, сперва исправить
3. `update_database` - обновить базу
4. `debug_launch` - запустить в отладке

Тот же пункт 2 нужен и когда обновление неявное: у `yaxunit_tests` по умолчанию `updateBeforeLaunch=true`,
то есть запуск тестов сам вызывает `update_database`.

### Навигация к определению
1. `go_to_definition` с `symbol` - найти определение метода или объекта
2. `get_symbol_info` - получить тип символа в конкретной позиции
3. `read_method_source` - прочитать код, если нужно больше контекста

### Перед разрушительной операцией

`insights operation=impact_analysis` считает радиус поражения объекта: что на него ссылается, какой
уровень серьезности (LOW / MEDIUM / HIGH) и что рекомендуется. Плагин прямо предписывает звать его
ПЕРЕД `delete_metadata_object`, `rename_metadata_object`, `remove_object_attribute` и прочими
операциями, которые что-то убирают. Одного `find_references` для этого мало: он показывает ссылки,
но не оценивает последствия.

### Рефакторинг метаданных
1. `find_references` - проверить все ссылки перед изменением
2. `rename_metadata_object` с `preview=true` - просмотр каскадных изменений
3. `rename_metadata_object` с `confirm=true` - выполнить переименование
4. `revalidate_objects` - проверить результат

### Модификация метаданных через EDT
1. `add_metadata_attribute` - добавить реквизит (вместо ручного редактирования XML)
2. `delete_metadata_object` - удалить объект/реквизит с очисткой ссылок
3. `write_module_source` - записать BSL-код с автопроверкой синтаксиса

### Изучение API платформы
1. `get_platform_documentation` с `typeName` - документация по типу
2. `get_content_assist` - автодополнение в контексте кода

### Сбор контекста перед доработкой
1. `ai_context` с `target=<FQN объекта>` и `depth=standard` - одним вызовом получить метаданные + список модулей + структуру методов
2. При необходимости углубиться в конкретный метод - `depth=full` + `focusMethod=<имя>`

### Code review изменений модуля
1. `diff_module` с `mode=summary` - обзор какие методы добавлены/изменены/удалены
2. Если нужен детальный разбор - `mode=methods` (отдельный diff на каждый измененный метод)
3. Для полного контекста изменений - `mode=unified` (git diff)

### Отладка BSL-кода
1. `get_applications` - получить `applicationId`
2. `debug_launch` - запустить приложение в режиме отладки
3. `set_breakpoint` - установить breakpoint в нужном методе
4. Запустить сценарий через UI приложения или `yaxunit_tests mode=debug`
5. `wait_for_break` - дождаться срабатывания breakpoint
6. `get_variables` с `frameRef` - посмотреть значения переменных
7. `evaluate_expression` - вычислить BSL-выражение в контексте остановки
8. `step` (over/into/out) или `resume` - продолжить выполнение
9. `remove_breakpoint` - снять breakpoint после завершения

### Профилирование BSL-кода
1. `debug_launch` или `yaxunit_tests mode=debug` - активная debug-сессия
2. `start_profiling` с `applicationId` - включить замер
3. Выполнить тестовый сценарий (через UI или YaxUnit)
4. `get_profiling_results` с `moduleFilter` - получить данные по вызовам/времени
5. Использовать `minFrequency` для фильтрации редко вызываемых строк

### Модификация формы без ручного XML
1. `edit_metadata operation=help topic=workflow` или `edit_form operation=help` - справка по операциям
2. `get_form_screenshot` - визуально оценить текущее состояние формы
3. `edit_metadata operation=add_field|add_group|add_button|add_table|add_decoration` (через `edit_form` тоже работает) - добавить элементы. Имена проверяются на коллизию
4. `edit_metadata operation=add_button standardCommand=Записать` - 22 stock команд платформы с auto-icon
5. `edit_metadata operation=add_table autoGenerateColumns=true` - один FormField на каждую колонку ТЧ с префиксом родителя
6. `edit_metadata operation=add_decoration kind=Picture picture="StdPicture.Find" projectName=...` - валидация картинки через `PictureValidator`
7. `edit_metadata operation=add_form_event_handler event=ПриСозданииНаСервере` - auto-stub в модуль формы (22 события из FormEventRegistry)
8. `edit_metadata operation=remove_form_attribute name=... deleteDataItems=true` - удаляет реквизит со всеми bound items
9. `edit_metadata operation=remove_item path=...` - удалить любой элемент по FQN
10. `get_form_screenshot` с `refresh=true` - проверить результат

### Запуск YAxUnit-тестов
1. `yaxunit_tests help=writing` - первое знакомство с YAxUnit (см. также `help=assertions|setup|events|advanced`)
2. `validate_for_export` - обязательно, когда `updateBeforeLaunch` не выключен явно (по умолчанию `true`,
   см. пункт 8): тогда запуск тестов сам выполняет `update_database`, то есть пишет конфигурацию в ИБ. При
   явном `updateBeforeLaunch=false` записи нет и проверка не требуется
3. `yaxunit_tests mode=run` с `applicationId` или `configName` - синхронный прогон с timeout polling
4. При истечении timeout вернется JSON `Pending` + `runKey` - повторить вызов с **теми же** параметрами (НЕ менять filters/configName), забирается финальный отчет
5. Filters: `tests=Тест_X,Тест_Y`, `suites=ТестыКадры`, `extensions=YAxUnit`, `modules=*Тесты*`, `tags=smoke,fast`, `contexts=Server,Client`
6. При `0 tests run` - проверить активность YAxUnit-расширения в ИБ (Конфигурация → Расширения → Active = Yes), затем `help=setup`
7. Отладка теста: `set_breakpoint` → `yaxunit_tests mode=debug tests=Тест_X` → `wait_for_break` → `get_variables`/`step`
8. `updateBeforeLaunch=true` (default) - автоматический `update_database` перед запуском, чтобы не висеть на модальном "Обновить?"

### Создание метаданных через edit_metadata

> Набор операций `edit_metadata` меняется чаще остального каталога. Авторитетный перечень - `operation=help`
> (и `topic=availability` для текущего runtime); ниже - проверенные практикой приемы и порядок, а не полный
> список операций.
1. `edit_metadata operation=help topic=workflow` - типичный сценарий "от нуля до готовой подсистемы"
2. `edit_metadata operation=help topic=availability` - probe какие группы реально доступны на текущем EDT runtime
3. `edit_metadata operation=create_object objectType=Catalog name=Products` - для `CommonForm` автоматически создается вторая форма-обертка.
4. `edit_metadata operation=add_object_attribute name=Article type=String` - идемпотентно. При несовпадении свойств возвращается тег `propertyMismatch` с массивом `mismatches` - НЕ ретраить, использовать `set_object_property`
5. `edit_metadata operation=create_form formType=Generic layout=empty` - 11 базовых свойств применяются автоматически, без них форма не открывается в редакторе
6. `edit_metadata operation=remove_object_attribute name=Article` - если поле используется в формах, нужно `cascadeForms=true` (без него получите `requiresCascadeForms` + preview `affectedForms`)
7. EventSubscription: `add_event_subscription_handler handler="CommonModule.X.Method"` или `"X.Method"` - префикс добавляется автоматически
8. Extension-проект: НЕ передавать `privileged=true` для CommonModule, НЕ комбинировать `global=true+server=true` - early-fail
9. HTTP services: `add_url_template` (URL-шаблон) → `add_url_template_method` (метод GET/POST/PUT/DELETE; default handler = `<template><method>`; возвращает hint с сигнатурой для `write_module_source`)
10. Object commands: `create_object_command` → автоматически создает `CommandModule.bsl` со стабом `ОбработкаКоманды`. `remove_command` для удаления.
11. **МАССОВОЕ создание (batch=true) - против N round-trip'ов.** За ОДИН вызов много операций: `edit_metadata batch=true operations=[{"operation":"create_object",...},{"operation":"add_object_attribute",...},...]`. Массив идет по порядку, КАЖДАЯ op в своей BM-транзакции, `projectName`/`ownerFqn`/`dryRun` наследуются от внешнего вызова (per-item переопределяет). Поздние op видят ранние (`create_object` -> `add_object_attribute` к новому объекту). Ответ: `batchResults[]` (index/operation/ok/response) + счетчики ok/fail. **Кейс "38 ролей": НЕ 38+ пар вызовов, а ОДИН** `batch=true` с `[{create_object Role1},{set_role_right ...},{create_object Role2},...]`. Работает для ЛЮБЫХ операций, не только adopt_*. Оговорка: не атомарно на все (каждая op - своя транзакция); нужна атомарность "все или ничего" - это отдельный запрос.
12. **Внешние обработки/отчеты - все через тулзы, руками в `.mdo` НЕ лезть.** Создание: `external_object_workshop operation=create kind=ExternalDataProcessor|ExternalReport name=X [parentProjectName=Y]` (создает DT-проект `.epf`/`.erf`, nature `V8ExternalObjectsNature`, `.mdo` c UUID; parentProjectName опционален). Наполнение - штатным `edit_metadata` по FQN корня: `add_object_attribute` / `add_tabular_section` / `add_template` на `ownerFqn=ExternalDataProcessor.X` РАБОТАЮТ. Формы - `create_form`; сборка - `validate_for_export` (обязательная проверка перед сборкой артефакта), затем `export_object` -> `.epf`.

---

```
# Object группа
edit_metadata operation=createObject projectName=X objectType=Catalog name=Products dryRun=true
edit_metadata operation=addObjectAttribute ownerFqn=Catalog.Products name=Article
edit_metadata operation=removeObjectAttribute ownerFqn=Catalog.Products name=Article cascadeForms=true

# Forms группа (alias к edit_form для add*/removeFormItem)
edit_metadata operation=createForm projectName=X ownerFqn=Catalog.Products formName=ItemForm formType=ItemForm setAsDefault=true
edit_metadata operation=addField formFqn=Catalog.Products.Form.ItemForm name=Article dataPath=Object.Article
edit_metadata operation=listPictures projectName=X filter=add  # поиск картинок (StandardPictures + CommonPicture.*)

# Templates группа
edit_metadata operation=addTemplate projectName=X ownerFqn=Catalog.Products name=PrintForm templateType=Spreadsheet  # 10 типов: Spreadsheet/Text/DCS/Appearance/Binary/HTML/Geo/Graph/ActiveDocument/AddIn

# HTTP-services: композитное создание + удаление
edit_metadata operation=create_http_service projectName=X name=Orders                              # минимум: один вызов = HTTPService + Template1 + Get GET + Module.bsl со стабом
edit_metadata operation=create_http_service projectName=X name=Orders rootURL=/api/orders \
  urlTemplateName=ByID urlTemplate=/order/{id} methodName=Read httpMethod=GET handler=ReadOrderByID
edit_metadata operation=add_url_template projectName=X ownerFqn=HTTPService.Orders name=List template=/orders
edit_metadata operation=add_url_template_method projectName=X ownerFqn=HTTPService.Orders templateName=List name=All httpMethod=GET withHandlerStub=true  # auto-stub в Module.bsl
edit_metadata operation=remove_url_template_method projectName=X ownerFqn=HTTPService.Orders templateName=List name=All
edit_metadata operation=remove_url_template projectName=X ownerFqn=HTTPService.Orders name=List
# В расширении тот же синтаксис, projectName=<extension project name>

# Extensions группа (batch + child-FQN)
edit_metadata operation=adopt_objects projectName=Ext baseProjectName=Base targetFqn=Catalog.A,Document.B,Document.C  # CSV per-object result
edit_metadata operation=adopt_object projectName=Ext baseProjectName=Base targetFqn=Document.SalesOrder recursive=true  # с детьми
# adopt_child / adopt_form_item принимают composed FQN или явные ownerFqn + childKind + name
edit_metadata operation=adopt_child projectName=Ext baseProjectName=Base ownerFqn=Catalog.Products childKind=Form name=ItemForm
edit_metadata operation=adopt_child projectName=Ext baseProjectName=Base targetFqn=Document.Sales.Attribute.Discount  # equivalent
edit_metadata operation=adopt_child projectName=Ext baseProjectName=Base targetFqn=InformationRegister.Rates.Resource.Rate
# childKind aliases на русском также поддержаны: Форма / Реквизит / ТабличнаяЧасть / Макет / Команда / Измерение / Ресурс

# Specialized группа
edit_metadata operation=addEnumValue ownerFqn=Enum.Statuses name=Active
edit_metadata operation=addRegisterField ownerFqn=InformationRegister.Q name=Status fieldKind=resource
edit_metadata operation=addEventSubscriptionHandler eventName=BeforeWrite handler="MyModule.Handler"  # нормализация в "CommonModule.MyModule.Handler"

# DCS группа
edit_metadata operation=createReportSchema projectName=X ownerFqn=Report.Sales
edit_metadata operation=addDataSet projectName=X ownerFqn=Report.Sales name=Main type=Query queryText="ВЫБРАТЬ..."
edit_metadata operation=addCalculatedField projectName=X ownerFqn=Report.Sales name=Total expression="Sum * Qty"
edit_metadata operation=repairReportSchema projectName=X ownerFqn=Report.Sales  # лечение схемы-фантома в расширениях
```

**Идемпотентность:**
- При повторном вызове `addObjectAttribute`/`addTabularSection`/`createObject` с уже существующим именем + другими свойствами - ответ содержит `propertyMismatch` тег с массивом `[{name, requested, existing}]`. AI агент должен вызвать `setObjectProperty` для каждого diff'а, а НЕ ретраить add*.
- При совпадении свойств - `idempotentSkip` тег (success no-op).

**Cascade form cleanup:**
- При `removeObjectAttribute`/`removeTabularSection`/`removeTabularSectionAttribute` с активными ссылками на удаляемое поле в формах - операция отказывает с `requiresCascadeForms` тегом + `affectedForms` preview.
- Передать `cascadeForms=true` (или `force=true`) - поля автоматически удаляются со всех форм владельца.

**Защитные слои:**
- **Standard attribute conflict guard** - `edit_metadata addObjectAttribute` блокирует имена, совпадающие с платформенными стандартными реквизитами (Code, Date, Number, Posted, LineNumber и др., включая русские варианты).
- **Supplier lock guard** - при обнаружении что объект на поддержке и режим прав `NOT_ALLOWED` / `DENIED` / `DISABLED` блокирует с инструкцией "включить редактирование в EDT или работать через расширение".
- **Гарантированный sync на диск** для всех BM-mutating tools (10s soft cap).

**Защитные слои (headless метаданные):**
- **EventSubscription handler auto-prefix** - `addEventSubscriptionHandler handler="..."` принимает `"Method"` или `"CommonModule.X.Method"`, нормализуется к полной форме. Если CommonModule не существует - early-fail с тегом `commonModuleNotFound`.
- **Extension CommonModule guards** - в проекте-расширении блокирует `privileged=true` и комбинацию `global=true+server=true` (платформа отвергает на UpdateDBCfg).
- **Generic+empty form 11 base properties** - `createForm formType=Generic layout=empty` автоматически получает 11 базовых свойств (групповая раскладка, командная панель и др.), без них форма не открывается в EDT-редакторе и таблицы схлопываются до нулевой высоты.
- **CommonForm auto inner form** - `createObject CommonForm.X` автоматически создает внутреннюю форму вторым шагом (.mdo + Form.form + Module.bsl рядом).

## AI-agent helper tools

Три композитных tool для AI-friendly workflows.

#### `generate_health_snapshot` - Полный health snapshot за один вызов
Объединяет errors + metadata stats + project metrics + anti-patterns в одном response, заменяя 5+ tool-calls. Один вызов дает AI агенту полную картину состояния проекта.

| Параметр | Обязательный | Описание |
|---|:---:|---|
| `projectName` | да | Имя проекта EDT |
| `includeAntiPatterns` | нет | Запустить `detect_query_anti_patterns` (default true) |
| `includeMetrics` | нет | Запустить `project_metrics` (default true) |
| `errorScope` | нет | `session\|project\|all` (default `session`) |

#### `code_template` - Boilerplate BSL templates
11 готовых шаблонов BSL-кода для типичных задач: HTTP-service handler, scheduled job, event subscription, form module skeleton, object events, print form, background job, EDP method, YAxUnit test suite и др.

| Параметр | Обязательный | Описание |
|---|:---:|---|
| `template` | да | Имя шаблона: `httpService`, `scheduledJob`, `eventSubscription`, `formModule`, `objectEvents`, `printForm`, `backgroundJob`, `edpMethod`, `yaxunit`, `commonModule`, `apiClient` |
| `params` | нет | JSON-объект с подстановками (имена методов/реквизитов) |
| `language` | нет | `ru\|en` (default `ru`) |

#### `extension_lifecycle` - Workflow для расширений
Многошаговый guided workflow: probe extension → adopt object → generate event handler → revalidate. Заменяет цепочку из 4-5 tool calls для типичного сценария "добавить перехватчик метода в расширении".

| Параметр | Обязательный | Описание |
|---|:---:|---|
| `projectName` | да | Имя расширения (V8ExtensionNature project) |
| `step` | да | `probe\|adopt\|generateHandler\|validate\|all` |
| `targetFqn` | нет | FQN заимствуемого объекта (для adopt/generateHandler) |
| `methodName` | нет | Имя метода для перехвата (для generateHandler) |
| `interceptType` | нет | `before\|after\|instead` (default `before`) |

При вызове deferred операции `edit_metadata` возвращает понятное сообщение с probe API availability и подсказкой про GUI fallback - это нормальное поведение, не ошибка реализации.