hyb-oa/.trellis/tasks/09-07-manager-ap-access-scope/implement.md

执行计划

2026-09-17 历史发布回执接回（仅本地文档对账）

09-08本轮W8逐条件对账从主checkout同名task implement的“已按本候选例外完成部署（2026-09-09）”接回原文档引用，并核现有脱敏postcheck-result.json；不复制整份旧文档覆盖本副本，也不读取原始发布日志/环境或连接远端。准确来源/行号/摘要与布尔事实见acceptance-boundaries-20260917的historical-acceptance-review.json及historical-report-facts.json。

AP实现已随b87cc55发布。运行制品及权限策略核验有据，真实账号AP接口/页面当时NOT_RUN；六个view_all未收窄，不重新部署或扩大权限修复。

本次未执行新的发布、真实查询或业务写入；旧“未部署”段落是当时记录，不再代表追加阶段当前余额。原PRD未满足项不补勾，status/completedAt/历史commit不改，不归档。当前G8未提交产品增量仍待独立复核和新的交付授权。

2026-09-08 付款账户配置只读核对与候选纠偏

• 用户附件要求综合判断后续部署与业务恢复，并提出核对此前配置的建行付款账户。本轮只读核对配置，不将附件中的提交/推送建议、批量主体回填建议或业务付款建议转换为执行授权。
• 21:10 CST 生产 f223bfb：legal_entities 共 1 条且启用未归档；payment_accounts 共 1 条且启用未归档，关联该启用主体及启用未归档的 CCB 银行字典；加密账号字段非空。只返回聚合数和存在性，没有输出或读取户名/账号明文，没有取回密文，没有调用解密。事务只读且 ROLLBACK 完成。
• 结论仅为“建行付款账户已配置”，不建议重复新建；解密和 snapshot 生成未验证。snapshot 的实现会在进程内解密账号，所以“验证 snapshot 且完全不解密”不能同时成立。若获准校验，仅回传成功/失败，不输出明文、户名或完整 snapshot。
• 候选必须包含本轮 CEO 撤权修订，不能部署旧 58dcee0；修订尚未提交。旧备份/回滚制品和 seed 比对作为历史证据保留，但发布前仍需核对时效、存在性及生产漂移，不能写成“只有候选 SHA 改一下即可”，新候选批准须明确。
• 不认可直接回填旧快照的 7 条员工：全表含 smoke 标识记录，须先明确真实业务员工范围和目标主体，复核当前字段及原值，再另批写入。唯一启用主体只是技术上唯一，不自动等于全部记录业务归属已获确认。
• 本地 readiness 代码除主体和付款账户外仍检查收款人银行/账号、单据状态、部门、批次占用及复核人等；未调用真实业务提交或组批，不宣布三张单必定可重提/审批/付款，也不凭角色默认断言唯一真实复核人。业务人员可先修订单据，但状态流转由实际系统结果验收，不替用户操作。
• 证据：artifacts/qa-flow/manager-ap-access-scope/payer-config-readonly-20260908/result.json。探针语法通过；本轮无生产写入、提交、推送或部署。经理关系修正保持已执行并回读完成，用户接受执行证据不冒充用户独立生产验证。

2026-09-08 财务直接经理单字段修正（明确授权）

• 用户已确认 wangzhiling 为财务本人、yj 为员工本人，并明确授权仅将财务 direct_manager_id 从 NULL 设为 majianyong；不以是否已经发生提交故障作为修正前提。
• 执行合同：唯一生产运行身份核对；事务内锁定两条员工记录及其角色记录，核对唯一身份、正常任职状态、完整角色及原经理空值；条件 UPDATE 仅一个字段、必须影响一行；提交后另开只读连接回读。任何前置不符均停止，不覆盖非空值；提交结果不明时不自动重试。
• 不改角色、审批规则、单据、其他员工字段，不运行 seed、部署、付款或审批。经理与 CEO 是否在实际流程中合并审批尚未验证，不声称两次审批或自动去重。回退亦须另行授权，不能将“可改回空”冒充无影响。
• 执行结果：2026-09-08 20:47:57 CST，PASS_APPLIED_AND_READBACK。原值在加锁事务内确认为 NULL，条件 UPDATE 影响 1 行，仅 SET direct_manager_id；提交后销毁原连接，用新连接只读回读，财务经理已指向 majianyong，双方完整角色与执行前一致。运行版本仍 f223bfb，未部署。
• 执行过程原样保留：首次 stdin 模式 require.main 不等于 module，执行函数没有被调用，包装器因空输出解析失败；先只读确认原值仍空，再修正入口。入口自测首次因模拟 process.env 缺失失败，补齐模拟后通过，不冒充首轮通过。第二次在 UPDATE 前检测到未审阅触发器并回滚；只读审查发现唯一触发器仅禁止修改 employee_no，不产生字段写入，无 UPDATE rule。固定触发器/函数定义摘要，并在表级 ROW EXCLUSIVE 锁内复核后执行；未禁用任何触发器或约束。第三次成功提交并独立回读，没有重复成功写入。
• 证据目录 artifacts/qa-flow/manager-ap-access-scope/finance-manager-correction-20260908/：result-applied.json 为最终回执；result.json 为触发器前置拒绝回执；reconciliation.json、trigger-inspection.json、stderr.log 记录前次停止和只读复核；selftest.json 为身份/状态/原值校验，stdin-selftest.json 为修正后的入口及连接失败回执验证。最终执行脚本 SHA-256 为 9b3abf70a4b36313b800ef3caddbb53e704a9ce0e7ec2f0acad58cb4adf55c43。
• 本次数据关系修正已完成，不等于真实提交/审批闭环已验证。AP 修订保持用户已复核但未提交/部署；不因此启用门禁或恢复其他任务。

