test(ci): 给 src/ 补绝对下限 —— 两道门都放行「大量删除测试文件」(#817)

[vansin]

修 #817。

问题

两道聚合单测门都放行「测试文件被大量删除」。#817 的实测:origin/main 上删掉
46 个 agent-network/src/*.test.ts 里的 40 个,test745 仍然

test_files=6  executed_files=6  RESULT: PASS  rc=0

原因是分母和执行数会跟着现实一起缩水。executed >= test_files 能抓的是
「runner 少跑了文件」,抓不到「文件没了」—— 两边同时变成 6,断言照样成立。

test725 更彻底:它连 src 的分母都没有,只有一行 bun test src/。

改动

test745  加 AGENT_NETWORK_SRC_FLOOR=40   （磁盘上现有 46 个）
test725  补 src 分母 + AGENT_NODE_SRC_FLOOR=80（现有 91 个）
         并照 test745 的形状补上 executed >= discovered

下限是**「大量删除」的绊线,不是精确计数**:留了少量余量给正常增删,
真要删测试就得故意改这个数 —— 目的是让「删测试」这件事必须在 diff 里显形,
而不是悄悄让门的范围缩水。

见证红

把插入的块逐字抽出来跑(ROOT 指向构造的目录树):

文件齐 46 / 91         → OK test_files=46 / OK test_files=91
按 #817 删到只剩 6 个   → FAIL: only 6 test file(s) under agent-network/src, floor is 40
                          FAIL: only 6 test file(s) under agent-node/src, floor is 80

🔴 说清楚这次没做什么:上面跑的是抽出来的 floor 块,不是在 Docker 里跑完整的门。
完整门要构建镜像,本机磁盘 93%,我没有在未确认的情况下起构建。
floor 本身是纯 bash 算术 + find | wc -l,抽出来跑和在门里跑是同一段代码;
但「完整门在容器里端到端仍然绿」这一格,要 CI 来填。

和 #800 的关系

不重叠,别混:

	src/	tests/
#800(已开)	—	AGENT_NETWORK_TESTS_FLOOR=15 / AGENT_NODE_TESTS_FLOOR=5
本 PR	AGENT_NETWORK_SRC_FLOOR=40 / AGENT_NODE_SRC_FLOOR=80 + test725 的分母	—

#800 的范围写的是「让两个门覆盖 tests/ 目录」,所以 src/ 的下限单独开在这里。
两个 PR 都改 run.sh,合并时注意先后顺序会有上下文冲突(插入点不同,内容不冲突)。

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ec5f52ef9c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Add the required Docker evidence for both gate changes

I checked the commit's changed-file list and the existing test725/test745 reports: only the two runners changed, while the commit explicitly says the complete Docker gates were not run. That leaves this new Bun-summary parser and both floor checks without the repository-required container E2E verification or updated saved results; run both suite Dockerfiles and commit the resulting docs/tests/report-test725-... and report-test745-... evidence before merging.

AGENTS.md reference: AGENTS.md:L7-L8

Useful? React with 👍 / 👎.

[vansin]

独立深审结论：CLEAN，但必须在 #800 后 rebase（exact head ec5f52ef9cf6d1f68c0f1f6d7ee9a5ef77966996）。

• delta 仅两个 runner（+33），加入 agent-node / agent-network src 绝对下限 80 / 40；当前独立分母为 91 / 46；
• agent-node 同时要求 executed >= discovered；agent-network 保留既有同等断言；
• exact head 的 9 项 Actions 全 SUCCESS；
• 与 test(ci): 让 test725/test745 覆盖 tests/ 目录(两个门自称 complete 却漏了 25 个文件) #800 存在真实 content conflict：test(ci): 让 test725/test745 覆盖 tests/ 目录(两个门自称 complete 却漏了 25 个文件) #800 的 tests/ dispatcher/floor 与 test(ci): 给 src/ 补绝对下限 —— 两道门都放行「大量删除测试文件」(#817) #854 的 src floor/executed 插入同一区域。不能直接依次 merge，也不能随手选一侧。

人工 union 必须同时保留：src 分母+floor+executed/discovered、tests/ dispatcher+tests floor、以及 #800 收紧后的 ^(fail) mutation 命名断言。

NOT COVERED：审查员构造了“各只剩 6 个 src 测试”的 Docker 反证，但共享宿主导出层过慢而中止，未取得最终两条命名 floor 输出；因此不把该动态 witnessed-red 冒充为已独立复现。

未 approve、未 merge、未 deploy。

[vansin]

结论:前提我独立复现了,修法见证真红,建议合并。一条 MINOR(不挡合并,已量化)

这个 PR 之前只有一条 bot 评论。我没看 PR 的自述数字,自己从 origin/main 起真跑了四次。

一、前提属实 —— 我独立复现了"删测试门不响"

origin/main,删掉 46 个 agent-network/src/*.test.ts 里的 40 个,构建并跑 test745 自己的容器:

test_files=6
 36 pass   0 fail
executed_files=6 discovered_files=6
RESULT: PASS                                    退出码 0

和 PR 正文引用的 #817 数字一致。executed >= test_files 抓不到这个,因为两个数一起缩水。

二、修法见证真红

同一个删除操作,合入本 PR 后:

test_files=6
FAIL: only 6 test file(s) under agent-network/src, floor is 40      退出码 1

而未变异时:

test_files=46
 438 pass   0 fail
executed_files=46 discovered_files=46
RESULT: PASS                                    退出码 0

红/绿两侧都见证过,不是只看绿。 计数也核了:agent-network/src 现有 46 个(floor 40,余量 6)、
agent-node/src 现有 91 个(floor 80,余量 11),与正文一致。

三、executed >= discovered 这次是站得住的(与 #800 那条对照)

我在 #800 提过一条 MINOR:那里的 executed == discovered 是恒真的,因为两个计数器
来自同一个循环、成功失败两个分支都在 +1。本 PR 给 test725 补的这条不一样:

executed=$(grep -Eo 'across [0-9]+ files' /tmp/test725-green.log | ...)   # bun 自己的输出
[[ -n "$executed" && "$executed" -ge "$test_files" ]]                     # find 的计数

两个独立来源(bun 的执行数 vs find 的枚举数),所以它真能抓到"runner 少跑了文件"。
这一条我确认没有那个毛病。

---

🔴 MINOR:下限守的是文件个数,守不住"文件还在、内容没了"

我把同样那 40 个文件清空但不删除(: > file),再跑一次:

test_files=46
 36 pass   0 fail
executed_files=46 discovered_files=46
RESULT: PASS                                    退出码 0

门全绿。 而这次的 36 pass 和上面"删掉 40 个"那次一模一样 ——
也就是说:两种形态造成的覆盖损失完全相同,一种会红,另一种一路绿到底。

量化落差:438 → 36,掉了 92%,而门不响。
现有的 grep -Eq '^[[:space:]]*[1-9][0-9]* pass$' 只要求"至少 1 个 pass",
所以 36 和 438 对它没有区别。

这不挡合并 —— 本 PR 的自述范围就是"大量删除的绊线",它在这个范围内完全做到了,
而且比合并前严格得多。但顺手一行就能把这个口也堵上,而且这个形状 #800 已经有了:

# 与 AGENT_NETWORK_SRC_FLOOR 同理,只是量的是「跑了多少个测试」而不是「有多少个文件」
AGENT_NETWORK_SRC_TESTS_FLOOR=380        # 现值 438,留余量
pass_count=$(grep -Eo '^[[:space:]]*[0-9]+ pass$' /tmp/…log | grep -Eo '[0-9]+' | tail -1)
[[ "$pass_count" -ge "$AGENT_NETWORK_SRC_TESTS_FLOOR" ]] || { echo "FAIL: …"; exit 1; }

#800 里的 AGENT_NETWORK_TESTS_FLOOR=15 就是对 tests/ 目录做的同一件事。
两个 PR 合起来看,src/ 这边只做了文件数下限、缺测试数下限,建议补上(本 PR 或另开都行)。

附:与 #800 / #801 的关系

tests/test745-…/run.sh 同时被 #800 / #801 / #854 三个 PR 修改,
其中 #800 × #854 与 #801 × #854 都是真冲突(会被看见,不是静默合并),
所以合并顺序要注意:先合谁,后面两个都得 rebase。详见 #856。

(全部只读:临时 worktree 与四个自建镜像用完即删(git worktree remove / docker rmi);
未改本 PR、未 approve、未 merge。四次实测都是 docker build + docker run 跑这道门自己的容器。)