Persistent plan cards and sidebar reading
常驻计划卡片与侧边栏阅读
A plan review occupies the composer only until the user answers or dismisses it. A completed Turn also folds its tool calls into the process disclosure. Neither lifetime gives a submitted plan a discoverable place to read while implementation continues.
English
Problem
A plan review occupies the composer only until the user answers or dismisses it. A completed Turn also folds its tool calls into the process disclosure. Neither lifetime gives a submitted plan a discoverable place to read while implementation continues.
Decision
ui-plan accumulates each Turn’s exit_plan_mode submissions, including native calls and PTC dispatches. Each invocation contributes a card to the completed Turn’s final artifact area. The conversation.chat.turnTail list admits file deliveries and plan cards together. Review dismissal, refusal, and approval do not delete the recorded plans.
The review intent may carry the tool-call identity. The question plugin declares an action slot, and the plan plugin contributes an opener there and on the historical card. When an invocation exists, both open the resource identified by its complete Session address and invocation. Subagent addresses retain the direct parent, child, and mode for snapshot reads, pagination, and reload. The resource address selects the document’s Session, while the mounted Sidebar selects where its preview opens; embedded child conversations do not require a child Sidebar store. Sidebar layout retains that address; the resource provider reads the existing Session history, paging backwards when the invocation is older than the opening window. Its temporary follow closes after the opening snapshot.
A review without an invocation opens a temporary address keyed by browser lifetime, Session, and pending request. The sidebar’s existing navigation parameters hold its Markdown without adding another document store or persisting text in layout. Closing and reopening from the pending card supplies the text again; restored tabs without navigation parameters report an expired preview.
The document is read-only. The pending review shows its status, View full plan link, title, two-line plain-text summary, and Request changes / Approve buttons; the complete text opens automatically in the sidebar. A transient Session-scoped store records each automatically opened invocation or unlogged request, so review remounts preserve manual closure. Historical cards never trigger automatic navigation. The cards use the file-delivery treatment with a Markdown icon, plan title, and Open action. Request changes cancels the pending wait and returns the composer for feedback. Approval stays in the pending-question owner; reopening a historical document does not revive a settled review or authorize implementation. Different submissions remain distinct even when they share a heading.
Alternatives considered
Keep only the pending review or an expandable tool row. Both hide the document behind unrelated interaction or process state. The user needs a persistent artifact entry.
Write a Markdown file or persist the document in sidebar layout. The tool arguments already own the exact submitted text. Another durable copy would need synchronization and could disagree with the reviewed plan. The plan-state decision remains the authority for that ownership.
Select a single owner for the Turn tail. Plans and file deliveries can occur in the same Turn. An additive list lets both plugins contribute without either knowing the other’s data or rendering.
Consequences
Logged plans survive review closure and browser reload without a new Session event or file. Complete plan arguments retain a card even when the tool rejects the call, including calls outside plan mode; the card does not certify approval or execution. Reads of old plans may require several history pages. The provider validates saved addresses and logged arguments, and reports unavailable history explicitly. The recorded Web plan-review scenario covers both entry points, repeated opening, process collapse, approval, and reload; focused tests cover multiple submissions, PTC deduplication, cropped history, and resource failures.
中文
Problem
计划审批只在用户回答或关闭之前占据编辑器。已完成的回合也会把工具调用折叠到运行过程里。这两种生命周期都无法在实施继续时，为已提交的计划提供容易找到的阅读入口。
Decision
ui-plan 汇总每个回合的 exit_plan_mode 提交，覆盖原生调用和 PTC dispatch。每次调用在已完成回合末尾的产物区域贡献一张卡片。conversation.chat.turnTail 列表同时容纳文件产物和计划卡片。关闭、拒绝或批准审批都不会删除已记录的计划。
审批意图可以携带工具调用标识。提问插件声明操作插槽，计划插件在该插槽和历史卡片中提供打开入口。存在调用标识时，两者都打开由完整会话地址和调用标识确定的资源。子会话地址保留直接父级、子会话及运行模式，用于快照读取、分页和刷新恢复。资源地址确定文档所属的会话，当前挂载的侧边栏决定预览打开的位置；嵌入式子对话不需要子会话自己的侧边栏 store。侧边栏布局保留该地址；资源 provider 读取已有会话历史，当调用早于初始窗口时向前分页。临时 follow 在取得初始快照后关闭。
没有调用标识的审批打开临时地址，由浏览器生命周期、会话和待处理请求共同标识。侧边栏已有的导航参数保存 Markdown，无需额外的文档 store，也不把正文持久化到布局中。关闭后从待处理卡片重新打开会再次提供正文；恢复的标签页若缺少导航参数，则显示预览已失效。
文档只读。待处理审批显示状态、“查看全文”链接、标题、两行纯文本摘要，以及“要求修改”和“同意执行”按钮；完整正文自动在侧边栏打开。临时的会话级 store 记录每个已自动打开的调用或无调用标识的请求，让审批组件重新挂载时仍保留用户的关闭选择。历史卡片不会触发自动导航。卡片采用文件产物样式，包含 Markdown 图标、计划标题和“打开”操作。“要求修改”取消待处理等待并恢复编辑器，供用户输入反馈。审批仍由待处理提问的属主负责；重新打开历史文档不会恢复已结束的审批，也不会授权实施。即使标题相同，不同提交仍彼此独立。
Alternatives considered
只保留待处理审批或可展开的工具行。 两者都会让文档受其他交互或运行过程状态控制。用户需要常驻的产物入口。
写入 Markdown 文件或在侧边栏布局中保存正文。 工具参数已经拥有准确的提交文本。另一份持久副本需要同步，且可能与审阅的计划不一致。计划状态决策仍是这项所有权的权威记录。
只选择一个回合末尾区域的属主。 计划和文件产物可能出现在同一回合。可追加列表让两个插件都能贡献内容，无需彼此了解数据或渲染。
Consequences
已记录计划在审批关闭和浏览器刷新后仍可阅读，无需新增会话事件或文件。即使工具拒绝调用，包括在计划模式之外调用，完整的计划参数也会保留卡片；卡片不代表批准或执行成功。读取旧计划可能需要多个历史分页。provider 校验保存的地址和调用参数，并明确报告历史不可用。已有 Web 计划审批录制场景覆盖两个入口、重复打开、运行过程折叠、批准和刷新；定向测试覆盖多次提交、PTC 去重、裁剪历史及资源读取失败。