update capabilities and formatting

Author: benbrandt

docs/rfds/resume-session.mdx docs/rfds/session-resume.mdxdocs/rfds/resume-session.mdx renamed to docs/rfds/session-resume.mdx

@@ -2,7 +2,8 @@
 title: "Resuming of existing sessions"
 ---
 
-Author(s): [@josevalim](https://github.com/josevalim)
+- Author(s): [@josevalim](https://github.com/josevalim)
+- Champion: [@benbrandt](https://github.com/benbrandt)
 
 ## Elevator pitch
 
@@ -21,13 +22,13 @@ This means that, once you close your editor, browser, etc, you can't resume the
 This is particularly a problem for agents that do not directly implement ACP and the
 functionality is implemented via a wrapper. In such cases, they may provide the ability
 to resume (without history), which we would like to hook into. Not only that, resuming
-could be used as a mechanism for proxies and adapter libraries to emulate "session/load". 
+could be used as a mechanism for proxies and adapter libraries to emulate "session/load".
 
 ## What we propose to do about it
 
 > What are you proposing to improve the situation?
 
-Add a "session/resume" command and a capability `resumeSession: true`.
+Add a "session/resume" command and a capability `{ session: { resume: {} }`.
 
 ## Shiny future
 
@@ -45,19 +46,21 @@ the stored messages.
 
 > Tell me more about your implementation. What is your detailed implementation plan?
 
-<!--
-    Use this section to add details that were not covered in the "What we propose to do about it" section and also include an implementation plan with phases.
-
-    Note: This section is OPTIONAL and NOT RECOMMENDED when RFDs are first opened. It can distract from the discussion of the problem.
--->
-
 ## Frequently asked questions
 
 > What questions have arisen over the course of authoring this document or during subsequent discussions?
 
-<!--
-    Keep this section up-to-date as discussion proceeds. The goal is to capture major points that came up on a PR or in a discussion forum -- and if they reoccur, to point people to the FAQ so that we can start the dialog from a more informed place.
--->
+### Should we introduce a new operation (session/resume) or add an option to (session/load)?
+
+A separate method provides a few benefits:
+
+- for clients that for whatever reason don't want the history, they can just resume
+
+- for agents that can only supply resume, a proxy on top could provide load on top of it,
+  but the agent is still clear on what it supports
+
+- for agents who support both, it should be trivial to use the same resume functionality,
+  they just either replay events or do not
 
 ### What alternative approaches did you consider, and why did you settle on this one?
 
@@ -77,18 +80,6 @@ mechanics. If an agent implements "session/load", then it can be used directly,
 doesn't, a proxy or adapter can provide a reasonable fallback on top of "session/resume".
 This argues "session/resume" is the basic primitive which "session/load" builds on top of.
 
-### Should we introduce a new operation (session/resume) or add an option to (session/load)?
-
-A separate method provides a few benefits:
-
-* for clients that for whatever reason don't want the history, they can just resume
-
-* for agents that can only supply resume, a proxy on top could provide load on top of it,
-  but the agent is still clear on what it supports
-
-* for agents who support both, it should be trivial to use the same resume functionality,
-  they just either replay events or do not
-
 ## Revision history
 
-* 2025-11-24: Update FAQ to mention session/resume vs session/load
+- 2025-11-24: Update FAQ to mention session/resume vs session/load