feat(web): 补齐结构化问答、计划卡片和原生命令反馈

[6iKUN6]

Problem

Refs #562，关联 #343、#348。

部分 OpenPI 工具和扩展命令已经可以在 Web 中执行，但浏览器缺少对应交互：ask_user 等待答案时没有提交入口，plan_ready 的完整计划藏在工具结果里，human_handoff 没有反馈卡片，部分命令执行后也没有可见结果。命令菜单统一标为“不支持”，与手动提交后仍可能执行的行为不一致。

验收中还复现了计划生成期间消息反复消失，以及停止等待中的问答时，实际已取消却显示失败的问题。

Value

用户可以在 Web 中完成提问、复核答案、阅读计划和反馈人工操作，也能明确看到当前模式、命令结果和停止状态。继续使用 Pi 原有的工具、Session、命令分派与取消流程，不增加另一套代理或权限系统。

Approach

• 增加紧凑的 ask_user 卡片，支持选项、自定义答案和复核提交。待回答的问题绑定到发起标签页、Session 和轮次；支持刷新恢复、过期、取消和重复提交回执。关闭卡片不提交草稿，也不扩大工具原有的 Plan／Setup 使用范围。
• 修复审查指出的复制标签页身份问题：首次请求前通过 Web Locks 独占 controller ID，遇到复制的 sessionStorage 身份则重新生成。普通刷新可恢复原身份；不支持 Web Locks 时使用新身份，安全降级但不保证刷新恢复。此机制隔离问答控制权，不隔离同一 Session 的历史消息，也不是新的登录体系。
• 已与 feat(web): complete session workbar and settings experience #561 做语义 rebase，保留三栏布局、工作栏、图片附件和设置页行为。设置窗口内可直接回答或停止问答，主聊天区继续遵守上游隐藏 Setup 过程的约定。
• 展示 plan_ready 成功返回的 Markdown 计划，支持收起、复制和刷新恢复。卡片不代表批准实施；本次不实现 bug(web): Plan Ready 后实施命令被静默处理，工具门仍关闭 #470 的实施交接，也不把未完成的流式参数显示成已就绪计划。
• 增加由现有 Plan 扩展控制的模式开关。切换不调用模型、不发送聊天气泡、不清空草稿；发送任务后才开始规划，并显示当前模式提示。写入限制仍由运行时执行。
• 为 human_handoff 增加操作说明和复核提交。“已完成”只是用户报告，模型仍需验证完成信号。
• 补齐已适配命令的菜单说明，以及 Plan／Cron／Usage 的浏览器反馈。命令仍交给 Pi 分派；界面反馈不额外进入模型上下文。
• 加强 Setup 对非法请求值的提示约束：说明合法范围，未经用户明确选择，不擅自替换为其他合法值。实际写入仍经过原有类型校验。
• 修复正常 SSE 缓冲被误判为断线的问题，保留每个连接的缓冲上限；修复问答取消后进入下一次模型调用时被初始化流程误报为普通错误的问题。

本次不包含主题选择器、主题直接写入接口或首屏主题处理，相关改动保留在独立本地分支继续打磨。

实现与边界说明：Web structured questions、Web interaction UI。

Validation

已基于上游 main 的 45f12a4（已合并 #561）完成冲突处理和重新验证。以下是整合后的结果，使用 Node 24.16.0：

