hyb-oa/.trellis/tasks/09-08-reimbursement-payment-closeout/implement.md

执行顺序（本地技术审查/修复已批准，真实业务动作另批）

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。

复验命令

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 成功；生产仍未部署，业务验收状态不随提交改变。