docs: correct workflow progress color

Author: elkaix

docs/reference/tools.md

@@ -103,7 +103,7 @@ If a model response calls `DynamicWorkflow`, that call must be the only tool cal
 
 In `manual` and `auto` permission modes a `DynamicWorkflow` call requests approval, and that approval shows the plan it is about to run — the description, the subagent type, the prompt template, and every item. Approving for the session is keyed to that exact plan, so a later call that swaps in a different item list asks again; `yolo` approves without asking. Permission rules match `DynamicWorkflow` on the plan, or on `model:<alias>` for the model a call asks its subagents to run on, so `DynamicWorkflow(model:some-model)` gates the model a fan-out may use.
 
-In the TUI, a foreground workflow shows a live framed mission-control panel with a coral title. Each subagent row shows an indeterminate circular progress glyph, its lifecycle state, task, current work, and elapsed time. Running rows rotate a thin cyan arc, and a completed row becomes a fixed green check. Pending, held, failed, and cancelled rows keep distinct glyphs and text states. The animation reports observed lifecycle activity, not percent complete or time remaining. The summary reports factual completion, failure, and cancellation counts plus elapsed time, without an estimated aggregate percentage or progress bar. When every task starts with the same preamble — which happens when `prompt_template` is left empty and each item carries a whole prompt — the shared opening is dropped from every row and replaced by a leading `…`, so the part that names the row is what stays on screen. Compact terminals combine the glyph and lifecycle label under `STATUS`; wide terminals show separate `PROGRESS` and `STATE` columns. When vertical space runs out, rows are clipped in workflow-index order and the remainder is summarized as `+ N more agents`.
+In the TUI, a foreground workflow shows a live framed mission-control panel with a coral title. Each subagent row shows an indeterminate circular progress glyph, its lifecycle state, task, current work, and elapsed time. Running rows rotate a thin periwinkle arc, and a completed row becomes a fixed green check. Pending, held, failed, and cancelled rows keep distinct glyphs and text states. The animation reports observed lifecycle activity, not percent complete or time remaining. The summary reports factual completion, failure, and cancellation counts plus elapsed time, without an estimated aggregate percentage or progress bar. When every task starts with the same preamble — which happens when `prompt_template` is left empty and each item carries a whole prompt — the shared opening is dropped from every row and replaced by a leading `…`, so the part that names the row is what stays on screen. Compact terminals combine the glyph and lifecycle label under `STATUS`; wide terminals show separate `PROGRESS` and `STATE` columns. When vertical space runs out, rows are clipped in workflow-index order and the remainder is summarized as `+ N more agents`.
 
 **`AskUserQuestion`** asks the user a structured multiple-choice question — useful for disambiguation or option selection. The `questions` parameter accepts 1–4 questions; each question requires `question` (ending with `?`), `options` (2–4 choices, each with a `label` and `description`), and optional `header` (max 12 characters) and `multi_select` (defaults to false). An "Other" option is appended automatically. Setting `background` to true starts a background question task and returns a task ID immediately. When the host does not support interactive questioning, a failure message is returned and the Agent should ask the user directly in a text reply instead.