Plan mode: the plan never lands in the conversation, so multi-turn revision can't re-read it

[ouhaochuan]

Discussion: Plan mode — the plan never lands in the conversation, so multi-turn revision can't re-read it

Repo: deepseek-ai/deepseek-harness
Area: /plan mode (dsh-plan-mode) + Web approval UI (dsh-client-ui-user-questions)
Type: UX / design feedback

---

Summary

In /plan mode, the complete plan is only ever shown inside a temporary approval
card that takes over the composer. It is not written into the conversation as a
normal assistant message. Because plans are revised over several turns, the plan
text is effectively lost as soon as the card is dismissed — the user cannot scroll
back and re-read the plan while negotiating changes.

What happens today

1. While in plan mode, the model calls exit_plan_mode with the full plan as its
   plan argument.
2. presentCall returns a card: 'generic' view with the plan as content, but the
   Web generic tool card derives its body from the call arguments (toolRowModel
   in dsh-client-ui-tool), so this content is never rendered. The plan text does
   not appear in the conversation.
3. execute sends the plan as the detail of a user-questions request with the
   plan-review presentation intent.
4. The Web UI (PlanReviewPanel in dsh-client-ui-user-questions) takes over the
   composer seat and renders the plan as a scrolling markdown body inside the card,
   with max-height: min(60vh, 520px).

So the plan lives only in a transient takeover card. The model's own message text
may or may not contain the full plan — it is not guaranteed, and nothing in the flow
requires it.

The problem

• Plans need revision. Approve / keep-planning / feedback loops mean several
  turns over the same plan. Once the approval card is dismissed (or a new turn
  starts), the plan is no longer visible anywhere in the conversation.
• Height is not the fix. Bumping the card's max-height (e.g. to
  min(85vh, 960px)) makes the card bigger, but it is still a transient surface —
  it scrolls away with the composer and is gone after the decision.
• The card is a dead end for "browse the plan while we talk about it".

Expected behavior

• The complete plan is output as a normal assistant message in the conversation
  (persistent, full-width, scrollable with the page, re-readable on later turns).
• The approval surface is reduced to a fixed, simple question — e.g. "Execute
  per plan?" — with Approve / Keep planning actions, and no plan body inside the
  card (or at most a collapsed summary linking back to the message).

Suggested directions (open to maintainer preference)

1. Model guidance: make exit_plan_mode's description (and the default
   plan:policy section) require the model to write the complete plan as its
   assistant message text before calling the tool. Cheap, but relies on model
   compliance.
2. Deterministic presentation: register a keyed tool.call.toolview for
   exit_plan_mode (following the existing ask-question-row pattern) that renders
   the plan argument as a full-width markdown message in the conversation. This
   guarantees the plan is always visible regardless of what the model writes.
3. Simplify the approval card: stop rendering the plan body in PlanReviewPanel;
   keep only the strip, the fixed question, and the action row. The plan lives in
   the conversation above.

Environment

• Branch/master at commit 141eb6fef83422698aef7a981029e843e8161534
• Web GUI, Windows
• This is a design/UX observation; no crash, no data loss.

---

(Chinese original below / 中文原文如下)

Discussion: plan 模式下计划不进入对话流，多轮协商无法反复查看计划

仓库: deepseek-ai/deepseek-harness
领域: /plan 模式（dsh-plan-mode）+ Web 审批界面（dsh-client-ui-user-questions）
类型: UX / 设计反馈

摘要

/plan 模式下，完整计划只显示在一个临时审批卡片里，没有作为普通助手消息写进对话流。计划需要多轮协商，卡片一旦关闭，计划正文就无法再查看 —— 用户在反复修改计划时没法回看原文。

现状

1. plan 模式下，模型调用 exit_plan_mode，完整计划放在 plan 参数里。
2. presentCall 返回 card: 'generic' 并把计划放进 content，但 Web 通用工具卡是从调用参数推导正文的（dsh-client-ui-tool 的 toolRowModel），所以这段 content 根本不渲染 —— 计划正文不进入对话流。
3. execute 把计划作为 detail 放进带 plan-review 呈现意图的 user-questions 请求。
4. Web 端（dsh-client-ui-user-questions 的 PlanReviewPanel）接管 composer 座位，把计划作为可滚动 markdown 正文渲染在卡片里，高度上限 max-height: min(60vh, 520px)。

于是计划只存在于一个瞬态接管卡片里。模型的普通消息文本是否包含完整计划并不保证，流程里也没有任何机制要求它。

问题

• 计划需要协商。 批准 / 继续规划 / 反馈意味着同一份计划要跨多轮对话。审批卡一旦关闭（或新回合开始），对话里就再也看不到计划了。
• 调高度不是正解。 把卡片 max-height 调大（例如 min(85vh, 960px)）只是卡片更大，它仍是瞬态表面 —— 会随 composer 滚走，决策完就没了。
• 卡片对"边聊边看计划"是死胡同。

期望行为

• 完整计划作为普通助手消息输出到对话流（持久、全宽、随页面滚动、后续回合可反复查看）。
• 审批面收敛为固定简单问题 —— 例如"是否按计划执行？"，只带 确认执行 / 继续规划 操作，卡片内不再放计划正文（至多一个可折叠摘要，链接回上面的消息）。

建议方向（以官方意见为准）

1. 模型引导： 让 exit_plan_mode 的描述（以及默认 plan:policy 段落）要求模型在调用工具前先把完整计划写成助手消息文本。改动便宜，但依赖模型遵守。
2. 确定性呈现： 仿照现有 ask-question-row 模式，为 exit_plan_mode 注册一个 keyed tool.call.toolview，把 plan 参数渲染成对话流里的全宽 markdown 消息。这样无论模型怎么写，计划都保证可见。
3. 简化审批卡： PlanReviewPanel 不再渲染计划正文，只保留条带、固定问题和操作行；计划存在于上方对话中。

环境

• 分支/master，提交 141eb6fef83422698aef7a981029e843e8161534
• Web GUI，Windows
• 设计/UX 观察；无崩溃、无数据丢失。