peer-conversation

# Peer Conversation (DP.SC.154) Задача: $ARGUMENTS > **Архитектура:** я (Claude) = писатель, напарник = `<PEER_VENDOR>` (kimi по умолчанию | codex — issue #296, выбор на Шаге 0а). > Напарник вызывается через `<PEER_ADAPTER>` напрямую — Bash tool, stdin pipe (`kimi-peer-adapter.sh` | `codex-peer-adapter.sh`, один и тот же turn-loop ниже, меняется только адаптер). > `list_peer_statuses` (Local Gateway) — координация файлов, **не** проверка доступности CLI напарника. > Gateway offline ≠ напарник недоступен. --- ## When to use Многотуровый диалог писателя (Claude) с напарником (Kimi по умолчанию, Codex — второй вендор, Шаг 0а) по задаче пилота (DP.SC.154). Ведёт turn-loop, обнаруживает CONSENSUS/ESCALATE, после консенсуса — Decision Gate (зафиксировать vs реализовать → ревью → проверить → задеплоить), синтезирует report.md через Agent tool. ## Scope boundary — не подменяет решения, зарезервированные за пилотом (найдено 2026-07-07) > Peer-сессия пригодна для: технических решений, дизайна, code review, поиска компромисса между подходами, подготовки кандидатов к решению. > **НЕ пригодна** для решений, которые процесс явно закрепляет за человеком (например, R15 Валидатор в `/apply-captures` — accept/reject/defer кандидатов знания; R1 Стратег — приоритеты месяца). Согласие двух агентов между собой — не решение пилота, даже единогласное и хорошо обоснованное. > > Если задача внутри пир-сессии требует такого решения — писатель обязан остановиться и спросить пилота напрямую в теку...