背景
Web Workbench（#326 / #337 引入）中，父回合通过 workflow / subagent_spawn 工具运行长任务时，后台正常工作（subagent 均已 done），但前端 transcript 数小时不更新，状态持续显示“正在准备任务...”；此时在输入框给 session 输入新提示词也不显示。
症状
实际场景：最后一次 user 消息（“修复提交（e014d34）。全量最终跑一遍，然后合并”）之后，父会话 transcript 不再更新；capability 区显示两个 Subagent（spec-review / standards-review）均 done；状态条持续停留在“正在准备任务...”数小时。期间在输入框向该 session 输入新提示词，输入内容不显示。
现场未保留更多观察（SSE 连接状态、/api/snapshot 轮询情况、/api/prompt 是否 pending 均未记录），归因见下。
代码定位（当前源码逐行核实，HEAD 72fbba5）
以下 4 条机制均已在当前 checkout 核实，任一或叠加即可产生上述症状：
-
prompt_accepted 把状态标签从"running"倒退回"preparing"
web/ui/app.js applyRuntimeEvent：prompt_accepted 分支无条件 state.livePhase = "preparing"。当前回合已在跑（agent_start 已置 "running"）时，新 prompt 被排队为 followUp——标签倒退回“正在准备任务...”，且要等当前回合结束、队列排空后才有下一个 agent_start。长回合期间（数小时）标签持续显示"preparing"。
-
父会话 transcript 在长工具调用期间按设计静默
web/runtime/pi-runtime.ts projectEvent：只投影父 session 的事件；父回合里 workflow() / subagent_spawn 工具调用执行期间，子 subagent 的消息都在子 session，不投影；queue_update 事件未投影。后台在工作、前端文字不动，是设计现状，用户无从区分。
-
无心跳、无兜底周期刷新
web/host/web-host.ts eventsStream：SSE 仅在连接建立时写一次 : connected，之后仅 publish() 时有数据，无 keepalive；web/ui/app.js 的 snapshot 刷新完全事件驱动（scheduleSnapshotRefresh 只在收到事件后触发），无周期性轮询。长静默期 = 零 UI 更新，无法区分“正在跑”与“传输/会话卡死”。
-
输入静默守卫无反馈、fetch 无超时
web/ui/app.js sendPrompt：state.promptAdmissionPending === true 时直接 return——不发请求、无乐观回显、无错误提示。若上一次 /api/prompt 的 admission 挂起（服务端 pi-runtime.ts sendPrompt 排队等前一个 admission），浏览器 api() 的 fetch 无超时，之后所有 Enter 均静默无效。另外 sessionSwitching 卡 true 时输入框整体 disabled，打字无反应。
假设待验证
具体个案由上述哪一条触发，需要 OPENPI_WEB_DEBUG=1 trace（web/trace.ts，默认关闭）+ 浏览器 Network 面板观察（SSE 状态、/api/snapshot 是否持续、/api/prompt 是否 pending）区分。以上 4 条代码路径本身已核实，触发归因待运行时证据。
期望
- 排队 followUp 不把状态标签从“正在运行”倒退为“正在准备任务”，并显示队列位置；
- 长工具调用期间有可观测的活跃度信号（capability strip 更新 / SSE 心跳）；
- 静默期有周期性兜底刷新，把“正在跑”和“传输/会话卡死”区分开；
promptAdmissionPending 卡住时输入有明确反馈；api() fetch 有超时。
相关
未检索到与本问题重复的既有 issue（web/UI/freeze/stuck/hang/SSE/卡住 等关键词已全量筛查，含已关闭）。
背景
Web Workbench（#326 / #337 引入）中，父回合通过
workflow/subagent_spawn工具运行长任务时，后台正常工作（subagent 均已 done），但前端 transcript 数小时不更新，状态持续显示“正在准备任务...”；此时在输入框给 session 输入新提示词也不显示。症状
实际场景：最后一次 user 消息（“修复提交（e014d34）。全量最终跑一遍，然后合并”）之后，父会话 transcript 不再更新；capability 区显示两个 Subagent（spec-review / standards-review）均 done；状态条持续停留在“正在准备任务...”数小时。期间在输入框向该 session 输入新提示词，输入内容不显示。
现场未保留更多观察（SSE 连接状态、
/api/snapshot轮询情况、/api/prompt是否 pending 均未记录），归因见下。代码定位（当前源码逐行核实，HEAD 72fbba5）
以下 4 条机制均已在当前 checkout 核实，任一或叠加即可产生上述症状：
prompt_accepted把状态标签从"running"倒退回"preparing"web/ui/app.jsapplyRuntimeEvent：prompt_accepted分支无条件state.livePhase = "preparing"。当前回合已在跑（agent_start已置 "running"）时，新 prompt 被排队为 followUp——标签倒退回“正在准备任务...”，且要等当前回合结束、队列排空后才有下一个agent_start。长回合期间（数小时）标签持续显示"preparing"。父会话 transcript 在长工具调用期间按设计静默
web/runtime/pi-runtime.tsprojectEvent：只投影父 session 的事件；父回合里workflow()/subagent_spawn工具调用执行期间，子 subagent 的消息都在子 session，不投影；queue_update事件未投影。后台在工作、前端文字不动，是设计现状，用户无从区分。无心跳、无兜底周期刷新
web/host/web-host.tseventsStream：SSE 仅在连接建立时写一次: connected，之后仅publish()时有数据，无 keepalive；web/ui/app.js的 snapshot 刷新完全事件驱动（scheduleSnapshotRefresh只在收到事件后触发），无周期性轮询。长静默期 = 零 UI 更新，无法区分“正在跑”与“传输/会话卡死”。输入静默守卫无反馈、fetch 无超时
web/ui/app.jssendPrompt：state.promptAdmissionPending === true时直接 return——不发请求、无乐观回显、无错误提示。若上一次/api/prompt的 admission 挂起（服务端pi-runtime.tssendPrompt排队等前一个 admission），浏览器api()的 fetch 无超时，之后所有 Enter 均静默无效。另外sessionSwitching卡 true 时输入框整体 disabled，打字无反应。假设待验证
具体个案由上述哪一条触发，需要
OPENPI_WEB_DEBUG=1trace（web/trace.ts，默认关闭）+ 浏览器 Network 面板观察（SSE 状态、/api/snapshot是否持续、/api/prompt是否 pending）区分。以上 4 条代码路径本身已核实，触发归因待运行时证据。期望
promptAdmissionPending卡住时输入有明确反馈；api()fetch 有超时。相关
未检索到与本问题重复的既有 issue（web/UI/freeze/stuck/hang/SSE/卡住 等关键词已全量筛查，含已关闭）。