Add tool_calls to the /chat turn summary

commands/chat.md

@@ -146,13 +146,24 @@ Present it to the user like a chat client would:
   clearly-secondary "thinking" notes (e.g. a collapsible/italic list), distinct from the answer.
 - `steps` — tool/status cues such as `"Running Bash..."`. Show them as lightweight progress/tool
   indicators, separate from both reasoning and the answer.
+- `tool_calls` — one record per tool call: `{ id, name, category, status, filledParameters,
+  unfilledParameters, durationMs, result, error }`. The parameter and result field names follow
+  the runtime's `toolCall` entity, so they match `--raw`. `id` is the runtime's `toolCallId`, or
+  `anon:<name>#<n>` when the runtime sent none. `filledParameters` are the values the model sent.
+  `result` is the tool output as a string (JSON-stringified if the runtime sent an object), cut at
+  2000 characters with `resultTruncated: true` and the full `resultLength`. `error` is only present
+  if the runtime sent one. Use these when the user is debugging a tool: show what was sent and what
+  came back. Don't dump full results by default; they can contain business data. A flow that failed
+  can still show up as `completed` with an empty result such as `{}`, so when a flow tool's result
+  looks wrong or empty, suggest checking that flow's run history.
 - `attachments` — files the agent produced, already **materialized to disk**. Each has
   `{ name, contentType, bytes, path }` (or `url` for external links). Give the user the `path`; the
   base64 is never inlined, so offer to open/preview the file rather than dumping its contents.
 - `activity_count` — raw activity count, for diagnostics only.
 
 Render **messages, reasoning, and tool steps differently** so the user can tell them apart — the
-final `text` is the answer, `reasoning` is the agent's thinking, and `steps` are tool invocations.
+final `text` is the answer, `reasoning` is the agent's thinking, `steps` are tool/status cues, and
+`tool_calls` hold the details of each tool invocation.
 
 - If `status` is `"error"`, surface the `error` message. For `needsClientId`, run the setup workflow
   (step 4). For a non-CLI `recognizerKind`, stop per the gate (step 3). If the error carries
@@ -165,8 +176,9 @@ final `text` is the answer, `reasoning` is the agent's thinking, and `steps` are
 
 **Output modes.** Add `--raw` to get the full, unfiltered activity payloads (start + turn) for
 debugging. Add `--pretty` for a colorized, live terminal chat experience (reasoning in cyan, tool
-cues dimmed, the answer rendered as styled Markdown, attachments listed with their paths) — useful
-when a human runs the script directly in a terminal rather than having the agent relay the JSON.
+cues dimmed, the answer rendered as styled Markdown, attachments listed with their paths, tool
+calls listed with their inputs) — useful when a human runs the script directly in a terminal
+rather than having the agent relay the JSON.
 
 
 Keep the loop going: after each agent reply, ask the user for their next message and send it with the