问题整改闭环插件设计文档

1. 目标与使用场景

检查、监督等不同业务产生的问题统一汇总到问题单表。问题单按来源和问题类型匹配处理规则，由规则确定整改人、复核人及期限，工作流编排整改、复核和复核不通过后的重新整改。

目标是让多个业务共用处理规则、单人办理、转交、通知与办理界面配置能力，减少重复实施配置，同时保留完整的整改、复核和转交历史。

使用人员包括配置来源、规则和节点界面的实施人员，以及下发问题、执行整改或复核的业务人员。各业务共用数据库和用户体系，本期不涉及跨系统同步。

1.1 本期确认范围

所有来源的问题统一进入 tabSafetyIssueDetails，以问题单为单位下发。
每张问题单的问题类型单选；每条规则的来源、问题类型均可多选，至少填写一项。
每个整改、复核环节只有一名当前办理人；两个环节分别支持配置一名兜底人。
当前办理人可将自己的环节转交给一名有效用户，支持连续转交。
提供整改、复核两个自定义工作流节点，以及可编辑的默认工作流模板。
在节点中配置办理界面、表单、提交与转交动作、通知及抄送。
问题列表、详情和历史记录主要由实施人员使用普通界面配置完成；插件提供可添加的业务动作。
不创建流程待办，不向流程待办统计注册业务任务。
支持桌面和移动端办理，新增用户文案同时提供中文、英文。
内置用检查业务表及所需字典定义。

2. 总体职责

层次	职责
问题来源	描述来源应用与来源表，供问题归属和规则匹配使用
处理规则	定义适用来源、类型，以及整改和复核的人员、兜底人、期限策略
统一问题单	保存问题内容、来源、问题类型、当前业务状态及本次下发配置快照
环节记录	保存具体轮次、当前办理人、实际期限、办理状态和工作流节点任务关联
整改复核记录	保存提交情况、复核结果和每次转交的历史
工作流	决定环节之间的流向，通过挂起和恢复等待业务人员办理
节点办理界面	供实施人员配置业务详情、输入字段、提交和转交入口

3. 来源定义与规则匹配

3.1 问题来源

字段建议	含义与约束
`id`	来源主键；问题单和规则通过关联使用，不要求额外来源编码
`name`	来源显示名称，供选择和展示，可初始生成为应用名与业务表名称的组合
`appCode`	来源业务所属子应用编码
`appName`	冗余保存应用名称，展示时不额外查询应用配置
`dataSource`	来源业务表所在数据源，默认 `main`
`collection`	产生问题的来源业务表标识，不统一填写为问题单表
`enabled`	是否允许新问题按该来源下发

规则可关联多个来源。停用来源后不允许以它启动新下发，已有环节继续使用保存的配置和业务关联；有历史引用的来源不应直接物理删除。

3.2 处理规则

字段建议	含义与约束
`id`、`name`	规则标识与名称
`sources`	问题来源多选关联，可为空
`issueTypes`	`IssueType` 字典多选，可为空；与问题单的单选类型使用相同字典值
`enabled`	只匹配启用的规则
`rectifyConfig`	整改人员选择、单名兜底人、期限配置 JSON
`verifyConfig`	复核人员选择、单名兜底人、期限配置 JSON

sources、issueTypes 至少一项非空。JSON 使用结构化表单配置并由服务端校验，不要求实施人员手写 JSON 或任意脚本。

3.3 匹配算法

设问题单来源为 S、类型为 T。对所有启用规则，来源命中指 S 在规则来源集合中，类型命中指 T 在规则类型集合中。空集合视为该项不命中，不是任意匹配。

档位	匹配条件
1	来源命中且类型命中
2	类型命中、来源不命中或未配置来源
3	来源命中、类型不命中或未配置类型

只在存在候选的最高档位选择规则。该档恰好一条时使用；多条时提示规则冲突，列出冲突规则，不取第一条、不混合配置，也不再向低档寻找。全部未命中时提示补充规则。

第二、三档允许另一项明确不匹配。例如来源不同但类型相同的规则可成为第二档候选；并非只有另一项为空才允许降档匹配。

