新猎手上岗：dead_code 与 det_pattern 门禁接线记

新猎手上岗：dead_code 与 det_pattern 门禁接线记

死代码在一个"禁止撒谎"的系统里是什么罪

大多数项目对死代码的态度是：留着吧，万一以后用得上。编译器的 dead_code 警告看多了就麻了——#[allow(dead_code)] 一贴，世界清净。

灵逍不能这么办。一个以"输出可复算"为立身之本的系统里，死代码不是"暂时没用的代码"，它是未兑现的承诺——写着签名、没写兑现的函数，本质上和 unimplemented!() 是同一类东西：模拟冒充。所以宪法第 9 条的枪口对准它，而今天，两个新门禁族正式接线上岗：dead_code（死代码封存）与 det_pattern（确定性反模式）。

一、接线实录：从 dispatch 到实跑

新门禁上岗的第一证据在管道分发器里（main.rs 原文）：

"dead_code" => gate_dead_code(&root), "det_pattern" => gate_det_pattern(&root),

两条新命令挂进 metrics_collector 的门禁分发，与 w5d/f40/k9 等老猎手并列。实跑记录：两条命令均通过 P0 熔断检测先行（第 386-7 条"AI 执行规范熔断法则"——第 386 条系下的子条款，XF58.2.0 立宪：有未清偿新建文件时拒绝一切后续）——新门禁上岗第一天，先学的就是守规矩。

接线是有一套标准流程的：dispatch 挂命令 → P0 先行检测 → 族内判定逻辑执行 → 输出与 exit 码 → 账本留痕。两条新猎手走完了全程——这与第 7 篇的判例规则化闭环完全一致：新族上岗本身就是一次判例规则的接线示范。

二、dead_code 门禁：不是删除，是"死刑复核"

这个族最有意思的设计是双仲裁——死代码的两种结局，各有一个仲裁函数：

• dead_code_seal_arbit（封存仲裁）：判定一段死代码是否值得保留。通过仲裁的进入"封存态"——封存的代码从活跃调用图剥离，但保留在文件里，等待未来的激活（呼应万文件锁的"容量预留位"哲学：文件位不删，功能待命）；
• dead_code_revive_arbit（复活仲裁）：封存的代码要重新启用？不能直接改回来——必须由复活仲裁判定"激活理由+依赖完整性+当前宪法合规性"三要素，通过才能解除封存。

仲裁的输入是三本账（实拍函数签名：dead_code_revive_arbit(scanned, dead, baseline) -> Result<String, String>）：

返回值是裁决文书不是布尔——仲裁要有说法：通过/驳回/附条件，全部落盘。而且两个仲裁的三参语义并不对称（实拍签名与裁决原文）：

复活仲裁 dead_code_revive_arbit(scanned, dead, baseline)：

裁决原文两分支：孤儿复活·ARMED红牌: 裸 dead_code {dead} ≠ 0（第9条）→ exit 2 熔断；孤儿复活·armed双口径通过（裸0·封条{baseline}在册）→ 放行。

封存仲裁 dead_code_seal_arbit(total, ann, red)：total=allow(dead_code) 总计、ann=有据封条数、red=无据黄灯数。裁决原文：封条清点·armed黄灯: 总计{total}·有据{ann}·无据{red}（清偿中·第453条）。

注意最后一处：黄灯走 Ok 不走 Err。两个仲裁都返回 Result<String, String>，但 Err 的语义刻意不同：复活仲裁的 Err = 熔断信号（阻断管道，exit 2）；封存仲裁的黄灯包在 Ok 里返回（留痕放行，Err 分支形同虚设）——双口径不只是文档口径，它写死在返回值的类型语义里：红牌必须 Err（阻断），黄灯永远 Ok（放行）。

一段死代码的封存之旅（完整流程）

一次复活申请的流程（反向走一遍）

封存代码要激活？不能直接改——revive 仲裁先审三要素：激活理由（为什么现在要用）、依赖完整性（它依赖的东西还健在吗）、宪法合规性（按当前版本宪法它还合格吗）。三要素通过→解除封存→黄灯-1→进 CI 全量回归→回归通过才算真复活。复活比死亡手续多——这是故意的：进入系统的东西要严审，回来的一样要。

三、族 13（dead_code 族的注册族号）的"双口径"设计：一个门禁，两把尺子

两个新族在接线时遇到了一个真实的立法问题：dead_code 的判定口径在"第 9 条裸 0 硬闸"（零容忍）与"第 453 条封条清点黄灯"（清偿过渡期警告）之间必须二选一吗？

答案是不选——族 13 双口径门禁（族号是门禁族注册表里的序号，族 13 即 dead_code 族、族 14 为缺口补建族；接线记录原文：“族13双口径门禁已迁居 bin: metrics_collector gate dead_code”）：

一条管道，两种严重度——这不是妥协，是把"理想态"与"过渡态"都纳入法治：硬闸保证新的死代码零增量，黄灯保证存量清偿有账可查而不把管道打成永久红。清偿完成，黄灯自然转绿。

判定走一棵决策树（注意：revive 不是"检出死代码"时的并列选项——它只适用于已封存代码的复活申请，是封存之后的另一条流程）：

检出死代码
└─ 带 seal 仲裁标记？
├─ 是 → 黄灯计数（封存态，不阻断）
└─ 否 → 硬闸熔断（裸死代码，零容忍）

