--- name: xdto description: Просмотреть или точечно изменить схему XDTO-пакета 1С по логическому адресу. Используй для EnterpriseData `valueType`, `objectType` и свойств типов. argument-hint: allowed-tools: - Read - Glob --- # /unica:xdto — XDTO-пакеты 1С Перед чтением или мутацией сверяй поддерживаемую грамматику и байтовые гарантии с `../../references/specs/1c-xdto-spec.md`. ## MCP routing - Используй только MCP `unica`: `unica.view` читает пакет по адресу, а `unica.apply` с операциями семейства XDTO строит и применяет точечную мутацию. - Всегда начинай с `unica.view`, затем перед каждой мутацией вызывай `unica.apply` с `at` и `ops`. Исполняй план вызовом только с `executionToken` из `data.executionToken` после поручения пользователя; любое изменение аргументов требует нового preview. - Планирующий `unica.apply` принимает непустой упорядоченный массив `ops`. Связное изменение — тип и его свойства — веди одним планом: операции видят результаты предыдущих, публикация одна, отказ любой операции не оставляет частичной записи. Ошибка элемента называет `ops[<индекс>]`. - И читателю, и писателю передавай один адрес `at` вида `<набор>:XDTOPackage.<Имя>` (для операций над типом — `<набор>:XDTOPackage.<Имя>.Type.<Тип>`, над свойством любой вложенности — `…Type.<Тип>.Property.<А>[.Property.<Б>…]`). Точка внутри имени пишется `\.`: свойство `A.B` — `…Property.A\.B` (в JSON — `A\\.B`). Никогда не передавай путь к `XDTOPackages/.../Ext/Package.bin`: он остаётся внутренней раскладкой платформенной выгрузки. - Не вызывай donor-команды compile, decompile или validate и не запускай их скриптовые обёртки: публичная граница этого скилла состоит ровно из двух нативных инструментов выше. Операции семейства XDTO в `ops` — закрытое объединение с тегом `op`, а их аргументы добавления едут только внутри `args.values`: `valueType.add` (`name`, `base`, необязательный `facets`), `objectType.add` (`name`, необязательные `base` и одно из `before` / `after`), `property.add` (`property`), `property.rename` (`newName`), `type.set` (`base`). `type.remove` и `property.remove` не принимают payload, включая пустой `values`. Плоские поля добавления и `values.at` отклоняются с `bad_value`. Необязательный `property.minOccurs` принимает целое JSON-значение `0` или `1`, включая эквивалентные записи `0.0`, `0e0`, `1.0`, `1e0`. Отсутствующее поле не подставляется как явная единица. Узел, над которым идёт операция, называет `at`, а не отдельный аргумент: `property.add` — на типе или на свойстве, во вложенный анонимный тип которого добавляется новое (`…Type.ЛюбаяСсылка.Property.СсылкаНаОбъект`); `property.remove` — на самом удаляемом свойстве. Прежние `propertyPath` и `name` у `property.remove` отклоняются с `bad_value`, `next` ведёт к адресу свойства. `property.rename` адресует само переименуемое свойство. Writer сохраняет BOM и наблюдённые переводы строк, а повтор того же добавления возвращает no-op. QName в `base` и `property.type` передавай с существующим префиксом. Если префикс не виден в области вставки, writer повторит его объявление локально только при единственном доказанном соответствии префикса URI во всём пакете; отсутствующее или противоречивое соответствие отклоняется без угадывания URI. ## 1. Прочитать логическую цель Корень пакета отвечает целевым пространством имён и счётчиками, а состав лежит в ветвях `Namespace`, `Type` и `Property`; спускайся в нужную адресом из `branches`. ```json { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "unica.view", "arguments": { "at": "main:XDTOPackage.EnterpriseData_1_17_3" } } } ``` Отдельный тип и его свойства читаются тем же вызовом глубже по адресу; свойство со вложенным анонимным типом объявляет ветвь `Property` своих свойств: ```json { "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "unica.view", "arguments": { "at": "main:XDTOPackage.EnterpriseData_1_17_3.Type.ЛюбаяСсылка" } } } ``` У свойства `props.type` — объект JSON с исходным QName, локальным именем и пространством имён; у ссылки на глобальное свойство эти сведения находятся в `props.reference`. `props.bounds` — объект JSON с эффективными `lower` и `upper`, признаками явного задания `lowerExplicit` и `upperExplicit`, а также `unbounded`. Отсутствующая граница имеет эффективное значение `1`; `upper=-1` означает неограниченную верхнюю границу. ### Добавить тип с основой между соседями Договор операции доступен через `unica.view(at="main:XDTOPackage.Пример.Can.objectType.add")`. Для пакета с типами `Основа`, `ПримерА`, `ПримерВ` и объявленным `xmlns:tns="urn:unica:example"` запрос из сценария `S-1408-xdto-base-order` выглядит так: ```json { "at": "main:XDTOPackage.Пример", "ops": [{ "op": "objectType.add", "args": {"values": { "name": "ПримерБ", "base": "tns:Основа", "before": "ПримерВ" }} }] } ``` Основа и вся её цепочка должны быть локальными объектными типами без цикла. `before` или `after` задают непосредственного соседа среди объектных типов; без них тип добавляется в конец. Предшествующие операции того же пакета могут создать основу или соседа. Импортированная основа для этой операции пока не поддерживается. Неизвестный сосед, неверная основа и конфликтующий дубль отклоняются без записи; эквивалентный повтор ничего не меняет. Перед исполнением проверь `data.xdtoObjects`: `base`, `previous`, `next` описывают окончательное состояние после всех операций, а `present=false` означает, что добавленный тип удалён последующей операцией. Отсутствующий `previous` или `next` означает край списка. Исполни сохранённый `executionToken`, затем прочитай новый тип. Поле `props.baseAt` даёт адрес однозначно разрешённой локальной основы; её свойства читаются по этому адресу. Поле `props.base` — объект JSON с QName. Собственная ветвь `Property` не разворачивает унаследованные свойства. ### Сменить основу типа `type.set` на адресе типа меняет только его `base`: имя, свойства, ограничения, `sequenced` и место сохраняются, входящие ссылки остаются верными. Объектному типу подходит локальный объектный тип без цикла, типу значения — тип `xs:` или локальный тип значения, если его ограничения допустимы для новой основы. Аргументы preview из сценария `S-1699-xdto-type-base`: ```json { "at": "main:XDTOPackage.Пример", "ops": [ {"op": "type.set", "args": {"at": "main:XDTOPackage.Пример.Type.Документ", "values": {"base": "tns:ОсноваБ"}}}, {"op": "type.set", "args": {"at": "main:XDTOPackage.Пример.Type.Количество", "values": {"base": "xs:integer"}}} ] } ``` После исполнения `props.baseAt` типа указывает на новую основу. Прежняя основа ничего не пишет; цикл, чужое семейство, отсутствующая основа и несовместимые ограничения отклоняются по `values.base` с причиной. ## 2. Построить preview ```json { "jsonrpc": "2.0", "id": 3, "method": "tools/call", "params": { "name": "unica.apply", "arguments": { "at": "main:XDTOPackage.EnterpriseData_1_17_3.Type.ЛюбаяСсылка.Property.СсылкаНаОбъект", "ops": [ { "op": "property.add", "args": { "values": { "property": { "name": "Документ_НовыйДокумент", "type": "tns:Документ_ЗаказКлиента", "minOccurs": 0 } } } } ] } } } ``` Связная последовательность — например `objectType.add` и следом `property.add` к созданному типу — передаётся тем же массивом `ops` и проверяется одним preview. ## 3. Применить только после подтверждения Когда пользователь поручил внести правку, передай только `executionToken` из `data.executionToken` успешного плана: Для исполнения передай `data.executionToken` из этого успешного плана: ```json { "jsonrpc": "2.0", "id": 4, "method": "tools/call", "params": { "name": "unica.apply", "arguments": { "executionToken": "" } } } ``` ## Переименовать свойство `property.rename` меняет только имя собственного свойства: тип, границы, `localName` и место среди соседей остаются. Несколько переименований одного типа идут одним планом; общий `at` — тип, у каждой операции свой `args.at`. Аргументы preview из сценария `S-1703-xdto-property-rename`: ```json { "at": "main:XDTOPackage.Пример.Type.Товар", "ops": [ {"op": "property.rename", "args": {"at": "main:XDTOPackage.Пример.Type.Товар.Property.Наименование", "values": {"newName": "Название"}}}, {"op": "property.rename", "args": {"at": "main:XDTOPackage.Пример.Type.Товар.Property.Код", "values": {"newName": "ВнешнийКод"}}}, {"op": "property.rename", "args": {"at": "main:XDTOPackage.Пример.Type.Товар.Property.Цена", "values": {"newName": "Цена.Розничная"}}} ] } ``` После исполнения читай свойство по новому адресу: последний сегмент заменён новым именем, точка экранируется (`…Property.Цена\.Розничная`). Старый адрес отвечает `not_found`. Текущее имя ничего не записывает. Имя соседа, в том числе `ref`, и совпадение XML-представления с соседом отклоняются `invalid_state` по `values.newName`. Явный `localName` остаётся XML-именем, поэтому формат обмена не меняется; без него меняется и XML-элемент. BSL-обращения к свойству по имени правь отдельно. ## Создать анонимный тип в свойстве Прочитай `Can.property.add` у именованного типа. В `property` укажи `name` и ровно одно определение: `type` с QName, `valueType` с основой и фасетами либо `objectType.properties` с упорядоченным списком дочерних свойств. Дети используют тот же договор и могут содержать собственный анонимный тип. `minOccurs` допускает `0` или `1`, `maxOccurs` — `-1` (без ограничения) или положительное целое; неуказанная граница равна `1`. Аргументы preview из сценария `S-1409-xdto-anonymous`: ```json { "at": "main:XDTOPackage.ПримерФормата.Type.Пример", "ops": [ { "op": "property.add", "args": { "values": { "property": { "name": "Строки", "minOccurs": 0, "maxOccurs": -1, "objectType": { "properties": [ { "name": "Основание", "type": "tns:ТипОснования", "minOccurs": 0, "maxOccurs": 1 }, { "name": "Получатель", "type": "tns:ТипПолучателя", "minOccurs": 0, "maxOccurs": 1 } ] } } } } } ] } ``` После preview исполни полученный `executionToken`. Один план создаёт контейнер, определение и детей; неверная ссылка ребёнка отклоняет весь план. Точный повтор дерева ничего не записывает, изменение границ, типа, состава или порядка детей при том же имени — конфликт. Прочитай `Type.Пример.Property.Строки`: `props.anonymousType` равен `ObjectType`, а `props.bounds` описывает границы. Перейди по адресу ветви `Property`, затем по `at` ребёнка. Повторяй эти переходы для следующего уровня; определение не сворачивается в ограниченную по размеру строку `props`. Следующая операция того же плана может добавлять детей по адресу контейнера в `args.at`, например `main:XDTOPackage.ПримерФормата.Type.Пример.Property.Строки`. ## Ограниченные значения Перед созданием прочитай `Can.valueType.add` у пакета или `Can.property.add` у типа. Для строки задай в `facets` максимальную длину `maxLength`; для decimal — нужные `totalDigits`, `fractionDigits`, `minInclusive` и `maxInclusive`. Границы числа передавай строками без экспоненты. Например, диапазону 0…999.99 при пяти значащих цифрах и двух дробных соответствуют `minInclusive: "0"`, `maxInclusive: "999.99"`, `totalDigits: 5`, `fractionDigits: 2`. Одних разрядности и масштаба недостаточно для запрета 1000.00. Именованный тип создай `valueType.add`, затем ссылайся на него из свойства через `property.type`. Для анонимного ограниченного значения передай `property.valueType` с `base` и `facets`; одновременно задавать `type` или `objectType` нельзя. Основа анонимного определения — только XML Schema `string` или `decimal`, в том числе без фасетов. После применения прочитай `props.facets`; у анонимного определения дополнительно проверь `props.anonymousType` и `props.base`. Проверка значений выполняется потребителем схемы, например `ФабрикаXDTO.ПрочитатьXML` платформы. Подробные допустимые сочетания описаны в спецификации, на которую ссылается начало навыка.