hyb-oa/.trellis/tasks/08-28-production-arm-backup-transfer-incident/implement.md

生产到 ARM 备份传输中断实施计划

2026-10-05 同模型独立复核回执及第 1–4 项补漏

用户回传对 f6d1025d 的同模型独立只读复核：通过、无阻断项、5 条非阻断问题；复核代理使用独立上下文，未修改仓库或访问远端。此处引用用户回执，不将其写成主会话独立执行，也不将旧提交结论自动套用到新改动。

• 补齐三个测试缺口：watchdog 与 drill-reminder 分别仍在运行、timer disabled 但 active、模式文件为断链；分别覆盖 probe/refresh，沿用现有合成 systemctl/SSH/Docker fixture，不改生产脚本。
• design 与下方切换步骤同步超时后的两种明确处置、安装前最终获批源码必须送达并核验、Persistent timer 重新启用可能立即补跑及告警。
• bash scripts/qa/run-deployment-contract-refresh-contract.sh PASS；node deploy/trialrun/validate-env-contract.js PASS。三个 helper 临时副本分别注入“只检查 daily service”“手动模式忽略 timer active”“断链当不存在”：使用 git show f6d1025d:scripts/qa/run-deployment-contract-refresh-contract.sh 的旧测试三次均 exit 0，使用当前测试三次均 exit 1（KILLED_BY_NEW_TEST），证明此次新增断言分别捕获原来的覆盖缺口。变异仅在自动清理的临时目录运行，生产 helper 源码未改。
• python3 .trellis/scripts/task.py validate 08-28-production-arm-backup-transfer-incident、node scripts/qa/check-trellis-governance.mjs、node scripts/qa/check-process-contract.mjs --baseline --json、三个改动文件的 scanSensitiveText 检查及 git diff --check 均通过；node scripts/qa/audit-docs.mjs --check-registry 无错误，保留既有 22 个未登记文档警告。本轮只改测试与说明，不重复执行未受影响的业务/数据库生命周期测试。
• 第 5 条 refresh_program FAIL 分类细化保留为非阻断后续，不扩入本轮。

本轮仅测试和任务说明补漏，不提交、不推送、不连接或修改生产/ARM。远端批准清单仍待形成；本轮结果不代表实际停用完成。

2026-10-05 最新决定与本地落实：仅手动快照

用户明确选择仅手动快照，不用其他厂商对象存储，也不再选 ARM/hyinda-20c 承担备份。此前对象存储选型、ARM 修复或替换、两个自然周期验收不再作为当前推进目标；原始结果保留，不勾成通过、不自动归档。

• 复用本 task，更新 PRD 当前目标、design 切换方案及部署规则；不再询问备份产品选择。
• 本地确认停用依赖：scripts/refresh-deployment-contract.sh:verify_timers 要求三个自动备份 timer 启用且运行；生产身份仍取自 daily service。不能直接卸载或停 timer 后宣称发布兼容。
• 本地 task validate、Trellis governance、process baseline、敏感扫描及 diff 检查通过；docs registry 无错误，保留 22 个未登记文档的既有警告，本轮未改动 docs 或处理这些文件。
• 用户 2026-10-05 批准适配后本地实施并验证：
  • scripts/refresh-deployment-contract.sh：新增根属普通文件 /etc/hyb-oa-backup-mode 显式模式。文件不存在 = 原自动模式（行为不变）；内容恰为 manual_snapshot 时要求三个自动备份 timer disabled:inactive（否则 exit 45 backup_timer_not_disabled），hyb-oa-warch3-ops.timer 仍须 enabled:active（43）；其他内容/符号链接/非 root 属主 → exit 44 backup_mode_invalid，probe 同样校验。不删除、不 mask 备份 unit，部署身份仍取自 daily service。
  • deploy/trialrun/deployment-contract-lib.sh 增加 44/45 分类；validate-env-contract.js 增加必需片段；部署规约 Validation Matrix 增加对应条目。
  • 验证：run-deployment-contract-refresh-contract.sh PASS（新增自动模式下停用失败、手动模式通过/全部运行/部分运行/ops 停用/内容非法/多行/符号链接/移除模式文件回归共 10 组断言）；两个源码变异（手动模式接受运行中 timer、跳过内容校验）均使测试变红；validate-env-contract.js exit 0；deployment-safety-contract 39/39、deployment-db-lifecycle 52/52。
