---
name: resolve-model-element
description: Использовать перед добавлением, определением, переименованием, объединением, разделением или изменением типа неоднозначного элемента производственной системы. Сначала исследует модель и источники, показывает противоречия, предлагает готовое определение, задаёт один вопрос подтверждения или коррекции и фиксирует результат только в пределах человеческого полномочия.
---

# Разрешить элемент модели

Определить, называет ли кандидат отдельный элемент живой деятельности, каким типом он представлен и нужна ли эта граница исполнителям. Не позволять красивому аналитическому слову превратиться в объект без референта.

## Обязательные контракты

Перед работой полностью прочитать:

1. references/LANGUAGE.md;
2. references/METAONTOLOGY.md;
3. references/TEMPLATE-CONTRACT.md, если затронут шаблон или его ID.

Если файлы уже прочитаны в этой задаче и не изменились, использовать прочитанное. Не исправлять язык или шаблон внутри семантического допуска.

## Вход

Собрать:

- формулировку кандидата и предполагаемый тип;
- зачем элемент нужен и какое действие, решение или контроль его использует;
- ближайший принятый срез модели и конкурирующие ID;
- точные употребления в живой работе, материалах и интерфейсах;
- текущий слой и версию;
- каноническое место записи;
- владельца смысла и полномочие подтверждающего человека.

Если операционного использования нет, сначала установить его. Термин без использования может остаться словом глоссария.

## Рабочий цикл

### 1. Открыть досье

Начать с проверяемого утверждения:

~~~text
Кандидат: «кейс привлечения»
Проверяемое утверждение: отдельный объект работы
Использование: основной объект процесса <id>
Статус: нерешённо
~~~

Не использовать само название как доказательство типа.

### 2. Исследовать контекст до вопроса

Проверить:

- принятые определения и прямые связи;
- фактические интерфейсы исполнения;
- наблюдаемые экземпляры и операционные записи;
- язык исполнителей;
- playbook, схемы, регламенты и встречи;
- решения владельцев.

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

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

### 3. Определить владеющий контекст

Термин может принадлежать:

- всей организации;
- одной производственной системе;
- конкретному процессу;
- производственному контракту между системами.

Не объединять разные локальные смыслы из-за одинакового слова. Не создавать дубликаты, если контексты обмениваются одним референтом.

### 4. Построить карту противоречий

Показать:

| Измерение | Принятое или прежнее утверждение | Конкурирующее употребление | Почему важно | Предлагаемое разрешение |
|---|---|---|---|---|

Проверить:

- одно слово для разных референтов;
- разные слова для одного референта;
- заявленный тип против фактического использования;
- несовместимые правила создания, кратности и завершения;
- фактическое исполнение против нормы или целевой модели;
- конфликт полномочий, свежести и авторитетности;
- несовместимые отношения и границы;
- различение в модели, которого нет в исполнении, и наоборот.

Если противоречий нет, перечислить проверенные измерения. Не писать только «расхождений не найдено».

### 5. Разделить слово, референт, экземпляр и запись

Явно различить:

- произносимое слово;
- реальный объект, событие, ответственность или условие;
- один экземпляр переиспользуемого процесса;
- объект работы этого экземпляра;
- CRM-карточку, запись, документ или событие, представляющие объект или исполнение;
- предлагаемый тип модели.

Особенно строго проверять слова «кейс», «эпизод», «путь», «онбординг» и «заявка».

### 6. Провести семь тестов

Использовать METAONTOLOGY.md:

1. референт;
2. идентичность;
3. трансформация и жизненный цикл;
4. представление;
5. операционное использование;
6. граница и контракт;
7. язык исполнителя.

Для предполагаемого объекта работы установить:

- событие создания;
- правило различения двух экземпляров;
- возможность нескольких экземпляров для одного человека или заказа;
- сохраняющуюся идентичность;
- закрытие, отмену, объединение и повторное открытие;
- действия и решения над ним;
- информационные представления и источник факта.

### 7. Опровергнуть свою гипотезу

Придумать минимальный сценарий, способный разрушить определение:

- два одновременных экземпляра;
- отмена и повторное открытие;
- слияние CRM-записей;
- отказ в приёмке;
- смена исполнителя;
- удаление информационного представления.

