docs: update divorce plan with Protocol feature audit and codegen approach

Protocol shim must include:
- notifications/cancelled handler (AbortController per request)
- notifications/progress handler (timeout reset on heartbeat)
- Auto-registered ping handler
- RequestHandlerExtra with signal, sessionId, sendRequest, sendNotification
- Timeout + maxTotalTimeout + resetTimeoutOnProgress

Schemas: generate all MCP Zod schemas from spec schema.ts via ts-to-zod
(same pipeline as existing ext-apps codegen).

Author: claude

docs/sdk-divorce-plan.md

@@ -60,13 +60,32 @@ onclose? / onerror?             u2014 callbacks
 fallbackNotificationHandler?    u2014 catch-all
 ```
 
-A minimal shim reproducing this surface is ~300 lines:
+A minimal shim reproducing this surface is ~400-500 lines:
 - JSON-RPC message routing (request/response correlation by ID)
 - Handler map keyed by method string (extracted from schema at registration time)
-- Timeout + AbortSignal support
-- Zod schema validation on incoming requests and outgoing results
+- Timeout + AbortSignal support for outbound requests
+- `notifications/cancelled` handler — aborts in-flight request handlers via AbortController
+- `notifications/progress` handler — forwards to per-request progress callbacks, resets timeouts
+- Auto-registered `ping` handler (returns `{}`)
+- Zod schema validation on incoming requests
+- `RequestHandlerExtra` construction (signal, sessionId, sendRequest, sendNotification)
 - No task management, no capability negotiation, no auth
 
+### Protocol features the shim MUST include
+
+| Feature | Why | How it works in V2 Protocol |
+|---------|-----|-----------------------------|
+| Request/response correlation | Core JSON-RPC plumbing | Map of message ID → response handler promise |
+| `notifications/cancelled` | Host/view can cancel in-flight requests | Auto-registered handler; calls `abortController.abort()` on matching request |
+| `notifications/progress` | Progress updates reset timeouts | Auto-registered handler; forwards to per-request progress callback |
+| `ping` auto-handler | Required by MCP spec | Auto-registered; returns `{}` |
+| Timeout + maxTotalTimeout | Prevents hung requests | `setTimeout` per request; reset on progress if opted in |
+| AbortSignal per request | Handler can observe cancellation | `AbortController` created per inbound request; passed in `extra.signal` |
+| `RequestHandlerExtra` | Handler context object | `{ signal, sessionId, sendRequest, sendNotification }` |
+| `onclose` / `onerror` callbacks | Lifecycle hooks | Called on transport close/error |
+| `fallbackRequestHandler` / `fallbackNotificationHandler` | Catch-all for unknown methods | Checked when no specific handler matches |
+| Debounced notifications | Batching for list-changed etc. | `_pendingDebouncedNotifications` map with `setTimeout` |
+
 ### For Zod schemas: Vendor from SDK or regenerate
 
 **Handler routing schemas** (11): These are only needed to extract the method string
@@ -87,13 +106,22 @@ the spec types. Or skip validation entirely (the SDK's V2 approach).
 
 **Composition schemas** (7 in `generated/schema.ts`): These are the trickiest.
 `ContentBlockSchema`, `ToolSchema`, etc. are used to compose ext-apps' own schemas.
-Options:
-1. Vendor the specific Zod schemas from SDK 1.29.0 source
-2. Regenerate from the spec schema.ts using `ts-to-zod` (ext-apps already uses this)
-3. Hand-write minimal versions
 
-**Wire validation** (1): `JSONRPCMessageSchema` u2014 vendor or redefine. It's a simple
-discriminated union.
+**Recommended: Generate all MCP Zod schemas from the spec types using `ts-to-zod`**,
+the same tool ext-apps already uses for its own `spec.types.ts` u2192 `generated/schema.ts`
+pipeline. The workflow:
+
+1. Copy `schema/2025-11-25/schema.ts` into `src/vendor/mcp-types.ts`
+2. Add a `generate:mcp-schemas` script that runs `ts-to-zod` on `mcp-types.ts`
+   outputting to `src/vendor/mcp-schemas.generated.ts`
+3. Update `src/generated/schema.ts` to import from `../vendor/mcp-schemas.generated.ts`
+   instead of from `@modelcontextprotocol/sdk/types.js`
+
+This gives us Zod schemas for everything u2014 request routing, result validation,
+schema composition, and wire validation u2014 all generated from a single source of truth.
+
+**Wire validation** (`JSONRPCMessageSchema`): Also generated by `ts-to-zod` from the
+spec types which define `JSONRPCMessage`, `JSONRPCRequest`, `JSONRPCNotification`, etc.
 
 ---
 
@@ -103,13 +131,12 @@ discriminated union.
 ext-apps/
 u251cu2500u2500 src/
 u2502   u251cu2500u2500 vendor/
-u2502   u2502   u251cu2500u2500 protocol.ts          # Minimal Protocol shim (~300 lines)
+u2502   u2502   u251cu2500u2500 protocol.ts          # Minimal Protocol shim (~450 lines)
 u2502   u2502   u251cu2500u2500 transport.ts         # Transport interface (~30 lines)
-u2502   u2502   u251cu2500u2500 jsonrpc.ts           # JSONRPCMessage types + validation schema
-u2502   u2502   u2514u2500u2500 mcp-types.ts         # Copy of spec schema.ts (chosen version)
+u2502   u2502   u2514u2500u2500 mcp-types.ts         # Copy of spec schema/2025-11-25/schema.ts
 u2502   u251cu2500u2500 generated/
-u2502   u2502   u2514u2500u2500 schema.ts            # Updated: import from vendor/ instead of SDK
-u2502   u251cu2500u2500 mcp-schemas.ts           # Minimal Zod schemas for MCP request/result types
+u2502   u2502   u251cu2500u2500 schema.ts            # ext-apps schemas (existing, updated imports)
+u2502   u2502   u2514u2500u2500 mcp-schemas.ts       # MCP Zod schemas (generated by ts-to-zod from mcp-types.ts)
 u2502   u251cu2500u2500 events.ts                # ProtocolWithEvents u2014 import from vendor/protocol.ts
 u2502   u251cu2500u2500 app.ts                   # Import types from vendor/mcp-types.ts
 u2502   u251cu2500u2500 app-bridge.ts            # Import types from vendor/mcp-types.ts
@@ -118,6 +145,11 @@ u251cu2500u2500 examples/                    # Still depend on SDK for McpServer
 u2514u2500u2500 docs/                        # Same
 ```
 
