TurboHR/20260815-优化.md

# 20260815 优化清单

> 来源：`20260815-优化.csv`（共 31 条）
> 结合 TurboHR 当期功能梳理，按模块归类，标注根因 / 修复方向 / 优先级 / 涉及文件。
> 优先级：P0 紧急（影响业务正确性/数据丢失）｜P1 高（流程阻塞或合规风险）｜P2 中（体验/增强）｜P3 规划（新模块）

---

## 一、离职管理（问题 2-11）

### 问题 2：离职日期调整后未联动社保/公积金截止年月
- **现状**：`Termination.tsx:1334-1338` 社保截止、公积金截止为 `<Input type="month">` 手动填写，默认值取 `terminationDate.slice(0,7)`，但修改离职日期后不会重算，也无"15 日前/后"规则。
- **修复方向**：
  1. 增加"离职日期 → 社保/公积金截止月"自动推导规则：每月 15 日（含）前离职不缴当月、15 日后离职缴纳当月，截止月 = 离职月 - 0 或 -1。
  2. 阈值日期（15 日）做成系统设置可配置项（`org_settings.socialInsCutoffDay`，默认 15）。
  3. 离职日期变更时自动回填两个截止月，同时保留手动覆盖入口。
- **优先级**：P1 高
- **涉及文件**：`frontend/src/pages/Termination.tsx`、`backend/src/services/termination.service.ts`、`backend/prisma/schema.prisma`（org_settings 增字段）

### 问题 3：合规检查"是否已支付经济补偿金"硬阻断
- **现状**：合规检查为必勾才能进入下一步，未勾选时无法继续，且未保存的检查项不进入待办/风险提醒。
- **修复方向**：
  1. 将"必勾才能下一步"改为"未勾选可下一步，但自动写入待办事项 + 风险提醒"。
  2. 待办项关联 `termination_draft`，在 Dashboard/风险中心展示"XX 员工解聘未支付经济补偿金"。
  3. 提交审批时若仍存在未闭环必检项，给出强提示但不阻断（除非法定禁止情形，如孕期/工伤）。
- **优先级**：P1 高
- **涉及文件**：`Termination.tsx`（step 2 校验逻辑）、`backend/src/services/notification.service.ts`、`frontend/src/pages/Dashboard.tsx`

### 问题 4：费用结算新增"剩余年假天数"
- **现状**：费用结算步骤仅展示补偿金/代通知金/赔偿金，未涉及年假折算。
- **修复方向**：
  1. 费用结算区新增"剩余年假天数"字段，支持手动录入或调用考勤模块年假余额（若有）。
  2. 按规则计算未休年假折算工资：`日工资 × 剩余年假天数 × 300%`（未休部分）。
  3. 折算金额计入"合计应付"。
- **优先级**：P2 中
- **涉及文件**：`Termination.tsx`（step 3）、`backend/src/services/termination.service.ts`（cost 计算扩展）

### 问题 5：补偿月数支持 N / N+1 / 2N / 其他
- **现状**：`Termination.tsx:1442` 补偿月数取 `costResult.cappedMonths`（系统按工龄自动算 N），不允许选择其他模式。
- **修复方向**：
  1. 补偿月数改为下拉：N、N+1、2N、其他（自定义输入）。
  2. 选择"协商解除"时允许修改月数并实时重算补偿金。
  3. 选择"其他"时需填写说明，留痕到 `compensationBreakdown.adjustments`。
- **优先级**：P1 高
- **涉及文件**：`Termination.tsx`（step 3 补偿金区）、`backend/src/services/termination.service.ts`

### 问题 6：计算基数支持多种来源
- **现状**：`Termination.tsx:1443` 计算基数固定取 `costResult.cappedWage`（近 12 月平均工资，且有三倍社平工资封顶）。
- **修复方向**：
  1. 计算基数改为下拉：近 12 月平均工资（默认）、合同工资、其他（手动填写）。
  2. 切换来源后实时重算补偿金，并记录选用算法到草稿。
  3. "其他"需填写说明，受三倍社平封顶提示但不强制。
- **优先级**：P1 高
- **涉及文件**：`Termination.tsx`、`termination.service.ts`

