docs: clarify repeated rectification push flow

src/pages/problem_rectification/problem-rectification.business-flow.md

@@ -342,9 +342,11 @@
    - `sender_status = "未完成"`
 6. 单条和多条推送均回写每个问题的 `metadata.department_rectification_items`；每个部门明细保存责任部门、填写人、审批人、整改字段、审批状态和待办 ID。已有明细时必须保留原明细记录和 `item_id`，在原明细行上更新本次流程人员、状态和待办，整改进度、整改情况、预计完成时间、证明材料、创建人和创建时间继续沿用原值
    - 再次推送时，只更新本次弹窗中保留并参与推送的部门明细；未参与本次推送的原明细行保持不变，不因删除弹窗部门配置而从父记录中移除
+   - 例如问题包含 2 个责任部门、其中 1 个已整改、1 个整改中时，只重新推送整改中的部门；已整改部门明细保留原状态和内容
    - 写入后逐条重新读取父问题并校验原明细是否保留、本次推送明细的 `item_id` 和待办 ID 是否回写；后台未返回预期明细时，本次推送显示失败，不展示成功提示
 7. 多选简单推送按批次只创建 1 条填写 OA 待办，同一批次全部部门明细共享流程主单状态和待办 ID；明细业务内容仍按各自 `item_id` 独立保存
-8. 发送内部通知和 OA 待办时，链接使用当前应用基准路径拼出 `<appBasePath>/problem_rectification_flow_table?id=<message_record_name>`，并在浏览器环境下补齐 `window.location.origin`；问题整改首次推送、流程内复核 / 驳回 / 最终审批和延期流程统一遵守该规则
+8. 单条问题按部门推送时，本次保留的每个部门各创建 1 条填写 OA 待办；只有对应填写人收到本次填写通知，复核人暂不收到通知。填写人进入流程页后仍可查看该问题关联的全部部门明细，但只能编辑本人负责的部门明细
+9. 发送内部通知和 OA 待办时，链接使用当前应用基准路径拼出 `<appBasePath>/problem_rectification_flow_table?id=<message_record_name>`，并在浏览器环境下补齐 `window.location.origin`；问题整改首次推送、再次推送、流程内复核 / 驳回 / 最终审批和延期流程统一遵守该规则
 
 推荐新交互：