R2.02.2Feature-complete pre-release walkthrough设计
需在功能完成后、发布前进行
别名: 功能完成走查 · 发布前验收 · 过早走查 · 过晚走查
概念解释
走查的窗口卡在功能完成之后、发布之前（feature-complete pre-release walkthrough）。功能完成指主路径、空、错、加载、权限拒绝这些约定状态在预发环境里都能走到，而不是「代码合进了主干」。发布之前指改动仍进得了这一次的发布包。窗口之外做的活动可以叫评审或补丁，不再是这次走查。
过早：缺的状态看起来像缺陷，走查记录会被未完成工作填满，真正的意图偏差被噪音盖住。过晚：同一条发现已经到了用户手里，修复要另开窗口，走查退化成事后登记。
机制
判断需要完整对象。空态、错误、权限拒绝若还没接上，评审者分不清「没做」和「做错」。过早走查产生的条目，一大部分会在后续开发中自然消失，剩下的那一小部分意图问题被混在过期条目里，跟进成本被抬高，团队学会忽略走查。
发布切点把可变性关掉。切点之后改的是下一列车，而下一列车有自己的范围，这条发现要重新排队。走查若落在切点之后，它不再能消耗「这一次还能改」的预算，只能消耗「以后再说」的预算——而「以后再说」没有强制力。因此窗口是唯一一段对象已经完整、改动仍然便宜的时间。日历上的位置不是礼貌问题，是判定条件是否成立的问题。
边界
持续交付、每日多次发布的流水线没有「一次大发布」，窗口改绑到「本变更的功能完成」与「本变更进入生产之前」，仍然是同一对边界，只是时长以小时计。热修只改崩溃、不含界面意图时，不应临时插入走查以免堵住修复。多端不同步发布时，每一端有自己的完成与切点，不能用服务端先发当作客户端已可走查。功能完成的定义若被缩成「主路径能点通」，空和错仍缺，窗口左边界其实还没到。
怎么落地
- 在发布清单里写下走查的两个时间戳：预发环境全部约定状态可走通的时刻，以及发布包冻结的时刻。走查必须落在二者之间。
- 会前用一张状态表打勾：主路径、空、加载、错误、权限拒绝。缺一格就延期走查，不要用「先看能看的」。
- 走查纪要写上对照的构建号；构建号若已越过冻结点，这次记录标为发布后发现，不进本轮必改。
- 验证：抽最近三次走查，核对时间戳是否夹在「状态表打满」和「包冻结」之间。三次里有一次在状态表未满时召开，或纪要对照的构建已经上线，窗口规则没有被执行。