fix(unstable): Fix plan capability key (#1369)

Should match the rest of the fields in the object

Author: benbrandt

docs/protocol/v1/draft/agent-plan.mdx

@@ -7,7 +7,7 @@ Plans are execution strategies for complex tasks that require multiple steps.
 
 Agents may share plans with Clients through [`session/update`](/protocol/v1/draft/prompt-turn#3-agent-reports-output) notifications, providing real-time visibility into their thinking and progress.
 
-The existing `plan` update is the baseline format. Clients that advertise `planCapabilities` during [initialization](/protocol/v1/draft/initialization#client-capabilities) can also receive identified plan operations through `plan_update` and `plan_removed`.
+The existing `plan` update is the baseline format. Clients that advertise `plan` during [initialization](/protocol/v1/draft/initialization#client-capabilities) can also receive identified plan operations through `plan_update` and `plan_removed`.
 
 ## Creating Plans
 
@@ -50,7 +50,7 @@ When the language model creates an execution plan, the Agent **SHOULD** report i
 
 ## Plan Operations
 
-Agents **MUST NOT** send `plan_update` or `plan_removed` unless the Client advertised `planCapabilities`. If the Client omits `planCapabilities`, the Agent **MUST** fall back to the existing `plan` update.
+Agents **MUST NOT** send `plan_update` or `plan_removed` unless the Client advertised `plan`. If the Client omits `plan`, the Agent **MUST** fall back to the existing `plan` update.
 
 `plan_update` carries a `plan` object with a `type` discriminator. Every plan format includes a required `id` so Clients can track multiple plans independently.
 

docs/protocol/v1/draft/schema.mdx

@@ -3232,7 +3232,7 @@ This capability is not part of the spec yet, and may be removed or changed at an
 NES (Next Edit Suggestions) capabilities supported by the client.
 
 </ResponseField>
-<ResponseField name="planCapabilities" type={<><span><a href="#plancapabilities">PlanCapabilities</a></span><span> | null</span></>} >
+<ResponseField name="plan" type={<><span><a href="#plancapabilities">PlanCapabilities</a></span><span> | null</span></>} >
   **UNSTABLE**
 
 This capability is not part of the spec yet, and may be removed or changed at any point.

docs/rfds/plan-operations.mdx

@@ -36,14 +36,14 @@ All variants carry a required `id: string` that identifies the plan, and an opti
 
 Additionally, introduce a `plan_removed` session update type that carries only a plan `id` to signal dismissal. This keeps `plan_update` focused purely on content updates and makes removal a distinct, self-describing event.
 
-The existing `plan` session update type is **not modified** and continues to work as before. Agents that want multi-plan support, new plan formats, or removal capabilities use `plan_update` and `plan_removed` only when the client advertises `planCapabilities`; otherwise they fall back to the existing `plan` session update type.
+The existing `plan` session update type is **not modified** and continues to work as before. Agents that want multi-plan support, new plan formats, or removal capabilities use `plan_update` and `plan_removed` only when the client advertises `plan`; otherwise they fall back to the existing `plan` session update type.
 
 ### Client Capabilities
 
 Add to `ClientCapabilities`:
 
 ```
-planCapabilities?: PlanCapabilities
+plan?: PlanCapabilities
 ```
 
 This field is optional. When present as `{}`, it signals the client supports the `plan_update` and `plan_removed` session update types. When omitted, the client does not advertise support, and the agent must fall back to the existing `plan` session update type.
@@ -64,7 +64,7 @@ Agent sends a `plan_removed` session update with the plan's `id` to dismiss it.
 
 > How will things will play out once this feature exists?
 
-Agents will be able to present plans in the format most natural to them — structured checklists for step-by-step execution, markdown for free-form design docs, or file URIs for large plans generated externally. Clients that support `plan_update` can show multiple concurrent plans (e.g., a high-level strategy and a detailed implementation checklist), and dismiss plans that are no longer relevant. Clients that don't advertise `planCapabilities` continue to receive the existing `plan` updates with no changes.
+Agents will be able to present plans in the format most natural to them — structured checklists for step-by-step execution, markdown for free-form design docs, or file URIs for large plans generated externally. Clients that support `plan_update` can show multiple concurrent plans (e.g., a high-level strategy and a detailed implementation checklist), and dismiss plans that are no longer relevant. Clients that don't advertise `plan` continue to receive the existing `plan` updates with no changes.
 
 ## Implementation details and plan
 
@@ -137,7 +137,7 @@ Removal:
 
 ### Why a new session update type instead of extending the existing `plan`?
 
-The existing `plan` variant flattens `Plan`'s `entries` field directly into the `SessionUpdate` discriminated union object. Adding a nested `plan` field, optional `id`, and polymorphic types to the same variant would require breaking the existing format or complex dual-deserialization logic. A new `plan_update` variant avoids this, but agents must only send it to clients that advertised `planCapabilities`; clients that do not advertise support can continue to receive the existing `plan` update.
+The existing `plan` variant flattens `Plan`'s `entries` field directly into the `SessionUpdate` discriminated union object. Adding a nested `plan` field, optional `id`, and polymorphic types to the same variant would require breaking the existing format or complex dual-deserialization logic. A new `plan_update` variant avoids this, but agents must only send it to clients that advertised `plan`; clients that do not advertise support can continue to receive the existing `plan` update.
 
 ### Why a separate `plan_removed` session update type instead of a removal variant inside `plan_update`?
 

docs/rfds/v2/plan-variants.mdx

@@ -25,7 +25,7 @@ For now, v2 should stabilize only the item-based plan content variant:
 }
 ```
 
-The markdown, file, and removal pieces from [Plan Operations Support](/rfds/plan-operations) remain behind the unstable plan-operations feature while that RFD continues. V2 does not need a separate `planCapabilities` runtime handshake for those unstable operations.
+The markdown, file, and removal pieces from [Plan Operations Support](/rfds/plan-operations) remain behind the unstable plan-operations feature while that RFD continues. V2 does not need a separate `plan` runtime handshake for those unstable operations.
 
 ## Status quo
 
@@ -55,10 +55,10 @@ ACP v2 should:
 - Stabilize only the `plan.type: "items"` content variant for now.
 - Keep unknown plan content variants parseable and preservable using the [v2 enum variant extension](/rfds/v2/enum-variant-extension) rules.
 - Require every plan content variant, including unknown future/custom variants, to carry a plan `id`.
-- Remove `ClientCapabilities.planCapabilities` from v2.
+- Remove `ClientCapabilities.plan` from v2.
 - Keep `markdown`, `file`, and `plan_removed` behind `unstable_plan_operations` until the Plan Operations RFD settles.
 
-The stable v2 `plan_update` shape does not require a capability. The unstable plan operations remain gated by the draft unstable protocol surface, not by a v2 `planCapabilities` field.
+The stable v2 `plan_update` shape does not require a capability. The unstable plan operations remain gated by the draft unstable protocol surface, not by a v2 `plan` field.
 
 ### Compatibility
 
@@ -93,7 +93,7 @@ Clients that only understand item-based plans can still preserve or display unkn
 
 ### Why not wait for the Plan Operations RFD to complete?
 
-The item-based tagged shape is enough to make v2 extensible and remove the old flattened plan variant. The rest of the Plan Operations RFD can continue behind the unstable feature flag. V2 does not need `planCapabilities` because those operations are either part of the draft unstable protocol surface or absent from the stable schema.
+The item-based tagged shape is enough to make v2 extensible and remove the old flattened plan variant. The rest of the Plan Operations RFD can continue behind the unstable feature flag. V2 does not need `plan` because those operations are either part of the draft unstable protocol surface or absent from the stable schema.
 
 ### Why use `main` for v1 conversion?
 

schema/schema.unstable.json

@@ -1025,7 +1025,7 @@
           "description": "**UNSTABLE**\n\nThis capability is not part of the spec yet, and may be removed or changed at any point.\n\nNES (Next Edit Suggestions) capabilities supported by the client.",
           "x-deserialize-default-on-error": true
         },
-        "planCapabilities": {
+        "plan": {
           "anyOf": [
             {
               "$ref": "#/$defs/PlanCapabilities"

src/v1/client.rs

@@ -1579,7 +1579,7 @@ pub struct ClientCapabilities {
     #[serde_as(deserialize_as = "DefaultOnError")]
     #[schemars(extend("x-deserialize-default-on-error" = true))]
     #[serde(default)]
-    pub plan_capabilities: Option<PlanCapabilities>,
+    pub plan: Option<PlanCapabilities>,
     /// **UNSTABLE**
     ///
     /// This capability is not part of the spec yet, and may be removed or changed at any point.
@@ -1662,11 +1662,8 @@ impl ClientCapabilities {
     /// Supplying `{}` means the client can receive both update types.
     #[cfg(feature = "unstable_plan_operations")]
     #[must_use]
-    pub fn plan_capabilities(
-        mut self,
-        plan_capabilities: impl IntoOption<PlanCapabilities>,
-    ) -> Self {
-        self.plan_capabilities = plan_capabilities.into_option();
+    pub fn plan(mut self, plan: impl IntoOption<PlanCapabilities>) -> Self {
+        self.plan = plan.into_option();
         self
     }
 
@@ -2293,14 +2290,14 @@ mod tests {
             })
         );
 
-        let capabilities = ClientCapabilities::new().plan_capabilities(PlanCapabilities::new());
+        let capabilities = ClientCapabilities::new().plan(PlanCapabilities::new());
         let json = serde_json::to_value(&capabilities).unwrap();
-        assert_eq!(json["planCapabilities"], json!({}));
+        assert_eq!(json["plan"], json!({}));
 
         assert_eq!(
-            serde_json::from_value::<ClientCapabilities>(json!({ "planCapabilities": null }))
+            serde_json::from_value::<ClientCapabilities>(json!({ "plan": null }))
                 .unwrap()
-                .plan_capabilities,
+                .plan,
             None
         );
     }

src/v2/conversion.rs

@@ -1665,7 +1665,7 @@ impl IntoV1 for super::ClientCapabilities {
             fs: crate::v1::FileSystemCapabilities::default(),
             terminal: false,
             #[cfg(feature = "unstable_plan_operations")]
-            plan_capabilities: None,
+            plan: None,
             #[cfg(feature = "unstable_auth_methods")]
             auth: auth.into_v1()?,
             #[cfg(feature = "unstable_elicitation")]
@@ -1687,7 +1687,7 @@ impl IntoV2 for crate::v1::ClientCapabilities {
             fs: _,
             terminal: _,
             #[cfg(feature = "unstable_plan_operations")]
-                plan_capabilities: _,
+                plan: _,
             #[cfg(feature = "unstable_auth_methods")]
             auth,
             #[cfg(feature = "unstable_elicitation")]