ИИ помогает писать код, но команде по-прежнему нужно разобраться, что именно изменилось, соответствует ли результат требованиям и кто готов принять его в работу. Чем больше задач выполняют агенты, тем важнее сохранить эту связь. Иначе скорость подготовки изменений растёт, а проверка и согласование остаются ручной работой.
Цифровые сотрудники CodeGraph организуют работу по знакомым команде ролям: от исследования пользовательской проблемы до разработки, проверки безопасности и выпуска. У каждой роли есть задача, права, ожидаемый результат и собственное заключение. Команда видит, кому передана работа, какие проверки выполнены и чего ещё не хватает для приёмки.
Codex или другой совместимый агент выполняет действия этих ролей. CodeGraph связывает их с требованиями, кодом и доказательствами. Люди определяют цель, доступ и решения, которые нельзя делегировать без одобрения. Передача ответственности назначает следующего исполнителя. Автоматический запуск выполняется через настроенный процесс исполнения; его состояние отражается в статусе запуска.
Зачем разделять работу между ролями
Разработчик смотрит на задачу через изменение кода. Архитектор проверяет границы компонентов, специалист по безопасности — угрозы и данные, QA — наблюдаемое поведение. Разделение этих вопросов помогает обнаружить пробел, который автор изменения мог не заметить.
В CodeGraph результат реализации и заключения проверяющих хранятся отдельно. Сводный отчёт показывает готовность задачи и ссылается на исходные проверки. Поэтому можно отличить «изменение подготовлено» от «приёмка подтверждена» и вернуться к конкретному основанию решения. Для руководителя это способ понять состояние работы без повторного разбора всей переписки. Для инженера — возможность продолжить задачу с известной ревизии и сохранёнными результатами.
Пример: изменить правило доступа
Рассмотрим учебный сценарий: только администратор должен менять лимит в сервисе. Сергей уточняет допустимые роли и поведение при отказе. Анна связывает работу с критериями приёмки. Дмитрий готовит изменение и тесты, а Рита проверяет затронутые зависимости.
Вера рассматривает возможность обхода проверки прав, Лена проверяет разрешённый и запрещённый вызовы. Борис обновляет инструкцию, Иван связывает результаты с требованием. Если выпуск входит в задачу, Глеб проверяет среду и способ отката. Ева сверяет затраты перед закрытием.
Лена сохраняет результат разрешённого вызова, а Вера — результат проверки обхода авторизации. CodeGraph связывает оба результата с изменением. В статусе задачи команда видит выполненные проверки и текущую работу каждой роли. Так каждый участник получает свой вопрос для проверки и сохраняет результат вместе с изменением.
Что команда получает на выходе
- Для продукта — связь пользовательского результата с требованиями и приёмкой.
- Для разработки — ограниченную задачу, контекст изменения и понятную передачу результата.
- Для проверяющих — свою область ответственности и доказательства по конкретной ревизии.
- Для руководителя — готовые результаты, открытые вопросы и учтённые затраты в одной задаче.
Начните с карты сценариев, чтобы выбрать работу для первой задачи. Карта анализа объясняет, какие вопросы можно исследовать по коду, а частые вопросы помогают разобраться с подключением и границами применения.
Выберите первую задачу
Начните с задачи, результат которой команда сможет проверить: известного дефекта, изменения одного правила или вопроса о конкретном участке кода. Задайте репозиторий, ревизию и ожидаемый результат. Так вы увидите, как роли используют общий контекст и передают работу от постановки к проверке.
| Задача команды | Что задать | Какой результат проверить |
|---|---|---|
| Исправить известный дефект | Ошибочное поведение, ожидаемый результат и затронутый участок кода. | Изменение, тест воспроизведения и заключения проверяющих по той же ревизии. |
| Разобраться в коде перед изменением | Вопрос, исходный компонент и границы исследования. | Объяснение со ссылками на код, зависимости и выводы о зоне влияния. |
| Подготовить выпуск | Состав изменений, среду и критерии приёмки. | Сводку готовности со ссылками на проверки, открытые вопросы и план отката. |
После первой задачи оцените, сколько контекста пришлось восстанавливать вручную, насколько легко найти основание каждого вывода и понятно ли, кто выполняет следующий шаг. Эти наблюдения помогут выбрать следующие задачи для команды.
Как устроена модель
Обычная поставка состоит из четырёх уровней:
- продуктового требования в OpenSpec и связанной истории либо сервисной задачи;
- капсулы задачи с областью работ, критериями приёмки, владельцем и передачами;
- ролевых доказательств реализации, ревью, безопасности, QA, документации, трассировки, рантайма и затрат;
- решения сервера о закрытии после сбора всех обязательных доказательств.
В установленном клиенте используйте ролевые навыки из плагина CodeGraph и подключения,
выданные для соответствующей роли. У репозитория разработки есть собственный AGENTS.md
и локальные процедуры. Права в проекте заказчика задаются его профилями доступа.
Ответственные роли
| Роль | Результат, за который она отвечает |
|---|---|
| Кира / Product Owner | Проблема, пользовательский результат, готовность исследования, границы работы. |
| Сергей / Industrial BA | Требования, ограничения, техническое задание, трассировка приёмки. |
| Анна / Product Delivery | План, капсула задачи, передачи между ролями, отчёт о готовности релиза. |
| Дмитрий / Implementation | Ограниченное изменение кода или конфигурации и сфокусированные тесты. |
| Рита / Structural Review | Архитектура, изменённые символы, зона влияния, риск регрессии. |
| Вера / AppSec | Безопасность, приватность, секреты, DLP и граница публикации. |
| Лена / QA | Критерии приёмки, регрессии, проверки работающей среды и автоматические проверки без интерфейса. |
| Борис / Documentation Memory | Документация, каталог, начальная маршрутизация задач, готовность памяти. |
| Иван / Traceability | Связи требований, историй, задач, тестов, доказательств и проекций. |
| Олег / Support | Проверенные ответы, известные проблемы, диагностика и оговорки для оператора. |
| Марина / AI Workforce Governance | Ролевые навыки, промпты, субагенты, одобрения, внедрение и расхождения настроек. |
| Глеб / DevOps and SRE | Рантайм, CI, развёртывание, релиз, откат и публикация. |
| Ева / Financial Control | Сверка токенов, времени, стоимости и финансовое закрытие. |
Полномочия каждой роли ограничены её задачами и правами. Заключения ролей и исходные доказательства хранятся отдельно от сводного отчёта.
Как проходит поставка
Продуктовые требования хранятся в openspec/changes/<change-id>/; принятые контракты переходят в
openspec/specs/. Команда связывает задачу с требованиями и проверяет результат по критериям приёмки.
Обычная последовательность такова:
- Кира и Сергей формулируют результат и границу приёмки.
- Анна создаёт или продолжает капсулу задачи и определяет обязательные проверки и ответственные роли.
- Дмитрий сначала добавляет тест ожидаемого поведения, затем реализует ограниченное изменение.
- Рита, Вера и Лена проверяют точную ревизию и наблюдаемое поведение.
- Борис и Иван синхронизируют документацию и трассировку.
- Олег и Глеб подтверждают поддержку и готовность работающего экземпляра, если эти проверки входят в задачу.
- Ева сверяет итоговые затраты; Анна сообщает о готовности, не подменяя ролевые вердикты.
Лёгкая сервисная задача может быть самостоятельной, с необязательным группирующим кейсом, без создания продуктовой истории. Продуктовая поставка связывается с OpenSpec, историей, кейсом и критериями приёмки. Владелец, область, критерии приёмки, передачи и обязательные доказательства остаются явными. В начале работы сервер формирует предварительную оценку затрат. Перед закрытием Ева сверяет фактические затраты.
Например, исправление документации можно оформить именованной сервисной задачей. Зафиксируйте страницы, ожидаемый текст и поведение примеров, ревизию источников, редакционное ревью и проверки. Если нужна публикация, добавьте доказательства выпуска и проверки страниц сайта. Сервер использует полный набор обязательных результатов при решении о закрытии задачи.
Статус и доказательства
Откройте статус задачи, чтобы увидеть выполненные проверки, заключения ролей и оставшиеся вопросы. Каждый результат связан с проверенной ревизией: команда может перейти от вывода к тестам, отчёту безопасности или документу, на котором основано решение.
Сервер проверяет наличие обязательных результатов перед закрытием задачи. Если отчёт или дашборд ожидает синхронизации, получите актуальный статус с сервера. Человеческое одобрение задаёт разрешённую область изменений; требования, результаты проверок и затраты сохраняются в контексте этой задачи.
Интерфейсы и область работы
Выбирайте интерфейс под задачу:
- MCP — для автоматизации агентом и типизированных управляемых действий;
- CLI — для локального анализа и ограниченных операторских процессов;
- REST или дашборд — для аутентифицированных операций приложения;
- ACP — для совместимых IDE и агентских клиентов.
Набор инструментов зависит от активного профиля рантайма и политики вызовов. Получайте каталог
через работающий клиент, передавайте нативные структурированные аргументы и явно задавайте
project_key, namespace, задачу и историю, когда их требует обнаруженная схема. Доступность инструмента подтверждайте работающим
вызовом в рантайме.
Как проверить поставку
Поле сервера final_status_allowed должно разрешать финальный статус для той же задачи и ревизии.
Перед отчётом о завершении заново откройте канонический статус той же задачи и ревизии. У каждого активного критерия приёмки должен быть явный результат, обязательные вердикты должны относиться к текущей ревизии, а решение о финальном статусе — не содержать открытых блокеров. История передач показывает смену ответственного, статус запуска — ход выполнения, а пакет закрытия — результат приёмки.
Если автоматический исполнитель ещё работает, укажите готовый результат и текущий этап запуска. При ожидающей синхронизации проекции получите статус с сервера. Такой отчёт показывает команде выполненную работу и следующий шаг.
Доступ и следующие шаги
Условия задачи и профиль доступа определяют права на командную оболочку, репозиторий, развёртывание и публикацию. Оператор отвечает за учётные данные, доступ к среде и согласованную с пользователем границу изменений.
Начните с быстрого старта, для проверки установленного экземпляра используйте руководство оператора MCP, а подходящий процесс выберите по руководству сценариев.