2026-09-08 AP 修订复核通过与全员工关系只读盘点

• 用户明确复核通过 CEO 读取修订；独立复核已由用户完成，不将其转换为提交、推送、部署或生产员工写入授权。
• 用户新增授权一次全员工列表查询，仅内部 ID、登录邮箱、角色、直接经理关系；不读取姓名、金额、票据、银行。输出用 E1–E8 替代 UUID，邮箱域名脱敏；完整邮箱与内部 ID 仅在远端进程内用于关联，不落本地回执。
• 20:36 CST 查询得到全表 8 条，非“8 条在职”；未查询任职状态，不能拿本次 5 条经理为空与旧 7 条在职/4 条为空直接比较。只读事务已成功 ROLLBACK，运行版本及镜像仍匹配 f223bfb。
• 脱敏清单：E1 smoke-finance，employee+finance，经理空；E2 majianyong，ceo+employee，经理空；E3 oa_smoke_02，employee+manager，经理 E2；E4 yj，employee，经理 E2；E5 smoke-manager，employee+manager，经理空；E6 oa_smoke_01，employee，经理 E5；E7 wangzhiling，employee+finance，经理空；E8 wangshunli，admin+employee，经理空。标签来自邮箱本地部分，不凭 smoke 字样断言所有此类记录都不是业务账号。
• 前次匹配失败的原因已具体化：系统记录为 wangzhiling 与 yj，而不是此前用于匹配的 wangzhuling 与 yangjun。两者是否分别对应用户所说的财务与员工仍需用户确认，不凭相似拼写/缩写认定真人。
• E7 财务角色记录的直接经理确实为空，是确定的字段缺口；若用户确认它是财务本人，则与“其他员工经理均为 majianyong”的业务口径冲突，须单独交审生产回填。没有执行提交，不能宣布已实测所有入口 409；E4 的经理配置已指向 majianyong，若其确为 yangjun，则此项关系一致，不代表全部审批链验证完成。
• 证据位于 artifacts/qa-flow/manager-ap-access-scope/employee-roster-readonly-20260908/result.json。探针语法检查通过；本轮不重跑产品测试、不改产品代码、不写数据库、不登录业务账号、不删回滚制品。部署仍暂停。

2026-09-08 身份确认后的 CEO 读取修订（待用户复核，不部署）

• 用户确认已匹配的邮箱同名账号为本人：wangshunli=admin+employee，majianyong=ceo+employee；确认其他员工业务直接经理为 majianyong，但不冒充数据库字段已一致。明确批准 AP 修订及另外两人的经理关系只读核对。
• 本轮运行时增量仅 server/src/constants/permissions.js、client/src/auth/permissions.ts 各删除 ceo 的 finance.ledger.view 一行。与 HEAD 全角色权限数组逐项比较，其他权限不变；审批路由、seed、工作流、账号、六个 view_all 均未修改。finance/finance_mgr 及 admin 通配保留，ceo+finance 仍按并集放行。
• 已更新角色、两个 AP GET、导航及浏览器矩阵：ceo 与 manager 拒绝；后端拒绝时零财务查询；前端直连 403、无入口、零 AP 请求。财务及两种混合角色正例渲染台账；CEO 四类审批与付款复核权限保留，导航单测确认付款入口保留。
• 复验：后端五文件 124/124 PASS；本地合成浏览器 7/7 PASS，单 worker、零重试、trace、2.7 分钟；typecheck、独立 artifacts 构建、全角色增量核对及 diff 检查通过。不是完整候选验收，不是生产角色验收；构建仍有既有 Browserslist 陈旧提示。独占 Vite 已停止，未修改归档截图。
• 20:23 CST 限定只读查询：majianyong 精确匹配一条；wangzhuling、yangjun 在工号、邮箱本地部分、企业微信绑定三个限定匹配方式下均为零条，因此二人的 direct_manager_id 未核实，不是查得为空，也不能断言不能提交。需要两人的系统工号才能继续定位，不需要密码、完整邮箱或业务内容。事务只读并成功 ROLLBACK，生产版本仍 f223bfb。
• PRD、当前设计矩阵、权限规约已同步；旧发布历史保留并明确被新矩阵覆盖，旧候选批准不自动转用于新改动。用户独立复核待办，不派代理，不以主会话自检冒充独立复核。
• 证据目录 artifacts/qa-flow/manager-ap-access-scope/ceo-scope-revision-20260908/：backend-final.log、browser.log、browser-results、typecheck.log、build.log、scope-check.json、manager-check.json、governance.log。review-code.diff 为代码/测试/规约增量，review-full.diff 包含既有未提交任务预检时间线，不能把后者全部归作本轮新增。
• 验证命令：server 下使用既有 PAYMENT_ORDER_PYTHON_BIN 执行 npm test -- tests/unit/routes/apOperations.permissions.test.js tests/unit/constants/permissions.test.js tests/unit/workspaceSettings.navigation.test.js tests/unit/routes/exports.apOperations.test.js tests/unit/routes/paymentBatches.reimbursement.test.js；client 下 npm run typecheck、vite build --outDir 指向上述独立目录；E2E_MODE=local E2E_BASE_URL=http://127.0.0.1:23119 playwright test tests/e2e/payment-reviewer-permissions.spec.ts --grep '只有付款复核职责|AP 专用读取权限' --workers=1 --retries=0 --trace=on --reporter=list，输出指向上述目录。
• 未提交、推送、部署或写生产；不删回滚制品，不回填员工经理。58 条、阶段 B、R1 保持暂停。交付保留：经理和 CEO 仍有原报销列表全量查看能力，本轮只收窄 AP。