（另一条流程：已封存代码申请复活）
revive 仲裁审三要素 → 通过 → 回归通道（全量测试通过才解除封存）

双口径还有两个容易被忽略的执行细节。其一："有据"的判定标准是封条必须挂条款号。门禁逐行扫描 allow(dead_code) 标注，注释里必须出现"宪法占位/保留理由/宪据"或具体条款号（第 9/50/83/282/453/459/385 条系等）才算有据——光贴一句 allow 而不声明依据，照样进黄灯账。第 5 篇的第 022 号修正案（未声明依据的指令无效）在封条层再一次被执行：连"容许死代码存在"这个动作本身，都要声明依据。

其二：gate_dead_code 会把封条计数独立复算第二遍（main.rs 原文注释：“第385-2条十边·反生回读（第一类往复身·十边=G5+R5）: 封条计数独立第二遍复算·断言两次一致”）。两遍一致→打印"反生回读环通"；不一致→"反生回读断边"。同一个数算两遍、必须相等——这不是性能浪费，是第 8 篇六维确定性（状态可复算）在门禁自己代码里的自我实践：一个管确定性的系统，自己的门禁先过确定性这一关。

四、det_pattern 门禁：确定性反模式的第一批通缉令

第 8 篇的六维矩阵里，确定性五维标着"缺失"。但"缺失"不等于"不设防"——det_pattern 门禁就是已完成部分的执法者：对已立法的确定性反模式自动检测。

第 1 号通缉令来自宪法第 376 条原文：Instant::now() 类调用——在确定性语境下，"当前时间"是外部输入（维度③），直接读取时钟会把不可复现性注入执行过程。

后续通缉令的排期对应六维的补齐路线（每条随对应维度的技术落地而生效）：

第 1 号（Instant::now()）与第 2 号（SystemTime::now()）同批生效——实跑输出一行四个数（原文格式）：确定性反模式·扫描{s}个rs·Instant{instant}·SystemTime{sys}·合法豁免{legal}，违例数 = Instant + SystemTime − 合法豁免，四元组落盘 确定性反模式违例清单_armed.json。时钟不是一律有罪：心跳计时、限流补充、超时控制这类文件，直读时钟本身就是职责——门禁按文件承载的职责把其中的时钟调用记入"合法豁免"，违例账只记豁免之外的裸时钟调用。

这类模式一经检出，与 W5D 红牌同等待遇：立案、清偿、入账。六维矩阵的"缺失"，指的是能力尚未建成；反模式门禁证明的是"建一点，守一点"——能力建设与纪律执法同步推进，缺失才不会越欠越多。

五、与编译器 dead_code 警告的三点区别

编译器是体温计，门禁是体检中心——两者不冲突，后者包含前者并加立法。

六、诚实边界

七、可证伪

三步：①metrics_collector gate dead_code / gate det_pattern——命令存在且可跑（P0 检测先行）；②在任一模块放一个未使用的函数→裸死代码（不带 allow）→观察封存仲裁触发；③在非时钟职责文件放一个 Instant::now()→gate det_pattern 违例计数应 +1、黄灯清单落盘。门禁不咬人，回来骂我。

快问快答

Q1：为什么不直接用编译器的 dead_code 警告？
见第五节对照表——编译器管单 crate 的当前调用图，门禁管全仓生命周期的死活，且带仲裁与账本。体温计与体检中心的区别。

Q2：det_pattern 和 clippy 的 lint 有区别吗？
第 7 篇说过 armed 与 Linter 的区别：强制力与闭环。clippy 报警可忽略，det_pattern 检出的违例=CI 熔断+清偿义务+判例入档——而且它的判据直接挂宪法第 376 条，确定性反模式是"违宪"不是"风格问题"。

Q3：封存仲裁会不会变成"垃圾场合法化"？
不会——封存占容量、黄灯计数、清偿压力三重账都在：封存区堆积本身会成为下一轮门禁的输入。垃圾场有容量表，且表是公开的。

Q4：双口径会不会让人钻空子（故意把死代码标成"已封存"逃硬闸）？
封存本身要走 seal 仲裁（读三本账：scanned/dead/baseline，判定"是否值得预留"）；封存代码将来要复活，还得过 revive 仲裁（审激活理由+依赖完整性+宪法合规性三要素）——双重仲裁、两道手续。且封存区计入黄灯账、占行数锁容量、受清偿压力监控——钻空子的成本是把自己的代码推进一个被持续观察的候审区。逃得了硬闸，逃不了黄灯。

Q5：封存的代码会腐烂吗？
会——封存态脱离活跃调用图，没人给它跑测试、没人喂新需求，这就是"复活仲裁要查依赖完整性与合规性"的原因：复活比死亡手续多，就是为了拦住"腐烂的先例"混回系统。同时封存区受黄灯与容量双重压力——腐烂速度被制度性地限制住了。

下一篇

门禁在生长，宪法在接线，下一篇进入系列预告已久的基础设施层：《十二正经经脉网络：金行验证的容错路由》——验证者掉线了怎么办？图搜索给出替代路径。

系列目录（持续更新中）

（本文为《宪法即代码》系列第 10 篇，数据口径：宪法版本 XF58.15.0、接线实录 2026-09-12）