• 复核补充（同日）：①probe 也执行模式与 timer/service 一致性检查，部署前即拦截，refresh 部署后复检；②手动模式还要求三个备份 .service 为 inactive/failed，在途运行 → 45。新增 7 条断言（probe 拦截运行中/部分运行、自动模式 probe 拦截停用、服务 active/activating 拒绝、failed 放行）；probe 去掉 timer 检查、去掉 service 检查两个变异均使测试变红；合同测试、env 合同、部署安全 + DB 生命周期 91/91 通过。注意：自动模式下 timer 异常现在部署前就失败（原先只在部署后失败），属有意收紧。
• 远端切换（另批；生产需 root 安装权限，ARM 需用户 sudo）。顺序：
  1. 先将最终获批提交的安装器和 helper 同步到生产目标代码目录，核对来源提交与文件摘要（同步本身也需远端写入批准）；installer 从该目录取源，不会自动取得本地提交。再用 install-deployment-contract-refresh.sh install 安装新 helper；无模式文件时仍为自动模式，forced-command probe 须 PASS。
  2. 先 systemctl disable --now 三个生产备份 timer（只停定时器，阻止新任务启动，不动 service）。
  3. 有界等待三个备份 service 变为 inactive/failed（上限预先写定，例如 90 分钟）；超时则停止切换，不强杀。执行前明确批准超时处置：恢复本次停用 timer 的原启用状态并验证自动模式，或保持停用且不写模式文件、记录“切换未完成，部署被阻断”。回滚未获批时使用后一种停止状态并报告，不擅自重启或宣称切换完成。
  4. 写入 /etc/hyb-oa-backup-mode（root:root 0644，内容 manual_snapshot），forced-command refresh 返回 PASS。
  5. 由用户 sudo 在 ARM 上 disable --now hyb-oa-offhost-deadman.timer 并单独核验 timer disabled:inactive、service 非 active；生产侧 refresh 成功不能代替 ARM 核验。未停 dead-man 时，生产停传后 ARM 会发一次 archive_stale。
  • 回滚：按保存的原状态恢复模式文件和本次变更的 timer；原为自动模式时移除本次模式文件，重新启用原本 enabled 的 timer，再跑 refresh。源码确认生产备份及 ARM dead-man timer 均配置 Persistent=true；现场复核后，将重新启用可能立即补跑及产生告警纳入回滚批准，不将其描述为无执行副作用。历史备份、unit 文件、公网健康探针均不动。
• 用户回传 f6d1025d 同模型独立只读复核通过，无阻断项；5 条非阻断问题及本轮补漏见顶部。新改动的本地验证与该次独立复核分别记录。
• 形成固定版本、模式配置、四个备份 timer 及回滚清单，另获生产/ARM 配置变更批准后执行与核验。

运行状态：未连接生产或 ARM，自动备份/告警可能仍按旧配置运行；未停用定时器、未删除历史备份、未创建快照。原适配已提交为 f6d1025d，本轮测试与说明补漏未提交，未推送或归档。当前选择不自动停用独立公网健康监控。手动快照执行时记录目标确认、覆盖确认、创建时间及成功状态，不记录真实资源标识。

2026-10-05 告警频繁的只读核验（用户当轮授权，ARM 普通账号）

背景：用户反馈群内仍频繁出现“内部 OA 运维恢复通知”及“OA 公网健康告警/恢复”。授权范围为生产与 ARM 只读核验；生产主机读取被本机工具权限策略拦截，未执行，生产侧数据全部为 NOT_RUN。

