# plan

## Назначение

`plan` сейчас отключен по умолчанию и больше не включает локальный read-only mode engine. Extension оставлен как переходная поверхность для будущего порта OMP plan mode: он регистрирует legacy tool `planMode`, команды `/plan` и `/todos`, но все эти поверхности возвращают fail-closed статус, пока настоящий OMP runtime не портирован.

## Почему он есть в проекте

Нужный продуктовый behavior уже есть в OMP interactive mode: `/plan` toggles plan mode, session хранит `PlanModeState`, агент пишет только plan file, любые остальные write/edit операции блокируются через OMP `plan-mode-guard`, approval идет через hidden `resolve`, а после approval runtime выбирает execution path, восстанавливает tools/model/context и отправляет synthetic approved-plan prompt. Старый локальный `planMode` был отдельным in-memory mode engine с собственным `tool_call` hook и allowlist для `bash`; это не должно конкурировать с OMP plan mode.

## Пользовательская поверхность

- Пользователь может вызвать `/plan on`, `/plan status`, `/plan execute` или `/plan off`, но команда покажет fail-closed сообщение о том, что OMP plan mode еще не портирован.
- Пользователь может вызвать `/todos`, но команда тоже покажет fail-closed статус. OMP plan mode хранит self-contained plan file, а не локальный список extracted todos в памяти `miloc-pi`.
- Агент может вызвать legacy tool `planMode` с `action` (`on`, `off`, `status`, `execute`) и optional `planText`; результат будет `isError=true` до порта OMP runtime.
- Extension больше не регистрирует `tool_call` или `before_agent_start` hooks, чтобы не создавать второй write gate и hidden planning prompt.

## Как работает по коду

Entrypoint `extensions/plan/index.ts` регистрирует command `plan`, command `todos` и legacy tool `planMode`. Tool валидирует прежний compatibility shape через TypeBox. После валидации все пути вызывают `planModeNotPorted`, который возвращает ошибку с source evidence для OMP plan mode files.

Execution path намеренно отсутствует. Extension не меняет `sharedState.plan`, не вызывает `setActiveTools`, не блокирует tools, не извлекает todos из `planText`, не отправляет hidden context и не управляет approval. Это защищает API от фейкового plan mode до настоящего порта.

- Entrypoint: `./extensions/plan/index.ts`
- Manifest: `extensions/plan/manifest.json`
- Commands: `plan`, `todos`
- Tools: `planMode`
- Hooks: none
- Permissions: fs.read=none, fs.write=none, subprocess=none, network=none, browser=false, models=false, ui=`confirm`, `setWidget`
- State: local plan state is not mutated in the fail-closed slice.
- Review: status=reviewed, source=wrapper-first, reviewedBy=miloc-pi, reviewedAt=2026-06-01, risk=high

## Ограничения и риски

Этот extension пока не создает `PlanModeState`, не пишет plan file, не ограничивает write/edit через OMP guard, не регистрирует standing `resolve` handler и не восстанавливает tools/model/context после approval. Включать его по умолчанию нельзя, пока OMP plan mode не портирован и не проверен в Pi runtime.

## Решение

Решение: `OMP-port-backlog`. Следующий шаг — портировать или тонко упаковать OMP plan mode как native session/TUI capability. Miloc-specific `/todos` можно добавлять только поверх OMP-compatible plan file lifecycle, а не вместо него.
