Производственный процесс 2.3.1

# Производственный процесс 0xExqui.OS 2.3.1

ПрП означает «производственный процесс». Product Owner рекомендует тип новой работы, владелец принимает решение:

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

До создания документов или изменения кода Product Owner сообщает: `тип работы; применяемый цикл`. Если ответ уже дан владельцем или действующими документами, повторять вопрос не нужно. Иначе тип выбирает владелец. Delivery первого продуктового эпика нельзя начинать до закрытия EPIC-000 и согласования DoR этого эпика.

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

Каждый продуктовый эпик проходит полный цикл:

**Discovery → Pre-Challenge → DoR → Delivery → Challenge → DoD → Rollout → Closure → Работа над ошибками**

EPIC-000 проектирует весь проект и проходит сокращённый цикл:

**Project Discovery → Project Challenge → DoR проекта → Closure → Работа над ошибками**

EPIC-000 не имеет Delivery, DoD и Rollout.

## Решения владельца

Для продуктового эпика владелец принимает три управленческих решения:

1. **«DoR согласован»** — результат, истории и границы эпика приняты; начинается Delivery.
2. **После DoD** — при положительном DoD владелец разрешает Rollout; при отрицательном возвращает эпик в Discovery с новым DoR, разделяет оставшуюся работу либо останавливает эпик.
3. **«Эпик закрыт»** — Closure и «Работа над ошибками» приняты. Закрытие последнего эпика завершает проект.

Для EPIC-000 владелец согласует тип работы, истории с критериями и DoR проекта, а после обязательной «Работы над ошибками» закрывает эпик.

Команда **«Действуй автономно до конца»** разрешает без нового сообщения перейти от положительного DoD к неизменившемуся Rollout, уже описанному в DoR, и закрыть эпик после обязательных докладов. Она не отменяет вопросы Discovery, согласование историй, критериев и DoR и не действует при отрицательном DoD, блокере, новом риске или изменении границ либо Rollout. Без отдельного решения нельзя удалять реальные данные, совершать покупки, связываться с третьими сторонами, менять секреты, права или доступ из интернета, перезагружать систему либо выполнять несогласованное административное действие.

После создания `PROJECT.md` решение владельца по проекту или эпику записывается туда до выполнения.

## Документы

### Общие для всей системы

- `AGENTS.md` — режимы работы и роли команды.
- `ENGINEERING.md` — действующий ПрП после его согласования владельцем.
- `README.md` — работающие возможности и способ использования системы.
- `ARCHITECTURE.md` — компактная карта действующей системы: компоненты, способы доступа и запуска active-сервисов, данные, интеграции, зависимости и статус `active` или `legacy`.
- `RISKS.md` — единый реестр всех подтверждённых рисков; его ведёт CyberSec, а оценку риска даёт ответственная за область роль.
- `PROCESS-ISSUES.md` — единый реестр подтверждённых проблем ПрП; его ведёт руководитель производственного процесса.
- `CHANGELOG.md` — только завершённые изменения.

`ARCHITECTURE.md`, `RISKS.md` и `PROCESS-ISSUES.md` находятся выше всех проектов. Планируемая архитектура хранится не в `ARCHITECTURE.md`, а в `DESIGN.md` соответствующего проекта.

### Для проекта

Каждый проект хранится в едином каталоге `projects/<project>/`. EPIC-000 создаёт в нём ровно три документа:

- `PROJECT.md` — цель, границы, общие требования к продукту, исходные просьбы владельца, все согласованные истории с критериями приёмки и решения владельца;
- `DESIGN.md` — крупный продуктовый и технический дизайн всего проекта: компоненты, данные, интеграции, интерфейс, переиспользование, security и эксплуатация;
- `ROADMAP.md` — связь идентификаторов историй с эпиками, результаты эпиков, зависимости, порядок, примерные оценки и состояние.

Пользовательская история полностью описывается только в `PROJECT.md`; `ROADMAP.md` ссылается на её идентификатор.

EPIC-000 полностью проектирует проект, но не создаёт `DESIGN.md` и `PLAN.md` будущих эпиков. Детали конкретного эпика проектируются только в его Discovery.

### Для эпика

