M8-R10: document meter lifecycle recovery runbook
frontend / frontend (push) Successful in 47s
pytest / test (push) Failing after 3m55s

This commit is contained in:
2026-08-24 18:37:46 +02:00
parent b1b6a309cb
commit d5623b9fcb
2 changed files with 73 additions and 0 deletions
+30
View File
@@ -1211,3 +1211,33 @@ M8 收尾的前置条件。agent 不得执行、记录为已执行,或以 mock
- [x] 最终报告完整交付 §12 九步及用户证据模板;真实 serial/HA walkthrough 由用户在交付后自行验收,不能在报告中伪称 agent 已执行。
- [x] 文档、Roadmap 和 milestone 状态反映真实完成度;没有删除用户数据、没有真实 secret/设备身份,
没有未经授权的 push/tag。
## 14. Post-M8 lifecycle repairM8-R08R10
M8 交付后的 Meter lifecycle 修复链记录在本地 `review-notes/M8-meter-lifecycle-repair-plan.md`
它不新增 ORM / **数据库** schema 或 Alembic revision,不做启动自动修复、一次性数据脚本或历史删除;R08 虽然
更新了 API/Pydantic schema 及 OpenAPI/codegen,但没有变更 ORM 或数据库 schema。已有的 stranded binding 只能
由用户通过 UI 的原子 Transfer 恢复。
| 修复卡 | 当前状态 | 独立 review | 实现 / review 简报 |
| --- | --- | --- | --- |
| M8-R08Close、Unbind、原子 Transfer 与 API 契约 | done | PASS(第 6 轮) | `M8-R08-impl-*``M8-R08-review-6.md` |
| M8-R09Meter 管理 UI | done | PASS(第 12 轮) | `M8-R09-impl-*``M8-R09-review-12.md` |
| M8-R10:文档、最终报告与全量收尾 | done | PASS(第 2 轮) | `M8-R10-impl-1.md``M8-R10-review-2.md` |
R08 的 base commit 为 `c40ee65`(其自动化链包含 5 个 `fixup!`,最终 review 范围止于 `5a50b07`);R09
的 base commit 为 `5c08825`(包含 10 个 `fixup!`,最终 review 范围止于 `c4f4ff7`)。R10 已由第 2 轮
冷启动独立 Reviewer 判定 PASS 后标记 `done`;实现者的本地闸门结果没有被当作人工或 review 验收。
R08/R09 规定的用户操作为:Close active Meter、Unbind open binding、以单请求 same-Meter Transfer 切 source
以及把 closed previous Meter 上的 stranded DSMR binding 恢复到 active Meter。`meter_swap` 在唯一兼容 open
binding 时可自动 handoff;歧义一律 fail closed。恢复可选择晚于新 Meter 起点的时间并留下可见 gap,所有
lifecycle 写入与相应成本重算同事务,失败整笔回滚,HA discovery 只在 commit 后 best-effort republish。
stranded DSMR walkthrough 只能使用开发库中已经存在、由用户报告的 stranded row;不得通过 SQL、API、脚本、
migration 或直接改数据库制造前置状态。若隔离开发库没有这类历史行,应将该项记录为 `N/A/blocked`。Close、
Unbind、Transfer、Recovery 与 handoff 都会改写 Meter/binding 状态,walkthrough 必须将它们视为独立场景,使用
彼此独立且满足前置条件的 Meter/binding(或先恢复各自前置状态),不得按一个会破坏后续前置条件的连续故事操作。
按用户指定顺序,R10 必须先获得独立 Reviewer PASS;之后才由 Orchestrator 对未 push 的 fixup 执行 autosquash
并回填最终交付 SHA 与 commit 数。在此之前,报告只可陈述 pre-autosquash 审计状态,不得伪称历史已干净收口。