2026-09-08 四账号与三单关系只读核对（最新边界）

• 用户批准四个指定账号的完整角色、当前与候选 AP 权限来源、通配符、直接经理及审批职责核对；分开核实当前 rejected 单的 submitter 与 owner。不读取金额、票据、银行、姓名或联系方式。
• 使用精确企业微信绑定匹配，缺失不猜身份；只读事务成功回滚后输出脱敏结果。当前三单不自动等同旧快照中的三单。
• 部署暂停，不修改账号、不移除角色、不删除回滚制品；结果交用户判断，不自动恢复部署。
• 20:06–20:07 CST 两次受控只读事务均回滚完成，生产版本和镜像仍匹配 f223bfb；运行权限表、认证插件、AP 路由摘要匹配旧版本。四标识精确企业微信绑定均无匹配；补充限定工号/邮箱本地部分候选查询，未扫描或输出人员名册。
• wangshunli 邮箱同名唯一候选为 admin+employee、持 *，当前及候选均可读 AP；majianyong 邮箱同名唯一候选为 ceo+employee、无 *，当前由 payment.batch.review、候选由 finance.ledger.view 放行。两候选均 active/在职/未归档、直接经理为空。邮箱同名不等于真人身份确认，不能写成四真人已核实。
• wangzhuling、yangjun 在以上匹配方式中均未找到；不推断账号不存在或角色为何。四账号完整映射尚未完成，需业务确认候选和提供另外两人的系统身份定位，不需要密码或银行信息。
• 当前恰有三条 rejected，三条 submitter_id=owner_id，均指向 majianyong 邮箱同名候选。未读取单号、金额、票据或银行，不能倒填历史三单对应关系。
• 当前启用的三条审批规则最高档确为 manager→ceo→finance，owner_self_fallback_role=finance；活动报销工作流引用 ceo。majianyong 同名候选具有四类审批及付款复核权限，明确分配给该候选的 workflow_tasks 有 completed 2 条，无其他状态；不把权限资格或任务数当作当前完整审批责任。其他活动工作流未提取到 role 类型引用不等于没有其他分配规则。
• 证据：artifacts/qa-flow/manager-ap-access-scope/account-role-readonly-20260908/ 的 result.json、result-candidates.json；后者账号标签仅表示邮箱同名候选。探针语法通过，未执行登录、部署、seed 或业务写入。初始绑定结果与补充候选结果分别保留。

2026-09-08 实际部署（已授权，公网角色验收前置失败，未进入部署写入）

