User Interaction

User Interaction

Edge adaptation of the upstream user question and confirmation system.

Upstream reference: User Interaction

What Upstream Provides

The user interaction subsystem (ctx.userQuestions) enables agents to pause execution and request human input when a tool or permission plugin needs approval to proceed.

• Question protocol — structured questions with stable IDs, optional multi-select, free-text "Other", and presentation intents (e.g. plan-review for plan approval).
• Provider seam — exactly one UserQuestionProvider may be active in a context. The UI registers the provider; the host runtime forwards questions to connected clients.
• Answer contract — responses carry selected option labels and optional custom text, keyed by question ID. Multi-select allows custom text alongside selections; single-select lets custom text override.
• Error taxonomy — EMPTY_QUESTIONS, NO_PROVIDER, ASK_ABORTED, CALLER_NOT_LIVE.

This capability is used by the approval system, plan mode, and any plugin that needs human confirmation before proceeding.

Current Edge Status

Not Implemented

Edge does not install the dsh-user-questions package or register a UserQuestionProvider. No user question flow exists — tools and plugins that call ctx.userQuestions.ask() will receive a NO_PROVIDER error.

The respond handler in edge-api.ts returns { accepted: false, reason: 'not-pending' } unconditionally — there are never any pending questions to respond to.

userQuestions is also one of ApiProxyService's four unsatisfied inject dependencies (alongside directoryPicker, subagents, sessionQuery), contributing to why Edge hand-writes createEdgeApi() instead of installing the upstream plugin.

Impact

• Approval system — cannot ask the user to approve dangerous operations before executing them.
• Plan mode — cannot present a plan for user review and approval.
• Tool confirmations — any tool guard that delegates to user questions silently fails.

What would be needed

The dsh-user-questions package (ctx.userQuestions) is a pure capability seam with no platform dependencies. The missing piece is a provider — a WebSocket-based implementation that forwards questions to the browser and collects responses. The client-side question UI already exists in the 33-plugin bundle (dsh-client-ui-conversation renders question nodes). The server-side provider needs to:

• Broadcast a session/question frame to the mux WebSocket
• Wait for a respond POST from the client
• Return the structured answer to the calling plugin

This follows the same transport bridge pattern as projection push and event broadcast. Works on all plans.

Architecture Summary

Component	Category	Status
UserQuestionService	Missing	Package available but not installed
WebSocket question provider	Missing	Needs Edge transport bridge implementation
Client question UI	Available	Already in client bundle

TODO

(#107) Install dsh-user-questions and implement a WebSocket-based provider. The upstream seam has no platform dependencies. The provider pattern mirrors the existing projection push bridge: broadcast to mux, wait for client response, deliver to caller. Would also unblock approval system, plan mode, and is one of four ApiProxyService dependencies.