142 行
19 KiB
Markdown
142 行
19 KiB
Markdown
# 报销通知与处理进度简化：实施计划
|
|
|
|
## 0. 边界与前置
|
|
|
|
- [x] 获得最终规划批准后再启动任务；生产只读诊断随本计划获批，任何生产写入、补发、配置修改或重启仍需另行批准。
|
|
- [x] 不修改审批链、付款 maker-checker、数据库 schema、历史任务或真实付款数据。
|
|
- [x] 生产诊断不输出通知正文、完整账号、企微 userid、内部业务 ID、Secret 或原始响应。
|
|
|
|
## 1. 生产只读通知诊断
|
|
|
|
- [x] 定位目标报销最新工作流的当前财务任务，先查 `workflow.task_assigned` 站内通知是否存在。
|
|
- [x] 有通知则查 delivery 状态/固定结果码、推送开关、绑定存在性和渠道匹配；无通知则核对下一任务与收件人解析事实。
|
|
- [x] 形成只含布尔值、计数和错误分类的结论；需要修生产配置、补发或重启时停止并申请批准。
|
|
|
|
诊断结论（脱敏）：当前财务任务及对应站内通知均已生成，收件人 active、开启推送且存在企微绑定；投递尝试为 0，生产无启用且匹配的企微通知渠道。根因位于投递配置层，不是审批推进或通知创建代码。本任务没有修改生产配置、补发、重启或部署。
|
|
|
|
## 2. 共享动作标签
|
|
|
|
- [x] PC 与移动审批页移除局部 `workflowActionLabel`，统一导入共享实现。
|
|
- [x] 增加 `start`/`submit` 中文映射回归，检查打印及其他调用方没有第三份重复映射。
|
|
|
|
## 3. 处理进度文案
|
|
|
|
- [x] 将员工详情的后两阶段改为“付款复核”“付款完成”。
|
|
- [x] 付款完成待处理说明明确“由财务登记，非审批环节”，保留权限门控的批次入口和回单完成状态。
|
|
- [x] 更新 PC/移动组件测试，断言五阶段顺序与普通员工不暴露内部批次入口。
|
|
|
|
## 4. 付款责任人通知
|
|
|
|
- [x] 以前述只读诊断结论为实施门：先证明公共通知创建/投递路径的根因与修复边界，再确定本节只新增发送点还是必须复用同一代码修复。
|
|
- [x] 增加付款复核待办与付款执行待办的通知类型、domain 和脱敏文案。
|
|
- [x] 批次创建事务内解析有复核权限的 active manager/ceo，排除创建人并创建通知；提交后复用现有 dispatcher。
|
|
- [x] 批次复核事务内通知 active 批次创建人/实际付款责任人，排除复核人；付款执行成功沿用现有申请人通知。
|
|
- [x] 覆盖无合格收件人、创建人停用、重复请求、投递失败不回滚业务和普通用户不可读批次等边界。
|
|
|
|
## 5. 验证与审查
|
|
|
|
- [x] 运行 workflow/reimbursement/payment-batch 聚焦 Vitest、付款并发与 maker-checker 回归。
|
|
- [x] 运行客户端 typecheck/build、相关 PC/移动 Playwright 和动作标签单测。
|
|
- [x] 运行 Prisma validate、task/governance/process/sensitive/diff 门禁。
|
|
- [x] 因涉及 workflow/付款职责和通知收件范围，实施后执行只读 reviewer 检查，不允许 reviewer 改代码。
|
|
- [x] 已获批部署并完成公网检查；企微实际到达仍必须由新业务事件和真机确认，不能用历史 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. 运行观察
|
|
|
|
- [x] 运行约定为每周集中建立一次付款批次，不建设排程功能。
|
|
- [ ] 王芝玲累计处理 5–10 张真实报销后触发一次访谈，决定财务复核与加入批次是否值得另立合并任务（未来触发条件，当前尚未发生）。
|
|
|
|
## 7. 付款入口与常开恢复
|
|
|
|
- [x] 先查生产 R54 变更历史、当前 flag 版本、创建/更新时间、updated_by 和环境硬开关，不先恢复。
|
|
- [x] 确认当前库没有 `FEATURE_FLAG_UPDATED` 审计；根因是当前库首次初始化与 `.env` 均采用关闭默认值，不是 QA runner 或人工关闭。
|
|
- [x] 将正式试运行环境默认硬开关和 seed 首次创建默认值改为付款常开，seed 仍不得覆盖已有记录。
|
|
- [x] 修复 QA 窗口 runner：结束时恢复调用前快照，不无条件写死 `force_off`；正式启用 runner 成功保持 `force_on`、失败恢复原值。
|
|
- [x] 移动财务工作台在付款能力启用但尚无批次时仍显示“付款”入口；PC 入口保持不变；新增移动付款路由避免小屏自动回首页。
|
|
- [x] 补测试覆盖新环境初始化、runner 原值 on/off、移动端零批次入口、普通员工不可见和已批准候选可读。
|
|
- [x] 通过只读审查后提交、部署；受控设置生产环境硬开关 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 静默改成固定关闭。审查未修改代码。
|
|
|
|
生产恢复与发布（2026-08-01，脱敏）：
|
|
|
|
- 静态 env 中唯一 `PAYMENT_BATCH_ENABLED=false` 已受控改为 true；修改时运行中旧容器未重启，未形成半开启能力。
|
|
- 既有受控 live 管理员凭据已失效，Feature Flag API 在任何 flag 写入前返回 401；没有重置账号或读取密码。随后改用服务器内 Prisma，在单个 Serializable 事务中锁定唯一 `payment_batch_v1`，断言版本 1/`force_off` 后更新为版本 2/`force_on global`，并新增恰好 1 条带 before/after 的 `FEATURE_FLAG_UPDATED` 审计。
|
|
- 提交 `37b4ef2` 已推送并通过既有安装固化入口部署；环境合同、远端 preflight、migration、`/ready`、external deps、runtime smoke、公网构建标识和前端资源扫描通过。
|
|
- runtime smoke 明确证明 env true 与 `payment_batch_v1=flag_force_on_global`；生产只读核验确认唯一 active 财务人员仍有付款管理权限、系统导航含 `paymentBatches`、已批准未付款计数为 1、可建批次候选计数为 1。
|
|
- 没有替财务创建付款批次，没有替负责人复核，也没有上传回单或执行付款。下一条真实验证由王芝玲创建批次触发，届时核验马建勇收到付款复核企微通知。
|
|
|
|
## 8. 首张真实付款批次闭环修正（已实施，待部署批准）
|
|
|
|
- [x] 只读核对创建路由、状态转换、通知发送点、前端按钮显隐和聚焦 E2E；确认不存在 submit API，`draft` 创建时已经发送复核通知。
|
|
- [x] 生产只读核验最新真实批次：已自动编号、状态 `draft`、未复核/未付款、含 1 个报销项；复核通知已生成且有 1 次企微成功投递。核验未读取名称、金额、人员标识、消息正文或原始 payload。
|
|
- [x] 服务端允许省略名称，自动生成批次标题和银行渠道默认值；付款完成登记缺少日期时按公司时区当天落账。
|
|
- [x] 既有报销批次渠道为空时按银行转账进行 API 展示和回单门禁，不执行生产数据回填。
|
|
- [x] 复核责任人解析改为单一 `ceo` 优先、`manager` 兜底；没有合格非制单复核人时在任何业务写入前拒绝创建。
|
|
- [x] 创建页收敛为选择报销 + “创建并提交复核”，移除名称、默认日期、渠道和凭证前缀的高频路径输入；异常覆盖仍留在详情。
|
|
- [x] 统一状态和动作：`draft=待付款复核`、`reviewed=待财务付款`、`executed=已付款`、`failed=付款登记失败`；“复核”改为“复核通过”，“执行”改为“登记付款完成”。
|
|
- [x] 提取付款批次共享状态映射并替换客户端局部映射；增加跨层语义回归，锁定报销进度与付款页对 `draft` 的一致表达。
|
|
- [x] 详情按状态显示当前责任职责、下一步和 maker-checker 说明；银行渠道无有效回单时唯一主动作是“上传银行回单”，上传后切换为“登记付款完成”；不新增 Tab、流程设计器、第二轮复核或 submit API。
|
|
- [x] 更新 server route 单测与付款主链 Playwright，覆盖自动字段、无复核人 fail-closed、单一收件人、状态/动作中文和实际付款日缺省值。
|
|
- [x] 运行 server focused Vitest、客户端 typecheck/build、聚焦 Playwright、Prisma validate、Trellis/governance/process/sensitive/diff 门禁。
|
|
- [x] 因修改付款责任解析和状态表达，实施后执行只读 reviewer 审查；通过后再申请提交、部署和公网/真机验证批准。
|
|
|
|
本地验证（2026-08-01）：付款/报销详情/通知/导出/导航聚焦 Vitest 85 passed；隔离 PostgreSQL 付款并发门禁覆盖双执行、执行/取消、重复建批次和直接付款竞争并全部通过；客户端 typecheck/build 通过；付款权限 5 条、高风险动作 8 条 Playwright 共 13 passed。reviewer 首轮未发现数据安全或状态机阻断项，指出“兼任复核职责的制单人仍显示自审按钮”和“回单查询失败误报为空”两项交互问题；已修为前端同步排除制单人、失败态只显示错误与重新加载，复查未发现新 blocker。既有真实批次未被读取正文、修改、复核、上传回单或登记付款。
|
|
|
|
生产发布（2026-08-02，脱敏）：提交 `7c39f8b` 已推送并通过既有安装固化入口部署；同步前远端源码、普通环境文件、PGDATA 和附件目录合同通过，未同步或覆盖 `.env`。63 项 migration 为 up to date，init/server 依赖层命中缓存；`/ready` 构建短标识、external deps smoke、runtime smoke、付款能力 env/flag 常开、公网前端资源扫描和付款懒加载块四项关键文案均通过。当前 shell 未配置 live-smoke 专用凭据，因此没有宣称登录后业务链自动验收；部署未替任何人复核批次、上传回单或登记付款。
|
|
|
|
## 9. 付款详情与批次短编号（已实施并部署）
|
|
|
|
- [x] 将付款详情重排为“批次概要 → 当前处理/下一步 → 报销明细 → 银行回单”，保留现有内联详情和顶部唯一主动作，不新增独立路由。
|
|
- [x] 付款页列表、移动卡片、详情总额、批次项、确认弹窗和高风险阈值全部改用共享 `formatMoney()`。
|
|
- [x] 使用公司时区生成 `PB-YYYYMMDD-NNN`，在同一 Prisma 交互事务中先取得双 int4 `pg_advisory_xact_lock`，再查询严格新格式最大日序号并创建批次。
|
|
- [x] 自动标题改为 `YYYY-MM-DD 付款批次 NNN`；显式名称保持原值；既有编号不迁移；日序号超过 999 时 fail-closed。
|
|
- [x] 更新 route 单测，覆盖时区、自动标题、显式名称、同日递增、跨日归零、同日旧长编号隔离和边界错误；更新真实 PostgreSQL 并发门禁，证明同日并发编号唯一递增。
|
|
- [x] 更新付款主链 Playwright，断言详情信息顺序、顶部主动作和全页金额格式；运行前端 typecheck/build。
|
|
- [x] 运行 Prisma validate、node syntax、task/governance/process/sensitive/diff 门禁；因涉及付款创建并发和原始 SQL，执行只读 reviewer，不允许 reviewer 改代码。
|
|
- [x] 把双参数咨询锁命名空间、锁顺序、错误矩阵和测试要求沉淀到 backend spec；通过后中文提交，不在未获新批准时部署。
|
|
|
|
本地验证（2026-08-02）：付款 route 单测 39 passed；隔离 PostgreSQL 付款并发门禁覆盖双执行、执行/取消、重复建批次、同日两来源日序号、直接付款竞争和缺失制单人场景并全部通过；付款权限与高风险动作 Playwright 14 passed；客户端 typecheck/build、Prisma validate、相关脚本语法、Trellis task/governance/process/sensitive/diff 门禁通过。文档注册审计保持 0 error，既有 22 个未登记 docs 文件 warning 与本轮无关。
|
|
|
|
实现中发现 Prisma 7.8 driver adapter 无法反序列化 `SELECT pg_advisory_xact_lock(...)` 的 PostgreSQL `void` 列并返回 `P2010`；锁调用改用 `$executeRaw` 后真实 PostgreSQL 并发门禁通过。该陷阱、双 int4 命名空间登记、固定锁顺序和禁止在已 aborted 事务内重试 `P2002` 已写入 backend spec。
|
|
|
|
只读审查（2026-08-02）：未发现权限、maker-checker、付款状态机或历史编号兼容阻断项。新编号分配在既有报销锁定、状态/占用和复核人校验之后、所有批次/批次项/审计/通知写入之前；咨询锁、严格新格式查询和创建保持在同一交互事务。旧长编号不参与日序号，超过 999 时零业务写入；付款页未新增路由或可操作权限，回单缺失时顶部仍只有一个主动作。审查未修改生产数据，也未执行部署。
|
|
|
|
生产发布与部署合同恢复（2026-08-02，脱敏）：
|
|
|
|
- 提交 `5d274af` 已推送并通过 `deploy-existing.sh` 的既有合同入口部署；六键合同读取、环境合同、远端 preflight、63 项 migration、`/ready` 构建标识、external deps、runtime smoke、付款能力常开和公网资源扫描通过。当前 shell 未配置 live-smoke 专用凭据，因此没有宣称登录后业务链自动验收。
|
|
- 部署前从运行中容器定位权威环境候选并逐键进行 SHA-256 比对：生产环境文件中的 163 个实际赋值键全部 PASS，0 个不可观测键。PASS 键名集合等于提交 `5d274af` 的 `deploy/trialrun/.env.example` 中全部非注释赋值键；唯一未进入生产集合的是注释状态的可选 `SHADOW_DATABASE_URL`。关键不可替代或身份相关键 `FIELD_ENCRYPTION_KEY`、`DATABASE_URL`、`POSTGRES_USER`、`POSTGRES_DB`、`POSTGRES_PASSWORD`、`JWT_SECRET` 均在 PASS 集合内。记录不含任何值、散列值、宿主路径或主机标识。
|
|
- 权威环境文件仅复制到规范部署根，旧文件原地保留；新副本字节 SHA-256 一致、部署用户属主且权限为 `0600`。部署全程保持 `SYNC_ENV=0`，没有从本地同步或覆盖生产环境文件，也没有删除四个旧源码候选目录。
|
|
- 部署后以新完整 SHA 重装 automatic-backup 与 WARCH3 合同；4 个 service 的工作目录、环境文件、构建 SHA 与规范根一致，4 个 timer 均为 enabled/active。
|
|
- 已手工触发一次完整真实自动备份周期：源端成功状态新鲜且构建标识一致，`resolve_active_runtime` 的运行构建、附件挂载和 PGDATA 挂载三项断言通过；异机归档完成，随后 watchdog 证明异机恢复点新鲜。没有输出归档路径、文件名、远端标识或任何密钥。
|
|
- 旧源码候选目录与旧环境文件继续保留，清理不属于本轮授权范围。任务仍保留运行观察项，不因本次部署归档。
|
|
|
|
## 10. 付款复核对象与阶段编辑收口（本轮）
|
|
|
|
- [x] 服务端将批次项编辑限制为 `reviewed/failed` 的凭证号与实际付款日期，拒绝任何创建后渠道覆盖；`draft/executed/cancelled` 均不可编辑。
|
|
- [x] 服务端将回单上传/作废限制为 `reviewed/failed`，保留所有状态下的授权查看/下载；拒绝请求不写附件、存储对象或审计。
|
|
- [x] 创建快照加入收款人姓名、开户银行和脱敏账户摘要；既有批次通过只读 fallback 补齐 DTO，不迁移或回写生产数据。
|
|
- [x] 创建面板增加付款渠道选择并传既有 `defaultPaymentChannel`；默认银行转账，创建成功后重置。
|
|
- [x] 详情待复核阶段隐藏付款登记输入和回单维护动作；复核后显示凭证号/日期与回单动作；已付款/已取消全部只读，四段结构和确认弹窗不变。
|
|
- [x] 服务端测试覆盖状态矩阵、渠道锁定、零副作用和脱敏 DTO；前端测试覆盖创建 payload、待复核零编辑、复核后登记及已付款回单只读。
|
|
- [x] 运行付款 focused Vitest、相关 Playwright、客户端 typecheck/build、Prisma validate、task/governance/process/sensitive/diff 门禁，并执行付款状态机只读审查。
|
|
|
|
本地验证（2026-08-02）：付款路由与并发保护单测 58 passed；付款权限/高风险动作 Playwright 15 passed；客户端 typecheck/build、Prisma validate、Node syntax、隔离 PostgreSQL 付款并发门禁、task/governance/process/docs/sensitive/diff 门禁通过。首次 Playwright 运行因本地静态预览未启动而在登录页统一 `ERR_CONNECTION_REFUSED`，启动本地预览后原样重跑全绿，不属于业务断言失败。文档审计保持 0 error，既有 22 个未登记 docs 文件 warning 与本轮无关。
|
|
|
|
只读审查首轮发现：原始 `snapshotJson` 仍可透传异常/历史快照，列表执行不必要的收款资料解密，且缺少 `failed` 正向和回单存储补偿测试。已移除付款响应的原始快照字段，详情只返回格式校验后的固定收款字段，列表不再加载或解密详情级收款资料；补充恶意快照、`failed`、拒绝零文件残留和上传期间状态变化清理回归。未修改生产数据，未执行部署或真实付款动作。
|
|
|
|
只读复查随后发现付款页仍把精简列表项当详情使用，会让真实收款依据显示为空；已改为按所选批次 ID 加载详情，并将 E2E 锁定为“列表收款字段为空、详情返回脱敏字段且页面确实发起详情请求”。最终复查无 Blocker/High/Medium/Low，未修改文件。
|