Deterministic approval backend ownership before the approval/request waterfall

[qfzlm]

DeepSeek Harness currently exposes approval answerers through an agent-scoped approval/request waterfall. The first terminal listener wins, so registration order, including prepend, can change which answerer owns a request when Browser, ACP, or an automated reviewer are composed together.

I revalidated this on dsh-v0.1.2-alpha.2 (0a53fb55bea101816fa226bb964ae2bed71c343b). ApprovalService still dispatches the waterfall after abort and policy handling. Browser now participates through API Remote Events and the Client approval listener; ACP registers its Host answerer directly. I did not find an official dispatcher, named-backend, or deterministic ownership capability.

I tested a small optional capability:

• ApprovalService consults an optional ApprovalDispatcher before the waterfall.
• The dispatcher selects exactly one named backend.
• A selected request never enters approval/request.
• Only an explicit delegate result enters the legacy waterfall.
• Missing, throwing, or invalid selected backends fail closed as unavailable.
• With no dispatcher, current waterfall behavior is unchanged.
• Browser and ACP expose their existing decision paths as named backends; fake-reviewer is test-only.

Tested against dsh-v0.1.2-alpha.2:

• all 17 related test files in user-approval, api/remotes, and acp/acp pass;
• 200/200 related tests pass;
• focused dispatcher tests pass 18/18;
• typecheck, contract lint, documentation checks, Cordis API/catalog checks, module-graph verification, and export-JSDoc verification pass;
• Browser, fake-reviewer, and ACP ownership are exclusive;
• adversarial prepend cannot steal dispatcher-owned requests;
• each request records exactly one approval/asked → approval/decided pair;
• abort and teardown behavior remains fail closed.

A resident dsh web live probe was not run for this alpha.2 port, so the current-version evidence is unit/integration verified rather than live verified.

Research, test evidence, and the reference patch:

https://github.com/qfzlm/dsh-switchyard

Questions for maintainers:

• Is ApprovalService the right consumer for a deterministic ownership capability?
• Would you prefer an optional service provider plus named backend services, or another extension primitive?
• Should backend selection be deployment-owned, Session-owned, or derived from Agent composition?
• Should the host enforce a decision deadline in addition to propagating cancellation?

[argszero]

This is a well-scoped RFC and the design is sound. I independently re-checked the key claims against the same 0a53fb55be (alpha.2) snapshot and found the architecture exactly as you describe — plus a precedent in the existing code that strengthens your case for ApprovalService being the right consumer.

Source confirmation (alpha.2):

• The waterfall is real and ordered: approval/request is forwarded with mode waterfall in packages/api/remotes/src/remote-events.ts:18, and Cordis waterfall composes listeners outermost-first, with the first listener to return a value owning the result (vendor/cordis/src/events.ts:234-243).
• Three answerers register on that one event: ACP (ctx.on('approval/request', ...) at packages/acp/acp/src/index.ts:154), Browser through the remote client (ctx.remote.$on('approval/request', ...) in packages/client/ui-approval/src/client/index.ts:90), plus any automated reviewer. There is no dispatcher, named-backend, or ownership primitive anywhere in interaction/user-approval or api/remotes.

The most relevant precedent — one you may not have cited:

ApprovalService.decide() (packages/interaction/user-approval/src/index.ts:272-277) already contains an explicit comment explaining exactly the class of problem you're raising:

"The 'never' policy is decided HERE, before any dispatch: a listener registered with prepend: true after this service mounts would sit ahead of any gate LISTENER, so a listener-shaped gate cannot keep the documented promise that 'never' rejects deterministically regardless of registration order — only the service's own request path can."

This is the project already acknowledging that the waterfall alone cannot guarantee deterministic policy, and choosing to resolve it in-service rather than as a listener. Your ApprovalDispatcher is that same principle extended from the never-vs-listeners case to "which answerer owns a request" — so the maintainers' own design comment is the strongest argument that ApprovalService is the right consumer.

On your four questions, my opinions:

1. Yes, ApprovalService is the right consumer — it's the only place that already owns deterministic pre-dispatch policy, and placing the dispatcher there keeps the ownership decision in the same seam as the never gate.
2. I'd prefer an optional service provider plus named backend services over a new extension primitive. It matches the existing Cordis idiom (ctx.effect()-based registrations, service definition + providers), and it's naturally prepend-immune because the service is consulted before the waterfall rather than participating in it.
3. Session-owned seems most consistent: approval policy is already per-session (effectiveApprovalPolicy(session.events)), so binding ownership selection to the session scope keeps all the decision inputs co-located. Deployment-owned is fine for the common single-answerer case but loses the ability to vary behavior per session.
4. A deadline is worth considering, but I'd frame it as optional and orthogonal to this RFC — the current abort/cancellation path already settles fail-closed on signal (decide() races against req.signal), so a deadline is arguably a separate policy concern from deterministic ownership. Worth a follow-up, not a blocker for this design.

One thing I'd want to see clarified before merging: when a dispatcher is present but no backend is selected/valid, you fail closed to unavailable. That matches the existing missing-answerer behavior, but could a misconfigured dispatcher silently turn an interactive Browser-only session into a permanently unavailable session? If so, a start-up validation/warning (dispatcher configured but zero known backends) would help operators catch misconfiguration before it bites. Not a blocker — just a robustness note.

The dsh-switchyard reference patch looks like a clean, well-tested implementation. This is a good direction for the project.

[qfzlm]

Thanks for the independent source check — the never-policy precedent is especially useful, and I agree that it strengthens the case for keeping ownership before the listener waterfall.

The Session-owned direction also makes sense to me given the existing per-Session approval policy.

Good point on misconfiguration. The reference currently treats a selected missing/invalid backend as fail-closed unavailable by design, but a configured dispatcher with no usable backend could indeed turn an otherwise interactive Session into a permanent failure mode without a clear operator signal.

I’ll keep the fail-closed runtime semantics, but add a configuration/startup validation or warning as a separate robustness layer rather than making implicit fallback part of the ownership contract.

I also agree that a host-enforced deadline is orthogonal to deterministic ownership and can stay outside this RFC.

Thanks for reviewing the reference patch and checking the alpha.2 paths independently.