示例	预期
问题为来源 A／安全，有规则同时包含 A 和安全	使用唯一的第一档规则，忽略低档候选
无第一档，有仅安全规则，另有仅来源 A 规则	使用仅安全规则
无第一、二档，只有包含来源 A 的规则	使用唯一的第三档规则
两条最高档规则均包含 A／安全	首次整改节点提示冲突，不产生有效分派
规则来源与类型均为空	保存校验不通过
没有任何候选	提示补充规则

3.4 配置快照

通用按钮先触发异步工作流，首次整改节点执行时完成业务校验与规则匹配，将规则关联、完整的整改与复核配置、匹配时间及必要的节点运行配置保存到本次有效下发快照。按钮请求返回时不保证已完成匹配或保存快照

规则后续修改、停用及关联集合变化不改变在途问题；重新整改也使用原快照，不再次按当前规则匹配。各环节实际进入时，根据快照中的人员选择条件解析用户，并计算实际截止时间，记录解析结果。

人员引用、业务关联与快照各有用途：快照用于保留当时要求，实际办理人以当前环节记录为准，不能重新读取问题单上某个可编辑的人员字段来覆盖当前环节。

4. 人员、兜底与转交

4.1 单人解析

人员选择可配置具体人员、岗位或角色，最终必须解析到一个有效的登录用户。已有员工关联可用于人员选择和业务展示，服务端办理权限根据用户账号判定。

主配置解析结果	处理
恰好一名有效用户	分派给该用户
未找到有效用户，包括人员失效或未绑定有效账号	使用本环节配置的兜底人
多名有效用户	提示人员配置异常，不取第一人，不使用兜底掩盖歧义
使用兜底后仍无法取得有效用户	提示处理，不跳过、不自动完成环节

整改、复核分别配置一名兜底人，兜底人本身也必须绑定有效用户。记录是否使用兜底及原因。两个环节的人员和兜底配置随规则快照保存。

第一版不按问题责任组织、当前登录身份所在组织等范围递归查找人员，不要求整改人与复核人必须为不同用户。

4.2 转交

仅当前有效环节的当前办理人可以转交。
一次只选一名有效接收人，转交立即生效，不需要接收确认。
接收人不能是当前办理人；接收范围可在节点的转交动作中配置。
转交替换当前环节的办理人，不完成环节、不启动下一环节、不改变期限。
每次转交新增历史记录，记录操作者、接收人、时间和说明；不能覆盖上一条转交历史。
A 转给 B 后，A 即使仍持有原消息链接，也不再具有提交或继续转交权限；B 可以继续转给 C。
已完成、已关闭或关联流程已终止的环节不能转交；转交与提交并发时，只允许一种状态变更成功。

4.3 复核不通过后的人员

复核不通过后，新一轮整改交给上一轮最后实际办理整改的人，包括经过转交后的接收人。不重新匹配规则或重新选回最初的整改人。

若该用户在新一轮进入时已无效，先使用原快照中的整改兜底人；兜底仍不可用时阻止新一轮分派并保留可诊断的异常，不丢失本轮复核结果。

5. 状态、期限

5.1 问题与环节状态

问题单继续使用 RectifyStatus 中已有三项，不增加“待下发”：

编码	名称	含义
`Rectify`	整改中	当前有效环节是整改
`Verify`	复核中	当前有效环节是复核
`Closed`	已闭合	复核通过，闭环完成

尚未下发的问题状态可为空，是否已下发根据工作流执行关联和环节记录判断；空状态不表示已完成。流程执行异常与上述业务状态分开记录，不额外塞入该字典。

环节记录需表达待办理、已完成及失效等内部状态，用于并发校验和恢复；这不等于新增问题单字典项，也不创建流程待办。

5.2 期限

整改期限从进入本轮整改环节起算，复核期限从进入本轮复核环节起算。
支持按小时、自然日或明确截止时间配置，不引入工作日历。
保存计算后的实际截止时间，供界面、通知和超期判断使用，不只保留配置中的天数。
转交不重置期限；重新整改使用原规则快照重新计算该轮期限。
超期不自动通过、不自动闭合，办理动作继续按当前人员及环节权限校验。

6. 默认工作流与业务动作

6.1 默认模板

内置可编辑的默认工作流模板，使用异步工作流等待业务办理：

