ADR-0076 D11 的落点没有 adr-anchors 锚点：dispatcher 拆解后的 runtime/src/domains/* 与 domain-handler-registry.ts 未被在场门守住 #5357

从 #5063 拆出来的第二步（该 issue 正文明说「可选的第二步…issue 明说可分开」），在 PR #5356 里刻意没有并入，理由见下。

观察

ADR-0076 在 scripts/adr-anchors.json 中没有任何条目（grep -n "0076" scripts/adr-anchors.json 零命中，当前 26 条锚点均属其他 ADR），但 D11 的产物是一整片实打实的代码：

• packages/runtime/src/domains/（14 个域模块）
• packages/runtime/src/domain-handler-registry.ts —— DomainHandlerRegistry，D11「thin dispatcher registry」的本体
• packages/runtime/src/http-dispatcher.ts —— 收缩后的 gates 管线

check-adr-anchors.mjs 存在的理由正是 framework#3723 那类事故：被治理的文件自己不提它所遵从的决定，作者就无从知晓。D11 的形状恰好是"一个读者单看文件会觉得可以'优化'掉"的那种 —— 例如把某个域体搬回 dispatcher、或给某个域直接注册框架特定路由，都会静默逆转 D11，而目前没有门会红。

为什么今天不算缺陷

这是 observation-class，不是用户能踩到的 bug：部分落点的文件头已经写了 ADR-0076（如 packages/runtime/src/domains/actions.ts 开头即 "extracted dispatcher body (ADR-0076 D11 step ③, PR-9)"），route-ledger / http-conformance 等测试也在守着行为面。缺的只是"在场门"这一层保险。

为什么单独做

check-adr-anchors.mjs 自己的文档写着：

Do not anchor everything; a map of everything is a map of nothing, and each entry must earn its failure mode.

所以在 14 个 domain 模块 + registry + dispatcher 里挑出哪几个该锚、每条锚的失败信息该携带什么不变量，是一次独立的判断，需要自己的核实过程 —— 混进一个纯状态行校准的文档 PR 里既撑大 diff 又稀释审阅。

建议

1. 选出真正"看起来可以被合理地改错"的少数落点（倾向：domain-handler-registry.ts + http-dispatcher.ts 的 gates 段 + 一两个代表性域模块，而非全部 14 个）
2. 为每条锚写出携带不变量而非仅 ADR id 的失败文案
3. 确认这些文件确实提及 ADR-0076（不足则补注释），再跑 pnpm check:adr-anchors

顺带记录，同一轮核对中发现 D11 只落了一半：dispatcher 已拆到约 1.7k 行，但同一决定点名的第二个中心路由生成器 packages/rest/src/rest-server.ts 现在是 7693 行 —— 比 ADR 记录的约 5.1k 更大。那属于实现工作，不属于本条锚点问题，未在此展开。

参考：#5063、PR #5356（状态行逐条校准，其中记录了 D1–D12 的完整证据）。

Generated by Claude Code