工程质量管理 · 概要设计文档

文档版本：1.00 ｜ 最近核对日期：2026-11-10

1. 设计范围与依据

按20261104会签资料重新设计，旧质量模块文档、业务代码、接口和流程不构成本版约束。本文描述目标架构，未证明已实现；业务规则唯一正文见需求分析，字段与接口见详细设计，物理模型见数据库设计。平台公共能力仍按系统架构和公共规范复用。

本版处理十二项功能的工程归属、业务资料、逐问题闭环和流程协作。重点差异是消缺“批次归集、问题独立办理”、非阻塞接收、岗位资格、专项适用计划与统计，避免把原型重复界面当成重复业务系统。

2. 系统边界与公共复用

领域	责任边界
工程基础	提供线路、标段、物理工点、单位工程、分部工程及其关系；本模块只读引用，保存必要快照
组织与用户	提供组织ID、人员账号、启停状态；质量岗位责任配置只描述实际任职，不另造企业/账号
质量业务服务	校验工程归属、材料、节点字段、问题闭环、来源报告和统计口径
Warm-Flow	实例、当前任务、会签、退回、办理意见、历史与流程图；不再建质量专属待办中心
文件服务	统一OSS上传/元数据/预览下载；业务服务控制文件与单据关联及访问权限
通知/抄送	登记提交后发送非阻塞站内知会；能否直接满足“可查看”的服务契约须专项核查，不能仅以有抄送按钮判定满足
检测总站	S01明确后期对接，本期手工登记；未来接入须单独契约与验收
大屏	提供按线路/专项计划统计的查询/推送边界；外发需要接收接口、身份与统计口径（D09）

工程主数据采用平台PBS/CBS/WBS/OBS分离关系，不建“质量专用工程树”。无子单位/子分部模型时不以质量表补建，D06只影响子级能力。

后端沿平台Controller/Service/Mapper、BO/VO分层；前端Vue3、TypeScript、Element Plus。响应复用R、PageQuery/PageResult；ID沿用BigNumberSerializer及前端原值。数据库按可迁移类型设计，DM8为当前落地环境，厂商差异集中适配；不另建动态表单/低代码引擎。

3. 业务聚合与关系

聚合	唯一业务身份与主要职责
质量记录	一条验收、检测报告、处置、日常问题或事故为一记录；类型有明确字段结构和节点策略，不用任意JSON绕过校验
消缺批次	一次登记/导入形成的任务名称、分类、填报信息；只归集问题与进度，不独立生成第二个审批流程
消缺问题	每问题有自身工程组合、责任链、等级、分支、整改资料、流程实例及闭环状态；是实际办理单位
岗位责任配置	组织、工程范围、岗位与有效账号；提交时解析并校验，已发任务记录实际办理人，不随通讯录更新改写历史
专项适用计划	一线路十三类中的实际适用项、计划日期、前置要件文件、完成依据；完成统计按适用计划项去重
验收目录配置	对工程基础分部维护排序/备注，不维护工程身份

通用质量记录可共享存储公共字段，类型专有资料采用明确的联合类型/DTO。是否共表是实现选择，业务必须隔离类型；不能因共表放宽权限或允许跨类型改写。消缺问题的流程与状态不可藏在批次头部；批次总数、闭环数、进行中数为派生结果，不双写一套独立审批状态。

4. 核心流程与状态

4.1 验收与巡查

各业务具体岗位顺序见需求§4、§6，不复制第二套规则。流程编码按功能稳定命名：首件、分部、单位、项目、五类消缺、不合格台账、处置、日常问题、事故，共13种拟定定义；专项/竣工无审批，不建定义。项目流程是否启用由D01裁决。

定义代码（目标）	业务实例主体
quality_first_item / quality_sub_project / quality_unit_project	对应验收记录
quality_project_acceptance	项目验收记录，D01确定采用后启用
quality_defect_construction / quality_defect_operation_early / quality_defect_fire / quality_defect_initial_assessment / quality_defect_post_operation	每条消缺问题，绝非整个导入批次
quality_nc_ledger / quality_nc_disposal	检测报告记录/关联处置记录
quality_problem / quality_accident	一条日常问题/事故