### 问题 7：手动调整补偿金分项后合计未同步
- **现状**：`Termination.tsx:530` 注释提到"系统预估 + 手动调整差额"，但 `handleSave`（578 行附近）仍使用 `costResult.grandTotal`，未叠加 `compAdjustments`。20260803 问题 13 已识别但未闭环。
- **修复方向**：
  1. 实际合计 = `costResult.grandTotal + Σ(adjustments.to - adjustments.from)`，保存与确认页统一使用此值。
  2. 调整任一分项后实时刷新"合计应付"显示。
  3. 后端 `compensationBreakdown.adjustments` 已支持，前端需正确传递并回显。
- **优先级**：P0 紧急
- **涉及文件**：`Termination.tsx`（`handleSave`、确认步骤、step 3 合计显示）

### 问题 8：工作交接未完成无法下一步
- **现状**：`Termination.tsx:552-554` step 4 校验 `work_handover/equipment_return/access_revoke` 三项必须完成才能下一步。
- **修复方向**：
  1. 改为可下一步，未完成事项自动写入待办（关联离职草稿）。
  2. 交接清单前三项标注"离职必办"，未完成时在确认页和风险中心强提示。
  3. 待办在到达离职日期前持续提醒，超期升级为风险。
- **优先级**：P1 高
- **涉及文件**：`Termination.tsx`（step 4 校验）、`notification.service.ts`、`Dashboard.tsx`

### 问题 9：离职管理"新建解聘"并入花名册操作栏
- **现状**：花名册操作栏已有"离职"按钮（`Roster.tsx:734-746`，触发 `ResignModal` 创建 RESIGNATION 草稿），但"新建解聘"仍在离职管理列表页独立入口，且仅支持 RESIGNATION 类型。
- **修复方向**：
  1. 花名册操作栏"离职"按钮扩展为支持所有解聘类型（协商/过错/非过错/裁员/到期/违法），弹出类型选择后跳转 Termination 向导并预填员工。
  2. 离职管理列表页移除"新建解聘"按钮，仅保留草稿列表与审批。
- **优先级**：P1 高
- **涉及文件**：`Roster.tsx`、`roster/modals.tsx`（`ResignModal`）、`Termination.tsx`（支持 URL 参数预填）

### 问题 10：解聘驳回后修改内容未更新
- **现状**：驳回后重新修改解聘类型、金额等，系统未按新内容更新（疑似使用旧草稿快照或前端未刷新）。
- **修复方向**：
  1. 排查 `updateDraft` 是否正确覆盖 `reason/compensationBreakdown/terminationDate`。
  2. 驳回后再编辑走 `updateDraft`（而非新建），版本号 +1，旧版本留快照。
  3. 前端进入驳回草稿时强制重新拉取最新数据。
- **优先级**：P0 紧急
- **涉及文件**：`Termination.tsx`（编辑驳回草稿逻辑）、`backend/src/services/termination.service.ts`、`backend/src/routes/termination.routes.ts`

### 问题 11：违法解除降低补偿金后无合规风险提醒
- **现状**：选择 ILLEGAL（2N）后手动降低补偿金金额，`acknowledgeRisk` 仅在初始选择违法解除时提示，金额变动后不再校验。
- **修复方向**：
  1. 实际补偿金 < 法定 2N 时，强制弹出合规风险提醒，需勾选"已知风险并继续"才能下一步。
  2. 风险提醒记录到 `compensationBreakdown.riskAcknowledged`，留痕可审计。
  3. 同步推送风险中心。
- **优先级**：P0 紧急
- **涉及文件**：`Termination.tsx`（step 3 风险校验）、`risk-center`

---

## 二、用工办理 / 合同（问题 12-13、18、20-23、26）

### 问题 12：合同续签新增合同开始日期应为上一份结束日期 +1
- **现状**：`WorkProcess.tsx:93-99` RENEW 表单 `newStartDate` 为手动填写，无自动推导。
- **修复方向**：
  1. 选择员工后自动拉取最新已签合同，`newStartDate` 默认 = 上一份合同 `endDate + 1 天`。
  2. 允许手动覆盖，但偏离时提示。
- **优先级**：P1 高
- **涉及文件**：`WorkProcess.tsx`（RENEW 字段）、`backend/src/services/work-process.service.ts`