• bun run check：通过，包含配置／文档合同、生产构建、格式、lint 和类型检查。
• bun run test：Node 1,712 passed / 2 failed / 1 skipped。两个失败是已有的 TUI Plan Markdown 渲染断言；用未修改的上游 45f12a4 和同一套依赖单独运行该文件，也得到 22 passed / 2 failed。不宣称全量测试通过。
• Node 失败会阻止后续 Vitest 分区，因此另外运行全部 .spec.ts（--maxWorkers=2）：22 files / 318 passed。默认高并发曾导致已有设置页和侧栏测试超时，限制并发后通过，没有放宽断言或超时时间。
• playwright test --config tests/web/playwright.config.ts：50 passed。
• playwright test --config tests/web/playwright.provider.config.ts：12 passed。使用隔离 Pi 目录、本地合成 Provider 和真实 Host／Pi／浏览器，不读取用户凭据。
• 复制身份回归使用真正的 window.open 继承存储，验证新标签页换身份、无法取得待答卡片、提交取消得到 403，原页刷新仍可回答。该用例在修复前已复现失败。新增设置窗口内完成问答和 Stop 取消的整合测试。
• 浏览器回归覆盖问答复核、刷新恢复、标签页隔离、人工交接、Plan 开关与只读限制、计划卡、命令反馈和流式数据突发。取消测试同时检查 HTTP 回执、原生 Session 的 aborted 状态，以及随后能否继续对话。
• 用户已确认闪屏消失，问题刷新恢复、生成中停止、Plan 开关和计划卡刷新恢复符合预期。最后的问答取消误报修复已有自动化覆盖，尚未声称完成真实模型复验。
• git diff --check：通过。

未覆盖 Safari 真机、手机软键盘和长期断网恢复。真实断线后的快照恢复仍可能暂时丢失未完成消息，本次修复的是正常有界数据突发造成的主动断线。

Impact

• 用户界面： 新增问答、计划和人工交接卡片，补齐模式状态与命令反馈。
• 模型上下文： 增加当前 Plan 状态提示、Setup 非法值处理要求和问答过期反馈；不新增模型工具，不扩大工具开放范围。
• 运行时： 新增有界、绑定发起标签页的问答传输，处理取消、过期和清理；修复流式连接与取消分类。保留原生权限和工具限制。
• 持久化： 复用 Pi Session 保存工具结果和 Plan 状态；增加用于 Web 展示的命令记录。未提交答案草稿不落盘，不引入新的配置项或主题写入口。
• 兼容性： 保留现有 TUI 交互路径，已对齐合并后的 feat(web): complete session workbar and settings experience #561。feat(web): confirm cleanup of pre-existing files in the controlling tab #549 的标签页身份、fix(web): retain Stop identity across session switches and native wakes #540 的 Stop 生命周期仍涉及共享边界，后续合并需继续对齐；本次不实现它们的其他功能。fix(ask-user): allow controls in full-size answer drafts #578 修复的是 TUI 满长度答案编辑，不与本次 Web 卡片重复。

本次仅引用 #562，不关闭其中尚未推进的提案。没有提交私人会话、录屏或现场调查草稿。

[tt-a1i]

先修复标签页 controller 隔离，再与已合并的 #561 做语义 rebase。当前 CI 基于旧 main，且 PR 现在是 CONFLICTING，不能证明集成结果。

[6iKUN6]

@tt-a1i 上次 review 提到的标签页 controller 隔离和与 #561 的合并冲突都已处理，已推送到 fe1fef8。

复制标签页继承 sessionStorage 时，现在会先通过 Web Locks 检查 controller ID 是否被其他页面占用，重复则换新身份，再发起请求。补了真正由原页 window.open 打开新页的回归，验证新页不能读取待答卡片或代答，原页刷新后仍能恢复问答。也已基于合并后的 #561 做语义 rebase，补齐设置窗口内的问答和 Stop，修复了卡片与新布局重叠的问题。当前 GitHub CI 全部通过，显示无冲突；main 后续又有更新，所以目前仍显示 behind，尚未包含这部分后续提交。

另外，实际使用时发现了 Plan 模式和设置页主题切换之间的一个矛盾，想和你确认一下处理方向。这部分目前完成了定位，还没有修改：

