feat(xg): 请假审批修复、点名今日汇总与寝室扣分条例脚本

同步请假/销假审批上下文与状态、宿舍点名今日汇总与假期留宿标识，并补充寝室检查扣分条例生产 SQL 与执行说明。

Co-authored-by: Cursor <cursoragent@cursor.com>

docs/开发文档/API/宿舍点名假期留宿标识说明.md

@@ -0,0 +1,57 @@
+# 宿舍点名 · 假期留宿标识说明
+
+## 背景
+
+宿舍点名原先仅对「当前有效请假」自动标识为请假（状态 `1`，不可修改）。  
+已通过审批且仍在留宿日期内的学生，点名界面会误显示为「在寝」。现已补充「假期留宿」标识与独立统计。
+
+## 有效留宿判定（后端统一）
+
+接口：`getRoomStudents` 在返回学生信息时附加 `holidayStayInfo`（有有效请假时不返回，请假优先）。
+
+条件：
+
+1. `apply_status = '2'`（已通过）
+2. 检查日落在 `[apply_start_date, apply_end_date]`（按日期比较，**结束日当天整天有效**）
+3. 同一学生多条记录时取最新一条
+
+假期结束后，接口不再返回 `holidayStayInfo`，前端恢复默认「在寝」可切换。
+
+## 点名状态字典 `xg_dorm_roll_call_status`
+
+| 值 | 含义 |
+|----|------|
+| 0 | 在寝 |
+| 1 | 请假 |
+| 2 | 不在 |
+| 3 | 空床位 |
+| 4 | 假期留宿 |
+
+## 统计字段
+
+主表 `xg_dorm_roll_call.holiday_stay_count`：本房间假期留宿人数。  
+明细可存 `holiday_stay_id` / `holiday_type` / `holiday_start_date` / `holiday_end_date`。
+
+## 交互
+
+与请假一致：自动标为假期留宿后**不可修改**。
+
+## 库表脚本
+
+`backend/script/sql/update/update_20261020_dorm_roll_call_holiday_stay.sql`
+
+部署时需先执行该脚本，再发布后端与前端。
+
+## 当天点名汇总（移动端首页）
+
+接口：`GET /dormRollCall/dormRollCall/todaySummary`  
+权限：`dormRollCall:dormRollCall:list1`
+
+口径：
+
+- **已点名寝室**：当前账号当天有效点名记录的去重房间数（同房多次取最新）
+- **未点名寝室**：管辖楼栋（宿舍管理员权限）∪ 当天已点过的楼栋 下可用房间 − 已点名
+- **请假 / 假期留宿 / 异常**：最新点名明细中状态 `1` / `4` / `2`，可点开看明细
+
+仅供移动端首页展示，不影响点名提交与 Web 列表。
+

docs/开发文档/寝室检查扣分条例生产执行说明-20261020.md

