zzw
23 小时以前 1332cc511936d7dbe804921bc733c83d5e4d1400
HANDOFF.md
@@ -1,12 +1,13 @@
# HANDOFF:临抢修软件需求与第一版实现
> 交接日期:2026-08-25(2026-08-26 晚 / 2026-09-07 / 2026-09-08 / 2026-09-09 核对 / 2026-09-10 / 2026-09-11 / 2026-09-14 / 2026-09-16 / 2026-09-17 / 2026-09-28 新会话准备 / 2026-09-28 专业配置与故障编号自动生成 更新)| 用途:新开会话时先读本文件,即可无缝接续
> 项目目录:`C:\Users\jcxiong\Documents\Codex\MyProject\EmergencyRepair`
> 交接日期:2026-08-25(2026-08-26 晚 / 2026-09-07 / 2026-09-08 / 2026-09-09 核对 / 2026-09-10 / 2026-09-11 / 2026-09-14 / 2026-09-16 / 2026-09-17 / 2026-09-28 新会话准备 / 2026-09-28 专业配置与故障编号自动生成 / 2026-09-29 代码入库公司 Git 更新 / 2026-10-02 本机环境迁移与前后端启动)| 用途:新开会话时先读本文件,即可无缝接续
> 项目目录(2026-10-02 起为本机 `D:\projectJava\lqx`;行内旧路径 `C:\Users\jcxiong\Documents\Codex\MyProject\EmergencyRepair` 为上一台机器)
> 注意:2026-10-02 本机工具链与旧记录不同,构建、启动与工作方式约定以第 16 节为准。
## 0. 最新交接(2026-09-28 新会话准备,优先阅读)
> 本节记录当前“第一版已落地代码”的最新状态,优先于下方较早的需求梳理和会话记录。
> 工作目录:`D:\Codex\MyProject\EmergencyRepair`;项目不是 Git 仓库。
> 工作目录:`D:\Codex\MyProject\EmergencyRepair`;Git 仓库:`http://admin@61.183.254.94:3000/r/EmergencyRepair.git`,默认分支 `main`。
### 0.1 当前运行状态
@@ -288,14 +289,14 @@
### 0.10 2026-09-28 专业配置与故障编号自动生成(本次会话,已实现并验证)
用户本次给出的 4 条新需求:① 系统管理增加“工程专业配置”(字段仅名称);② 系统管理增加“T队专业配置”(字段名称、分类 A/B);③ 故障编号不再手工输入,改为按 `潜1基-X号/A-YYMMDD-nnn` 自动生成;④ 派单号为 `故障编号/nn`,承修单位序号从 01 起。
用户本次给出的 4 条新需求:① 系统管理增加“工程专业配置”(字段仅名称);② 系统管理增加“T队专业配置”(字段名称、分类 A/B);③ 故障编号不再手工输入,改为按 `固定前缀-X号/A-YYMMDD-nnn` 自动生成;④ 派单号为 `故障编号/nn`,承修单位序号从 01 起。
已实现:
- “工程专业配置”:菜单 `/system/engineering-majors`,字段仅“名称”;表 `LX.T_ENGINEERING_MAJOR(ID, NAME, CREATE_TIME, UPDATE_TIME)`;接口 `/api/system/engineering-majors`(GET/POST/PUT/DELETE)。
- “T队专业配置”:菜单 `/system/team-majors`,字段“名称、分类(A/B)”;表 `LX.T_TEAM_MAJOR(ID, NAME, CATEGORY, CREATE_TIME, UPDATE_TIME)`;接口 `/api/system/team-majors`(GET/POST/PUT/DELETE)。
- 两处配置均校验名称非空与重名;T队专业分类只允许 A/B。启动时 `DataInitializer.ensureMajorConfigMenus` 幂等补菜单,`seedMajors` 预置演示数据:工程专业 动力/电气/液压/辅机;T队专业 动力=A、液压=A、电气=B、辅机=B(默认拆分,可在页面修改)。
- 故障编号自动生成:`BusinessService.generateFaultCode`,格式 `潜1基-X号/分类-YYMMDD-nnn`。
  - 前缀固定 `潜1基-`;X号取 3 位数字(`X01` → `001`)。
