专家评审覆盖的推理边界：源码正确不等于系统保证正确
锁库的 acquire 方法检查无误，租约过期也照常拒绝——但旧 worker 恢复后仍向库存库写入，因为守卫不在资源端。本页定义专家评审必须覆盖的推理边界、三层反问与"有条件通过"的写法。
评审应覆盖的六类边界
专家评审应覆盖工作负载和热点变化后的资源容量、响应丢失时的未知副作用、旧实例或迟到数据造成的陈旧写入、主库恢复后的重复与遗漏、降级对用户能力的影响，以及 SLO、成本和数据保留变化带来的决策重审。这些边界检验决策是否显式包含假设、所有者、监控、恢复和复查条件。
从局部实现追到跨域承诺
高级评审可核对API、关键源码与失败分支；架构师还需检查所有旁路写、恢复、迁移和组织责任是否一致。例"使用fencing拒旧worker"需资源端原子检查，备份恢复后令牌不回退，管理员脚本也不能绕过；只看锁库acquire方法不足以覆盖保证。
声明故障模型：单节点崩溃、分区、暂停后恢复、数据损坏与恶意参与者分别处理。共识协议的崩溃故障保证不能推广成任意拜占庭行为；三容器同主机也不能证明机房隔离。评审必须指出实验环境覆盖了什么。
三层反问与反例
第一层改变输入：峰值或对象大小十倍，容量、队列与索引怎样变？第二层改变时序：确认丢失、回调重复、旧主恢复，哪里裁决？第三层改变边界：跨库、跨区、外部支付，原来的原子性是否还成立？
给每层一个可计算答案。例如缓存命中95%→80%使1万请求回源500→2000；源日志保留2小时但恢复需5小时就无法依原offset完成；回滚旧应用无法读取新schema就不能安全回切。
演练：把"有锁"追问到恢复后的写入裁决
题设是3个worker竞争库存修改权，租约10秒，某worker在拿到令牌41后暂停20秒，另一worker得到42。只检查租约服务会发现41已过期，却不能阻止旧worker恢复后向库存库写入。评审必须找到库存资源端的原子条件，例如"仅当incoming_token不低于已见代际且操作唯一键未处理时接受"，并说明代际验证与业务变更在同一事务/原子域内。
继续改变条件：库存库从只保存令牌40的备份恢复，而发号服务也可能回到旧数据。此时旧41可能再次通过；原正常路径测试无力证明恢复后安全。候选包括持久且恢复不回退的代际、恢复时切换新的主权epoch、在重新开放写入前完成全局隔离和状态校验。不能仅把锁时长从10秒加到60秒，因为暂停仍可更长，且恢复回退并未被修复。
最后加入管理员修复脚本与批量导入。如果旁路不执行相同资源守卫，正常API的证明仍不覆盖系统。评审产物要列全部写入口及其约束、谁能绕过、绕过时的停写与审计流程，区分恶意绕过和受控运维。无需假装一个小实验覆盖所有故障，但必须准确限定它检验的历史。
推荐结论示例是"当前单库、持久代际与受控写入口下有条件通过；备份恢复必须停写并重建主权；跨区双写不在此次授权范围"。再为每个条件给能观测的指标、发布阻断点与主责。这样评审才从源码细节连接到可执行的系统承诺。租约与fencing的协议细节由租约和 fencing 令牌权威讲授。
验收和限制
评审结论可以是有条件通过：允许当前负载和单区写域，必须有故障扫描，跨区写需要另评。条件要可观测、可负责、可触发，不使用"注意稳定性"这种无法验收的句子。
准备五个变式让另一个人追问，要求至少一次改变原推荐。永远坚持同一方案可能意味着没有真正把约束纳入推理。此处"专家"作为专题深化训练名称，课程统一目标仍是高级必会与架构师进阶。
边界覆盖检查表与授权声明
本页讲了六类推理边界与"有条件通过"，评审时还需要一张覆盖检查表：每类边界要么有证据，要么显式声明未覆盖。六类边界是：容量与热点、未知副作用、陈旧写入、主库恢复后的重复与遗漏、降级对用户能力的影响、SLO/成本/保留变化的重审。
示例：容量有负载模型与余量表；未知副作用有幂等与查询路径；陈旧写入有资源端 fencing；主库恢复只有演练计划（未运行）——这一格必须写成缺口并给出负责人与触发条件，而不是留空。降级有权能契约；SLO/成本/保留有单位成本与保留预算。缺口一格，正好对应"有条件通过"里必须写清的那一条。
有条件通过的写法：允许当前负载与单区写域；必须有故障扫描；跨区写不在本次授权范围。每个条件要可观测、可负责、可触发。反例："注意恢复风险"不是条件——没有观测、没有负责人、没有触发点。
检查表还要区分"未覆盖"与"不适用"：拜占庭故障对内部服务可能不适用（明确声明），而多区双写对当前的区域级故障目标就是未覆盖（必须补证）。两者混淆，会把真正的缺口藏进"不适用"。
执行 python3 labs/review_models.py boundary_coverage：预期输出六类边界、缺口 ["restore_dup"]、conditional_pass=true 与规则"有条件通过要写明缺口、负责人与触发条件"。脚本只做覆盖检查，不执行真实演练。
两个合理选择：A 所有边界都要求实机证据才通过，严谨但多数方案无法上线；B 允许有记录的缺口加触发条件。本例选 B，并规定缺口必须在发布后第一个月内启动补证，否则条件失效、评审结论作废。
架构师变化条件
把租约从 10 秒延到 60 秒：暂停窗口缩小但恢复回退未修复，评审结论不变——追的是资源端守卫而非参数。若库存库改为多主复制，"资源端原子条件"的前提被打破，需重新评审写裁决位置。备份恢复加入跨区副本：代际持久性要覆盖副本链。每次变化重列全部写入口与守卫覆盖表。
闭卷验收
本页 8 道闭卷题收进了下方自测面板：先回忆，再展开参考答案与评分点，最后给三档自评。