### 问题 13：合同结束日期早于开始日期未校验
- **现状**：`WorkProcess.tsx` 表单提交前无日期前后关系校验，已产生时间倒置数据。
- **修复方向**：
  1. 前端表单提交前校验 `endDate >= startDate`，否则阻断并提示。
  2. 后端 `work-process.service.ts` 增加同样校验，双保险。
  3. 历史倒置数据提供修复脚本/列表提示。
- **优先级**：P0 紧急
- **涉及文件**：`WorkProcess.tsx`、`work-process.service.ts`

### 问题 18：员工转正移植到花名册操作栏，替换发薪
- **现状**：花名册操作栏（`Roster.tsx:694-747`）有调薪/发薪/调部门/离职，无转正入口；转正仍在用工办理 CONFIRM 流程。
- **修复方向**：
  1. 操作栏"发薪"按钮（`Wallet`，711-720 行）替换为"转正"按钮（`CheckCircle`），点击弹出转正 Modal（转正日期 + 转正薪资）。
  2. 仅试用期员工（`probationInfo.isProbation`）显示转正按钮。
  3. 发薪入口保留在薪税管理模块。
- **优先级**：P1 高
- **涉及文件**：`Roster.tsx`、`roster/modals.tsx`（新增 `ConfirmModal`）

### 问题 19：转正薪资未回写花名册，未与用工协议匹配校验
- **现状**：CONFIRM 流程填写 `regularSalary` 后未同步到员工 `monthlySalary`，也未校验与已签合同薪资是否一致。
- **修复方向**：
  1. 转正完成后同步更新员工 `monthlySalary`，并在花名册明细展示"试用期薪资 → 转正薪资"变更记录。
  2. 校验转正薪资与最新合同 `monthlySalary` 是否一致，不一致时提示并支持发起合同变更流程（CHANGE）。
- **优先级**：P1 高
- **涉及文件**：`work-process.service.ts`（CONFIRM 完成回调）、`Roster.tsx`、`roster/SalaryInfo.tsx`

### 问题 20：开具证明移植到花名册操作栏
- **现状**：操作栏无开具证明入口，需进用工办理 INCOME_CERT/LEAVING_CERT 流程。
- **修复方向**：操作栏新增"证明"按钮（`FileText`），点击弹出证明类型选择（收入证明/离职证明/在职证明），复用 WorkProcess 的 INCOME_CERT/LEAVING_CERT 表单。
- **优先级**：P2 中
- **涉及文件**：`Roster.tsx`、`roster/modals.tsx`

### 问题 21：合同续签移植到花名册操作栏
- **现状**：操作栏无续签入口，批量续签在列表顶部（`Roster.tsx:444`），单人续签需进用工办理。
- **修复方向**：操作栏新增"续签"按钮（`Repeat`），仅合同即将到期（≤30 天）或已到期员工显示，点击跳转 WorkProcess RENEW 并预填员工。
- **优先级**：P2 中
- **涉及文件**：`Roster.tsx`、`WorkProcess.tsx`（支持 URL 参数预填）

### 问题 22：合同变更选择员工无法查询到对应合同
- **现状**：`WorkProcess.tsx:88-92` CHANGE 表单 `contractId` 为 `contract-select` 类型，但选择员工后未按员工过滤合同列表，导致查不到。
- **修复方向**：
  1. `contract-select` 组件接收 `employeeId` 参数，仅返回该员工的有效合同。
  2. 后端合同查询接口支持 `employeeId` 过滤。
- **优先级**：P1 高
- **涉及文件**：`WorkProcess.tsx`（contract-select 组件）、`backend/src/routes/contract.routes.ts`

### 问题 23：合同续签原合同 ID 无法查询，改为选择已存在合同
- **现状**：`WorkProcess.tsx:95` RENEW 表单 `oldContractId` 为 `text` 类型，需手动输入 UUID，无法查询。
- **修复方向**：将 `oldContractId` 改为 `contract-select`（同问题 22），选择员工后下拉展示该员工已存在合同。
- **优先级**：P1 高
- **涉及文件**：`WorkProcess.tsx`（RENEW 字段类型）

