correct

Correct

操作者一直在这个仓库里纠正代理犯同样的错。改这个仓库，让下一个代理没法再犯。

假定每个贡献者都是代理。它只看见自己打开的文件，抄最近的例子，走能编译通过的最短路径。把仓库设计成这样：从单个文件看起来对的改动，对整个仓库也是对的。

找出错误类别

先读最近的提交、回退、评审评论、给代理的说明文件，以及解释绕过做法的注释。把错误分成几类。同一类发生过两次，才算一类。

在够用的最高一层修好每一类

1. 用架构消掉它。 每一份状态只留一个所有者，每一项任务只留一种支持的做法。藏住内部，让错误的导入失败。把靠人手同步的多份清单换成唯一的一份。删掉旧做法，以及代理会去抄的死代码。
2. 用类型挡住，让坏状态写不进去。 如果坏代码还能编译通过，就加一条 lint 或 CI 检查，报错里点名该改用的文件、类型或函数。这种写法已经很常见时，只在这次改动又多加一处时才让检查失败。
3. 用测试卡住行为。 某个测试在它检查的行为坏掉时仍然能通过，或者只有内部实现变了它就失败，就修好或删掉这个测试。
4. 最后才写文档或给代理的规则，而且只写需要判断的情况。 代理跳过它们，什么检查都不会失败。

修好，并证明检查会失败

然后现在就修最常见的几类，每类一次提交。每条新检查都要用一次真实犯过的错证明它会失败。同一条命令在本地和 CI 里都跑。例外写在出错的那一行，带上原因、到期日，以及一个人的批准。

留一张规则对照表

最后，在给代理的说明文件里留一张表，把每条规则和卡住它的机制配在一起。操作者纠正你时，修好这个错，并补上规则。规则已经在表里、却没有东西去卡住它，这就是重复发生，所以在同一次改动里，在够用的最高一层修掉。某类错误已经不可能发生时，删掉对应的规则。

回复： 每一类错误、它的证据、你选的那一层，以及为什么更高一层行不通。