/metadata-modeling

name: metadata-modeling
description: "Моделирование метаданных 1С. Используй когда нужно выбрать класс объекта под бизнес-данные — справочник, документ, перечисление, план видов характеристик, константа, — типизировать реквизиты, решить про составные и определяемые типы, длину строк, предопределённые элементы, общие реквизиты, имена и представления."

Metadata Modeling

MCP routing

• Preferred path: use MCP `unica` tools `unica.view {}`, `unica.view` on the object node, `unica.apply`, `unica.view` on the subsystem node, `unica.search`, `unica.check`, and `unica.run`.
• Runtime идёт через `unica.run`: вызов без `op` отдаёт словарь операций и

контракт каждой — `argsSchema`, `execution`, `previewRequired`, `dryRunRequired`. Контракт вызова бери оттуда, а не из этого текста; при `implemented: true` используй опубликованную `argsSchema`; при `support.state: limited` разрешено только подмножество `support.supportedArgs`. При `support.state: unavailable` остановись; не выдумывай аргументов при `argsSchema: null`. Для плановой операции сначала проверь результат `dryRun: true`, затем исполняй запрос с `dryRun: false`. Preview не фиксирует входы между вызовами. Не обходи контракт прямым runner-ом.

• Use `unica.docs` with `source: "development-standard"` for the standards about modelling: 432, 468, 474, 531, 587, 603, 649, 677, 697, 704, 728, and diagnostics АПК:93, АПК:304, АПК:305, АПК:1205, АПК:1207, АПК:1210-1217, АПК:1329, АПК:1330. These are standards, not evidence of runtime behavior; confirm the wording before citing one.
• Use `unica.view` on the role node when predefined items need their interactive-deletion rights checked.
• Do not call internal analyzer, runtime, standards, or package adapters directly. They are hidden behind MCP `unica`.

Scope boundary

This skill owns **which class holds the data and how its attributes are typed**. Register internals belong to `register-design`, what a document records and when to `document-posting`, event handlers to `object-events`, code hosting to `module-placement`, and form layout to `form-patterns`.

References

• Read `../../references/platform/metadata-modeling.md` for the class choice, attribute typing, predefined items, and names and presentations.
• Read `../../references/platform/register-design.md` when the answer turns out to be a register.
• Read `../../references/platform/metadata-conventions.md` for naming, synonym, and fill-check conventions.

Core model

Ask what changes and who changes it:

• **A fact at a point in time** → document. Most documents post, and an unposted one is a draft (std603).
• **A stable list the user maintains** → catalog.
• **A fixed set known when the configuration is written** → enumeration. Its values are metadata child objects, so adding one is a configuration change and a deployment, never a user action.
• **A set of kinds the user must extend at run time** → chart of characteristic types. This is the answer whenever "the customer will add their own types later" appears and an enumeration was the first instinct.
• **One value for the whole infobase** → constant.
• **An accumulated resource or a state keyed by dimensions** → register; go to `register-design`.

A value several objects carry identically may be a common attribute (std677) rather than a repeated one.

Workflow

1. State the business question the data must answer, and who is allowed to change the set of values. That answer picks the class. 2. Check what already exists with `unica.view` (the configuration root and the object) and `unica.view` on the object node — an existing object with the same meaning is a reason to extend rather than add — and locate the owning subsystem with `unica.view` on the subsystem node. 3. Type every attribute deliberately: string length, composite type set, and whether a defined type already covers it (std432, std728, std704). 4. Decide predefined items and their update mode before creating the object, and check the interactive-deletion rights with `unica.view` on the role node (std697). 5. Create with `unica.apply` and refine with `unica.apply`, one verifiable step at a time. 6. Fill names, synonyms, and presentations; leaving both object and list presentation empty is АПК:93. 7. Verify statically with `unica.check` on the module node (test runs are outside the v0.13 surface), report runtime behavior as unverified, and search existing callers with `unica.search` when a type changed.

Design rules

• A composite attribute used in joins, filters, or sorting contains only reference types. Mixing in `Строка`, `Число`, `Дата`, `УникальныйИдентификатор`, `Булево`, `ХранилищеЗначения` slows those queries markedly (std728, АПК:1329).
• To combine a reference with free text, add a separate catalog for the free values instead of a primitive type, fill it automatically on write, and clean it with a scheduled job.
• Do not use `ЛюбаяСсылка`, `СправочникСсылка`, `ДокументСсылка` on stored objects; list the types explicitly (АПК:1330). An over-wide composite joins every table in the type on dotted access without `ВЫРАЗИТЬ`, forces restructuring when a referenced object is deleted, and makes marked-object deletion pay more for reference search and locks.
• String attributes use variable allowed length with a maximum set. Fixed length is only for a genuine equal-length guarantee (std432, АПК:1205). Unlimited length is for large user text and for machine-generated technical strings.
• A type used widely and likely to change on implementation becomes a defined type once, not a copy per use site (std704).
• Predefined items are created automatically: keep `ОбновлениеПредопределенныхДанных = Авто` and do not flip it from code (std697, АПК:304, АПК:305). In a subordinate distributed-infobase node they arrive from the main node, so update handlers that fill them run only in the main node.
• A presentation equal to the synonym is not stored, so setting it to the same text achieves nothing (АПК:1210 and its si