• 用户明确批准例外并表示“可以部署”，目标仍为 58dcee08f72013fe5b9448a3c2e82a759ba5b01f；沿既有受管发布入口执行 migration/seed、应用切换、健康与版本校验及 AP 定向验收，不扩展产品改动。
• 用户消息沿用了旧的“ARM 归档未核验”状态；实际已由用户管理员回传并与源端对齐，不将已补证事实退回未知，也不因此另索同一批准。
• 执行顺序：固定干净候选定向复验 → 执行前运行身份/备份时效/旧镜像制品/容量检查 → 受管发布 → 版本与基础检查 → 经理 AP 拒绝、财务/CEO 可读、经理复核入口保留。使用既有受管 live-smoke 凭据，仅在进程内读取；不运行真实审批、复核、付款、导出或角色修改。
• 用户提出验收通过后删除旧镜像制品；该条件尚未满足，发布和验收过程中保留制品，不提前删除、不转移到 ARM、不做其他空间清理。容量与管理员凭据后续事项仍不扩大为本轮修复。
• 未授权数据库恢复、永久门禁豁免、提交/推送或其他任务归档。任何实际失败和验收缺项如实记录，不以部署命令退出 0 替代角色验收。
• 固定 58dcee0 干净隔离来源复验通过：后端五文件 123/123、六条合成浏览器 6/6，workers=1、retries=0、trace=on；浏览器耗时 1.6 分钟，独占 Vite 已停止，候选工作树仍干净。这不是完整候选验收，也不是公网角色验收。
• 19:26 CST 验收凭据预检发现新阻碍：受管 manager 登录 200、/me 200、角色匹配且无额外管理角色，但 mustChangePassword=true；finance 登录 403；ceo 登录 401。每个凭据仅尝试一次，成功的经理会话已登出（200），没有重置密码、修改角色、尝试替代凭据或操作业务。
• 登录/登出及失败尝试可能产生正常认证会话、审计、失败计数写入，不能表述为“生产完全零写入”。本轮未运行部署入口、migrate、seed、构建或容器切换；19:28 CST /ready 200、构建仍 f223bfb72fb2。
• 此结果仅说明当前受管验收凭据不能完成要求的四项公网验收，不证明真实业务人员账户故障；401/403 原因未进一步推断。验收范围实质变化不由已批准例外自动覆盖，暂停在部署前，待用户决定是否接受公网角色验收延后。镜像删除的“验收通过”条件未成立，保留独立制品。
• 证据位于 artifacts/qa-flow/manager-ap-access-scope/release-20260908/，含 backend-tests.log、browser-tests.log、browser-results、live-credentials-precheck.json、ready-before-paused-release.json；公网预检未保存 token、密码、完整身份或响应正文。

2026-09-08 一次性发布例外（用户已批准，实际部署待单独授权）

• 用户对“仅针对候选 58dcee0 的一次性发布例外，接受已列明缺口；这一步不执行部署”明确回复“批准”。固定候选为 58dcee08f72013fe5b9448a3c2e82a759ba5b01f，已核实生产基线为 f223bfb72fb2baef51199702c2def84c41af7aef。
• 接受范围：完整候选验收未通过；五次恢复演练均未完成、数据库/附件完整恢复及镜像实际回滚未经成功演练；镜像不撤销 seed 写入、数据库恢复可能丢失备份时点后数据；生产容量仍须执行前复核。
• 不授权本轮部署、提交、推送、恢复数据库、修改权限/门禁或清理。候选改变或风险/实际写入范围实质变化重新交审；实际部署前仍复核身份、备份时效、回滚制品及容量，不足或无法确认则停止。
• 此处仅登记例外决定，不把未通过测试标为通过，不启用 R1，不关闭恢复演练/P1 事件或扩大六个 view_all 范围。下一步只请求实际部署授权。

2026-09-08 ARM 管理员回传归档核验（此前受限项已补证）

• 用户自行在 ARM sudo 终端执行所提供的只读命令并回传 PASS_INTEGRITY_ONLY。最新归档创建于北京时间 09-08 02:30:02，校验时 ageHours=16.48、within24Hours=true；DB/附件大小及 SHA-256 均匹配，版本/镜像匹配预期。
• 本地将回传 batchIdentitySha256 和 manifestSha256 与生产 production-01.json 逐字比对，两项均相等；两端同一批次/manifest 的证据链已对齐。证据来源为用户回传，不冒充执行端直接取得 ARM 私有文件。
• 归档路径实际 statvfs 回传可用 95,960,739,840 字节、使用率 52.4%，补足此前仅有根文件系统代理量的缺口；不据此证明具体挂载身份，也不倒填旧时间点。
• 不再保留“本轮异机归档文件未验真”作为当前缺项；保留五次恢复 NO_GO、未做成功恢复/镜像导入演练、完整候选验收未通过、生产容量及备份时点后数据损失风险。P1 连续周期/容量验收未因此结案，发布仍未批准。

2026-09-08 ARM 管理员通道直接尝试（现有凭据受限，不再转交手工）

• 用户明确要求执行端直接操作、不再询问；据此对同一 ARM 目标用现有 SSH 配置/密钥尝试 root 身份，仅执行 id -u 验证。认证被拒，未登录成功；不尝试密码、其他身份或改授权。
• 普通账号执行现有只读探针，确认在 arm_capacity 阶段 PermissionError，归档受限不是仅凭 sudo 提示推断。dead-man 状态仍 success/0，阈值读到 93600 秒；未读取归档内容。
• 15:47 CST 补取普通账号可访问的 ARM 根文件系统：使用率 53%，可用 95,961,047,040 字节（约 95.96 GB / 89.37 GiB）。未证明该文件系统就是私有归档目录所在文件系统，不以此替代归档盘实测。
• 当前阻碍是凭据/文件权限而非业务授权；保留 ARM 最新归档及所属文件系统未独立验证，不继续索取用户手工操作，不把受限结果写成通过。无权限变更、生产写入或部署。

2026-09-08 两端容量与异机链只读复核（生产完成，ARM 权限受限）

