aaif-goose / aaif-goose/goose

Collapse tool calls within a turn into a compact summary

オープン
#11,926 コメント 2 件 リアクション 0 件 担当者 1 名 @alexhancock が担当を希望しています GitHub で見る
主要言語
Rust
スター
54.2k
フォーク
6.2k
平均マージ
3日 4時間
マージ済み PR(30日)
240

説明

**What problem would this solve?**

In a long turn the agent makes many tool calls, and each one renders as its own card in the conversation. The agent's own text replies get pushed apart by cards the user rarely needs to read, so on a turn with a dozen calls you scroll past a wall of tool output to find what the agent actually said.

This affects anyone using Goose Desktop for non-trivial work. Two use cases it makes difficult:

- Following a running turn — the view is dominated by cards, and the reply you are waiting for arrives somewhere below the fold.
- Re-reading a finished session — reconstructing what happened means skimming past tool detail that was only interesting while it ran.

This is a readability and interaction-design change, not a proposed solution to session rendering performance.

**What would a good outcome look like?**

Within one turn, tool activity is represented compactly by default, and the detail is available on demand. Constraints the outcome has to respect:

- It is always visible which tool is running right now.
- Any call and its result can still be inspected in full.
- Tool calls awaiting user approval stay visible and actionable in place — they must never be hidden behind an interaction.
- The compact representation keeps a stable position while the turn continues to produce replies, so the view does not jump as new content arrives.

**Possible approaches**

Trade-offs worth settling in the design discussion rather than in a patch:

- Collapsed by default vs. behind a user setting. Collapsing by default changes existing behaviour for every user, which is the main risk in this change.
- What the compact form shows: a count only, tool names, or a progress indicator.
- Where "currently running tool" belongs. The bottom status line already carries progress messages and is a candidate, but it competes with what is shown there today.
- Scope and lifetime of the expanded state: per turn, per session, or persisted.
- How calls that are pending approval, errored, or cancelled are excluded from collapsing.
- Interaction with the existing consecutive-tool-call chaining in the message list.

**Two adjacent questions this raises**

Collapsing tool cards alone does not make a turn read as one unit, so these are worth deciding together rather than after the fact:

- *Thinking blocks.* They are part of the same intermediate detail and arguably belong in the compact form too. Whatever is decided, thinking must remain reachable — moving it behind a disclosure is a design choice, dropping it from the UI is a regression.
- *Density of intermediate replies.* Replies inside one turn are currently spaced and footered like separate answers (timestamp, usage). Treating them as a running log instead would make the turn read as one unit, but it changes information that some users rely on. Whether this belongs in the same change is an open question.

**Additional context**

Related, not duplicates:

- #11321 — a running tool call never shows its command over ACP. Overlaps with the "which tool is running" constraint above, but that issue is about the data reaching the UI, not about how the UI presents it.
- #11348 — large sessions stay expensive after open. Adjacent motivation only; see the note above that this is not a performance change.
- #10915 — scroll snapping near the bottom of the chat. Same area of the UI as the "stable position" constraint.

- [x] I have verified this does not duplicate an existing feature request

Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

The issue is about the conversation UI in Goose Desktop. Start by examining how tool calls are currently rendered as cards in the message list. Look for the UI components that handle turn rendering and tool call display. The design constraints must be understood before implementation, particularly around pending approvals and stable positioning. 'Done' means a compact summary is shown by default, with detail available on demand, respecting all listed constraints.

索引モデルが issue の本文から書いたものです。

評価

領域
developer-experience, frontend
issue の種類
機能追加
難易度
4/5
見積もり時間
3〜5日
活発さ
活発
明瞭さ
おおむね明確
初心者へのやさしさ
45/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。