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 完成，不可先行移除。