tool-runtime-pipelinelisted

# Tool Runtime Pipeline ## Overview Model a tool call as a full runtime chain: resolve the tool, validate input, run pre-hooks, resolve permissions, execute the tool, map results, run post-hooks, and handle failures. No stage should silently bend the protocol. ## Source Anchors - `src/services/tools/toolExecution.ts` - `src/services/tools/toolHooks.ts` ## Workflow 1. Resolve tool identity and attach MCP server metadata, safe logging fields, and telemetry context. 2. Validate input before execution and map schema errors into a stable user-facing and telemetry-safe form. 3. Run `PreToolUse` hooks so hooks can add context, modify input, request allow or ask or deny, or stop continuation. 4. Merge hook output with the base permission system, but never let hooks bypass rule-based deny or ask decisions or safety checks. 5. Execute the tool only after permission passes, and record duration, result, and classified error details. 6. Normalize tool output into transcript-consumable blocks so builtin tools and MCP tools share one exit shape. 7. Run `PostToolUse` and `PostToolUseFailure` hooks so governance logic stays separate from tool implementation. 8. Classify aborts, auth failures, timeouts, input errors, and tool errors separately so retry logic stays correct. ## Design Rules - Make permission resolution an explicit stage, not a side effect inside tool code. - Treat hooks as a governance layer, not as a privileged execution layer. - Clone or backfill input carefully so cor