服务端配合修改清单：聊天附件（移动端）

现状确认无需改动

移动端按上游契约发送，服务端已正常工作（本次复核确认）：

POST /api/v1/partners/{partner_id}/chat/execute-stream
{
  "content": "…",
  "session_key": "app-xxx",
  "attachments": [
    { "type": "image", "base64": "…", "filename": "a.png", "mime_type": "image/png", "url": "" }
  ]
}

• base64 解码落盘 media/web/{uuid12}_{filename} ✓
• 视觉/文档推理、SSE 流式回复 ✓
• 限制：单文件 20MB / 单批 25MB（413）、数据无效（422）✓

P0-1：附件下载端点已实施

新增端点（与建议形态一致，id 采用哈希反查而非路径拼接，结构性免疫路径穿越）：

GET /api/v1/partners/{partner_id}/attachments/{attachment_id}
鉴权: router 级 admin 依赖（与全部伙伴 API 一致）
attachment_id: 12 位十六进制 = sha1(文件绝对路径)[:12]（与 history 中的 id 同源）

实测：

P0-2：history 附件安全化已实施

history 响应中的附件记录现在长这样（实测，与建议字段完全一致）：

{
  "id": "f46731c5dce4",
  "type": "pdf",
  "filename": "2000_Core_Words.pdf",      ← uuid12_ 前缀已剥离
  "mime_type": "application/pdf",
  "size": 4083819,
  "download_url": "/api/v1/partners/dina/attachments/f46731c5dce4"
}

• path / base64 / extracted_text / extracted_chars 全部不再序列化（实测 0 残留；JSONL 存储保留全量，仅 API 出口裁剪）

P1-1：流式首帧 / 心跳已实施

• 采用周期心跳方案：静默 ≥10s 自动下发 event: ping（data 带 ts），客户端忽略内容但重置空闲计时即可
• session 帧本就早于推理发出（物料化在首帧前、耗时毫秒级），维持原语义以保证 413/422 仍以 HTTP 状态返回（移动端已依赖）
• 实测：25s 静默桩驱动已部署代码，收到 2 帧 ping（10s/20s 各一），随后 content/done 正常

可选项未实施 · 记录在案

1. 单条消息删除/撤回：暂缓——需动 JSONL 存储层，收益有限；当前以测试专用 session_key + 整会话删除管理测试污染
2. 附件配额与清理：暂缓——media/ 目前 5 个测试 PNG + 2 个真实文件，量级可忽略；达到 GB 级再做按 partner 配额

服务端验收清单（原始项逐条核对）

• 带 Bearer GET .../attachments/{id} 返回 200，文件字节与上传一致（md5 比对）
• 无 token → 401；伪造/他人 partner 的 attachment_id → 404；不存在 → 404
• attachment_id 含 ../ 等穿越尝试 → 400/404（哈希反查，绝不落到 media 目录外）
• history 响应中不再出现 /app/data/... 内部路径（附件字段已清洗；events 内工具命令文本除外——那是行为轨迹非结构泄露，且 slim 模式不含）
• Content-Disposition: attachment 且原始文件名可读（中文 UTF-8 实测正常）
• 大文件（4MB PDF）下载稳定（200 全量字节）；Range 断点未实现（非必需）

移动端对接速查