chore: docs 结构整改 + compose 双目录对齐(合并重建提交)
本提交为 .git 对象库损坏后的重建提交,内容等价于原先三个本地提交 (5e2fd4c2 / 57a53c98 / 5d7e1873)的累积结果,未做任何额外改动。 一、docs 结构整改(整改 #14) 根因:重构时新结构为 untracked 文件,执行 git stash(未带 -u)未纳入, 随后 git reset 拉回 HEAD 旧 tracked 树,导致旧树复活、新旧两棵目录 树并存于 docs/,共 791 文件、双分类体系冲突。 修复动作: - b2 同名异主题文件改名迁移保全 9 个 - C 类 39 个孤立文件按主题正确归类 - A/B1 类 222 个重复文件删除(新结构已有内容副本) - 9 个旧独有空目录删除 - 270 处内部引用按 verified 映射改写 - 整改记录 #14 登记于 04-运维文档/部署运维 结果:docs 791 → 569 文件,顶层仅规范 8 类 + 治理文件,单树恢复。 残留:约 20 处指向从未存在文件的陈旧死链,归入独立文档卫生任务。 二、compose 双目录对齐(消除踩坑 A) - docker-compose.yml:nginx 前端挂载全部由根目录 frontend-*/dist 改为 src/frontend-*/dist(h5 / agent / admin / terminal) - docker-compose.dev.yml:dev 服务 build context 与卷同步改 src/ - 效果:本地 docker compose up 不再把根目录 stale dist 挂回, 与线上一致,分叉隐患消除(已 docker compose config 校验通过) 防复发铁律: - 重构须提交;仓库修复须 git stash -u 或先 commit - 新结构须 git add 并提交,避免再次 untracked 复活 - H5 改动只动 src/frontend-h5/,禁改根目录遗留 frontend-*/
This commit is contained in:
@@ -0,0 +1,146 @@
|
||||
# 任务说明书
|
||||
|
||||
> **版本**: v1.0 | **日期**: 2026-07-24
|
||||
|
||||
---
|
||||
|
||||
## 📋 基本信息
|
||||
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| **任务名称** | H5选项交互消息重复处理 |
|
||||
| **任务ID** | #125 |
|
||||
| **优先级** | 🔴P0 |
|
||||
| **类型** | Bug修复 |
|
||||
| **状态** | 已完成 |
|
||||
| **负责人** | Simon / 助理 |
|
||||
| **创建日期** | 2026-07-24 |
|
||||
| **计划完成日期** | 2026-07-24 |
|
||||
|
||||
---
|
||||
|
||||
## 📥 输入项来源
|
||||
|
||||
### 产品需求
|
||||
| 来源文档 | 相关章节 | 说明 |
|
||||
|----------|----------|------|
|
||||
| `01-产品文档/03-AI服务/PRD-REQ-AI-004-AI回复来源标识-v1.0.md` | §1 | AI对话交互流程 |
|
||||
|
||||
### 技术方案(参考)
|
||||
| 来源文档 | 相关章节 | 说明 |
|
||||
|----------|----------|------|
|
||||
| `02-技术文档/实现配置/AI对话链路全栈改造实施计划-v1.0.md` | §3.6 / §4.5 | 选项回传链路(option_select)、WS消息处理 |
|
||||
|
||||
> ⚠️ 本次修复是对现有选项回传链路的Bug修复,根因是前端消息处理逻辑问题,不涉及技术方案变更。
|
||||
|
||||
### 需了解的现有代码(历史现状)
|
||||
| 模块/文件 | 说明 | 需了解的内容 |
|
||||
|-----------|------|-------------|
|
||||
| `frontend-h5/src/stores/conversation.ts` | H5消息状态管理 | sendOptionSelect函数、消息去重机制 |
|
||||
|
||||
---
|
||||
|
||||
## 📤 输出成果要求
|
||||
|
||||
### 交付物清单
|
||||
|
||||
| # | 交付物 | 类型 | 说明 |
|
||||
|---|--------|------|------|
|
||||
| 1 | `frontend-h5/src/stores/conversation.ts` | 代码 | 修复选项选择消息重复逻辑 |
|
||||
| 2 | `docs/04-运维文档/部署运维/00-标准故障排查手册.md` | 文档 | 新增CASE-20260724-01 |
|
||||
|
||||
---
|
||||
|
||||
## 🎯 问题描述
|
||||
|
||||
### 现象
|
||||
员工端H5点击AI提供的选项后,出现两条相同的员工消息(如"检查同步设置")。
|
||||
|
||||
### 时间特征
|
||||
- 一条立即出现
|
||||
- 另一条约3秒后出现(轮询间隔)
|
||||
|
||||
### 坐席端表现
|
||||
坐席端只看到一条消息(说明后端只存储了一条,问题在前端显示)。
|
||||
|
||||
---
|
||||
|
||||
## 🔍 根因分析
|
||||
|
||||
### 直接原因
|
||||
1. 前端点击选项时:本地立即添加消息(message_id = `option_select_${timestamp}`)
|
||||
2. 后端收到后:存储到数据库(message_id = UUID,与前端不同)+ 广播给前端
|
||||
3. 前端收到后端广播的消息时,因为 message_id 不同,去重检查失效,导致重复添加
|
||||
|
||||
### 根本原因
|
||||
- 前端本地添加的消息与后端存储的消息 message_id 不同
|
||||
- 去重机制基于 message_id 无法识别这种场景
|
||||
|
||||
---
|
||||
|
||||
## 🛠 修复方案
|
||||
|
||||
### 核心思路
|
||||
前端不再本地立即添加消息,只发 WS 给后端,等后端存储后通过轮询/广播回来再添加,确保消息来源唯一。
|
||||
|
||||
### 修改内容
|
||||
- 修改 `frontend-h5/src/stores/conversation.ts` 中的 `sendOptionSelect` 函数
|
||||
- 移除本地立即添加消息的代码
|
||||
- 依赖后端回传后添加消息
|
||||
|
||||
---
|
||||
|
||||
## ✅ 验证结果
|
||||
|
||||
H5点击选项后只显示一条消息,问题已修复。
|
||||
|
||||
---
|
||||
|
||||
## 📎 关联文档
|
||||
|
||||
- `docs/04-运维文档/部署运维/00-标准故障排查手册.md` - CASE-20260724-01
|
||||
- `.workbuddy/memory/MEMORY.md` - 前端消息处理规范
|
||||
|
||||
---
|
||||
|
||||
## 💡 设计改进建议(补充到产品设计文档)
|
||||
|
||||
### 问题反思
|
||||
本次Bug的表层是技术问题(前后端ID不一致),但深层是**产品设计文档中没有定义「用户点击选项后的界面反馈是什么」**。
|
||||
|
||||
### 应该补充到产品/设计文档的内容
|
||||
|
||||
| 文档 | 需补充内容 | 目的 |
|
||||
|------|-----------|------|
|
||||
| **PRD 需求文档** | 明确「用户交互反馈」规范 | 定义「选中即禁用」还是「显示待确认消息」 |
|
||||
| **UI/UX 设计稿** | 补充「选项卡选中态」设计 | 选中后的视觉表现(变灰/高亮/加载中) |
|
||||
| **技术设计文档** | 补充「消息添加时机」原则 | 前端不应在收到后端确认前添加消息 |
|
||||
|
||||
### 具体需要确认的产品问题(以「用户点击AI选项」为例)
|
||||
|
||||
| 问题 | 选项A | 选项B | 选项C |
|
||||
|------|-------|-------|-------|
|
||||
| **点击后界面立即显示什么?** | 显示"发送中..."状态 | 显示该选项内容作为消息 | 按钮变灰+显示处理中 |
|
||||
| **何时显示正式消息?** | 等后端返回后 | 等后端返回后 | 等后端返回后 |
|
||||
| **如果后端失败?** | 显示错误提示 | 消息变红/撤回 | 按钮恢复+提示错误 |
|
||||
|
||||
### 推荐的设计方案
|
||||
选中即禁用 + 等待后端消息:
|
||||
1. 用户点击选项 → 按钮立即设为「禁用状态 + 高亮选中态」
|
||||
2. 静默发送 WS 给后端(不添加本地消息)
|
||||
3. 后端处理完成 → 广播 new_message
|
||||
4. 前端收到后端消息 → 添加到消息列表,渲染真正的员工消息
|
||||
|
||||
**优点**:
|
||||
- 用户体验更好:选中即有视觉反馈
|
||||
- 逻辑更简单:不需要处理重复消息问题
|
||||
- 一致性自然解决:只有一条消息
|
||||
|
||||
### 规范改进建议(适用于所有类似交互)
|
||||
|
||||
| 阶段 | 规范要求 |
|
||||
|------|---------|
|
||||
| **需求阶段** | PRD 必须包含「用户交互反馈」章节,明确定义每个操作的即时界面表现 |
|
||||
| **设计阶段** | UI 设计稿必须包含「状态变化」标注(正常/禁用/加载/错误) |
|
||||
| **技术设计阶段** | 技术方案必须写明「前端消息添加时机」——是本地先添加还是等后端确认 |
|
||||
| **验收阶段** | 用例测试必须覆盖「网络异常/超时」场景,验证界面反馈是否符合预期 |
|
||||
Reference in New Issue
Block a user