feat: 完善设计报工、质检及齐套跟踪

gptlog-process/gpdlog.md

@@ -3186,3 +3186,259 @@ pm run build：通过，仅有既有警告。
 
 ### 结论
 - 当前工作区内的设计工时报表导出、产品合格率工位菜单迁移、旧菜单脚本修正和对应中文日志已全部提交并上传到远程。
+- 功能提交号为 `0784746`。
+
+### 验证结果
+- `git diff --check` 通过。
+- `git diff --cached --check` 通过。
+- 凭据特征扫描结果为 0。
+- 上传前本地与远端分叉为 `0 0`。
+- 推送后本地与远端同步，工作区无未提交修改。
+
+## 2026-07-15 设计报工限制、重复报工及多类说明功能
+
+### 用户提问
+- 修改 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`：一个人不能同时开始多个任务，点击开始时提示哪个任务未关闭。
+- 任务点击完成后仍允许再次开始和结束，第二次开始、结束后也可以再次完成。
+- 增加“异常说明”和“奇思妙想”功能，允许随时多次录入文字；列表按“时间换行内容”的格式显示，多次录入显示多条。
+- “进度说明”采用与异常说明相同的列表显示格式。
+- 将“未结束人员”改名为“设计正在对应”。
+- 在设计任务页面同时显示异常说明、奇思妙想、进度说明和设计正在对应字段。
+
+### 执行过程
+1. 读取仓库根目录 `AGENTS.md`，确认本次执行结束后必须将提问、结论和完整执行过程以中文追加到 `gptlog-process/gpdlog.md`。
+2. 检查目标报工页、设计任务页、校验页、工时报表页、相关 SQL 增量脚本、项目命令和 Git 工作区状态。
+3. 确认报工页原有逻辑只校验当前行的 `当前用户未结束报工数`，无法可靠阻止同一人员跨任务同时开始；前后端还把“已完成”作为禁止重新开始的终态。
+4. 确认原有结束弹窗已经可以录入进度说明，数据库报工记录也已有对应字段，但任务查询和两个任务列表尚未聚合显示进度历史。
+5. 确认异常说明和奇思妙想没有独立数据表及保存过程，不能仅靠前端完成持久化和多条历史展示，因此确定增加幂等数据库增量脚本。
+6. 检查工作区已有改动，发现设计任务页存在用户未提交的表单布局调整，质量检验页面也存在无关修改；本次保留所有已有改动，只在设计任务页追加所需列表字段，并对该页原有布局改动做必要的空格格式整理。
+7. 修改报工页列表：
+   - 将“未结束人员”列标题改为“设计正在对应”，继续使用原有 `未结束报工人员` 返回字段。
+   - 新增进度说明、异常说明和奇思妙想三列。
+   - 三列使用保留换行的样式展示历史内容。
+8. 修改报工页操作区：
+   - “开始”按钮不再因任务已完成而禁用。
+   - 新增“异常说明”和“奇思妙想”两个文字按钮。
+   - 新增通用说明录入弹窗，显示 DID 和任务描述，内容必填，最多 2000 字。
+   - 保存时调用新增存储过程，并携带当前操作人 ID 和姓名。
+9. 增加开始前全任务实时查询：如果当前人员已有任何未结束记录，提示“任务 DID + 任务描述尚未关闭，请先结束该任务”；查询失败时阻止开始，避免绕过校验。
+10. 保留结束按钮仅在当前任务存在本人未结束记录时启用；已完成任务重新开始后状态变为执行中，结束后变为已结束，因此可以再次点击完成。
+11. 修改设计任务页列表，新增“设计正在对应”、进度说明、异常说明和奇思妙想四列，展示格式与报工页一致。
+12. 新增 `db_backups/update_design_report_task_notes_and_restart_20260715.sql`：
+   - 幂等补齐报工记录的进度说明字段。
+   - 新建 `MES_设计报工_任务说明` 表，保存异常说明和奇思妙想的多条记录、操作人及录入时间。
+   - 新建 `设计报工_任务说明_新增` 保存过程，校验任务、说明类型和非空内容。
+   - 重建 `设计报工_任务_查询`，聚合进度说明、异常说明和奇思妙想，单条格式为“时间 + 换行 + 内容”，多条之间留空行。
+   - 重建设计报工开始过程，取消已完成任务禁止开始的限制。
+   - 开始过程使用按人员标识生成的 `sp_getapplock` 事务锁，防止两个页面并发点击时同时产生两条未结束记录。
+   - 开始过程跨全部任务检查当前人员的未结束记录，返回未关闭 DID 和任务描述。
+   - 重建设计报工结束过程，允许重新开始后的任务结束，并按现有方式保存本轮进度说明。
+13. 首次执行两目标页面 ESLint 时，报工页无错误；设计任务页报告用户原有布局调整中的多余空格、空行和异步箭头函数格式问题。
+14. 对设计任务页做最小格式整理后，再次执行两目标页面 ESLint，检查通过；仅输出项目依赖的 Browserslist 和 Baseline 数据过期提示。
+15. 对三个目标文件执行 `git diff --check`，检查通过；全工作区检查仍能看到无关的 `OtherInbound.vue` 原有尾随空格，本次没有修改该文件。
+16. 执行 `npm run build`，webpack 生产构建成功；仅有项目原有的大资源体积警告和浏览器兼容数据过期提示，构建没有留下受版本控制的 `dist` 改动。
+17. 尝试使用当前 Windows 集成身份对目标数据库 `192.168.2.92 / YL_MESDB` 做只读连通性检查，服务器拒绝 Guest 身份登录；未猜测或查找数据库凭据，也未向目标数据库发布脚本。
+18. 检查本地开发服务，确认进程来自当前仓库，访问 `https://localhost:1997/` 返回 HTTP 200。
+19. 为验证 SQL，在独立 LocalDB 测试实例中创建最小基础表。前两次使用 PowerShell 标准输入传递中文 SQL 时发生代码页解析错误，均未进入增量脚本有效验证；每次都在 `finally` 中删除测试实例，随后核对并清理由第一次测试生成的 MDF/LDF 文件。
+20. 改用 UTF-8 SQL 测试夹具和 `sqlcmd -i -f 65001` 重跑隔离测试，增量脚本编译及业务场景验证通过：
+   - 状态为已完成的任务可以重新开始。
+   - 同一人员未结束第一项任务时开始第二项任务，被正确拦截并返回第一项任务的 DID 和描述。
+   - 第一项任务可以正常结束并保存进度说明，状态回到已结束。
+   - 连续保存两条异常说明和一条奇思妙想均成功。
+   - 任务查询按要求返回进度说明、两条异常说明和奇思妙想的“时间换行内容”历史。
+21. 验证结束后删除临时 SQL 测试夹具、LocalDB 实例及测试数据文件，确认不保留测试数据。
+22. 最终检查目标文件状态和差异，确认未修改用户无关的质量检验页面，未提交或推送任何文件。
+
+### 修改文件
+- `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
+- `src/views/ProductionManagement/DesignReportTask/Task/index.vue`
+- `db_backups/update_design_report_task_notes_and_restart_20260715.sql`
+- `gptlog-process/gpdlog.md`
+
+### 结论
+- 同一人员只能保留一个未结束的设计报工任务，前端会提示具体未关闭任务，数据库事务锁同时保证并发场景不会绕过限制。
+- 已完成任务可以重新开始、结束，并在新一轮结束后再次完成。
+- 异常说明和奇思妙想支持在任意任务状态下多次录入；进度说明、异常说明和奇思妙想均按“时间换行内容”显示多条历史。
+- 报工页和设计任务页都已显示进度说明、异常说明、奇思妙想和“设计正在对应”。
+- 前端代码和数据库增量脚本均已在本机验证；由于当前身份没有目标 SQL Server 登录权限，增量脚本尚未发布到目标数据库，目标环境启用新功能前必须执行该脚本。
+
+### 验证结果
+- 两目标页面 ESLint 检查通过。
+- 三个目标文件 `git diff --check` 通过。
+- `npm run build` 生产构建通过。
+- 隔离 LocalDB 中增量脚本编译通过，重新开始、跨任务拦截、结束及多条说明聚合场景验证通过。
+- `https://localhost:1997/` 返回 HTTP 200，本地开发服务保持运行。
+
+## 2026-07-15 发布设计报工增量脚本到目标数据库
+
+### 用户提问
+- 用户提供目标数据库地址 `192.168.2.92`、数据库管理员账号及密码，要求继续完成数据库发布。
+- 按安全要求，本日志不记录数据库明文密码。
+
+### 执行过程
+1. 使用用户提供的 SQL Server 凭据连接 `192.168.2.92 / YL_MESDB`，先执行只读预检。
+2. 预检确认目标数据库为 `YL_MESDB`，服务器为 `YLLT-MES`，数据库兼容级别为 150。
+3. 确认 `MES_设计报工_任务`、`MES_设计报工_记录` 和记录表的 `进度说明` 字段已经存在；`MES_设计报工_任务说明` 表和 `设计报工_任务说明_新增` 过程尚不存在。
+4. 确认设计报工查询、开始、结束、完成过程均存在，其中查询和开始过程仍为本次修改前的旧版本。
+5. 使用 `sqlcmd` 的失败即退出模式和 UTF-8 输入模式执行 `db_backups/update_design_report_task_notes_and_restart_20260715.sql`，脚本发布成功。
+6. 发布后检查数据库对象定义，确认：
+   - 任务说明表已创建。
+   - 任务说明保存过程已创建。
+   - 开始过程已包含 `sp_getapplock` 人员并发锁。
+   - 查询过程已包含异常说明、奇思妙想和进度说明聚合。
+   - 开始过程已移除“任务已完成，不能开始”的旧限制。
+7. 在目标数据库外层事务中插入两条临时设计任务，执行完整业务验证：
+   - 状态为已完成的第一条任务开始成功。
+   - 同一测试人员在第一条任务未结束时开始第二条任务，被正确拦截，返回第一条任务 DID 和任务描述。
+   - 第一条任务结束成功并保存第一轮进度，随后完成成功。
+   - 第一条任务第二次开始、结束并保存第二轮进度，随后再次完成成功。
+   - 连续新增两条异常说明和一条奇思妙想，三次保存均成功。
+   - 任务查询返回两次报工记录、最终已完成状态、两轮进度说明、两条异常说明和一条奇思妙想；显示内容符合“时间换行内容”的多条格式。
+8. 回滚外层测试事务，并查询确认名称以 `Codex发布验证_` 开头的测试任务数量为 0，没有向正式库遗留测试任务、报工记录或说明记录。
+9. 检查本地工作区，数据库发布没有生成新的临时文件或构建产物；保留用户原有的无关工作区修改。
+
+### 结论
+- `update_design_report_task_notes_and_restart_20260715.sql` 已成功发布到 `192.168.2.92 / YL_MESDB`。
+- 同一人员跨任务同时开始限制、未关闭任务提示、已完成任务重新开始和再次完成、进度说明历史、异常说明及奇思妙想多条录入功能均已在目标数据库验证通过。
+- 验证数据已全部回滚，正式数据库无测试数据残留。
+
+### 验证结果
+- 数据库对象和过程定义检查通过。
+- 两轮“开始、结束、完成”验证通过。
+- 跨任务重复开始拦截验证通过。
+- 多条进度、异常说明和奇思妙想聚合验证通过。
+- 回滚后测试任务数量为 0。
+
+## 2026-07-15 设计报工按钮、说明悬停及任务可见范围调整
+
+### 用户提问
+- 设计报工点击开始后，当前任务的开始按钮应变为灰色且不可点击。
+- 进度说明、异常说明和奇思妙想在列表正常显示时应单行省略，避免撑高行高；鼠标悬停对应字段时显示完整内容。
+- 设计任务新建弹窗需在指派对象前增加“对齐可见”字段，并使用与指派对象相同的人员多选方式。
+- 设计报工页面根据登录账号限制任务范围，只显示本人创建、对齐可见包含本人以及指派对象包含本人的任务。
+
+### 执行过程
+1. 重新检查报工页和设计任务页现有模板、数据模型、人员查询、任务新增/编辑参数及目标数据库过程结构。
+2. 检查登录流程和 Vuex 用户状态，确认登录态 `id` 来源于 `Personnel_Number`，与设计任务人员选择器使用的 `人员编号`一致，可以直接用于对齐可见和指派对象精确匹配。
+3. 调整设计报工开始按钮：
+   - 恢复 `canStart` 行级判断。
+   - 当前行 `当前用户未结束报工数` 大于 0 时开始按钮禁用并显示为灰色。
+   - 其他任务的开始按钮仍可点击，继续保留提示具体未关闭任务的逻辑。
+4. 调整报工页和设计任务页的三类说明展示：
+   - 进度说明、异常说明和奇思妙想正常状态使用单行、溢出隐藏和省略号，不再撑高表格行。
+   - 每个字段外层增加 Element UI Tooltip，非空内容悬停时显示完整历史。
+   - Tooltip 内容保留原有换行，设置最大宽度、最大高度、自动纵向滚动和长文本换行。
+5. 在设计任务列表增加“对齐可见”列，便于维护人员直接确认任务可见范围。
+6. 在设计任务新增/编辑弹窗的“指派对象”之前增加“对齐可见”多选人员字段：
+   - 使用独立的远程人员选项集合，避免与指派对象搜索互相覆盖。
+   - 保存人员编号列表到 `对齐可见ID`，保存人员姓名列表到 `对齐可见`。
+   - 编辑时还原已选人员，并补齐当前远程列表中不存在的已选项。
+   - 每次打开新建弹窗时刷新对齐可见人员列表。
+7. 扩展数据库增量脚本：
+   - 幂等增加任务表 `对齐可见ID` 和 `对齐可见` 两个字段。
+   - 查询过程返回两个新字段。
+   - 重建任务新增和编辑过程，支持保存及修改对齐可见人员。
+   - 仅当查询传入当前登录人员时应用报工页可见范围；不传人员的设计任务维护页继续返回全部任务。
+8. 第一版可见范围按用户最初要求实现为“本人创建或对齐可见包含本人”。用户随后补充“指派对象的任务也可见”，立即终止正在进行的旧版本构建，避免把不完整版本作为最终验证结果。
+9. 将查询可见范围扩展为三种关系的并集：
+   - 当前人员姓名等于创建人。
+   - 当前人员编号或姓名存在于对齐可见列表。
+   - 当前人员编号或姓名存在于指派对象列表。
+10. 使用隔离 LocalDB 对第一版字段和查询规则进行验证：
+    - 不传当前人员时维护页返回全部三条任务。
+    - 创建人只能看到本人创建任务。
+    - 同时具有创建和对齐关系的人员返回两条任务。
+    - 仅对齐可见人员返回对应任务。
+    - 无任何关系人员返回 0 条。
+    - 编辑对齐可见后，新人员立即能查询到任务，并返回对齐可见字段。
+11. 用户补充指派对象规则后，再次使用隔离 LocalDB 验证：
+    - 指派对象列表包含当前人员时能返回对应任务。
+    - 无创建、对齐或指派关系的人员返回 0 条。
+12. 两次 LocalDB 验证均使用独立临时实例；验证后删除 SQL 测试夹具、实例及 MDF/LDF 文件，没有遗留测试资源。
+13. 执行两目标页面 ESLint，检查通过；仅输出项目依赖的 Browserslist 和 Baseline 数据过期提示。
+14. 对目标前端文件和数据库脚本执行 `git diff --check`，检查通过。
+15. 执行 `npm run build`；用户补充指派对象规则前的构建被主动终止，补齐最终规则后重新执行生产构建并成功通过，仅有项目原有的大资源体积及浏览器数据过期警告。
+16. 使用用户此前提供的数据库凭据，将扩展后的幂等脚本重新发布到 `192.168.2.92 / YL_MESDB`，发布成功；日志不记录明文密码。
+17. 在目标数据库检查确认：
+    - 两个对齐可见字段已经存在。
+    - 查询过程包含指派对象可见逻辑。
+    - 新增和编辑过程均包含对齐可见参数。
+18. 在目标数据库外层事务中执行正式环境验证：
+    - 本人创建任务查询返回 1 条。
+    - 对齐可见任务查询返回 1 条。
+    - 指派对象任务查询返回 1 条。
+    - 无关系人员查询返回 0 条。
+    - 不传人员的设计任务维护查询仍返回指定任务。
+19. 回滚目标数据库测试事务，确认 `Codex可见验证_` 测试任务残留数量为 0。
+20. 最终再次执行 ESLint、生产构建、目标文件空白检查和本地开发服务访问检查，全部通过；`https://localhost:1997/` 返回 HTTP 200。
+
+### 修改文件
+- `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
+- `src/views/ProductionManagement/DesignReportTask/Task/index.vue`
+- `db_backups/update_design_report_task_notes_and_restart_20260715.sql`
+- `gptlog-process/gpdlog.md`
+
+### 结论
+- 当前人员开始任务后，该任务行的开始按钮会立即在刷新后变灰并不可点击；其他任务仍可点击并提示未关闭任务。
+- 三类说明列表保持单行省略，悬停可查看保留换行的完整内容，不再导致表格行高过高。
+- 设计任务新增和编辑弹窗已支持“对齐可见”人员多选，并在列表显示选中人员。
+- 设计报工页面只显示本人创建、对齐可见包含本人或指派对象包含本人的任务；设计任务维护页仍显示全部任务。
+- 数据库字段和过程已发布到目标库，正式环境事务验证通过且无测试数据残留。
+
+### 验证结果
+- 两目标页面 ESLint 检查通过。
+- 目标文件 `git diff --check` 通过。
+- 最终 `npm run build` 生产构建通过。
+- 隔离 LocalDB 的新增、编辑、创建人可见、对齐可见和指派可见场景通过。
+- 目标数据库三类可见关系及维护页全量查询验证通过。
+- 目标数据库回滚后测试任务数量为 0。
+- `https://localhost:1997/` 返回 HTTP 200。
+
+## 2026-07-15 修复及时齐套生产订单 7912 工艺路线颜色
+
+### 用户提问
+- 修改 `PlanManagement/TimelyKitTrackingResult/index`。
+- 搜索销售订单 `261079` 后展开子项，生产订单 `7912` 的工艺路线状态不正确。
+- 第 4 序已经完成 5 个，应显示蓝色；第 5 序已经发料，应显示绿色。
+- 要求参考“生产计划跟踪”页面搜索生产订单 `7912` 时的工艺路线。
+
+### 执行过程
+1. 检查 `src/views/PlanManagement/TimelyKitTrackingResult/index.vue`、参考页面 `src/views/ProductionManagement/ProductionPlanTrack/index.vue`、及时齐套查询脚本和原项目验收文档。
+2. 对比两页的工艺路线前端算法，确认蓝色、绿色、红色判断和连续外协分组处理逻辑完全一致：
+   - 收检合格数大于 0、报工或辅助结束显示蓝色。
+   - 外协工序收料数大于收检合格数与不合格数之和时显示绿色。
+   - 连续且 `外协分组` 相同的工序统一采用该组最后一道工序的颜色。
+3. 确认及时齐套页面不直接计算数据库状态，而是解析 `生产管理_及时齐套跟踪结果_查询` 返回的 `工艺路线明细` JSON 后着色。
+4. 查询目标数据库过程参数和生产订单 `7912` 的 `View_生产订单_MES` 原始工序数据。首次查询误用了视图不存在的 `开始时间` 字段而失败，删除该字段后重新查询成功。
+5. 原始数据确认：
+   - 第 4 序数铣，计划数 5、完成数 5、收料数 5、收检合格数 5，任务状态为已完成，应显示蓝色。
+   - 第 5 序调质，收料数 5、收检数 0、任务状态为已开工，应显示绿色。
+   - 第 6 序喷砂尚未开始，应显示红色。
+6. 执行参考过程 `生产管理_生产计划跟踪` 查询订单 `7912`，确认参考数据包含 `外协分组`：
+   - 第 2 至第 4 序的外协分组为空，属于同一连续组，跟随第 4 序显示蓝色。
+   - 第 5 序外协分组为 2，独立显示绿色。
+   - 第 6 序外协分组为 3，独立显示红色。
+7. 执行及时齐套查询过程查询销售订单 `261079`。首次命令同时使用了互斥的 `sqlcmd -W` 与 `-y` 选项而失败，修正选项后重新执行成功。
+8. 检查及时齐套对生产订单 `7912` 的实际返回 JSON，确认完成数、收料数、收检数均正确，但每道工序都缺少 `外协分组` 字段。
+9. 定位根因：前端把缺少分组字段的第 2 至第 6 序全部视为同一个连续外协组，最终全部跟随第 6 序显示红色；因此不是页面蓝绿基础判断错误，而是后端 JSON 字段缺失。
+10. 修改当前最新及时齐套过程脚本 `db_backups/update_timely_kit_tracking_result_multi_detail_orders_20260630.sql`，在 `工艺路线明细` JSON 中增加 `p2.[外协分组]`。
+11. 发布前执行差异和空白检查，确认脚本只增加一个返回字段，不改变筛选、缺件匹配或其他统计口径；目标库当前过程定义检查结果为确实缺少该字段。
+12. 使用用户此前提供的数据库凭据，将修改后的过程脚本发布到 `192.168.2.92 / YL_MESDB`；日志不记录明文密码。
+13. 发布后重新执行销售订单 `261079` 的及时齐套查询，从实际过程输出中提取生产订单 `7912` 的工艺路线 JSON，并按页面当前算法复算：
+   - 第 4 序数铣：外协第一组，收检合格 5，最终颜色为蓝色。
+   - 第 5 序调质：外协分组 2，收料 5、收检 0，最终颜色为绿色。
+   - 第 6 序喷砂：外协分组 3，未收料未收检，最终颜色为红色。
+14. 检查目标数据库过程定义，确认 `p2.[外协分组]` 已发布。
+15. 执行及时齐套页面 ESLint，检查无错误，仅保留页面原有 `v-html` 安全规则警告和项目依赖数据过期提示。
+16. 执行数据库脚本 `git diff --check`，检查通过；访问本地开发服务 `https://localhost:1997/` 返回 HTTP 200。
+17. 保留工作区中用户已有的设计报工和质量检验相关修改，本次未改动或回退这些无关文件。
+
+### 修改文件
+- `db_backups/update_timely_kit_tracking_result_multi_detail_orders_20260630.sql`
+- `gptlog-process/gpdlog.md`
+
+### 结论
+- `TimelyKitTrackingResult/index.vue` 的现有颜色算法与生产计划跟踪一致，无需重复修改前端算法。
+- 实际问题是及时齐套查询返回的工艺路线 JSON 漏掉 `外协分组`，导致多个不同外协组被错误合并并统一显示红色。
+- 字段已补齐并发布到目标数据库；销售订单 `261079`、生产订单 `7912` 现在第 4 序显示蓝色，第 5 序显示绿色，第 6 序显示红色，与生产计划跟踪一致。
+