# Производственный процесс 0xExqui.OS 3.0 Редакция от 22 сентября 2026. По решению владельца действует во всех рабочих инициативах. Историческая версия применяется только по явному выбору владельца. ПрП означает «производственный процесс». Product Owner рекомендует тип новой работы, владелец принимает решение: - **задача** — один результат, который можно проверить и принять отдельно; - **эпик** — не более семи пользовательских историй; - **проект** — несколько связанных эпиков. До создания документов или изменения кода Product Owner сообщает: `тип работы; применяемый цикл`. Если ответ уже дан владельцем или действующими документами, повторять вопрос не нужно. Иначе тип выбирает владелец. Delivery первого продуктового эпика нельзя начинать до закрытия EPIC-000 и согласования DoR этого эпика. Самостоятельная задача выполняется через Superpowers без документов и фаз эпика. До реализации согласуются результат, способ и границы; CTO проверяет простоту решения, CyberSec — относящиеся риски. Перед завершением основной агент технически проверяет полный результат; Product Owner независимо проверяет пользовательские сценарии и наблюдаемые результаты, CTO — реализацию; остальные роли — затронутые области. Для веб-сервиса используется один изолированный кандидат в Dev по правилам Challenge. Согласованное поручение заменяет DoR, короткий итог с вердиктами — DoD; выпуск разрешает владелец по правилам Rollout без оформления фаз эпика. Сохраняются правила документов и итоговый доклад: результат, доказательства, незавершённое, ошибки и выводы. Новая возможность или число проверяющих сами по себе не требуют эпика. Каждый продуктовый эпик проходит полный цикл: **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 начинается после проверки предъявленного DoR руководителем процесса. 2. **После DoD** — при положительном DoD владелец разрешает Rollout; при отрицательном возвращает эпик в Discovery с новым DoR, разделяет оставшуюся работу либо останавливает эпик. 3. **«Эпик закрыт»** — Closure и «Работа над ошибками» приняты. Закрытие последнего эпика завершает проект. Для EPIC-000 владелец согласует тип работы, истории с критериями и DoR проекта, а после обязательной «Работы над ошибками» закрывает эпик. Команда **«Действуй автономно до конца»**, включая «до самого конца», заранее разрешает согласованный в DoR Rollout после положительного DoD и закрытие после обязательных докладов. Discovery, согласование DoR и предъявление DoD сохраняются. Новые отклонения, риски и изменение Rollout требуют решения владельца. Исправления выполняются автономно в согласованных границах и пределах циклов. Без отдельного решения нельзя удалять реальные данные, совершать покупки, связываться с третьими сторонами, менять секреты, права или доступ из интернета, перезагружать систему либо выполнять несогласованное административное действие. Технические решения предъявляются в DoR или при согласовании самостоятельной задачи; во время выполнения — только изменения согласованного решения. После создания `PROJECT.md` решение владельца по проекту или эпику записывается туда до выполнения. ## Документы Все общие файлы из таблицы ниже защищены: добавление, изменение и удаление — только после согласия владельца на конкретное «было → стало», проверенное куратором. Согласование задачи, DoR, Rollout или Closure этого разрешения не заменяет. Исключение для DEPLOYMENTS.json определено ниже. Требования и решения не дублируются; вместо копий — ссылки. Статус, фаза и счётчики текущего эпика хранятся только в PROJECT; остальные документы ссылаются на этот блок. Устаревшее заменяется; история — в Git. HANDOFF, CHANGELOG, дневники и дублирующие перечни не ведутся. EVIDENCE — только индекс; отчёты проверок — отдельные неизменяемые доказательства. Исторические снимки и локальные копии читаются только для назначенного аудита. До записи основной агент проверяет назначение файла, согласование, дубли, ссылки и изменение объёма. Объём общего файла не увеличивается без отдельного согласия владельца; сокращение сохраняет требования и доказательства. Куратор проверяет итоговый документ целиком: требования совместимы, устаревшие решения и дубли удалены, детализация соответствует фазе. Доклад владельцу: результат, влияние, требуемое решение. Все сведения для решения предъявляются в сообщении; ссылка содержит только дополнительные доказательства. ### Общие файлы Платформы `PLATFORM` — корень Платформы; текущий путь: `/`. Основной агент и руководитель процесса читают AGENTS.md и ENGINEERING.md целиком. Остальные роли читают источники по AGENTS.md; основной агент передаёт ссылки на условия текущей фазы и применимые принципы. Повторно читают изменения. Отсутствующий источник выясняют до зависимой работы. | Файл в PLATFORM | Назначение | Куратор | | --- | --- | --- | | AGENTS.md | Роли и общие правила | Руководитель процесса | | ENGINEERING.md | Единый производственный процесс | Руководитель процесса | | ARCHITECTURE.md | Действующая архитектура всей системы | Основной агент; CTO проверяет независимо | | NETWORK.md | Сеть и доступ к сервисам | Главный администратор | | WORKSPACES.md | Проекты и их рабочие папки | Главный администратор | | DEPLOYMENTS.json | Точные адреса и состояние выпусков | Главный администратор | | RISKS.md | Риски, проверки и решения владельца | CyberSec; CTO — технические риски | | PROCESS-ISSUES.md | Проблемы производства | Руководитель процесса | | TONE-OF-VOICE.md | Правила пользовательского текста | Дизайн-директор | | [DESIGN_UI.md](DESIGN_UI.md) | Правила оформления интерфейса | Дизайн-директор | RISKS.md: `риск; последствие; устранение; исполнитель; проверка; решение владельца; статус`. CyberSec и CTO предлагают изменения единого списка: не более семи актуальных рисков суммарно, включая принятые владельцем. Превышение предъявляется владельцу с предложением устранения; скрывать риски ради лимита запрещено. Устранённые записи удаляются из текущего списка после согласования; история остаётся в Git. PROCESS-ISSUES.md содержит подтверждённые открытые проблемы производственного процесса; номера не переиспользуются. Локальные AGENTS.md содержат только ссылку на PLATFORM и особенности проекта; общие правила и ПрП не копируются. Другая версия применяется только по поручению владельца; источник фиксируется для всей инициативы. На Discovery адреса веб-сервиса в Dev и целевом контуре берутся из DEPLOYMENTS.json. Новый адрес или изменение существующего согласует владелец до записи и установки. Решение фиксируется в документах проекта и DEPLOYMENTS.json; уже согласованный адрес повторно не спрашивают и не выводят из имени проекта. Перед каждым выпуском агент перечитывает актуальные NETWORK.md, ARCHITECTURE.md и DEPLOYMENTS.json из PLATFORM, сверяет разрешённый контур, точный Host, источник выпуска и отсутствие коллизии с фактическими стеками; расхождение блокирует выпуск. В согласованной установке, обновлении или снятии агент меняет только записи своего проекта в DEPLOYMENTS.json: `assigned` — размещение назначено; `active` — установленная версия проверена по NETWORK.md; `retired` — снятие проверено. В `last_verified` указываются выполненные проверки и их ограничения; `active` не заменяет приёмку владельца. Это исключение не разрешает менять ARCHITECTURE.md, NETWORK.md или чужие записи. Прежнее состояние, результаты проверки и откат — в плане текущей работы. ### Файлы проекта Основной агент читает README, PROJECT, ROADMAP, BUGS, документы проектирования и план текущей работы. Все роли читают в первоисточниках цель, границы, требования и критерии проекта и текущей работы целиком; остальные разделы — по своей области и зависимостям. Для самостоятельной задачи используются существующие документы и согласованное поручение. Отсутствующие документы создаются по циклу проекта, без пустых заготовок. Проект внутри Платформы хранится в `projects//`. EPIC-000 создаёт: - `PROJECT.md` — цель, границы, общие требования к продукту, исходные просьбы владельца, все согласованные истории с критериями приёмки и решения владельца; - `ROADMAP.md` — связь идентификаторов историй с эпиками, планируемые результаты, зависимости, порядок, примерные оценки и ссылка на текущее состояние в PROJECT. README, PROJECT, ROADMAP и BUGS ведёт Product Owner. Документы проектирования пишет основной агент, независимо проверяет CTO; выполнение плана проверяет руководитель процесса. README описывает работающие возможности и использование. История полностью хранится в PROJECT; ROADMAP ссылается на её ID. Проектные правки перечисляются в поручении или DoR; остальные согласуются отдельно. В BUGS.md записываются неустранённые баги, требующие решения владельца: `ID; сценарий; ожидалось/получилось; влияние; ответственный; проверка; статус`. Неподтверждённое помечается «требует воспроизведения». В DoD и перед следующей инициативой Product Owner предлагает исправление или отсрочку; решает владелец. После успешного повторения исходного сценария Product Owner удаляет запись; история и ID сохраняются в Git. Пустой файл не создаётся. EPIC-000 проектирует целое решение без документов будущих эпиков. Детали эпика определяются в его Discovery. ### Для эпика Основной агент создаёт документы проектирования и план реализации по Superpowers. Ссылки на них хранятся в PROJECT.md. `RUN-LOG.jsonl` хранит события и измерения работы, `reviews/` — доклады ролей и доказательства. Используются уже существующие журналы и отчёты без дублирования. Документы завершённого эпика сохраняются как история и не переписываются следующим эпиком. Номер записи общего реестра не меняется и не используется повторно. Перед интеграцией параллельная ветка сверяет каждый общий или проектный документ с целевой веткой и объединяет только принадлежащие своей инициативе записи и разделы; заменять целый файл устаревшей копией запрещено. Новый межпроектный `CRITICAL` немедленно предъявляется владельцу. ## Изоляция работы Название эпика: `[<ФАЗА>] <Проект> · EPIC-<номер>. <Суть в 1–2 словах>`. Самостоятельная задача называется `<Проект> · TASK. <Суть в 1–2 словах>` без фазового префикса. При закрытии эпик или задача получает `[CLOSED]`. При каждой смене фазы эпика основной агент обновляет префикс через `app-server` текущего подключения: `thread/name/set`, затем проверяет сохранённое имя через `thread/read`. Создание и архивирование выполняются штатными инструментами Codex. Прямое изменение локальной базы запрещено. В начале работы, после восстановления контекста и перед первым изменением Codex фиксирует: `режим; тип работы; источник ПрП; проект и эпик; ветка; worktree`. Названная владельцем версия ПрП берётся только из неизменяемого файла, commit или контрольной суммы. Каждая параллельная инициатива работает в собственном `.worktrees/`; общий каталог не переключается на её ветку. Если правильный worktree уже существует, используется он. До записи основной агент проверяет ветку, каталог кода и подключение инструмента: сервер, базу или сервис. Разрешены только ресурсы этой инициативы; production меняется только в согласованном Rollout. При смене подключения проверка повторяется; неизвестная цель допускает только чтение. Перед выводом о недоступности GitHub или другого внешнего сервиса основной агент выполняет безопасную read-only проверку из разрешённой проекту сетевой среды через настроенное подключение, не изменяя его параметры. Ошибка только из ограниченной среды означает «не проверено из этой среды» и не блокирует локальные Git-действия. После потери контекста источники восстанавливаются по разделу «Документы». Новая роль получает режим, источник ПрП, проверяемую версию, требования и доказательства без истории диалога; при повторной проверке — изменения после её вердикта. ## Superpowers и субагенты Основной агент и субагенты используют согласованные модель и reasoning. Основной агент проверяет параметры запуска; недоступность настройки или проверки сообщает владельцу. Подмена без согласия владельца запрещена. Основной агент выполняет процесс Superpowers и использует созданные им документы и проверки. В Project Challenge и Pre-Challenge проверяются материалы проектирования, в Challenge — полная собранная реализация и результаты проверок. Основной агент доводит согласованную работу до закрытия, обеспечивает фазы, доклады и согласования. После промежуточного ответа продолжает работу; остановка — по просьбе владельца, для предусмотренного согласования или при неустранимом препятствии с указанием причины и условия продолжения. Роли: CyberSec — в начале инициативы; Product Owner — по открытым багам; Product Owner и CTO — в Discovery; дизайн-директор — при выборе дизайн-системы; проверяющие — в контрольных точках; руководитель процесса — перед Delivery/Rollout и после Closure; куратор — перед правкой общего документа и при изменённых сведениях в Closure. Роль исполняется отдельным субагентом; её доклад не дублируется. На инициативу создаётся не более одного субагента на роль; в следующих контрольных точках и повторах используется тот же. Между проверками субагент не работает. Замена при недоступности фиксируется руководителем процесса. В Delivery основной агент может применять Superpowers с числом параллельных субагентов до трёх для независимых задач. Вложенные субагенты запрещены. ## Роли и доклады Проверяющая роль независимо оценивает только свою область, не исправляет проверяемый результат и не подменяет другую роль. Перед циклом основной агент сверяет фазу, согласования и оставшийся лимит в PROJECT. В Project Challenge, Pre-Challenge и Challenge основной агент завершает все обязательные ролевые проверки до исправлений, даже после первого FAIL. До конца цикла документы или реализация, которые проверяют роли, не меняются. Порядок Project Challenge, Pre-Challenge и Challenge: дизайн-директор → CTO → главный администратор → CyberSec → руководитель процесса → Product Owner. Во всех фазах дизайн-директор участвует только при создании или изменении интерфейса либо текста продукта для пользователя; без таких изменений основной агент его не вызывает. Каждая проверяющая роль возвращает: `версия; PASS/FAIL; критерий → наблюдаемый результат и источник; блокеры`. Для блокера роль объясняет, какое требование нарушено, почему это мешает текущему этапу и что нужно исправить. До разработки проверяется план; перед выпуском — работающий результат. Product Owner передаёт вердикты без изменения смысла. До исправлений основной агент сверяет исходные замечания ролей и кураторов с требованиями фазы; спорные требования и противоречия разрешают выдавшие их роли до зависимых правок. Исправление заменяет затронутое решение, сохраняя принятые требования и удаляя устаревшее и дубли. Основной агент и Product Owner не снимают чужой FAIL. ### Повторные проверки В первом цикле участвуют все предусмотренные роли. В повторном — прежние FAIL, затронутые исправлениями роли, руководитель процесса и Product Owner последним. Проверяются прежние блокеры, изменённые области и окружение; остальные PASS сохраняются. Недостающие проверки выполняются. Переход фазы не требует повторного прогона. Основной агент один раз проверяет доступность версии и передаёт результат ролям. Если роль не может открыть результат, основной агент проверяет его из требуемого контура и передаёт доказательства той же роли. Неудачная попытка проверки не доказывает неисправность; необходимое доказательство всё равно требуется. | Проверка | Всего циклов, включая первый | Куда возвращаются блокеры | | --- | --- | --- | | Project Challenge | 3 | Project Discovery | | Pre-Challenge | 2 | Discovery | | Challenge | 3 | Delivery; изменение DoR — отрицательный DoD | После лимита автономная серия заканчивается. Для проверок до DoR применимо только одно исправление по следующему разделу. Иначе владелец останавливает или разделяет работу либо разрешает новую серию Discovery с изменёнными границами или решением. Счётчики новой серии начинаются заново; прежние сохраняются. Security-FAIL принять нельзя. ### Исправление перед DoR После исчерпания лимита Project Challenge или Pre-Challenge основной агент может один раз исправить технический пропуск в плане без обращения к владельцу, если согласованные истории, критерии, архитектура, Rollout и принятый риск остаются прежними. Исправление проверяют затронутые роли, руководитель процесса и Product Owner последним. Повторный или новый блокер завершает серию; счётчики не обнуляются. Security-FAIL снимает только CyberSec. Доклад сохраняется во время проверки; позднее восстановление помечается как ретроспектива и не может заменить отсутствующий PASS. Основной агент обновляет один блок текущего состояния в PROJECT: статус, фазу и счётчики серии, циклов, коррекций, возвратов и субагентов. История изменений — в Git; доказательства проверок — в докладах. Перед предложением новой серии пересмотри затронутое решение целиком. Объясни причину тупика и изменение подхода, начиная с упрощения и переиспользования. ## 0. Project Discovery — спроектировать проект Project Discovery и Discovery имеют общий порядок: 1. Основной агент выясняет цель, границы и ограничения: устройства, контур и путь доступа владельца, данные, интеграции, интерфейс, эксплуатация и безопасность. Полученные ответы используются повторно; число необходимых вопросов не ограничено. 2. Product Owner сравнивает до трёх сопоставимых продуктов по официальным описаниям и демонстрациям: пользовательские сценарии, интерфейс, подача текста. 3. CTO проверяет наш код, официальную документацию и пример, если он есть, затем до трёх готовых решений по исходным репозиториям, включая GitHub. Критерий — решение задачи и совместимость со стеком, интеграциями и средой выполнения; звёзды лишь признак популярности. В документах проектирования: `источник → что берём → как применяем`. Выбор: готовое решение, технический подход или обоснованная собственная разработка. После выбора поиск прекращается; актуальные выводы используются повторно. 4. Основной агент применяет brainstorming. Product Owner связывает каждую просьбу с историей, предъявляет полный состав и получает согласие на новые или изменённые истории. Уже согласованное сохраняется. Если критерий отсутствует или изменился, спрашивает: «Как вы поймёте, что получили то, что хотели?» Ответ без изменения смысла записывается в PROJECT. До ответа по каждой истории проверка проекта не начинается. 5. Основной агент проектирует компоненты, данные, интеграции, интерфейс, переиспользование, безопасность и эксплуатацию. В Project Discovery основной агент проектирует систему целиком; Product Owner фиксирует требования в PROJECT и эпики с зависимостями, порядком и оценками в ROADMAP. В Discovery эпика дополняются только его решения. При интерфейсе или пользовательском тексте основной агент получает недостающие требования и референсы, готовит прототип с настоящим текстом по TONE-OF-VOICE.md и DESIGN_UI.md, показывает владельцу и повторно предъявляет исправления. Прототип согласуется с DoR; согласованный повторно не создаётся. CyberSec указывает в плане риск, проверку и ожидаемый результат. Подтверждённые проверки, в том числе защиты администратора, используются повторно, если проверяемый код, настройки и условия не изменились. Сведения для постановки задачи не разрешены к публикации автоматически. Product Owner перед Rollout проверяет явное разрешение владельца на публикацию личных сведений. ### Project Challenge Документы проверяются по порядку раздела «Роли и доклады». Product Owner собирает блокеры одной волной. Порядок повторов, лимиты и исправление перед DoR определены там же. После устранения блокеров Product Owner предъявляет цель, границы, требования, истории и критерии, дизайн, эпики, зависимости, оценки, риски и открытые вопросы. Ответ **«DoR проекта согласован»** разрешает Closure и «Работу над ошибками» EPIC-000; реализации будущих эпиков нет. ## 1. Discovery — понять и спроектировать эпик Основной агент читает документы, затронутые код, сервисы и данные. Выполняет общий порядок Project Discovery для историй эпика; повторяет только недостающие или устаревшие сведения. Действующий способ применяется первым; отклонение обосновывается в документах проектирования. Изменение DoR или прямого поручения согласуется с владельцем. Product Owner предъявляет полный состав эпика. Непокрытая просьба, несогласованная история или отсутствующий критерий блокируют Pre-Challenge. Product Owner разбирает BUGS.md; выбранные владельцем исправления включает в истории и DoR. Для интерфейса документы проектирования фиксируют прототип и обязательные элементы, принимаемые в DoR; ранее согласованный прототип используется повторно. Остальные детали агент дорабатывает самостоятельно. Проверка готовых решений охватывает новые механизмы подготовки, реализации, проверок и выпуска. Если документации недостаточно для выбора решения, допускается до трёх изолированных пробных проверок, в том числе в существующем Dev: одна проверка — один открытый вопрос. После ответа проверка прекращается; отдельный прототип или контур не обязателен. Production, реальные данные, секреты, внешние последствия, результат и границы не меняются. Результат: - Документы проектирования: ID историй и ссылки на критерии PROJECT; результат, границы, пользовательский путь, интерфейс, данные, интеграции, переиспользование или удаление старого, проверки, мониторинг, восстановление и безопасность. - План реализации: необходимые шаги реализации, проверок и Rollout. Для сервиса указаны контур, место установки, устройства и каналы доступа владельца, адрес или способ назначения, запуск, перезапуск, проверка работоспособности, мониторинг и откат. Неизвестный конечный путь блокирует Pre-Challenge. ### Pre-Challenge Документы проектирования и план реализации проверяются по порядку раздела «Роли и доклады». Product Owner собирает блокеры одной волной. После их устранения — DoR; повторы, лимиты и исправление перед DoR определены в общем разделе. ## 2. DoR — согласовать эпик Product Owner предъявляет DoR строго по шаблону: - **Цель эпика:** какой результат получит владелец. - **Границы:** что входит и не входит в эпик. - **Решение и выпуск:** способ реализации и целевой контур; для сервиса — точный адрес. - **Истории пользователя:** каждая история — глазами пользователя, с ожидаемым результатом и способом личной проверки через интерфейс или другим наблюдаемым способом. - **Упрощение CTO:** что требуется переиспользовать, удалить или исключить из разработки. - **Риск:** существенный риск, если он есть. - **Решение:** «Прошу утвердить DoR». CyberSec отдельно предъявляет предлагаемые изменения `RISKS.md` для согласования. Руководитель производственного процесса сообщает количество циклов и возвратов Pre-Challenge. Выбор навыков и субагентов не входит в DoR. Ответ **«DoR согласован»** принимает описанный эпик. Перед Delivery руководитель процесса проверяет сообщение с полным DoR и согласие владельца; без подтверждения переход запрещён. Ссылка на документ доклад не заменяет. ## 3. Delivery — реализовать эпик После согласования DoR основной агент автономно выполняет план текущего эпика по процессу Superpowers. Перед первым изменением интерфейса он открывает согласованные прототипы, сохраняет обязательные элементы и самостоятельно дорабатывает остальное. Необязательная новая идея не прерывает Delivery, не реализуется и передаётся Product Owner для решения владельца. До Rollout нельзя изменять действующую production-систему, реальные данные и реальные внешние последствия. Работа останавливается только тогда, когда выполнить DoR невозможно без его изменения или обнаружен новый существенный риск, требующий решения владельца. `Implementation complete` — основной агент завершил реализацию и проверки Delivery по плану реализации и правилам Superpowers; доказательства применимы к предъявляемой версии. Для ПрП это означает только готовность начать Challenge: эпик ещё не принят, ветка не завершена, production не изменён. Новый тест проверяет конкретное поведение или воспроизводит баг, обнаруживает соответствующую ошибку и входит в реально запускаемый набор. Дубли и тесты, повторяющие реализацию без проверки поведения, не добавляются. Перед Challenge основной агент проверяет полную сборку: запуск, интеграции и выполнение требований. Способы технической проверки выбирает сам по типу результата; результаты передаёт ролям. Недоступная обязательная интеграция остаётся неподтверждённым критерием. Число тестов и строк не является критерием качества. Основной агент проверяет инструкцию, выполняя указанные в ней команды. При проверке сбоя основной агент подтверждает, что сбой действительно возник, и проверяет реакцию системы. В Dev используются синтетические данные и тестовые доступы. В других контурах проверки не изменяют реальные данные и не создают внешних последствий без согласования. ## 4. Challenge — независимо проверить реализацию Перед Challenge готовится полный результат в границах DoR. Веб-сервис полностью собирается и запускается изолированным кандидатом в Dev; прочие результаты предъявляются в полной рабочей форме. Основной агент фиксирует commit и способ доступа, передаёт ролям доступ к проверенной им сборке; роли и владелец получают одну версию. Вердикт не входит в пользовательский результат и не создаёт новую версию. Проверка проходит по порядку раздела «Роли и доклады»; версия неизменна до конца волны, даже после FAIL. Product Owner независимо проходит пользовательские сценарии полной сборки, включая настоящие интеграции на тестовых данных, и сверяет результат с согласованными критериями. Веб-интерфейс проверяет через управляемый браузер по зарегистрированному Dev-URL. Для результата без интерфейса использует технические доказательства основного агента и независимо проверяет наблюдаемый результат. Основной агент передаёт результаты проверок Delivery для этой версии; проверки, доступные только владельцу, перечисляет отдельно. Остальные роли проверяют свои области по AGENTS. Для веб-сервиса главный администратор проверяет по NETWORK.md соответствие зарегистрированного Dev-адреса установленному кандидату. FAIL означает блокер; неблокирующее замечание не меняет вердикт. Product Owner собирает блокеры одной волной. Основной агент исправляет их в Delivery и повторяет её проверки. Изменение истории или DoR прекращает автономную серию и отражается в отрицательном DoD. Руководитель процесса обновляет счётчики после цикла. Немедленный доклад — при нарушении границ, лимита циклов или субагентов; полный — в DoD. После цикла без блокеров или исчерпания лимита Product Owner в любом случае предъявляет DoD. Четвёртый Challenge не начинается. ## 5. DoD — подвести итог сделанной работы Product Owner всегда предъявляет владельцу DoD до Rollout, включая автономный режим, строго по шаблону: - **Результат:** какой собранный кандидат проверен и где владелец его открывает. - **Истории пользователя:** по каждой истории — фактический результат, `PASS/FAIL` и точный способ личной проверки владельцем. - **Отклонения:** что изменено или не выполнено относительно DoR. - **Состав реализации:** что переиспользовано, добавлено и удалено. - **Challenge:** вердикты ролей, блокеры и существенные риски. - **Открытые дефекты:** влияние каждого дефекта и предложение — исправить до Rollout или принять для Rollout. - **Rollout:** куда устанавливается тот же кандидат. - **Решение:** «Прошу разрешить Rollout», включая принятие перечисленных дефектов; при отрицательном DoD — одно требуемое решение. CyberSec сообщает изменение рисков и требуемое решение. Руководитель процесса — циклы, возвраты, число субагентов, максимум одновременно работавших и нарушения. Проверки только владельцем перечисляются отдельно и по умолчанию выполняются до положительного DoD. Если защищённый вход появляется только после установки, владелец подтверждает его после Rollout до Closure, в том числе при автономной работе; до этого доступность результата владельцу не подтверждена. При автономности после публикации может ожидаться личная субъективная оценка; она не заменяет обязательные проверки, согласие владельца или ролевой PASS. DoD использует результаты Challenge без повторного прогона. Для контура с VPN/2FA личный вход подтверждает владелец при первом размещении, изменении входа или выявленном сбое. DoD положительный, если подтверждены обязательные критерии и нет блокеров. По каждому неблокирующему дефекту Product Owner предлагает исправление до Rollout или принятие для Rollout; решает владелец. Исправление возвращает работу в Delivery и требует нового Challenge и DoD. Принятый дефект записывается в BUGS.md и повторно не согласуется. Новый дефект автономность принять не разрешает. Перед Rollout руководитель процесса проверяет полный доклад, заключения CyberSec и процесса и разрешение владельца. При автономности разрешение на неизменный согласованный Rollout уже получено. Смена фазы не требует повторной проверки продукта. При отрицательном DoD владелец возвращает эпик в Discovery с новым DoR, разделяет или останавливает работу. Весь проект пересматривается только при изменении цели, общей архитектуры или зависимостей. Способ завершения ветки указывается в плане реализации; после разрешения Rollout основной агент применяет `finishing-a-development-branch` из Superpowers. Несогласованный способ выбирает владелец. Проверенный commit сохраняется для Rollout, worktree — до Closure. Изменение реализации после DoD требует нового Challenge и DoD. ## 6. Rollout — изменить работающую систему В целевой контур переносится артефакт из Challenge из того же commit без пересборки. Различия настроек Dev и целевого контура согласуются в DoR; изменение реализации после DoD требует нового Challenge и DoD. 1. Главный администратор проверяет действующую стабильную версию и штатный механизм восстановления целевого контура, затем выполняет установку или обновление. Отдельный механизм отката создаётся только как согласованная история, если штатного недостаточно. 2. Основной агент проверяет установленную версию и критичные интеграции; Product Owner подтверждает доступный ему пользовательский результат. В Private работа сервиса проверяется на целевой VM, вход владельца — через VPN/2FA. Отсутствие у агента личной сессии не блокирует установку и не подтверждает пользовательский вход. Полный Challenge повторно не выполняется. 3. Главный администратор проверяет запуск, перезапуск, данные, мониторинг, ресурсы и работоспособность затронутых соседних сервисов. 4. Product Owner предъявляет владельцу результат и точный конечный путь; если Closure следует сразу, объединяет этот доклад с итогом Closure. Если Rollout может прервать Codex, его выполняет штатный независимый механизм целевого контура с сохранением результата. Отдельный управляющий скрипт или сервис создаётся только как согласованная история. Если Rollout вызвал сбой, сначала восстанавливается предыдущая стабильная версия и фиксируется инцидент. Если DoR не меняется и лимит Challenge не исчерпан, работа возвращается в Delivery, затем проходит новый Challenge и DoD. Иначе Product Owner выдаёт отрицательный DoD, а решение принимает владелец. При остановке Closure разрешён только после подтверждённого восстановления. ## 7. Closure — привести систему и документы к факту Closure начинается после успешного Rollout; без него — если он исключён согласованными границами, владелец остановил эпик или это EPIC-000 с принятым DoR проекта. При сбое сначала подтверждается восстановление. Фиксируется фактический результат и отсутствие выпуска, если его не было. Основной агент сверяет документы с результатом. Заключение куратора используется повторно, если документ и подтверждаемые факты не изменились; иначе куратор проверяет изменения по разделу «Документы». Непроверенная документация блокирует закрытие, в том числе самостоятельной задачи. Основной агент с кураторами: 1. Актуализирует README, PROJECT, ROADMAP, BUGS; отделяет документы проектирования от общей ARCHITECTURE; проверяет сведения NETWORK, риски и проблемы процесса. Общие правки согласует по разделу «Документы». 2. Завершает план реализации, проверяет ссылки на доказательства, сохраняет критерии и незавершённые обязательства. Документы завершённого эпика остаются историей; документы будущих не создаются и не переписываются. 3. Проверяет систему, удаляет собственные ненужные временные артефакты и формирует четыре показателя. В EPIC-000 отмечает: «Closure завершён, ожидается Работа над ошибками». Product Owner сообщает результат, путь владельца, показатели, исправленные и оставшиеся баги и следующий эпик; незавершённую личную приёмку выделяет отдельно. CyberSec сообщает только изменения после DoD. ### Четыре показателя производства С начала работы основной агент учитывает фазы, все связанные сеансы, дефекты, переделки и вмешательства владельца. Расход берётся из штатных счётчиков существующими средствами, без отдельного AI-агента и разработки нового сборщика. Все попытки и исправления входят в расход; ошибочный вызов не считается проверкой. В Closure предъявляются показатели и пробелы данных. | Показатель | Как считается | |---|---| | Time to Market | Календарные дни по 24 часа от начала до доступности результата владельцу; до доступности показатель незавершён. Отдельно: активная работа, ожидания, полный срок до закрытия. Параллельные интервалы не складываются; неизвестное активное время не вычисляется из общего. | | Расход | Токены всех относящихся к работе сеансов, с разбивкой по фазам; cached input входит в input, reasoning входит в output. Деньги рассчитываются только по известному применимому тарифу; без него денежная стоимость неизвестна. | | Качество | Число подтверждённых дефектов и волн переделки уже выполненного результата из-за нарушения принятого критерия. Повторный возврат того же дефекта не создаёт новый дефект. Плановая редактура и новая просьба владельца не считаются дефектами; окончательная оценка текста остаётся за владельцем. | | Сбои автономности | Случаи, когда для продолжения потребовалось незапланированное вмешательство владельца: исчерпан лимит, потеряно продолжение или возник иной подтверждённый тупик. Плановые вопросы и приёмка владельца сюда не входят. | Снимок Closure не включает ещё не выполненную «Работу над ошибками». При закрытии основной агент дополняет итог её фактическим расходом и временем без новой ролевой проверки и изменения принятой реализации. Неатрибутированные токены и пробелы журналов показываются явно; доказательств улучшения без измерений не заявляют. ## 8. Работа над ошибками — улучшить следующий цикл После Closure тот же руководитель процесса независимо проверяет показатели и источники, причины переделок, сбоев и нарушений. Пересматривает PROCESS-ISSUES: дубли, устранение причин и приоритеты. Изменения реестра согласуются по разделу «Документы»; добавленная инструкция не доказывает устранения причины. До закрытия руководитель процесса предъявляет владельцу отдельный короткий доклад: четыре показателя, причины переделок, сбоев и нарушений, действия на следующий цикл. Запись в плане реализации или PROCESS-ISSUES доклад не заменяет. Предложение содержит подтверждённую проблему, точную правку и влияние на срок, стоимость и согласования. Для нарушенной существующей нормы выясняется причина неисполнения; дубликат не добавляется. Новые правила и проверки принимает владелец. Отсутствующий в исходном цикле доклад нельзя задним числом представить как выполненную фазу: ретроспектива помечается отдельно. До этого доклада эпик не закрыт. После доклада владелец принимает решение **«Эпик закрыт»**; при действующей команде «Действуй автономно до конца» основной агент фиксирует закрытие после обязательных докладов. Основной агент фиксирует закрытие эпика в PROJECT.md и обновляет изменившиеся зависимости в ROADMAP.md. В последнем эпике он завершает проект. При закрытии задачи или эпика основной агент ставит префикс `[CLOSED]` в названии задачи и проверяет сохранённое название до итогового сообщения; непринятый или заблокированный результат так не помечается. ## Архитектурные принципы 1. **Server-first.** Production работает на VPS без компьютера владельца. 2. **AI через Codex.** AI-запросы выполняются через Codex с ChatGPT-аутентификацией; недоступность Codex не останавливает остальные функции. 3. **Изоляция и явные границы.** Сбой, перезапуск или исчерпание ресурсов одного сервиса не останавливают SSH и другие сервисы; неизвестный вход безопасно отклоняется, а очереди, повторы, фоновые процессы и внешние вызовы ограничены и восстанавливаемы. 4. **Владение и жизненный цикл.** Каждый сервис владеет своим процессом и каноническими данными; writable storage, cache, releases и временные артефакты имеют владельца, измеримый resource budget, наблюдаемые current/peak и условие удаления. 5. **Целостность данных.** Вход проверяется до записи; повтор, сбой и восстановление не теряют и не дублируют данные. 6. **Приватность.** Личные данные и секреты не попадают в Git, status и логи; доступ выдаётся по минимальной необходимости. ## Дизайн-принципы 1. **Цель истории.** Каждый экран, состояние и действие служат согласованному результату истории. 2. **Полнота состояний.** Предусмотрены все необходимые начальные, пустые, рабочие, успешные и ошибочные состояния. 3. **Визуальная иерархия.** Главное содержание и основное действие распознаются первыми. 4. **Единообразие.** Одинаковые элементы, состояния и действия выглядят и работают одинаково. 5. **Понятные действия.** До действия ясны его назначение, доступность и последствия. 6. **Понятные тексты.** Объясняют назначение, возможности, устройство и ограничения продукта там, где это помогает его понять. Утверждения подтверждены фактами; язык соответствует согласованным образцам и `TONE-OF-VOICE.md`. 7. **Функциональная минимальность.** Интерфейс не содержит элементов без пользы для истории. ## Производственные принципы 1. **Решение владельца.** Владелец определяет тип работы, принимает границы, истории, Rollout и закрытие. 2. **Работа в границах.** Выполняется только запрос владельца и согласованный DoR. 3. **Необязательное не мешает обязательному.** Новая идея не прерывает Delivery и предлагается как продолжение. 4. **Разделение ответственности.** Каждая роль проверяет только свою область и не принимает результат за владельца. 5. **Challenge не повторяет Superpowers.** Роли независимо проверяют готовую реализацию, не повторяя внутренний процесс Superpowers. 6. **Production меняется только в Rollout.** До этого готовая реализация проверяется изолированно; в Dev — на синтетических данных с тестовыми доступами. 7. **Документация по факту.** Куратор проверяет полезность правки; владелец согласует общие документы; история остаётся в Git. 8. **Минимальный объём.** Перед добавлением основной агент ищет, что переиспользовать, упростить или удалить в затронутой части. При равном результате выбирает меньше кода и инструкций без ухудшения понятности, скорости и безопасности. Комментарии нужны только для неочевидных причин и ограничений, которые не объясняют имена и структура кода. Заявленное ускорение подтверждается измерением.