wecom_it_smart_desk/docs/01-产品文档/04-坐席工作台/PRD-REQ-坐席-011-统一工作队列重构-v0.1.md

# PRD — 坐席端统一工作队列重构

> **REQ编号**: REQ-坐席-011
> **版本**: v0.1（方案草案 / 沟通确认阶段；C-8 决策见 §6.4）
> **状态**: 🟡 待评审 — 含未决项，不得据此排期开发
> **优先级**: P1（其中 Phase 0 为 P0）
> **日期**: 2026-08-08
> **作者**: 宋献
> **关联**: REQ-坐席-004（任务详情视图切换）、REQ-坐席-009（会话状态Tab筛选）、任务说明书 #132、原型 `原型-REQ-坐席-000-坐席工作台-v1.8.html`（v1.8 演进）

---

## 1. 背景

### 1.1 提案

取消坐席工作台「待办事项」独立面板，将审批单与工单纳入左栏，与咨询会话统一按优先级和分类排列。

### 1.2 提案原始论据与核查结论

| # | 原始论据 | 核查结论 | 依据 |
|---|---|---|---|
| ① | 咨询/审批/工单本质都是待处理的单个事件 | ✅ **成立** | 与 Zendesk / ServiceNow Agent Workspace 的单一工作队列范式一致 |
| ② | 均关联对应员工（左栏） | ❌ **当前不成立** | `TodoItemData`（`src/frontend-agent/src/api/todo.ts:17`）顶层无 employee 字段 |
| ③ | 均需辅助处理功能（右栏） | ⚠️ **当前未实现，且不应简单共用** | `AiAssistantPanel.vue:100` 仅依赖 `conversationId`，不感知 `workspaceView` |

**对 ② 的补充**：前端待办头像为伪造实现 —— `todoAvatarText()`（`TodoPanel.vue:224-233`）从 `title` 按 `" - "` 切分后取**部门名最后一个字**，颜色取 `title` 的 hash。后端 `applicant` 仅有 userid，埋在 `description` JSON 内未暴露到顶层（`src/backend/app/services/todo_source_service.py:485`）。

**对 ③ 的补充**：会话辅助信息（知识推荐 / 话术 / 排查步骤）服务于「对话」；审批辅助信息（申请人历史 / 同类通过率 / 合规校验）服务于「决策」。二者不同源、不同构。统一三栏布局 ≠ 统一右栏内容，右栏必须按工作项类型分派渲染。

### 1.3 立项主理由（重新论证）

原提案表述为「布局更合理、处理更高效」，论证力度不足。本 PRD 采用以下主理由：

> **待办面板置于右栏属于信息架构语义错位。** 右栏的定义是「当前会话的上下文辅助面板」，而待办是**不隶属于任何会话的全局工作队列**。将全局队列置入上下文面板，破坏了右栏的语义一致性，并导致坐席的工作入口分裂为两处。

### 1.4 与 #132 的关系（须在评审中说明）

| 项 | 内容 |
|---|---|
| #132 做了什么 | 2026-08-02～08-03，待办面板由**左栏底部**迁至**右栏底部** |
| #132 的决策依据 | 任务说明书仅记载「与 v1.1 原型保持一致」，验收项含「左栏会话列表不被压缩」。**无信息架构层面论证** |
| 本次是否为返工 | **否**。#132 是面板位移；本次是数据模型与列表融合，属架构升级 |
| 需规避 | 若仅将面板移回左栏（见 §5 方案 B），将原地重演 #132 的左栏空间竞争问题，构成第三次搬迁 |

---

## 2. 已确认决策

以下三项经沟通确认，作为本方案的设计约束。

| # | 决策项 | 结论 | 推导出的约束 |
|---|---|---|---|
| **D-1** | 左栏列表主键模型 | **以「事」为主键** | 每个咨询/审批/工单各占一条；员工信息作为条目属性展示，不作聚合维度 |
| **D-2** | 实施顺序 | **先闭环、后合并** | Phase 0（操作闭环）为 Phase 2（布局合并）的硬前置，顺序不可调换 |
| **D-3** | 待办归属范围 | **本人指派 + 组内未分配** | 引入「认领」动作与并发控制 —— **当前系统完全没有此能力，属新增需求** |

### 2.1 D-3 的成本提示

D-3 不是筛选条件的调整，而是新增一条状态机路径。当前 `todo-items` 接口按 `assigned_agent_id` 过滤，不存在无主池概念。落地需新增：

