Discovery: in-editor accept/reject (gate vs post-hoc review models)

[Cannon07]

Tracking + discovery issue for letting users accept/reject a proposed change from inside Neovim, without switching focus back to the agent's terminal pane.

Sources:

• Feature request: Feature request: accept diff via neovim keymap #69
• Discussion (in-editor approval): Accept changes without switching back to coding agent #50
• Discussion (post-hoc / VSCode-style review, Copilot manual+autopilot): Show diff when copilot cli runs in autopilot mode. #71
• Prior art: https://github.com/farouqaldori/vibe-notch (blocking-hook approach)

Motivation

The plugin's thesis is "review agent edits inside Neovim." Today that loop is only half-closed: you review in Neovim, then switch back to the agent's pane to confirm — and in autopilot there's no review window at all. Closing the loop completes the plugin's core promise.

Two candidate models (the core design fork)

Both answer the same friction; they are opposite mechanisms. The grill must pick one — or support both as a review_mode config.

Model A — Synchronous gate (decide before the write)

Block the hook; user accepts/rejects in Neovim; the agent waits for the decision and writes or skips accordingly. The review gate moves from agent-owned to plugin-owned (a direct evolution of [ADR-0002]).

• Crux blocker — per-agent feasibility. Requires the agent's hook protocol to accept an injected decision, not just observe:

  Agent	Hook can return allow/deny?	Status
  Claude Code	Yes (permissionDecision: allow/deny)	Likely doable
  OpenCode	Likely (TS plugin hook return)	Needs verification
  Codex	Native ask-loop — unclear	Needs spike
  Copilot	Native ask-loop — unclear	Needs spike

• Other problems: agent hook timeouts (slow hooks get killed), orphaned waits, nvim closing mid-wait, multi-proposal correlation (OpenCode fires all before-hooks first → a keypress must map to the right pending proposal).

Model B — Asynchronous post-hoc review (decide after the write; the VSCode model)

Let the agent apply the change (works in autopilot, no gate). The plugin keeps the diff open as a pending review; the user accepts (keep) or rejects (revert to original) in Neovim afterwards.

• Key advantage: depends on nothing in the agent's hook-return protocol → uniform across all backends (Claude Code, OpenCode, Codex, Copilot). Sidesteps Model A's feasibility spike entirely. This is the model the Copilot reporter is asking for.
• The plugin already captures the original content (orig tempfile); the change is: post-tool keeps the diff pending instead of closing it; accept clears it; reject writes the original back to disk.
• Hard parts:
  1. Revert correctness — if the file changed again between the agent's write and the user's reject, a naive revert clobbers. Needs staleness detection.
  2. Accumulation queue — autopilot lands many changes fast; the plugin must hold a queue of pending reviews, each retaining its captured original (richer than today's changes registry, which holds status only).
  3. Reject semantics per edit type — Edit = restore original; Write (new file) = delete; ApplyPatch = per-file; Bash write = not revertable (Tier 1 never captures content). Inherits the existing Tier 1/Tier 2 boundary.
  4. Partial accept — VSCode does per-hunk. Whole-file only for v1, or hunk-level? Major scope lever.
  5. Post-tool behavior fork — today post-tool closes the diff; this needs it to stay pending. Likely a review_mode = "gate" | "post_hoc" config.

Plan / sequencing

1. Land Windows support (Request Windows 11 support #46) first — already scoped and unblocked.
2. Grilling session + ADR-0007 — decide between Model A, Model B, or both-as-modes; design the pending-review registry, revert/staleness contract, config story, and Windows-shim coupling (the polling logic in Model A lives in the shim).
3. Per-agent feasibility spike — only needed if Model A is in scope. Model B needs no spike.
4. Implement. Model B is the more agent-universal starting point; Model A (or a Claude-Code-first gate) can layer on if the spike supports it.

Status: accepted, design deferred until after #46.