tool-orchestratorlisted

# Tool Orchestrator Select the smallest currently exposed or installed tool that can complete the requested step. Treat a tool's presence as capability information, never as permission to mutate an external system. ## Discover the current surface 1. Enumerate the installed tools, connectors, scripts, and local commands actually exposed in this session. 2. Tag each candidate with capabilities such as `inspect`, `read`, `edit`, `test`, `preview`, `browser`, `deploy`, `external-write`, `destructive`, or `secrets-sensitive`. 3. Separate availability, authentication, authorization, and evidence. A listed tool may still be unavailable, unauthenticated, unauthorized, or unable to prove a live result. 4. Prefer deterministic local inspection for local facts and an official service surface for service facts. Do not invent a connector or silently substitute a different system. ## Choose by capability and risk 1. Start with the least powerful tool that satisfies the step; prefer read-only over write-capable and dry-run over apply. 2. Compare candidates by scope, reversibility, privacy, reliability, and the evidence they can return. Record why the selected capability fits. 3. Keep one tool/resource per bounded lane when possible. Do not let two lanes mutate the same file, record, database object, or external resource. 4. If a capability is missing, explain the limitation and offer a safe local or manual fallback. Never claim that every vendor, connector, or integration is bundled, s