api-compat-review

# API Compatibility Review Framework Assess API changes by surface — the MCP tool surface (dynamically re-discovered by clients) and the REST surface (hardcoded clients) have different compatibility models. Do not apply REST-style breaking-change caution to MCP tools, and do not apply MCP's rename-friendliness to REST. ## Step 1: Classify the Change Determine which surface(s) the change touches: - **MCP tools** — `application/tools/` tool definitions, `parameterSchema`, tool `description` strings - **REST API** — `interfaces/api/v1/routes/`, `interfaces/api/v1/dto/Dtos.kt`, `openapi.yaml` A single change (e.g., a domain model field rename) can touch both surfaces independently — assess each. ## Step 2: MCP Surface Assessment LLM clients re-read the `tools/list` schema every session — there is no persistent client binding to break. A pure parameter rename does NOT require keeping the old name working. Verify instead: - [ ] Every changed param's `parameterSchema` key and its arg-parsing read site stay in sync — no schema-says-X/code-reads-Y drift - [ ] ALL first-party callers update in lockstep: plugin skills, hooks, output styles, auto-memory references, and `api-reference.md`. This doc coordination is the real cost of an MCP change, not client breakage. - [ ] The tool `description` string accurately reflects the new behavior ## Step 3: REST Surface Assessment HTTP clients hardcode field and param names, so compatibility DOES matter here: - [ ] Response-shape changes a...