Tcuzzo Understanding Gates
Effort: light — 每个阶段跑一轮验证器，对照最初的请求打分，每次修复后重跑。消除：对照转述被验证通过的漂移——绿着落地、回答的却是没人问过的问题的构建。
一套面向构建的验证纪律。它在五个阶段审问工作——Design、Plan、Build、Test、Ship——永远对照最初的请求，绝不对照工作对请求的转述。每道关返回证据：分数、一个裁决、具名的失败、修复动作。它约束 agent，不约束人：不加新的审批步骤，不给提需求的人添摩擦。
什么时候跑
- 任何会落到真实地方的构建、修复或升级。
- 任何你正要说"做完了"、而唯一凭据是一个绿色测试的时刻。
- 每次修复之后，在失败的同一阶段上。
第 0 阶段 — 锚定意图
打分之前，先钉死比较的锚点：人的原话，加上一行翻译过的指令（见 intent-compiler）。每道关都对着这个锚点打分。绝不对着你自己的转述打分——转述会漂移，然后每道关就都在悄悄验证漂移，而不是验证请求。
五道关
每道关对照原始意图问一个问题：
| 阶段 | 问题 |
|---|---|
| Design | spec 清晰，并且忠于最初的请求吗？ |
| Plan | 计划回应了意图，并且适配它要发布到的界面吗？ |
| Build | 代码满足 spec，没有漂移吗？ |
| Test | 测试锻炼的是真实行为，不是替身吗？ |
| Ship | 它能干净地应用、失败会大声，而且交付声明经得起事实核查吗？ |
每道关都用同样五个镜头打分，每个 0–4：spec 契合、架构契合、类型安全、可测性、安全性——按阶段措辞（在 Design，"可测性"问的是 spec 可不可检验；在 Ship，问的是交付声明可不可检验）。汇总：五个镜头求和（0–20），乘以 5——就是该关 0–100 的裁决分。记录每个镜头的分，不只记总分——总分会藏住是哪个镜头失败了。
裁决
把镜头分滚成 0–100，分档：
- Approve（80+）：证据充分。仍然不是"做完"的证明——见第二条法则。
- Revise（60–79）：存在具名失败。每一条都是修复目标。
- Reject（低于 60）：工作偏离了意图。退回上一阶段。
背后没有具名失败的裁决是低信息量裁决。要清单。
修复纪律
- 每次重跑都以最初的意图为锚。
- 记录每个镜头的分，不只记最上面那个数。
- 每条具名失败都当成修复目标。没有一条失败是装饰。
- 修复后，重跑同一道关。没有重跑的修复只是一个声明。
- 绝不把信心升格为就绪。由测试和真实界面说了算。
两条法则
1. 回声法则。 一个只会同意的检查是回声，不是验证器。诚实的证明是反驳：喂给它一条你明知为假的声明，看它把那条判掉。假话都能过，这个检查就是演戏。关于 mock 的推论：只 mock 不稳定的外部叶子——付费 API、抽风的网络。绝不 mock 行为本身就是证明的那个器官；它的打分、声明抽取和判定逻辑必须真跑。
2. 必要，不充分。 通过的测试是必要的，永远不充分。"做完"的意思是：人真正使用的那个真实界面，自己把活干了。点名那个界面，触发真实路径，看着正确结果到达。绝不把一张单元测试的回执升格成实况能力声明。
硬性规则（什么会让这个技能失败）
- 对着转述打分，而不是对着最初的请求。
- 一个 revise 或 reject 裁决背后没附任何具名失败。
- 修复了却没重跑失败的那道关。
- mock 了验证器本身，或 mock 了正在改动的那条接缝。
- 凭一个绿色测试、没有真实界面证明就宣称做完。
保留构建记录
每个阶段留下：意图、确切的输入产物、分数、具名失败、执行的修复、重跑结果、真实界面的证据。指不到可复现证据的记录是横幅，不是记录。
搭配使用
- intent-compiler — 打分之前先翻译请求。
- red-first — Test 关的契约：先 commit 失败测试。
- sniper-testing — 真实副作用，没有 mock 剧场。
- blind-tribunal — 架在这些关卡之上的独立评分者。
- repair-loop — 把 revise 裁决推到绿的那个循环。