### 问题 26：去掉用工办理模块
- **现状**：侧边栏"团队"分组有"用工办理"入口（`SidebarNav.tsx:47`），承载 HIRE/ONBOARD/CONFIRM/CHANGE/RENEW/SUSPEND/INCOME_CERT/LEAVING_CERT/FLEXIBLE 等流程。
- **修复方向**：
  1. 将各流程入口下沉到花名册操作栏（转正/续签/变更/开具证明/入职）和独立页面（合同管理/电子签署）。
  2. 侧边栏移除"用工办理"菜单项，保留 WorkProcess 页面作为批量流程入口（或迁移到"更多"分组）。
  3. 需先完成问题 18/20/21/22/23 的入口下沉，再移除菜单。
- **优先级**：P2 中（依赖前置问题完成）
- **涉及文件**：`SidebarNav.tsx`、`Roster.tsx`、`WorkProcess.tsx`、`App.tsx`（路由）

---

## 三、花名册（问题 14-17、24-25）

### 问题 14：身份证号全域改为"证件号码"
- **现状**：`roster/modals.tsx:687`、`WorkProcess.tsx:60/109/132/140` 等多处 label 为"身份证号"。
- **修复方向**：全域搜索替换 label "身份证号" → "证件号码"，字段名 `idCardNumber` 保持不变（兼容历史数据），同时支持证件类型下拉（身份证/护照/港澳台通行证）。
- **优先级**：P2 中
- **涉及文件**：`roster/modals.tsx`、`WorkProcess.tsx`、`Roster.tsx`（搜索 placeholder）、`SpecialStatus.tsx` 等

### 问题 15：添加员工根据证件号码进行年龄合规筛查
- **现状**：`roster/modals.tsx:557` 已根据身份证号自动计算性别，未做年龄校验。
- **修复方向**：
  1. 解析证件号码出生日期，计算年龄。
  2. 年龄 < 16 岁禁止录入（童工红线），强提示并阻断。
  3. 年龄 ≥ 60（男）/55（女干部）/50（女工人）提示已达法定退休年龄，确认后允许录入但标记"退休返聘"。
- **优先级**：P1 高
- **涉及文件**：`roster/modals.tsx`（`handleIdCardChange`）

### 问题 16：编辑入职日期后状态未变更
- **现状**：花名册明细编辑入职日期后，员工状态未联动（如改为下月 1 日入职，状态应从"在职"变为"待入职"）。
- **修复方向**：
  1. 编辑入职日期时，若新入职日期 > 今天，状态自动设为 `PENDING_ONBOARD`（待入职）；若 ≤ 今天，设为 `ACTIVE`。
  2. 状态变更需二次确认，避免误操作。
  3. 变更记录留痕到员工档案。
- **优先级**：P1 高
- **涉及文件**：`roster/BasicInfo.tsx`、`backend/src/services/employee.service.ts`

### 问题 17：录入手机号查重
- **现状**：`roster/modals.tsx:702` 手机号为选填，无查重；身份证号已有查重（691 行）。
- **修复方向**：
  1. 手机号录入时调用查重接口，已存在则提示"该手机号已用于 XX 人员"。
  2. 允许继续保存（一人多号/家庭号场景），但强提示确认。
- **优先级**：P2 中
- **涉及文件**：`roster/modals.tsx`、`backend/src/routes/employee.routes.ts`（新增手机号查重接口）

### 问题 24：花名册多选增加批量转正
- **现状**：`Roster.tsx:444-447` 批量操作仅有"批量续签""批量解聘"，无批量转正。
- **修复方向**：
  1. 多选后新增"批量转正"按钮，仅对试用期员工生效。
  2. 弹窗统一填写转正日期（默认今天）和转正薪资（可按原薪资倍数/手动逐人填写）。
  3. 调用后端批量转正接口，复用问题 18 的转正逻辑。
- **优先级**：P2 中
- **涉及文件**：`Roster.tsx`、`roster/modals.tsx`、`backend/src/services/employee.service.ts`

### 问题 25：花名册多选增加批量开具证明
- **现状**：无批量开具证明入口。
- **修复方向**：
  1. 多选后新增"批量开具证明"按钮，选择证明类型（在职/收入）后批量生成。
  2. 支持批量下载（ZIP）或逐个下载。
- **优先级**：P2 中
- **涉及文件**：`Roster.tsx`、`backend/src/services/work-process.service.ts`（批量生成接口）

---

## 四、薪税管理（问题 28）