- 故障编号自动生成:`BusinessService.generateFaultCode`,格式 `固定前缀-X号/分类-YYMMDD-nnn`。
  - 前缀固定 `固定前缀-`;X号取 3 位数字(`X01` → `001`)。
  - 分类取“T队专业配置”的 A/B;未配置或分类非法时保存报错并提示先行维护。
  - YYMMDD 取上报日期;nnn 为“同一 X号 + 同一 T队专业 + 同一上报日期”的序号,从 001 起。
  - 新建自动生成;修改时强制沿用原编号(改 T队专业/日期也不重新生成)。
@@ -308,8 +309,8 @@
验证(2026-09-28):
- 后端 `mvn -q -DskipTests package` 通过;前端 `vue-cli-service build` 通过(仅既有包体积提示)。
- 接口:工程专业、T队专业各返回 4 条;`/api/system/menu/nav` 系统管理下新增两项(排序 35/36)。
- 自动编号:`X02 + 动力专业(A) + 2026-09-28` → `潜1基-002/A-260928-001`、`潜1基-002/A-260928-002`;换 T队专业(电气 B)→ `潜1基-002/B-260928-001`;换上报日期 → `潜1基-001/A-260929-001`;修改故障改 T队专业后编号保持不变。
- 派单端到端:一条故障分配两个承修单位,生成 `潜1基-002/B-260928-001/01`、`.../02`。测试数据已从 `LX.T_FAULT`、`LX.T_WORK_ORDER` 清理。
- 自动编号:`X02 + 动力专业(A) + 2026-09-28` → `固定前缀-002/A-260928-001`、`固定前缀-002/A-260928-002`;换 T队专业(电气 B)→ `固定前缀-002/B-260928-001`;换上报日期 → `固定前缀-001/A-260929-001`;修改故障改 T队专业后编号保持不变。
- 派单端到端:一条故障分配两个承修单位,生成 `固定前缀-002/B-260928-001/01`、`.../02`。测试数据已从 `LX.T_FAULT`、`LX.T_WORK_ORDER` 清理。
- 浏览器:两个新配置页正常渲染;故障上报新增表单“故障编号”只读且占位“保存后自动生成”,T队专业/工程专业下拉为配置项;修复后控制台无新增报错。
- 历史演示故障仍使用 `GZ-2026-0xx` 旧编号(未迁移,避免影响已派工单引用);新建故障一律使用新规则。
- 文档已同步:`requirement\决策表_待确认项.md`、`前44页需求梳理.md`、`工程状态机设计.md`、`界面还原.html`,以及首页公告“派单规则”文案。
@@ -335,6 +336,7 @@
- 端到端:临时走完“故障上报→XCB审核→三级审批→派单→完工信息上报”,提交成功且派工单状态写为 `COMPLETED`;库内落盘为 `SOLUTIONS_JSON=[{"content":"更换密封件"},{"content":"完成压力复测"}]`、`SOLUTION=更换密封件;完成压力复测`、器材 JSON 含 `certificate`。本次临时数据(故障、派工单、完工信息、验收)已全部清理。
- 浏览器核验(1440px):基础信息内“验收方式+项目名称”同一行,“修后质量情况”“故障说明”“原因分析”各独占整行;处理解决情况表头为“序号/处理解决情况/操作”;器材表头为“序号/名称/规格型号/技术参数/数量/计量单位/合格证明/出库单号/来源/备注/操作”;两个“添加一行”按钮均可用。
- 最终布局微调(2026-09-28 晚):按用户补充要求把“项目名称”并到“验收方式”一行、把“故障说明”“原因分析”改为整行;前端 vue-cli-service build 再次通过,dist 已刷新。
- 代码托管(2026-09-28 晚):项目首次纳入 Git,初始化 `main` 分支并推送到 `http://admin@61.183.254.94:3000/r/EmergencyRepair.git`,首提交 `5305262`;`.gitignore` 排除 `.venv/`、`.ocrvenv/`、`_extract/`、`node_modules/`、`dist/`、`target/`、`*.log`,共提交 103 个文件(约 4.6MB,含需求文档)。
## 0. 本会话记录(2026-09-20 周日)
@@ -639,3 +641,188 @@
- **产品结构树管理 / 设备基础库管理**:产品结构树为型号→X号→一级系统→二级系统→设备的5级树;设备基础库为一级系统→二级系统→设备的3级树;前者设备是实例,后者设备是类。
- **统计报表**:一级菜单包含6项功能;装备故障总体分析上方为柱状图、下方为统计,故障高发设备 Top 通过设备基础库跨T归集。
- **XCB助理审核补充(16:25)**:补齐9类筛选控件;“修改”“销项”按钮已落地并验证。修改支持 `UNREPORTED / REPORTED_XCB / RETURNED`,销项仅支持 `REPORTED_XCB / RETURNED`,销项后状态为 `CANCELLED` 并写回理由、操作人和时间。
## 15. 收尾快照(2026-09-29 周二 06:49,上班前关机)
**本次会话完成(细节见 0.10 / 0.11)**
- 决策表 B1–B4 按建议关闭并落地:系统管理新增“工程专业配置”(字段:名称)、“T队专业配置”(字段:名称、分类 A/B)。
- 故障编号改为自动生成:`固定前缀-X号/A-YYMMDD-nnn`(X号 3 位数字,A=T队专业 A/B,nnn 为同一 X号+同一专业+同一上报日期内从 001 递增);派单号=`故障编号/nn`(承修单位序号,从 01 起)。
- 故障上报页:任务状态标签与任务状态下拉框拆成两行(标签换到下一行)。
- 完工信息上报页(AXU15):修后质量情况独占整行;项目名称与验收方式同一行;故障说明、原因分析各独占整行;“处理解决情况”改为可多行的表格(序号/处理解决情况);维修器材表列改为序号、名称、规格型号、技术参数、数量、计量单位、合格证明、出库单号、来源、备注。后端新增 `LX.T_COMPLETION_INFO.SOLUTIONS_JSON` 与 `MaterialItem.certificate`,并继续兼容原 `SOLUTION` 字段。
- 项目纳入公司 Git 仓库:`http://admin@61.183.254.94:3000/r/EmergencyRepair.git`,分支 `main`,首提交 `5305262`(103 个文件),随后 `0bacdcf` 补记远端信息。
**关机时状态**
- 前端 `http://localhost:8082`(监听 PID 22092)、后端 `http://127.0.0.1:8091`(监听 PID 28104)仍在运行,随关机自动结束。
- 登录 `admin / admin123`;数据库 DM8 `SYSDBA/SYSDBA@127.0.0.1:5236`,schema `LX`。
- 工作区干净,本地 `main` 与 `origin/main` 一致。
**下次开机接续**
1. 先确认 `8082/8091` 是否在监听;不在就按 0.1 节命令重启(前端用内置 Node 24 跑 `vue-cli-service serve`,后端用 `mvn -q spring-boot:run`,输出分别重定向到 `frontend.log` / `backend.log`)。
2. 决策表 B6–B10 待用户答复(`requirement\工程状态机设计.md` 第 4 节 + `requirement\决策表_待确认项.md` B 组),答完固化为正式设计。
3. AXU15 剩余待确认:字段来源与可改性(待确认清单第 13 条)、完工验收各环节角色与打印输出、修后质量评级与 AXU14 T员评分字段的关系。
4. 后续改动完成后直接推送到公司 Git 仓库 `main` 分支。
## 16. 收尾快照(2026-10-02 周五,本机环境迁移与前后端启动)
**环境迁移(重要,与第 0 节旧记录不同)**
- 代码已在本机重新拉取,工作目录改为 `D:\projectJava\lqx`,不再是 `D:\Codex\MyProject\EmergencyRepair`。
- 仓库:`http://61.183.254.94:3000/r/EmergencyRepair.git`,分支 `main`,本地 HEAD `5d015d7`(docs: add shutdown snapshot for 2026-09-29),与 `origin/main` 一致。
- 克隆时远端 HEAD 指向不存在的 ref,不会自动检出,需手动 `git checkout main`。凭据已存入 Windows 凭据管理器,`.git/config` 中不再有明文密码。
- 本机工具链与旧机器不同,**第 0.9 节和第 8 节里“`apply_patch` 不可用、必须用 Python 读改写、不能用 `Start-Process`”的约定只适用于上一台机器**,本机 `apply_patch` 与 `Start-Process` 均可正常使用。
- JDK:`C:\Program Files\Java\jdk1.8.0_172`。PATH 里的 java 是 JRE 1.8.0_481(没有 javac),构建前必须显式设置 `JAVA_HOME`。
- Maven:`D:\solidDir\apache-maven-3.6.1\bin\mvn.cmd`(不在 PATH,需绝对路径调用)。
- Node/npm:`C:\Program Files\nodejs`(Node v14.8.0 / npm 6.14.7,不在 PATH,需绝对路径调用)。
- 达梦驱动 `dm.jdbc:DmJdbcDriver18:1.0` 在默认本地仓库缺失(只有下载失败标记),已从 `D:\solidDir\repo` 同名构件安装进 `C:\Users\Lenovo\.m2`;属环境准备,未改项目文件。
- DM8:服务 `DmServiceDMSERVER` 运行中,监听 `127.0.0.1:5236`(PID 5692),账号 `SYSDBA/SYSDBA`,schema `LX`。
**本次完成的构建与运行**
- 后端 `mvn -B -DskipTests clean package` 通过,产物 `emergency-repair-server\target\emergency-repair-server-1.0.0-SNAPSHOT.jar`(约 27MB)。
- 前端 `npm install` + `npm run build` 通过,产物 `emergency-repair-web\dist`,仅两个既有包体积告警。
- 后端用 `java -jar target\emergency-repair-server-1.0.0-SNAPSHOT.jar` 后台运行,监听 `8091`(PID 61648);前端用 `node node_modules\@vue\cli-service\bin\vue-cli-service.js serve` 后台运行,监听 `8082`(PID 57052)。日志为项目根的 `backend.log` / `frontend.log`(`*.log` 已被 `.gitignore` 忽略)。
- HTTP 验证:`POST /api/auth/login`(`admin/admin123`)返回 `code=200`;`GET http://localhost:8082/` 返回 200;前端 `/api` 代理到 8091 链路通。登录 `admin / admin123`。
**本次唯一代码改动(已获用户确认)**
- `emergency-repair-web\src\utils\sensitive.js`:敏感词运行时替换改为跳过表格数据单元格。
  - 口径:`<td>` 内的文本与属性保持代称;`<th>` 表头、页面标题、筛选标签、placeholder 照常替换。
  - 实现:新增 `isInsideTableCell()`(`closest('td')`),接入文本遍历、属性替换、`MutationObserver` 字符变化回调,以及 `replaceDom()` 直接收到文本节点的分支。
  - 验证:向运行页面注入探针表格(表头与数据格均写 `X号`),结果为 `<th>县号</th>`、`<td>X号</td>`;`npm run build` 通过。
  - 效率影响:表格场景通常更快;没有表格且高频更新普通文本时,仅增加 `closest('td')` 的少量判断开销。