ARM 侧结果（13:30–13:45 CST，只记聚合值，不记地址/路径/日志原文）：

• dead-man：timer active/enabled，10-05 06:30 service success/0。说明当日 06:30 时 ARM 最新归档未超 26h 阈值；归档完整性未复核（目录及 sudo 仍不可用）。
• 公网健康探针：timer active/enabled，13:30 那次 service 以 exit-code/1 失败，耗时约 11s（与 10s 超时一致）；具体类别在 root-only 状态/journal，普通账号读不到（journal 返回“无条目”）。
• ARM → OA 公网入口：ping 三轮丢包 67% / 74% / 52%，RTT 约 143ms；HTTPS /ready 40 次中 11 次超时（10s）、13 次 TCP 建连 >1s、平均 3.35s。
• 对照：ARM → 其他三个国内目标 ping 0% 丢包；ARM 本机 DNS 解析约 1ms（已缓存），当前不是 DNS 阶段问题。本机开发环境经代理（假 IP 段）访问，40/40 成功，但路径不同，不能证明生产入口对普通用户正常。

判断（假设，未结案）：当前公网健康告警的主要成因是 ARM 到生产入口这条线路持续丢包导致请求超时，不是 OA 应用不可用。同一条线路的丢包也可能是历史 rsync 传输中断（partial）的成因，需生产侧传输记录印证。丢包发生在 ARM 运营商一侧还是生产入口一侧尚未区分；若在生产入口一侧，真实用户也可能受影响。

未完成 / 下一步：

• 生产侧（备份/watchdog 服务结果、告警状态、容量、近 7 天告警类别与部署时间对照）：需用户放开本机对生产主机只读命令的权限，或由用户手动执行。
• ARM root-only 公网健康状态文件和 journal 中的类别统计：需用户以 sudo 手动执行固定只读命令。
• 区分线路问题在哪一侧：需要第三个直连观测点（不经代理）对生产入口测丢包。

2026-10-05 候选替代节点 hyinda-20c 只读摸底（用户当轮授权）

• 形态：Windows 主机上的 WSL2（Ubuntu 22.04，x86_64，20 核，15 GiB 内存），经动态域名 + 非标端口映射访问；普通账号 sudo 需密码；无 Docker。
• 可用性：开机约 9 天；近两个月重启记录集中在 09-26（多次）与 08-22（多次），生命周期受 Windows 开关机/更新/WSL 实例回收影响。
• 存储：WSL ext4 显示 1 TiB 虚拟盘，实际受宿主 Windows 盘余量约束（宿主两盘分别约 167G / 88G 可用）；未见 Linux 层磁盘加密，宿主 BitLocker 未知。
• 网络：节点流量（含指定公共 DNS 的解析）均被本机透明代理接管为假 IP 段，到 OA 入口 HTTPS 70/70 成功、平均约 0.13s，但不是直连测量，不能作为线路证据。
• 容量需求参照：既有记录单批次聚合约 11 MB 量级，容量和带宽对任何候选节点都不是约束；选型关键是常在线、独立、可控访问与恢复能力。
• 用户决定（2026-10-05）：不购买轻量“自动备份”（备份点按 60GB 盘容量预付至实例到期，约 983 元）；采用每次部署前手动创建轻量免费快照（配额 2，满则删最旧），已写入 .trellis/spec/hyb-oa/deployment-trialrun.md Rules。快照随实例销毁而删除，不替代实例外副本；实例外副本（另一厂商对象存储）与 ARM 链路退役待用户另行决定。用户确认控制台中名为“Windows Server”的轻量实例即 OA 生产（实际为 Linux，仅实例名称历史遗留），快照对象即此实例。
• 结论：不建议 hyinda-20c 作为主要异机备份节点（WSL 生命周期、代理接管网络、虚拟盘依赖宿主、无加密证据）；可作为额外副本候选。主要节点建议改评国内云的独立厂商对象存储或小型云主机，待用户决策。

