一轮结束时,结果不是直接落地——它先过 design-kit 门禁。门禁对 agent 写出的文件运行 kit 的检查,并在 transcript 里报告:Gate passed,或者一份列出具体哪条规则挂了、在哪个位置的 FAIL 清单。
它检查什么
门禁以浏览器的方式读结果——渲染之后、真实宽度下:
- 对比度 ——文本相对背景必须达到亮度下限
- 最小字号 ——不允许任何文本低于 kit 的尺寸下限
- 点击目标 ——交互控件尺寸必须可点
- 活导航 ——每个导航项必须真正去到某处,在开关最常断头的手机 和平板宽度下检查
- 死区 ——布局吞掉交互的区域
检查横跨五个宽度——桌面、笔记本、平板和两种手机宽度——所以 只在 agent 碰巧写的那个尺寸下正常的设计会被抓住,而不是被交付。
PASS
Gate passed 表示结果过了 kit——归你保留、继续 steer,或交付。 transcript 列出这一轮碰过的文件,让你一眼看清这次改动的波及范围。
FAIL ——以及修复循环
FAIL 把每条挂掉的规则列为一个发现——检查 id、挂掉的宽度、以及 那个元素。发现上的 "Fix at this width" 把恰好那个问题作为一行 修复 brief 发回 agent;FAIL 不是死胡同,它是已经替你写好的下一轮。 自动修复循环会先自己重试一次,才把发现交到你手里。
它不检查什么
门禁执行的是规则,不是品味——通过的结果仍然可能不是这份 brief 想要的设计,这正是 steering、评审模式和你自己的眼睛存在的意义。 而且它只检查 kit 知道的东西:规则之外的新颖交互或不寻常结构默认 放行,不给判定。
它在哪里运行
门禁在每个标准项目轮次结束时运行。codebase 项目不一样:被采纳的 仓库对你自己的 dev server 上本轮改动的文件跑 diff 范围的检查——见 Build mode。Free 和 Pro 跑同一个门禁; 它不在许可证计量的范围里。
Tip: 当某个 FAIL 发现看起来是刻意设计(故意的强调色例外、已知 的权衡),你不一定要修它——用评论或 Tweak 绕过它 steer,或者接受 这个发现继续前进。门禁提建议;你拿主意。