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

报销通知与处理进度简化

Goal

让报销单在 5–10 人公司的真实流程中做到两件事：新的责任人能及时收到待办通知；申请人能看懂“审批”和“付款处理”的区别，不再把四个动作误认为四轮审批。

Background

• 马建勇已在生产完成杨俊报销的主管审批，但下一节点王芝玲没有收到预期审批通知；王芝玲此前已通过企业微信登录，不能把问题归因于“从未登录”。
• 代码在报销提交和工作流流转时会创建 workflow.task_assigned，主管通过后也会生成下一任务并排队通知，因此应先区分“站内通知未生成”和“已生成但企微未投递”。
• 当前员工详情展示“付款批次复核”“付款与回单”，容易被理解为两轮额外审批；实际前者是非制单人付款复核，后者是财务线下付款后的回单与状态登记，不是审批。
• 当前职责基线：马建勇负责主管审批和非制单付款复核；王芝玲负责财务复核、创建付款批次、线下付款、上传回单和登记付款完成。一个付款批次可以覆盖多张报销单。
• client/src/lib/approvalDisplay.ts 已把 start 映射为“提交”，但 PC WorkflowTaskDetailPage.tsx 与移动 MobileApprovalsPage.tsx 各自复制了缺少 start 的局部映射，导致显示 start · 杨俊。
• 首张真实付款批次暴露了创建闭环的表达缺陷：服务端在创建事务内已经自动编号、锁定报销、生成付款复核通知并开始投递，但数据库状态和页面仍显示“草稿”，页面也不存在提交接口或提交按钮，导致制单人无法判断是否已经送审、由谁处理、下一步是什么。
• 生产只读核验确认该真实批次已经自动编号，当前未复核/未付款；付款复核通知已经生成并有企微成功投递。当前解析同时创建了 ceo 和 manager 两类站内收件记录，不符合“一个明确责任人、不要泛发”的小团队运行目标。

Scope

• 先做一次获批的生产只读诊断：只核对目标工作流任务、王芝玲对应站内通知是否存在、投递记录状态/固定错误分类、通知开关、企微绑定状态和渠道匹配状态；不读取 Secret、消息正文或原始企微 payload。
• 删除 PC/移动审批页重复的动作标签映射，统一使用共享 workflowActionLabel()；start 和 submit 均显示“提交”。
• 员工报销进度保留五个业务阶段，但改为：申请提交、主管审批、财务复核、付款复核、付款完成；付款完成明确为“财务登记，非审批环节”。
• 保留付款 maker-checker：付款批次创建人与复核人不得相同，当前只需一次非制单复核，不增加更多复核层级。
• 通知以“新的责任人需要行动”为准：提交后通知主管、主管通过后通知财务、创建付款批次后通知非制单复核人、付款复核后通知财务/批次创建人继续付款、付款完成后通知申请人。
• 每周集中建立一次付款批次作为当前运行约定，不在本任务建设定时排程、自动组批或强制付款日。
• 修复财务首次使用时的入口死锁：付款能力正式常开时，即使尚无付款批次，财务人员也必须能在 PC 和移动工作台看到“付款”入口并进入创建页。
• 恢复生产 payment_batch_v1 正式常开基线，并防止新环境初始化或 QA 窗口收尾把正式常开状态静默改回关闭。
• 收口付款批次创建到复核的首个真实闭环：创建页只要求选择待付款报销，编号、标题和常用付款默认值由服务端生成；创建动作明确等价于提交付款复核，不再让用户寻找不存在的二次提交按钮。
• 付款页用业务状态而非内部状态名表达下一责任：draft 显示“待付款复核”，reviewed 显示“待财务付款”，executed 显示“已付款”；详情说明当前责任职责和唯一下一步。
• 付款复核通知收件人按 ceo 优先、manager 兜底选择一个确定的非制单人；没有合格复核人时创建前失败并给出可解释提示，不生成无人负责的批次。

Requirements