flowchart TD
    A[通用按钮触发异步工作流] --> B[首次整改节点校验、认领并保存规则快照]
    B --> C[进入本轮整改节点]
    C --> D[提交整改并保存历史]
    D --> E[进入本轮复核节点]
    E --> F{复核结果}
    F -->|合格| G[问题闭合并汇总完成时间]
    F -->|不合格| H[保留复核记录，进入下一轮]
    H --> C

复核不合格是正常业务结果，输出给工作流分支或循环处理，不用节点执行错误代替退回。具体循环编排复用当前工作流公开能力，不直接修改工作流历史任务来倒退。

6.2 下发

不开发专用下发动作。实施人员在问题列表或详情中添加现有“触发工作流”动作，将名称配置为“下发”，绑定已启用的“自定义操作事件”工作流。触发器使用 tabSafetyIssueDetails 的单行数据上下文，流程使用异步模式，并配置整改、复核节点。本期仍以单张问题单为下发单位，不据此扩展批量下发能力。

按钮负责携带问题上下文和请求触发工作流，现有触发能力负责流程绑定、数据访问与触发权限检查。首次整改节点在服务端重新读取问题的实际状态，完成业务下发权限、来源与类型、规则匹配、人员及兜底、必要节点配置等校验；校验成功后原子认领问题并创建首轮整改环节。按钮显示或禁用条件不代替上述服务端校验。

通用异步按钮请求成功只表示触发请求已被接受，不代表规则有效、人员已确定或整改已经分派。规则缺失、规则冲突、人员无效等后续校验错误保存在可定位问题的工作流执行结果中，供实施人员处理；

6.3 整改节点与复核节点

整改节点首次执行时负责第 6.2 节的校验、规则快照与问题认领；有效执行的后续轮次不重新匹配规则。节点进入时创建或取得本轮环节记录，记录人员、期限和关联节点任务，随后挂起工作流。业务提交动作保存当前环节结果后请求恢复工作流，由工作流决定下一环节。

节点	输入	业务提交	输出用途
整改	问题记录、触发用户与执行上下文、轮次；首轮建立快照，后续轮次读取原快照	整改情况及配置的业务字段	当前轮次整改完成，进入复核
复核	问题记录、本轮整改和历史记录、原快照	复核意见、合格／不合格结果及配置的业务字段	合格闭合，不合格进入新一轮整改

业务提交接口只完成当前环节并保存恢复依据，不同时自行创建下一环节。下一环节由工作流节点进入逻辑创建，避免两处推进导致重复记录。

7. 节点界面、办理入口与消息

7.1 配置归属

归属	配置内容
规则	人员选择条件、单名兜底人、期限策略
整改／复核节点	办理界面、业务字段、可用操作、转交接收范围、通知和抄送
普通业务页面	问题列表、筛选、详情、关联历史区块以及下发／办理动作的位置

每个节点提供“办理界面配置”入口。实施人员在其中配置问题详情、历史、输入表单和插件业务动作；不要求开发固定的问题中心页面。

7.2 可配置动作

动作	提供者与行为
下发	复用现有“触发工作流”动作，由实施人员放置、命名并绑定问题单单行上下文的异步工作流；插件不另提供专用动作
办理	插件提供，实施人员放置到列表或详情，根据当前有效环节打开对应节点办理界面
提交整改	插件提供，在整改节点界面中配置，保存情况并完成整改环节
提交复核	插件提供，在复核节点界面中配置，保存意见与结果并驱动后续流向
转交	插件提供，在节点界面中配置，填写说明并单选一名接收人

7.3 消息与链接

进入整改、进入复核及转交后通知对应的当前办理人；复核不合格后通知新一轮整改人。节点可配置通知渠道、模板和抄送对象；抄送不产生办理权限。

消息和业务页面的“办理”动作使用同一办理入口，链接定位到具体环节记录，并由系统结合节点界面生成，不要求实施人员逐条拼接 URL。环节记录须能定位其所用的节点与界面配置，不能仅根据问题当前状态猜测旧消息目标。

旧消息不会误提交到新一轮环节；转交后的旧办理人及已完成环节只能按查看权限访问，不再具有办理权限。链接参数不能代替登录、数据访问和当前办理人校验。

新增办理动作、表单及转交选择在移动端必须可用，包括触摸操作、弹层、键盘输入、错误提示和消息链接打开。可访问性及中英文文案按仓库要求执行。