- `projects/<project>/epics/NNN/DESIGN.md` — точный продуктовый и технический дизайн текущего эпика;
- `projects/<project>/epics/NNN/PLAN.md` — план его реализации, проверки и Rollout.

`epics/` — каталог, внутри которого каждый эпик имеет собственный каталог с номером.

Документы завершённого эпика сохраняются как история и не переписываются следующим эпиком.

Номер записи общего реестра не меняется и не используется повторно. Перед интеграцией параллельная ветка сверяет каждый общий или проектный документ с целевой веткой и объединяет только принадлежащие своей инициативе записи и разделы; заменять целый файл устаревшей копией запрещено. Новый межпроектный `CRITICAL` немедленно предъявляется владельцу.

## Изоляция работы

В начале работы, после восстановления контекста и перед первым изменением Codex фиксирует: `режим; тип работы; источник ПрП; проект и эпик; ветка; worktree`. Названная владельцем версия ПрП берётся только из неизменяемого файла, commit или контрольной суммы.

Каждая параллельная инициатива работает в собственном `.worktrees/<initiative>`; общий каталог не переключается на её ветку. Если правильный worktree уже существует, используется он. Пока соответствие не подтверждено, разрешены только read-only действия.

Основной агент полностью читает `AGENTS.md`, `ENGINEERING.md`, документы текущего проекта и эпика и относящиеся записи общих реестров. Ролевой субагент получает режим, источник ПрП, свою роль, проверяемую версию, истории и доказательства; весь диалог без необходимости не передаётся.

## Superpowers и субагенты

Superpowers самостоятельно выбирает подходящие навыки. ПрП задаёт только границы фаз, ожидаемый результат и решения владельца и не повторяет внутренние инструкции навыков.

Субагент — отдельно запущенный Codex, а не роль или навык. Ролевые субагенты запускаются только в Project Challenge, Pre-Challenge и Challenge; руководитель производственного процесса дополнительно выполняет «Работу над ошибками» после Closure. В остальных фазах действует основной агент; упоминание роли не запускает нового.

На весь эпик создаётся не более одного субагента на роль; в следующих контрольных точках и повторах используется тот же. Между проверками субагент не работает. Замена при недоступности фиксируется руководителем процесса. Ролевые проверки идут последовательно. В Delivery Superpowers может использовать до трёх параллельных субагентов для независимых задач. Вложенные субагенты запрещены.

## Роли и доклады

Цели, ответственность, принципы и полномочия ролей определены в `AGENTS.md`. Проверяющая роль независимо оценивает только свою область, не исправляет проверяемый результат и не подменяет другую роль.

Каждая проверяющая роль возвращает: `проверенная версия; PASS/FAIL; доказательства; блокеры`. Product Owner передаёт вердикты без изменения смысла. Доклад сохраняется во время проверки; позднее восстановление помечается как ретроспектива и не может заменить отсутствующий PASS. Основной агент ведёт в `PROJECT.md` краткий журнал фаз, циклов, возвратов и субагентов.

## 0. Project Discovery — спроектировать проект

В EPIC-000 основной агент применяет brainstorming и:

1. Задаёт вопросы, пока не выяснены цель, границы, исходные просьбы и общие требования проекта: целевые устройства, внутренний или внешний контур, каналы и URL доступа владельца, данные, интеграции, требования к интерфейсу, эксплуатации и безопасности. Фиксированного лимита вопросов нет.
2. Формулирует полный список пользовательских историй и связывает с ними каждую исходную просьбу без потери или сужения смысла.
3. Product Owner предъявляет владельцу общие требования и весь список историй; Project Discovery не продолжается, пока владелец явно не согласовал их.
4. После этого Product Owner по каждой истории спрашивает: «Как вы поймёте, что получили то, что хотели?» Ответ владельца дословно или без изменения смысла становится критерием приёмки. Без ответа по каждой истории Project Challenge не начинается.
5. Проектирует целое решение в крупную клетку и определяет компоненты, данные, интеграции, интерфейс, переиспользование, security и эксплуатацию.
6. Разбивает истории на эпики, определяет зависимости, порядок и примерные оценки.
7. Создаёт `PROJECT.md`, `DESIGN.md` и `ROADMAP.md`.