### 问题 28：补偿金批次经济补偿金发放数据读取错误
- **现状**：`money/BatchTab.tsx:110` 批次类型支持 `SEVERANCE`（补偿金），但创建补偿金批次时经济补偿金发放数据读取逻辑有误（疑似读取了工资数据或未关联离职草稿的 `compensationBreakdown`）。
- **修复方向**：
  1. 排查 `createBatch` 当 `type=SEVERANCE` 时的数据源，应从已审批通过的 `termination_draft` 读取 `compensationBreakdown.grandTotal`。
  2. 校验员工范围：仅包含有未发放补偿金的离职员工。
  3. 增加预览页展示每位员工的补偿金明细，确认后再创建批次。
- **优先级**：P0 紧急
- **涉及文件**：`money/BatchTab.tsx`、`backend/src/services/payroll.service.ts`（SEVERANCE 分支）

---

## 五、特殊员工（问题 29）

### 问题 29：男职工应无法选择三期
- **现状**：`SpecialStatus.tsx:123` 默认 `type: 'PREGNANCY'`，新增/编辑表单未根据员工性别过滤类型，男职工也可选"三期"。
- **修复方向**：
  1. 选择员工后，若 `gender === '男'`，类型下拉移除"三期"选项或置灰并提示"三期仅适用于女性员工"。
  2. 后端保存时增加校验，男职工 + PREGNANCY 组合拒绝并返回 400。
- **优先级**：P1 高
- **涉及文件**：`SpecialStatus.tsx`（表单 type 下拉）、`backend/src/services/special-status.service.ts`

---

## 六、系统设置 / 组织架构（问题 27）

### 问题 27：增加简单组织架构，支持三步以内审批流转
- **现状**：系统无组织架构模块，`LeaveApproval.tsx:90` 仅有简单审批，无层级流转；`settingsApi.org()` 仅返回企业基本信息。当前员工仅有 `department`（字符串）和 `position`（字符串，前端 label "职务/岗位"）两个字段，无上下级关系。
- **职位/岗位设计决策**：
  - **现状**：数据库只有一个 `position` 字段（`schema.prisma:225`，注释"岗位"），前端 label 统一为"职务/岗位"（`roster/modals.tsx:686`、`roster/BasicInfo.tsx:153/328`），已合并为一个字段。
  - **建议方案 A（推荐，保留一个字段）**：维持 `position` 单字段，label 保持"职务/岗位"。组织架构中"岗位"作为独立实体管理（岗位字典，含岗位名称、职级、编制人数），员工 `position` 关联到岗位字典。优点：改动小，兼容历史数据，符合当前使用习惯。
  - **方案 B（拆分两个字段）**：新增 `jobTitle`（职位，如"经理/主管/专员"）+ `position`（岗位，如"前端工程师"）。优点：职级体系更清晰；缺点：需改 schema + 全域表单 + 历史 position 数据需清洗归类，工作量大。
  - **结论**：建议采用方案 A，组织架构模块中"岗位"独立建表（`Position` 字典），员工 `position` 字段值关联岗位字典 ID 或保持文本（兼容旧数据），审批流按"直属上级 → 部门负责人"两级流转，无需引入职级。
- **修复方向**：
  1. 系统设置新增"组织架构"子页：树形部门（`Department` 自引用 parent）+ 岗位字典（`Position`，含名称/所属部门/编制）+ 上下级关系（`Employee.supervisorId`）。
  2. 新建简单审批流配置：最多 3 步（发起人 → 直属上级 → 部门负责人），支持按流程类型（休假/离职/调薪）配置是否启用某步。
  3. 现有 `LeaveApproval` 接入审批流引擎，离职/调薪等流程可选启用。
  4. 数据模型：`Department`（树形，parent 自引用）、`Position`（岗位字典）、`Employee.supervisorId`、`ApprovalFlow`（type + steps）。
- **优先级**：P3 规划（新模块，建议单独排期）
- **涉及文件**：`Settings.tsx`、新增 `pages/OrgChart.tsx`、`backend/prisma/schema.prisma`、`backend/src/services/approval.service.ts`

---

## 七、全域问题（问题 1、30、31）