2026-09-17 结案缺口与最小补证方案（本地整理，未执行远端观察）

据09-08后期W4推进，复用本task既有调查器和历史脱敏结果，不重跑旧调查/恢复。两自然日期09-14/09-15副本完整性已由既有记录证实，09-16源又有同源绑定；不再把“等待两份副本”当剩余工作。自然恢复不证明根因修复；本次只把AC的剩余证据和停止线列清。

AC	已有支持/缺口	下一步最小取证及判定
AC1	原生产完整批次/单点分类、成功prune/失败保留、partial不同停止位置有据；真实rsync码和可靠传输时长NOT_AVAILABLE，不能推定单一根因	可保留“历史不可测、根因未收敛”的明确裁决；以后只有同次自然失败才提取绑定运行的退出码/阶段专属时钟。没有新异常不建议为追根因重传
AC2	本地分类器修复已验证；未实施传输/生产容量修复	需审阅结案口径：若无需传输修改，明确接受观察性结案条件；若容量不足，先给具体最小处置/回滚清单再批准，不能勾为修复完成
AC3	两自然日期完整原子副本已有manifest/集合/字节/SHA证明	复用原证据，未来不重复消耗同一等待条件；本轮未刷新时效
AC4	既有daily/watchdog/dead-man部分状态与后验记录；跨两周期service结果配对未齐	下次获批只读观察同时取timer active、最近运行开始/结束、Result、exit及最新归档身份摘要；active本身不是success
AC5	两日期完整性已有；两个自然周期各自partial/容量趋势未齐	优先找同窗口既有脱敏聚合；不足时只补下一两个自然周期相同字段，不手工补跑。每周期记录新增完成批次数、partial件数/总字节、空闲字节，缺历史基点标NOT_MEASURED
AC6	原10GiB可用不是经核的峰值预算，也不是当前容量事实	同批准只读观察取可用字节、受管保留批次总量、自然构建/备份峰值；预算=一次完整新批次实测额外峰值+经审阅安全余量。峰值或余量未定记UNKNOWN，不用最新压缩包大小替代双份DB/附件/镜像的峰值
AC7	发送调用与人工确认分开合同已有；缺自然事件响应样本	责任人shunli协调系统管理员与公司责任人；自然告警仅记录发送时间、首个确认时间与延迟、是否升级；无事件=NOT_TRIGGERED；无确认=NOT_ACKNOWLEDGED，不能把sent当阅读，不发测试通知
AC8	本地工具/治理与交叉引用已有	本轮更新后再跑task/Trellis/process/docs/敏感/diff；不替代上面远端项

合并只读观察的输入门禁：固定两个自然周期、既有allowlist调查器版本、双方角色与授权范围；输出仅时间、布尔/分类、计数、字节和脱敏运行标识，不含Secret、地址、真实目录或原始日志。本轮不生成可直接执行的远端命令，也不读真实配置。观察发现无合格新鲜批次、空间不足下一次预算、partial增长或监控失败时记录对应风险并停止扩读；修复、清理、改timer、补传、告警发送分别另批。原恢复PARTIAL和旧入口已消费不变。

当前仍有AC1/2/4/5/6/7共6项缺口或裁决，AC3/AC8有范围内证据；不按表格存在性批量勾原PRD。下一可执行动作是接回非秘密观察事实/具体授权，当前主会话继续其他本地工作。

2026-09-17 原AC本地证据映射（未新增远端操作）

按09-08协调规划仅复用已存PRD/实施回执，不连接生产/ARM、不读真实配置/备份、不重传/清理/改timer，不重新跑恢复。此表是原验收对账，不修改PRD复选框，也不把已有局部证据升级为全部结案。

