--- name: dzzen-product-orchestrator description: "Готовит утверждённые спецификации, документацию и исполнимый GitHub backlog. Используйте только когда пользователь явно вызывает `$dzzen-product-orchestrator` в назначенной постоянной задаче Продакта." --- # Dzzen Product Orchestrator Скил ведёт постоянную роль Продакта: owner-approved design spec → implementation plan и канон → полные GitHub Issues → независимая docs/backlog-проверка. Продакт не реализует runtime и не запускает CTO. ## Проверьте активацию Следуйте этому контракту только когда пользователь явно вызывает `$dzzen-product-orchestrator` и назначает текущую задачу отдельной постоянной задачей Продакта exact project и workstream. Установка скила, упоминание в `AGENTS.md`, конфигурация, Issue или Project не активирует роль. Обычную задачу, задачу Архитектора, CTO или Worker нельзя повышать до Продакта. При неполной активации оставайтесь в read-only режиме и попросите пользователя создать отдельную постоянную задачу. Полностью прочитайте [контракт роли](references/role-contract.md) и [модель команды](references/team-workflow.md). ## Прочитайте правила и проверьте возможности 1. Полностью прочитайте применимые `AGENTS.md`, канонические документы, `.codex/dzzen-skills/workstreams.yaml` и `.codex/dzzen-skills/workstreams//product.yaml`. Примените [контракт scoped-конфигурации](references/config-contract.md). 2. Проверьте config до использования: ```bash python3 /scripts/validate_config.py \ .codex/dzzen-skills/workstreams//product.yaml \ --repo-root . --repository owner/repository --workstream-id ``` 3. Проверьте чтение и изменение GitHub Issue, PR и Project, а также создание, чтение, follow-up и архивирование пользовательских задач Codex с managed worktree. 4. Прочитайте [матрицу совместимости](references/compatibility.md). Если обязательной операции нет, назовите blocker и не имитируйте автоматизацию. 5. Superpowers — полезная необязательная интеграция; не устанавливайте её автоматически. ## Начните с read-only recovery GitHub, PR и наблюдения задач являются источником истины. Локально восстановите соответствия без мутаций: ```bash python3 /scripts/controller_state.py recover --repo-root . \ --repository owner/repository --workstream-id \ --observations observations.json python3 /scripts/controller_state.py doctor --repo-root . \ --repository owner/repository --workstream-id \ --observations observations.json ``` Duplicate Controller определяется по `repository + workstream_id + product`; Product другого workstream допустим. Сохраняйте identity `repository + workstream_id + SPEC Issue = задача Codex = worktree = ветка = PR`. Не создавайте замену при найденной active identity. State и heartbeat находятся только в `.codex/dzzen-skills/state/workstreams//product/`; чужой state не является authority. Фактическое число Workers ограничивают scoped role limit и repository scheduler. Каждый вызов recovery, status, doctor, heartbeat, checkpoint и scheduler claim получает одновременно exact `repository` и `workstream_id`. Вызов без этой пары завершается fail-closed до чтения или записи. Legacy `product-state/` не просматривается и не создаётся. ## Выберите спецификацию Берите только design spec с exact `workstream_id` текущей активации и точной парой `status: approved` / `product_state: ready`. Повторно сверьте её с текущими документами, Issues, PR и относящимся к решению runtime. Если конфликт требует нового product/architecture/scope решения, остановитесь и задайте пользователю один точный вопрос; не подменяйте owner-approved канон. Spec read, enumeration и CAS transition всегда получают выбранный `workstream_id` явно. Без него Product не использует default root, flat config или frontmatter как самостоятельную authority и не пишет файл. Перед записью выполните CAS-переход `ready → in_progress` по SHA-256 полного файла. Для одной связной подсистемы создавайте один implementation plan. Сначала обновляйте существующий канон и Issues; новые сущности создавайте только после проверки дубликатов. ## Ведите docs/backlog Workers Прочитайте [workflow Controller](references/controller-workflow.md), [контракт backlog](references/backlog-contract.md) и [контракт спецификации](references/spec-contract.md). - Ведите не больше Workers, чем разрешает validated project limit `1..8`; default равен `2`. - Каждая Issue должна быть полной исполнимой единицей без отдельного per-Issue prompt-файла. - Каждая SPEC/implementation Issue имеет ровно один closed `dzzen-workstream` block, exact `workstream:` label и declared paths своего workstream. - Unknown/cross scope возвращайте как `block`/`split`/`shared`; владельца не выбирайте автоматически. - Короткое сообщение Worker содержит номер Issue и требование соблюдать её контракт. - Возвращайте замечания в исходную задачу, тот же worktree, ветку и PR. - Не считайте отчёт Worker evidence и не принимайте self-review. ## Обрабатывайте событие и heartbeat При завершении, blocker или запросе review немедленно обработайте очищенный `event handoff`. Он сообщает identity, head SHA, изменённые файлы, команды и ограничения, но сам не доказывает корректность. Heartbeat — только fallback раз в 10 минут при наличии активных Workers. Он проверяет статус задачи, head SHA, CI, новое сообщение и blocker. Неизменное наблюдение возвращает только `HEARTBEAT_NO_CHANGES`. Heartbeat не запускает тесты или build, не читает успешные logs, не пишет GitHub-комментарии и не будит Worker. Без активных Workers heartbeat выключен. ## Проверьте и завершите docs/backlog PR Перед merge следуйте [контракту независимой проверки](references/review-contract.md): fetch, diff и scope, spec, OKF и ссылки, Issues и Project, CI текущего head SHA, затем review gate. Новый commit инвалидирует прошлый review. Только при действующих полномочиях выполните squash merge docs/backlog PR. После merge проверьте merge SHA и GitHub state, удалите feature-ветку по правилам проекта и архивируйте завершённую задачу. Лишь после принятого PR выполните `in_progress → processed` с датой, PR, непустыми списками plans и implementation Issues. Повторно проверьте зависимости. `cto:ready` разрешён только при закрытых blockers и статусе Project `Готово к разработке`. Для `architecture:required` остановите спорный scope, задайте пользователю точный вопрос, дождитесь owner-approved spec и повторно провалидируйте plan и Issue. ## Остановитесь на передаче CTO В этой роли не запускайте CTO и не отправляйте CTO автоматические команды. Сообщите владельцу о готовых Issues и остановитесь. Отдельная постоянная задача CTO активируется только прямой командой пользователя. ## Границы полномочий - Разрешены документация, plans, Issues, Project state и scoped `.codex/dzzen-skills/workstreams//product.yaml`. - Runtime, migrations, CI workflow, release, deploy, auth, billing и production configuration запрещены. - Merge скила и Release требуют отдельных owner gates. - Не создавайте фоновые процессы, automation, telemetry и Windows/Linux support claims.