---
name: model-production-system
description: Использовать для первичной сборки, наполнения или расширения производственной системы в готовом каноническом шаблоне из принятых определений и проверяемых свидетельств. Моделирует продукт и приёмку, объекты и состояния, процессы и действия, позиции, решения, контракты, контроль и связи для схем, не меняя язык и структуру шаблона.
---

# Собрать производственную систему

Построить версионную модель, по которой люди способны работать, агент — сопровождать, а реестр и draw.io — строить представления из одних стабильных ID.

Результат не равен заполненной таблице. Он должен позволять проиграть исполнение без устных дополнений.

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

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

1. references/LANGUAGE.md;
2. references/METAONTOLOGY.md;
3. references/TEMPLATE-CONTRACT.md;
4. references/PROJECTION-CONTRACT.md.

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

## Вход

Установить:

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

Документ, встреча, интерфейс, схема и регламент могут содержать свидетельства. Они не становятся второй канонической моделью.

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

### 1. Проверить шаблон

До записи прочитать:

- «Инструкция»;
- «Система»;
- «Схема шаблона»;
- «Версии»;
- связанные авторские строки;
- вычисляемые проверки.

Сверить заголовки, словари, формулы, проверки данных и связи R-* с TEMPLATE-CONTRACT.md. При расхождении остановить запись и показать drift контракта.

### 2. Задать систему от продукта назад

Установить:

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

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

### 3. Пройти исполнение вперёд

Построить второй путь:

~~~text
триггер
→ входящий объект или вход
→ первое ответственное действие
→ решения, передачи и исключения
→ конечный выход
→ приёмка или мотивированный отказ
~~~

Сопоставить его с продуктовым путём. Если они не встречаются, найдена выдуманная деятельность или недостающая производственная связь.

### 4. Составить инвентарь кандидатов

Извлечь:

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

Сохранить точные слова исполнителей и локаторы источников. Дедуплицировать по принятым ID.

Инвентарь ещё не является моделью. Каждый новый или изменивший тип элемент с неясным референтом, идентичностью, границей или использованием провести через resolve-model-element.

### 5. Смоделировать объекты и жизненные циклы

Для каждого допущенного объекта определить:

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

Различать:

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

Не выбирать объектом таблицу, которую редактирует сотрудник. Не выбирать человека только потому, что работа касается человека. Не создавать «кейс» как объект, если он означает одно исполнение.

### 6. Выделить процессы

Процесс готов к записи, если имеет:

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

Подпроцесс использовать для связного локального преобразования. Для навигации использовать группировку, не превращая каждый этап в процесс.

### 7. Разложить действия

Одно действие содержит:

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

Разделить формулировку, если:

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

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

### 8. Построить граф действий

Явно представить:

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

Не прятать ветку в коротком описании. Каждый не терминальный узел имеет исходящую связь. Каждый узел достижим от начала.

### 9. Смоделировать позиции и назначения

Позиция описывает устойчивую ответственность. Конкретного человека или ИИ-агента связывать через «Назначения» с периодом и статусом.

Автоматизация выполняет действие от имени позиции и не заменяет её ответственность. ИИ-агент занимает позицию только при явной передаче ответственности.

### 10. Смоделировать передачи и контракты

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

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

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

### 11. Добавить контроль

Добавлять только доказанные:

- правила;
- данные;
- источники истины;
- информационные системы;
- интерфейсы;
- показатели;
- нормативы;
- SLA;
- автоматизации;
- материалы.

У показателя фиксировать формулу, единицу, период, источник факта и владельца. У SLA — событие начала, окончания, календарь, паузы и последствия нарушения.

### 12. Подготовить набор записи

Показать строки «создать / изменить / заменить» по стабильным ID и авторским листам.

Писать в порядке TEMPLATE-CONTRACT.md:

1. система и версия;
2. позиции;
3. объекты и состояния;
4. процессы;
5. действия и связи;
6. переходы;
7. контрольные элементы;
8. контракты и связи;
9. диаграммы.

Брать значения из живых словарей «Системы». Честно использовать «кандидат», «гипотеза», «конфликт» и «неизвестно». Не помечать собственное предложение как «принято».

### 13. Проиграть сценарии

Минимум:

1. нормальный экземпляр от триггера до принятого продукта;
2. отказ или исключение;
3. возврат, исправление, тайм-аут или повторное открытие, если допустимо.

На каждом шаге назвать:

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

Фраза «дальше как-то происходит» означает дефект модели.

### 14. Проверить структуру и проекции

Перечитать записанные строки. Проверить:

- «Проверки»;
- «Реестр процессов»;
- «Рабочую панель»;
- «Проекцию draw.io»;
- достижимость графа;
- внешние ключи;
- полноту веток;
- стабильность ID узлов, рёбер и дорожек.

Зелёные формулы не закрывают семантическую неизвестность.

## Результат

Вернуть:

1. границу, продукт и контракт приёмки;
2. список допущенных и нерешённых элементов;
3. изменения по авторским листам;
4. иерархию процессов;
5. исполнимые пути действий;
6. результаты проигрывания;
7. структурные проверки;
8. готовность проекции draw.io;
9. список представлений и интерфейсов, которые должны быть построены из версии;
10. решения владельца и дату следующего пересмотра.

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

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

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

### Богатый playbook

Запрос содержит действия «принять поставку», «назначить ответственность», «проверить карточку и источник».

Хороший результат: сохранить рабочие глаголы, определить объекты, позиции, состояния, решения и доказательства. Не сворачивать всё в абстрактный процесс «обработать квалифицированные входящие кейсы».

### Норма не доказывает исполнение

Запрос: «Регламент требует три дня, пометь текущий процесс соответствующим».

Хороший результат: записать требование как норматив или SLA, отдельно искать факт исполнения и не объявлять текущую практику соответствующей по одному документу.

### Безопасная таблица

Запрос: «Наполни модель и обнови схемы».

Хороший результат: писать только авторские листы, сохранить формулы, затем проверить реестр и draw.io по стабильным ID.