**用户本次明确的工作方式要求(务必遵守)**
- 用户问“可不可以……”时只是要调查结论和方案,**不要直接改代码**;只有用户明确要求实施时才动文件。
- 改动前先说明要改什么,口径不明确时先问清楚。
**下次接续**
1. 先确认 `5236 / 8091 / 8082` 是否在监听,不在再按上面的命令重启(本机启动需显式设置 `JAVA_HOME`,Maven / Node 用绝对路径)。
2. `sensitive.js` 改动已获确认并随本次提交推送;`requirement\~$原始需求.docx` 是 Word 锁文件,不要提交。
3. 需求侧待确认项不变:决策表 B6–B10、AXU15 字段来源与可改性、完工验收各环节角色与打印输出、修后质量评级与 AXU14 T员评分字段的关系。
4. 后续改动完成后推送到公司 Git 仓库 `main` 分支。
## 17. 收尾快照(2026-10-04 周六,需求 11 / 12 / 17-19 联调收尾)
**本轮完成内容**
- 需求 11:完工情况处理将状态改为“完工”时,只更新派工单状态,不再跳转“完工信息填报”。完工处理与完工填报由不同用户分别操作。
- 需求 12:完工信息填报的派工单选择列表只展示“已在完工情况处理中确认完工、属于当前登录用户所属单位、且尚未填报”的派工单,并增加工程名称(项目名称)显示。
- 需求 17:角色管理的“用户设置”增加“全部 / 已设置”过滤切换。
- 需求 18:新增“组织机构”部门树表页面,菜单 `/system/organization`,页面 `OrganizationManage.vue`,数据来自 `CSICZB_ZB.SYS_DEPT`,后端接口 `/api/system/depts`。当前环境返回 34 个部门,支持名称、编码、负责人、部门类型筛选。
- 需求 19:承修单位改为读取 `SYS_DEPT.DEPT_TYPE='cj'` 的部门记录,部门 ID 作为承修单位 ID;承修单位接口保留 GET,页面改为只读。当前环境返回 7 个 cj 部门,XCB审核、派单均使用 cj 部门 ID/名称。
**主要文件**
- 后端:`emergency-repair-server/src/main/java/com/emergencyrepair/system/service/SystemService.java`、`emergency-repair-server/src/main/java/com/emergencyrepair/business/service/BusinessService.java`、`emergency-repair-server/src/main/java/com/emergencyrepair/bootstrap/DataInitializer.java`。
- 前端:`emergency-repair-web/src/views/system/OrganizationManage.vue`、`emergency-repair-web/src/views/system/ContractorManage.vue`、`emergency-repair-web/src/views/completion/CompletionReport.vue`、`emergency-repair-web/src/views/system/RoleManage.vue`、`emergency-repair-web/src/router/index.js`。
**验证结果**
- 后端 `mvn -B -DskipTests clean package` 通过;前端 `npm run build` 通过。
- 页面验证脚本完整通过:`node .codex-run/verify-items-11-12-17.js`、`node .codex-run/verify-items-18-19.js`;截图见 `.codex-run/organization-verified.png`、`.codex-run/contractor-readonly-verified.png`、`.codex-run/completion-report-verified.png`、`.codex-run/role-scope-verified.png`。
- 端到端联调使用临时故障 `固定前缀-088/A-261004-001`,跑通上报、XCB审核分配“厂家1/厂家2”、CMB/JCC三级审批、派单。最终故障保存 `contractorIds = 1303144990487465986,1303145150793764866`、`contractorNames = 厂家1、厂家2`,生成两张派工单,均保存 cj 部门 ID/名称。
- 完工填报可见性验证:`cjyh1-1` 仅看到厂家1派工单,`cjyh2-1` 仅看到厂家2派工单,`admin` 可看到两张。临时 `T_FAULT` / `T_WORK_ORDER` 测试数据已清理。
**当前运行状态(2026-10-04)**
- 前端:`http://localhost:8082`;后端:`http://127.0.0.1:8091`;DM8:`127.0.0.1:5236`;headless Edge 调试实例端口 `9222`。
- 登录:`admin / admin123`;数据库:`SYSDBA/SYSDBA`,业务 schema `LX`。
**接手注意事项**
- 非管理员用户的完工填报派工单单位匹配当前按 `DEPT_NAME`,不是按 `DEPT_ID`。本次验证通过;如存在同名部门,应改为按部门 ID 精确匹配。
- 历史演示派工单可能保留旧 `T_CONTRACTOR` 名称,非管理员 cj 用户可能看不到这些历史单;`admin` 不受单位过滤影响。
- `.codex-run`、Office 锁文件 `requirement\~$原始需求.docx` 和 `emergency-repair-web/public/新建 文本文档.txt` 属本地联调或临时文件,不应提交。
- 本轮代码已提交并推送公司 Git 仓库 `main` 分支,提交 `757dcb3`;交接文件回填提交记录。后续启动、构建和排错命令沿用第 16 节。
## 18. 收尾快照(2026-10-06 周一,需求 20 菜单权限管理收尾)
**本轮完成内容**
- 需求 20:菜单权限管理取消租户权限和角色权限的双重授权,改为单步设置角色权限。当前用户本身没有租户归属,因此不再设置租户权限。
- 权限树继续展示菜单节点和按钮节点,不按 `menuType` 过滤;切换角色后,已保存权限复选框正常反显。
- 菜单权限接口只保留 `roleId` / `roleMenuIds`,删除租户菜单授权及 `/api/system/tenants`。
- 修复雪花 ID 经浏览器 JSON 解析后精度丢失的问题:后端返回字符串 ID,前端选中态按字符串处理。
**主要文件**
- 后端:`emergency-repair-server/src/main/java/com/emergencyrepair/business/dto/Requests.java`、`emergency-repair-server/src/main/java/com/emergencyrepair/system/controller/SystemController.java`、`emergency-repair-server/src/main/java/com/emergencyrepair/system/service/SystemService.java`。
- 前端:`emergency-repair-web/src/views/system/MenuPermission.vue`。
**验证结果**
- 后端 `mvn -B -DskipTests compile` 通过;前端 `npm run build` 通过。
- 接口:`GET /api/system/menu-permissions?roleId=2106221661022490625` 返回字符串型 `roleMenuIds` 共 14 条。
- 浏览器:`node .codex-run/verify-menu-permission.js` 输出 `hasTenantPanel: false`、`buttonNodeCount: 76`、`checkedMatchesSaved: true`、`hasError: false`;截图 `.codex-run/menu-permission-verified.png`。
- 页面确认按钮节点保留,切换角色后权限勾选可正常反显。
**当前运行状态(2026-10-06)**
- 前端 `http://localhost:8082`,后端 `http://127.0.0.1:8091`,DM8 `127.0.0.1:5236`,Edge CDP `9222`。
- 登录 `admin / admin123`;数据库 `SYSDBA/SYSDBA`,业务 schema `LX`。
- 后端日志:`.codex-run/backend-20261006-menu-permission-fixed.out.log`、`.codex-run/backend-20261006-menu-permission-fixed.err.log`。
**接手注意**
- 不要提交 `.codex-run`、Office 锁文件或 `emergency-repair-web/public/新建 文本文档.txt`。
- 本轮代码与交接记录一并提交并推送公司 Git 仓库 `main` 分支。
## 19. 收尾快照(2026-10-06 周一,需求 21-22 菜单权限入口与错误日志)
**本轮完成内容**
- 需求 21:移除独立“菜单权限管理”菜单,在角色管理操作列新增“权限设置”按钮,并复用菜单/按钮权限树弹窗;旧 `/system/menu-permissions` 路由和页面已删除。
- 需求 22:系统管理新增“系统配置 / 权限配置 / 日志管理”三个二级目录;组织机构、承修单位、产品结构树、设备基础库、工程专业、T队专业、三员控制归入系统配置,用户管理、角色管理、菜单管理归入权限配置,登录日志、操作日志、错误日志归入日志管理。
- 错误日志为新增功能:`GlobalExceptionHandler` 捕获未处理的非业务异常并异步写入 `LX.T_SYS_ERROR_LOG`;业务校验异常不记录。列表支持模块、异常类型、时间筛选,详情展示完整堆栈。
- 新库初始化和旧库迁移均会删除旧菜单并补齐二级目录的父子菜单关系;权限树继续保留菜单节点和按钮节点,角色切换后复选框可反显。
**主要文件**
- 后端:`emergency-repair-server/src/main/java/com/emergencyrepair/system/entity/SysErrorLog.java`、`.../mapper/SysErrorLogMapper.java`、`.../log/ErrorLogRecorder.java`、`.../common/GlobalExceptionHandler.java`、`.../bootstrap/DataInitializer.java`、`.../bootstrap/DatabaseBootstrap.java`、`.../system/controller/SystemController.java`、`.../system/service/SystemService.java`、`.../system/service/ButtonPermissionCatalog.java`。
- 前端:`emergency-repair-web/src/views/system/RoleManage.vue`、`RolePermissionDialog.vue`、`ErrorLogManage.vue`、`emergency-repair-web/src/router/index.js`、`MenuManage.vue`;`MenuPermission.vue` 已删除。
**验证结果**
- 后端 `mvn -B -DskipTests clean package` 通过;前端 `npm run build` 通过,仅有既有包体积告警。
- `node .codex-run/verify-req21-22.js` 通过:三个二级目录和错误日志菜单正常显示,旧菜单不存在,角色管理“权限设置”弹窗按钮节点数为 78 且反显正常。
- 人为访问非法错误日志详情 ID 后,记录自动落库并可在错误日志页面查看;验证用临时记录已从数据库清理。
- 截图:`.codex-run/role-permission-dialog-verified.png`、`.codex-run/error-log-verified.png`。
**当前运行状态(2026-10-06)**
- 前端 `http://localhost:8082`;后端 `http://127.0.0.1:8091`;DM8 `127.0.0.1:5236`;Edge CDP `9222`。
- 登录 `admin / admin123`;数据库 `SYSDBA/SYSDBA`,业务 schema `LX`。
- 后端日志:`.codex-run/backend-20261006-req21-22.out.log`、`.codex-run/backend-20261006-req21-22.err.log`。
**接手注意**
- 错误日志当前覆盖进入 Spring MVC 全局异常处理的异常;启动阶段异常、异步线程中未进入该处理器的异常暂不会自动落库。
- 不要提交 `.codex-run`、Office 锁文件或 `emergency-repair-web/public/新建 文本文档.txt`。
- 本轮代码与交接记录一并提交并推送公司 Git 仓库 `main` 分支。
## 20. 收尾快照(2026-10-06 周一,需求 23-25 系统配置、完工查阅与菜单父节点)
**本轮完成内容**
- 需求 23:系统名称和版本改为关键词配置,codename 分别为 `rk_SystemName`、`rk_SystemVer`。登录页、页头、Logo 替代文本和浏览器标题使用配置值;页头版本使用红色显示。
- 需求 24:新增“完工信息查阅”功能,菜单 `/completion/query`,接口 `GET /api/work-orders/completion/query`。查询结果按故障汇总,一个故障展开多张派工单;故障编号、rk_X号、设备、工程名称及损坏情况、上报单位、上报日期、序号这 7 列使用单元格纵向合并。每张派工单的完工处理情况和更换器材支持多条明细。
- 需求 24 的查询条件包括关键词、承修单位、完工状态和完工日期。关键词匹配故障、派工单、工程编号、承修人和明细内容。
- 需求 25:菜单管理编辑时,“上级菜单”改为可编辑级联选择器;编辑时排除当前菜单及其全部下级,按钮类型只能选择菜单类型父节点。
- 需求 25 后端同步增加父节点存在性、自引用和循环层级校验,避免通过接口构造循环菜单树。
**主要文件**
后端:
- `emergency-repair-server/src/main/java/com/emergencyrepair/business/dto/CompletionFaultQueryItem.java`(新增)
- `emergency-repair-server/src/main/java/com/emergencyrepair/business/controller/WorkOrderController.java`
- `emergency-repair-server/src/main/java/com/emergencyrepair/business/service/BusinessService.java`
- `emergency-repair-server/src/main/java/com/emergencyrepair/bootstrap/DataInitializer.java`
- `emergency-repair-server/src/main/java/com/emergencyrepair/system/service/SystemService.java`
- `emergency-repair-server/src/main/java/com/emergencyrepair/system/service/ButtonPermissionCatalog.java`
前端:
- `emergency-repair-web/src/views/completion/CompletionQuery.vue`(新增)
- `emergency-repair-web/src/views/system/MenuManage.vue`
- `emergency-repair-web/src/components/AppHeader.vue`、`Login.vue`、`RepairLogo.vue`、`layout/AppLayout.vue`、`router/index.js`、`utils/sensitive.js`、`main.js`
- `emergency-repair-web/public/sensitive-words.json`、`public/index.html`
- `requirement/敏感词字典.json`
**验证结果**
- 后端 `mvn -B -DskipTests compile` 通过;前端 `npm run build` 通过,仅有既有包体积告警。
- `node .codex-run/verify-req23-25.js`:页面标题和页头使用“临抢修管理系统 / 网络版”,版本颜色为 `rgb(255, 107, 107)`;完工查阅显示故障 `GZ-2026-012`、处理情况和器材;菜单编辑父节点显示“故障管理”且可编辑。
- 接口实测:临时同一故障插入两张派工单和两条完工记录后,`GET /api/work-orders/completion/query?keyword=ZZ-MERGE-TEST-20261006` 返回 1 个故障、2 张派工单,每条各 1 条处理情况和 1 条器材。
- 浏览器合并实测:页面生成 2 张派工单行,故障编号单元格只出现 1 次,7 个故障信息列均有 `rowspan=2`,两张单各自的处理情况和器材均正常显示,无网络异常;截图 `.codex-run/completion-query-merge-verified.png`。临时数据库记录已清理。
- 菜单父节点接口实测:临时创建父子菜单成功;把父菜单移动到其子菜单下返回“上级菜单不能选择当前菜单的下级”;把子菜单移动到其他父节点成功;临时菜单已清理。
**当前运行状态(2026-10-06)**
- 前端 `http://localhost:8082`;后端 `http://127.0.0.1:8091`;DM8 `127.0.0.1:5236`;Edge CDP `9222`。
- 登录 `admin / admin123`;数据库 `SYSDBA/SYSDBA`,业务 schema `LX`。
- 后端日志:`.codex-run/backend-20261006-req23-25-v2.out.log`、`.codex-run/backend-20261006-req23-25-v2.err.log`。
**接手注意**
- 完工信息查阅当前只汇总已经存在完工填报记录 `T_COMPLETION_INFO` 的派工单;仅完工处理但未填报完工信息的派工单不会出现在查阅结果中。
- 完工查阅接口当前一次返回全部匹配结果,没有分页;数据量进一步增大时建议增加分页或导出策略。
- 不要提交 `.codex-run`、Office 锁文件或 `emergency-repair-web/public/新建 文本文档.txt`。
- 本轮代码、需求文件和交接记录一并提交并推送公司 Git 仓库 `main` 分支。