fix: 优先引导下载银行制单（09-08-reimbursement-payment-closeout）

2026-09-09 09:05:17 +08:00
@@ -2872,3 +2872,60 @@ isManagementPath(pathname, permissions);
  <Eye aria-hidden="true" />
 </button>
 ```
+
+## Scenario: Payment Detail Guides First Order Before Receipt
+
+### Scope / Trigger
+
+The selected payment-batch detail after independent review, not the default
+payment ledger landing page. Reuse the existing desktop and mobile action model.
+
+### Signatures
+
+`PaymentBatchesPage.paymentActionModel`, `canExportPaymentOrder`,
+`paymentOrderExportCount`, `needsBankReceipt`, `canRegisterPaymentComplete`.
+The backend remains authoritative for reviewed status, role and snapshot checks.
+
+### Contracts
+
+- A reviewed, exportable bank batch with no generated order and no receipt uses
+  `下载银行制单` as its single primary action. Do not ask for a bank receipt before
+  exposing the first order needed to make that payment.
+- Keep `上传银行回单` in `更多` for users who already paid manually; generating an
+  order is not a new hard prerequisite for recording a legitimate payment.
+- After first generation, use `上传银行回单` as primary and put re-download in
+  `更多`. With an existing receipt, keep `登记付款完成` primary even if no order
+  was generated. Unknown receipt state is not an empty receipt list.
+- Re-download requires a reason and the duplicate-bank-submission warning.
+  Download success must not execute a payment, upload a receipt or mark paid.
+- Legacy/non-bank/non-exportable batches retain the existing manual flow.
+  Do not add roles, bypass backend guards or change the payment state machine.
+
+### Validation / Error Matrix
+
+| State | Primary | Additional route |
+| --- | --- | --- |
+| Reviewed, exportable, first order, no receipt | Download order | Manual receipt upload in more |
+| Order generated, no receipt | Upload receipt | Re-download in more |
+| Receipt already present | Register payment complete | Existing allowed order actions |
+| Download fails | Keep download step | Reason dialog remains; no payment mutation |
+| Receipt query fails | No upload/complete primary inferred from absence | Reload/error feedback |
+
+### Good / Bad Cases
+
+Good: finance downloads the approved batch file, then receives a receipt prompt.
+Bad: hiding first generation behind more while prompting for a not-yet-existing
+receipt; or requiring an export before accepting an already-completed manual payment.
+
+### Tests Required
+
+Desktop/mobile first download, reason/cancel, received BIFF8 bytes, re-download
+warning and no payment mutation, manual upload via the actual file chooser,
+existing-receipt and non-bank behavior, and unknown-receipt refusal. Keep backend
+authorization and independent workbook parsing tests separate from browser mocks.
+
+### Wrong vs Correct
+
+Wrong: a visible action or a generated file proves money was paid.
+Correct: file generation, bank execution and OA payment registration are distinct
+events. Synthetic browser/backend/container checks do not prove real bank acceptance.
@@ -0,0 +1,67 @@
+# 业务闭环方案（规划，未实施）
+
+## 1. 复用而非重建
+
+现有入口是付款页面的待组批、付款批次、复核及“下载银行制单”。后端 POST /api/payment-batches/:id/payment-order 要求财务角色与 payment.order.export，批次 reviewed，完整且可用的同源收付款快照。生成成功会更新导出计数和审计；不能把这个 POST 当作生产只读预检。
+
+代码入口：server/src/routes/paymentBatches.js、server/src/services/paymentOrderXls.js、server/src/scripts/fill-payment-order-template.py、client/src/pages/PaymentBatchesPage.tsx。历史范围见 archive/2026-08/08-02-corporate-bank-account-payment-order，本 task 不重开已完成实现。
+
+## 2. 模板映射
+
+| 列 | 模板字段 | 报销付款来源/行为 |
+| --- | --- | --- |
+| 1 | 序号 | 稳定排序的批次行号，文本 |
+| 2–3 | 付款方账号/账户名称 | 复核批次冻结的公司付款账户 |
+| 4 | 收款方行别代码 | CCB 本行固定文本 01，不生成他行 02 |
+| 5–7 | 收款账号/名称/开户行名称 | 同一批次的收款快照 |
+| 8 | 收款方联行号 | 沿现有本行制单合同留空 |
+| 9 | 客户方流水号 | 批次号+行号，稳定、唯一并满足长度限制 |
+| 10 | 金额 | 已批准批次项金额，数值且两位小数 |
+| 11 | 用途 | 报销款，不复制工资/公积金用途 |
+| 12 | 备注 | 报销单号 |
+| 13–15 | 短信标志/手机/附加信息 | 0、不通知，后两列空；不读样例手机号 |
+
+用户三个 input 文档的表头完全一致，空白模板与内置模板相同，账号列为文本。检查原件只提取结构与摘要，原件不改、不重新保存、不复制真实行到测试夹具。工资及公积金样例仅用于确定文件格式，不暗中扩为新业务。
+
+## 3. 两条业务线
+
+A：0014 当前已审批待付款 → 核定归属/主体 → 管理员直接维护真实 CCB 收款资料 → 财务重查 readiness → 财务组批 → 独立付款复核 → 财务下载 .xls → 授权人员网银导入核对并付款 → 回单与实际结果匹配 → 系统登记。
+
+B：三张 rejected → 本人逐张修改 → 本人重提 → 实际审批人处理 → 通过后进入下一批付款。不等 A 或 AP 发布；未通过不能直接放入付款批次。
+
+## 4. 停止条件与授权
+
+- 身份、单号、原值不一致，或收付款资料非 CCB：停止对应操作，不按名字/唯一主体猜值。
+- 生产 legal_entity_id 修正：单人单字段、前置锁定和原值检查、条件写入、提交后独立回读；须单独授权。失败不自动反复重试，回退另批。
+- 银行真实资料由管理员/获授权维护人直接在系统录入；不让财务通过聊天转交卡号给执行端。
+- 解密/生成真实制单涉及敏感数据；按明确范围批准，只输出脱敏验收结果。正式下载由财务操作且保留审计，不用管理员或伪身份抵扣。
+- 已存在批次、复核不通过、资料变动或旧快照缺失：核实实际状态，不删批次或改数据库状态绕过。是否重建批次另行决定。
+- 银行导入失败、部分成功或回单未核对：不标全批成功，不因重下载重复付款。
+
+## 5. AP 发布独立处理
+
+AP task 保留原实施写入面和已通过用户复核。提交/推送后冻结包含 CEO 撤权的完整新 SHA，重新核对发布所需时效、回滚制品和生产漂移；旧 58dcee0 不再是正确候选。没有新发布授权就不部署，不能因业务急付款而默认豁免门禁。
+
+## 6. 验证层级
+
+1. 首轮规划完成静态源码与原件结构检查；用户追加技术审查/修复授权后运行定向合成测试，并在当前生产容器以独立合成密钥和纯合成资料验证制单运行环境。后者不访问数据库、不用真实密钥、不读取真实银行卡、不调用正式导出接口、不落制单文件。
+2. 执行阶段先用合成收付款数据核验模板、BIFF8、金额与文本类型、未复核拒绝、非建行拒绝、重下载与审计、付款角色分离；已有测试能复用则不另造。
+3. 获准核实生产模板摘要、Python/固定依赖等运行前提时，不顺手触发真实导出；代码基线存在功能不等于生产运行时可用。
+4. 真实财务路径、银行导入结果与最终回单属于业务验收，合成测试不能抵扣；分别记录未执行/通过/阻断，不提前全绿。
+
+## 7. 八角度复核与修订
+
+| 角度 | 审查结论 | 处理 |
+| --- | --- | --- |
+| 业务优先级 | 已审批 0014 和退回三单是不同状态，不互等 | 维持两条业务线，不把 AP/门禁作为重提前置 |
+| 角色职责 | 财务可制单不等于可改员工银行卡；admin 通配也不替代制单路由的财务角色要求 | 管理员录资料，真实财务组批/导出，非制单人复核；不加权限 |
+| 资料与隐私 | 付款方账户已有，但个人收款资料和所属主体缺失仍是真实阻断 | 按原值另批补 0014 归属人，不批量关联 smoke；敏感资料不进聊天 |
+| 财务操作顺序 | 当前详情页未制单先把上传回单作为主动作，下载藏在更多，与原银行制单合同及本轮顺序冲突 | 最小修复动作模型：首次下载→上传回单→登记完成；人工上传保留在更多，不添加硬门禁 |
+| 格式兼容 | 原件和内置模板一致；既有测试只验文件头、行数、总额等，缺少独立逐列读回 | 新增 xlrd 对生成文件的表头、列宽、工作表、前导零文本、金额与用途/备注读回断言 |
+| 运行环境 | 本地普通 Python 可能无 BIFF8 依赖，不能据此推断生产缺失 | 使用既有固定 venv；生产容器合成生成/独立读回 PASS，不安装新依赖，不改生产 |
+| 失败与重试 | 下载有审计写入；导出不等于付款，网络失败后的重下载也不能重复银行划款 | 补下载原因/取消零请求、文件成功下载、重下载警示、失败不推进状态、手工回单入口测试 |
+| 发布与实际付款 | 当前正确 AP 修订与本轮界面补丁都未部署；银行文件“验证”和真正导入可能不分离 | 新候选另批；只有网银明确支持不提交的校验模式才做真实文件格式校验，否则不为测试上传文件，实际付款须按业务批准办理 |
+
+本轮界面修复仅改变已选付款详情的动作优先级，继续使用既有按钮/更多/移动端固定操作区，不重画页面、不调整角色、审批、付款状态机、数据快照或后台接口。保留现金/历史批次人工付款、已有回单直接登记及回单查询失败时不冒充空状态的行为。
+
+报销主体和收款资料应在组批前补齐，因为批次冻结的是当时的账户快照；生成文件不能静默取之后变更的个人账号替换已复核快照。已有批次若需取消/重建，重新交审，不直接更新旧快照。
@@ -0,0 +1,146 @@
+# 执行顺序（本地技术审查/修复已批准，真实业务动作另批）
+
+## 2026-09-08 获批技术执行
+
+1. 检查 CLI/项目/npm 稳定版本及官方 update dry-run；保留现有定制，稳定通道无新版则不切 beta、不强刷文件。
+2. 从业务先后、身份权限、资料安全、状态一致性、模板兼容、运行依赖、失败重试、部署边界八方面审查计划与实现。
+3. 先运行付款 readiness、公司账户、复核/执行、BIFF8、审批退回相关定向单测；浏览器仅运行本地合成的付款路径，不运行已挂起的合同/真实账号全链用例。
+4. 发现影响本业务的具体代码缺陷先用最小失败用例复现，再修复并回归；只缺生产资料的项目不冒充代码故障。仅存在覆盖缺口则补针对性验证，不宣布实际业务已完成。
+5. 输出已修技术项、仍须真人操作的数据项、未验证生产项；只读复核由用户完成，不派代理，不自动提交或部署。
+
+证据根目录：artifacts/qa-flow/reimbursement-payment-closeout/technical-review-20260908/。开始前完整 Git 状态、tracked 摘要、未提交 diff 和 index diff 已保存；既有 AP 修订/其他 task 不回滚、不混报。
+
+## 技术阶段结果（本地完成，待用户复核，不等于业务完成）
+
+### 2026-09-08 追加单字段生产授权
+
+用户在“另行批准只补 0014 归属人的主体；银行资料由授权管理员直接录系统”之后回复“同意，批准”。本次仅执行 0014 归属人 legal_entity_id 从空值关联当前唯一启用未归档主体；不扩展为银行资料写入、解密、提交、推送、部署或真实付款授权。
+
+只读预检通过：0014 唯一、approved 且未付、归属人是已确认 majianyong、角色 ceo+employee、主体字段为空、无付款批次项占用、目标主体唯一。员工 UPDATE 触发器/规则摘要与前次已审单字段修正一致。生产仍为 f223bfb。执行时再次锁定核对身份/状态/原值/目标摘要，条件更新恰好一行，再提交并以独立连接只读回读；失败不自动重试，提交状态不明时不宣称回滚。
+
+证据目录：artifacts/qa-flow/reimbursement-payment-closeout/legal-entity-correction-20260908/。脚本仅读取身份与状态必要字段，不读取金额、票据、银行字段或真实密钥，输出脱敏核对结果。
+
+执行结果：2026-09-08 北京时间 22:30，PASS_APPLIED_AND_READBACK；条件更新 1 行，原值为空，独立连接回读与获批主体一致，角色保持不变。仅更新 employees.legal_entity_id，不改单据、批次、银行字段或审批关系。个人银行资料当前是否补齐未重新查询，不宣称财务已可组批或付款。语法检查、task validate、治理及 diff 检查通过；主会话自审，不冒充独立人员复核。回退需要另批，且应以本次目标值为原值进行条件检查，不自动清空。
+
+- Trellis：CLI/项目均为 0.6.16，npm 的 CLI/core stable latest 同为 0.6.16；beta 为 0.7.0-beta.3，不切预发布通道。按官方 upgrade --dry-run 和 update --dry-run 核验，无稳定版本升级；11 个项目定制文件保持原样，没有执行 force 覆盖、全局安装或改模板哈希。记录见 trellis-registry-tags.json、trellis-core-registry-tags.json 和两份 dry-run 日志。
+- 八角度规划审查已完成并写入 design.md 第 7 节：业务先后、角色、资料隐私、操作顺序、格式、运行环境、失败重试、发布/银行授权。保留单据资料与技术问题的区分，不批量回填、不扩大角色或付款规则。
+- 确认并修复一项界面顺序债：已复核且可制单、尚未生成且无回单的详情优先下载，生成后转上传回单；手工付款用户仍可在更多直接上传，已有回单仍可登记。使用既有样式/动作模型，运行时仅 client/src/pages/PaymentBatchesPage.tsx 一个文件新增变化；前后端权限、付款接口、审批及数据库均未修改。
+- 先补断言再修：browser-red.log 明确复现首个下载动作被隐藏，1 条失败；该失败发生在登录成功后的动作断言，不是认证/网络前置。后续桌面/移动端测试实际收到了合成 .xls 文件，核对文件字节、原因/取消、重下载警示和不触发付款，且通过真实 filechooser 保留手工上传路径。
+- 后端最终 9 文件 158/158 PASS（backend-verified.log），包括 readiness、付款账户、复核/执行/回单/导出、报销提交与退回通知、CEO/经理解析及新增的独立 BIFF8 逐列读回。新增 readback 初次因测试直接访问未配置的第 15 列宽触发 KeyError；改用 xlrd 的有效列宽 API 后通过，保留诊断日志，不当作生产缺陷。
+- 浏览器同一最终源码的 16 条目标用例全部已覆盖通过，分两次完成：browser-final.log 为 13 PASS + 3 因本地 Vite 退出导致登录连接拒绝而未能执行；未改代码/断言，恢复同源服务后仅补跑这 3 条，browser-boundary-rerun.log 为 3/3 PASS。不是一次 16/16 全绿；自动 retries 始终为 0。之前 browser-payment.log 的 2 条失败是新增合成文件 helper 在 ESM 中误用 require，改为 createRequire 后通过，不混入业务缺陷清单。
+- 本地环境前置：全新 context、原生在线采样 true、无 cookie、表单可见、监听 refresh=0，不安装 route mock；见 browser-environment.json。随后用例 API 均为合成 mock，不能冒充真实后端端到端或生产账号验收。Vite 中途退出原因未进一步归因；补跑把服务与测试绑定在同一受控 shell 生命周期，结束自动停止，未改全局诊断 harness。
+- 当前生产容器 f223bfb 的纯合成制单探针 PASS（runtime-synthetic.json）：内置模板摘要、BIFF8/3 sheet/15 列、表头、前导零账号文本、01 行别、金额均由独立 Python 读回确认。使用独立合成密钥与资料，不访问 DB、不读真实银行数据、不用真实密钥、不调用正式导出接口、不落制单文件；不代替真实账户解密或网银验收。
+- npm run typecheck、独立 artifacts 目录 vite build、task validate、Trellis governance、process contract、git diff --check 均通过。文档注册检查通过但保留既有 1 项 warning（22 个未登记文档），构建保留既有 Browserslist 陈旧提示，不升级无关依赖。
+- 范围核对 scope-check.json：相对本轮开始只改变 4 个已跟踪文件（付款页面、两份测试、前端规约），外加当前未跟踪 task 文档；既有 AP 包及其他 tracked 改动摘要不变，index 不变。原始 input 和归档截图没有写入，不提交/推送/部署，不更新生产资料。新动作顺序尚未上线，线上仍可使用既有更多中的制单入口。
+- 桌面和移动端截图已主会话查看，确认主动作切换使用既有区域、人工路径保留；它们是合成页面，不是生产截图。本轮是主会话多角度自审及验证，不冒充独立人员复核；用户可审 technical-code.diff 和本 task。
+
+### 复验命令
+
+```bash
+trellis upgrade --dry-run
+trellis update --dry-run
+cd server
+PAYMENT_ORDER_PYTHON_BIN=<既有固定BIFF8虚拟环境解释器> npm test -- tests/unit/services/paymentOrderXls.test.js tests/unit/services/paymentBatchReadiness.test.js tests/unit/services/paymentProcessingProgress.test.js tests/unit/routes/paymentBatches.reimbursement.test.js tests/unit/routes/paymentAccounts.test.js tests/unit/routes/reimbursements.payment-batch-gate.test.js tests/unit/routes/reimbursement.submit-side-effects.test.js tests/unit/utils/workflow.test.js tests/unit/routes/workflow.return-notifications.test.js
+cd ../client
+npm run typecheck
+./node_modules/.bin/vite build --outDir ../artifacts/qa-flow/reimbursement-payment-closeout/technical-review-20260908/build
+PAYMENT_ORDER_PYTHON_BIN=<同一解释器> E2E_MODE=local E2E_BASE_URL=http://127.0.0.1:23121 ./node_modules/.bin/playwright test tests/e2e/system-action-confirmation.spec.ts --grep '付款|回单|制单|移动端固定操作区' --workers=1 --retries=0 --trace=on --reporter=list --output=<独立结果目录>
+```
+
+最后三条补跑使用同一 spec 与参数，仅 grep 改为“只有超级管理员职责|兼任付款复核职责|回单查询失败”，服务生命周期与测试同一 shell 管理。针对性结果不抵扣 58 条清单，也不充当 R1 所需完整候选全绿耗时。
+
+| 优先级/工作包 | 主责 | 动作 | 结束判据 | 当前状态 |
+| --- | --- | --- | --- | --- |
+| P0 0014 付款资料解阻 | 执行端核对，用户批准，管理员录资料 | 主体已单独获批补齐并回读；管理员录真实收款银行/卡；获准检查公司付款账户可用性 | 实际财务页面不再因这些缺项禁用，其他 readiness 阻断如实列出 | 主体已补；银行资料与完整 readiness 未验，不宣称可付款 |
+| P0 三张退回单重提 | majianyong，实际审批人 | 按退回理由逐张修改重提并实际审批，不代操作 | 每张有重提/审批结果或具体缺项，付款进度另算 | 待本人操作 |
+| P1 付款复核与 .xls 制单 | wangzhiling，合格非制单复核人 | 财务组批，实际独立复核，填写原因下载模板制单；必要时先跑合成回归与获准运行时预检 | reviewed 后成功生成同模板 .xls；未复核拒绝；无敏感日志 | 既有功能，真实闭环未验 |
+| P1 银行付款与回单 | 用户指定的银行操作人，财务 | 网银导入核对、银行批准执行、回单核对、系统登记 | 实际银行结果与系统付款状态/回单一致 | 尚未付款；操作人待实际指定 |
+| 独立 AP 发布收口 | 执行端，用户批准 | 仅已审 AP 增量提交/推送、新候选、时效与漂移复核、单独授权部署 | 正确新版本及 AP 角色矩阵验收 | 复核通过，未提交/部署，不阻塞以上资料整理 |
+
+## 本轮完成的准备
+
+- 阅读 input 中三份制单 xls 的结构；空白模板与内置模板字节相同，均为 3 sheet/15 列合同，两份已填样例表头一致。未输出真实数据、未修改原件。
+- 确认现有 reviewed 后制单功能、财务导出守卫和导出审计；相关功能文件相对生产基线 f223bfb 无 Git 差异。不把源码存在当作生产成功生成或银行导入通过。
+- 新建一个业务闭环 planning task，复用旧付款准备包/已完成制单实现/AP task，不一次拆出多份待实施任务，不启动产品开发。
+
+## 汇报纪律
+
+后续只按“0014 是否可组批/已复核/已制单/银行已付/回单已核”“三张单各自是否重提/审批”汇报。维护业务进度与部署进度两个独立判断，不以文件数、测试数或已通知代替业务结果。
+
+## 暂停项
+
+全员主体回填、新员工自动关联、工资/公积金业务扩展、银行自动付款、六个 view_all、58 条红项、阶段 B、R1 均不进入本轮实施。
+
+## 2026-09-09 综合审查后的后续任务规划（待批准，不扩展本 task 实施范围）
+
+本节按用户要求综合主会话三视角审查与外部审查建议，复用当前记录保存后续独立任务清单；不批量新建 task、不自动提交/推送、部署、执行真实恢复或修改生产配置。后续新任务只在到达队首且范围获批后创建，现有任务只做经批准的方案修订。付款主线目前由用户要求等待。
+
+业务最新证据：用户于 2026-09-09 提供财务页面截图，0014 已创建付款批次，待付款复核 0/1、银行制单未生成、报销仍待付款。证明组批已发生，不证明负责人已收到提醒、已复核、已制单或银行已付。既有“资料待补/尚未组批”是此前历史状态，不再当作当前阻断；本节未查询生产。
+
+### 规划裁决
+
+- 恢复验真改用受控人工最小路径，不继续叠加安装器/runner。不能把 Attempt 3 非零且底层原因未知归结为已证实工具故障，也不能认定备份损坏。
+- “数据库还原并数表”只回答该批次数据库能否恢复，不代表附件、应用启动、正式切换或完整灾备能力。恢复目标隔离、合法管理员通道、批次身份/完整性、失败诊断和精确清理不得删除。
+- 统一待办上调为跨模块业务交接任务，不再仅作为页面文案优化。既有依据为 09-05 错误解释 task implement §12、09-06 付款观察 task design §3；当前没有已批准的独立统一待办实现任务。
+- 2026-10-05 距当前 2026-09-09 为 26 天。错误基线有 673 条指纹记录、695 次调用、73 个文件；不是 673 个已确认缺陷。清单分流现在启动规划，不等恢复/seed/待办做完；实施按独立提交单元排队。
+- 不承诺“一个下午必成功”；第一次最小恢复以一个有界操作窗口为目标，遇失败收集脱敏原因并停止，不在现场加装置或自动反复尝试。
+
+### 队列与验收合同
+
+| 工作包 | Trellis 归属 | 范围/交付 | 完成判据与停止边界 |
+| --- | --- | --- | --- |
+| T0 两笔已审改动收口 | 复用 09-07-manager-ap-access-scope 与本 task | 按路径拆 AP 与付款按钮/制单测试两笔，分别引用 task；在 AP 包内纠正 task.json 的“保留 CEO 财务读取”陈旧摘要；分别记录代码/发布/业务验收/等谁 | 不漏既有文件、不混其他 task；提交、推送须明确批准，部署另批；必要复验针对各自增量，不批量归档。不以 Git 暂存路径隔离冒充 worktree 物理隔离 |
+| T1 最小正式备份恢复验真 | 修订 08-23-isolated-backup-restore-drill，保留原历史 AC | ARM 已获准管理员通道，读取执行时最新正式备份；一次性无宿主端口 PG16，使用现有 restore-db.sh；先形成数据库结果，再单列配对附件结果 | 批次身份/摘要/新鲜度核验；目标非生产且无生产数据库连接；恢复命令全程退出 0、源 migration 对照及既定关键表可读；附件需另验解包/引用/适用摘要。DB PASS 不关闭原整体 task；任一失败保留阶段与安全原因，清理仅本轮目标，不删正式归档 |
+| T2 日常发布与初始化分离 | 待新建独立 existing-deploy-seed-separation task；关联 09-05-existing-deploy-db-lifecycle-isolation | 保留 initialize 的初始化能力；existing 不再无条件运行覆盖既有配置的 seed；确有升级数据变更时走明确版本化步骤 | 合成库验证 initialize 可用、existing 不改管理员既有配置、重复发布语义稳定、缺配置有明确停止/补救路径；迁移、配置版本、旧版本兼容与回滚边界明确；既有 DB 生命周期隔离回归不退步。先验证再改变默认发布路径，真实部署另批 |
+| T3 统一业务待办投影 MVP | 待新建 reimbursement-payment-todo-projection task；复用 09-06 观察记录 | 首批仅报销退回补改、财务待组批、付款待复核、复核后财务制单/付款登记四类；既有业务状态为事实源，复用待办/首页/通知能力，不建第二套审批引擎 | 接收人不用口头转述即可从工作台找到本人的下一步，数量与明细一致、深链有权可达；制单人不自审、不扩 AP 读取；处理后消除陈旧待办，通知失败不丢待办且有可观测重试，重复刷新/投递不重复任务。正式通知和真人流程另批；缺失交接样本保留未验，不用管理员代验抵扣 |
+| T4a 员工业务就绪检查 | 待新建 employee-business-readiness task | 能登录/能提交/能付款分阶段检查；解释缺项、维护责任与入口，复用现有审批解析/readiness，不另造一套判定 | 覆盖负责人兜底、普通员工、缺经理、缺主体/银行卡、无权限维护、smoke 排除；不在入职时强收银行资料，不自动回填真实记录，不为补资料扩大财务权限 |
+| T4b 职责与数据范围表 | 先做设计交付，关联 AP task；实现单独定范围 | 按已确认真实账号列审批/复核、全量读取、资料维护、付款执行四类能力；明确 view_all 未决项 | 用户逐项裁决；保留 CEO 审批路由、多角色权限并集及现有合法业务上下文。没有业务裁决不改六个 view_all，不摘角色，不以任务完成声称全部数据范围已收窄 |
+| E 错误豁免到期分流 | 复用 09-05-error-explainability-payment-readiness，新增经批准的后续阶段 | 现在按文件/调用指纹列“本期迁移/有理由延期/已失效待核销”，指定责任人与各自验收/复审日期 | 保留首批主链路不得豁免、新旧调用结构校验、到期失效规则；延期逐模块审查并保留原到期日与原因，不批量改日期、不删规则凑绿；不能把目录删除或无命中直接当豁免已解决 |
+
+T0 是新增代码工作的前置；T1 数据库路径获成功证据后推进 T2，配对附件仍作为独立恢复缺口保留，不能用 DB PASS 自动授权 T2 生产发布。T1 若有未解释的恢复非零，不以“时间已到”越过风险继续生产部署。T3 的已发生交接证据整理、T4b 职责设计和 E 分流可与 T1 规划并行，但主会话不派实现/检查代理，不在当前脏树叠加第三笔产品改动。T2 本地实施通过后，T3/T4 按业务价值排队，不要求所有基础任务整体归档才允许业务规划前进。
+
+### T1 最小操作与保留保障
+
+使用 ARM 现有正式归档与已有合法管理员操作路径，不把真实备份下载到开发机，不用生产容器作为恢复目标，不新增 sudoers 或修改目录权限。执行前确认资源余量、唯一批次、manifest 配对、大小/摘要、备份年龄和 PG/来源版本；创建本轮专用影子库、只挂载该批次只读数据或使用 stdin、无宿主端口，不挂生产数据卷，不启动 OA/worker、不执行迁移或 seed。
+
+先独立确认数据库目标就绪并符合 restore-db.sh 的 shadow/名称确认门禁，执行既有恢复脚本，检查其退出码及源 migration/关键表可读性。表计数仅为一致性线索，不能代替完整恢复退出状态或凭空声明与生产逐表一致。若只完成数据库，结果明确写 DB_RESTORE_PASS、STORAGE_NOT_TESTED、APP_NOT_TESTED；附件完成后才补相应状态。原任务完整验收不被这项缩小后的实验替代。
+
+操作保留简短脱敏回执：批次指纹、开始结束时间、数据库结果、附件结果、失败阶段/可安全提取的原因、清理结果。不强制新增 RTO 分段框架；不删除原正式演练要求，相关指标未测就保留未测。原始敏感错误仅留受控位置按既有隐私规则处理，清理前形成安全诊断，避免重演 Attempt 3 丢失原因。精确清理本轮一次性容器/卷/临时数据并回查，不清理旧镜像备份、正式归档或未知对象。
+
+### T3 输入边界
+
+目前只确认资料已补且财务成功组批，并观察到后续操作需通过聊天指引；尚未实际观察 majianyong 是否从现有待办/消息找到复核、复核后财务是否收到交接。三张退回单的“本人未处理”不能单独证明没有发通知。规划阶段分别核对业务状态投影、接收人解析、通知创建/投递和消息深链，不把四类不同故障预先合并成同一个已证实代码缺陷。已发生样本先定合同，后续样本用于补验，不伪造、不中断当前真人流程抓证据。
+
+### E 初步模块分流与建议日期（待批准，不是已承诺全部迁移）
+
+- 优先审查名单：auth/users/employees（登录与员工资料），workflow 路由及解析（审批人/退回），paymentAccounts/AP（付款资料和权限），todos/notifications/portal（交接可解释性），invoicePool（报销票据主链路）。按具体仍为 legacy 的调用选高频阻断，不重复迁移已覆盖的报销/付款主链路，也不假设这些模块的全部调用都必须本期完成。
+- 次优先核对：采购/差旅、部门与主数据、预算/项目、合同；根据当前真人使用和变更范围决定迁移或有理由延期，不能仅因调用数大就统一延期。
+- 其余模块：逐文件列剩余指纹、业务影响、现有兜底、责任人、拟新日期与理由后交审；低频或暂未使用需有依据，不把工资/绩效/资产等默认判定无人使用。当前仅形成模块初分，没有修改任何豁免。
+- 建议 2026-09-11 前完成 73 文件全量处置清单；09-18 完成首批高频调用的迁移与定向验证；09-25 复审剩余容量和延期理由；09-30 前完成逐模块延期裁决；10-02 做一次剩余到期项检查。不得等到 10-05 才改日期。
+- 当前门禁以 UTC 日期判断 expiresOn <= today 即失效，因此 2026-10-05 00:00 UTC（北京时间 08:00）即触发该日期的到期项，不按北京时间当天午夜前仍有效来安排。全部 673 条同日到期属于计划风险，不等于当天线上功能会自动停用。
+
+### 明确不做
+
+本轮不执行提交/推送/恢复/部署，不改变任何账号或真实银行资料，不自动发送通知或审批/付款；不增加通用 workflow 引擎、全站重设计、微服务、大文件专项重构、全员主体回填；58 条红项、合同阶段 B、R1 仍暂停。独立任务规划不改变当前付款 task 的业务完成判据，也不授权把其余改动顺带提交。
+
+
+## 2026-09-09 综合规划批准后的首批本地执行
+
+用户回复“开始实施”，综合规划的本地工作进入执行。审批、真实付款仍按用户要求等待；此次未获得提交/推送、ARM真实恢复或部署的单独授权，不将开始实施扩大解释为这些操作。
+
+- T0：AP和付款建立两个独立detached交审副本，另一个ops-preparation副本仅维护原恢复task及错误解释task的准备文档。不是新开第三笔产品开发；原工作树保留，未重置或覆盖已有改动。
+- 付款副本仅包含4个已审tracked文件和本task；未包含AP撤权差异。后端9文件158/158通过，使用已有固定BIFF8环境，无安装新依赖。浏览器未重新运行，不把此前13+3分轮证据改成新的同轮通过。
+- E：673指纹/695调用/73文件逐项对上当前源码，原expiry和门禁不改；全量清单在独立准备副本的原错误解释task implement §13。16文件优先审查、25文件业务影响复核、32文件逐模块审查延期理由；未逐调用完成业务裁决，未批准任何延期，也未迁移新原因码。
+- T1：独立准备副本内修订原恢复task的最小人工操作阶段，复用3份既有恢复/校验脚本，保留正式演练AC；没有创建新runner、修改sudoers、连接远端或读取真实备份。
+- T2/T3/T4未开新的代码任务，既有58条、阶段B、R1不动。原因码分支迁移尚未开始，不能以“清单完成”宣布技术债清零。
+
+| 代码 | 发布 | 业务验收 | 等谁 |
+| --- | --- | --- | --- |
+| 付款按钮/制单验证已审，独立副本已隔离复验 | 未提交/推送/部署，线上仍是既有更多入口 | 用户截图确认0014已建批；待复核0/1、制单未生成、未确认付款 | 业务按用户要求等待；技术先等两笔提交的明确授权 |
+
+证据根为原主工作区 `artifacts/qa-flow/project-roadmap-execution-20260909/`。提交建议标题：`fix: 优先引导下载银行制单（09-08-reimbursement-payment-closeout）`；不自动提交或把其他准备文档混进这一笔。
+
+
+## 2026-09-09 提交与推送授权
+
+用户对“AP 与付款修复分两笔提交并推送，不部署、不执行真实恢复、不混入后续准备文档”明确回复“是”。本次只提交本 task 对应已隔离交审文件及当前授权记录；原恢复 task、错误豁免后续阶段和另外两个未跟踪 task 不进入这两笔。实际提交 SHA 与远端结果以 Git 回执为准，不提前宣称 push 成功；生产仍未部署，业务验收状态不随提交改变。
@@ -0,0 +1,62 @@
+# 报销付款与银行制单业务闭环
+
+## Goal
+
+以业务结果为目标：已审批未付款的 0014 完成付款准备、独立付款复核、按用户模板生成建行制单、银行付款及回单登记；三张退回报销由本人修改重提，实际审批后再进入付款，不让两条业务线互相等待。
+
+2026-09-08 首轮为规划；用户随后明确批准检查并按指南更新 Trellis、多角度审查修订计划，以及完成影响这些业务的技术债务。当前执行范围为本地技术审查、针对性合成验证和已定位阻断的最小修复；不改变既有人工制单/网银流程。未批准生产数据回填、真实账号解密、真实提交/审批/组批/导出/付款、部署或外部通知。此前财务直接经理单字段修正已完成，不重复操作。
+
+## 已核实依据
+
+- 截图显示 0014 待组批且被三项阻断：归属人缺公司主体、收款银行缺失、收款账号缺失。截图不是完整 readiness 通过证明，不凭页面人员名称替代写入前 owner_id 核实。
+- 最新只读结果：一个启用未归档主体、一条匹配该主体的启用建行付款账户，密文字段非空；解密可用性未验证。公司付款账户不等于个人收款账户，不重复创建已有账户。
+- 用户确认 E1/E3/E5/E6 为 smoke 账号，排除在业务回填范围外。只先准备 0014 归属人的单字段主体修正，不批量回填所有员工。
+- input/制单模板.xls 与 server/src/assets/payment-order/ccb-payment-order-template.xls 字节完全一致，SHA-256 为 72e83ab6b7cd71263ca00196746de896e02a02390bab5c896dabd76421e40c0e。
+- 两份已填写的工资、公积金制单样例均为 BIFF8，三个工作表、15 列，表头与模板完全一致。只提取结构，不复制样例的户名、账号、金额或联系人；样例用途不构成新增工资/公积金业务范围。
+- 当前源码已经包含付款复核后下载银行制单功能。制单路由、生成器、Python 填表脚本、内置模板及付款页面与生产基线 f223bfb 的 Git 内容无差异；这证明基线包含能力，不证明运行时依赖、真实数据或企业网银导入已通过。
+- AP 修订已由用户复核，未提交部署；58dcee0 不含撤销 CEO 台账授权的最新修订，不能用作该修复的最终候选。
+
+## Scope
+
+2026-09-08 追加授权与结果：用户批准仅补 0014 归属人的所属主体。已于北京时间 22:30 完成 majianyong 的 legal_entity_id 空值到唯一启用未归档主体的条件更新（1 行），提交后独立连接回读匹配。此项覆盖首轮“主体回填未授权”的历史状态；个人收款银行/账号仍待授权管理员在系统维护，本次未查验或写入银行资料，未证明完整 readiness 已通过，其他生产业务动作及部署仍未授权。
+
+0014 付款前置资料、既有付款复核与 BIFF8 制单、人工银行付款及回单闭环；三张退回报销本人重提；AP 发布作为独立关联任务。当前获批交付为规划修订、业务相关技术审查及最小本地修复，真实业务动作另批。
+
+## Requirements
+
+- R1：业务优先；不要求 0014 等三张退回单，不要求三张退回单等 AP 发布。不让 R1 门禁、58 条红项或合同测试成为本 task 的扩修前置。
+- R2：生产补数据前核对唯一业务记录、原值和目标。只准备 0014 归属人的 legal_entity_id 空值到获批主体的修正；非空或身份不符停止，执行另批并回读。唯一启用主体不代替业务归属批准。
+- R3：真实收款开户行与账号由具备 employee.bank.manage 的授权人员直接录系统；现有真实账号由 wangshunli 管理员维护，普通 finance 不因制单需要新增维护权限。非建行停止，不发聊天、不填样例或占位账号。
+- R4：付款账户解密检查与真实制单均在获准范围内执行；明文只在必要进程内存/实际交付文件出现，不输出日志、Trellis 或完整快照。解密可用性与真实银行账户正确性分别确认，不能互相替代。
+- R5：财务用真实身份重新检查 0014 待组批状态，通过实际 readiness 后创建批次。已有批次占用、部门开关、收付款资料等阻断按实际返回逐项处理，不把某三项补齐称为所有检查通过。
+- R6：报销审批和付款复核是两道不同业务动作。wangzhiling 制单，具备权限且不是制单人的实际人员复核；majianyong 为已有 ceo 业务复核人候选，须满足系统当前条件，不伪造账号或绕过独立复核。复核人同时为受益人的治理边界沿既有获批规则，不在本轮擅自加层或宣称不存在风险。
+- R7：仅 reviewed 的合格报销银行付款批次由财务生成 BIFF8 .xls。沿用精确模板、15 列与三个工作表，账号和行别代码保持文本，行别为 01，金额两位小数，用途为报销款，备注关联单号，客户流水号可追溯且不重复；不改为 xlsx/CSV，不套用样例里的真实数据。
+- R7a：详情页复核通过、可制单、未生成且无回单时，唯一主动作优先“下载银行制单”；生成后切换“上传银行回单”，重下载进入更多。未生成但已人工付款仍可从更多直接上传，已有回单优先登记完成；资料不完整、非银行或回单状态未知时不错误引导下载/付款。桌面和移动端使用同一动作模型，不改变列表页主动作或增加自动付款。
+- R8：制单下载需要原因并写导出审计/次数，不是纯只读；重下载不等于新增银行付款。未复核、旧快照缺失、非建行、解密/依赖/模板失败不得生成部分文件，不用手填绕过本轮制单验收。
+- R9：生成 .xls 不等于付款成功。由授权银行操作人导入网银、核对对象/笔数/金额、按银行流程批准执行；银行返回结果与回单核对后才在系统登记。失败/部分成功分别处理，不能整批提前标已付；单据状态、付款记录与回单一致才算闭环。
+- R10：三张 rejected 各自核实退回原因、参与人和实际修改结果，由 majianyong 本人重提；不代维护、不复制绕过、不提前承诺所有审批必过。由实际分配的审批人处理，通过后进入后续批次，不重复纳入 0014 当前批次。
+- R11：复用已有制单功能。用户已授权本地修复影响这些业务的技术债，先复现再做最小修复；若涉及新增业务语义、权限放宽、状态机重构或生产写入，重新交审，不先重构、升级业务依赖或新增付款模块。
+
+## Acceptance Criteria
+
+- [ ] 0014 的实际归属人、当前阻断和允许操作范围已核实；主体及真实收款资料按授权补齐，实际待组批可选，未触碰 smoke 账号。
+- [ ] 付款账户及收款资料通过必要的受控校验；完整账号不进入聊天、日志、任务或普通接口。
+- [ ] 实际财务创建批次、非制单人完成所需复核；未复核不能下载制单，真实复核结果有记录。
+- [ ] 财务下载的 .xls 与用户空白模板结构一致，账号/01 不丢前导零，金额、条目与批准批次一致，失败不产出部分文件；真实文件不提交仓库。
+- [ ] 网银实际导入和业务核对通过，执行结果与银行回单核验后才登记付款；没有银行结果时仅标“已制单/待付款”。
+- [ ] 三张退回单逐张有实际重提结果或明确阻断，未完成的不虚报收口；审批完成与最终付款分别计进度。
+- [ ] AP 修订按独立候选与发布授权处理；业务任务不冒充发布完成，不启用暂停事项。
+
+## Out of Scope
+
+不批量关联全员主体，不开发新员工自动关联，不扩工资/公积金/差旅付款，不新增银行直连或自动划款，不放宽 CCB/复核/资料守卫，不扩六个 view_all，不修 58 条、合同阶段 B 或启用 R1，不代发消息、不代替真人业务审批。
+
+## Test Plan
+
+- 本轮：原件结构/模板摘要比对、源码流程核对、task validate、Trellis governance、git diff --check；不生成真实制单，不执行业务操作。
+- 执行阶段：复用 paymentOrderXls 与 paymentBatches.reimbursement 定向单测，以及真实付款页面对应的合成浏览器用例，检查 reviewed 守卫、导出权限、模板格式、账号文本和失败无部分输出；先发现具体缺口再补测试，不重跑无关完整红项。
+- 生产与银行验收：在分别获准后核对数据原值/回读、实际财务身份操作、网银导入反馈及付款回单，未执行项不抵扣为通过。真实导出包含审计写入，不能标为只读。
+
+## 执行边界
+
+本次技术审查沿用既有“付款复核通过后，财务主动点击下载银行制单，再由授权银行操作人导入网银”的方式；不新增自动下载或自动付款。不重复索取本地技术审查/修复授权；各项生产写入、真实账号解密、导出、付款和发布仍分别获批。
@@ -0,0 +1,26 @@
+{
+  "id": "reimbursement-payment-closeout",
+  "name": "reimbursement-payment-closeout",
+  "title": "报销付款与银行制单业务闭环",
+  "description": "围绕0014待付款、三张退回报销及建行xls制单推进业务闭环规划和限定技术债修复；复用已有付款能力，生产数据、真实业务操作和发布分别批准。",
+  "status": "in_progress",
+  "dev_type": null,
+  "scope": "business-payment-closeout",
+  "package": null,
+  "priority": "P1",
+  "creator": "shunli",
+  "assignee": "shunli",
+  "createdAt": "2026-09-08",
+  "completedAt": null,
+  "branch": "main",
+  "base_branch": "main",
+  "worktree_path": null,
+  "commit": null,
+  "pr_url": null,
+  "subtasks": [],
+  "children": [],
+  "parent": null,
+  "relatedFiles": [],
+  "notes": "用户追加批准Trellis更新检查、多角度计划复核及影响付款业务的本地技术债修复。稳定版已最新，不切beta、不覆盖项目定制。沿用人工下载xls/网银流程，修复首次制单动作优先级并补合成验证；生产数据/真实银行卡解密/实际业务操作/提交推送部署仍另批。",
+  "meta": {}
+}