• 用户已同意通过既有生产管理员和 ARM SSH 通道，由执行端完成一次限定只读检查：两端空间、最新正式异机归档时间/完整性及备份 timer/service/dead-man 状态。
• 使用现有权限；拒绝访问即停止该项，不修改权限。不触发备份/传输/恢复/告警，不清理、不上传远端探针文件、不部署。探针通过标准输入运行，只回传脱敏结果；真实备份不下载到开发机。
• 生产 15:02 CST：数据库/附件/备份/旧镜像制品均位于同一文件系统，使用率 86%，可用 8,925,286,400 字节；最新成对备份完整性通过、约 12.53 小时龄，正式本地批次目录 7 个，合计文件约 141.51 MB。运行 SHA/镜像未变，daily/watchdog 成功、timer active。
• 生产实际备份 runner 摘要与 f223bfb 受管源码匹配，last-success 对应最新本地批次且 manifest 摘要匹配；该源码在异机 finalize 成功后写成功状态。因此源端有今日传输/finalize 成功回执，不应继续称“两周前失败一直未恢复”。
• ARM SSH 可连，但 sudo -n 执行失败；只读 sudo 能力检查明确 passwordRequired=true。停止受限归档/容量读取，不更换身份、不索取密码、不改权限。普通账号读取到 dead-man 今日 06:30 success/0、timer active；未读取最新正式归档或 last-deadman 文件，未重算 ARM 包摘要。
• 结果不能冒充两端全通过、两连续自然周期验收或恢复成功。证据位于 artifacts/qa-flow/manager-ap-access-scope/offhost-readonly-20260908/；脚本语法、合成批次正反检查及文件系统分组检查通过。详见 design.md §6.10。

2026-09-08 发布例外恢复风险补充（本地核对完成，远端新调查待授权）

• 核对恢复演练 Attempt 1–5 全为 NO_GO；该 task 没有完整恢复成功证据。Attempt 3 底层恢复失败原因未知，不能把五次全部解释成已证实的工具缺陷。
• 后续 P1 task 记录 08-28 自然恢复一个新鲜 ARM 原子批次，但连续两个自然周期及容量验收未收口；不以 08-27 失败记录倒填今日现状。
• 发布例外已补上历史未成功恢复、异机现状未独立复核、数据回退损失和完整候选验收缺口，详见 design.md §6.9。镜像保存后可用约 8.98 GB，不能忽略本轮新增制品占用。
• 下一步拟一次只读核对两端容量及异机链，等待限定管理员通道授权；不实际恢复、不触发备份、不清理、不部署。

2026-09-08 管理员只读备份校验脚本交接（用户已回传完整性通过）

• 用户确认能使用具备备份读取权限的服务器管理员账号，并单独批准上传脚本、由用户在管理员终端执行。该授权不包含执行端提权或自行读取受限备份。
• 校验脚本已上传至系统临时目录下独立目录 hyb-oa-backup-check-7fptuwbq，目录 0700、文件 0600；文件名 check-backup-admin.py。上传后复读 SHA-256 与本地一致：58a604fc1e0ebab824553fa0507683ed5d8c44872d36d56c41574d8959ea6a35。
• 本地合成正例、数据库包损坏、状态文件缺字段反例通过；仅上传，未执行远端校验脚本、未读取备份、未改变既有权限。回执 admin-script-upload-01.json 存于既有 rollback-image-20260908 证据目录。
• 交给用户的命令先校验脚本内容摘要，再以 Python 隔离模式执行同一份已读字节；只回传脱敏校验结果。用户已回传 PASS_INTEGRITY_ONLY：manifest、数据库包、附件包摘要/大小匹配，备份版本 f223bfb，完成于北京时间 2026-09-08 02:30:51，校验时年龄 9.56 小时；restoreTested=false。
• 结果归因为用户在管理员终端执行，不冒充执行端直接核验。管理员 SSH 别名发现过晚造成不必要手工操作；后续先检查既有通道，再请求限定授权，不将连接配置当作已有无限授权。详见 design.md §6.8。
• 镜像独立保存、备份完整性和 seed 比对结果已具备，发布例外仍未批准。恢复实测、完整候选验收及恢复备份后丢失后续业务数据的风险仍须明确；未追加生产操作。

2026-09-08 独立旧镜像制品保存（已获批执行并完成校验）

• 用户对“保存 f223bfb 当前运行镜像为独立文件并校验；先检查空间、不重启、不切换、不删旧镜像、不部署”明确回复同意。
• 执行范围：核验容器/镜像身份及目标磁盘空间，在部署身份的持久用户目录中创建独立私有制品目录，docker save 固定镜像 ID；核对归档、配置 ID、层摘要，记录文件 SHA-256 和前后运行身份。空间不足或身份漂移停止，失败产物不冒充可用制品。
• 不读取受限数据库备份、不变更现有权限、不执行 docker load/镜像切换/清理；本授权不是备份验真、恢复演练或发布授权。
• 09:48:50 CST 保存完成：旧运行镜像 ID 与预检一致；独立 image.tar 为 1,117,595,648 字节，配置摘要及 14/14 层摘要匹配，另起只读校验进程复读 SHA-256 通过。容器身份、启动时间和运行版本未变。
• 制品位于部署身份持久用户目录、Docker 存储之外；私有目录 0700、文件 0600。它仍是同机副本，未做 docker load 或恢复演练，不覆盖主机/磁盘损坏风险。位置锚点、文件名与完整摘要见 design.md §6.7 及脱敏回执。

