[finding] ADR-0076 D11 的第二半从未落地:`packages/rest/src/rest-server.ts` 已 8593 行(ADR 记录约 5.1k),且无 issue 承接

[os-zhuang]

observation-class:今天没有用户会踩到,纯结构性欠账 + 记录承接问题。由 #5357(D11 锚点入账,PR #5940)派生登记 —— 该 issue 随 PR 关闭后,这条观察的唯一书面记录就没了。

事实

ADR-0076 D11 点名了两个中心路由生成器要拆:

1. packages/runtime/src/http-dispatcher.ts(ADR 记录约 3.8k 行)—— 已拆:14 个域体迁至 packages/runtime/src/domains/*,路由走 DomainHandlerRegistry,dispatcher 收缩到约 1.9k 行,多适配器由 packages/qa/http-conformance 验证。
2. packages/rest/src/rest-server.ts(ADR 记录约 5.1k 行)—— 未动,而且在长大:

时点	行数	出处
ADR-0076 rev.9 记录	约 5100	docs/adr/0076-objectql-core-tiering.md D11 决定正文
2026-08-05	7693	#5357 正文顺带记录
2026-08-06(本次实测,origin/main a6b3ee7)	8593	wc -l packages/rest/src/rest-server.ts

即一天内 +900 行。ADR 的状态行本身已如实记录这一半(「D11 — substantially implemented; the rest-server half is untouched. … is now ~7.7k LOC, i.e. larger than the ~5.1k figure below, not smaller」),所以决定与现状之间没有隐瞒 —— 缺的是承接:实测当前 open issue 里没有任何一条跟踪这半边(按 open issue 全量扫描 title/body 关键字 rest-server,仅 #5936 命中且是另一件事:/discovery 第二生产者的 environment 广播)。

为什么单独登记而不是并进锚点 PR

#5357 的分诊评论明令「正文末段顺带记的 rest-server.ts 7693 行问题不属本单验收,勿顺手带」,PR #5940 因此严格只做锚点 + 注释。但 #5357 关闭时这条观察会随之消失,所以按 Prime Directive #10 单独落一条不指派的 finding。

建议(留给分诊,不在此裁决)

拆解本身是实现工作,而且是 ADR 明说的 "Incremental(both mechanisms already coexist — migrate one domain at a time)" —— 与 dispatcher 那半走过的路径相同(注册表先行,再一域一 PR 搬运)。可选处置:

• A 按 dispatcher 的同一套路径排一条增量拆解线(先接缝、再逐域),晋级为可派工作项;
• B 判定 rest-server 的中心生成形状是刻意的(它与 dispatcher 按域分区、不重复;OQ#9 的结论是「delineate, do not merge」),则应在 ADR-0076 D11 上写一条修订说明「第二半不拆」的理由,让状态行从"未落地"变成"已裁决",这条欠账才算真正关掉;
• C 什么都不做,但至少让本 issue 承接住记录,避免下一轮 ADR 校准时再重新发现一次。

倾向 B 优先于 A:D11 对 rest-server 的判断写在 2026-06-28,而 #2462 的审计结论(OQ#9)已经把两者定为按域分区而非重复,所以"拆不拆"更像是一个待复核的决定,而不是一件待做的工。这需要维护者裁决,不是开发能自行选的。

参考:#5357、PR #5940、#5063(D1–D12 状态行逐条校准)、ADR-0076 D11 / OQ#9。

[claude]

发现分诊轮:持有(留 finding),补域 domain:cli。

• 过时前提检查:实测 origin/main 的 packages/rest/src/rest-server.ts 仍在增长(ADR 记 ~5.1k → 08-05 7693 → 08-06 8593);ADR-0076 的状态行本身已如实写明 rest-server 半边未动 ⇒ 缺的是承接,不是准确性。前提成立。
• 为什么持有:8.6k 行中心路由生成器的拆分是多周程序,pm:queue 里没有一个车道能按现状认领;而 D11 的第一半(http-dispatcher → domains/* + DomainHandlerRegistry)已有可照搬的落地形状,所以这不是「要不要做」而是「什么时候排」—— 属 appetite 与排期,归维护者。
• 重启条件:①维护者给出 appetite(届时由分诊座位转 needs-user-decision 立程序卡,再按 contract-first 拆子单),或②rest-server 因体量再次直接造成事故/评审阻塞 —— 两者任一发生即晋级。
• 域:domain:cli(packages/rest 在该行范围内)。本单的价值就是书面承接:ADR-0076 D11 的落点没有 adr-anchors 锚点：dispatcher 拆解后的 runtime/src/domains/* 与 domain-handler-registry.ts 未被在场门守住 #5357 随 PR docs(runtime): ADR-0076 D11 四条在场锚点入账 —— registry + dispatcher 门序 + 两个代表域 (#5357) #5940 关闭后,这条观察不再有别的落脚点,⛔ 不要因为它「不可派发」而关掉。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code