- 后端：未分配待办的查询口径（组边界定义见 §6 未决项 U-3）
- 后端：`claim`（认领）动作 + 幂等与乐观锁（防并发抢单）
- 前端：认领按钮、认领中态、认领失败（已被他人认领）的提示
- 数据：认领操作的审计留痕

---

## 3. 阻塞项（原 P0，2026-08-09 修订为 P1）

### 3.1 任务详情操作按钮无服务端闭环（原「全部为 Mock」，已部分修复）

> **📝 2026-08-09 修订**：本节原记录 `TaskDetailView.vue:117` 为无条件 `ElMessage.success` 的 Mock 实现。
> 经架构师代码核查（`技术核查-坐席会话条目操作菜单-v1.0.md` §1.1），**该无条件成功提示已被修复**，行号亦已变更。
> 原描述已过期，现更新如下，避免后续评审基于过期事实。

#### 3.1.1 当前实际代码

```ts
// src/frontend-agent/src/components/chat/TaskDetailView.vue:129-135（2026-08-09 时点）
function handleAction(action: string): void {
  if (props.todoItem.type === 'approval') {
    // 企微不支持服务端代审批，跳转由 ApprovalDetail 的 <a target="_blank"> 原生完成
    console.info('[TaskDetailView] 审批动作已跳转企微审批原系统:', action)
    return
  }
  ElMessage.info('该操作需在原系统中完成')
}
```

**修复内容**：无条件 `ElMessage.success` 已移除，改为按 `type` 分支——
- `type === 'approval'` → 静默返回（跳转由 `ApprovalDetail` 的 `<a target="_blank">` 原生完成），不再弹成功提示；
- 其他类型（工单等） → `ElMessage.info('该操作需在原系统中完成')`，中性提示，不谎报成功。

#### 3.1.2 修订后的结论

| 项 | 原结论（v0.1 初稿） | 现结论（2026-08-09 核查后） |
|---|---|---|
| 是否谎报成功 | 是（无条件绿色成功 toast） | ❌ **否，已修复**。审批静默跳转，其他类型为中性 info |
| 是否服务端闭环 | 否 | ❌ **仍否**。审批为降级跳转 + 回调回写（U-1 已定），工单受 U-1.1 / U-1.2 外部阻塞 |
| 风险定级 | 🔴 P0，阻塞布局合并 | 🟡 **降级为 P1**，不再是"错误反馈"型 P0，但**服务端闭环缺失依然阻塞 Phase 2 的工单/审批混排**（Phase 0 的降级跳转 + 回写仍须先落地） |

**剩余阻塞点**（未因本次修复而消解）：
- 审批：`approval.py:902` 的 `sys_approval_change` 回调状态回写尚未补全 → 跳转后前端无法感知外部状态变更（Phase 0 待办项）；
- 工单：`ITSMService.get_todo_list()` 无条件 `return []`（U-1.2），读链路即断，写接口更无从谈起（U-1.1 / T05）。

#### 3.1.3 🔴 与会话侧操作的性质差异（Phase 2 组件抽象的核心依据）

| 维度 | 会话侧 4 操作（接单/置顶/代办/转接） | 任务侧操作（审批/工单） |
|---|---|---|
| 闭环性质 | **服务端真闭环**。`UserInfoBar.vue:116-164` → `ChatArea.vue` handler → `stores/conversation.ts:498-571` → `api/conversation.ts:176-244` → 后端 `conversations.py` 六端点，**全链路实证可用** | **降级跳转**（审批）/ **当前无对象**（工单） |
| 执行路径 | store → API → 后端 → `fetchConversations()` 刷新 | `<a target="_blank">` 跳外部系统 → 回调回写 → WS 推送 |
| 反馈模型 | **同步**成功/失败 | **异步最终一致** |
| 后端权限 | `assign`/`transfer`/`grab` = `update:all`；`resolve`/`pin`/`todo` = `update:own` | 不适用 |

> **这一差异是 Phase 2 组件抽象不可回避的约束**：左栏统一容器上的操作菜单**必须按 `kind` 分派反馈策略**，菜单项定义需携带 `execMode: 'direct' | 'redirect' | 'disabled'` 字段。
> **若三类工作项共用一套「点击 → toast 成功」的反馈模型，就会以另一种形式重演本节原先定性为 P0 的那个错误。**
> 具体设计见 `PRD-REQ-坐席-012-会话条目操作菜单-v1.0.md` §7.2。

**风险定级：🟡 P1（由 P0 降级）。**

