Tool Execution Pipeline

Maintenance mode: curated Mermaid flow; exact tool schemas and event signatures live in generated catalogs.

This graph shows where policy, hooks, sandboxing, and future filesystem guards fit without changing the loop. The key extension point is the tools/execute waterfall.

flowchart TD
  model["Assistant message contains tool-call block"]
  toolCall["Session event: tool/call"]
  waterfall["ctx.tools.execute()<br/>tools/execute waterfall"]
  policy["Policy / permission / hooks listener"]
  toolBody["Registered tool execute() body"]
  owned["Tool-owned session events<br/>todo/write, future fs policy facts"]
  toolResult["Session event: tool/result"]
  ui["UI presentation<br/>presentCall / presentResult"]
  model --> toolCall --> waterfall
  waterfall --> policy
  policy -->|next| toolBody
  policy -->|veto / throw| toolResult
  toolBody --> owned
  toolBody --> toolResult
  toolCall --> ui
  toolResult --> ui

Future pressure from the fs stack: PR #128 snapshots a policy rejection card. The graph keeps the veto path explicit because filesystem read-before-edit checks, permission prompts, and hook bridges all belong on this path.

1.3 KiB Raw Blame History

Tool Execution Pipeline

1.3 KiB

Raw Blame History