wangsli/hyb-oa
1
0
派生 0
代码 工单 合并请求 工作流 7 软件包 项目 发布 百科 活动
文件
2b4e3faa0ee204e8b9259f385a3e8e803ceb06d5
hyb-oa/.trellis/tasks/09-08-reimbursement-payment-closeout/implement.md
T

36 KiB
原始文件 Blame 文件历史

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

本轮复核输入与提交准备（未提交）

用户批准整理两笔独立改动的复核/提交方案。基线均为5d8cdf12；01为制单备注5文件，02为UI布局11文件，路径无重叠。仅生成补丁、摘要清单并用临时索引验证顺序合并，不改变实际HEAD/index，不创建commit，不推送或部署。复核入口位于layout副本的artifacts/qa-layout/review-preparation/README.md；临时合并树不是发布候选commit。既有验证按输入不变复用，本轮不新增测试通过计数；UI补跑外层143、网银导入未验证、未独立复核等边界保留。提交前须核对冻结摘要，发布前还需验证合并后的实际候选，不能把单包测试冒充集成验收。

2026-09-11 制单备注小改（已批准，独立执行副本）

基线5d8cdf12；独立remarks工作副本执行，官方current已切本task。原integration副本的既有制单准备/恢复/账号隔离记录不覆盖、不混入本补丁。不新建task，不提交、推送或部署。

  • 核制单一单一行、冻结payee来源、模板没有备注长度说明，BX配置驱动/PB按日三位流水；编号实现不改。
  • 先补备注、多人/同人多单及缺失输入回归，跑红后改备注拼接。
  • 跑制单单测与真实BIFF8读回、编号/付款路由相关回归、语法与流程检查。
  • 主会话复核最小差异，记录银行导入未验证和候选未发布；不要求真人代测。

本轮验证：旧实现15项中3项按预期失败（备注缺姓名与用途），修改一行运行时后4个测试文件121/121通过：制单15、编号8、付款路由82、付款就绪16。追加用途/备注BIFF8文本类型断言后，制单15/15再通过；不将重复执行累加为新测试数。真实固定模板生成并用xlrd读回，验证15列、3个sheet、模板表头/列宽、中文备注、金额、账号前导零、稳定客户流水号。node --check、git diff --check、Trellis治理和process-contract baseline检查通过。

主会话检查确认运行时只改备注拼接，不动权限、状态、审批、编号或数据迁移；本轮不是独立复核。现有银行模板没有长度上限说明，网银实际导入及长备注接受性未验证。仅本地完成，未连接生产、未导出真实制单、未提交/推送/部署。下一步将本增量纳入候选复核与提交准备；提交/推送和部署须明确授权，不能直接覆盖原integration任务记录或将原有冻结候选视为包含本改动。

2026-09-11 业务就绪只读检查准备（未执行生产查询）

复用已确认身份和经理/主体回填回执，不再猜邮箱或索取工号。排除 smoke 账号，分别核对能登录、能提交、能审批/复核、能组批/登记，不能合并成一个笼统 ready。

  • 登录：真实业务账号在职/启用及角色组合，只回传角色与布尔状态，不读取凭据或个人登录历史。
  • 提交：核对直接经理和适用审批人解析；财务经理已修正和 CEO 自报兜底只作为历史证据，不推断所有规则都能提交。
  • 审批/复核：保留 CEO 审批路由及非制单复核；不用 admin 通配代替业务角色，不修改六个 view_all。
  • 付款：主体、付款账户、收款银行资料只回传是否存在/启用/关联匹配。受控解密可用性需另列范围，仅回传成功/失败；门户待办不解密、不输出银行信息。
  • 有缺项只报告脱敏对象、阶段、维护职责；真实回填另批，不由本地测试自动推导生产 UPDATE。

报销详情一致性与四类业务待办的本地实施分别归 09-04 和 09-11 任务，联合验证已通过：135 单测、39 页面及真实隔离 HTTP/双端流程。证据见联合副本 artifacts/qa-flow/20260911-combined/；只登记合成回单，没有银行连接。本轮未查询生产、未调用真实腾讯 OCR、未实际付款或发消息；独立复核、提交和部署未完成。

