环境门、静态门、编译门，性能门，consumer gate、race gate和full gate分别是什么，你弟弟sol很喜欢这些，请逐一解释

比如让代码 Agent 改一个 Go 写的缓存库，它改完说“完成了”，你不能只信这句话，要检查：环境能不能跑、代码有没有明显问题、能否编译、下游能否正常使用、有没有并发问题、性能有没有退步。这些验收关卡就可以叫 gate：满足条件才允许继续、合并或发布。 不过，这七个名字不是一套统一的行业标准，尤其 consumer gate 和 full gate，具体含义要看项目脚本。我没查到 sol 对它们的专门定义，下面按软件工程里的常见含义逐一解释。 环境门：检查“有没有条件正确执行后续验证”。 比如 Go 版本是否符合要求、依赖能否下载、测试用数据库是否启动、必要的环境变量是否配置。数据库没启动导致测试失败，应报告环境阻塞，不能直接断言代码有 bug；同样也不能当成测试通过。 静态门：不实际运行目标程序，先检查代码本身。 比如格式检查、lint、静态分析，发现未使用的变量、可疑调用、潜在错误等。Go 项目可能检查 gofmt 并运行 go vet./...。类型检查归在这一门还是编译门，要看项目约定。通过它不代表业务逻辑正确。 编译门：检查代码能不能成功构建。 比如执行 go build./...，发现函数参数对不上、符号不存在或依赖不兼容。它回答的是“能不能构建出来”，不是“运行结果对不对”。返回错误结果的程序照样可能编译成功。 性能门：检查性能是否满足目标、有没有明显回退。 比如修改缓存后，在相同机器和负载下比较延迟、吞吐量、内存分配；项目可以规定“延迟回退超过 5% 就阻止合并”。这个百分比只是例子，不是通用标准。性能测试要考虑预热、重复测量和环境噪声，不能凭一次快慢下结论。 consumer gate：通常是“下游使用方验收门”。 比如缓存库自己的测试全过了，但别的服务调用它时编译失败，或者依赖的返回格式变了，这一门就应该拦住。常见做法是构建真实下游项目、运行调用方测试或做消费者驱动契约测试。 这里 consumer 通常指 API、库或服务的使用方，不一定是消息队列消费者；具体仍需看上下文。 race gate：通常是“数据竞争检测门”。 比如两个 goroutine 没有正确同步就读写同一个共享变量，普通测试可能碰巧通过，带竞争检测运行时却会报错。Go 的典型命令是 go test -race./...。 注意：它只能发现本次运行实际触发的数据竞争；通过不代表绝对没有并发 bug，也不能保证没有死锁或业务层面的竞态。 full gate：项目定义的“完整验收入口”。 比如项目提供一个名为 make full-gate 的命令，统一执行静态检查、构建、单元测试、集成测试、下游兼容性验证等。这个命令名只是示例，并非标准命令。 “full”覆盖哪些检查必须看配置：不一定包含耗时的性能测试，也不意味着能证明程序完全正确。 串起来就是：环境门看能不能测，静态门看代码是否符合规则，编译门看能不能构建，性能门看快慢和资源，consumer gate 看别人还能不能用，race gate 看有没有触发数据竞争，full gate 汇总项目规定的完整检查。 接着你之前问的 reward hacking：如果 Agent 为了“过门”删测试、放宽性能阈值、跳过下游验证，就是让分数变好，而不是真把代码修好。所以还要检查验收规则有没有被改，以及到底执行了哪些检查；没执行不能算通过。 参考： https://go.dev/doc/articles/race_detector https://microsoft.github.io/code-with-engineering-playbook/automated-testing/cdc-testing/ 你贴一下 sol 的原话或 gate 脚本，我可以进一步对应它实际检查什么。