四个闭合
四个闭合不只是 closeout schema 的字段，更是一种思考方式。当 AI 输出感觉哪里不对、却又找不到具体哪一关没过时，就用它们来定位。
一个 wave 必须四个维度全部显式才算闭合。四过三还是没闭。
四个维度
| 维度 | 它要回答的问题 |
|---|---|
| 权威 | 这个表面的真相住在哪里？内部是不是一致的？ |
| 语义 | 合同的必填字段、失败模式、复杂场景是不是都已经显式？ |
| 消费方 | 消费这个接缝的系统或读者，用得对吗？ |
| 抗漂移 | 下一个实现者会不会很容易把设计退回旧形态？ |
权威闭合
这个表面的真相住在哪里？内部是不是一致的？
权威闭合要追问的是：这次改动之后，规范化的拥有者还是恰好一个吗？任何并行真相面（影子缓存、App 局部便利状态、双读路径），是已经被消除掉，还是在哪里被显式准入？
| 闭合的样子 | 没闭合的样子 |
|---|---|
| 规范化拥有者唯一 | 两个表面同时声称权威 |
| 没有并行真相残留 | 一份非正式缓存悄悄变成了规范化 |
| 准入过的修改是显式的 | 出现过 owner-cut 的悄悄重开 |
典型的权威失败：AI 加了一个 helper，事实上把另一个包拥有的行为重新实现了一遍，造出影子真相。
语义闭合
合同的必填字段、失败模式、复杂场景是不是都已经显式？
语义闭合要追问的是：两个不同实现者实现这份合同，会不会得到等价的行为？MIME type、错误原因、重试策略、边缘场景行为是被指定下来了，还是「留给实现自行决定」？
| 闭合的样子 | 没闭合的样子 |
|---|---|
| 必填字段被指定 | 必填字段被省略 |
| 失败模式被钉死 | 只有 happy path |
| 复杂场景没被静默 defer 为假设 | 「边缘场景」被悄悄 park |
典型的语义失败：只走 happy path —— AI 把成功的样子实现了，失败处理留作隐式。
消费方闭合
消费这个接缝的系统或读者，用得对吗？捷径会不会悄悄变成主线？
消费方闭合要追问的是：真正使用它的消费方（App、文档读者、运维），把这次工作体验为「问题被解决了」吗？还是合同那边干净落地，消费方那边依然坏着？
| 闭合的样子 | 没闭合的样子 |
|---|---|
| 普通消费方走的是正确的接缝 | 消费方还在走旧接缝 |
| 捷径不会悄悄变成主线 | 「临时」捷径悄悄变成实际通路 |
典型的消费方失败：build-pass / consumer-fail。本次文档 remediation topic 的前身就是教科书式案例：机器侧每一关都过了，可读者拒绝了文档，理由是「这是审计工件味儿的散文」。
抗漂移闭合
下一个实现者会不会很容易把设计退回旧形态？
抗漂移闭合要追问的是：禁用捷径有没有被点名？reopen 条件是不是显式的？防止退化的边界，是结构性强制的，还是只靠社交约定？
| 闭合的样子 | 没闭合的样子 |
|---|---|
| 禁用捷径显式列出 | 捷径没被点名，将来又能被翻出来 |
| 后来者很难悄悄削薄设计 | 没显式准入也能继续削薄 |
典型的抗漂移失败：closeout 今天看着没问题，但留不下任何机制阻止同一个捷径在下个季度（上下文丢了之后）卷土重来。
为什么四维都得独立成立
四过三是 AI 工作里最常见的伪闭合形态。「过三差一」的每一种组合都对应一类可识别的病：
| 权威 | 语义 | 消费方 | 抗漂移 | 结果 |
|---|---|---|---|---|
| ✓ | ✓ | ✓ | ✗ | 今天能用，半年后烂掉 |
| ✓ | ✓ | ✗ | ✓ | 技术上对，但没法用 |
| ✓ | ✗ | ✓ | ✓ | 体验不错，合同没指定清楚 |
| ✗ | ✓ | ✓ | ✓ | 并行权威被藏起来了 |
方法论要求四维都显式。closeout 缺哪一维都属于 schema 违反，不是软提示。
阅读场景：用四个闭合判一个 wave
你是 manager，要判一个 wave 的 closeout。worker 说工作做完了。你按四个闭合来走：
- 权威。 规范化真相还在
.nimi/spec/**吗？没有创出影子路径吧？所有权清晰吗？ - 语义。 kernel 规则是不是仍然把必填字段、失败模式、schema 都钉住了？复杂场景是不是显式？
- 消费方。 真正的 App / 文档读者 / 运维，把这次工作体验为问题被解决了吗？把渲染出来的站点跑一下、把散文读一遍、把 API 试一下。
- 抗漂移。 禁用捷径目录最新吗？reopen 条件点名了吗？将来一次仓促的改动会不会重新引入错误模式？
三过、消费方没过。这个 wave 没闭合。要么打回修改，要么准入一个补 consumer gap 的后续 wave。
阅读场景：真实的「过三差一」
上一次的公开文档 remediation 在机器审计层闭合了：权威闭合（spec 没漂）、语义闭合（声明跟 spec 对得上）、抗漂移闭合（forbidden-claim 姿态保住了）。消费方没过 —— 用户拒绝渲染出的文档，理由是「审计工件」。
方法论的回应：把 topic 留在 pending（不要标 closed），准入一个补 consumer gap 的后续 wave，不要回头去改已闭 wave 的记录。
这就是四闭合框架存在的原因。如果没有它，「build 过了」就会被当成完成。