@@ -0,0 +1,137 @@
+# 寝室检查扣分条例生产执行说明（2026-10-20）
+
+## 目标
+
+按宿管《扣分条例10月15日》，把寝室卫生检查可选扣分项切换为新条例（共 **60** 项）。
+
+系统加载规则：寝室检查调用 `listByAreaType?areaType=1`，只显示  
+`xskh_discipline_type` 中 **区域类型=宿舍区(1)** 且 **状态=正常(0)** 的违纪类型。
+
+**不需要发版**，只改生产库数据。
+
+---
+
+## 交付文件
+
+| 文件 | 说明 |
+|------|------|
+| `backend/script/sql/update/update_20261020_dorm_hygiene_deduction_types.sql` | 备份 → 停用旧宿舍区类型 → 插入新条例 |
+| 本文档 | 生产执行步骤与验收 |
+
+---
+
+## 执行前确认
+
+1. 已与宿管确认《扣分条例10月15日》为现行标准。  
+2. **「吸毒、贩毒」** 原文无分值，脚本暂按 **2–12** 录入（见该条 `remark`），确认后可改。  
+3. 有生产库备份权限；建议低峰执行。  
+4. 准备好可回滚窗口（约 10–15 分钟）。
+
+---
+
+## 推荐执行步骤
+
+### 第 1 步：全库备份（运维）
+
+按现有规范做一次生产库逻辑备份 / 快照（至少包含 `xskh_discipline_type`）。
+
+### 第 2 步：在测试库先跑一遍（强烈建议）
+
+```bash
+# 示例：在测试库执行整份脚本
+mysql -h<测试主机> -u<用户> -p <库名> < backend/script/sql/update/update_20261020_dorm_hygiene_deduction_types.sql
+```
+
+核对输出：
+
+- `bak_dorm_type_count` > 0（若原先没有宿舍区类型，可为 0）
+- `new_active_dorm_types` = **60**
+- 「仍启用的旧宿舍区类型」查询结果为 **空**
+
+测试环境打开：寝室卫生检查 → 新建检查 → 扣分项列表应为新 60 项。
+
+### 第 3 步：生产执行
+
+1. 登录生产库（只读账号先跑「步骤1核对」SELECT，确认现状）。  
+2. 用有写权限账号**整文件执行**：
+
+```bash
+mysql -h<生产主机> -u<用户> -p <生产库名> < backend/script/sql/update/update_20261020_dorm_hygiene_deduction_types.sql
+```
+
+或在 Navicat / DBeaver 中打开该 SQL，**按步骤分段执行**（0→1→2→3→4→5），每步看结果再继续。
+
+3. 确认：
+
+```sql
+SELECT COUNT(*) AS new_active_dorm_types
+FROM xskh_discipline_type
+WHERE area_type = '1' AND deleted = 0 AND status = '0'
+  AND type_code LIKE 'sskf202610_%';
+-- 期望：60
+```
+
+### 第 4 步：业务验收
+
+1. Web：**学生考核 → 违纪类型**，筛「宿舍区」，应看到 60 条新类型（编码 `sskf202610_*`）。  
+2. Web / 移动端：**寝室卫生检查** 新建一条，扣分项下拉为新条例；选一项默认分为最低分，可在区间内改。  
+3. 旧历史检查记录仍可打开（旧类型已停用但未删）。
+
+### 第 5 步：通知宿管
+
+告知：从即日起检查按新条例扣分；若某项分值需调整，在「违纪类型」里改最低/最高分即可，不必再跑脚本。
+
+---
+
+## 脚本做了什么（摘要）
+
+1. **备份**当前宿舍区类型 → `xskh_discipline_type_bak_20261020`  
+2. **停用**旧宿舍区启用类型（`status=1`，不删）  
+3. **删除**未被子检查引用的本批次旧插入（便于重跑）  
+4. **插入** 60 条新类型（`area_type=1`，`type_category=1`，`status=0`）  
+5. **核对**查询
+
+教学区违纪（`area_type=2`）**不动**。
+
+---
+
+## 回滚（出问题才用）
+
+```sql
+-- 1. 去掉本次新数据（若尚未被检查引用）
+DELETE FROM xskh_discipline_type WHERE type_code LIKE 'sskf202610_%';
+
+-- 2. 按备份恢复旧宿舍区类型状态
+UPDATE xskh_discipline_type t
+INNER JOIN xskh_discipline_type_bak_20261020 b ON b.id = t.id
+SET t.status = b.status,
+    t.remark = b.remark,
+    t.update_time = NOW()
+WHERE t.area_type = '1';
+```
+
+若新类型已被检查使用，不要 DELETE，改为把新类型 `status` 置停用，再恢复旧类型。
+
+---
+
+## 分类与条数
+
+| 分类 | 编码前缀 | 条数 |
+|------|----------|------|
+| 卫生方面 | `sskf202610_ws_*` | 21 |
+| 纪律方面 | `sskf202610_jl_*` | 16 |
+| 重大违纪 | `sskf202610_zd_*` | 23 |
+| **合计** | | **60** |
+
+---
+
+## 常见问题
+
+**Q：执行后检查页还是旧项？**  
+刷新页面或重新进入检查；确认接口 `listByAreaType?areaType=1` 返回新数据。
+
+**Q：能否只改几条、不全量切换？**  
+可以，改在后台「违纪类型」手工增删改；本脚本适合一次性对齐条例。
+
+**Q：历史扣分记录会变吗？**  
+不会。历史明细仍引用旧 `discipline_type_id`，只是旧类型被停用，新检查不再可选。

docs/开发文档/请假销假审批按钮修复说明.md

@@ -0,0 +1,20 @@
+# 请假/销假审批按钮修复说明（方案 B）
+
+## 问题
+
+办理页「审批」按钮依赖 `pageType=approval && status=waiting`。  
+打回重提后，流程实例已是 `waiting`，业务表常残留 `draft`/`back`，老师看不到审批按钮。
+
+## 方案
+
+1. **后端权威同步**：`LeaveFlowStatusSyncHelper` 在流程事件/任务创建时，按流程实例状态对齐请假 `approval_status`、销假 `cancel_status`（实例 waiting 则强制 waiting；禁止 waiting→draft）。
+2. **审批上下文接口**：`GET /workflow/instance/approvalContext/{businessId}`  
+   返回 `canApprove`、`taskId`、`suggestedBusinessStatus`。
+3. **按钮判断**：`canApprove=true` 即可显示审批（不再只绑死业务 status）。
+4. **存量修复**：`backend/script/sql/update/update_20261020_fix_leave_cancel_status_sync.sql`
+
+## 影响范围
+
+- 请假/销假办理页（Web + 移动端）
+- 通用 `approvalButton`（新增可选 `canApprove`，默认 false，其它模块不受影响）
+- 不改 Warm-Flow 全局监听器