未定义的情况会由实现者随意决定
别名: 未指定即发明 · gap filling in implementation · 交付缺口补全
概念解释
画面没画到的数据形状，并不会在工程里停住等下一次评审。未指定即发明（unspecified-case invention）指：交付包对某一内容边界保持沉默时，实现者必须当场造出一种表现才能让分支编译通过。造法来自个人习惯、邻近界面的记忆、框架默认值，而不是来自一份被共同看见的决定。缺口不是「暂时空着」，缺口是「决定权已经换手」。
这与组件缺了悬停、禁用那些交互态被随手补上不是同一件事。这里换手的是内容形状——超长编号怎么放、附件名为空字符串怎么办——不是控件自身的交互皮。
机制
产品要发版，未覆盖的 else 不能保持为空白。编译器、类型系统和测试夹具都会逼出一个具体分支：截断、换行、显示「-」、丢进省略号、或把空串当成缺失而隐藏整行。每位实现者面对同一缺口时，手里的默认工具不同——一端的排版默认换行，另一端默认裁切，第三个人从旧业务线复制了中间截断。这些选择单独看都像在解决问题，并置之后同一字段在三个页面上各走各的。
沉默还会被读成许可。评审过主路径的人会假定「没画出的等于不重要」，实现者则假定「没画出的等于可以按我熟的来」。两边都不觉得自己改了设计，于是分歧要到用户在两个入口看到两种表现时才被发现。交付包的完备性衡量的不是画了多少幸福路径，而是沉默被翻译成代码之前，有没有把翻译权收回来。
边界
明确写进延期清单、并标了负责人与下一次补帧日期的项目，不是沉默，是被登记的未知；实现者应走临时的显式占位（例如开发标记），而不是私自定终身表现。一次性原型、内部演示如果预定要扔掉，发明的成本可以接受，前提是这些发明不准回流进生产文件。实现者同时就是该界面的设计负责人时，当场决定是职责内的设计，不是缺口补全——但决定仍应写回源文件，否则下一位接手者又会再发明一次。平台控件的原生行为（系统日期选择器如何显示超长区域名）若产品决定全盘接受，需要在交付里写「跟随系统」，否则仍会被理解成可改。
怎么落地
- 在交付走查时把主路径上每一个数据槽列成清单，问「最短、最长、空值、非法值有没有对应画面」；任何答不上的格子标成缺口，而不是标成「实现时看情况」。
- 缺口必须二选一：补帧，或写成带日期的延期项并指定临时表现（统一显示为「不可用」，禁止各端自行发挥）。
- 禁止在口头上说「这个应该不会发生」而不落文件。若产品规则确实禁止该数据形状，把禁止规则和触达该形状时的拦截表现一并交出。
- 找两名未参加设计的工程师，各自只看现有交付包，独立写出某个未画槽位的处理。两份答案不一致，就是发明已经发生——在写代码之前把该槽补进包里。