fix: 统一报销付款状态与进度（09-04-reimbursement-state-gap-finance-view）

.trellis/tasks/09-04-reimbursement-state-gap-finance-view/prd.md

@@ -2,6 +2,18 @@
 
 ## Goal
 
+### 2026-09-11 追加需求：付款下一步与详情侧栏一致性（已批准本地实施）
+
+用户反馈财务在报销详情同时看到“去组建付款批次”和已创建、已复核的付款进度。只记录脱敏状态矛盾，不复制真实截图、票据或金额。已发布 fe025e65 源码中右侧下一步及主动作只按报销 status=approved 判断，忽略已由服务端提供的付款阶段；报销进度插在主列材料之后，付款详情则在右栏操作下方。报销审批通过并不等于尚未组批，也不等于银行已经付款。
+
+- 操作、下一步和进度必须消费同一份权威付款阶段，不再各自仅由报销状态猜测。只有明确处于待组批且当前用户有组批权限时才展示组批入口；已存在有效批次时进入该批次，不重复组建。
+- 复用既有服务端 processingProgress、付款阶段语义和权限控制；批次入口不可因缺少 targetHref 而推断“未组批”。数据缺失、请求失败或不完整时不展示猜测性的创建入口。
+- PC 统一为主列业务内容/材料，右栏上方操作及下一步、下方当前处理进度；进度不在主列重复。长历史按既有授权完整保留，可折叠或进入历史区域，不能因侧栏变窄截掉意见/记录。手机保持单列及底栏动作，同类页面状态/下一步/进度顺序一致，不强做双栏。
+- 首批闭合报销详情、报销审批工作台与付款批次详情的状态/位置一致性；其他业务详情先列实际差异再按归属分批调整，不以“统一”重写全部页面、复制审批引擎或改变各业务状态机。
+- 按已批准体验复用现有侧栏/进度样式，不引入新视觉体系。全系统位置原则需在方案获批后同步既有产品规则及共享组件规约，避免现有规则仍允许两种位置。
+
+本阶段验收：无批次、待复核、已复核未制单、已制单未付、有回单待登记、已付款、失败/取消及数据未知分别有准确下一步；角色正反例和批次深链权限正确，同一目标入口不重复。必须在真实隔离角色链中创建/复核批次后返回原报销详情，比较动作、说明与进度；另测已打开页面重新聚焦/刷新，不能只检查付款页成功或源码存在某句文案。桌面与手机覆盖长材料、长意见、滚动、侧栏遮挡/溢出及显示唯一性。生产合成写入、消息发送和部署仍另批，不拿真人单据回放。
+
 ### 2026-09-09 后续阶段：退回报销的删除与重建
 
 本阶段归属复用，不重开原 R1/R2 的全部范围；综合顺序与验证见 09-08-reimbursement-payment-closeout 的最新 design/implement。用户已明确业务取向：退回后既能修改原单重提，也能删除旧单再创建报销提交；界面使用“删除”，不要求员工理解底层作废/留痕术语。2026-09-10 行业调研后用户确认本地实施；本追加阶段允许 design 中的 nullable 删除标记迁移，旧 R1/R2 的“无 schema 变更”约束不适用于本阶段。提交、推送及部署仍另批。