diff --git a/devdocs/02-前后端协同事项.md b/devdocs/02-前后端协同事项.md
index 4023348..ba20843 100644
--- a/devdocs/02-前后端协同事项.md
+++ b/devdocs/02-前后端协同事项.md
@@ -1108,3 +1108,27 @@ POST /api/v1/chat      (221-byte body) → 200 OK
 1. **多附件不再被输入护栏整回合拦掉**（G2/G2b）：护栏输入上限现在按**推导预算统一换算**（1M 窗口 ⇒ 2,796,200 字符），**5 份满额注入仍有余量**；`GUARDRAIL_MAX_INPUT_CHARS` 未设/`0` = 派生、`>0` = 覆盖、`<0` = WARN 回落。
 2. **IM 入站附件摄取已接通**（M1）：微信/QQ/Telegram/kook **收到的文件**会落内容寻址存储并进入该回合的用户消息 ⇒ 她能读到。
    ⚠️ **但现网适配器只上报 URL/ID、不给字节** ⇒ 真机上她目前只会得到「**无法读取：渠道只给了远程引用**」的诚实提示（我们**刻意不代取任意远程 URL**，与 `F3` 的 SSRF 教训一致）。**让 IM 文件真能读需要各适配器入站时下载并内联字节**（IM-1，等主人点头）。你们若在客户端做「发送文件给昔涟」的入口，**IM 渠道这条路暂时还不通**，优先走 Web/App 的 `POST /api/v1/documents`。
+
+---
+
+## 登记（客户端会话，2026-10-05 凌晨 · 跟上 v0.61 的 `.pdf` 之后的两条）
+
+### 一、`unreadable` 只有状态、没有原因 —— 建议 DTO 加一个可选 `reason`
+
+v0.61 让**扫描件/图片型 PDF** 落到 `status:"unreadable"`，而**原因文案**（「图片型/无文本层 PDF，需要 OCR（当前未做）」）只在**服务端侧**。
+
+- 客户端拿到的 `documents[]` 元素**只有** `name`/`mime`/`size`/`chars`/`truncated`/`status` —— **没有原因字段**。
+- 后果：界面上只能说通用的一句「读不到」。**我们刻意没有自己拼「图片型 PDF，需要 OCR」**——那是替服务端编它没说过的话。
+- **建议**：元素上加一个可选 `reason`（或 `note`，`omitempty`，只在该说的时候下发）。客户端**一处改**（芯片/弹层的文案取它，缺失时回落现有通用句）。
+- 优先级：低。**没有它我们不会少做什么**，只是用户少一句解释。
+
+### 二、一句措辞上的别扭（产品口径，不是缺陷）
+
+**文本层 PDF** 会被抽取成功 ⇒ 芯片显示「**已读入**」；而**本端**的预览对 PDF **不渲染正文**、只说「App 内不预览这类内容，请用『用其它应用打开』或『保存到下载目录』」。
+
+两句**都是真的**（服务端能读 ≠ 本端渲染 PDF 字节），但并排出现时用户可能觉得别扭。要不要把两句接起来说（例如「她已经读过了，但这类文件本机不预览」）是**产品口径**，我们没擅自编 —— 若你们在意，给个措辞我们就改。
+
+### 三、顺带确认（不用回执）
+
+- **`ExtractorVersion → documents/v3` 的既有附件重抽**：客户端**什么都不做**，照旧显示服务端回读的 `chars`/`truncated`；我们**没有**把它当数据损坏去加任何兜底。这条与你们「预期行为」的说法一致。
+- **成对裁决（扩展名 ∧ 字节嗅探）**：我们的选文件器只放行了 `application/pdf`（`v0.61` 第 23 项），最终裁决仍在服务端；被拒时**原样显示你们的 415 文案**，不假装成功。