docs(rfd): align plan identifier naming with schema (#2384)

Author: benbrandt

docs/rfds/plan-operations.mdx

@@ -32,9 +32,9 @@ Add a new `SessionUpdate` variant — `plan_update` — that carries a `plan` fi
 | `file`     | Agent provides a file URI containing the plan         | `uri: string`          |
 | `markdown` | Agent provides raw markdown text                      | `content: string`      |
 
-All variants carry a required `id: string` that identifies the plan, and an optional `_meta` for extensibility.
+All variants carry a required `planId: string` that identifies the plan, and an optional `_meta` for extensibility.
 
-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.
+Additionally, introduce a `plan_removed` session update type that carries only a `planId` 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 `plan`; otherwise they fall back to the existing `plan` session update type.
 
@@ -50,15 +50,15 @@ This field is optional. When present as `{}`, it signals the client supports the
 
 ### Multiple Plans
 
-The `id` field on every plan variant identifies a specific plan.
+The `planId` field on every plan variant identifies a specific plan.
 
-- Each `plan_update` targets the plan with the given `id`
+- Each `plan_update` targets the plan with the given `planId`
 - Client tracks plans by ID; updates replace the content of that specific plan
 - Different plans may use different types (e.g., one `items` plan and one `markdown` plan)
 
 ### Plan Removal
 
-Agent sends a `plan_removed` session update with the plan's `id` to dismiss it. This is a separate session update type from `plan_update`, keeping content updates and lifecycle events distinct.
+Agent sends a `plan_removed` session update with the plan's `planId` to dismiss it. This is a separate session update type from `plan_update`, keeping content updates and lifecycle events distinct.
 
 ## Shiny future
 
@@ -88,7 +88,7 @@ Item-based (`plan_update`):
   "sessionUpdate": "plan_update",
   "plan": {
     "type": "items",
-    "id": "plan-1",
+    "planId": "plan-1",
     "entries": [
       { "content": "Step 1", "priority": "high", "status": "pending" }
     ]
@@ -103,7 +103,7 @@ Markdown:
   "sessionUpdate": "plan_update",
   "plan": {
     "type": "markdown",
-    "id": "plan-1",
+    "planId": "plan-1",
     "content": "## Steps\n- [ ] Refactor module\n- [ ] Add tests"
   }
 }
@@ -116,7 +116,7 @@ File-based:
   "sessionUpdate": "plan_update",
   "plan": {
     "type": "file",
-    "id": "design-doc",
+    "planId": "design-doc",
     "uri": "file:///tmp/plan.md"
   }
 }
@@ -127,7 +127,7 @@ Removal:
 ```json
 {
   "sessionUpdate": "plan_removed",
-  "id": "plan-1"
+  "planId": "plan-1"
 }
 ```
 
@@ -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 `plan`; 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 `planId`, 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

@@ -17,7 +17,7 @@ For now, v2 should stabilize only the item-based plan content variant:
   "sessionUpdate": "plan_update",
   "plan": {
     "type": "items",
-    "id": "plan-1",
+    "planId": "plan-1",
     "entries": [
       { "content": "Step 1", "priority": "high", "status": "pending" }
     ]
@@ -54,7 +54,7 @@ ACP v2 should:
 - Add `sessionUpdate: "plan_update"` to the default v2 schema.
 - 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`.
+- Require every plan content variant, including unknown future/custom variants, to carry a `planId`.
 - Remove `ClientCapabilities.plan` from v2.
 - Keep `markdown`, `file`, and `plan_removed` behind `unstable_plan_operations` until the Plan Operations RFD settles.
 
@@ -83,8 +83,8 @@ Clients that only understand item-based plans can still preserve or display unkn
 3. Leave `PlanFile`, `PlanMarkdown`, and `PlanRemoved` behind `unstable_plan_operations`.
 4. Remove `SessionUpdate::Plan` from the v2 schema and make `SessionUpdate::PlanUpdate` the default plan variant.
 5. Keep the removed `sessionUpdate: "plan"` discriminator rejected so it cannot be accepted as an unknown v2 update.
-6. Require `id` on unknown `PlanUpdateContent` fallback payloads.
-7. Document that adapters may map the v1 `plan` update to v2 `plan_update` with `id: "main"`.
+6. Require `planId` on unknown `PlanUpdateContent` fallback payloads.
+7. Document that adapters may map the v1 `plan` update to v2 `plan_update` with `planId: "main"`.
 8. Regenerate v2 schema docs so the default v2 surface shows only the item-based tagged plan shape.
 
 ## Frequently asked questions