交接日期：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
本节记录当前“第一版已落地代码”的最新状态，优先于下方较早的需求梳理和会话记录。
工作目录：D:\Codex\MyProject\EmergencyRepair；Git 仓库：http://admin@61.183.254.94:3000/r/EmergencyRepair.git，默认分支main。
http://localhost:8082，最后运行进程示例 PID 30224；2026-09-20 下班关机时已停止；2026-09-28 再次启动，监听 PID 示例 22092（用内置 Node 24 运行 vue-cli-service serve）。node C:/Users/jcxiong/.cache/codex-runtimes/codex-primary-runtime/dependencies/node/bin/node.exe node_modules/@vue/cli-service/bin/vue-cli-service.js serve；生产构建把 serve 换成 build。http://127.0.0.1:8091，最后运行进程示例 PID 17712；2026-09-20 下班关机时已停止；2026-09-28 再次启动，监听 PID 示例 31836。admin / admin123。emergency-repair-web。emergency-repair-server。mvn -q spring-boot:run，输出重定向到项目根 backend.log。emergency-repair-web\dist。mvn -q -DskipTests package 通过；npm run build 通过，仅有既有 webpack 包体积警告。故障编号/01、故障编号/02 两张派工单；派单后不再出现在未派单列表。测试记录已从 LX.T_FAULT、LX.T_WORK_ORDER 及相关表清理，故障总数恢复为 16。8082/8091 是否仍在监听；若不在，再按下方命令重启。emergency-repair-web\src\components\RepairLogo.vue。AppHeader.vue；登录页接入：Login.vue。25px，并 transform: translateY(2px) 向下微调；登录页 44px。width: 1.30em; height: 1.03em。emergency-repair-web\src\views\fault\FaultReport.vue。emergency-repair-web\src\components\ProductTreePicker.vue。X号 下的设备；勾选不同 X号 设备时立即取消该次勾选并提示，确认时保留兜底校验。equipmentIds：逗号分隔的全部产品结构树设备 ID。equipmentId：首个设备 ID，保留兼容。equipmentName：多设备名称用中文顿号连接，例如“主推进装置、主配电装置”。parentSystem：多个上级系统用中文分号连接。LX.T_FAULT 新增 EQUIPMENT_IDS VARCHAR(2000)。DatabaseBootstrap.java，方法 ensureColumn(...)。Fault.java 已增加 @TableField("EQUIPMENT_IDS")。BusinessService.normalizeEquipmentIds(Fault fault)：EQUIPMENT_IDS。EQUIPMENT_ID。EQUIPMENT_NAME 字段，因此派工单显示的是故障的全部合并装备名称，不需要新增派工单表字段。EQUIPMENT_IDS -> 产品结构树设备 -> BASE_EQUIPMENT_ID -> 设备基础库设备 归集。GZ-2026-001 已变为 X01 / 主推进装置、主配电装置 两台设备。DataInitializer.upgradeDemoMultiEquipmentFault() 会在启动时幂等更新该演示数据。equipmentIds 为两个 ID、名称为两设备合并名称。FaultReport.vue 已改为服务端分页。20 条，可选 20 / 50 / 100。GET /api/faults/page?current=1&size=20&status=&keyword=Page<Fault>，字段包含 records/current/size/total/pages。GET /api/faults 保持返回列表，供审批、派单、导出使用。MyBatisPlusConfig.java 配置：PaginationInnerInterceptor(DbType.DM)。current=1&size=5 返回 5 条、总 16 条、共 4 页。emergency-repair-web\src\views\fault\FaultReport.vue 已补齐 AXU3 查询条件：X号、T队专业、工程专业、上报单位、负责人、上报日期起止。/api/faults/page 和 /api/faults 均支持上述筛选参数；导出复用同一组筛选条件，导出的是当前筛选结果而不是全部数据。xNo、teamMajor、engineeringMajor、reportUnit、owner、reportDateStart、reportDateEnd。动力专业 / 电气专业 / 液压专业 / 辅机专业，修复了原表单选项与业务数据不一致的问题。/api/system/tree?type=product 的产品结构树节点实时读取，当前为 X01/X02/X03。FAULT_CODE、EQUIPMENT_NAME、ENGINEERING_NAME_DESC；X号不再参与关键字查询，使用独立X号下拉筛选。ENGINEERING_NAME_DESC / engineeringNameDesc；启动时幂等迁移 T_FAULT.FAULT_DESCRIPTION -> ENGINEERING_NAME_DESC。完工信息的“故障说明”仍使用 FAULT_DESCRIPTION，未改动。工程名称及损坏情况、修理技术要求 位于 所属上级系统 与 工程专业 之间；补齐 重大故障描述、是否自修、是否涉H、监测数值。是否自修、是否涉H、监测项目 均显示“是/否”；全前端“要求完工时间”已统一改为“要求完工日期”。故障性质、是否自修、是否涉H、监测项目、上报日期、要求完工日期 单元格居中，其余字段保持默认左对齐。FaultReport.vue 新增/修改表单中的 X号 已改为可筛选的 el-select，选项复用页面从 /api/system/tree?type=product 加载的 xNumbers。监测项目；保留 是否监测项目 开关和受其控制的 监测数值 输入框。AuthController 的 /api/auth/login 与 /api/auth/me 新增返回 deptName，通过 LX.SYS_USER 关联 LX.SYS_DEPT 查询；Login.vue 将其写入 sessionStorage.deptName，FaultReport.vue 的 blankForm() 用它初始化 reportUnit。未找到部门时返回空字符串，原 T01队 硬编码已删除。是否监测项目 与 监测数值 单独占用一行，前者占 el-col-8，后者占 el-col-16，避免受前一行的栅格累计宽度影响而换行。ProductTreePicker.vue 改为固定位置的弹窗：使用 lock-scroll + top=4vh + flex 高度布局，树节点区域单独滚动；底部“已选择 nn 台设备”和按钮固定，已选设备列表以可关闭 el-tag 展示，点击关闭图标即取消该设备。id、parentId 和 baseEquipmentId 已按字符串返回，避免雪花 ID 超过 JavaScript 安全整数范围后在树内回查时串到错误的 X号。el-col-16，并根据节点级别显式排除型号根节点和 X号；多设备选择后只显示各设备 X号以下的系统路径，统一使用中文顿号连接。新保存值和历史 T_FAULT / T_WORK_ORDER 中的分号也会由后端幂等归一化为顿号。是否涉H、是否监测项目、监测数值位于同一行并各占 el-col-8。getXNo() 默认被 Jackson 映射为 xno，与前端 xNo 不一致。Fault、WorkOrder、Acceptance、CompletionInfo 已显式添加 @JsonProperty("xNo")。启动时还会根据已有 equipmentId 回填历史空 X号；此前页面测试产生的空 X号故障已补回 X01。Long ID 及关联 ID 字段已用 @JsonSerialize(using = ToStringSerializer.class) 按字符串返回；页面修改 xxx–001/A–0920–001、X号保持 X01 后保存已成功。FaultEditDialog.vue，销项填写理由后调用 /api/faults/cancel。UNREPORTED、REPORTED_XCB、RETURNED 状态允许由XCB助理修改；销项规则：仅 REPORTED_XCB、RETURNED 状态允许销项，写回销项理由、销项人、销项时间，任务状态改为 CANCELLED。xxx–001/A–1224–001。130 -> 180。80/90 -> 64（X号为3位数字）。210 并增加 show-overflow-tooltip。dist/sensitive-words.json，不重新打包。placeholder、title、aria-label 和动态 DOM。sensitive-words.json，用 TreeWalker 全量遍历文本节点，并替换 placeholder、title、aria-label 属性，再通过 MutationObserver 监听 document.body 的新增节点和 characterData 变化。O((文本节点数 + 属性节点数) × 字典项数)；动态内容会按新增子树或变化文本节点再次扫描。页面规模大、字典项多或 DOM 高频刷新时，可能出现主线程卡顿和重复无操作扫描。MutationObserver 通知、替换期间暂停 observer、跳过无目标节点；如果页面规模继续增长，改为表格 formatter、统一显示函数或虚拟滚动，不再全量扫描 DOM。/api/reports/overview、/api/reports/top-equipment、/api/reports/by-team、/api/reports/contractors、/api/reports/yearly-trend 已从 BusinessService 的整表加载 + JVM 聚合迁移到独立 ReportMapper + ReportMapper.xml + report DTO；接口 URL、返回结构和前端页面字段保持不变。business/mapper/ReportMapper.java、business/service/ReportService.java、business/dto/report/*、resources/mapper/ReportMapper.xml。ReportController 改为注入 ReportService。GROUP BY、COUNT、SUM、UNION 等数据库端聚合。topEquipment 保留 EQUIPMENT_IDS 与历史 EQUIPMENT_NAME 兼容口径；byTeam 和 yearlyTrend 的备品备件消耗改为汇总 T_COMPLETION_INFO.CONSUMABLE_COUNT，不再循环 selectById。DatabaseBootstrap 启动时幂等补 T_COMPLETION_INFO.CONSUMABLE_COUNT，并新增 IX_T_WORK_ORDER_FAULT_ID、IX_T_COMPLETION_WORK_ORDER 索引；DataInitializer 回填历史完工记录的消耗数量；BusinessService.submitCompletion(...) 同步写入该值。mvn -q -DskipTests package 通过；五个统计接口全部返回 code=200，重构前后的关键统计值一致。emergency-repair-server\src\main\java\com\emergencyrepair\bootstrap\DatabaseBootstrap.javaemergency-repair-server\src\main\java\com\emergencyrepair\bootstrap\DataInitializer.javaemergency-repair-server\src\main\java\com\emergencyrepair\business\entity\Fault.javaEQUIPMENT_IDS。emergency-repair-server\src\main\java\com\emergencyrepair\business\controller\FaultController.java/api/faults 和 /api/faults/page。emergency-repair-server\src\main\java\com\emergencyrepair\business\service\BusinessService.javaemergency-repair-server\src\main\java\com\emergencyrepair\business\controller\ReportController.javaemergency-repair-server\src\main\java\com\emergencyrepair\business\service\ReportService.javaemergency-repair-server\src\main\java\com\emergencyrepair\business\mapper\ReportMapper.javaemergency-repair-server\src\main\resources\mapper\ReportMapper.xmlemergency-repair-server\src\main\java\com\emergencyrepair\config\MyBatisPlusConfig.javaemergency-repair-web\src\views\fault\FaultReport.vueemergency-repair-web\src\components\ProductTreePicker.vueemergency-repair-web\src\components\RepairLogo.vueemergency-repair-web\src\components\AppHeader.vueemergency-repair-web\src\views\Login.vueemergency-repair-web\src\views\fault\XcbReview.vueemergency-repair-web\src\views\fault\DispatchPage.vueemergency-repair-web\src\views\fault\SimpleApproval.vueemergency-repair-web\src\views\completion\CompletionList.vueemergency-repair-web\src\views\acceptance\AcceptanceList.vueemergency-repair-web\src\views\Dashboard.vue前端构建：
cd D:\Codex\MyProject\EmergencyRepair\emergency-repair-web
npm run build
后端构建：
cd D:\Codex\MyProject\EmergencyRepair\emergency-repair-server
mvn -q -DskipTests package
后端重启时不要只杀单个 Java PID：
Get-NetTCPConnection -LocalPort 8091 -State Listen 找到监听 PID。mvn/java/cmd/powershell 的完整进程树。$ws = New-Object -ComObject WScript.Shell
$cmd = 'powershell.exe -NoProfile -Command "Set-Location ''D:\Codex\MyProject\EmergencyRepair\emergency-repair-server''; & ''D:\maven\apache-maven-3.6.1\bin\mvn.cmd'' -q spring-boot:run *> ''D:\Codex\MyProject\EmergencyRepair\backend.log'' 2>&1"'
$ws.Run($cmd, 0, $false)
8091 再次监听，再用 API 验证，不要只看日志文件是否存在。EQUIPMENT_IDS。GZ-2026-001 当前为两个装备。total=16、size=5、pages=4、records=5。故障编号/01、故障编号/02；核对使用临时数据并已清理。engineeringNameDesc，不再返回 faultDescription；DM8 实际列为 ENGINEERING_NAME_DESC。X02 返回 0 条；页面占位符、X号下拉（X01/X02/X03）和“至”分隔符显示正常。center；故障性质、是否自修、是否涉H、监测项目、上报日期、要求完工日期六列单元格为 center，工程名称及损坏情况、备注 等保持 left。上报单位默认值核验：admin 在 DM8 中的 DEPT_ID 无匹配 SYS_DEPT 记录，/api/auth/login 和 /api/auth/me 返回 deptName=""，页面上报单位为空。
X号 为 el-select，是否监测项目 为 el-col-8、监测数值 为 el-col-16 且同行，装备名称占位符正确。scrollHeight=1130、clientHeight=403，可独立滚动；底部已选设备与按钮位置固定；选中两台设备后可通过 el-tag 关闭图标删除其一。xxx–001/A–0920–001 打开修改弹窗，字段完整，保存返回“保存成功”，弹窗 display:none 且实际不可见。CANCELLED，销项理由/销项人/销项时间均正确写回；临时记录已从 LX.T_FAULT 清理。overview 返回工程总数 17、重大故障 4、涉H 5、监测项目 17、未完工 2、已完工 6、完工待试验 1、销项 0；top-equipment、by-team、contractors、yearly-trend 均返回 code=200，关键指标与重构前一致。T_FAULT、T_WORK_ORDER、T_COMPLETION_INFO 全表加载到 JVM；CONSUMABLE_COUNT 历史回填核验为 6 条完工信息、缺失 0 条、数量合计 12。8082、后端 8091 及其完整进程树，两个端口当前均无监听；下次按 0.5 构建与重启命令 重新启动。http://localhost:8082，用 admin / admin123 登录。FaultReport.vueProductTreePicker.vueBusinessService.javaFaultController.javarequirement\决策表_待确认项.md 的 B/C 组；不需要重新做历史需求梳理。8082、后端 8091 均未运行。需要联调时先按 0.5 启动。ReportMapper + ReportMapper.xml + DTO 重构。B6=...、C10=... 等结论。apply_patch 在本机不可靠，已有约定是使用 Python io.open(...) 读改写，并验证替换生效。Start-Process / ProcessStartInfo，后台启动用 WScript.Shell。LX，表名和字段名统一大写。SYS_DEPT、SYS_USER 通过 LX 同义词访问 CSICZB_ZB 下同名表。用户本次给出的 4 条新需求：① 系统管理增加“工程专业配置”（字段仅名称）；② 系统管理增加“T队专业配置”（字段名称、分类 A/B）；③ 故障编号不再手工输入，改为按 潜1基-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）。
- 分类取“T队专业配置”的 A/B；未配置或分类非法时保存报错并提示先行维护。
- YYMMDD 取上报日期；nnn 为“同一 X号 + 同一 T队专业 + 同一上报日期”的序号，从 001 起。
- 新建自动生成；修改时强制沿用原编号（改 T队专业/日期也不重新生成）。
- 生成使用 JVM 内锁 + LX.T_FAULT.FAULT_CODE 唯一索引兜底。
- 前端“故障编号”改为只读，新建时占位“保存后自动生成”；故障上报、修改弹窗、XCB助理审核的“T队专业 / 工程专业”下拉全部改为读取配置接口，删除前端硬编码数组。
- 派单号规则保持 故障编号/nn（BusinessService.dispatch），无需改动。
- 故障上报查询栏微调（2026-09-28 追加）：任务状态 标签与下拉框被折行拆开，已在标签前加 .filter-break 强制换行，二者同处新的一行；同时把该栏错别字 工程X号专业 修正为 工程专业。
- 顺带修复 emergency-web/src/utils/sensitive.js（实际路径 emergency-repair-web/src/utils/sensitive.js）：replaceAttributes 收到 MutationObserver 上报的注释节点时抛 root.querySelectorAll is not a function，已加节点类型守卫，动态渲染不再报错。
验证（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 清理。
- 浏览器：两个新配置页正常渲染；故障上报新增表单“故障编号”只读且占位“保存后自动生成”，T队专业/工程专业下拉为配置项；修复后控制台无新增报错。
- 历史演示故障仍使用 GZ-2026-0xx 旧编号（未迁移，避免影响已派工单引用）；新建故障一律使用新规则。
- 文档已同步：requirement\决策表_待确认项.md、前44页需求梳理.md、工程状态机设计.md、界面还原.html，以及首页公告“派单规则”文案。
用户提出的 4 条调整：
1. 把“修后质量情况”移入“基础信息”，占 1 整行（el-col :span="24"，textarea）。
2. 把“项目名称”移到“验收方式”同一行（各 el-col :span="8"）；“故障说明”“原因分析”各自独占 1 整行（el-col :span="24"，textarea，与“修后质量情况”一致）。
3. “处理解决情况”改为与“维修器材”相同的多行表格（可“添加一行”/删除），列＝序号（自动）、处理解决情况。
4. “维修器材 / 元器件消耗情况”列改为：序号、名称、规格型号、技术参数、数量、计量单位、合格证明、出库单号、来源、备注（另加“操作”删除列）。
实现要点：
- 前端 emergency-repair-web/src/views/completion/CompletionReport.vue：基础信息新增 4 个字段；“修理情况”section 改为独立的“处理解决情况”section（表格式，form.solutions）；器材表按新列序重排，新增 certificate（合格证明）。
- 后端 Requests.MaterialItem 增加 certificate 字段；Requests.CompletionRequest 增加 solutions 列表（SolutionItem { content }），保留原 solution 字段兼容旧调用。
- LX.T_COMPLETION_INFO 新增 SOLUTIONS_JSON CLOB（DatabaseBootstrap.ensureColumn 幂等迁移，同时加入建表 DDL）；CompletionInfo 增加 solutionsJson。
- BusinessService.submitCompletion：把 solutions 序列化为 SOLUTIONS_JSON，并把各行以“；”连接写回原 SOLUTION 列（长度上限 2000），保证旧字段仍可读。器材清单（含合格证明）继续存 CONSUMABLES_JSON。
- 演示数据同步：DataInitializer 的完工样例改为 2 行处理解决情况，器材样例补 certificate。
验证（2026-09-28）：
- mvn -q -DskipTests package 通过；前端 vue-cli-service build 通过。
- DM8 已确认 T_COMPLETION_INFO.SOLUTIONS_JSON 列存在。
- 端到端：临时走完“故障上报→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，含需求文档）。
dist/sensitive-words.json 中 real_name，不重新打包。/01 开始；同一故障的多个承修单位依次为 /01、/02 等。例：故障编号 F001 有两个承修单位时生成 F001/01、F001/02。MyProject\trafficAudit；数据库 DM8 127.0.0.1:5236，账号/密码 SYSDBA/SYSDBA，大小写敏感；表名和字段名统一使用大写；临抢修模式 LX 需要新建；SYS_DEPT、SYS_USER 通过同义词访问 CSICZB_ZB 模式下的同名表。emergency-repair-server，前端 emergency-repair-web。8091；启动命令：mvn -q spring-boot:run。8082；启动命令：npm run serve，生产构建命令：npm run build。admin / admin123（第一版暂不启用角色拦截）。emergency-repair-web/public/sensitive-words.json；正常构建后部署，部署到生产环境后再修改生产环境 dist/sensitive-words.json 的 real_name，前端运行时读取并替换页面文本。http://localhost:8082。界面还原.html、前44页需求梳理.md、决策表_待确认项.md、工程状态机设计.md、敏感词字典.md/.json。连带口径变更：① 取消艇长审批环节（原待确认清单第 9 条 → 已解决：不纳入第一版）；② 取消全部离线能力（单机版/离线填写、数据包导入导出）；③ 取消“XCB助理完工处理/导出完工项目”环节；④ 报价处理移出主流程；⑤ JCC助理审批确认为必经环节。
requirement\界面还原.html（新增全局口径条 + AXU1 卡片重写 + AXU2/AXU13 受影响标注）、requirement\前44页需求梳理.md（第 2 节业务总览、3.3 流程总览、4.1/6.2/6.3/第 7 节标注、第 9 节新增 14–17 条、术语表）、requirement\工程状态机设计.md（审批顺序、任务状态机、流转表/矩阵、新增待确认 11–12）、requirement\决策表_待确认项.md（全局口径、AXU1 行已核对、C-8 已解决、新增 C-12–C-15）。2026-09-14 用户答复（已回填全部文档）：
- ① 艇长环节不纳入第一版（确认）；② 报价处理移出主流程，“报价管理”菜单与模块整体不做（C-14 已解决）；③ JCC 助理审批为必经环节（确认）；④ C-12 离线/数据包相关功能**整体取消，对应菜单项一并删除**（数据包导入、完工信息导入、导出待完工数据包、报价导出/导入）；⑤ AXU2 数据包导入：只做网络版、无导入功能，**无需核对**（页面与菜单项删除）。
- 已解决：**C-13 派单口径**（2026-09-16 确认）——XCB助理审核仍负责分配承修单位、拆单、生成工程单号；后续派单页按故障选择、按承修单位生成派工单，不再重新分配承修单位或修改厂家。剩余：B 组工程状态机 10 项；A 组下一步 AXU5 CMB领导审批。（C-15 术语已于 2026-09-14 答复：统一写“T员验收”）
- 后续进展：A 组已于 2026-09-16 完成 AXU3/AXU4，下一步为 AXU5 CMB领导审批（AXU0/AXU1/AXU15 已完成，AXU2 免核对）。
requirement\界面还原.html 的 AXU0 卡片），并落实用户三项全局口径（见下）。requirement\敏感词字典.md/.json 新增 TD=艇队（现 7 词条：X号/JC/JCC/CMB/T/TD/XCB）；requirement\决策表_待确认项.md C-7 标记【已解决】、C-9 补充 X号当前状态取值、A 组 AXU0 行已核对。无临时文件残留。项目目录说明：C:\Users\jcxiong\Documents\Codex 与 D:\Codex 为同一物理目录（junction），本会话 cwd 为 D:\Codex\MyProject\EmergencyRepair，无需同步。
临抢修软件开发项目，原始需求在 requirement\原始需求.docx（共 114 页）。
_extract\AXU0.png ~ AXU16.png）。.ocrvenv）提取全部截图文字，做了两轮（原图 + 放大分块）交叉校验，结果一致。OCR 文本在 _extract\ocr\*.txt 与 _extract\ocr2\*.txt。requirement\前44页需求梳理.md（按业务分组：门户/审批链/工程管理/完工/验收/查询/报价/基础信息/技术文件，模糊处标【待确认】）。requirement\界面还原.html（17 张截图逐张文字还原，黄色高亮=待确认/OCR疑误；顶部有 AXUnn↔菜单名↔文档页对照表）。**用户核对状态：AXU15 已完成（2026-08-26），AXU0 已完成（2026-09-09/10），AXU1 已完成（2026-09-11），AXU2 免核对（已取消 2026-09-14），AXU3/AXU4 已完成（2026-09-16），AXU5/6/7 已完成（2026-09-17），AXU8 暂缓（2026-09-20），AXU10/AXU14 已确认（2026-09-20）；系统管理菜单已确认（2026-09-20）；AXU9、AXU11–AXU13、AXU16 暂不处理并移出当前需求；仅保留 AXU15 遗留项。**requirement\工程状态机设计.md（任务状态机 + 工程状态机 + 操作/角色矩阵 + 首页卡片映射，含 10 项新增待确认）。requirement\敏感词字典.md（+requirement\敏感词字典.json），按最小词根维护（X号/JC/JCC/CMB/T）；正常构建部署后，在生产环境修改已部署的 dist/sensitive-words.json。trafficAudit；数据库仅 DM8；完成 requirement\技术路线.md，记录连接参数、大小写敏感约束、表名/字段名全大写规范、LX 新模式及 CSICZB_ZB 同义词访问规则。| 截图 | 菜单名 | 文档页 | 截图 | 菜单名 | 文档页 |
|---|---|---|---|---|---|
| AXU0 | 首页门户 | 5 | AXU9 | CMB领导已阅 | 15 |
| AXU1 | 流程总览 | 6 | AXU10 | 派单管理 | 16 |
| AXU2 | 数据包导入（已取消 09-14） | 8 | AXU11 | 已派工程 | 17 |
| AXU3 | 故障上报 | 9 | AXU12 | 已派工程单 | 18 |
| AXU4 | XCB助理审核 | 10 | AXU13 | 工程单打印输出 | 19 |
| AXU5 | CMB领导审批 | 11 | AXU14 | 完工情况处理 | 20 |
| AXU6 | JCC助理审批 | 12 | AXU15 | 完工信息上报 | 23 |
| AXU7 | JCC处长审批 | 13 | AXU16 | 技术文件管理 | 44 |
| AXU8 | 临抢修工程管理·总览 | 14 |
【2026-09-11 确认，2026-09-16/20 更新】第一版简化流程（只做网络版）：T员故障上报 → XCB助理审核（分配承修单位、拆单、生成工程单号）→ CMB领导审批 → JCC助理审批 → JCC处长审批 → XCB助理派单（显示未派单故障，勾选后一键派单，按承修单位生成派工单）→ 厂家线下修理（系统外）→ 厂家上报完工信息 → 完工验收流程（验收申请 → 质检员验收 → 质检负责人验收 → 完工验收打印输出 → 修后质量评级）→ 验收完成。
当前纳入模块：XCB助理派单（AXU10）→ 完工情况处理（AXU14）→ 完工信息上报（AXU15）→ 完工验收（验收申请 → 质检员验收 → 质检负责人验收 → 完工验收打印输出 → 修后质量评级）→ 系统管理 → 统计报表。原临抢修工程管理中的 CMB领导已阅（AXU9）、已派工程（AXU11）、已派工程单（AXU12）、工程单打印输出（AXU13）以及技术文件管理（AXU16）暂不处理；监测信息、查询、基础信息和技术文件管理不再主动展开，除非用户后续补充需求。
原始需求流程（存档，已不采用）：故障上报（数据包导入）→ 艇长（批量/单项）→ 大队助理（XCB）审批 → CMB领导审批 → JCC助理审批 → JCC处长审批 → …… → 完工信息上报 → 验收；含单机版/离线数据包与报价导出导入环节。
关键规则（来自截图备注）：
- 派单规则（2026-09-20 确认）：JCC处长审批完成后进入XCB助理派单页面，显示“未派单”的故障一览；勾选一个或多个故障后点击“一键派单”，系统按每个故障的承修单位生成派工单。一个故障有多个承修单位时，每个承修单位各生成一张派工单。
- 派工单编号（2026-09-20 确认）：故障编号 + “/” + 两位序号，从 /01 开始；同一故障的多个承修单位依次为 /01、/02 等。例：故障编号 F001 有两个承修单位时生成 F001/01、F001/02。故障编号由T队在故障上报时人工填写。原截图“固定-X号/班组类别-YYMMDD-厂家代号”不再作为派工单编号口径。
- 派单页按钮（2026-09-20 确认）：除“一键派单”外，原截图中的修改、生成临修工程单、删除亚复（疑为清除重复）等业务按钮暂不需要。
- AXU14 完工处理（2026-09-20 确认）：派单后进入本页；每一行=1个派工单且只允许勾选1行；完工状态固定为“未完工（默认）/待备件/完工待试验/完工”；去掉导出、添加进度备注、销项；T员评分把修后质量评分和意见写回所选派工单；“完工”按钮跳转 AXU15，成功提交后回写状态“完工”。
- 工程单号：固定-X号/班组类别-YYMMDD-厂家代号/序号（YYMMDD 为上报日期），用于领器材；XCB助理审核完成后即可领器材。工程单号在XCB助理审核环节生成，派单时不再重新分配承修单位或修改厂家。
- XCB助理审核可分配多个承修单位，审核后按承修单位拆分工程单并生成工程单号；派单页按故障选择、按承修单位生成派工单。
- 完工信息上报与状态回写（2026-09-20 确认）：从 AXU14 选中派工单并点击“完工”进入 AXU15；AXU15 成功提交后，关联派工单完工状态写为“完工”。第一版只做网络版，取消“导出工程单→单机填写→导入”离线路径。
- 报价链（已废止）：原为 导出待报价项目 → 单机填写/导入报价信息 → 修船办助理审价 → JCC 审价；2026-09-14 已确认报价管理整体不做。
dist/sensitive-words.json 中 real_name，不重新打包；前端启动时读取并替换页面文本。需求/设计文档与代码一律只写代称。已确认：X号=舷号、JC=舰船、JCC=舰船处、CMB=参谋部、T=艇（详见 requirement\敏感词字典.md）。MyProject\trafficAudit。数据库仅开发**达梦8（DM8）**版本，不开发 MySQL；连接地址 127.0.0.1:5236，用户名 SYSDBA，密码 SYSDBA，数据库大小写敏感，表名和字段名统一使用大写。临抢修业务模式为 LX，需要新建；SYS_DEPT 和 SYS_USER 使用 CSICZB_ZB 模式下的同名表，通过同义词访问。完整记录见 requirement\技术路线.md。requirement\敏感词字典.md 与 .json 已同步（词条持续追加）。AXU3 故障上报（2026-09-16 用户确认）：字段、按钮通读通过；列表表头增加“上报日期”“上报单位”；任务状态统一采用七个值：未上报 / 已上报XCB / 上级打回 / XCB助理审核完成 / CMB领导审批完成 / JCC助理审批完成 / JCC处长已阅；故障影响、故障性质均为可配置字典字段，示例值分别为“供气”“重大”，其他值待补；“填写故障分析报告”第一版暂不实现。新增改为表单式，默认带出登录用户所属单位、所属专业、本人和当前日期；T队专业、工程专业、故障影响、故障性质为下拉；点击“装备名称”打开产品结构树，选择后自动填入“装备名称”和“所属上级系统”；停泊地字段不保留。H 已纳入敏感词字典，字段统一写“是否涉H”。删除限制：未上报故障可以删除，已上报故障不能删除，任务状态为“上级打回”时除外。
/01、/02 等两位序号”；原截图的固定复合编号口径不再采用。/01、/02 等两位序号。除“一键派单”外，原截图其他业务按钮暂不需要。故障编号由T队在上报故障时人工填写，故障信息增加“故障编号”字段。ReportMapper + ReportMapper.xml + DTO，采用 DM8 手写聚合 SQL，已移除 overviewReport、topEquipment、byTeamReport、contractorReport、yearlyTrend 的整表加载和 Java 内存聚合，并补上完工消耗计数及关联索引。普通单表筛选、CRUD 继续使用 MyBatis-Plus BaseMapper + LambdaQueryWrapper；后续新增复杂查询按同样边界处理。requirement\原始需求.docx — 原始需求文档（114 页）requirement\前44页需求梳理.md — 需求清单（主要交付物）requirement\界面还原.html — 截图文字还原（用户核对用）requirement\工程状态机设计.md — 工程状态机设计草案（2026-08-25 新增，待确认）_extract\AXU0~16.png — 解出的界面截图_extract\ocr\、_extract\ocr2\ — 两轮 OCR 文本_extract\slices\、_extract\slices2\、_extract\zoom\ — 截图切片.ocrvenv\ — OCR 环境（rapidocr_onnxruntime）requirement\技术路线.md — 前端、后端、DM8、同义词和模式约束requirement\敏感词字典.md（+.json） — 保密代称字典（md 说明 + 可配置 JSON 样例）HANDOFF.md — 本交接文件（项目根，关机前更新会话记录）C:\Users\jcxiong\.codex\AGENTS.md 第 8 节）；一律用 .ocrvenv 本地 OCR 提取文字。apply_patch 在本机 100% 失败（Windows Store Codex ACL），改文件一律用 Python：io.open(path, encoding='utf-8') 读取 → str.replace(old, new, 1) → 写入 newline=''，并验证替换生效。Start-Process/ProcessStartInfo（Path/PATH 重复键错误）；后台进程用 WScript.Shell。C:\Users\jcxiong\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe。requirement\敏感词字典.md），禁止在非密材料出现真实名称。故障编号/01、/02 编号落地；故障编号由T队人工填写，故障信息增加对应字段。requirement\工程状态机设计.md 第 4 节 + 决策表 B 组），答完固化为正式设计。ReportMapper + ReportMapper.xml + DTO 和手写聚合 SQL；普通故障列表仍保留 MyBatis-Plus Wrapper，后续只对确实复杂的查询扩展 Report Mapper。C:\Users\jcxiong\Documents\Codex 是指向 D:\Codex 的 junction，两个路径实为同一物理目录，无需同步（已记入顶层 AGENTS.md 第 0 节）。requirement\）：需求清单、界面还原.html、工程状态机设计.md、敏感词字典.md/.json；本交接文件 HANDOFF.md 位于项目根。无进行中的未保存工作。界面还原.html（AXU15 已完成，剩余 AXU0–14/16）。工程状态机设计.md 第 4 节 10 项新增待确认。requirement\界面还原.html、requirement\前44页需求梳理.md、requirement\工程状态机设计.md、requirement\决策表_待确认项.md、requirement\敏感词字典.md + 本文件；无临时文件残留（已核验），无进行中的未保存工作。requirement\敏感词字典.md。.ocrvenv 本地 OCR）；apply_patch 在本机 100% 失败，改文件一律用 Python 读改写并验证；后台进程用 WScript.Shell；Python 用 codex-runtimes\...\python.exe。HANDOFF.md、requirement\界面还原.html、requirement\前44页需求梳理.md、requirement\工程状态机设计.md、requirement\决策表_待确认项.md、requirement\敏感词字典.md/.json。已检查敏感词 JSON 可解析、无临时文件残留。HANDOFF.md、界面还原.html、前44页需求梳理.md、工程状态机设计.md、决策表_待确认项.md 均已保存；无临时文件残留，无未保存的进行中工作。/01、/02 等。UNREPORTED / REPORTED_XCB / RETURNED，销项仅支持 REPORTED_XCB / RETURNED，销项后状态为 CANCELLED 并写回理由、操作人和时间。