2026-09-08 剩余 seed 对象比对（已完成，不替代恢复前置）

• 09:22:19 CST 只读快照：费用类型 44、编号 1、分类 11、考勤 1、预算规则 1、假期类型 3、假期额度策略 3、工作区 1、部门 2，共 67 项，均唯一存在且实际覆写字段一致；CCB 已存在、3 条审批规则走保留分支。
• 这是配置目标字段一致，不是 seed 无写入。未查询员工假期余额；管理账号分支引用早先证据，本次未重查。前一轮 14 开关/四工作流/39 日历与本轮不是同一快照。细项与限制见 design.md §6.6。
• 只读事务 ROLLBACK 完成；源摘要匹配固定候选。比较脚本语法、比较原语正反检查和 67 项结果断言通过；首次本地自检路径映射错误已修正，无生产重试。
• 备份渠道仍待指定，独立镜像制品保存未获明确执行授权；不自动把补查完成转换为发布资格。R1、阶段 B、58 条及业务消息状态不变。

2026-09-08 seed 只读差异补查（已完成三组对比，仍不发布）

• 按用户授权比对默认 14 个强制开启开关、四类工作流和 CN_2026_STD 日历；实际 init 额外 flags 为 0。08:42:41 CST 快照结果：14/14 开关目标字段一致；四类仅 v1 激活且定义一致；日历表头及 39/39 日条目一致，无多余日期或待补主体绑定。
• 查询严格 READ ONLY 并完成 ROLLBACK；未执行 seed。即使目标值一致，version 递增、工作流取消激活再写回、日历删除重建仍会发生；其余 seed 写入对象未逐字段比对，不宣称全量无副作用。
• 证据在 artifacts/qa-flow/manager-ap-access-scope/seed-readonly-diff-20260908/；首次 Compose v2 不兼容失败与后续 v1 成功结果分开保留。详见 design.md §6.5。
• 备份验真仍受授权通道限制，独立回滚制品未固定；不绕权限、不擅自执行制品写操作、不批准或执行部署。58 条、阶段 B、R1 与业务消息状态不变。

2026-09-08 获批生产只读预检（已执行，未部署）

• 用户单独批准只读预检及 seed 行为核实。本轮从固定 58dcee0 干净隔离检出，以 PRODUCTION_READ_ONLY_PREFLIGHT=1 执行既有 bootstrap；exit 0，13/13 合同检查，迁移 pending=none，既有回滚窗口 OPEN，明确未进入 deploy.sh。
• 生产 BUILD_SHA=f223bfb；对候选 7 提交/103 文件，其中应用源码 7 文件 +11/-4，deploy/schema/migration/seed 无差异。seed 在生产容器内的摘要也与候选一致。
• 只读 seed 账号分支为唯一 active admin+employee，重跑角色集合不新增，但仍重写角色记录/时间。配置 seed 会更新或重置多类配置，不是零写入；细节见 design.md §6。
• 备份服务本日 02:30 成功、合同版本一致；备份目录元数据权限不足，未验证 manifest/备份文件摘要。旧运行镜像可 inspect，但未固定独立回滚制品，不把预检 PASS 扩大为备份恢复和发布资格 PASS。
• 未改生产权限或通道，未部署、迁移、seed、真实业务写入或查个人访问日志；只读 SQL 显式 READ ONLY 并 ROLLBACK。业务消息仍未发送。
• 本轮只补两份既有 task 文档与忽略目录证据，不提交、不推送，不修新问题。两个未跟踪其他 task 原样保留。

2026-09-08 发布方案准备（仅文档）

• 提交推送已完成：门禁 9916712、AP 58dcee0，与已有两个 Trellis 提交一并到远端。此处如实补记实际结果，不生成第三笔提交或再次推送。
• 用户同意继续准备发布方案；已在 design.md §5 分开写单次例外批准、验证缺口、回滚验收。生产预检、执行发布、seed 写入及回滚均未授权或执行。
• 本轮只读仓库发现既有部署 run-init 包含迁移和 seed，不能承诺“无 schema 改动即零部署数据写入”；实际生产基线和回滚点待获批只读预检。
• 业务三个具体问题仍待真实人员沟通，没有发送工具，不代发、不记为已完成。非建行限制应按既有付款工具合同解释，不能未经业务决定扩展成所有付款路径禁止。

2026-09-08 独立复核与提交授权

• 用户已独立复核通过本 task 的 18 文件包，包括单权限守卫、原有获准角色无误伤、经理复核保留、前后端正反测试与 AP-only 边界；不是主会话自检替代独立复核。
• 用户本轮授权独立提交 AP 修复，并与门禁包及已有两个 Trellis 提交一起推送；不包含部署或归档。本节之后的“待复核／未提交”表述保留为上轮交审时的历史状态。
• 推送不是发布；尚未授权生产部署，不能宣称生产 AP 权限已经收窄。经理其他 view_all 仍保留，不能宣称全域只看相关单据。
• 后续若准备未通过完整候选验收的发布方案，必须另行明确批准合同、验证缺口、候选、回滚及验收条件；本次提交推送授权不是整道候选门禁的豁免。

