xbsl-meta-add

Создание объекта конфигурации в 1С:Элемент (XBSL). Используй этот скилл когда пользователь хочет создать новый объект метаданных в проекте

Во всех командах ниже {python} означает python в Windows и python3 в macOS/Linux/WSL. Выбирай команду сразу по текущей ОС, не запускай оба варианта.

Создание объекта конфигурации в 1С:Элемент

Перед созданием или дополнением .xbsl прочитай docs/xbsl-spec.md; API HttpСервиса и других объектов сверяй по reference-файлам скилла и официальным источникам из registry.

HttpСервис — быстрый путь

Если тип объекта HttpСервис — используй скрипт вместо шагов 1–4:

Шаг 1 — Dry-run

{python} skills/xbsl-meta-add/scripts/generate_http.py \
  --name <ИмяСервиса> \
  --url /<ресурс> \
  --routes "GET /, POST /, GET /{id}, PUT /{id}, DELETE /{id}" \
  --root <корень>

Опциональные флаги: - --subsystem <ИмяПодсистемы> — если нужно выбрать конкретную подсистему - --access РазрешеноАутентифицированным — добавить контроль доступа; без --access блок контроля доступа не добавляется.

/api зарезервирован платформой и отклоняется: платформа автоматически добавляет этот префикс к КорневойUrl.

Показать вывод пользователю. Если ⚠️ Сервис уже существует — спросить: заменить или отмена. Если скрипт завершился с ошибкой — сообщи пользователю и остановись.

Шаг 2 — Применить (только после подтверждения)

{python} skills/xbsl-meta-add/scripts/generate_http.py \
  --name <ИмяСервиса> \
  --url /<ресурс> \
  --routes "GET /, POST /, GET /{id}, PUT /{id}, DELETE /{id}" \
  --root <корень_проекта> \
  --apply

Шаг 3 — Итог

Перечислить созданные файлы из вывода скрипта: - <ИмяСервиса>.yaml — объект HttpСервис с маршрутами - <ИмяСервиса>.xbsl — заготовки обработчиков

Добавление маршрутов в существующий сервис

Если пользователь хочет добавить endpoint в уже существующий HttpСервис:

Шаг 1 — Dry-run

{python} skills/xbsl-meta-add/scripts/generate_http.py \
  --service <ИмяСервиса> \
  --add-routes "DELETE /{id}, GET /{id}/items" \
  --root <корень>

Показать вывод пользователю. Если ⚠️ обработчик уже существует — он будет пропущен.

Шаг 2 — Применить

{python} skills/xbsl-meta-add/scripts/generate_http.py \
  --service <ИмяСервиса> --add-routes "..." --root <корень> --apply

Шаг 3 — Итог

<ИмяСервиса>.yaml — добавлены новые ШаблоныUrl
<ИмяСервиса>.xbsl — добавлены новые методы-обработчики

Все остальные типы объектов

Шаг 0: Определи тип объекта

Из запроса пользователя определи ВидЭлемента, затем открой object-coverage.json. Это единственный registry покрытия, маршрутизации, reference-paths и статусов для 1С:Предприятие.Элемент 9.3.

Действуй по записи registry:

supported — продолжай текущий workflow и читай reference_path вместе с shared_reference_paths.
partial — не генерируй объект по догадке; сообщи, что полная поддержка пока не описана в registry, и используй reference contract только для постановки/проверки работ.
routed — передай задачу в owner_skill; для ЗапланированноеЗадание владельцем является xbsl-scheduled-task.
automatic и out_of_scope ищи только в top-level routing; они не входят в 32 функциональных типа objects.

Все поддерживаемые виды маршрутизируются через supported-записи registry: для каждого открывай одноименный references/<Вид>.md и создавай только required companion-артефакты, перечисленные в artifacts. Если registry указывает shared reference references/ТабличныеЧасти.md, читай его дополнительно и не копируй правила табличных частей в object-specific reference. Для Отчет доступна точечная feature-delta ЭкспортироватьВИзображение() с пометкой 9.2+; базовый Отчет остается min_version: 9.1.

