# Source audit: tool-router

Decision: copy-after-audit. The current `tool-router` extension is a disabled compatibility wrapper around OMP/Pi active-tool boundaries: `/tools` is inspect-first, and explicit preset switches call the runtime `setActiveTools` API.

OMP source evidence:
- `/tmp/oh-my-pi-review/packages/coding-agent/src/slash-commands/builtin-registry.ts`
- `/tmp/oh-my-pi-review/packages/coding-agent/src/session/agent-session.ts`
- `/tmp/oh-my-pi-review/packages/coding-agent/src/extensibility/extensions/types.ts`
- `/tmp/oh-my-pi-review/docs/custom-tools.md`
- `/tmp/oh-my-pi-review/LICENSE`

License note: OMP checkout is MIT-licensed. Local `/tools` behavior is an inspect-first compatibility wrapper; no OMP implementation code was copied in this slice.

Ported/aligned contract:
- `/tools` without args shows tool state instead of mutating active tools.
- `/tools use <preset>` and legacy `/tools <preset>` switch local Miloc presets through `pi.setActiveTools`.
- `toolRouter` remains the programmatic compatibility tool for preset activation.
- The `minimal` preset uses primary OMP-style `ask`, not legacy `askUserQuestion`.

Known gaps:
- Local API has no `getActiveTools` or `getAllTools` read method, so `/tools` status reports current local preset, not the true runtime registry.
- OMP `--tools`, `--no-tools`, generic discovery, MCP selection, and approval policy are not ported here.
- Runtime Pi proof is still required before default enable.