2026-09-10 本轮付款体验已发布

  • 代码：付款提交 fe025e65 与删除提交 73fcd5a6 已分别提交并推送，最终统一候选 fe025e65；中文“报销制单”文件名、下载免手填理由但保留敏感/重复下载确认、操作卡下方处理进度及 filename* 解析修复随本轮上线。本节覆盖下文历史阶段的“未提交/未发布”状态。
  • 发布：用户明确批准后，23:11:59（Asia/Shanghai）正式 deploy-existing 第二次执行退出 0。第一次依赖下载 ECONNRESET，确认未执行迁移/切换后按原候选重试，无更改锁文件或跳过门禁。新迁移仅来自删除提交；existing 无 seed，数据库容器不重启、环境文件不变、备份合同 refresh 成功。
  • 验证：本轮生产只读核验版本、代码/结构摘要、68 条迁移、HTML 与 12 份相关资源、匿名权限守卫和回滚制品；正式公网资源扫描 106 份、buildMarker PASS、findings=0。证据位于主 checkout 的 artifacts/qa-flow/20260910-release-fe025e65/，发布细节和回退限制共用删除 task 最新回执，不另建 task。
  • 公网浏览器补查桌面/手机未登录入口，控件可见、无横向溢出、console errors/warnings 为 0；不是已登录付款页面验收。关闭回报 closed 但外层退出 143，已另核本次浏览器进程退出，不包装为整组浏览器命令全绿。
  • 业务边界：本次不登录真人账号操作真实批次，不重复导出真实制单、不复核或付款；真实 BIFF8/中文下载/桌面手机付款流程的执行证据仍为合并候选已有真实隔离联合测试，不冒充生产真实付款验收。独立 reviewer 未审制单/前端/BIFF8、完整候选验收缺口保留。
  • 下一步：实际付款与回单继续按业务办理，不要求财务或经理替执行端发现基础缺陷。F1 非阻断加固留原删除 task 后续处理；不自动归档、提交补记或清理回滚制品。

2026-09-10 当前执行

合并候选验证与发布边界

  • 最终页面回归：合并构建产物 preview，Playwright system-action-confirmation.spec.ts 按“财务先制单/制单失败/付款/银行回单/报销”选择，19/19，退出 0；ui-final.log 为最终证据，ui.log 为中断记录。已检查桌面与手机截图：操作卡下接进度，窄屏无横向溢出，底栏动作可达。当前本地实现与联合验证完成，等待独立复核及提交发布授权。

  • 本轮独立付款副本基线 e5685f1；与退回删除按补丁合入 artifacts/isolated-worktrees/20260910-reimbursement-payment-integration，没有提交或覆盖主 checkout 的既有改动。

  • 合并 focused 后端：23 文件、296/296；另下载文件名解析 7/7。命令以删除 task 的 focused 列表加 paymentOrderXls.test.js 为准；文件名测试为 tests/unit/utils/client-download-filename.test.js。记录见合并副本 artifacts/qa-flow/20260910-combined/unit.log、filename.log。

  • 真实隔离执行：RUN_ISOLATED_DB_TEST=1 RUN_RETAINED_DELETE_TEST=1 RUN_BROWSER_TEST=1 RUN_PAYMENT_EXPERIENCE_TEST=1 node scripts/qa/test-invoice-first-http.cjs；BIFF8 使用既有受控测试解释器。real-db-browser.log 为 PASS_REAL_DB_HTTP，退出 0，数据库、合成文件及浏览器完成清理。

  • 联合验证涵盖上传选票填明细、退回重提与三步审批、退回留痕删除与票据复用、并发/事务回滚、财务组批、CEO 复核、非授权下载拒绝、桌面/手机真实下载中文 BIFF8、不要求理由、再次下载警告。不执行真实银行付款，OCR 为真实 worker + mock provider，不能称为本轮腾讯 OCR 新验证。

  • 前端 typecheck/build、Prisma validate、UI strict/self-test、错误解释 strict、process baseline、task validate、Trellis governance、diff 检查通过。文档 registry errors=0 / warnings=1，为既有 22 个未登记文件，不扩修。

  • 最初真实付款 fixture 缺环境功能开关导致 409，修正仅限隔离配置；浏览器实际复现中文名称被旧解析器丢弃，已修产品代码并补七项解析测试。合并页面首轮受 SIGTERM 中断（143），不能视为通过，单独重跑结果另记。

  • 保留生产边界：未提交/推送/部署，未触碰真实单据/账户；六个 view_all 与审批角色不变，不能宣称经理只能看相关报销。退回留痕删除含新增迁移，旧镜像可能重新显示留痕删除记录，不能复用“无迁移、只改权限”旧例外。

  • 主会话执行本地自审与自动验证；独立只读 reviewer 未执行。下一步先复核两份独立补丁，再按明确授权分别提交、冻结统一候选、重新发布预检和部署后自动验收，不交给员工发现基础缺陷。

