待审批会阻塞整个 step —— 提问 seam 已经解决了同样的问题，请把同一套模式扩展到 approval/request

[overact]

Part 1 · 中文

标题

待审批会阻塞整个 step —— 提问 seam 已经解决了同样的问题，请把同一套模式扩展到 approval/request

摘要

一个审批提示会让所有进展停下：工具调用调度器在 pre-execute 闸门上 await，导致同一步里后续的兄弟调用
根本发不出去、step 无法结束、模型也拿不到下一次思考机会，直到有人应答。提问 seam 已经为同一种等待
落地了解法，审批也该有。

现状

• dsh-tools 内联等待闸门：
  const gate = await this.ctx.waterfall(carrier, "tools/pre-execute", exec, …) →
  serviceAsk → await approval.request({ agent, toolName, callId, reason, signal })。
  结果只有 allowed-once / rejected / cancelled 三种——没有超时。
• dsh-agent-loop 用 await startCall(nextToStart) 顺序启动调用，而 startCall 在派发前先
  await prepare(exec)（也就是等审批）。因此挂起的审批会阻塞：后续兄弟调用、step 的结束、模型的
  下一次思考；maxParallelToolCalls 救不了，因为阻塞的 await 就在顺序填充循环里。
• @deepseek-ai/dsh-user-approval 自己写明了约束：请求必须在 turn 内；只有一次性授权
  （allowed-once，没有记住的规则）；并且 "a durable out-of-turn approval workflow is
  deferred"。
• 今天唯一的非交互姿态是 policy: never，它是自动拒绝，而不是延期。

先例：提问 seam 已经这么做了

@deepseek-ai/dsh-tool-ask-user 注册 ask_user_question 的配置是
{ mode: "legacy" | "timed", timeout }（默认 legacy）。在 timed 模式下，
ctx.userQuestions.askTimed(…) 会在前台窗口关闭时立刻返回：

{ "pending": true, "callId": "…",
  "message": "… Continue useful independent work. … Do not treat this as permission." }

问题保持可答（open / continued 投影供客户端渲染），晚到的答复会以
answer_to_pending_question 回送进会话。也就是说，限时等待 → pending 结果 → 继续干活 → 晚到的
答复回送，在本代码库里已经被接受为提问的设计。审批是同一种形状的等待，只是安全要求更严。

期望行为

1. approval/request 增加一个软性截止时间。
2. 到期时提示降级而非消失——它作为待决卡片保持可答。
3. 该调用以一个新增的 deferred / pending 结果收尾，并带上同风格的指令：未执行、不要重复、
   去做不依赖它的工作。
4. 之后人类给 allow 时恢复或重新发起该调用；给 reject 时按今天的方式收尾。
5. 可选启用 + 失败即拒绝：到期绝不能自动放行，且某个审批挂起期间新发起的调用仍须各自过闸。

待解问题

1. 可持久化的 deferred 状态，是否就是"被延期的跨 turn 审批工作流"的预期形态？
2. 一个 deferred 调用能否在有序的 tools/pre-execute 调度器里释放 slot，让兄弟调用继续？
3. 这件事有多少可以在 out-of-tree 用「approval/request answerer + pending 存储」实现，
   有多少必须动核心？

更省事的替代方案

• 一条"总是允许"的记忆规则或按工具的 allowlist，能从源头减少大量提示，且不需要改调度器
  （上游同样把它列为缺失项）。
• 一个失败即拒绝的超时 answerer：N 秒后返回 rejected，不动核心；代价是那次调用作废而不是被延期。
• dsh-plugin-decision-inbox（社区插件）覆盖的是决策/提问，并明确声明不替代安全审批。

---

---

Part 2 · English

Title

Pending approvals block the entire step — the question seam already solved this; please extend the same pattern to approval/request

Summary

One approval prompt halts all forward progress: the tool-call scheduler awaits the
pre-execute gate, so later sibling calls in the same step never start, the step cannot
end, and the model gets no further turn until a human answers. The question seam already
ships a fix for the same shape of wait; approvals should get it too.

Current behaviour

• dsh-tools awaits the gate inline:
  const gate = await this.ctx.waterfall(carrier, "tools/pre-execute", exec, …) →
  serviceAsk → await approval.request({ agent, toolName, callId, reason, signal }).
  Outcomes are only allowed-once / rejected / cancelled — no timeout.
• dsh-agent-loop starts calls with await startCall(nextToStart), and startCall
  awaits prepare(exec) — the approval — before dispatching. A pending approval therefore
  blocks later sibling calls, the end of the step, and the next model turn;
  maxParallelToolCalls cannot help, because the blocking await sits inside the
  sequential fill loop.
