收到过一封 Guideline 5.6 的评审暂停信。它和普通的版本被拒是两类东西，区别不在措辞严厉，而在于信里到底给了什么可操作的信息：它不指名构建里的任何缺陷，没有崩溃、没有缺失的用途说明、没有要补的文案，它指名的是一个日期，并且写明该日期之前，重投与回复都不会被处理。整封信的工程内容，就是那个日期。
而几乎所有的拒审处理反射都是为“缺陷型拒绝”建的：读信、修、重投。指向“日期型拒绝”时，这个循环没有东西可修，只剩一个被明确排除的动作，重投。于是最常见的两种消耗出现了：在按构造不可能成功的窗口里反复尝试；以及把这些从未被看过的提交计入“失败尝试”，让失败率开始说谎。如果链路里还有任何“收到拒绝就自动重投”的路径，它会一声不响地把整个窗口烧满。
处理顺序，每一步的存在都依赖它前面那步：
1. 先分类。对任何拒审信问两个问题：它指名构建缺陷吗？它写明日期吗？缺陷否、日期是，这不是 bug 报告，是排期，之后所有动作都以日期为闸门。 2. 不往二进制上花力气。暂停是版本之上的判定，任何一版构建的修补都不作用于它；用“再发一版”去回应，成本花了，对象错了。起作用的是回复通道：写清楚构建与提交环节具体改了什么、如何保证不再发生，附可核对的证据，而不是一个新的 build number。 3. 日期过去之前，一个尝试都不花；过去之后，用一个小的、受控的提交恢复，一个版本，盯到底。暂停刚解除就把积压全部推上去，从平台一侧看，与触发暂停的行为难以区分。
一分钟自检：翻开最近一封拒审信，只回答那两个问题。若答案是“无缺陷、有日期”，下一步应当是一个日历提醒和一封写清楚的回复，而不是一个新构建。然后再查一件事：有没有任何自动路径在“被拒”状态上触发重投？有，就给它加上“暂停类状态一律停”的规则，否则它会替你把日期前的窗口烧满。
这和一切自带时间的报错是同一条纪律：配额重置、冷却窗口、维护时段——原因写明了清除时间，就按排期处理，先验证条件已过，再花尝试。