Перейти к содержанию

Роли AI-агентов SKUARO

Статус: ДЕЙСТВУЕТ В DEV.

Обновлено: 2026-08-26.

Назначение

Project-scoped профили находятся в .codex/agents/*.toml. Они специализируют работу, но не заменяют AGENTS.md, task card, permission boundaries или evidence gate.

По решению 0032 роли не маршрутизируются автоматически в обычной live STAGE-итерации. Основной агент реализует и размещает изменение напрямую. Профили подключаются по отдельной команде, в verification-контуре или перед PROD.

Модель и reasoning effort в профилях не закрепляются: агент наследует текущую конфигурацию родительской сессии. Project config разрешает максимум три subagent-потока одновременно, чтобы вместе с основным координатором сохранять не более четырёх рабочих потоков.

Реестр ролей

Роль Основной результат Режим записи Кому передаёт
orchestrator task card, маршрутизация, решение handoff read-only профиль профильному executor/verifier
architect границы, contracts, данные, permissions, ADR-предложение read-only orchestrator
frontend проверяемое frontend-изменение наследует sandbox родителя tester
backend проверяемое backend-изменение наследует sandbox родителя tester
tester независимое поведенческое доказательство наследует sandbox; в verification не редактирует reviewer/orchestrator
reviewer findings и независимый итог качества read-only orchestrator
production-release полный production audit, repair loop и итоговый отчёт наследует sandbox родителя; внешние опасные действия отдельно tester/reviewer/orchestrator

Маршрутизация

Следующая строгая последовательность применяется только когда verification-контур явно включён:

  1. orchestrator создаёт task card.
  2. architect подключается только если меняются границы, данные, contracts, permissions, зависимости или существенное техническое решение.
  3. frontend или backend выполняет ограниченную реализацию и возвращает READY_FOR_VERIFICATION.
  4. tester проверяет критерии и возвращает VERIFIED, REJECTED или BLOCKED.
  5. reviewer обязателен для архитектурных, security-, permission-, migration-, deploy- и других критических изменений; для низкорисковой задачи достаточно tester и детерминированных gates.
  6. Только orchestrator присваивает ACCEPTED_FOR_HANDOFF.

Если задача затрагивает frontend и backend, она делится на два последовательных контракта через публичный contract. Следующая часть не использует непроверенный результат предыдущей.

Внешний UI/UX-агент не входит в project-scoped роли и создаёт только visual reference package по docs/ui-agent/TASK.md. После сигнала владельца внутренний frontend получает отдельную implementation task и отвечает за фактический Product-код и evidence.

Профиль production-release запускается только командой ПОДГОТОВИТЬ К ПРОДАКШНУ после ручного STAGE-тестирования. Он координирует исправления, но финальный candidate обязательно передаёт независимым tester и reviewer. Детальный gate определён в docs/PRODUCTION_READINESS.md.

Параллельность

  • Параллельно разрешены независимые read-heavy исследования, анализ тестов и review разных непересекающихся артефактов.
  • Write-heavy задачи по умолчанию последовательны.
  • Параллельная запись разрешается только при доказанно непересекающихся путях, независимых acceptance criteria и назначенном интеграционном verifier.
  • Один agent thread получает одну конкретную ограниченную задачу.
  • Сводка subagent не является доказательством: координатор проверяет файлы, diff и воспроизводимые результаты.

Границы полномочий

  • Профиль не расширяет sandbox, разрешения родителя или полномочия из task card.
  • Ни одна роль не получает автоматического права на install, commit, push, merge, deploy, публикацию, удаление, секреты или внешние изменения.
  • Tester и reviewer не исправляют найденный дефект под видом независимой проверки.
  • При конфликте профиля с AGENTS.md действует AGENTS.md; при конфликте источников истины работа блокируется до решения.

Формат результата

Executor возвращает пакет READY_FOR_VERIFICATION по docs/AGENT_WORKFLOW.md. Tester/reviewer возвращают матрицу доказательств и один статус VERIFIED, REJECTED или BLOCKED. Orchestrator фиксирует причину ACCEPTED_FOR_HANDOFF или отказа.