### 问题 1："劳动合同"调整为更宽泛的"用工关系"
- **现状**：系统多处文案使用"劳动合同"（合同管理、离职管理、WorkProcess 等）。
- **修复方向**：
  1. 全域文案审计：将面向用户的"劳动合同"在合适场景改为"用工关系"或"用工协议"（涵盖劳动合同/劳务协议/实习协议/灵活用工协议）。
  2. 数据层 `Contract` 模型保持不变，新增 `contractCategory` 字段区分劳动关系类型。
  3. 注意法律文书模板中的"劳动合同"为法定术语，不可改。
- **优先级**：P2 中
- **涉及文件**：`SidebarNav.tsx`、`Contracts.tsx`、`WorkProcess.tsx`、`Termination.tsx` 等文案

### 问题 30：全域保存草稿后部分录入数据未保存（BUG）
- **现状**：多个流程页面支持"保存草稿"，但部分字段（如 `compAdjustments`、`handoverItems` 备注、`checklistOverrides`）未持久化。
- **修复方向**：
  1. 排查各流程 `saveDraft` 的 payload，确保覆盖所有前端 state。
  2. 后端 `draft` 表 schema 检查是否有字段缺失（`compensationBreakdown.adjustments`、`handoverItems.remark` 等）。
  3. 增加"草稿完整性校验"：保存后立即回读对比，缺失字段告警。
  4. 重点排查：Termination（补偿金调整/交接备注）、WorkProcess（自定义字段）。
- **优先级**：P0 紧急
- **涉及文件**：`Termination.tsx`（`handleSaveDraft`）、`WorkProcess.tsx`、`backend/src/services/termination.service.ts`、`backend/src/services/work-process.service.ts`

### 问题 31：单立户客服端

#### 已实现部分（平台管理端，代码完整可运行）

系统已有完整的"平台管理端"（Platform），前后端代码均已实现：

**前端（4 页面 + 1 侧边栏）**：
- `frontend/src/pages/platform/PlatformLogin.tsx` — 独立登录页
- `frontend/src/pages/platform/PlatformDashboard.tsx` — 数据总览（企业数/用户数/员工数/合同数/工资条数 + 套餐分布 + 最近注册企业）
- `frontend/src/pages/platform/PlatformOrgs.tsx` — 企业租户管理（创建/搜索/编辑套餐/删除/管理员账号管理）
- `frontend/src/pages/platform/PlatformUsers.tsx` — 用户管理（启用/禁用）
- `frontend/src/components/layout/PlatformSidebar.tsx` — 独立侧边栏（带 ADMIN 徽章）
- `frontend/src/lib/api-services.ts:938-965` — `platformApi` 完整定义
- `frontend/src/App.tsx:217-220` — 四条路由注册 + `PlatformRoute` 角色校验（`SUPER_ADMIN`）

**后端（1 路由文件 437 行 + 1 schema）**：
- `backend/src/routes/platform.routes.ts` — 完整实现 11 个接口：
  - `GET /platform/dashboard` — 平台总览数据
  - `GET /platform/orgs` — 企业列表（分页+搜索+套餐筛选）
  - `POST /platform/orgs` — 创建企业（含管理员账号自动创建）
  - `GET /platform/orgs/:id` — 企业详情（含用户列表）
  - `PUT /platform/orgs/:id` — 编辑企业（套餐/上限/联系人）
  - `PUT /platform/orgs/:id/admin` — 编辑企业管理员（姓名/手机号/重置密码）
  - `DELETE /platform/orgs/:id` — 删除企业（级联）
  - `GET /platform/users` — 全平台用户列表
  - `PUT /platform/users/:id/toggle` — 启用/禁用用户
  - `GET /platform/admins` — 平台管理员列表
  - `POST /platform/admins` — 创建平台管理员
- `backend/src/schemas/platform.schema.ts` — 入参校验
- `backend/src/middleware/auth.ts` — `platformAdminMiddleware` 权限校验

**数据模型**：
- `Organization` 模型支持多租户（`plan`/`maxEmployees`/`city`/`contactName`/`contactPhone`）
- `User.role` 含 `SUPER_ADMIN` 角色，`orgId` 为 null（平台管理员不归属任何租户）
- `backend/prisma/seed-multi-org.ts` — 多租户种子数据

**结论**：单立户服务（开户+租户管理+用户管理+数据总览）**已完整实现**，CSV 标注为"调整"类型也印证了该功能已存在。

#### 可增强部分（客服工作台，尚未实现）

当前平台管理端是"运营管理后台"，定位为超级管理员/运营使用。如需扩展为客服人员日常服务客户的工作台，以下功能尚未实现：