降级理由：谎报成功的错误反馈已消除，坐席不再会因绿色提示误判外部系统已变更。
**但仍阻塞 Phase 2**：待办提升至左栏主队列首屏后，若操作仍只是"提示到原系统操作"，等同于把无实际能力的入口放在最高可见度位置——Phase 0 的降级跳转 + 状态回写仍是 Phase 2 的硬前置（§6 D-2 顺序不变）。

---

## 4. 其余工程前置条件

| 编号 | 前置项 | 现状 | 不处理的后果 |
|---|---|---|---|
| **B-1** | 待办缺员工身份字段 | 顶层无 employee_id/name/department；`applicant` 仅 userid 且未暴露 | 混排后同列表内会话条目为真人头像+姓名+部门，待办条目为伪头像+部门残字，身份密度断裂，无法按人扫视 |
| **B-2** | 待办无实时推送 | 会话走 WS（`useWebSocket.ts` 12 类事件）；待办为 60s 轮询（`TodoPanel.vue:143`），后端**无任何 todo WS 事件** | 紧急审批最长滞后 60s 才浮升；同列表内会话实时跳动而待办静止，坐席对排序失去信任 |
| **B-3** | 优先级不可比 | 会话为 `urgency_score` 1–5 叠加 6 档加权（置顶 −10000 / 代办 −5000 / 招手 −2000 / 需介入 −1500 / 情绪 −1000 / VIP −800）；待办仅 `urgent/high/normal` 三档，且**同档内无二级排序**（`todo_aggregator_service.py:134` 无时间兜底） | 混排结果不可解释，坐席无法预期条目位置 |
| **B-4** | SLA 语义冲突 | 会话等待成本为「用户实时干等」（秒级）；审批为「当日处理完毕」（小时级） | 纯优先级排序会使 urgent 审批将 `serving` 状态会话挤出首屏。**漏回一条实时会话的代价显著高于晚 30 分钟处理一单审批**，纯优先级模型会系统性放大该错误 |

**B-4 的设计要求**：统一排序权重**不得**仅取优先级，必须引入「实时性/等待可感知度」维度。建议排序键为 `f(优先级, SLA剩余时间, 对端是否在线等待)`，其中「对端在线等待」应具备最高权重档位。具体系数见 §6 未决项 U-2。

---

## 5. 方案选型

| 方案 | 做法 | 优势 | 劣势 | 采纳 |
|---|---|---|---|---|
| **A** 完全融合 | 单列表跨类型混排 | 真正的单一队列 | 四项前置全欠；实时会话被挤压；排序不可解释 | ❌ 不作为首个形态 |
| **B** 移回左栏保持分区 | 左栏上会话、下待办，可折叠 | 改动最小（≈0.5d），立即消除右栏语义错位 | 仍为两个列表；重演 #132 左栏空间竞争，构成第三次搬迁 | ❌ 不单独实施 |
| **C** 统一容器 + Tab 分层 | 左栏 Tab 增加类型层「会话 / 待办 / 全部」，「全部」下混排 | 兼顾专注模式与全局视图；可灰度、可回退 | Tab 层级加深一层 | ✅ **首个落地形态** |
| **D** WorkItem 统一模型 | 后端抽象 WorkItem，会话/工单/审批为其子类型，共享优先级、SLA、关联人、状态机 | 架构最干净；未来接入设备告警、巡检任务零边际成本 | 后端工作量高一个数量级 | ✅ **目标态** |

**采纳路径：以 D 为目标态，C 为首个落地形态，Phase 0 为硬前置。**

---

## 6. 实施路线

> 工时为粗估，用于排序参考，不作为承诺。

### Phase 0 — 操作闭环（P0，阻塞后续全部阶段）

> **U-1 已验证结论（2026-08-08）**：企微审批**不可服务端闭环**（官方文档证实无代审批接口，PC Web 无 JS-SDK 能力），审批动作必须降级为「跳转企微原系统 + 回调状态回写」；ITSM 工单因操作类 OpenAPI 尚未落地，**暂不可判定服务端闭环**，需先降级跳转，待 T05 外部依赖到位后升级。详见 `docs/02-技术文档/技术架构/技术验证-U-1-审批与工单操作闭环可行性-v1.0.md`。