批量提交逐条校验并启动问题实例，返回明确每条结果；批次草稿导入事务与逐问题流程提交事务分开。不得宣称一次多实例启动天然可跨资源原子回滚，实际事务参与能力须在平台SPI调用链核查。

4.2 状态分离

• 流程状态：由Warm-Flow返回，草稿/待办/退回/完成等不另造同名枚举。
• 整改结果：未整改、已整改待确认、已销项等由业务节点产生；最终枚举及完成依据按需求确定，不能仅看到施工提交就认定闭环。
• 等级调整：原等级、建议等级、运营确认结果；与整改状态独立。
• 检测结论：报告不合格不因审核完成变合格。
• 批次概况：按问题汇总，全部满足终审后显示全部闭环；部分完成仍显示实际数量。

有/无设计核实、有/无降级均在每问题实例内分流，避免一个头部布尔值控制全批不同问题。正式验收阶段字段受节点权限控制，退回只开放当前补正范围。完成后只读，历史任务与意见不可被普通编辑覆盖。

5. 页面与交互结构

保留需求十二项业务入口；不照搬原型多层弹窗与复制菜单。新建/编辑在业务台账，查看/办理进入固定表单工作台。消缺台账分“任务台账/问题清单总台账”，从批次查看问题；“办理”必须定位具体问题，批次提供问题选择和整体进度，不能把同一次点击含糊地当作全批办理。

标准台账使用查询卡→列表卡、左标题右工具栏；默认10条，固定关键识别列、右侧状态及操作列，次要列横向滚动。工作台复用FlowHeaderCard、FlowActionPanel、FlowTimeline，人员复用NextHandlerPicker/UserSelect，组织复用平台单位选择器，附件复用FileUpload。工程组件传递完整组合身份并由服务端反校验。视觉、响应式和焦点规则见界面规范，不复制到各业务页面另行维护。

岗位配置属于责任人员配置的必要支撑，建议放消缺责任配置/管理员入口，不新增独立主数据业务域；专项适用计划和要件维护放专项验收内，避免无依据增加顶层菜单。

6. 权限与可靠性

候选集=有效账号∩节点岗位任职∩工程范围∩操作权限；数据为空或加载异常拒绝放宽，不回退全部用户。前端隐藏动作不替代后端鉴权；知会用户仍受查询与工程权限控制。权限资源粒度与接口见详细设计，三段式权限保持前端、后端、菜单一致。

必要事务由业务服务集中负责：批次及问题草稿、单问题资料和流程推进、报告与来源关系、专项计划与成果关系。校验失败不能残留半条业务数据或假流程状态。通知送达失败不回滚已成功提交的业务，不设计未授权的短信/微信外发；实际失败恢复沿平台能力，不为理论并发新增锁、版本号或重试系统。

7. 依赖与实施顺序

1. 建立源资料字段、岗位、节点、权限和新契约；D01等裁决仅阻塞对应功能。
2. 核实工程基础实际API及子级范围、组织账号、节点资格和通知能力，落地责任配置。
3. 实施新数据模型、类型策略、标准模板预检、目录引用和无流程资料台账。
4. 按业务定义生成流程、实现节点资料与逐问题办理、专项统计及集成。
5. 定向自动化、接口与纳管读写、真实角色页面及流程链验证；用证据填测试与验收。

历史文件是否一次性迁移单列D07，不默认迁移、不维护旧API兼容。实施过程中若发现旧物理对象、菜单或已发布定义仍存在，用户“业务废弃”不等于数据库破坏性删除或改写在途历史授权；先核实再按项目安全边界退役，不能为复用表名执行DROP/TRUNCATE。

8. 文档协同

需求规则由需求分析维护；接口与节点字段由详细设计维护；全部拟建表字段及核验差异由数据库设计维护；运行证据只进入测试与验收，最终用户操作见操作手册。本次仅交付文档，未修改服务、数据库、流程定义或部署。