门禁体系：边界由机器判

「内核不许长出领域知识」「文档数字不许漂」这类纪律，写在散文里就会烂掉。 本仓的做法是：凡是能机械判定的，一律做成门禁，全部挂在 make check 上， CI 只执行这一条命令——门禁若只挂在工作流里，本地要到推送之后才知道违规， 那是「推送后门禁」而不是「提交前门禁」。

make check                # 全量门禁（提交前必须绿）
make architecture-check   # 单跑架构门禁；--report 看全量
make docsync              # README ↔ 仓库事实一致

make check 全链

两类判定：正则规则与结构判定

rules 段的正则规则（清单见包清单与机器事实，机器生成）管写法类红线：域词污染、测试夹具领域词面、 宿主依赖、宿主运行时、裸 goroutine、printf 回调、双 errors 包、沙箱执行单入口。 完整清单见包清单与机器事实（机器生成）。

go/ast 结构判定（清单见ADR-0001 · 领域知识红线）管形状类红线：

为什么结构判定必须走语法树：import 声明有六种以上书写形态（单行/块/别名/空白导入/ 点导入/括号同行），逐行正则必然漏，且漏得毫无声响。

门禁的失败形态必须是变红

这是全套纪律里最核心的一条：规则的失败形态若是变绿，规则就等于不存在。

• 改任何判定逻辑，必须同时给**「坏实现会红」**的用例——只测「好实现能过」的用例， 一个把数字比较写成字符串比较的错实现照样全过；
• 反向验证不是仪式：每条规则都做过「注入违规 → 报错 + 退出码 1」的实测；
• 门禁自己也要能被检查：测试文件被整体跳过、import 规则漏形态、例外到期不失效、 规则可无执行体——这些「静默失效」都实测发生过，修法都配了反向用例；
• 例外登记必须写 until 与拆除条件，到期即失效——失效的豁免会被门禁点名 要求当天拆除，而不是永远留着变成装饰（当前例外数：0）。

数字纪律：docsync 的两种口径

派生计数（包数、规则数、门包数）不抄进多处散文——抄进几处就有几份不一致。 每个数字要么被机器判，要么在旁边写明「不受机器管，改前请手算」。没有第三条路。

提交纪律

• 提交前必须绿。门禁红了先判断是「代码错了」还是「规则该改」； 后者必须先改 policy 再写代码，并在提交说明里写清理由；
• 新增包必须登记 architecture-policy.yaml 的 modules 段 （漏登记的包对依赖方向门禁完全隐形），新增内部依赖同理——先改 policy 再写代码；
• 覆盖率阈值是真阈值：全局 + 逐包两条判据，逐包豁免必须写原因且失效即红。

规则源：architecture-policy.yaml（声明面）。执行体：archcheck 包 （宿主可直接导入复用同一份判据——判据各写一套必然漂移）。