Цифровые сотрудники CodeGraph — ответственные роли процесса поставки, а не автономные персонажи с неограниченным доступом. Каждая роль работает в границах задачи, фиксирует собственные доказательства и передаёт результат следующему ответственному контуру. Codex или другой совместимый агент выступает оператором этих ролевых процессов.
Как устроена модель
Обычная поставка состоит из четырёх уровней:
- продуктового требования в OpenSpec и связанной истории либо сервисной задачи;
- капсулы задачи с областью работ, критериями приёмки, владельцем и передачами;
- ролевых доказательств реализации, ревью, безопасности, QA, документации, трассировки, рантайма и затрат;
- авторитетного решения о закрытии после сбора всех обязательных доказательств.
Корневой AGENTS.md — внутренний контракт маршрутизации. Повторяемые процедуры ролей находятся
в .agents/skills/sdlc-*/SKILL.md. Текущее состояние репозитория и поведение рантайма важнее
сгенерированных проекций и прежних статей.
Ответственные роли
| Роль | Результат, за который она отвечает |
|---|---|
| Кира / Product Owner | Проблема, пользовательский результат, готовность исследования, решение по scope. |
| Сергей / Industrial BA | Требования, ограничения, техническое задание, трассировка приёмки. |
| Анна / Product Delivery | План, капсула задачи, передачи между ролями, отчёт о готовности релиза. |
| Дмитрий / Implementation | Ограниченное изменение кода или конфигурации и сфокусированные тесты. |
| Рита / Structural Review | Архитектура, изменённые символы, зона влияния, риск регрессии. |
| Вера / AppSec | Безопасность, приватность, секреты, DLP и граница публикации. |
| Лена / QA | Критерии приёмки, регрессии, live- и headless-проверки. |
| Борис / Documentation Memory | Документация, каталог, bootstrap-маршрутизация, готовность памяти. |
| Иван / Traceability | Связи требований, историй, задач, тестов, доказательств и проекций. |
| Олег / Support | Проверенные ответы, известные проблемы, диагностика и оговорки для оператора. |
| Марина / AI Workforce Governance | Ролевые навыки, промпты, субагенты, одобрения, rollout и drift. |
| Глеб / DevOps and SRE | Рантайм, CI, развёртывание, релиз, откат и публикация. |
| Ева / Financial Control | Сверка токенов, времени, стоимости и финансовое закрытие. |
Полномочия каждой роли действуют в её контуре. Вердикт каждой линии и исходные доказательства хранятся отдельно от сводного отчёта оркестратора.
Как проходит поставка
Продуктовая работа начинается в openspec/changes/<change-id>/; принятые контракты переходят в
openspec/specs/. Исторические PRD остаются свидетельством миграции и не служат изменяемым запасным
источником.
Обычная последовательность такова:
- Кира и Сергей формулируют результат и границу приёмки.
- Анна создаёт или продолжает капсулу задачи и назначает обязательные контуры.
- Дмитрий реализует минимальный инкремент через tests-first.
- Рита, Вера и Лена проверяют точную ревизию и наблюдаемое поведение.
- Борис и Иван синхронизируют документацию и трассировку.
- Олег и Глеб подтверждают поддержку и готовность рантайма, если они входят в scope.
- Ева сверяет итоговые затраты; Анна сообщает о готовности, не подменяя ролевые вердикты.
Для лёгкой сервисной работы корнем управления может быть сама задача. Продуктовая поставка всё равно требует связанных OpenSpec, истории, кейса и критериев приёмки.
Статус и доказательства
Успешные unit-тесты подтверждают проверенное ими поведение. Готовность документации, безопасности, публикации рантайма, финансовой сверки и полного SDLC-закрытия подтверждается отдельными пакетами свидетельств.
Авторитетный пакет закрытия должен быть привязан к ревизии, содержать
final_status_allowed=true и не иметь отсутствующих контуров или блокеров. Сгенерированные
Markdown-файлы, дашборды и проекции репозитория считаются рекомендательными, если они устарели,
ожидают синхронизации или не защищены проверкой ревизии compare-and-swap.
Человеческое одобрение разрешает только тот переход и scope, которые названы в подписанном носителе. Оно не меняет неявно требования, доказательства, вердикты, статус или финансы.
Интерфейсы и scope
Выбирайте интерфейс под задачу:
- MCP — для автоматизации агентом и типизированных управляемых действий;
- CLI — для локального анализа и ограниченных операторских процессов;
- REST или дашборд — для аутентифицированных операций приложения;
- ACP — для совместимых IDE и агентских клиентов.
Набор инструментов зависит от активного профиля рантайма и политики вызовов. Получайте каталог
через работающий клиент, передавайте нативные структурированные аргументы и явно задавайте
project_key, namespace, задачу и историю. Доступность инструмента подтверждайте работающим
вызовом в рантайме.
Как проверить поставку
Перед отчётом о завершении заново откройте канонический статус той же задачи и ревизии. У каждого активного критерия приёмки должен быть явный результат, обязательные вердикты должны относиться к текущей ревизии, а решение о финальном статусе — не содержать открытых блокеров. Не смешивайте эту проверку с принятыми handoff: handoff подтверждает передачу ответственности, но не выполнение работы.
Если runner ещё не завершён или проекция устарела, отдельно назовите готовый локальный результат и недостающие доказательства. Так полезная работа остаётся видимой, но не выдаётся за формальное закрытие.
Ограничения и следующие шаги
Полномочия на shell, репозиторий, развёртывание и публикацию задаются carrier и профилем доступа. Оператор отвечает за учётные данные, доступ к среде и согласованную с пользователем границу изменений.
Начните с быстрого старта, для runtime-discovery используйте руководство оператора MCP, а подходящий процесс выберите по руководству сценариев.