R4.13.3rejection cycle cost设计
被拒的代价是发布周期而不是修改量
别名: 审核周期代价 · resubmit cost · 驳回时间成本
概念解释
商店驳回之后，改一个按钮文案和重做半个功能，在日历上看起来几乎一样：都要重新排队、重新等、可能被重新看一遍不相干的屏幕。被拒的代价是发布周期（rejection cycle cost），不是补丁大小。设计决策若把「改起来很小」当成低风险，就看错了成本函数——闸门是离散的天数，不是连续的工时。
它不讨论规则约束什么，也不讨论审核员看不看源码。它讨论的是失败之后付的那种钱：时间，而且是发版节奏上的时间。
机制
二进制一旦离开团队，就进入一条团队控制不了的队列。驳回把产品从队列里拿出来，改完再从队尾进去。队列等待、版本号、可能的复审范围，都与 diff 的行数无关。一行文案和两千行重构，只要都触发一次重新提交，日历成本同阶。热修复若仍要过审，小补丁并不更快。
因此风险要按「会不会触发一次提交」来估，而不是按「改起来几个小时」来估。付费墙、首次路径、权限开口这类一旦失败就要整包重走的表面，设计上应被当成高周期风险，哪怕像素很少。把它们留到冻结当晚会把周期风险叠到功能风险上：修得快，也仍然要再等一轮。
边界
允许不重新审核的热更新通道（某些商店的资源包、网页部分）会让小改动的日历成本下降；不要把这种通道的经验搬到必须过二进制审核的客户端改动上。企业内部发布没有商店队列，代价回到真正的修改量。正在进行的加急审核、预约审核窗口会改变等待分布，但不改变「一次驳回 ≈ 一次完整再入队」的阶跃。已经下架、不再提交的产品没有周期可付。
怎么落地
- 把会触发重新提交的表面（付费、首次启动、权限、外链、元数据截图）从功能列表里单独标成「周期风险」，在冻结前闭合，而不是当成可以随版火车带走的小项。
- 冻结后改这些表面，视为一次新的发版，而不是「顺手改两个字」。
- 准备好驳回后的最小可提交集：只改被点名的屏幕，避免借机塞进未评审的交互，以免扩大复审范围。
- 验证：用最近一次真实或模拟驳回，记下从收到信到再次可被审核的日历天数，以及实际改动的文件数。若天数不随文件数下降，成本模型就应改成按次排队，而不是按工时。设计评审里对周期风险项问「晚一周上架可以接受吗」，而不是「改动大不大」。