生产健康：终态债务处置与 live verify 验收

[HCHogan]

目标

Max 应能用受支持的命令检查持久化一致性与运行健康，并能区分仍待解决的问题、正常排队和经过审查的历史终态。

2026-09-06 按 main b7ccaf0 核对时，命令和状态分类已经实现，但生产验收与终态处置尚未完成。2026-09-09 已部署 ba7387d，完成受支持的审计处置和两次带流量的生产只读验收；下方保留此前实现与历史证据。

已实现

• lower_notes 可在 admin timeline 查看，支持解释每个 endpoint 的降级。
• max-adr003-maintenance health 与 verify 已有可执行检查；runbook 要求部署后在有流量时运行准确部署版本的只读 verify，旧的“不要运行 verify”警告已失效。
• migration 086 将 permanent_failure 与主动 suppressed 分离，存储、平台状态、admin/timeline/UI 和健康查询已经打通；相关数据库测试覆盖两个状态独立计数。
• Max.DB.Health 是共享检查来源，包含 task attempt/deadline、frontend lease、任务通知和 request 状态；已经移除退休 Plan 表的健康查询。

实现证据：migration 086、状态分类测试、health 查询。这里勾选的是已落地的源码能力，不是生产整体健康已经通过。

2026-09-09 已完成

• 终态债务有受支持的 reconciliation/acknowledgement 生命周期。 对 outcome_unknown、permanent_failure、parked media 等，提供有类型、可审计、作用域明确的运营动作，区分未处理、已核实解决和明确接受的历史事实。保留原始证据，避免依赖临时 SQL 清零；未知非幂等副作用不得通过确认动作隐式重发。
• 健康门禁与处置生命周期一致。 经过审查的历史事实仍可追踪，新的未解决问题继续让门禁失败；不能简单放宽查询或把所有终态一律忽略。
• 完成生产只读验收。 在准确记录服务版本/迁移的前提下，确认活跃流量下 verify 和 health 的结果，分别记录投影一致性、运行队列、终态债务和租约；修复后重复检查以证明新问题没有继续增长。
• 把实际验收证据写入部署流程。 源码测试、空/测试库通过、服务 active、生产带流量验证分别记录，任何一个都不能代替另外几个。

历史证据的有效范围

2026-09-05 的只读生产检查发现 stale rendered_text、delivery/dispatch ambiguity 和 parked media；详见已有评论与 runbook。这是当时的快照，本轮没有把这些旧数量当作当前生产数值，也没有修改生产数据。

当前源码仍把未处置的终态计入健康失败，因此只完成检查命令本身不能关闭本 issue。

关联：#13 跟踪 iMessage 已知 bridge down 时仍开始投递的问题；#19 跟踪数据库/effect 边界整理。两者都不替代本 issue 的运营处置与生产验收。

本次生产验收

完整版本、迁移、演练、审计 ID、命令与数据证据：2026-09-09 发布验收记录。

• h610 实际部署 Max ba7387d2ea916af851651efe797861646a0a0dae，nix-config e506529；migration 102/103 于 06:44:07 UTC 应用。
• 3490 条部署前历史终态经分类审查后记为 accepted，审计 ID 1–3490；源记录保持原状，没有重发、重跑或删除数据。新观察版本和未审查终态仍使门禁失败。
• 06:52:11–06:52:16 与 06:54:33–06:54:38 UTC 两轮 exact-binary verify 和独立 health 均通过，间隔超过 120 秒投递租约；所有活跃租约/截止期限和未知 journal 检查为 0。
• 两轮间消息数 164986 → 164997；部署后 148 次 QQ 投递确认，终态债务没有新增，服务 NRestarts=0。
• 1103 单元测试、357 真实 PostgreSQL 测试、生产快照迁移演练、Darwin/Linux Nix 构建及发布版本 CI 全部通过。

边界：iMessage bridge 仍连接超时并等待恢复，未据此关闭 #13。291 条历史 waiting/delegated 请求仍如实显示，不把数据库健康门禁通过等同于所有历史请求都已回答。

[HCHogan]

Status check 2026-09-05 (corrected after finding a usable read-only production path):

• lower_notes is already exposed by the admin timeline and covered by Max.AdminTimelineSpec; the first item is checked.
• The exact deployed 0.17.3 maintenance binary was run read-only as max-bot against the live database while traffic was flowing. verify is executable but not green: it found 2,522 stale rendered_text projections among 149,395 messages. The first 50 mismatches are dated 2026-08-06 through 2026-08-07, consistent with historical projection debt; no reproject write was attempted. The second item remains unchecked.
• Equivalent read-only operational queries found 1,175 delivery outcome_unknown, 9 dispatch outcome_unknown, and 385 parked media jobs, with no expired delivery/dispatch lease and no stuck monitor, plan, active journal, or sandbox state. This is not all historical: five iMessage mirror deliveries entered outcome_unknown after the current service started, and current logs show the iMessage bridge still timing out roughly every 90 seconds while the Max service remains active.
• A local change introduces migration 086 and a distinct permanent_failure state through store, status API, overview, timeline, UI, tests, and the operational health gate. It is not checked here until that change is committed/deployed and the live query is verified.