当前状态

• 2026-09-07：方案获批并修订为专用 finance.ledger.view，已 start；inline 实施。已保存全仓起始快照于本 task 的 artifacts，旧门禁包不得改写。
• 已读取 AP 两个 GET、导出守卫、角色权限和前端路由/页面判据，形成 PRD 与设计。
• 门禁任务不关闭、不归档、不自动提交；本轮实现及验证已完成，等待用户独立只读权限复核。

执行结果

• 已同步前后端静态角色表：仅 ceo、finance、finance_mgr 新增 finance.ledger.view；manager/ceo 的复核权限和六个 view_all 不变。应急 admin 通配符不变。
• AP 两个 GET、前端路由、本地 fallback 导航、服务端导航注册表只使用专用读取权限；没有 CEO 角色分支。导出与付款复核实现未修改。
• 新增 AP 路由矩阵；角色/导航/导出单测补反例；既有浏览器经理 AP 可访问测试按获批口径改为直连拒绝，新增 CEO、finance、finance_mgr、manager+finance 读取正例，实际切换财务台账；合同用例正文未修改、未运行。
• 后端五文件 123/123 PASS（含 76 条付款批次报销回归）；前端六条定向浏览器 6/6 PASS、零重试、trace。不是 full-local，不抵扣旧 58 条清单。
• typecheck、独立 artifacts 目录 build、Node 语法、diff 检查和 Trellis governance PASS；未覆盖 client/dist。build 保留既有 Browserslist 数据陈旧提示，没有更新依赖。
• 首轮扩展付款回归有 BIFF8 导出失败，默认 Python 缺 xlrd；使用已存在的隔离 Python（固定 BIFF8 依赖）后 123/123 通过。原始失败日志保留，不宣称任意环境都具备该依赖。
• 浏览器前置原生 online=true、无 cookie、登录表单可见、refresh=0；本次是本地 Vite + 合成 API 浏览器测试，不冒充真实后端浏览器闭环或部署验证。
• 旧门禁 33 文件逐一摘要核对全部不变。未提交、push、部署或操作生产；独占 Vite 服务已停止。独立只读复核待用户，不派 implement/check 代理，不以主会话自检冒充独立复核。

验证命令与证据

证据目录：artifacts/qa-flow/manager-ap-access-scope/implementation-01/。

cd server
PAYMENT_ORDER_PYTHON_BIN=<已存在的隔离BIFF8解释器> npm test -- tests/unit/routes/apOperations.permissions.test.js tests/unit/constants/permissions.test.js tests/unit/workspaceSettings.navigation.test.js tests/unit/routes/exports.apOperations.test.js tests/unit/routes/paymentBatches.reimbursement.test.js
cd ../client
npm run typecheck
E2E_MODE=local E2E_BASE_URL=http://127.0.0.1:23117 ./node_modules/.bin/playwright test tests/e2e/payment-reviewer-permissions.spec.ts --grep '只有付款复核职责|AP 专用读取权限' --retries=0 --trace=on --reporter=list --output=../artifacts/qa-flow/manager-ap-access-scope/implementation-01/browser-final-results
./node_modules/.bin/vite build --outDir ../artifacts/qa-flow/manager-ap-access-scope/implementation-01/build
cd ..
node scripts/qa/check-trellis-governance.mjs
git diff --check

日志：server-tests-final.log、browser-tests-final.log、browser-preflight.json、typecheck-final.log、build.log、governance-final.log。局部 6 条来源 spec 与 grep 如实记录，不能称整个 payment-reviewer-permissions spec 通过。

原批准步骤（保留顺序记录）

1. 加载权限、后端、前端相关稳定规约，冻结既有工作树和本 task 写入面。
2. 先补 AP 权限矩阵测试及 CEO/多角色/经理复核保留反例。
3. 最小收紧 AP 后端读取与前端入口投影，不改其他 view_all 或付款复核授权。
4. 执行针对性后端测试、前端类型检查及获批的本地合成浏览器验证；不默认重跑 full-local 或生产操作。
5. 对照 AC 审核并交独立只读权限复核；发现新的数据范围或正常复核依赖问题先报告，不扩修。
6. 获批后更新现有权限规约，交付明确保留的 view_all 开口。提交、推送、部署均不随实施授权自动进行。

待独立复核

• 复核代码、正反权限结果和范围；本轮不请求或执行生产变更。task 保持 in_progress。
• 明确保留：经理仍可从报销列表查看全部单据，本轮只收窄 AP 入口，未实现所有业务域“只看相关单据”。

2026-09-09 T0 独立交审副本

