恢复付款入口与常开基线（08-01-reimbursement-notification-progress-clarity）

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

@@ -20,6 +20,8 @@
 - 保留付款 maker-checker：付款批次创建人与复核人不得相同，当前只需一次非制单复核，不增加更多复核层级。
 - 通知以“新的责任人需要行动”为准：提交后通知主管、主管通过后通知财务、创建付款批次后通知非制单复核人、付款复核后通知财务/批次创建人继续付款、付款完成后通知申请人。
 - 每周集中建立一次付款批次作为当前运行约定，不在本任务建设定时排程、自动组批或强制付款日。
+- 修复财务首次使用时的入口死锁：付款能力正式常开时，即使尚无付款批次，财务人员也必须能在 PC 和移动工作台看到“付款”入口并进入创建页。
+- 恢复生产 `payment_batch_v1` 正式常开基线，并防止新环境初始化或 QA 窗口收尾把正式常开状态静默改回关闭。
 
 ## Requirements
 
@@ -29,6 +31,9 @@
 - 普通员工页面不突出“付款批次”内部对象名；有付款批次权限的人员仍可通过现有权限门控入口查看批次。
 - 共享动作标签是唯一事实源；PC、移动和打印页不得继续维护互相漂移的局部映射。
 - 不删除主管审批、财务复核或付款复核，不放宽自审，不把付款完成伪装成审批通过。
+- 付款开关恢复前先查询 R54 变更历史；若当前库无变更审计，必须区分“seed 首次创建默认值”和“seed 覆盖已有值”，不得把不存在的 runner/人工操作写成根因。
+- QA 短窗口结束时必须恢复调用前快照；正式启用流程成功后保持常开，失败才回滚，不得无条件写死 `force_off`。
+- 正式环境和新初始化的试运行环境必须同时满足环境硬开关与数据库开关常开；任何一层关闭都应由部署/运行门禁发现。
 
 ## Acceptance Criteria
 
@@ -39,6 +44,9 @@
 - [ ] 创建付款批次后通知实际可复核人员；复核通过后通知实际付款责任人；付款完成继续通知申请人，且同一事件不会重复创建/投递。
 - [ ] 付款复核仍强制非制单人且仅一轮；既有付款批次、审批快照和历史记录不迁移、不改写。
 - [ ] PC/移动相关组件测试、通知路由/服务测试、付款 maker-checker 回归、前端 typecheck/build 与 Trellis 门禁通过。
+- [ ] 财务人员在尚无付款批次但存在已批准待付款报销时，PC 与移动端均可看到“付款”入口，并能看到该报销作为新建批次候选。
+- [ ] 正式初始化基线为付款批次常开；QA 窗口测试覆盖原值为 on/off 两种情况并恢复原值，不再硬编码关闭。
+- [ ] 生产恢复后只验证入口和候选可见，不代替财务创建批次、负责人复核或执行付款。
 
 ## Out of Scope