+The `generated/mcp-schemas.ts` file is produced by `ts-to-zod` from `vendor/mcp-types.ts`
+using the same pipeline ext-apps already uses for its own `spec.types.ts` u2192 `generated/schema.ts`.
+This gives us Zod schemas for all MCP types: `CallToolRequestSchema`, `JSONRPCMessageSchema`,
+`ContentBlockSchema`, etc. u2014 all from a single versioned source of truth.
+
 ### What stays as SDK dependency
 
 - **`examples/`** and **`docs/`**: These use `McpServer`, `StdioServerTransport`,
@@ -205,10 +237,11 @@ If we later need draft-only types, cherry-pick them.
 
 | Phase | Files changed | New code | Risk |
 |-------|--------------|----------|------|
-| 1. Vendor Protocol | 3-4 | ~350 lines | Medium u2014 must match V1 behavior exactly |
-| 2. Vendor MCP Types | 8-10 | ~100 lines (schemas) + copy spec | Low u2014 type-only changes except schemas |
+| 1. Vendor Protocol | 3-4 | ~450 lines | Medium u2014 must match V1 behavior (cancel, timeout, progress) |
+| 2. Vendor MCP Types + Schemas | 8-10 | ~0 hand-written (generated by ts-to-zod) + copy spec | Low u2014 same codegen pipeline as existing |
 | 3. Abstract Client | 3-4 | ~30 lines (interface) | Low u2014 structural subtyping |
 | 4. Clean up | 5-10 | 0 | Low u2014 import path changes |
 
-Total new code: ~480 lines (Protocol shim + schemas + interface).
+Total hand-written code: ~480 lines (Protocol shim + interface).
+Generated code: MCP Zod schemas (via ts-to-zod, same pipeline as today).
 Spec types file: ~67 KB copied from spec repo (2025-11-25 version).