---
name: maintain-production-system
description: Использовать для контролируемого изменения существующей производственной системы после решения владельца, подтверждённого расхождения, принятого целевого изменения или изменения исполнения. Повторно допускает изменившиеся элементы, рассчитывает влияние, выпускает неизменяемую версию, решает миграцию активных экземпляров и синхронизирует реестр, схемы, playbook, регламенты и интерфейсы.
---

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

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

Сопровождение начинается с проверяемого изменения и полномочия, а не с редактирования самой свежей строки.

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

Полностью прочитать:

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

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

## Вход

Потребовать:

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

Без принятого решения выполнять только исследование и карту влияния. Реплика на встрече и правка документа не становятся действующей системой автоматически.

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

### 1. Классифицировать изменение

Выбрать один основной класс:

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

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

### 2. Повторно разрешить изменившийся смысл

Запустить resolve-model-element для каждого:

- нового элемента;
- изменения типа;
- разделения;
- объединения;
- вынесения за границу;
- смыслового переименования;
- изменения правила идентичности.

Редакционное переименование может сохранить ID, только если референт, жизненный цикл, использование и связи не изменились.

Не сохранять плохую абстракцию только ради удобного ID. Не создавать новый ID при простом изменении названия.

### 3. Построить карту влияния

От каждого затронутого ID пройти входящие и исходящие зависимости:

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

Каждую зависимость классифицировать:

- обязательно изменить;
- обязательно проверить;
- пересобрать представление;
- не затронуто — с причиной.

Показать карту до записи.

### 4. Спроектировать версию

Для смыслового изменения создать новую version_id. Принятая версия неизменяема.

Сохранить ID, если референт переживает изменение. Заменить или вывести ID, если изменилась идентичность.

Зафиксировать:

- «до → после»;
- основание;
- решение владельца;
- дату вступления;
- слой;
- затронутые элементы;
- совместимость;
- способ восстановления;
- дату следующей проверки.

### 5. Решить судьбу активных экземпляров

Выбрать явно:

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

Указать:

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

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

### 6. Подготовить ограниченный набор изменений

Показать по авторским листам:

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

Не удалять историческое свидетельство и не переписывать прошлую версию ради аккуратного вида.

### 7. Получить человеческий допуск

Сверить показанный набор с решением владельца. Подтверждение одной формулировки не разрешает скрытые зависимые изменения.

Особо подтвердить:

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

Без подтверждения оставить набор предложением.

### 8. Записать в порядке зависимостей

Следовать TEMPLATE-CONTRACT.md:

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

### 9. Проверить поведение

Повторно проиграть затронутые:

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

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

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

Затем проверить «Проверки», «Реестр процессов», «Рабочую панель» и «Проекцию draw.io».

### 10. Синхронизировать представления

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

- пересобрать реестр;
- обновить draw.io по стабильным ID;
- обновить playbook;
- обновить исполнительские регламенты;
- привести интерфейсы исполнения в соответствие;
- обновить обучение, отчёты и контрольные панели;
- пометить недоступные для обновления представления как расхождение с владельцем и сроком.

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

### 11. Подтвердить ввод

Целевая версия становится текущей только после:

1. решения владельца;
2. реализации в производственной системе и интерфейсах;
3. свидетельства живого исполнения по новой модели.

До этого сохранять разделение текущей и целевой модели.

## Результат

Вернуть:

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

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

- Нет принятия — нет изменения принятой модели.
- Принятая версия не редактируется на месте.
- Новое имя не требует нового ID.
- Новая идентичность не использует старый ID.
- Текущая и целевая модели не смешиваются до ввода.
- Высокорисковые поля рассматриваются отдельно.
- Представления следуют за моделью.
- Ограничение языка или шаблона не обходится заметкой.

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

### Разделение объекта

Запрос: «Подтвердили, что два вида работы создают отдельные экземпляры. Обнови общий объект».

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

### Сначала изменился регламент

Запрос: «Владелец изменил срок в документе. Сделай систему текущей».

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

### Обновить всё зависимое

Запрос: «Изменение модели принято. Обнови всё».

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