Если проект содержит интерфейс, brainstorming отдельно запрашивает желаемый интерфейс, референс или файл с дизайн-рекомендациями.

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

### Project Challenge

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

1. Арт-директор, если предусмотрен интерфейс.
2. CTO.
3. Главный администратор.
4. CyberSec.
5. Руководитель производственного процесса.
6. Product Owner — последним.

Роли не исправляют документы во время проверки. Product Owner объединяет блокеры в одну волну возврата в Project Discovery.

Разрешено всего три Project Challenge, включая первый. В повторном цикле те же субагенты проверяют прежние блокеры и затронутые исправлениями области; руководитель процесса и Product Owner участвуют всегда, Product Owner — последним. К DoR проекта можно перейти только после цикла без блокеров. После третьего автономная серия заканчивается: владелец останавливает или разделяет проект либо явно начинает новую серию Project Discovery с изменёнными границами или решением; её циклы считаются заново. Security-FAIL принять нельзя.

После завершения Project Challenge Product Owner предъявляет владельцу цель, границы, общие требования, истории и их критерии приёмки, дизайн проекта, эпики, зависимости, оценки, риски и открытые вопросы. Ответ **«DoR проекта согласован»** принимает проект. Затем EPIC-000 проходит Closure и «Работу над ошибками» без реализации будущих эпиков.

## 1. Discovery — понять и спроектировать эпик

Основной агент читает документы проекта, общую карту действующей системы и относящиеся к эпику код, runtime и данные. Затем применяет brainstorming, чтобы уточнить назначенные эпику истории, пользовательский путь и общие требования, затронутые этим эпиком. Фиксированного лимита вопросов нет.

Product Owner связывает каждую просьбу владельца с историей в `PROJECT.md`, предъявляет владельцу полный список историй эпика и получает явное согласие по каждой. Затем по каждой истории задаёт вопрос: «Как вы поймёте, что получили то, что хотели?» — и записывает ответ как критерий приёмки в `PROJECT.md`. Непокрытая или несогласованная просьба, история без ответа владельца либо новая история возвращает работу в Discovery.

Если эпик затрагивает интерфейс, brainstorming отдельно запрашивает требования владельца, референс или файл с дизайн-рекомендациями.

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

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

Собственная разработка допускается только после доказательства, что готового решения недостаточно. Если документации недостаточно, основной агент может автономно выполнить до трёх безопасных изолированных read-only прототипов. Каждый прототип отвечает на один открытый вопрос; после получения ответа попытки прекращаются. Прототипы не меняют production, реальные данные, секреты, внешние последствия, результат или границы эпика.

Результат Discovery:

- `DESIGN.md` с идентификаторами историй и ссылками на их критерии в `PROJECT.md`, а также результатом, границами, пользовательским путём, интерфейсом, данными, интеграциями, переиспользованием или удалением старого, проверками, мониторингом, восстановлением и security;
- `PLAN.md` с необходимыми шагами реализации, проверки и Rollout.

Для сервиса `DESIGN.md` и `PLAN.md` однозначно задают целевой контур, место установки, устройства и каналы доступа владельца, адрес или способ его назначения, запуск, перезапуск, проверку работоспособности, мониторинг и откат. Неизвестный конечный путь — блокер Pre-Challenge, а не задача на Rollout.

### Pre-Challenge

Готовые `DESIGN.md` и `PLAN.md` последовательно и независимо проверяют:

1. Арт-директор, если изменяется интерфейс.
2. CTO.
3. Главный администратор.
4. CyberSec.
5. Руководитель производственного процесса.
6. Product Owner — последним.

Роли применяют `AGENTS.md` и не исправляют документы во время проверки. Product Owner объединяет блокеры в одну волну возврата в Discovery.

Разрешено всего два Pre-Challenge, включая первый. В первом участвуют все предусмотренные роли. В повторном те же субагенты проверяют прежние блокеры и затронутые исправлениями области; руководитель процесса и Product Owner участвуют всегда, Product Owner — последним. К DoR можно перейти только после цикла без блокеров. После второго автономная серия заканчивается: владелец останавливает или разделяет эпик либо явно начинает новую серию Discovery с изменёнными границами или решением; её циклы считаются заново. Security-FAIL принять нельзя.