原验收	现有本地记录支持的事实	尚缺与后续计划
AC1	08-28记录有完整本地恢复点、清理保留语义、partial聚合与different修订、空间及wait_natural建议	rsync原始码/传输时长NOT_AVAILABLE，未收敛单一根因；保留未测原因，不从旧mtime/通用exit补造。新异常再按原调查范围审阅
AC2	链路曾自然恢复，有后续完整副本	无可绑定的最小修复/回滚/容量处置闭环证据，不能称已实施修复；出现可证缺陷或预算不足后再提交具体变更方案
AC3	09-16人工只读回执证明09-14/09-15自然批次manifest、DB/storage字节/SHA及原归档元数据一致	该子项已有证据，不再无理由等待两个日期；本轮仅引用arm-user-readback.json，不新读备份
AC4	09-16生产及ARM回执有timer/service success/0与新鲜度观察	不代表每个自然周期三组监控全部逐项验收；整理原同窗观察可覆盖部分，缺项待有授权的限定观察
AC5	两个自然日期的新完整副本已证	每周期partial数量/聚合字节、监控与双方容量趋势未形成完整成对记录；不得以两个归档摘要替代整个AC5
AC6	已有不同时间点容量观察	一个完整新批次实际峰值+安全余量的审阅预算及两个周期趋势仍不齐；先按现有聚合数据拟预算，必要取数另列范围，不主动扩容/清理
AC7	既有告警响应计时合同要求，历史首次知晓时间不可补造	启用状态和自然告警/恢复样本、人工确认锚点尚无完整闭环；未触发或无证据如实区分，不发送测试消息
AC8	与08-23交叉引用保留，本轮按更新文档执行本地task/治理/流程/文档/敏感/diff门禁	本地门禁通过不替代AC1–AC7；实际结果归09-05本轮收口回执

原事件保持开放，责任人shunli。下一结案入口是逐项补齐可用旧证据，再针对剩余字段固定最小观察/预算方案；根因仍不可得时保留限制或另审验收处置，不为全绿重传、改历史记录或批量归档。

2026-09-16 人工只读回执：两个自然批次异机完整性通过

用户13:16:49Z在ARM以sudo运行已固定摘要探针，回执来源USER_MANUAL_SUDO。09-15与09-14两份自然批次manifest与12:50Z生产回执逐一相同，数据库/附件字节和SHA256全部匹配，归档元数据未变；最新年龄18.78小时，前一批42.78小时为正常历史批次，不以旧批超过24小时判最新副本陈旧。ARMtimer active、service success/0且检查前后不变，目标盘余89.38GiB。

两个连续自然日期的异机完整性证据已补齐；这证明这两份副本已到达且完整，不重建当时传输过程/失败持续时间，不替代PRD其他根因、修复和验收要求，不自动归档事件。普通账号访问限制仍存在，不再将其误写成此次人工核验也未完成。规范化回执位于postrelease-recovery-20260916/arm-user-readback.json；没有生产/ARM配置变更、重传、归档修改或恢复。

2026-09-16 最新自然备份只读核验计划

归属09-08总任务P1，为08-23配对恢复选源提供事实。本轮仅规划，未连接远端；历史2026-08-28调查结论不等于本日链路仍健康或仍故障。现生产发布b1d25d3c；09-16手工842c61e6备份仅已知同机存在，不能抵消异机传输/自然周期验收。

• 确认只读访问范围与权限，记录生产/ARM同一观察窗口；读取既有受控合同确定目标和状态来源，不靠历史日志猜地址/路径。
• 分别选生产与ARM正式目录的最新自然complete批次，核manifest规范、文件集合/类型、大小/SHA、来源build/image及年龄；核同批对应关系。手工/周备份/partial分开，不拿目录mtime替代createdAt。
• 分列“最新自然批次时效≤24h”“异机完整性”“当前发布同源恢复点是否已形成”；祖先构建但同源镜像可恢复不等于坏备份，当前发布滞后另记finding。
• 核daily/watchdog/dead-man的现有timer、最近退出状态与脱敏告警状态；失败退出码只在能绑定同次传输时归因，不凭service通用exit推断rsync故障。不发消息、不restart或修配置。
• 记录双方容量、既有partial数量/聚合体积及变化；没有前一可靠观察就记趋势NOT_MEASURED。向08-23提供ARM平台/资源能力事实，不读取原件/数据库业务内容。
• 有一个合格最新批次可支持08-23准备单次恢复；事件结案仍须两次连续自然周期各自新批次及完整性/监控/容量证据。历史档案可追溯则复核利用，不要求无理由多等两个周期；缺证据才等下一自然周期。