• @deepseek-ai/dsh-user-approval states the constraint itself: requests are
  turn-enclosed, only one-shot grants exist (allowed-once, no remembered rule), and
  "a durable out-of-turn approval workflow is deferred."
• The only non-interactive stance is policy: never, which auto-rejects rather than
  defers.

Prior art: the question seam already does this

@deepseek-ai/dsh-tool-ask-user registers ask_user_question with
{ mode: "legacy" | "timed", timeout } (default legacy). In timed mode,
ctx.userQuestions.askTimed(…) returns as soon as the foreground window closes:

{ "pending": true, "callId": "…",
  "message": "… Continue useful independent work. … Do not treat this as permission." }

The questions stay answerable (an open / continued projection feeds the client), and a
late reply is delivered into the session as answer_to_pending_question. So bounded wait
→ pending result → keep working → late answer delivered is already accepted design here
for questions. Approvals are the same shape of wait with a stricter safety requirement.

Proposed behaviour

1. approval/request gains a soft deadline.
2. On expiry the prompt is demoted, not dismissed — it stays answerable as a pending
   card.
3. The call resolves with a new deferred / pending outcome carrying the same style of
   instruction: not executed, do not repeat it, continue with independent work.
4. A later allow resumes or re-issues the call; reject resolves as today.
5. Opt-in and fail-closed: expiry must never auto-allow, and calls made while one
   approval is pending must still pass their own gate.

Open questions

1. Is a durable deferred state the intended shape of the deferred out-of-turn approval
   workflow?
2. Can a deferred call release its slot in the ordered tools/pre-execute scheduler so
   sibling calls proceed?
3. How much can be built out-of-tree as an approval/request answerer plus a pending
   store, versus needing core changes?

Cheaper alternatives

• A remembered "always allow" rule or per-tool allowlist removes many prompts at the
  source and needs no scheduler change (also listed as missing upstream).
• A fail-closed timeout answerer that returns rejected after N seconds needs no core
  change — the trade-off is that the call is lost rather than deferred.
• dsh-plugin-decision-inbox (community) covers decisions/questions and explicitly does
  not replace security approvals.

[DoodleBears]

We reproduced this boundary in a persistent Bot application with real model calls and browser approval controls. The required behavior is that a protected operation stays pending while the same root Agent remains conversational. We would like to qualify a maintained native contract rather than introduce an application-owned executor or reissue the Tool from a later model response.

The results are separate:

Case	Observed result
RC1, the Orchestrator's own native approval	Unrelated input was durably admitted by the application, but had no native input claim, model step or reply for over 20 seconds while approval remained pending. Approving returned the original call result; only then did unrelated dialogue proceed.
Isolated RC2, native timed question	The original Tool truthfully returned pending. The same Session produced an unrelated real model reply, became idle, then accepted a qualified late answer through the original browser card and produced the actual selected-answer reply.
RC1, independent Assignment approval	The Assignment can release application running capacity while its original native approval Promise remains open. Its separate Orchestrator and another Assignment can execute. Approval reacquires capacity and rechecks authority before the original call executes. This does not unblock the approving root itself.

Evidence and runnable experiments:

• RC1 native approval reproduction and sanitized timelines: run the approval case on an isolated Profile; the changed case verifies scope refusal. Both use the real model, native command and authenticated browser/service boundaries.
• RC2 question card E2E: includes the fixed application run ownership after an ordinary Turn fully ends.
• Assignment approval-capacity tracer: real competing execution, original-call resumption and revocation without the original effect; descendant roots conservatively retain capacity.

On 2026-10-09 we rechecked official master / dsh-v0.2.1-alpha.1 at 5badb15009ae1756c3afe0ae0cef1faafc290ccc. The approval Service and default Agent-loop implementations are byte-identical to the investigated RC1 sources. The current outcome vocabulary has four outcomes (allowed-once, rejected, cancelled, unavailable), with no pending value. The Service reference still requires an open Turn. This is a source comparison, not a new alpha runtime test.

Could maintainers identify the intended native owner and API for this lifecycle?

1. Preserve the exact original Session/call, arguments and approval identity while unrelated input reaches real model processing in that same root.
2. On a valid late decision, execute only that operation after current actor/owner/scope/destination checks and bounded capacity acquisition. Ordinary chat, a question answer and Group membership grant no permission.
3. Reject only the protected operation, leaving dialogue available. Stop, expiry, restart and uncertain effects must never authorize a replay or duplicate effect.

Our concrete acceptance case is a Group conversation: a private-content request stays pending while the requester and another eligible member receive permitted replies, without protected reads/disclosure or private approval-detail leakage. We have not qualified that Group behavior. Timed question success and independent Assignment capacity are supporting evidence, not completion of this requirement.