mcp修复

docs/architecture/spatial-mcp-v1.md

@@ -4,14 +4,22 @@
 
 首版 MCP 内嵌在现有 Go 服务中，使用标准库实现 HTTP/JSON-RPC 协议层，使用 `pgx/v5` 原生连接池访问 PostgreSQL/PostGIS。没有引入 MCP SDK、Web 框架或 ORM。
 
-采用这一边界是因为当前只需要 SuperAgent 已验证的 `2025-06-18` 四个方法和同步 JSON 响应；业务复杂度位于固定空间查询、权限范围和安全语义，而不是协议框架。
+采用这一边界是因为当前只需要与不能配置协议版本的 SuperAgent 客户端协作：服务端实际提供 `2025-06-18` 版本标识、四个方法和同步 JSON 响应；版本字段和 Header 按已稳定接通的 SuperAgent 兼容档案处理，不作为拒绝门禁。业务复杂度位于固定空间查询、权限范围和安全语义，而不是协议框架。
+
+## SuperAgent 兼容档案
+
+同一 SuperAgent 中已稳定启用的 `th-hotel-simple-superagent` 服务不会读取 `initialize.params.protocolVersion`，也不会读取或校验 `MCP-Protocol-Version` Header；它固定返回 `2025-06-18`，并正常处理 `notifications/initialized`、`tools/list` 与 `tools/call`。本项目对齐这一已验证的接入方式，目标是让 SuperAgent 能调用消防 MCP，而不是追求最新 MCP 版本。
+
+`initialize.params.protocolVersion` 的缺失、空值、非字符串或其他值，不单独触发版本拒绝；可解析的 JSON-RPC initialize 始终返回 `result.protocolVersion: "2025-06-18"`。`MCP-Protocol-Version` Header 同样不作为拒绝门禁，SuperAgent 配置中无需增加版本或 Header 项。服务端并不因此实现或声明支持客户端填写的任意版本，也不把 `2025-03-26`、`2025-11-25` 等版本列为实现目标；固定返回 `2025-06-18` 是兼容响应。
+
+上述兼容仅针对版本元数据。HTTP 方法、JSON-RPC 结构、独立 Bearer、`Content-Type`、非空 `Origin`、工具 schema、只读查询、服务端数据范围和结果脱敏等安全及业务边界仍由 Handler、Service 和 Repository 强制执行。initialize 结果可按实际字段记录 `direct_success`（值为 `2025-06-18`）或 `compatibility_success`（缺失或其他值被兼容处理），不得记录原始版本值。
 
 ## 模块关系
 
 ```mermaid
 flowchart TD
     APP["internal/app\n依赖装配与 readiness"]
-    H["internal/handler\nBearer、JSON-RPC、schema、限流边界"]
+    H["internal/handler\nBearer、JSON-RPC、握手协商、schema、限流边界"]
     S["internal/service\n查询边界、超时、结果语义"]
     D["internal/domain\n稳定空间领域对象"]
     R["internal/repository\npgxpool、固定参数化 PostGIS SQL"]