若失败，先提交一份最小故障分类和拟操作范围；手工重传、源复制、镜像加载、清理、参数修改与告警发送都另批，不将只读计划默认为修复许可。产出附回09-08及08-23，避免另开事件任务或重复建工具。

Phase 0：规划与授权

• 创建 P1、operations Trellis task，记录来源事件和与恢复演练的阻塞关系。
• 固定只读调查、生产/ARM 写操作、手工补跑和测试告警为不同审批边界。
• 用户审阅并批准本规划及补充项后运行 task.py start；该批准只授权进入本地实施，不自动授权连接远端。

Phase 1：本地只读调查准备

• 从 scripts/run-automatic-backup.sh、receiver、dead-man 和 systemd installer 提取真实单位名、状态路径来源、阶段和退出码合同，禁止手写近似常量。
• 实现只输出 allowlist 的跟踪只读采集器：生产本地完整恢复点合同、本地成功/失败清理保留语义、partial 匿名字节比例、rsync 原始码、无法取得的传输时钟、两端容量；timer/service 继续复用既有只读 systemd 聚合合同，不在 Python 中另写一套。
• 为本地完整/无完整批次、成功清理/失败保留、相近/不同停止偏移、rsync 23/30/12/11/255、缺失持续时间、权限拒绝、畸形 manifest 和敏感输出补合成回归。
• 本地语法、合同、敏感扫描全部通过后，提交远端只读调查摘要与精确权限边界，单独申请执行批准。

本地准备结果（2026-08-28）

• 跟踪调查器：scripts/qa/inspect-backup-transfer-incident.py；仅接受显式绝对路径参数，不回显参数值，未知异常也只输出稳定类别。
• 可复跑合同：scripts/qa/run-backup-transfer-incident-contract.sh；初始 19 项合成检查通过；现场分类缺陷修复后扩展为 20 项，fixture 与 Python cache 零残留。权限拒绝不会被误写成“无有效备份”，其他阶段的旧日志不会冒充本轮 rsync 诊断；生产多个批次时只哈希最新元数据合格候选，最新哈希失败不回退扫描旧批次；停止偏移必须同时满足 5% 和 64 MiB 双阈值。
• 既有 run-automatic-backup-contract.sh 74 项通过；生产 wrapper 未改。现状没有持久化传输专属开始/结束时刻，故持续时间必须为 NOT_AVAILABLE。
• rsync 原始码只在安全摘要明确为 phase_offhost_transfer_failed 时从 root 私有 last-error.log 固定正则提取，避免把 paired-backup/finalize 的旧诊断错误归因给传输。

Phase 2：获批的远端只读调查

• 在不修改生产/ARM 的前提下采集四类证据；每个临时入口在同轮精确清理并由外层独立复核零残留。
• 先判定“生产单点”或“无已证明可用备份”，再交叉判定主要根因、次要候选、清理/累积语义和容量预算；无法取得的字段标为 NOT_AVAILABLE/NOT_MEASURED。
• 记录过渡恢复点决策；只读证据无法收敛时停止扩读，提交一次受控观测性重传的独立审批方案，不直接执行。
• 更新本 task 证据，给出单一最小修复方案、回滚方案和生产写操作清单；停止并请求用户审阅。

远端只读调查结果（2026-08-28，追加时间线）

