docs(rfd): Add next edit suggestions RFD

[scotteveritt]

Summary

This RFD proposes adding support for next edit suggestions (tab-completions / predictive edits) to ACP. The proposal enables agents to proactively suggest:

• Edits the user might want to make next
• Navigation targets (cursor jumps) to where the next edit will occur
• Chained sequences of edits (tab-tab-tab flow)

Key Features

Feature	Description
Navigation suggestions	Predict cursor jumps alongside edits
Streaming	Token-by-token for ghost text UX
Partial acceptance	Word-by-word, line-by-line tracking
Retention tracking	Track if suggestions are kept/modified/deleted
Chained suggestions	hasFollowUp for tab-tab-tab flow
Invalidation	Mark stale suggestions

New Protocol Methods

• editContext/didChange - Context updates (Client → Agent)
• suggestions/request - Request suggestions (Client → Agent)
• suggestions/stream / streamEnd - Streaming (Agent → Client)
• suggestions/accept / reject / dismiss - User actions (Client → Agent)
• suggestions/retained - Retention tracking (Client → Agent)
• suggestions/offer / invalidate - Proactive suggestions (Agent → Client)

Research

Based on technical analysis of:

• Cursor Tab (edit + navigation prediction, tab-tab-tab sequences)
• GitHub Copilot NES (low-latency task-specific model)
• Supermaven (250ms latency, edit-diff context)
• Sourcegraph Cody (retention tracking, partial acceptance)

Test plan

• Review RFD structure and completeness
• Validate protocol design against existing ACP patterns
• Discuss scope (edits + navigation vs broader "next action")
• Consider integration with existing RFDs (cancellation, session modes)

[ignatov]

@scotteveritt wow! you're reading our minds! Thanks for the contribution!

[olegtaratuhin]

Thanks for putting this proposal together! It’s a solid start, though given the size of this feature space, there are naturally quite a few details we'll need to sort out before moving forward.

A few initial thoughts:

EditContext: The current context definition feels a bit too specific/opinionated. Since most implementations will likely have their own unique context sources, including non-essential parts here might complicate the protocol without adding value for the majority of adopters.

Partial Results: Making partial results a strict requirement might not be realistic. Depending on how a "nes agent" represents outputs internally, mapping them to incremental file changes isn't always technically feasible.

Suggestion Responses: These feel a bit restrictive, though it might be a reasonable starting point. We can likely assume that some client/agent pairs will end up needing non-standard additional suggestion types anyway.

Streaming: This is the biggest area for improvement. Streaming in UI in the editor is very distracting, somewhat of a proof of this is that no vendor on the market currently does it this and Supermaven backtracked on this UX very quickly after the initial release. It is also unclear how streaming deletions or modifications would work. Mandating this assumes specific internal representations, which severely constrains how "nes agents" can be built.

Invalidation: There is a potential issue here regarding state management. If clients act on assumptions about what invalidates the agent (e.g., treating any typing as a cancellation), it forces agents to maintain complex internal caching, likely duplicating effort across implementations.