用户批准后续规划开始本地实施。AP 10 个既有差异文件已完整复制到专属 detached worktree，基线为 58dcee0；只在此副本纠正 task.json 的陈旧 CEO 授权描述并追加本节。付款按钮/制单测试的四文件差异未进入本工作树，原主工作树全部改动保留作对照，不宣称原混合工作树已清空。

隔离副本后端5文件124/124通过，保留付款复核/导出旁路回归。首轮123通过、1条BIFF8导出预期200实际409；本地默认Python缺xlwt/xlutils，补充已有固定PAYMENT_ORDER_PYTHON_BIN后同一集合124/124通过，代码与断言无改动。未重跑浏览器，既有独立复核及浏览器结果仍为此前证据，不倒写成本轮复跑。

代码	发布	业务验收	等谁
CEO撤权修订已复核，独立副本已隔离复验；摘要已纠正	未提交/推送/部署；58dcee0不是最终修复候选	真实账号线上AP权限尚未做新版本验收；其他view_all仍保留	等明确提交授权，之后推送/部署按授权推进

与本轮隔离/校验证据的关联见原主工作区 artifacts/qa-flow/project-roadmap-execution-20260909/。本次是主会话自检，不冒充新增独立审核。提交建议标题：fix: 取消CEO默认AP台账权限（09-07-manager-ap-access-scope）；标题建议不代表已经提交。

2026-09-09 提交与推送授权

用户对“AP 与付款修复分两笔提交并推送，不部署、不执行真实恢复、不混入后续准备文档”明确回复“是”。本次只提交本 task 对应已隔离交审文件及当前授权记录；原恢复 task、错误豁免后续阶段和另外两个未跟踪 task 不进入这两笔。实际提交 SHA 与远端结果以 Git 回执为准，不提前宣称 push 成功；生产仍未部署，业务验收状态不随提交改变。

已按本候选例外完成部署（2026-09-09）

用户明确批准 b87cc55 的例外、existing 发布及必要旧应用回滚，不授权自动数据库恢复。14:07 CST 既有 deploy-existing.sh 返回 0：build-init、run-init、build-server、build-switch-server 均 PASS；随后迁移对账、就绪/依赖/runtime smoke、公网构建标识及前端 bundle 检查和受控备份合同 refresh 完成。没有使用未发布 override，没有执行回滚。独立 clone main=origin/main=b87cc55 是本次发布来源，主工作树仍保留原未提交治理改动，不据主工作树旧 HEAD 判断生产版本。

部署后复核：

• 正式运行 build=b87cc55aca0003130cf8a5bbe38d0dd15528389c；14:08 CST 单独公网 /ready 与首页 HTTP 200，/ready buildSha=b87cc55aca00。
• init 日志的阶段精确为 validate_config → migrate → check_required_configuration，INIT_PASS/existing，无 seed 阶段；发布前后迁移对账无 pending。
• 运行容器内权限常量、AP 路由、workspaceSettings、auth 插件及 deploy-init 五文件摘要与候选完全一致。直接调用运行镜像中的权限解析器：manager/ceo 不获 finance.ledger.view，finance/finance_mgr 及兼财务角色可读，admin 通配保留；manager/ceo 的 expense.approve 和 payment.batch.review 保留。
• 上一项是部署制品字节核验和运行时代码策略执行，不是使用真人会话请求 AP 接口或实际点击菜单。本轮没有伪造真人 token、登录真实账户或读取台账明细；authenticated account route test / real-user page acceptance 均 NOT_RUN，不冒充四项真人验收全通过。
• 系统已发布且公网可测试，但经理/CEO 仍可经既有报销列表查看全部报销的开口保留，本轮仅收窄 AP，不宣称“经理只能看所有相关单据”整体实现。
• 发布后可用空间 45.50 GiB；旧备份、独立旧镜像制品及 34 个 Docker 拒绝删除项仍保留，未追加清理。backup unit BUILD_SHA 已刷新为新版本；最新已验备份仍是发布前 f223bfb，不把合同刷新写作新版本备份已产出。
• 例外缺口仍保留：完整候选验收没有通过证据；本次真实镜像构建现已通过，不能继续列为未构建；附件与应用恢复尚未演练，镜像回滚不撤销数据库写入。数据库最小恢复历史成功不等于任意当前备份均已演练恢复。

证据归 artifacts/qa-flow/20260909-release-b87cc55/：deployment-result.json、postcheck-result.json、public-check.json、脱敏迁移回执；完整发布输出为受控 0600 日志，不回传原始环境/业务内容。主会话执行发布及验证，不伪称独立 reviewer 验证部署集成。此次状态补记未另行提交或推送，不归档整个门禁 task，不启动 R1/阶段 B 或修 58 条。

下一步回到业务验收：majianyong 本人确认 AP 台账入口不可用、原审批/付款复核入口可用；财务本人确认 AP 可读和已复核批次可下载银行制单。仅让用户验证自己的授权界面，不代付、不代批、不创建额外测试付款。实际付款仍是复核 → 制单 → 网银付款 → 回单登记，下载成功不等于付款成功。取得真人交接证据后按已排队的统一待办任务收敛下一阶段方案，不让等待验收自动变成另起一笔未批准功能改动。