Проследить количество реальных экземпляров, сохраняющуюся идентичность, состояния, отношения и записи. Если ответ непоследователен, пересобрать определение или оставить элемент нерешённым.

### 8. Предложить готовое определение

Не просить человека определить термин с чистого листа. Подготовить пакет:

~~~text
каноническое название:
определение:
референт:
тип:
правило идентичности:
граница жизненного цикла:
включает:
исключает и контрпримеры:
синонимы:
операционное использование:
представления:
отношения и кратности:
разрешённые противоречия:
открытые противоречия:
статус знания:
рекомендуемый исход:
затронутые ID:
~~~

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

### 9. Задать один вопрос

Строить дерево зависимостей:

~~~text
контекст → референт → идентичность → тип
→ жизненный цикл → отношения → формулировка → исход
~~~

Факты искать самостоятельно. Человеку адресовать только решение или реальный пробел доказательств. Задавать самый ранний нерешённый вопрос, потому что его ответ может удалить все последующие.

Форма вопроса:

> Я нашёл <употребления>. Источники расходятся в <противоречие>, что меняет <идентичность/тип/границу>. Рекомендую определить элемент так: «<готовое определение>» и выбрать исход <исход>. Сильнейшая альтернатива — <вариант>, но она приводит к <последствие>. Подтверждаете определение или исправляете <одну решающую часть>?

Не задавать анкету. Не задавать следующий вопрос до фиксации результата текущего.

### 10. Выбрать один исход

- принять;
- принять и переименовать;
- зарегистрировать как синоним;
- разделить;
- объединить;
- изменить тип;
- вынести за границу;
- отклонить;
- оставить нерешённым;
- зафиксировать конфликт.

Заполненная строка, зелёная проверка и привычное слово не являются семантическим доказательством.

### 11. Зафиксировать подтверждение

Подтверждение распространяется только на явно показанные поля.

Если человек уполномочен и текущей интерактивной сессии явно поручена запись:

1. сразу записать точное подтверждённое определение;
2. сохранить стабильный ID, источник, владельца, тип, границу, синонимы и дату проверки;
3. показать изменение «до → после»;
4. проверить схему, словарь и ссылки;
5. перечитать записанное;
6. только затем продолжить.

Без явного полномочия сохранить предложение для рассмотрения, но не помечать его «принято».

Источник истины, полномочие, формула показателя, SLA и критерий приёмки всегда оформляются как отдельное высокорисковое решение.

Зависимые изменения процессов, схем и интерфейсов не считать автоматически подтверждёнными. Передать их в maintain-production-system только после показа границы влияния.

## Результат

Вернуть:

1. конкорданс употреблений;
2. карту противоречий;
3. владеющий контекст;
4. результат опровергающего сценария;
5. пакет определения;
6. один рекомендуемый исход и сильнейшую альтернативу;
7. один вопрос подтверждения или коррекции;
8. после ответа — записанное или подготовленное изменение и проверку;
9. затронутые ID и непроверенные последствия.

## Ограничения

- Один экземпляр процесса имеет один основной объект работы.
- Экземпляр процесса, объект работы и запись исполнения — разные возможности.
- Человек не является позицией.
- Этап воронки не является состоянием автоматически.
- Заголовок документа не является процессом.
- Неизвестно и конфликт — допустимые результаты.
- Частота употребления не принимает нормативное решение.

## Проверочные сценарии

### Неоднозначный «кейс»

Запрос: «Добавь кейс привлечения как объект всех процессов».

Хороший результат: агент сначала сравнивает процесс, экземпляр, объект и CRM-запись, показывает конфликт употреблений, проверяет повторный запуск и предлагает изменить тип либо отклонить. Строка не создаётся до подтверждения.

### CRM-название

Запрос: «В CRM это называется сделкой, значит сделка — объект работы».

Хороший результат: агент проверяет отдельную идентичность и жизненный цикл сделки и допускает возможность, что это только представление другого объекта.

### Подтверждение

Запрос: уполномоченный владелец говорит: «Подтверждаю именно это определение, продолжай».

Хороший результат: агент сначала записывает и проверяет показанные поля, а зависимые изменения оставляет отдельным набором влияния.