| 任务 | 说明 | 降级层级 |
|---|---|---|
| 审批操作 → 降级跳转 + 回写 | 通过 / 拒绝 / 转交 → 点击「在企微审批中打开」跳转原系统，由 `approval_webhook.py` 接收 `sys_approval_change` 回调 → 补全 `approval.py:902` 状态回写 → WS 推送 | Level 0 立即可做；Level 1 需补回调回写 |
| 工单操作 → 降级跳转（暂） | 接单 / 开始处理 / 结单 / 转派 → 点击「在 ITSM 中打开」跳转原系统；ITSM 写接口到位前不承诺服务端闭环（受 T05 外部阻塞）。**⚠️ 注意：该跳转依赖工单可见，而当前 ITSM 读列表亦未实现（见 U-1.2），故本行在读链路打通前无实际可操作对象** | Level 0（暂，受 U-1.2 前置） |
| 失败态处理 | ~~移除无条件 `ElMessage.success`~~ ✅ **已完成**（2026-08-09 核查确认，见 §3.1.1）。**剩余部分**：改为「跳转成功提示 + 状态回写后刷新」按三态分派（当前仅做到中性 info，尚无回写后刷新）；仍禁止以 toast 作为验收依据 | — |

**验收标准**：操作后外部系统（ITSM / 企微审批）**状态真实变更**，且前端反馈与外部状态**最终一致**（通过回调 / webhook 回写达成）。禁止以 toast 成功作为验收依据。审批 / 工单在降级跳转模式下，以「跳转成功 + 原系统状态通过回调回写并刷新」作为验收闭环，不要求前端内嵌直接操作。

### Phase 1 — 数据层归一（后端）

| 任务 | 对应前置项 |
|---|---|
| `TodoItem` 顶层暴露 `employee_id` / `employee_name` / `department`（由 applicant userid 反查企微通讯录） | B-1 |
| 新增 `sla_due_at` 字段 | B-4 |
| 定义 WorkItem 统一排序权重模型 | B-3 / B-4 |
| 新增 todo WS 事件：`todo_created` / `todo_updated` / `todo_claimed` / `todo_resolved` | B-2 |
| 未分配待办查询口径 + `claim` 动作（幂等 + 乐观锁） | D-3 |

### Phase 2 — 左栏统一容器（前端，方案 C）

| 任务 |
|---|
| 左栏 Tab 分层：类型层（会话 / 待办 / 全部）+ 状态层（沿用 REQ-009 的四态） |
| 定义统一 `ListItem` 类型（含 `kind` 判别式），条目组件支持会话态与任务态两种渲染 |
| 移除 `AiAssistantPanel.vue` 中的 `<TodoPanel />` 挂载 |
| **右栏按 `workspaceView` 分派渲染**（修复现存缺陷：任务详情下右栏仍显示上一会话的排查建议） |
| 修复 `selectConversation` 不重置 `workspaceView` 的问题 |
| 视图切换时保留输入框草稿与滚动位置（当前 `v-if/v-else` 互斥卸载会丢失，`ReplyBox.vue:307` 的 `inputText` 为组件局部 ref） |

### Phase 3 — 混排与观察

| 任务 |
|---|
| 「全部」Tab 下按归一化权重混排 |
| 灰度发布 + 2 周数据观察（观测指标见下） |
| 依据数据决定是否推进 D（后端 WorkItem 模型） |

**观测指标**：会话首响时长（是否因混排而劣化）、待办平均处理时长、坐席 Tab 切换频次、认领冲突率。

### Phase 0.5 — TaskDetailView 操作区精简（C-8 决策，2026-08-10）

**背景**：原 `TaskDetailView` 操作区固定渲染 4 按钮（接单 / 开始处理 / 结单 / 转派），垂直占 body 区 50%+ 空间，导致「处理进度 / SLA」等关键状态信息需滚动才看完。

**设计变更**：状态机驱动 + 二级收纳

| Task Type | 主操作按钮（按状态） | ⋯ 次要动作 |
|---|---|---|
| 工单 queued | 📥 接单 | 转派 / 挂起 |
| 工单 serving | ✅ 结单 | 转派 / 挂起 |
| 审批 pending | ✅ 审批通过 | 拒绝审批 / 转交审批 / 加签 |
| 设备异常 | ✅ 标记恢复 | 一键开单 / 派工 / 加入巡检计划 |

**收益**：
- 操作区按钮数 4 → 1~2（-50%）
- body 区可用垂直高度 +50%↑
- 状态信息一眼可见，无需滚动

**状态机原则**：开始处理被吸收到状态推进逻辑（点「接单」后接单 + 开始处理隐式完成，不显式拆分）。