• 通知诊断必须先判断站内通知是否生成，再进入企微投递层，不能直接假设缺少通知代码或重复创建通知。
• 若本次缺失由生产配置、人员推送开关、企微绑定或渠道配置造成，先给出脱敏根因和最小修复建议；任何生产写入、配置修改、补发消息或重启均需再次批准。
• 新增付款阶段通知时必须复用现有通知、投递和审计服务；通知只给真实需要行动的人，不向所有 finance/manager 角色泛发重复消息。
• 普通员工页面不突出“付款批次”内部对象名；有付款批次权限的人员仍可通过现有权限门控入口查看批次。
• 共享动作标签是唯一事实源；PC、移动和打印页不得继续维护互相漂移的局部映射。
• 不删除主管审批、财务复核或付款复核，不放宽自审，不把付款完成伪装成审批通过。
• 付款开关恢复前先查询 R54 变更历史；若当前库无变更审计，必须区分“seed 首次创建默认值”和“seed 覆盖已有值”，不得把不存在的 runner/人工操作写成根因。
• QA 短窗口结束时必须恢复调用前快照；正式启用流程成功后保持常开，失败才回滚，不得无条件写死 force_off。
• 正式环境和新初始化的试运行环境必须同时满足环境硬开关与数据库开关常开；任何一层关闭都应由部署/运行门禁发现。
• 付款批次内部仍可保留 draft 作为兼容状态，但该状态已代表“创建并提交、等待独立复核”，前端、通知和测试不得再把它描述成尚未提交的可编辑草稿。
• 新建批次不要求财务手工编批次名称、付款日期、渠道或凭证前缀；服务端继续自动生成唯一批次编号，按公司时区生成标题，默认付款渠道为银行转账，实际付款日期在登记付款完成时缺省取登记当天。异常项仍可在批次详情中覆盖。
• 付款动作必须使用“登记付款完成”等事实性文案，不得用“执行付款”暗示 OA 会连接银行或自动转账。
• 付款复核仍是一轮 maker-checker；责任收件人只选一个，优先具备复核权限的 active ceo，没有时再按稳定顺序选择 active manager，始终排除制单人。
• 付款页同一时刻只显示一个主动作：银行渠道复核通过但尚无有效回单时显示“上传银行回单”；上传后才显示“登记付款完成”，不能让用户先撞到 bank_receipt_required 才知道前置条件。
• 付款批次状态标签必须使用共享展示映射；列表、详情、移动响应式视图和相关测试不得各自复制 draft/reviewed/executed/failed/cancelled 中文文案。
• 付款详情保持现有列表内显式选择后的详情形态，不新增独立详情路由；信息顺序固定为“批次概要 → 当前处理/下一步 → 报销明细 → 银行回单”。顶部操作组始终承载当前唯一主动作，回单章节后移不得把“上传银行回单”推到明细列表之后。
• 付款页的列表、详情总额、批次项、确认弹窗和高风险阈值统一使用共享 formatMoney()；不得继续裸输出金额或在页面内新增货币格式化副本。
• 新建付款批次编号使用公司时区日期和三位日序号 PB-YYYYMMDD-NNN；既有编号不迁移。未显式传名称时自动标题为 YYYY-MM-DD 付款批次 NNN，显式名称原样保留。
• 日序号必须在创建批次的同一交互事务中，先取得双参数 PostgreSQL 事务级咨询锁，再查询当日严格新格式最大序号并创建；咨询锁使用固定 int4 命名空间和 int4 YYYYMMDD，不得依赖唯一冲突后的原事务内重试。
• draft 已表示“创建并提交、待付款复核”，批次项不得继续沿用未提交草稿的编辑权限；付款凭证号、实际付款日期和银行回单只能在 reviewed/failed 财务处理阶段维护，executed/cancelled 全部只读。
• 付款渠道在创建面板确定并作为复核事实提交，默认银行转账；创建后不得通过批次项覆盖改变，避免复核对象在复核前后漂移。
• 付款复核明细必须显示收款人姓名、开户银行和脱敏银行账户摘要；不得向付款批次 API 暴露完整账号或加密原值。新批次固化脱敏快照，既有批次以当前报销归属人只读降级展示。

Acceptance Criteria