• Plan 开启时，设置页仍可以提交主题修改，但请求最终会调用 configure_my_pi_setup，被 Plan 的写入限制拦截，主题没有变化。
• 退出 Plan 后，Session 已正确记录为 inactive，Plan 的工具限制也已解除，但模型可能继续沿用上下文里的旧拦截结果，反复让用户执行 /plan off。目前代码只在 Plan 开启时注入状态提示，关闭后没有明确告知模型已经退出。
• Setup 过程在主聊天区被隐藏了，用户不容易看到失败原因，就可能继续点击、积累更多配置请求。

如果继续沿用当前配置约定，我打算这样处理：Plan 处于 planning/ready 时，设置页先明确提示“退出 Plan 后才能修改配置”，阻止提交这类请求，并提供显式退出入口；运行中则先要求停止，不替用户自动退出。退出后，在下一次模型请求里明确提供当前状态，说明历史 Plan 限制已失效，但退出不代表批准实施旧计划。用户再选择主题，仍通过 Setup 修改，失败原因直接显示在设置页。这样可以避免发出注定被拦截的请求，同时保留现有权限边界和配置入口。

还有一个体验上的疑问：现在点击主题选项，Web 会代用户提交 /openpi-setup <修改主题的请求>，再由模型调用配置工具保存。也就是说，即使只是选择一个明确的主题枚举，也会产生模型调用、等待和 Token 消耗，配置请求及回复还会进入当前 Session 的模型上下文。虽然这些气泡在 Web 主聊天区被隐藏，执行轨迹和会话记录仍然保留。

我理解你在 #561 中要求保留 /openpi-setup 作为唯一配置入口。是否可以考虑经过明确审阅后，为 Web 开放一个只允许修改少量外观字段的受限接口，例如主题、聊天宽度和字号？接口继续复用 Setup 的类型校验、持久化和变更通知，保留同一份配置作为事实来源，不开放任意字段写入，也不涉及模型、权限或并发设置。这样这类确定性的 UI 操作可以不经过模型；是否允许它在 Plan 期间执行，也一并明确到约定里。

这会调整现有入口边界，所以先在这里讨论，不会直接把这条写入路径混进本 PR。如果你有更合适的方案，也想听听你的建议。

[tt-a1i]

审查提交：96a3b5e560b6959c926e6096cd9bee04f7b807c7。

本轮未发现新的阻断问题。以下结论仅覆盖所列验证范围，不是合并批准。

验证范围

审阅完整生产代码差异及问答、计划控制、异步命令来源和身份隔离相关测试。152 个 Node 测试及 202 个 UI 单元测试通过。

旧标签页控制身份问题已改为 Web Locks 独占加重复身份轮换；问答提交用固定请求身份和终态回执去重，未知提交结果不冒充未提交。Plan 状态修改复用原生 Session 控制并校验空闲状态/版本。

限制与后续

本轮未执行原生 provider 浏览器 E2E、真实模型请求或 TUI 验收。UI 单测通过不能代替这些验收。

设计草稿 WEB_STRUCTURED_QUESTIONS.md 的 future Composer control 段落未完全同步已实现的控制栏，属文档收尾。

[tt-a1i]

复审提交 c1891a9b2f9f37b6432f2e5f465fad702dc14be9。

本次新增提交只修正 WEB_STRUCTURED_QUESTIONS.md 的 Plan 控制描述；它与已审过的实现一致，新增的设计文档链接也有效。此前代码审查结论仍适用于未改动的功能代码，当前 PR 分支的远端检查全部通过。

仍需修改：与当前 main（6132d997）合并时，tests/web/web-host.test.ts、web/ui/src/protocol/client.ts 和生成的 web/dist/app.js 有内容冲突。特别是 WebClient.prompt() 的请求体：main 加入了 sessionPath，此 PR 加入了 controllerId，解决冲突必须同时保留两者，避免丢失当前 Session 绑定或问答标签页控制身份。请合并当前 main、手动处理测试夹具和客户端请求，并从最终源码重新构建 web/dist/app.js；然后在合并结果上重跑 Web、Host 和浏览器相关检查。分支现有绿灯不能覆盖这个集成结果。