Z4.09.4State reconciliation after recovery设计
故障恢复后需要确认状态而非默认恢复正常
别名: 恢复确认 · 上电状态 · power-on state · 状态再同步
概念解释
故障清除——设备重连、网络恢复、云端回归——之后，系统不该默认「一切回到故障前的状态」，而应把恢复后的实际状态摆给用户核对。因为恢复的只是连接，不是状态一致性：故障期间物理世界没有停，恢复后的世界已经是另一个世界。
一个常被忽略的硬件事实：许多智能设备断电重启后不记忆断电前的状态，回到出厂默认档（通常是「关」）。这个行为叫上电状态（power-on state / state recovery），它意味着「来电了」之后设备的状态取决于固件设计，而不是取决于停电前它是什么。
机制
恢复期的错位有三种来源，每一种都让「默认恢复正常」变成谎言：
- 物理改动没有被感知。 故障期间有人拨了墙上的开关、按了设备本体、机械地动了门——系统记录里没有这些，重连后它拿一份旧账本当现实。
- 错过的事件不可补。 降级期间本该触发的通知、联动、录像没有发生，它们不会在恢复后补放；界面上看不到「错过」这个事实，用户便以为无缝衔接。
- 部分恢复。 十台离线设备回来八台，剩下两台可能就此失联；全量恢复的提示会掩盖这个差集。
三者叠加的结果：用户以为系统回到了断点，实际面对的是一个新的、未知的、未被任何人核对过的状态。此时若安全相关设备也在其中——门锁显示已锁而机械状态被改过——问题就从体验升级为风险。
边界
- 不是每次恢复都要人工确认。 后果轻微、物理状态可直接观察的设备（一盏灯）恢复即用；需要核对的是三类：安全相关（门锁、安防布防）、故障期间可能被物理改动的、断电后不记忆状态的。
- 确认不能变成打扰。 每次路由器重启都弹确认框，用户会迅速学会无脑点「好」，确认流于形式；频次控制与安全分级是同一件事的两面。
- 「不记忆上电状态」是选型问题不是交互问题。 同一场景里，换一台支持状态记忆（或可配置上电行为）的设备，比任何界面确认都干净；交互补救应在选型之后。
怎么落地
- 恢复流程加一步状态核对：列出故障期间发生的变化——哪些自动化错过了触发、哪些设备回到了默认态、哪些设备没有回来——让用户逐项看见而非逐项手点。
- 安全设备恢复后显式重申当前态：「前门：已锁」要主动说一次，不依赖用户去查；重申的依据是设备实测回报，不是缓存记录。
- 采购与配置阶段标注每台设备的上电行为（记忆/固定档/可配置），把「关」默认的设备从安全链路里剔出去。
- 验证办法：制造一次复合故障演练——断设备电源、期间物理改动设备状态、恢复供电——逐一核对系统呈现的状态与物理实际是否一致；任何一处「显示恢复了、实际没有」都是缺陷。再数一次：恢复后到用户发现第一个状态错位的时间，这个时延就是核对机制缺位的代价。