状态:✅ 已完成并人工验证(2026-09-17 归档到
completed/) 结果:会话、问答记录、反馈全部切到 DMS;回归脚本 36/36 通过(打真实 DMS); 浏览器人工点验通过(用户确认)。 存储粒度:一问一答一条(1889 幂等键c_record_id)。曾一度改成「一个会话一行、 整段对话 JSON 塞进 c_answer」,同日按用户要求改回本版——理由是这样更贴近库表原本的 语义(chat_record就是一行一轮问答),也便于按轮次检索/统计。 实测留痕:用户真实提问后库中数据 —— 1887 该会话 1 行(c_title=首问、c_credit_code=访客_68e82b71…)、1889 两轮问答 2 行(同c_session_id、不同c_record_id、c_question/c_answer均已写入),与约定完全一致。 日期:2026-09-17 前置:../active/dms-api-replacement.md(DMS 替换总方案)
把会话、问答记录、反馈从旧接口 {VITE_API}/chat/* 迁到 DMS 数据管理服务
(栏目 1887 助手会话 / 1889 助手问答记录),并且:
session.id(UUID,恒等于聊天协议 thread_id,跨刷新稳定)| 决策 | 选择 | 理由 |
|---|---|---|
| 会话标识 | session.id → c_session_id |
恒等于协议 thread_id,可与协议对账;跨刷新稳定 |
| 问答存储粒度 | 一个会话一行,整段消息 JSON 存 c_answer |
用户要求:一行拿到整个会话 |
| 写入方式 | 每次以本地 messages 为准整段重写 | 本地状态是权威;避免「读-改-写」的并发覆盖 |
| 反馈存储 | 写进该行 JSON 里对应那条消息上 | 用户选择;反馈仍能精确定位到某一轮 |
| 访客归属 | c_credit_code = 访客_<埋点访客id> |
复用现有访客 id,跨刷新稳定,零新增代码 |
| token | vite 代理注入,前端产物不含 | 避免把数据管理权限发给每个访客 |
progress.md Session 022):addContent 不需要 c_id、
返回记录 uuid(纯字符串)、删除是 POST /content/updateAudit + state=4、
时间戳格式与长文本往返.env.development 的 VITE_DMS_API / VITE_DMS_TARGET、
vite.config.ts 的 /dms-api/ 代理(补 /dms 前缀 + 注入 token)、
runtime-config.ts 的 getDmsApiBaseUrl()、index.html 注入src/network/api/dms/client.ts + 业务层 chat-sessions-dms.tschat-sessions.ts 换内部实现(签名不变,调用方零改动)sendMessage / totalResponse / close / submitQuestionAnswersBusinessRecord.vuesaveDmsTranscript() 整段重写;
fetchDmsSessionRecords() 从 JSON 还原问答对;writeDmsFeedback() 改成
「读整行 → 改那条消息 → 写回」,并与对话写入共用 session: 顺序链npm run build 通过node harness/tools/verify-dms-chat-storage.mjs <代理地址> —— 36/36 通过,
其中关键断言:第二轮后仍是一行(不是一封问答一行)、反馈只改命中那条消息、
另一条消息未被误改、定位不到时不新增行202,直连不带 token 208 无tokenBusinessRecord 的
localFeedback 初始恒为 None,未做「从 DMS 读回反馈态」的回填。要做得另接一条线。