update doc

docs/prompt-compatibility.md

@@ -45,7 +45,7 @@ DS2API 当前的核心思路，不是把客户端传来的 `messages`、`tools`
   -> 统一消息标准化
   -> tool prompt 注入
   -> DeepSeek 风格 prompt 拼装
-  -> 文件收集 / inline 上传 / history split
+  -> 文件收集 / inline 上传 / history split（OpenAI 链路）
   -> completion payload
   -> 下游网页对话接口
 ```
@@ -96,7 +96,7 @@ DS2API 当前的核心思路，不是把客户端传来的 `messages`、`tools`
 - `prompt` 才是对话上下文主载体。
 - `ref_file_ids` 只承载文件引用，不承载普通文本消息。
 - `tools` 不会作为“原生工具 schema”直接下发给下游，而是被改写进 `prompt`。
-- OpenAI、Responses、Claude、Gemini 等入口都会先翻译成统一的 OpenAI 兼容请求形状，再走同一套归一化与 DeepSeek payload 组装。
+- OpenAI Chat / Responses 原生走统一 OpenAI 标准化与 DeepSeek payload 组装；Claude / Gemini 会尽量复用 OpenAI prompt/tool 语义，其中 Gemini 直接复用 `openai.BuildPromptForAdapter`，Claude 消息接口在可代理场景会转换为 OpenAI chat 形态再执行。
 - 客户端传入的 thinking / reasoning 开关会被归一到下游 `thinking_enabled`。Claude surface 没有 `thinking` 字段时按 Anthropic 语义视为关闭；Gemini `generationConfig.thinkingConfig.thinkingBudget` 会翻译成同一套 thinking 开关；关闭时即使上游返回 `response/thinking_content`，兼容层也不会把它当作可见正文输出。
 
 ## 5. prompt 是怎么拼出来的
@@ -286,6 +286,7 @@ OpenAI 文件相关实现：
 - top-level `system` 优先作为系统提示
 - `tool_use` / `tool_result` 会被转换成统一的 assistant/tool 历史语义
 - `tools` 同样会被并进 system prompt
+- 常规执行通过 `internal/adapter/claude/handler_messages.go` 转到 OpenAI chat 路径，模型 alias 会先解析成 DeepSeek 原生模型
 - 当前代码里没有像 OpenAI 那样完整的 `ref_file_ids` 附件链路
 
 ### 10.3 Gemini
@@ -295,6 +296,7 @@ OpenAI 文件相关实现：
 - `systemInstruction`、`contents.parts`、`functionCall`、`functionResponse` 会先归一
 - tools 会转成 OpenAI 风格 function schema
 - prompt 构建复用 OpenAI 的 `BuildPromptForAdapter`
+- 未识别的非文本 part 会被安全序列化进 prompt，并对二进制/疑似 base64 内容做省略或截断处理
 
 也就是说，Gemini 在“最终 prompt 语义”上，尽量和 OpenAI 保持一致。