| 增强项 | 现状 | 说明 |
|--------|------|------|
| 工单管理 | 缺失 | 无 `Ticket` 模型、无工单页面，客服无法接收/分派/跟进客户问题 |
| 客户会话 | 缺失 | 无会话模块，客服无法与客户企业管理员实时沟通或留言 |
| 租户数据穿透 | 缺失 | `SUPER_ADMIN` 仅能看租户列表和统计，无法穿透查看指定租户的花名册/合同/薪税/风险等业务数据 |
| 协助操作 | 部分已有 | 管理员重置密码已有，代客户发起流程/调整套餐等未实现 |
| AI 辅助 | 缺失 | 当前 AI 仅在企业端，客服侧无 AI 问答辅助 |
| 操作日志 | 缺失 | 当前 `AuditLog` 仅在企业端，客服操作无留痕 |

**增强修复方向（如需）**：
1. 新增角色 `SUPPORT`（客服），独立路由 `/support/*`，独立登录页 `/support/login`。
2. 客服端侧边栏含：工单中心、客户会话、租户数据查看、协助操作、AI 辅助、操作日志。
3. 数据模型新增：`Ticket`（工单：标题/内容/状态/优先级/归属租户/处理人）、`TicketMessage`（工单回复）、`ChatSession`（客户会话）。
4. 租户数据穿透：客服选择租户后，以"只读+代操作"模式访问该租户的业务数据（复用现有 API，请求头带 `X-Support-Tenant-Id`，后端中间件切换租户上下文）。
5. AI 辅助复用现有 AI 接口，独立会话隔离。
6. MVP 建议：先做工单 + 租户数据查看 + AI 辅助三项。

- **优先级**：核心功能已完成；增强部分 P3 规划（新模块，建议单独排期）
- **涉及文件（增强部分）**：新增 `frontend/src/pages/support/*`、`frontend/src/components/layout/SupportSidebar.tsx`、`backend/prisma/schema.prisma`（Ticket/ChatSession 模型）、`backend/src/routes/support.routes.ts`、`backend/src/middleware/support-tenant.ts`

---

## 优先级汇总

| 优先级 | 问题 | 说明 |
|--------|------|------|
| **P0 紧急** | 7、10、11、13、28、30 | 数据丢失/业务正确性/合规风险 |
| **P1 高** | 2、3、5、6、8、9、12、15、16、18、19、22、23、29 | 流程阻塞或合规校验缺失 |
| **P2 中** | 1、4、14、17、20、21、24、25、26 | 体验优化/功能增强 |
| **P3 规划** | 27、31增强 | 新模块（组织架构+审批流 / 客服工作台增强），需单独排期 |
| **已完成** | 31核心 | 单立户服务（平台管理端）已完整实现，前后端代码可运行 |

---

## 建议执行顺序

1. **第一批（P0，立即）**：问题 30（草稿丢失）→ 问题 7（补偿金合计）→ 问题 10（驳回未更新）→ 问题 11（违法解除风险）→ 问题 13（合同日期校验）→ 问题 28（补偿金批次数据）
2. **第二批（P1，本迭代）**：离职管理联动（2/3/5/6/8/9）→ 花名册校验（15/16）→ 用工办理入口下沉（18/19/22/23）→ 特殊员工性别校验（29）
3. **第三批（P2，排期）**：花名册批量操作（24/25）→ 文案统一（1/14）→ 入口下沉收尾（20/21/26）→ 年假折算（4）→ 手机号查重（17）
4. **第四批（P3，规划）**：组织架构与审批流（27）→ 客服工作台增强（31增强，MVP = 工单 + 租户数据查看 + AI 辅助）
   - 问题 31 核心功能（单立户服务/平台管理端）已完整实现，无需开发

---

## 备注

- 本清单基于当期代码梳理，部分"根因"为基于代码静态分析的推断，实际修复前需运行复现确认。
- 涉及数据库 schema 变更的（问题 2/27/31），需走 migration + 回滚方案，符合数据 8 铁律。
- 涉及文案全域替换的（问题 1/14），需同步更新 HelpModal、OnboardingGuide 等帮助文案。
- 问题 26（去掉用工办理模块）依赖问题 18/20/21/22/23 完成，不可先行移除。