## 2. DoR — согласовать эпик

Product Owner предъявляет владельцу короткое управленческое описание:

1. Какой результат получит владелец.
2. Что входит и не входит в эпик.
3. Какие истории, критерии приёмки и полный путь будут реализованы.
4. Как устроено решение, что переиспользуется и почему выбран этот вариант.
5. Как результат будет проверен и безопасно выведен в production с возможностью восстановления.
6. Какие риски, отклонения и открытые вопросы требуют решения владельца.

CyberSec отдельно сообщает изменения в `RISKS.md`. Руководитель производственного процесса сообщает количество циклов и возвратов Pre-Challenge. Выбор навыков и субагентов не входит в DoR.

Ответ **«DoR согласован»** принимает описанный эпик и запускает автономную Delivery.

## 3. Delivery — реализовать эпик

После согласования DoR основной агент автономно реализует `PLAN.md` текущего эпика с помощью Superpowers. Необязательная новая идея не прерывает Delivery, не реализуется и передаётся Product Owner для решения владельца.

До Rollout нельзя изменять действующую production-систему, реальные данные и реальные внешние последствия. Работа останавливается только тогда, когда выполнить DoR невозможно без его изменения или обнаружен новый существенный риск, требующий решения владельца.

`Implementation complete` означает, что Superpowers по своим правилам закончил реализацию `PLAN.md` текущего эпика. Для ПрП это означает только готовность начать Challenge: эпик ещё не принят, ветка не завершена, production не изменён.

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

## 4. Challenge — независимо проверить реализацию

Роли независимо проверяют готовую реализацию в своей области.

Перед Challenge основной агент фиксирует commit реализации и работающий экземпляр. В течение одного цикла они не изменяются. Вердикт Challenge не входит в проверяемый пользовательский результат и не создаёт новую версию реализации.

Проверку последовательно проводят:

1. Арт-директор, если изменён интерфейс.
2. CTO.
3. Главный администратор.
4. CyberSec.
5. Руководитель производственного процесса.
6. Product Owner — последним.

Product Owner сопоставляет исходные просьбы, все истории и критерии приёмки с работающим результатом и проверяет реальные интеграции через безопасный для данных и внешних последствий доступ. Основной агент выполняет все проверки, которые способен выполнить; проверки, требующие личного действия или восприятия владельца, перечисляются отдельно и не считаются выполненными за него. Арт-директор проверяет точный работающий интерфейс на всех согласованных устройствах и размерах. Остальные роли применяют свои области, вопросы и полномочия из `AGENTS.md`.

Главный администратор проверяет конечный путь из целевого контура: внутренний сервис — по внутреннему адресу, внешний — независимым обращением к публичному адресу. Сам факт, что production не изменён, не является эксплуатационным PASS. Недоступный или неизвестный владельцу путь — FAIL.

Один цикл Challenge не останавливается на первом FAIL, а реализация во время проверки не исправляется. FAIL означает блокер в области роли; неблокирующее замечание фиксируется, но не меняет вердикт на FAIL. Product Owner собирает все блокеры в одну волну.

Блокер реализации возвращает работу в Delivery. Если требуется изменить историю или DoR, автономный Challenge заканчивается; Product Owner отражает это в отрицательном DoD, после которого владелец может вернуть работу в Discovery.

Разрешено всего три Challenge, включая первый. В первом участвуют все предусмотренные роли. В повторном участвуют прежние FAIL, затронутые исправлениями роли, руководитель процесса и Product Owner последним; неизменившийся PASS сохраняется. Между циклами основной агент исправляет общую волну в Delivery, а Superpowers снова доводит реализацию до `Implementation complete`. Четвёртый Challenge не начинается.

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

Challenge заканчивается после цикла без блокеров либо после исчерпания автономных циклов исправления. Затем Product Owner в любом случае представляет DoD.

## 5. DoD — подвести итог сделанной работы

DoD — итог сделанной работы после всех проведённых циклов Challenge. Он может быть положительным или отрицательным.

Product Owner сообщает:

1. Каждую историю, её критерий приёмки, способ проверки и фактический статус.
2. Что выполнено, что не выполнено и какие есть отклонения от DoR.
3. Итоги всех проверяющих ролей и оставшиеся дефекты.
4. Какие необязательные идеи предлагается перенести в другие эпики.
5. Что именно будет сделано в Rollout либо какое решение требуется при отрицательном результате.

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

Проверки, доступные только владельцу, Product Owner перечисляет в DoD отдельно. Владелец выполняет их сам; без его результата соответствующая история не подтверждена и DoD не может быть положительным.

Product Owner разделяет оставшиеся дефекты на блокирующие принятые истории и безопасные неблокирующие. Блокирующий дефект делает DoD отрицательным. Безопасный неблокирующий дефект указывается в положительном DoD; только владелец решает, принять ли его и куда перенести. До этого решения Rollout не начинается.

Если результат должен открываться или запускаться владельцем, до положительного DoD Product Owner и главный администратор проверяют его в безопасно изолированном экземпляре тем же способом, который предназначен владельцу. Путь, доступный только из среды разработки, не принимается.

DoD положительный, если все принятые истории подтверждены и у проверяющих ролей нет других блокеров. Иначе DoD отрицательный.

При положительном DoD владелец разрешает описанный Rollout. При отрицательном DoD владелец решает: вернуть текущий эпик в Discovery с новым DoR, разделить оставшуюся работу или остановить эпик. Весь проект пересматривается только при изменении его цели, общей архитектуры или зависимостей эпиков. Четвёртый Challenge по прежнему DoR не начинается; Rollout при отрицательном DoD запрещён.

Способ завершения ветки указывается в `PLAN.md`. После разрешения Rollout Superpowers применяет `finishing-a-development-branch`; если способ не согласован, выбор делает владелец. Проверенный commit сохраняется для Rollout, а worktree — до Closure. Внутренние инструкции навыка в ПрП не повторяются. Любое изменение реализации после DoD требует нового Challenge и нового DoD.

## 6. Rollout — изменить работающую систему

В production переносится тот же commit реализации, который был проверен в Challenge и принят положительным DoD, без дополнительных исправлений.

1. Главный администратор проверяет действующую стабильную версию, возможность восстановления и состояние системы, затем выполняет установку или обновление.
2. Product Owner выполняет production smoke полного основного пользовательского пути и реальных интеграций.
3. Главный администратор проверяет запуск, перезапуск, данные, мониторинг, ресурсы и работоспособность соседних сервисов.
4. Product Owner предъявляет владельцу результат и точный конечный путь в привычной форме использования. Это итоговый доклад, а не повторная приёмка или новый цикл.

Codex не должен остановить сам себя перезапуском и ждать нового сообщения владельца. Если операция может прервать работу Codex, сначала запускается независимый процесс, который завершит операцию, проверит результат, выполнит восстановление при сбое и сохранит отчёт. Способ запуска, проверка успеха, восстановление и место отчёта заранее записываются в `PLAN.md`.

Если Rollout вызвал сбой, сначала восстанавливается предыдущая стабильная версия и фиксируется инцидент. Если DoR не меняется и лимит Challenge не исчерпан, работа возвращается в Delivery, затем проходит новый Challenge и DoD. Иначе Product Owner выдаёт отрицательный DoD, а решение принимает владелец. При остановке Closure разрешён только после подтверждённого восстановления.

## 7. Closure — привести систему и документы к факту

Для обычного эпика Closure начинается после успешного Rollout. Если Rollout прямо исключён согласованными границами либо владелец остановил эпик после отрицательного DoD, Closure начинается без Rollout и фиксирует фактический результат и отсутствие изменений production. Для EPIC-000 Closure начинается после согласования DoR проекта.

Основной агент:

1. Обновляет `README.md` только работающими возможностями.
2. Обновляет общий `ARCHITECTURE.md` фактическими компонентами, способами доступа и запуска, данными, интеграциями, зависимостями и статусами `active` или `legacy`.
3. Обновляет состояние проекта в `PROJECT.md` и `ROADMAP.md`.
4. В обычном эпике закрывает выполненные пункты `PLAN.md` и сохраняет `DESIGN.md` и `PLAN.md` как историю. В EPIC-000 окончательно проверяет `PROJECT.md`, `DESIGN.md` и `ROADMAP.md` и отмечает: «Closure завершён, ожидается Работа над ошибками».
5. Обновляет `RISKS.md`, `PROCESS-ISSUES.md` и `CHANGELOG.md` только по подтверждённым фактам.
6. Проверяет состояние системы и удаляет только собственные ненужные временные артефакты.

