Web 侧问：怎样呈现已有 Pi-native /btw 而不污染主上下文？

[tt-a1i]

OpenPI 已有 TUI /btw，值得讨论的是 Web 怎样调用和呈现这个 Pi-native 旁路提问：主任务运行时，用户在侧窗问“这里的术语是什么意思”“这个文件为什么这样设计”，不打断主任务，也不把旁支自动塞进主对话。

当前机制已具备：runByTheWay 复用 Subagent manager 并继承parent Trust/model/thinking，但明确仅允许 TUI；deliverBtwResult 将旁路结果存为Session entry，不进入主模型context/follow-up。所讨论的缺口是控制面，不是再造侧Session运行时。

观察到的两种实现：

• pi-btw@4f85810 使用真实 Pi 子 Session，支持继承主上下文或空白 tangent，显式 inject/summary 带回主Session。其当前子Session实际开启 read/bash/edit/write，所以不能把它直接当成只读侧问模板。
• pi-studio@e04fc7a 把起始选区、相关文件 root、是否继承主上下文分开选择；Bring to main 是显式动作。附件工具和外部检索也让权限和成本边界变复杂。

尚未确定的是 Web 的入口和范围：做一个有界旁路问答面板，还是复用 #346 的 Subagent 检查/接管面板；只保留当前一次旁问，还是允许独立多轮；是否需要与已有TUI旁问互通。如果多数“插一句”只是因为主任务状态不透明，先完成 #346/#468/#469 可能收益更高。再加一套侧Session持久化与调度未必划算。

如果试验，建议限定为：显式触发、继续继承当前模型/思考级别、复用现有 manager 的 child-safe 权限与预算/取消，先只读上下文，没有自动提交/自动写仓库，用户主动把可检查摘要带回原Session。跨Web/TUI的身份、取消、结果去重需要明确；不用安装另一个btw包。用“解释术语 / 理解选中代码 / 比较已有产物”三个真实场景衡量对主任务的干扰、额外耗时和token成本，再决定控制面设计。

欢迎讨论：哪些真实场景普通追问或fork无法满足；应该保留整条旁支还是只要可选摘要；Web入口是否应与现有TUI /btw互通。本次仅维护者源码与文档研究，未安装或运行两包。

研究记录：Pi 社区能力研究与候选清单（2026-09-08）。源码证据、运行验证与采用决策分别记录。