• 脱敏证据能明确回答本次财务通知属于“未生成”还是“已生成未送达”，并定位到单一失败层或明确下一步，不包含通知正文、账号、Secret 或原始 payload。
• 马建勇通过主管审批后，王芝玲能够收到对应的新待办站内通知；企微投递恢复需另有真实投递证据后才能标为通过。
• PC 与移动审批处理历史均显示“提交 · 杨俊”，不再出现原始 start；动作标签映射只保留一个共享实现。
• 普通报销详情依次显示“申请提交、主管审批、财务复核、付款复核、付款完成”，并明确付款完成不是审批。
• 创建付款批次后通知实际可复核人员；复核通过后通知实际付款责任人；付款完成继续通知申请人，且同一事件不会重复创建/投递。
• 付款复核仍强制非制单人且仅一轮；既有付款批次、审批快照和历史记录不迁移、不改写。
• PC/移动相关组件测试、通知路由/服务测试、付款 maker-checker 回归、前端 typecheck/build 与 Trellis 门禁通过。
• 财务人员在尚无付款批次但存在已批准待付款报销时，PC 与移动端均可看到“付款”入口，并能看到该报销作为新建批次候选。
• 正式初始化基线为付款批次常开；QA 窗口测试覆盖原值为 on/off 两种情况并恢复原值，不再硬编码关闭。
• 生产恢复后只验证入口和候选可见，不代替财务创建批次、负责人复核或执行付款。
• 新建批次页面只需选择报销；提交后自动得到唯一编号、按公司时区生成的标题、银行转账默认渠道，并直接进入“待付款复核”。
• 创建按钮显示“创建并提交复核”，成功反馈明确“已提交，等待负责人复核”；页面不存在需要用户寻找的第二个提交动作。
• 制单人看到“待付款复核”和“负责人复核（制单人不可自审）”；实际复核人看到可用的“复核通过”；复核后财务看到“待财务付款”和“登记付款完成”。
• 同一批次只通知一个确定的非制单复核责任人，ceo 优先、manager 兜底；无合格复核人时拒绝创建且不写批次、批次项、审计或通知。
• 未填写实际付款日期时，登记付款完成以公司时区当天落账；银行转账仍要求先上传银行回单，OA 不执行真实转账。
• 银行渠道复核通过且没有有效回单时，唯一主动作是“上传银行回单”；上传成功后唯一主动作切换为“登记付款完成”，不会先触发可预见的 409。
• 无合格复核人的错误明确说明“复核人必须是非制单人且在职，请联系管理员”，不把配置问题伪装成财务人员操作错误。
• 既有真实批次不改 ID、不改金额、不改报销绑定、不改复核/付款事实；部署后仅获得新的业务文案和下一步说明，不替任何人推进状态。
• 既有报销批次渠道为空时按银行转账展示并执行回单门禁，但不回写历史记录；当前真实批次同样先上传回单再登记付款完成。
• 付款详情按“批次概要、当前处理/下一步、报销明细、银行回单”连续展示；各状态唯一主动作位于顶部，银行回单章节内不出现第二个同等级主按钮。
• 付款页所有人民币金额统一显示为 ¥1,234.56 形式，列表、详情、批次项、确认弹窗和高风险阈值无裸金额残留。
• 新批次编号为公司时区 PB-YYYYMMDD-NNN，同日并发创建得到唯一递增序号，跨日从 001 开始；超过 999 时 fail-closed，不改变编号格式。
• 自动标题在编号生成后使用相同日序号；调用方显式提供名称时不追加序号；旧编号保持原值且导出/AP/外部传递继续按不透明字符串兼容。
• 待付款复核期间批次项和回单均不可编辑；后端直接 PATCH/上传/作废请求同样拒绝，且不产生静默未审计变更。
• 创建批次时可选择付款渠道且默认银行转账；创建后渠道只读，复核人看到的渠道与创建事实一致。
• 每条付款明细显示收款人姓名、开户银行和脱敏账户摘要，不返回完整账号、密文或其他身份信息；当前既有批次无需迁移即可展示。
• reviewed/failed 允许登记凭证号、实际付款日期及维护回单；executed/cancelled 的回单与付款资料只读。

Out of Scope

• 不在本任务删除付款批次、付款复核或银行回单要求。
• 不接银行接口，不让 OA 自动执行真实付款。
• 不建设每周付款日排程、自动组批、批次自动复核或定时通知。
• 不在未获批准时修改生产通知渠道、员工推送开关、企微绑定、环境变量或服务状态。
• 不顺带重构全部审批页面或统一所有业务状态标签。
• 不新增“提交中”数据库状态或单独 submit API，不增加第二轮付款审批，不建设可配置的付款复核人选择器。
• 不把批次创建与财务复核合并，不由系统自动复核、自动上传回单或自动登记付款完成。

Deferred Decision With Trigger

• 本轮不合并“财务复核通过”和“加入/创建本周付款批次”。决定性依据是王芝玲尚未实际执行过财务复核，无法判断她会随到随审还是与周付款批次一起处理；提前合并可能迫使她延迟复核或频繁建批次。
• 触发条件：王芝玲累计处理 5–10 张真实报销单后，由负责人直接询问“财务复核与加入付款批次通常一次完成，还是分开完成？”若一次完成，再立小任务评估合并；若随到随审、定期组批，则永久保持两个动作分离。

Test Plan

• 聚焦测试动作标签、下一审批任务通知、付款批次创建/复核/执行通知和幂等性。
• 运行相关 server Vitest、付款并发/maker-checker 回归、客户端 typecheck/build 与相关 Playwright。
• 运行 task validate、Trellis governance、process contract、sensitive-content scan 与 git diff --check。
• 生产只读诊断和任何后续真机通知验证分开记录；没有实际企微到达证据时不得宣称通知已恢复。