# Resolution devices runtime

Pending previews and plan approval no longer use a `resolve` tool. They finalize through three plain-text writes handled by `packages/coding-agent/src/tools/resolve.ts`:

- `/xdev/resolve` — apply the pending staged preview; body = reason text
- `/xdev/reject` — discard the pending staged preview; body = reason text
- `/xdev/propose` — submit the plan for approval while plan mode is active; body = the plan slug/title (`<slug>` for `local://<slug>-plan.md`)

## Preview flows

Preview producers call `queueResolveHandler(...)` with `apply(reason)` and optional `reject(reason)` callbacks. That registers a non-forcing pending invoker in `ToolChoiceQueue`.

While a preview is pending, `AgentSession.nextToolChoiceDirective()` returns a soft requirement:

- `toolName: "write"`
- `satisfies: isPreviewResolutionToolCall`
- reminder from `resolve-device-reminder.md`

So the model can comply by writing to `/xdev/resolve` or `/xdev/reject`; a write to any other path is still a detour and gets skipped/escalated.

Dispatch path:

- `dispatchResolutionDevice(session, "resolve" | "reject", text)`
- `peekQueueInvoker() ?? peekPendingInvoker()`
- `runResolveInvocation(...)`

`reject` with no pending action succeeds (`Nothing to reject; no pending action remains.`). `resolve` with no pending action throws.

## Plan approval

Plan mode installs a separate proposal handler through `setPlanProposalHandler(...)`.

- `InteractiveMode` uses it to hand `PlanApprovalDetails` to the plan-review UI.
- ACP mode uses it to run elicitation/approval and emit mode updates.
- PlanYolo uses it to auto-approve and switch to the execution target.

Dispatch path:

- `dispatchResolutionDevice(session, "propose", title)`
- `peekPlanProposalHandler()`

`/xdev/propose` is only valid while plan mode is active.

## Why `write` is guaranteed

Because previews and plan approval now ride `write`, the harness keeps `write` available whenever it is needed:

- `createTools(...)` auto-appends `write` when a `deferrable` tool is active (e.g. `ast_edit`)
- `createAgentSession(...)` keeps `write` registered when a deferrable tool exists or plan mode is enabled

## Custom tools

Custom tools still stage previews through `pushPendingAction(...)`; the loader forwards them into `queueResolveHandler(...)`. Nothing about the custom-tool API changes except the model-facing finalization step: the follow-up is now a plain-text write to `/xdev/resolve` or `/xdev/reject`, not a `resolve` tool call.