• 公网 /ready 调查前后均 PASS，12 位构建前缀均为 7b86ffb3c9ef；生产固定入口与 staging 经外层独立枚举均为 0，ARM arm_independent_residue=0。调查未改变在线 OA、正式归档、timer 或业务数据。
• 生产：complete_local_recovery_point=yes、backup_risk_classification=production_single_point；完整哈希通过的最新批次 1 个、元数据完整批次 7 个，最新候选年龄 42885 秒、聚合 11400180 bytes；生产文件系统 82% 使用、10 GiB 可用。源码顺序证明传输失败保留完整本地批次、异机成功后 prune、生成临时对象在失败路径清理，故过渡动作是 wait_natural。
• 生产最近 daily/watchdog service 均为 success/0、timer active；历史失败摘要未保留可绑定到本轮的 rsync 原始码或传输专属时钟，因此退出码和时长均为 NOT_AVAILABLE，不得用 service exit、mtime 或对话时刻替代。
• ARM 原始输出：partial 2 个，聚合 2682168 bytes，样本总字节分别为 2682168 与 0；调查器当时输出 arm_partial_stop_offset_class=similar。该原始结果不回写。
• 分类缺陷修订：旧实现以 max(64 MiB, 5%) 为接近上限，使 2.68 MB 与 0 字节被 64 MiB 阈值错误吞并。按固定阈值必须同时满足的合同，人工重算为 different；一个约 32 日龄 partial 满足完整合同但未 finalize，另一个约 36 小时龄 partial 为零字节，不能据此声称两次都停在同一确定性偏移。
• ARM 正式原子归档 7 个、无无效归档，最新完整归档年龄 45756 秒；inbox/archive 文件系统 54% 使用、89 GiB 可用；dead-man service success/0、timer active、最近状态 PASS_OFFHOST_DEADMAN_FRESH/healthy。链路已自然恢复一个新鲜原子批次，可解除恢复演练的事件阻塞，但 P1 仍需第二个连续自然周期及容量验收后才能结案。
• arm_deadman_alert_state_finding_count=invalid 不表示远端状态损坏。仓库 helper 明确把 alert state 写成仅含 schemaVersion/status/category 的去抖状态；findingCount 属于 last-deadman.json summary。私有探针错误复用了 summary 读取模板，后续证据不得把这个表示缺陷升级为告警链 finding。
• 独立 finding：ARM health service 为 failed/1，但公网 /ready 实测前后一致且 PASS。这是健康监控执行/状态/通知链问题，不是 OA 当前不可用的证据；本次授权不覆盖进一步调查或修改。
• 根因裁决：历史单一 rsync 原始码和可靠传输时长不可得，两个 partial 的真实停止位置明显不同，现有证据不能收敛为单一根因。不得把自然恢复一次冒充“已实施修复”；后续若再失败，候选动作是另行批准的一次受控观测性重传。生产 10 GiB 余量仍需独立容量方案。

分类缺陷复盘

• 根因类别是“隐含假设 + 测试覆盖缺口”：实现用 max(absolute, relative) 把两个独立上限误写成二选一宽松上限；旧正例夹具只证明“绝对差异较小”，没有证明相对差异也在 5% 内，因而为错误实现背书。
• 修复机制已闭环：实现改为 min(...)；合同直接覆盖现场 2682168/0、同时满足双阈值的正例、分别越过相对/绝对阈值的负例；稳定 spec 写明公式、错误写法与断言点。仓库搜索确认该分类公式只有这一个实现位置，不存在需要同步的第二套逻辑。
• 原始远端 similar 保留，人工修订追加为 different；以后任何现场分类缺陷都按同样的不可变时间线处理，不回写旧证据。

Phase 3：本地修复与变更审批

