test682 是一道过时的门:它断言的东西被 #698 有意删掉了(连带一个零调用方模块)

[vansin]

现象

tests/test682-uncovered-task-trace 是一道形状完整的 Docker 门,但从没被注册进
L1_TESTS,所以一直没人跑。跑起来是红的:

wiring.test.ts:9
  expect(cli.match(/sendPeerReplyTaskWithTrace\(/g)?.length).toBe(1);
  Expected: 1   Received: undefined

它不是烂了,是过时了

#698 有意把 peer reply 改成协商 send_peer_reply 原子工具,send_task 那条老路
被删掉。而且这个新形状是被另一道门锁住的 —— agent-node/src/reply-routing-source.test.ts:

describe("#698 peer reply runtime wiring", () => {
  test("peer replies negotiate the atomic tool and retain only a terminal legacy fallback", () => {
    expect(source).toContain('sendAtomic: (args) => callCommHub("send_peer_reply", {');
    expect(source).toContain('sendLegacyReply: (args) => callCommHub("send_reply", {');
    expect(source).not.toContain("sendPeerReplyTaskWithTrace({");   // ← 断言它不得出现
    expect(source).not.toContain("REPLY_VIA_SEND_TASK");
  });

两道门方向完全相反:test682 要求恰好出现 1 次,reply-routing-source 要求一次都不许有。
后者在 agent-node/src 下,现在由 test725 覆盖、在 CI 里跑着、是绿的。

所以当前 main 的行为是对的,过时的是 test682。

连带:一个零调用方的模块

agent-node/src/peer-reply-task-trace.ts 现在没有任何生产调用方:

$ git grep -l 'peer-reply-task-trace' origin/main | grep -v '\.test\.ts$\|^tests/'
<空>

它只被 test682 自己的四个文件引用(run.sh / semantics.test.ts / true-hub.ts /
wiring.test.ts)。也就是说,这个模块是被一道过时的门吊着命的死代码。

为什么值得单独提

这是孤儿门的第二种危害,和「测试烂掉没人知道」不同:

一道没人跑的门,会悄悄开始断言与当前设计相反的东西。

如果有人只看到「test682 没在 CI 里」就把它注册进去,main 会当场被它拦住,
而被拦的恰恰是正确的代码。我在 #803 里注册了另外三个孤儿门,唯独跳过它,
原因就是这个。

建议(不在 #803 里动手,等定夺)

1. 退役 tests/test682-uncovered-task-trace,或者只保留其中仍然成立的部分;
2. 确认 agent-node/src/peer-reply-task-trace.ts 确实该删 —— 它是 #167 的产物,
   删之前值得让当初的 owner 确认一句,而不是我按「grep 不到调用方」就动手。

范围:origin/main,证据全部可复验。

[vansin]

Independent current-main triage confirms the core conflict, with one scope correction.

Confirmed on main 034f0064:

• agent-node/src/peer-reply-task-trace.ts has zero production import/call sites;
• the only positive references are inside tests/test682-uncovered-task-trace;
• active agent-node/src/reply-routing-source.test.ts explicitly requires sendPeerReplyTaskWithTrace({ to be absent, matching fix: codex app-server peer replies create new tasks without terminalizing originals #698’s atomic send_peer_reply + terminal send_reply fallback design;
• test682’s wiring assertion requiring exactly one call is therefore obsolete and directionally wrong.

Do not delete the entire test682 directory blindly. The same suite also exercises still-live agent-network/src/client-task-trace.ts and shared agent-network/src/task-trace.ts invariants (transport, lifecycle label, throw preservation, missing task id, queued/delivered semantics). Wholesale deletion would reduce unrelated client tracing coverage.

Recommended narrow fix denominator:

1. delete the orphan agent-node/src/peer-reply-task-trace.ts only after an exact full-tree reference guard;
2. remove peer-only wiring/semantics/true-Hub legs and peer-only mutations from test682;
3. retain and rename/document the client/shared tracing half, with its existing witnessed-red mutations;
4. run agent-node build, agent-network typecheck/build, the narrowed Docker suite, and the active fix: codex app-server peer replies create new tasks without terminalizing originals #698 reply-routing/atomic peer-reply gates.

No code deletion or production action performed in this triage.

[vansin]

补一条:同源的第二个死模块

顺着这条线扫了 agent-node/src + agent-network/src 下 228 个非测试模块,
找「只被测试引用、没有任何生产调用方」的。精确核完剩两个,都出自 #698 废掉的同一个设计:

模块	生产 importer	说明
agent-node/src/peer-reply-task-trace.ts	0	只被 test682 的 semantics.test.ts / true-hub.ts import
agent-node/src/runtime/reply-routing.ts	0	只被它自己的 reply-routing.test.ts import

第二个更值得说,因为它带着一份绿的单测:

$ git grep -nE "export \*.*reply-routing|from ['\"]\./reply-routing" origin/main
agent-node/src/runtime/reply-routing.test.ts:6:} from "./reply-routing";     ← 唯一命中

导出符号在生产源码里的引用数(排除自身、测试、tests/):

createReplyRouteCache → 0
resolveReplyRoute     → 0
ReplyRoute            → 0

而它导出的类型是:

export type ReplyRoute = "send_reply" | "send_task";

这正是 #698 废掉的那个「用 send_task 回复」的概念 —— 和
peer-reply-task-trace.ts 同源。cli.ts 现在走的是
import { routePeerReplySse, runInboxTurnByReplyPolicy } from "./peer-reply-inbox"。

所以这里有两种不同的「看起来还活着」:

• peer-reply-task-trace.ts 被一道没人跑的过时门吊着;
• reply-routing.ts 被一份跑着且是绿的单测吊着 —— 更隐蔽,因为绿色本身
  就是「这东西还在用」的错觉来源。单测只证明模块自洽,不证明有人调用它。

一条自我更正

同一次扫描还报了 agent-node/src/runtime/grok-copresence/profile-process-probe.ts
「零 import」。那是假阳性,它不是死代码 —— 它是被
spawnSync(process.execPath, [join(import.meta.dir, "profile-process-probe.ts")])
当子进程拉起的 fixture,本来就不该有 import 语句。写在这里免得后来者照着删。

建议不变

删之前让 #167 / #698 的 owner 确认一句。我只给证据,不动手。