Plan и goal mode
Безопасно проектируйте изменения в read-only режимах SOBA и переходите к реализации только когда решение согласовано.
Plan mode отделяет проектирование от реализации. В нём SOBA исследует проект и готовит план, но не меняет файлы, Git state, Project Memory, конфигурацию и не запускает shell-команды.
1. Переключение режимов
В TUI используйте /plan:
/plan # показать текущий режим
/plan on # включить plan mode
/plan goal # уточнить цель и критерии успеха
/plan off # вернуться в обычный agent mode
/plan toggle # переключить plan/agentplan готовит implementation brief: scope, файлы, риски, проверки и открытые решения. goal уточняет задачу,
критерии успеха, ограничения и границы работы. agent — обычный режим: в нём возможны изменения после стандартных
permission checks.
2. Что разрешено
В plan и goal mode SOBA использует inspection tools: read, ls, search_files, inspect_file,
read_project_memory и checkpoint. Read-only MCP tools также доступны, если сервер объявляет
annotations.readOnlyHint: true. Turn можно завершить готовым планом или goal brief.
Намеренно недоступны:
- mutation tools для файлов и памяти (
write,edit,write_project_memory); bash, даже для на вид безопасныхgit statusилиbun test;- custom или MCP tools без явно безопасной семантики, включая инструменты с
destructiveHint: true.
SOBA использует объявленные effects инструмента, а не пытается угадать поведение по имени. У built-in tools есть
каноническая семантика; MCP readOnlyHint означает inspection, а destructive или неаннотированные MCP tools в
restricted mode блокируются по fail-closed правилу.
Это строгая граница безопасности. Shell allowlist легко обойти через scripts, redirects, Git subcommands или
интерпретаторы. Запускайте диагностику сами через !command, либо явно переключайтесь на /plan off, когда агент
должен реализовать и проверить изменения.
3. Как обрабатываются запросы на реализацию
Контракт активного restricted mode помещается в начало model prompt — раньше общих инструкций agent loop. Tool schemas
фильтруются по каноническим именам из registry до transport conversion, поэтому bash не может снова появиться как
анонимный local_shell, а mutation tools вообще не показываются модели.
Поэтому один и тот же императивный запрос работает по-разному:
| Активный режим | Запрос: «Реализуй endpoint заметок, добавь тесты и запусти их» |
|---|---|
agent | Исследовать код, изменить файлы, запустить нужные проверки и подтвердить завершение evidence. |
plan | Исследовать релевантный код и вернуть decision-complete implementation plan. Не пытаться менять файлы и не просить переключить режим. |
goal | Уточнить цель, ограничения, scope и критерии успеха без проектирования или выполнения патча. |
Runtime execution policy остаётся вторым рубежом защиты. Устаревший, вручную сформированный или неожиданный mutation
call всё равно отклоняется с plan_mode_blocked, хотя в нормальном model path этот tool уже не виден.
4. Уточнения кнопками
Если текущий client поддерживает structured clarification, SOBA вызывает ask_user прямо во время планирования. Он
показывает один короткий вопрос, от двух до пяти вариантов и при необходимости поле Other. Выбранный ответ
возвращается в тот же agent turn — итоговый план уже учитывает решение.
Первая версия работает в ACP clients, рекламирующих нестабильную capability elicitation.form. Без этой capability
инструмент не показывается модели: SOBA просто перечисляет нерешённые вопросы в финальном плане. TUI пока осознанно
использует текстовый fallback.
5. Рекомендуемый workflow
/plan on
Исследуй репозиторий и предложи минимальный безопасный план.
Если стратегия релиза неоднозначна, запроси выбор.
/plan off
Реализуй согласованный план и запусти нужные проверки.Включайте plan mode, когда неверное предположение меняет дизайн, пользователь должен выбрать вариант или перед изменением workspace нужен reviewable implementation brief.