• 仅修改证据支持的脚本/installer/合同；不轮换已通过初始认证的密钥，不放宽 manifest/finalize 门禁。
• 容量方案优先扩容或精确处置已确认的自动备份自有对象，证明不会触碰唯一恢复点、数据库或附件源。
• 运行自动异机备份、receiver、dead-man、故障注入、回滚和敏感输出合同。
• 列出生产/ARM 的每个写目标、旧值指纹、候选 SHA、执行/回滚命令和停止条件，单独申请实际变更批准。

Phase 4：获批的实际修复

• 执行最小变更和容量处置；不做未批准的手工备份、timer 修改、partial 清理或测试告警。
• 若另获手工补跑批准，只运行一次并记录真实 rsync 码、时长、原子 finalize 和残留；失败不自动重试。
• 验证至少一个新原子批次、manifest/三文件/字节/SHA-256、三组 service exit 0 和容量预算。

Phase 5：两个自然周期观察

• 自然周期 1：daily 新原子批次 PASS；watchdog/dead-man service success；记录生产/ARM 容量、ARM partial 数量/聚合字节趋势和适用的告警响应锚点。
• 自然周期 2：重复同一组断言；不以手工补跑或旧批次替代；ARM partial/容量趋势不得继续恶化。
• 两个周期均通过后标记事件 GO，否则保留失败并返回 Phase 2/3，不临时放宽阈值。

Phase 6：解除阻塞与收口

• 在 08-23-isolated-backup-restore-drill 追加本任务结果交叉引用并解除事件阻塞；恢复演练仍需新批次身份探针和单独实际恢复审批。
• 运行 task validate、Trellis governance、process baseline、docs registry、敏感扫描和 git diff --check。
• 中文提交引用 08-28-production-arm-backup-transfer-incident；不自动 push，不归档未满足两个自然周期的任务。

停止条件

• 只读操作将输出路径、身份、凭据、原始日志/JSON 或业务内容。
• 需要新增 sudo、读取超出 allowlist 的 root 状态或改变生产/ARM 状态但尚未获独立批准。
• 清理对象、配置目标、旧值或回滚路径不唯一。
• 新原子批次不完整、service 非零、容量低于预算或任一自然周期失败。
• 告警发送/人工确认锚点缺失时不得补造响应延迟。

验证命令

• bash -n / python3 -m py_compile 覆盖新增或修改的运维脚本。
• 运行自动备份、receiver、dead-man 和相关敏感输出合同。
• python3 ./.trellis/scripts/task.py validate .trellis/tasks/08-28-production-arm-backup-transfer-incident
• node scripts/qa/check-trellis-governance.mjs
• node scripts/qa/check-process-contract.mjs --baseline --json
• node scripts/qa/audit-docs.mjs --check-registry
• node scripts/qa/check-sensitive-content.mjs
• git diff --check

2026-09-16 新时点只读实施

12:50Z核生产最近两个自然批次：09-15T18:30:05Z（b7d2285d，manifest 0913782f84bf7253a8ea1a24e727f8c20a6a637c58737b5df767331809dd2f4e）和09-14T18:30:05Z（229867f5），两者database/storage字节与SHA256均匹配、归档元数据未变。最新年龄18.34小时；生产盘余27.39GiB、备份timer active、service success/0、容器运行身份前后不变。不是当前b1d25d3c的同源自然备份，手工备份未混入自然批次。

ARM可SSH且普通账号可读systemd状态：deadman timer active、service success/0；正式归档目录访问被拒，非交互sudo不可用。结论ACCESS_UNAVAILABLE，不是PATH_NOT_FOUND，不是异机副本损坏，也不是完整性PASS。没有安装探针、改权限/定时器、重传、清理或触发告警。两个连续自然周期的异机独立完整性证据仍未取得，事件不结案。

证据：artifacts/qa-layout/postrelease-recovery-20260916中的production.json、arm.json、arm-unprivileged.json；下一步需具备归档只读权限的执行方式，再重取同一时点双方批次摘要。生产端通过不能替代异机端，通过一次也不能覆盖两个自然周期要求。