Документы будущих эпиков в Closure не создаются и не переписываются.

Product Owner сообщает полученный результат и следующий эпик. CyberSec сообщает только факты, изменившиеся после DoD, и не повторяет прежний вердикт.

## 8. Работа над ошибками — улучшить следующий цикл

После Closure тот же субагент руководителя производственного процесса независимо:

1. Подводит итоги циклов, возвратов, задействованных субагентов и повторной работы.
2. Выявляет подтверждённые причины лишней работы и нарушения ПрП.
3. Обновляет `PROCESS-ISSUES.md`, сохраняя исходные факты и перенося исправленные записи в архив с версией ПрП.
4. Предлагает владельцу только подтверждённые изменения процесса; без решения владельца новые правила и проверки не появляются.

Отсутствующий в исходном цикле доклад нельзя задним числом представить как выполненную фазу: ретроспектива помечается отдельно. До этого доклада эпик не закрыт.

После доклада владелец принимает решение **«Эпик закрыт»**; при действующей команде «Действуй автономно до конца» основной агент фиксирует закрытие после обязательных докладов. Статус записывается в `PROJECT.md` и `ROADMAP.md`. В последнем эпике он завершает проект.

## Архитектурные принципы

1. **Server-first.** Production работает на VPS без компьютера владельца.
2. **AI через Codex.** AI-запросы выполняются через Codex с ChatGPT-аутентификацией; недоступность Codex не останавливает остальные функции.
3. **Изоляция и явные границы.** Сбой, перезапуск или исчерпание ресурсов одного сервиса не останавливают SSH и другие сервисы; неизвестный вход безопасно отклоняется, а очереди, повторы, фоновые процессы и внешние вызовы ограничены и восстанавливаемы.
4. **Владение и жизненный цикл.** Каждый сервис владеет своим процессом и каноническими данными; writable storage, cache, releases и временные артефакты имеют владельца, измеримый resource budget, наблюдаемые current/peak и условие удаления.
5. **Один минимальный механизм.** Существующая реализация переиспользуется, исправляется, упрощается или удаляется вместо создания параллельной; добавляется только необходимое для DoR.
6. **Целостность данных.** Вход проверяется до записи; повтор, сбой и восстановление не теряют и не дублируют данные.
7. **Приватность.** Личные данные и секреты не попадают в Git, status и логи; доступ выдаётся по минимальной необходимости.

## Дизайн-принципы

1. **Цель истории.** Каждый экран, состояние и действие служат согласованному результату истории.
2. **Полнота состояний.** Предусмотрены все необходимые начальные, пустые, рабочие, успешные и ошибочные состояния.
3. **Визуальная иерархия.** Главное содержание и основное действие распознаются первыми.
4. **Единообразие.** Одинаковые элементы, состояния и действия выглядят и работают одинаково.
5. **Понятные действия.** До действия ясны его назначение, доступность и последствия.
6. **Понятные тексты.** Тексты кратки, однозначны и используют язык владельца.
7. **Функциональная минимальность.** Интерфейс не содержит элементов без пользы для истории.

## Производственные принципы

1. **Решение владельца.** Владелец определяет тип работы, принимает границы, истории, Rollout и закрытие.
2. **Работа в границах.** Выполняется только запрос владельца и согласованный DoR.
3. **Необязательное не мешает обязательному.** Новая идея не прерывает Delivery и предлагается как продолжение.
4. **Разделение ответственности.** Каждая роль проверяет только свою область и не принимает результат за владельца.
5. **Challenge не повторяет Superpowers.** Роли независимо проверяют готовую реализацию, не повторяя внутренний процесс Superpowers.
6. **Production меняется только в Rollout.** До этого готовая реализация проверяется отдельно на копиях данных, тестовых учётных записях или через безопасный read-only доступ к реальным интеграциям.
7. **Документация по факту.** В Closure общие документы приводятся к фактическому состоянию, а `CHANGELOG.md` содержит только завершённые изменения.