**实现细节**：
- 前端：组件 `useConversationMenuItems.ts` 状态机新增 `claim / recover / approve` reducer
- 后端：**不变**（仅前端状态机调整 + ⋯ 菜单 UI）
- 视觉密度补偿：主按钮 padding 从 `8×18` → `8×22`

**影响范围**：
- ✅ 不影响：左栏三点菜单（v1.7 §4.4 矩阵）、中栏顶栏 UserInfoBar（v1.7 D-2 已删 3 留 1）
- ⚠️ 涉及文件：`TaskDetailView.vue:128-135`、`useConversationMenuItems.ts`
- 📐 原型版本：v1.7 → v1.8（已落，决策依据详见原型变更说明段）

---

## 7. 未决项

| 编号 | 未决项 | 影响 | 需谁决策 |
|---|---|---|---|
| **U-1** | 审批操作能否在坐席 PC Web 端完成 | **已验证（2026-08-08）**：企微审批**不可服务端闭环**——官方文档证实无代审批接口，PC Web 亦无 JS-SDK 原生表单能力。结论：审批动作须降级为「跳转企微原系统 + `sys_approval_change` 回调状态回写」。该结论**不阻塞** Phase 0 启动（降级跳转可立即落地）。验证依据见 `技术验证-U-1-审批与工单操作闭环可行性-v1.0.md` | 已闭环（技术） |
| **U-1.1** | ITSM 写接口到位时间 | 工单「接单 / 开始处理 / 结单 / 转派」能否服务端闭环，取决于 ITSM 平台方提供的操作类 OpenAPI 文档、`app_id`/`secret` 写权限、测试账号（对应 T05）。当前项目内 ITSM 仅实现只读查询（`itsm_service.py` 全文件无写操作），无写接口实证。该项是**工单服务端闭环的外部阻塞项**，未到位前工单同样降级跳转 | 平台方 / 外部协调 |
| **U-1.2** 🔴 | **ITSM 工单当前在坐席端完全不可见（读链路即断）** | **代码实证（2026-08-08 主理人复核补录）**：`ITSMService.get_todo_list()`（`src/backend/app/services/itsm_service.py:113-130`）**无条件 `return []`**，仅打印告警「ITSM 代办列表 API 尚未实现」。`TodoAggregatorService`（`todo_aggregator_service.py:110-127`）并发聚合审批与 ITSM 两源，ITSM 分支恒为空 → **待办列表中工单数量恒为 0，现有待办全部是企微审批单**。且因无列表即无 `process_instance_id`，已实现的 `get_todo_detail` / `workitem/detail`（只读）**实际也无从调用**。<br>**影响**：此项**比 U-1.1（写接口缺失）更前置**——写接口的前提是先能读到工单。在读链路打通前，「工单纳入统一队列」在数据层无内容可纳入，Phase 2 的工单部分实为空跑 | 平台方 / 外部协调（与 U-1.1 合并索取） |
| **U-2** | 统一排序权重的具体系数 | 决定混排结果是否可解释、是否会挤压实时会话 | 产品 + 坐席试用反馈 |
| **U-3** | 「组内未分配」的组边界定义 | 全体 IT 支持组？还是按技能/区域路由后的子集？直接影响列表长度 | 产品 |
| **U-4** | 认领并发冲突的交互 | 两名坐席同时认领同一单时的提示与落败方引导 | 产品 |
| **U-5** | 列表长度上限与虚拟滚动 | 合并 + 组内未分配后列表显著变长，260px 宽左栏的承载能力 | 前端 |
| **U-6** | 待办条目的未读/变更标识 | 会话有 `is_todo` 等标志，待办无未读概念，混排后视觉规则需统一 | 产品 |

---

## 8. 风险登记

| 编号 | 风险 | 等级 | 缓解措施 |
|---|---|---|---|
| R-1 | 实时会话被审批挤出首屏，首响时长劣化 | 🔴 高 | 排序模型引入「对端在线等待」最高权重档；Phase 3 灰度观测首响指标 |
| R-2 | 认领并发抢单导致重复处理 | 🟡 中 | 后端乐观锁 + 幂等；前端落败态明确提示 |
| R-3 | 轮询向 WS 迁移期间的双通道数据不一致 | 🟡 中 | 迁移期保留轮询作为兜底，以 WS 事件为主、轮询做对账 |
| R-4 | 第三次布局搬迁引发团队对决策稳定性的质疑 | 🟢 低 | 评审时明确说明本次为架构升级而非位移返工（见 §1.4） |
| R-5 | 工单闭环因 ITSM 写接口缺失受阻，导致 Phase 0 工单部分停滞 | 🟡 中 | U-1 已验证：审批走降级跳转**不阻塞** Phase 0；工单闭环的外部阻塞已独立为 U-1.1 / T05，审批与工单降级跳转可先行落地，不拖累整体路线 |

