R1.03.3unspecified-state improvisation设计
状态缺失会在实现阶段被随意补齐
别名: 临场补状态 · implementation default · 实现期填洞
概念解释
规格里没有的状态，代码里不会留下一个洞——发布物必须对每一种输入有反应。于是实现者用自己的默认值补上：禁用写成透明度 0.4，错误写成红边，加载写成按钮里转圈。未指定状态的临场补齐（unspecified-state improvisation）会把缺口变成一簇互不兼容的私设，并且这些私设会作为产品被发出去。
它描述的是填洞这个动作及其后果，不是哪几格最常被漏，也不是转换路径怎么写。洞一旦补上，就很难再被认出是洞。
机制
实现阶段有硬约束：事件会来、属性会传、测试要点击禁用按钮。没有设计帧，工程师仍要写分支，否则类型、无障碍或视觉上会露出未处理。个人默认来自习惯和当时能抄到的邻近组件，不来自产品合同，所以同一缺口在不同仓库、不同迭代会补出不同答案。
更麻烦的是补齐没有标记。透明度 0.4 看起来像「有设计」，代码评审也看不到空帧，只有把两个页面的禁用并排才发现一个更淡、一个整钮变灰还关了焦点。缺口的真实形态不是空白，而是未经协调的发明家族。之后设计若补画官方帧，还要先清掉这些发明，否则官方帧会和已发出的私设打架。
边界
平台原生控件（系统开关、系统警告）的未指定外观由操作系统补，不由产品工程师发明，这时「随意」发生在系统侧，产品能做的是选用原生并接受其状态，或完全自绘并自己补全。黑客马拉松分支和本地草稿允许临时补齐，但合入主分支前必须把临场值升格为规格或删掉分支。动画中间帧若只存在几十毫秒、用户来不及当状态读，可以不单独出规格，但起止两态仍要有。
怎么落地
- 实现开始前把状态表里标为缺口的格子冻结为「不得私补」：对应分支要么阻塞发布，要么显式链到设计任务。
- 代码评审遇到没有设计帧对应的新状态分支，要求补帧或删分支，不允许「先用透明度顶上」。
- 把已经发出的临场值收进债清单，并排截图对比各页面的同一状态，作为清债输入。
- 验证：选一个曾缺帧的状态，搜全库该状态的实现；若出现两套以上互不相同的视觉或行为，临场补齐已经发生。收敛到一套并回写规格，才算补上的是合同而不是私设。