6.7 KiB
报销通知与处理进度简化：实施计划
0. 边界与前置
- 获得最终规划批准后再启动任务；生产只读诊断随本计划获批，任何生产写入、补发、配置修改或重启仍需另行批准。
- 不修改审批链、付款 maker-checker、数据库 schema、历史任务或真实付款数据。
- 生产诊断不输出通知正文、完整账号、企微 userid、内部业务 ID、Secret 或原始响应。
1. 生产只读通知诊断
- 定位目标报销最新工作流的当前财务任务，先查
workflow.task_assigned站内通知是否存在。 - 有通知则查 delivery 状态/固定结果码、推送开关、绑定存在性和渠道匹配；无通知则核对下一任务与收件人解析事实。
- 形成只含布尔值、计数和错误分类的结论；需要修生产配置、补发或重启时停止并申请批准。
诊断结论（脱敏）：当前财务任务及对应站内通知均已生成，收件人 active、开启推送且存在企微绑定；投递尝试为 0，生产无启用且匹配的企微通知渠道。根因位于投递配置层，不是审批推进或通知创建代码。本任务没有修改生产配置、补发、重启或部署。
2. 共享动作标签
- PC 与移动审批页移除局部
workflowActionLabel，统一导入共享实现。 - 增加
start/submit中文映射回归，检查打印及其他调用方没有第三份重复映射。
3. 处理进度文案
- 将员工详情的后两阶段改为“付款复核”“付款完成”。
- 付款完成待处理说明明确“由财务登记，非审批环节”，保留权限门控的批次入口和回单完成状态。
- 更新 PC/移动组件测试，断言五阶段顺序与普通员工不暴露内部批次入口。
4. 付款责任人通知
- 以前述只读诊断结论为实施门：先证明公共通知创建/投递路径的根因与修复边界，再确定本节只新增发送点还是必须复用同一代码修复。
- 增加付款复核待办与付款执行待办的通知类型、domain 和脱敏文案。
- 批次创建事务内解析有复核权限的 active manager/ceo，排除创建人并创建通知；提交后复用现有 dispatcher。
- 批次复核事务内通知 active 批次创建人/实际付款责任人，排除复核人；付款执行成功沿用现有申请人通知。
- 覆盖无合格收件人、创建人停用、重复请求、投递失败不回滚业务和普通用户不可读批次等边界。
5. 验证与审查
- 运行 workflow/reimbursement/payment-batch 聚焦 Vitest、付款并发与 maker-checker 回归。
- 运行客户端 typecheck/build、相关 PC/移动 Playwright 和动作标签单测。
- 运行 Prisma validate、task/governance/process/sensitive/diff 门禁。
- 因涉及 workflow/付款职责和通知收件范围，实施后执行只读 reviewer 检查，不允许 reviewer 改代码。
- 已获批部署并完成公网检查；企微实际到达仍必须由新业务事件和真机确认，不能用历史 WMSG1 或自动化替代。
只读审查结论：首次检查发现站内通知中心缺少 payment_batch 目标链接，已补 PC/移动统一直达付款页并增加回归；复查未发现阻断项。通知记录与付款动作同事务，IM 投递发生在提交后且失败不回滚；复核人解析排除制单人，付款责任人解析排除复核人；重复创建/复核由既有锁和状态校验拒绝，不重复通知。生产仍无启用且匹配的企微渠道，属于已知部署后配置门，不得表述为企微通知已恢复。
生产发布记录（2026-08-01，脱敏）：
- 已将已发布提交
aa6b9bc按既有安装固化入口部署；环境合同、迁移状态、/ready、外部依赖 smoke、运行时 smoke、公网构建标识和前端资源扫描通过。 - 历史 WMSG1 已证明当前企微应用具备应用消息发送能力；本轮没有另发渠道测试消息。
- 生产仅启用 1 条
wecom_app_message渠道，限定 workflow/reimbursement 域和 7 类审批、报销、付款通知；非相关业务类型不匹配。 EMAIL_ENABLED=false已在新容器生效；没有创建邮件通知渠道。- 渠道创建写入 1 条审计；没有扫描、补发或重放任何历史通知。
- 当前仅证明“新事件可匹配企微渠道”；仍待王芝玲财务复核/创建付款批次等真实新动作产生 delivery，并由收件人真机确认消息到达与 Deeplink 回流。
6. 运行观察
- 运行约定为每周集中建立一次付款批次，不建设排程功能。
- 王芝玲累计处理 5–10 张真实报销后触发一次访谈，决定财务复核与加入批次是否值得另立合并任务（未来触发条件，当前尚未发生）。
7. 付款入口与常开恢复
- 先查生产 R54 变更历史、当前 flag 版本、创建/更新时间、updated_by 和环境硬开关，不先恢复。
- 确认当前库没有
FEATURE_FLAG_UPDATED审计；根因是当前库首次初始化与.env均采用关闭默认值，不是 QA runner 或人工关闭。 - 将正式试运行环境默认硬开关和 seed 首次创建默认值改为付款常开，seed 仍不得覆盖已有记录。
- 修复 QA 窗口 runner：结束时恢复调用前快照，不无条件写死
force_off；正式启用 runner 成功保持force_on、失败恢复原值。 - 移动财务工作台在付款能力启用但尚无批次时仍显示“付款”入口；PC 入口保持不变；新增移动付款路由避免小屏自动回首页。
- 补测试覆盖新环境初始化、runner 原值 on/off、移动端零批次入口、普通员工不可见和已批准候选可读。
- 通过只读审查后提交、部署；受控设置生产环境硬开关 true 和数据库全局
force_on，写审计并验证候选计数，不创建真实批次。
本地验证（2026-08-01）：seed/部署合同/Portal 聚焦单测 19 passed；flag 快照 helper 的原值 force_off department_allowlist 与 force_on global 两类恢复测试 2 passed；移动信息架构 6 passed；客户端 typecheck/build、Prisma validate、脚本语法、Trellis/task/process/sensitive/diff 门禁通过。
只读审查（2026-08-01）：未发现阻断项。PC 与移动付款路由使用同一权限集合，普通员工不会因新增移动路由获得付款能力；移动财务卡片同时受真实财务角色/付款权限和后端 financeSummary 门控；env、DB flag 与 runtime smoke 三层缺一即失败；短窗口在任何临时写入前保存完整快照，成功/失败分支均不会把调用前 force_on 或 allowlist 静默改成固定关闭。审查未修改代码。