---

## 9. 明确不在本次范围

- 会话侧数据模型改造（`urgency_score` 与加权标志保持不变）
- H5 员工端任何改动
- 设备异常类型（REQ-004 §2.3 曾定义，现已从 `TodoPanel` 移除，本次不恢复）
- 坐席在线统计数据源（当前取自 `src/mock/data.ts`，属独立技术债）

---

## 10. 变更记录

| 日期 | 版本 | 变更内容 | 变更人 |
|---|---|---|---|
| 2026-08-08 | v0.1 | 创建方案草案；固化 D-1/D-2/D-3 三项决策；完成原始论据核查与现状事实核实 | 宋献 |
| 2026-08-08 | v0.1 | 据 U-1 技术验证结论（架构师高见远）修订 §6 Phase 0 与 §7 U-1：审批明确为降级跳转 + 回写（U-1 已验证）；新增 U-1.1 ITSM 写接口外部阻塞项；同步下调 R-5 风险表述 | 宋献 |
| 2026-08-08 | v0.1 | 主理人复核补录 **U-1.2**：代码实证 `ITSMService.get_todo_list()` 无条件返回空列表，ITSM 工单在坐席端读链路即断、当前待办全为企微审批单。该项前置于 U-1.1，一并标注于 §6 Phase 0 工单行 | 齐活林（交付总监） |
| 2026-08-09 | v0.1 | **修正 §3.1（原描述已过期）**：`TaskDetailView.vue` 的无条件 `ElMessage.success` 已被修复，行号由 `:117` 更新为 `:129-135`，现为按 `type` 分支（approval 静默跳企微 / 其他 `ElMessage.info('该操作需在原系统中完成')`）。风险由 🔴 P0 降级为 🟡 P1（谎报成功已消除，服务端闭环缺失仍阻塞 Phase 2）。新增 §3.1.3 明确「**会话侧 4 操作是真闭环，任务侧审批/工单是降级跳转，二者性质根本不同**」，并将其确立为 Phase 2 按 `kind` 分派反馈策略（`execMode` 字段）的核心依据，指向 PRD-REQ-坐席-012 §7.2。依据：`技术核查-坐席会话条目操作菜单-v1.0.md` §1.1 | 许清楚（产品经理） |
| 2026-08-09 | v0.1 | **Phase 0 审批线落地**：T01（前端降级跳转）+ T02（后端 `/approval/callback` + `approval_webhook` 回调回写）已实现并通过 QA 独立回归（51 例全绿，前端 type-check 改动文件干净，无源码缺陷）。代码已 commit `9292f41` 于分支 `feat/agent-approval-degrade-jump`，并已推送 Gitea（远端 SHA 与本地一致，`main` 未被改写）。PR 入口：<http://192.168.3.200:8418/simon/wecom_it_smart_desk/pulls/new/feat/agent-approval-degrade-jump>。**工单线（T03+）仍未启动**，受 U-1.2（ITSM 读链路断裂）+ U-1.1（写接口缺失）外部阻塞 | 寇豆码（工程师）→ 严过关（QA）→ 齐活林（主理人编排） |
| 2026-08-10 | v0.1 | **C-8 决策**：TaskDetailView 操作区由原版固定 4 按钮（接单/开始处理/结单/转派）重构为「状态驱动主操作按钮 + ⋯ 次要动作收纳」。依据：操作区占 body 区底部 50%+ 垂直空间，导致「处理进度 / SLA」等状态信息需滚动才看完。详见新增 §6.4。原型 v1.7 → v1.8，代码待 `useConversationMenuItems.ts` 状态机 reducer 改造。**不影响**：左栏三点菜单（v1.7 §4.4 矩阵）、中栏顶栏 UserInfoBar、后端 API | 宋献 |
| 2026-08-10 | v0.1 | **PR #5 已合并**：commit `af87f1de` redis_client 修复（approval.py + byod.py）经 Gitea UI 合并为双亲 merge `d8e7dbe`，main 现位于 `5db3079d`。本地 main 已同步。审批回调 `POST /approval/callback` 生产实测 HTTP 200 `{errcode:0}` | 齐活林 → 宋献（合并）|