hyb-oa/.trellis/tasks/08-01-reimbursement-notification-progress-clarity/implement.md

报销通知与处理进度简化：实施计划

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 静默改成固定关闭。审查未修改代码。

生产恢复与发布（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. 首张真实付款批次闭环修正（已实施，待部署批准）

• 只读核对创建路由、状态转换、通知发送点、前端按钮显隐和聚焦 E2E；确认不存在 submit API，draft 创建时已经发送复核通知。
• 生产只读核验最新真实批次：已自动编号、状态 draft、未复核/未付款、含 1 个报销项；复核通知已生成且有 1 次企微成功投递。核验未读取名称、金额、人员标识、消息正文或原始 payload。
• 服务端允许省略名称，自动生成批次标题和银行渠道默认值；付款完成登记缺少日期时按公司时区当天落账。
• 既有报销批次渠道为空时按银行转账进行 API 展示和回单门禁，不执行生产数据回填。
• 复核责任人解析改为单一 ceo 优先、manager 兜底；没有合格非制单复核人时在任何业务写入前拒绝创建。
• 创建页收敛为选择报销 + “创建并提交复核”，移除名称、默认日期、渠道和凭证前缀的高频路径输入；异常覆盖仍留在详情。
• 统一状态和动作：draft=待付款复核、reviewed=待财务付款、executed=已付款、failed=付款登记失败；“复核”改为“复核通过”，“执行”改为“登记付款完成”。
• 提取付款批次共享状态映射并替换客户端局部映射；增加跨层语义回归，锁定报销进度与付款页对 draft 的一致表达。
• 详情按状态显示当前责任职责、下一步和 maker-checker 说明；银行渠道无有效回单时唯一主动作是“上传银行回单”，上传后切换为“登记付款完成”；不新增 Tab、流程设计器、第二轮复核或 submit API。
• 更新 server route 单测与付款主链 Playwright，覆盖自动字段、无复核人 fail-closed、单一收件人、状态/动作中文和实际付款日缺省值。
• 运行 server focused Vitest、客户端 typecheck/build、聚焦 Playwright、Prisma validate、Trellis/governance/process/sensitive/diff 门禁。
• 因修改付款责任解析和状态表达，实施后执行只读 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. 付款详情与批次短编号（已实施并部署）

• 将付款详情重排为“批次概要 → 当前处理/下一步 → 报销明细 → 银行回单”，保留现有内联详情和顶部唯一主动作，不新增独立路由。
• 付款页列表、移动卡片、详情总额、批次项、确认弹窗和高风险阈值全部改用共享 formatMoney()。
• 使用公司时区生成 PB-YYYYMMDD-NNN，在同一 Prisma 交互事务中先取得双 int4 pg_advisory_xact_lock，再查询严格新格式最大日序号并创建批次。
• 自动标题改为 YYYY-MM-DD 付款批次 NNN；显式名称保持原值；既有编号不迁移；日序号超过 999 时 fail-closed。
• 更新 route 单测，覆盖时区、自动标题、显式名称、同日递增、跨日归零、同日旧长编号隔离和边界错误；更新真实 PostgreSQL 并发门禁，证明同日并发编号唯一递增。
• 更新付款主链 Playwright，断言详情信息顺序、顶部主动作和全页金额格式；运行前端 typecheck/build。
• 运行 Prisma validate、node syntax、task/governance/process/sensitive/diff 门禁；因涉及付款创建并发和原始 SQL，执行只读 reviewer，不允许 reviewer 改代码。
• 把双参数咨询锁命名空间、锁顺序、错误矩阵和测试要求沉淀到 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. 付款复核对象与阶段编辑收口（本轮）

• 服务端将批次项编辑限制为 reviewed/failed 的凭证号与实际付款日期，拒绝任何创建后渠道覆盖；draft/executed/cancelled 均不可编辑。
• 服务端将回单上传/作废限制为 reviewed/failed，保留所有状态下的授权查看/下载；拒绝请求不写附件、存储对象或审计。
• 创建快照加入收款人姓名、开户银行和脱敏账户摘要；既有批次通过只读 fallback 补齐 DTO，不迁移或回写生产数据。
• 创建面板增加付款渠道选择并传既有 defaultPaymentChannel；默认银行转账，创建成功后重置。
• 详情待复核阶段隐藏付款登记输入和回单维护动作；复核后显示凭证号/日期与回单动作；已付款/已取消全部只读，四段结构和确认弹窗不变。
• 服务端测试覆盖状态矩阵、渠道锁定、零副作用和脱敏 DTO；前端测试覆盖创建 payload、待复核零编辑、复核后登记及已付款回单只读。
• 运行付款 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，未修改文件。

生产发布与资料门禁（2026-08-02，脱敏）：

• 提交 185d64d 已推送并通过既有安装固化入口部署；聚合体检 13 项、环境与数据合同、63 项 migration、/ready 构建标识、external deps、runtime smoke、付款能力常开、公网构建标识、前端资源扫描和部署后备份合同刷新全部通过。部署保持 SYNC_ENV=0，没有同步或覆盖生产环境文件。
• 首次生产只读核验仅输出固定检查项结论：目标员工记录 PASS，开户银行 FAIL，加密银行账号非空且可解密格式 FAIL；未输出账号、密文、路径、主机或原始 payload。管理员随后通过受支持的敏感资料 API 在本地浏览器补录，账号没有经过聊天、仓库或 SQL。
• 补录后按同一只读口径复核：目标员工记录、开户银行、加密银行账号非空且可解密格式三项全部 PASS。付款资料门禁解除；后续仍由真实业务人员取消旧批次并重建，再依次完成非制单复核、线下转账、回单上传和付款完成登记。