审批/提问水瀑事件单一赢家：第三方回答者无法与官方 Web composer 共存（建议：非接管观察 / 多表面展示 / carrier 复用）

[Mars-Sea]

概述

我们维护社区插件 dsh-deeppilot（话题 dsh-plugin）：让用户用 iPhone 驱动 DeepSeek Harness —— 把审批和提问请求镜像到手机（渲染为可回答的卡片），并推送 APNs 通知。DSH 0.1.2-alpha 起，approval/request 与 user-questions/request 变成 Cordis 先答先得（first-answer-wins）水瀑事件，第三方回答者与官方 Web composer 无法在同一请求上共存：插件接管水瀑，官方 Web composer 就被饿死（浏览器什么都不渲染）；插件调用 next() 委托，手机就既看不到、也无法回答。

希望平台提供能力：不接管也能观察/展示，或者多表面（multi-surface）回答者模型。这与 讨论 #5236（approval 确定性所有权） 相关但互补：它聚焦"谁拥有"的确定性调度；我们聚焦"展示与接管解耦"、"提问（user-questions）的可观察性"以及"官方 carrier 复用"。

问题

现状（DSH 0.1.2）

• approval/request（@deepseek-ai/dsh-user-approval）与 user-questions/request（@deepseek-ai/dsh-user-questions）声明为 @mode waterfall，经 Scoped<Agent> 分发：

  'approval/request'(this: Scoped<Agent>, req: ApprovalRequestEvent, next: () => Promise<ApprovalOutcome>): Promise<ApprovalOutcome>;
  'user-questions/request'(this: Scoped<Agent>, request: AskUserQuestionRequestEvent, next: () => Promise<AskUserQuestionAnswer>): Promise<AskUserQuestionAnswer>;

• 官方 Web UI 通过 @deepseek-ai/dsh-api-remotes 参与：remoteEventSource(ctx) 在 Host 侧注册这两个事件的监听器（API_REMOTE_FORWARDED_EVENTS），forwardWaterfall 把请求桥接到浏览器；官方 composer（@deepseek-ai/dsh-client-ui-approval、@deepseek-ai/dsh-client-ui-user-questions）经 ctx.remote.$on(...) 消费，并通过 conversation.composer 链渲染。

• 水瀑语义：第一个返回值（而非调用 next()）的监听器胜出，其余监听器——包括官方 Web answerer——都被跳过。

第三方回答者面临的冲突

手机桥接需要把请求展示到手机（卡片 + 推送）并让手机回答。单一赢家水瀑下没有中间态：

插件行为	手机	官方 Web composer
插件接管（返回 pending promise，不调 next()）	✅ 卡片 + 回答	❌ 被饿死，不渲染
插件立即 next()	❌ 无卡片、无法回答	✅ 渲染并回答

任何一端都无法同时满足，具体约束：

• uiSession.registerPendingInteraction(...) 是 per-session 单槽（SessionPendingInteractionSnapshot 是 ReadonlyMap<SessionId, ...>），插件卡片与官方卡片无法同时可见。
• user-questions 没有 user-questions/asked 这类会话审计事件（不像 approval/asked / approval/decided 已经存在），提问连"非接管观察"都做不到；唯一信号就是那个可接管的水瀑本身。
• 官方 pending carrier（PendingApproval / PendingQuestion）在 dsh-client-ui-approval / dsh-client-ui-user-questions 中是 type-only 导出，插件无法发布官方 carrier 实例（从而复用官方 composer），除非上游先改。

当前 workaround（dsh-deeppilot 内）

插件注册 prepend 水瀑监听器，仅在存在可达手机目标时接管（有在线连接设备；或推送传输可用且设备未静默该分类的离线设备）；否则调用 next()，让官方 Web composer 处理。这样两端都能"运转"，但永远无法同时生效：手机在时浏览器无展示；无手机时手机只能收到通知。

功能建议

以下任一方向我们都非常欢迎（按偏好排序）：

1. 非接管观察 / 镜像事件 —— 与 approval/asked 对齐，补一个 user-questions/asked 会话审计事件，让第三方可以观察、展示、发通知而不用抢 answerer 位。（审批已有 approval/asked 覆盖。）
2. 把"展示"与"接管"解耦 —— 允许同一请求在多个表面展示（官方 Web composer + 第三方表面），先答先得结算；任一表面回答后，其余表面清除。我们现有的 respondApproval / respondQuestion 单次结算模式可以平滑映射到这个模型。
3. 让官方 pending carrier 可复用 —— 把 PendingApproval / PendingQuestion 改为值导出（并文档化复用路径），插件可发布官方 carrier 实例、用官方 composer 渲染，而不必 fork UI。
4. 显式的回退/镜像注册 —— 提供文档化 API，让第三方回答者注册为"官方回答者之后"或纯镜像（可与 Deterministic approval backend ownership before the approval/request waterfall #5236 的确定性 ownership 能力统一设计）。

环境

• DSH 版本：0.1.2-alpha.2 / 0.1.2-alpha.3（npm dist-tag alpha）
• 插件：Mars-Sea/dsh-deeppilot
• 我们乐意提供更多细节、最小复现插件，或协助测试任何新 API。