Человекочитаемая матрица находится в object-coverage.md и генерируется из JSON. Не создавай вторую ручную таблицу покрытия в этом файле.

Шаги 1 и 2: выполни параллельно

Шаг 1 — Загрузи спецификацию. Прочитай файл спецификации для нужного типа:

<reference_path из object-coverage.json>

Дополнительно прочитай каждый путь из shared_reference_paths.

Если в запросе упоминаются табличные части (ТЧ, строки, таблица, колонки), а registry ещё не перечисляет references/ТабличныеЧасти.md в shared_reference_paths, прочитай его дополнительно как shared reference и не копируй правила табличных частей в object reference.

Шаг 2 — Разведка проекта. Используй скилл xbsl-explore, передав тип объекта и имя (если известно из запроса).

Если xbsl-explore вернул пустой список projects — остановись и предложи пользователю сначала создать проект через скилл xbsl-init, затем повторить запрос.

Шаг 3: Сгенерируй UUID

Из спецификации узнай, сколько UUID нужно (1 на объект + по 1 на каждый реквизит/элемент/измерение/ресурс). Посчитай точное количество и вызови скилл xbsl-uuid с этим числом.

Шаг 3а: Проверь межподсистемные ссылки

Для каждого ссылочного реквизита (<Имя>.Ссылка?) из запроса определи подсистему объекта-источника.

Как определить подсистему источника: - Из результатов xbsl-explore (шаг 2) извлеки корень проекта - Найди файл <Имя>.yaml в дереве проекта: <root>/**/<Имя>.yaml - Имя папки-родителя этого файла — подсистема Y источника - Имя папки из suggested_path нового объекта — подсистема X

Если подсистема Y источника отличается от подсистемы X нового объекта:

Файл	Действие
`<ПодсистемаY>/<Источник>.yaml`	Прочитай. Если `ОбластьВидимости: ВПодсистеме` — изменить на `ВПроекте`
`<ПодсистемаX>/Подсистема.yaml`	Добавить `Y` в список `Использование` (если Y ещё не в списке)
Новый объект (создаётся в Шаге 4)	Включить поле `Импорт: [Y]` (объединить все внешние подсистемы одним списком)

Для каждого изменённого существующего файла кратко сообщи пользователю: - «Обновлён ОбластьВидимости → ВПроекте в Основное/Склады.yaml» - «Добавлено Использование: [Основное] в Закупки/Подсистема.yaml»

Если объект-источник не найден в проекте — действуй по текущему правилу (ставь Тип: Строка, предупреди пользователя).

Шаг 4: Создай файлы

Создай {ИмяОбъекта}.yaml по структуре из спецификации, в suggested_path из разведки
Создай каждый required companion из artifacts записи registry и уточни его структуру в object reference. Например, КонтрактСервиса всегда требует одноименный <Имя>.xbsl с абстрактными методами, даже если пользователь не просил готовую реализацию.
Optional companion создавай только когда он нужен по запросу пользователя или по object reference.

Шаг 5: Контроль доступа

Если тип объекта — Справочник, Документ, РегистрСведений или РегистрНакопления — вызови скилл xbsl-access-set, передав: - корень проекта (из результатов xbsl-explore, шаг 2) - имя только что созданного объекта (параметр --object)

Скилл сам спросит у пользователя желаемое значение ПоУмолчанию, покажет dry-run и применит изменения после подтверждения.

Для остальных supported/routed типов без object-specific правила контроля доступа — шаг пропускается. Для HttpСервис шаг не нужен: быстрый путь уже принимает флаг --access.

Шаг 6: Движения по регистру (только для Документа)

Если создаётся Документ и пользователь упоминает движения, регистр накопления, регистр сведений, приход, расход, списание, поступление, проведение — после создания .yaml вызови скилл xbsl-pattern-register.

Скилл напишет код в файл <ИмяДокумента>.Объект.xbsl (не .xbsl). Без суффикса .Объект платформа не привяжет код к объекту.