docs: record 2026-10-04 integration commit

zzw

3 天以前 073605b6d62363dd7d48f5ca047a1d401418574a

 HANDOFF.md

@@ -289,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队专业/日期也不重新生成）。
@@ -309,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`，以及首页公告“派单规则”文案。
@@ -646,7 +646,7 @@

**本次会话完成（细节见 0.10 / 0.11）**
- 决策表 B1–B4 按建议关闭并落地：系统管理新增“工程专业配置”（字段：名称）、“T队专业配置”（字段：名称、分类 A/B）。
- 故障编号改为自动生成：`潜1基-X号/A-YYMMDD-nnn`（X号 3 位数字，A＝T队专业 A/B，nnn 为同一 X号＋同一专业＋同一上报日期内从 001 递增）；派单号＝`故障编号/nn`（承修单位序号，从 01 起）。
- 故障编号改为自动生成：`固定前缀-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` 补记远端信息。
@@ -697,3 +697,32 @@
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 节。