---
name: audit-production-system
description: Использовать для независимого read-only аудита существующей модели или шаблона производственной системы. Ищет выдуманные элементы, смешение объекта и данных, неполную логику процессов, разрывы графа действий и состояний, смешение текущего и целевого, слабые полномочия и доказательства, слепые зоны и устаревшие схемы или документы, не изменяя модель.
---

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

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

Не исправлять найденное внутри аудита.

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

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

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

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

## Вход и граница

Определить:

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

Не называть аудит полным, если проверен один документ или один процесс.

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

### 1. Зафиксировать read-only базу

Прочитать:

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

Зафиксировать количество элементов и ID без записи. Проверить сохранность формул, словарей и валидации.

### 2. Отдалиться до производственного контракта

Проверить:

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

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

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

Провести сокращённый допуск для:

- объектов;
- состояний;
- процессов;
- действий;
- позиций;
- решений;
- правил;
- систем;
- показателей;
- контрактов.

Полное досье resolve-model-element рекомендовать, если идентичность или тип сомнительны.

Искать:

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

Аудит формулирует дефект, но не изобретает замену без достаточных свидетельств.

### 4. Проверить процессы

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

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

Флагировать:

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

### 5. Проверить действия

Для каждого действия установить:

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

Флагировать:

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

### 6. Проиграть исполнение

Минимум:

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

На каждом шаге проследить:

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

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

### 7. Проверить передачи и ожидание

Для каждого стыка установить:

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

Смена статуса отправителем не доказывает завершённую передачу.

### 8. Провести sweep слепых зон

Исследовать, но не добавлять автоматически:

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

Классифицировать:

- подтверждённо отсутствует;
- вероятно отсутствует;
- только вопрос для исследования.

Чек-лист не является свидетельством существования процесса.

### 9. Проверить управление истиной

Проверить:

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

Флагировать текущее утверждение, которое поддерживается только предписанием, схемой или старой встречей.

### 10. Проверить структуру

Проверить:

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

Отделить структурную зелень от семантической корректности.

### 11. Проверить представления

Для реестра, draw.io, playbook, регламента и интерфейса сравнить:

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

Не перерисовывать схему в ходе аудита.

### 12. Ранжировать и остановиться

Формат finding:

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

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

Рекомендовать:

- неоднозначная идентичность или тип → resolve-model-element;
- отсутствующая первичная модель → model-production-system;
- принятое исправление существующей версии → maintain-production-system;
- ограничение языка или шаблона → отдельное решение владельца.

## Результат

Вернуть:

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

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

- Read-only означает отсутствие правки строк, формул и статусов.
- Различать факт, вывод, гипотезу и недоступное свидетельство.
- Не добавлять элементы из одного чек-листа.
- Не предполагать заранее, что CRM-запись является или не является объектом.
- Не считать красивое определение доказательством референта.
- Finding объясняет механизм и последствие, а не только пустую ячейку.

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

### Все формулы зелёные

Запрос: «Проверки зелёные. Модель хорошая?»

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

### Что забыли документы

Запрос: «Найди всё, чего нет в playbook».

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

### Устаревшая схема

Запрос: «Актуальна ли схема первого процесса?»

Хороший результат: сравнить ID и version_id с авторскими строками, показать лишние и отсутствующие узлы, но не рисовать новую схему.