|
|
@@ -1736,3 +1736,44 @@
|
|
|
- ⚠️ 若写入被拒:是等 DMS 侧放宽 must,还是这些字段仍要传——**由用户定,前端不自行补**
|
|
|
- **下一步最佳动作**:拿到新 token 后跑 `verify-dms-chat-storage.mjs` 确认真实写入是否通过
|
|
|
|
|
|
+## Session 041
|
|
|
+
|
|
|
+- **日期**:2026-09-18
|
|
|
+- **本轮目标**:用户给了新的 DMS token,重跑真实写入验证
|
|
|
+- **Token**:有效期至 **2026-09-18 21:33**(已写入 `.env.development.local`,按约定不入库;
|
|
|
+ vite 代理已自动重启拾取,实测经代理查询返回 200)
|
|
|
+- **⚠️ 真实写入验证结果(决定性)**:
|
|
|
+ | 栏目 | 结果 |
|
|
|
+ |---|---|
|
|
|
+ | **1889 助手问答记录** | ✅ **写入正常**;`title = 问题文本` 已确认生效 |
|
|
|
+ | **1887 助手会话** | ❌ **被 `214 数据错误` 拒绝** |
|
|
|
+- **最小必需字段实测(addContent 二分)**:1887 **必须四个字段全带**,少任何一个都 214:
|
|
|
+
|
|
|
+ | 载荷 | 结果 |
|
|
|
+ |---|---|
|
|
|
+ | 全不带(= 当前前端) | 214 |
|
|
|
+ | +summary | 214 |
|
|
|
+ | +summary+qpyszx | 214 |
|
|
|
+ | +summary+qpyszx+qyzt | 214 |
|
|
|
+ | **四个都带** | **200 成功** |
|
|
|
+ | 只带 qpyszx(不带 summary) | 214 |
|
|
|
+
|
|
|
+- **结论:用户的两条要求与 DMS 现状冲突** ——
|
|
|
+ 用户要求「只传 title,不要 summary 这些多余字段」,
|
|
|
+ 而 DMS 的 1887 模型把这四个字段设成了 `must=true`。**二者不能同时满足**,必须有一方让步。
|
|
|
+- **当前应用的实际状态**:**1887 会话写入是坏的**(新建会话、改名、删除同步都写不进去),
|
|
|
+ 1889 记录行照常写入 → 表现为「DMS 里有问答记录、但没有对应的会话行」
|
|
|
+ (这也是用户此前反馈「改名后 title 不同步」的另一层原因)
|
|
|
+- **已清理**:本轮二分探测产生的 probe 行已删除(残留 0)
|
|
|
+- **运行过的验证**:`verify-dms-chat-storage.mjs`(打真实 DMS)——
|
|
|
+ 1889 相关全通过、1887 相关因 214 失败(如实记录,未粉饰)
|
|
|
+- **已记录证据**:本文件 Session 041;上面的二分表(原始响应为证)
|
|
|
+- **更新过的文件或工件**:`.env.development.local`(不入库)、本文件
|
|
|
+- **已知风险或未解决问题**(**需用户决策**):
|
|
|
+ - 三条路选一:
|
|
|
+ ①**DMS 侧把这四个字段改成非必填**(`must=false`)→ 前端就能只传 title(最贴合用户要求)
|
|
|
+ ②**前端仍传这四个** → 取值口径要定;也可以先传**空值/默认值**(`summary:""` 等)
|
|
|
+ 让写入先通,后续再定口径 —— 但这是"为了通过校验而填",需用户认可
|
|
|
+ ③**维持现状** → 1887 会话写入持续失败
|
|
|
+- **下一步最佳动作**:等用户在①②③中选一个
|
|
|
+
|