联调发现并已修：共享下载客户端只解析 filename，忽略 filename*，导致服务端中文名仍被 ASCII fallback 替代。现优先解析 UTF-8 扩展名；损坏编码、不支持编码、空值回退原 filename。新增 7 项客户端解析回归，已通过。付款路由/BIFF8 93 项通过；最终浏览器和合并验证见本节记录，本地通过不代表已发布。

用户批准本轮报销/付款改动全部完成、合并验证后再部署。付款在独立副本实施，基线 e5685f1，不混入退回删除的迁移。既有历史阶段不代表当前发布状态。

  1. 中文制单文件名、无手填理由的敏感下载确认、操作卡下方处理进度。
  2. 制单独立请求合同允许省略原因；旧客户端真实填写的原因仍保留，系统用途及来源独立记录，不伪造用户原因。
  3. 路由、BIFF8、桌面/移动浏览器定向回归，再与退回删除合并做隔离数据库全链验证。
  4. 独立复核、提交和发布尚未完成；生产动作另行授权，不以员工正式业务代测。

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

2026-09-09 后续工作执行顺序（按已确认选票流程更新规划）

本节为最新规划，旧阶段结果保留；已确认付款独立复核和制单下载，不确认实际付款。当前只更新已有 task 需求与设计，没有创建 task、改代码、运行产品测试或部署。

  • 收口用户取向：报销制单中文名；首次/再次不强制手填理由但保留确认与审计；处理进度右移；退回单可以删除后新建；验证由执行端承担。
  • 将删除阶段归入 09-04-reimbursement-state-gap-finance-view，将“选票自动生成明细并关联”归入 08-29-reimbursement-expense-policy-invoice-guard，付款优化留本 task；对应 PRD/design/implement 同步。明确替换旧手工关联方案，不新建 task。
  • 综合方案确认后，先为第一批补齐存储/绑定接口设计与隔离端到端夹具，复现两个原始阻断；评估是否涉及迁移，不默认免迁移。
  • 第一批在干净副本实施：退回单删除留痕与发票占用释放、选票自动生成明细并关联及已有明细直接加票；验证所有旧状态的拒绝边界，核实真实腾讯 OCR，异常不交给员工发现。
  • 并行准备部署后专用合成测试条件；缺失项由执行端列出具体配置和授权请求，不调用真人单据或凭据。
  • 第一批完成真实后端角色链、桌面/窄屏验证及只读交审，取得明确提交推送授权后收口；不把另一批产品变更叠入同一脏树。
  • 第二批按已确认付款方案实施中文名、独立下载原因合同和布局；完成文件内容/审计/权限/布局回归及本批交审。若第一批遇真正外部阻塞，第二批可在独立副本提前完成，不扩大范围。
  • 每批冻结候选并提出发布方案，附可执行的部署后自动检查；部署另批，上线后由执行端运行验证、报告失败与回滚建议，必要回滚按具体授权执行。
  • 功能交付后回到统一待办投影；同期维护原错误豁免截止日队列，不批量归档或延期。

首个实施动作明确为“用空报销合成数据复现发票顺序问题，并核查退回删除事务/材料关系”，不是继续生产清理或让 majianyong 再尝试一次。主工作树在旧基线且有治理差异，执行副本须从最新 origin/main 核验建立，按任务登记分批文件清单与测试命令。

在新工单中引用 查看 Git Blame 复制永久链接