[feature] 完善的测试体系及测试样例 + 及代码质量保障

[vansin]

/loop 5m

不改业务逻辑，不改功能，针对已有的功能探索高效的测试及质量保障体系，每 5min 迭代一次方案

1、确保方案能够支持 anet CLI 、commhub、agent-node 的广泛真实测试
2、测试时间紧可能的不要太长，追求性价比
3、需要真的测到点子上，从用户角度去测去设计测试方案
4、给出测试需要的资源

不断完善方案，可以存到 doc 的 qa 文档里面测试方案，我们先上测试，测试方案应该是 1 步 1 步的融入整个研发体系中，不要一口吃个大胖子，不要成为研发 anet 的阻碍。

每次 round 完成后把 round 结果 保存到 #31 的新 comment 里面，每个 comment 最后付上 round 规则 及 下次 round 的计划

👥 Agent Assignment

• Primary: 通信测试马 (QA loop owner)
• Helpers: 通信龙 (Lead)
• Tier review gate: 通信龙
• Priority: P2
• Status: In Progress (维护模式 + 周报锚点 2026-05-17 22:00 GMT+8 W20)

[s2agi]

R1 — QA 骨架 + 3×3 矩阵

只动 docs，不改业务一行。先把「测什么、怎么分层、谁来 review」拍下来，避免上来就堆 Dockerfile。

本轮产物（commit fef2cfb）

• docs/qa/strategy.md — 3 条铁律（用户视角 / 2min 上限 / Docker 隔离）+ L0-L4 分层 + 资源清单 + R1-R5 节奏
• docs/qa/test-matrix.md — CLI / commhub / agent-node 三 persona 矩阵首版，标注已覆盖项（test30 / test31 / docker-e2e）

三个 persona × 3×3 矩阵 总览

Persona	已覆盖	待补	R2 候选
CLI 用户	5/7（session resume + auth 全套）	hub start / network create / node create	—
commhub 调用方	4/8（auth 全套）	register→mint→send→SSE 闭环	HUB-05 ⭐
agent-node runtime	3/6	success 路径 / hub 重启重连	—

资源（最小集）

资源	状态
Docker (sg docker)	✅
Bun 1.x	✅
@preview npm 包	✅
假 LLM key（让 reply 必失败便于断言）	✅ docker-e2e 已用
fixtures（utok/ntok/task）	❌ R2 补
pnpm qa 一键入口	❌ R3 补

明确不要：公网 hub / 生产数据库 / 真实 LLM 配额 / 真实 IM token。

哲学（每轮自检）

1. 测的是用户动作不是代码实现
2. 单测试套件 ≤ 2 min
3. Docker 隔离，永不碰 47.116.* 产线 hub / 本地 commhub.db
4. 一轮只动 1 件事，不阻塞 anet 业务迭代

---

Round 规则（每轮固定附）

三目标：① anet CLI / commhub / agent-node 广泛真实测试 ② 性价比优先（≤ 2min）③ 用户视角而非代码视角。

流程节奏：

• 不改业务代码、不改功能
• 每轮 ≤ 1 个新测试 / 1 块文档增量
• R 完成后 commit + push + 评论本 issue
• 评论末尾必须有「本轮产物 + 下轮计划」
• 安全红线：评论里永不放 token / 私有 IP / 本机绝对路径

下轮（R2）计划

目标：落地 HUB-05 闭环测试 — register utok → mint ntok → POST /api/tasks → SSE 收到。

步骤：

1. 新建 tests/qa-hub-05-roundtrip/Dockerfile（参考 test30 模式）
2. 入口脚本：bun 拉起 hub → curl + jq 4 步断言 → 退出码
3. 预算：cold ≤ 60s，warm ≤ 20s
4. 产出 docs/tests/report-qa-hub-05.txt
5. 不修业务代码，纯黑盒

R2 验收：本地 sg docker -c 'docker build ... && docker run ...' 一条命令 PASS。

[s2agi]

R1.1 — 补丁：加 dashboard persona + 代码视角

Vincent 反馈两点：

1. 漏了 dashboard persona
2. 用户视角 + 代码视角都要，不能只强调用户视角

commit 4d1576c 已修。

变更

strategy.md 铁律 #1：

• 用户视角（L1+）= 外黑盒，保「用户能用」
• 代码视角（L0 单测）= 内白盒，保「代码不退化」
• 二者不互相替代

分层新增 L3v：视觉回归（dashboard repo Playwright 已有，跨仓库列为保护资产）。

L0 单测渐进清单（每轮 ≤ 1 个文件，先纯函数后大文件）：

• ⭐ server/src/auth.ts — utok/ntok 生成 + 校验（安全核心）
• ⭐ server/src/db.ts — task 状态机非法迁移
• server/src/password-dict.ts — 快可上
• agent-network/bin/cli.ts 解析层 — 4771 行大文件，先重构再测，分多轮

test-matrix.md 新增 dashboard 矩阵 10 格：

ID	用户故事	现状
DASH-01	/login 注册落到 dashboard	✅ docker-e2e SC01
DASH-02	看到自己网络的 agent-node	✅ SC03
DASH-03	Enter 发任务（非 Cmd+Enter）	✅ SC04
DASH-04	失败回复 UI 同步	✅ SC05
DASH-05	刷新历史在	✅ SC06
DASH-06	连发 3 条顺序不乱	✅ SC07
DASH-07	未登录被拒	❌ R4
DASH-08	跨账号隔离	❌ R4
DASH-09	视觉无回归（TopoGraph/chat/node card）	🟡 dashboard repo Playwright（跨仓库）
DASH-10	SSE 断连恢复	❌ R3-R4

新增 L0 代码视角清单（UT-01..05）在矩阵末尾，跟 strategy 对齐。

现状盘点（4 persona × 多维度）

Persona	用户视角覆盖	代码视角覆盖
CLI	5/7 ✅	❌ cli.ts 4771 行 0 单测
commhub	4/8 ✅	❌ auth.ts / db.ts 0 单测
agent-node	3/6 ✅	🟡 client.test.ts 仅 1 个
dashboard	6/10 ✅	(前端在 dashboard repo)

代码视角是真正的洼地 — 但先不一口吃，每轮 ≤ 1 文件。

---

Round 规则（每轮固定附）

三目标：① 4 persona（CLI / commhub / agent-node / dashboard）真实测试 ② 性价比优先（≤ 2min） ③ 用户视角 + 代码视角双线

流程节奏：

• 不改业务代码、不改功能
• 每轮 ≤ 1 个新测试 / 1 块文档增量
• R 完成后 commit + push + 评论本 issue
• 评论末尾必须有「本轮产物 + 下轮计划」
• 安全红线：评论里永不放 token / 私有 IP / 本机绝对路径

下轮（R2）计划 — 不变

落地 HUB-05 闭环测试（用户视角 L1 contract）— register utok → mint ntok → POST /api/tasks → SSE 收到。

预算 cold ≤ 60s / warm ≤ 20s，纯黑盒。R3 起再开 L0 代码视角第一条（UT-02 password-dict.ts，最快上）。

[s2agi]

R2 — HUB-05 contract test 上线（PASS）

第一条真在跑的 QA 测试 — register utok → mint ntok → send task → DB 落库 + SSE 连接。
跑通了，但 hub 行为里抠到一个 SSE push 的前置条件，R3 接着补。

commit 4acfd2b · 实测 PASS（warm ~11s / cold ~30s）

跑法

sg docker -c 'docker build -t anet-qa-hub-05 -f tests/qa-hub-05-roundtrip/Dockerfile .'
sg docker -c 'docker run --rm anet-qa-hub-05'

实测输出：

[0] start hub (no COMMHUB_AUTH_TOKEN, admin bootstrap)
[1] login admin → utok_
[2] create network → network_id   network_id=net_93554f97da1e
[3] mint ntok_ for node 'test-agent'
[4] subscribe SSE on /events/test-agent (background)
[5] POST /api/task → {"ok":true,"message_id":"..."}
[6] verify task landed in GET /api/tasks
PASS qa-hub-05 register→mint→send→DB-lands + SSE-connects (R2 scope)

拿到的「点子上」收获

跑 R2 时发现 server/src/index.ts L836：

if (targetSession) pushEvent(body.alias, ...);

契约：hub 只对已注册 session 推 SSE。一个全新订阅者（curl 没注册）只能收到 connected 事件，不能收到 task body。

真 agent-node CLI 启动时会 report_status 注册 session，所以生产路径正常。但裸 SDK 用户如果只订阅 SSE 不 report_status，就静默丢消息。R3 加一步 report_status pre-reg 来覆盖 end-to-end，并把这个契约写进 test-matrix.md HUB-05 说明。

这就是「用户视角测试」相对「代码视角」抠出的非显然契约 — 看 code 看不出来，跑测试一发就显。

资源（实际用上的）

资源	状态
sg docker	✅
node:20-slim + apt(bash/curl/ca-certs/jq/unzip)	✅
bun via curl bun.sh/install（依赖 unzip）	✅ 踩坑：第一次没装 unzip 直接报错
@sleep2agi/agent-network@preview	✅ v2.1.7-preview.2
jq	✅ 替代 bun 解 JSON，更轻

踩坑记（写进经验，下个测试不再踩）：

1. apt 装 bun 需要 unzip，slim 镜像没有
2. SSE 端点强制 ntok_ + network_id query param，不能用 utok 订阅
3. hub bootstrap 后第一次 /health 200 需要 ~3s，循环重试别 < 60 次

Round 规则（每轮固定附）

三目标：① 4 persona（CLI / commhub / agent-node / dashboard）真实测试 ② 性价比优先（≤ 2min） ③ 用户视角 + 代码视角双线

流程节奏：

• 不改业务代码、不改功能
• 每轮 ≤ 1 个新测试 / 1 块文档增量
• R 完成后 commit + push + 评论本 issue
• 评论末尾必须有「本轮产物 + 下轮计划」
• 安全红线：永不放 token / 私有 IP / 本机绝对路径

下轮（R3）计划

目标 A（接 HUB-05 收尾）：在 qa-hub-05-roundtrip/run.sh 步骤 [4] 之前加 report_status 调用（curl 打 /mcp JSON-RPC 或用 CLI），让 session 行先落库，然后断言 SSE 真的收到 task body。

目标 B（开 L0 代码视角第一条）：补 UT-02 server/src/password-dict.ts 单测 — 弱密码命中字典即拒。纯函数 ~5s，最快出成果。

两个目标二选一还是都做？倾向先做 A（HUB-05 真闭环），R4 再开 L0 单测。如有不同意见欢迎在 issue 评论或派任务给我（通信测试马）。

[s2agi]

R3 — HUB-05 全闭环 PASS（~11s）

把 R2 留的 TODO 收掉。现在 register→mint→report_status→send→SSE new_task push→DB 整条链路硬断言通过。

commit 1c10fef · 矩阵 HUB-05 升 🟡 → ✅

关键修法

加步骤 [3.5]：POST /mcp JSON-RPC tools/call report_status 注册 session 行，这样 hub 的 if (targetSession) pushEvent(...) 条件成立，SSE 真的推。

MCP 调用形状（写进 report 给后人少踩坑）：

POST /mcp
Authorization: Bearer <ntok>
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2025-03-26

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"report_status",
           "arguments":{"resume_id":"<uuid>","alias":"<alias>",
                        "status":"idle","network_id":"<net>"}}}

响应是 SSE-framed（data: {...}），用 sed -n 's/^data: //p' | head -1 取首行。

R2→R3 两个非显然契约（测试逼出来的）

1. SSE push 只对已注册 session 触发 — server/src/index.ts L836 if (targetSession) pushEvent(...)。裸 SDK 用户只订 SSE 不报 status，消息静默丢。
2. SSE 通知不带 body，只带 {type:"new_task", inbox_count, priority, from} — agent 收 push 后必须再调 get_inbox MCP 工具拉具体内容。R2 原断言「SSE 里看到 task 文本」其实是错的协议假设。

这两条是看代码看不出来、跑测试一发就显的契约。后面所有 SDK 集成测试都会用到。

实测输出

[0] start hub (no COMMHUB_AUTH_TOKEN, admin bootstrap)
[1] login admin → utok_
[2] create network → network_id   network_id=net_fb211f9e4f25
[3] mint ntok_ for node 'test-agent'
[3.5] register session via MCP report_status (so SSE delivery works)
[4] subscribe SSE on /events/test-agent (background)
[5] POST /api/task → {"ok":true,"message_id":"..."}
[6] wait up to 5s for SSE to receive new_task push
[7] verify task landed in GET /api/tasks
PASS qa-hub-05 register→mint→report_status→send→SSE-push→DB-lands
real 0m11.429s

当前 QA 测试库（实跑可复现）

测试	层	persona	状态	时间
qa-hub-05-roundtrip	L1 contract	commhub	✅ PASS	~11s
test30 auth-deprecation	L2 CLI	CLI / commhub auth	✅ 历史 PASS	~60s
test31 claude-code-cli-resume	L0+L2	agent-node	✅ 历史 PASS	—
docker-e2e (7 SC)	L3	dashboard + agent-node	🟡 保护资产	~90s

R3 之前 0 个新增 "QA-tagged" 测试。R3 后 1 个，且暴露 2 个协议契约，开始有价值。

Round 规则（每轮固定附）

三目标：① 4 persona（CLI / commhub / agent-node / dashboard）真实测试 ② 性价比优先（≤ 2min） ③ 用户视角 + 代码视角双线

流程节奏：

• 不改业务代码、不改功能
• 每轮 ≤ 1 个新测试 / 1 块文档增量
• R 完成后 commit + push + 评论本 issue
• 评论末尾必须有「本轮产物 + 下轮计划」
• 安全红线：永不放 token / 私有 IP / 本机绝对路径

下轮（R4）计划

目标：开 L0 代码视角第一条 — UT-02 server/src/password-dict.ts 单测。

理由：

• 纯函数，最快上，预算 < 5s
• 是 test30 step3 已在端到端层覆盖的逻辑，补一层快速单元保护，PR 改这文件能秒拦截 regression
• 同时建 agent-network/ 下 bun test 怎么跑的脚手架文档，便于下轮接 CLI 解析层等更复杂模块

R5 起按矩阵 ROI 排队补，每轮 ≤ 1 个新测试 / 模块。

[s2agi]

R4 — UT-02 L0 单测落地（19 pass，55ms）

第一条代码视角测试上线。commit 4633484

产物

• server/src/password-dict.test.ts — bun:test，19 断言 / 25 expect
• tests/qa-ut-02-password-dict/ — Docker 包装（oven/bun:1，可选）
• docs/tests/report-qa-ut-02.txt
• 矩阵 UT-02 升 ✅

覆盖（19 个断言）

组	内容
常见弱密码字面值	123456 / password / qwerty / admin / letmein / iloveyou / passw0rd
6 位补零数字家族	000000 / 000042 / 000999
passwordN 家族	N=0/42/999
qwertyN 家族	N=0/999
大小写契约	Set 只存 lowercase；pin auth.ts L26 WEAK_PASSWORDS.has(password.toLowerCase()) 行为
强密码必须不在	StrongPassw0rd / correct horse battery / Tr0ub4dor&3 / 等 5 条
Set.size > 3000 sanity	89 字面 + 1000×3 家族

跑法

# 本地 dev loop（推荐）
cd server && bun test src/password-dict.test.ts        # ~55ms

# Docker（CI / 跨平台一致性）
sg docker -c 'docker build -t anet-qa-ut-02 -f tests/qa-ut-02-password-dict/Dockerfile .'
sg docker -c 'docker run --rm anet-qa-ut-02'           # ~0.5s

跟现有 test30 的差异 — 这就是 L0 的价值

test30 step 3 端到端测了 register API 拒 password / 123456 — 2 个输入，~60s。
UT-02 测19 输入 + 3 个家族边界 + 大小写契约 + size sanity — 25ms。

端到端不可替代（测 HTTP 链路），单测不可替代（边界 + 速度）。两条线都要，这是 R1.1 铁律 #1 的实证。

当前 QA 测试库

测试	层	persona	状态	时间
qa-ut-02-password-dict	L0 unit	(commhub auth)	✅ NEW	local 55ms / Docker 0.5s
qa-hub-05-roundtrip	L1 contract	commhub	✅	~11s
test30 auth-deprecation	L2 CLI	CLI / commhub auth	✅ 历史	~60s
test31 claude-code-cli-resume	L0+L2	agent-node	✅ 历史	—
docker-e2e (7 SC)	L3	dashboard + agent-node	🟡 保护资产	~90s

L0 / L1 / L2 / L3 四层各至少一条。骨架打通了，剩下按矩阵 ROI 排队补格子。

资源消耗（实测）

资源	用途	实际开销
oven/bun:1 镜像	L0 Docker 包装	~200MB
本地 bun 1.x	local dev loop	已装
网络 / DB / commhub	0	完全不需要

Round 规则（每轮固定附）

三目标：① 4 persona（CLI / commhub / agent-node / dashboard）真实测试 ② 性价比优先（≤ 2min） ③ 用户视角 + 代码视角双线

流程节奏：

• 不改业务代码、不改功能
• 每轮 ≤ 1 个新测试 / 1 块文档增量
• R 完成后 commit + push + 评论本 issue
• 评论末尾必须有「本轮产物 + 下轮计划」
• 安全红线：永不放 token / 私有 IP / 本机绝对路径 / maintainer 私有 hub IP

下轮（R5）计划

目标：HUB-06 — utok 撤销后 ntok 失效 安全边界 contract test。

理由：

• 这是 双 token 体系 的核心安全契约，错了就出大事
• 用户视角：管理员撤了用户，那个用户派生的 agent 应该立即断
• 复用 R3 的 qa-hub-05 脚手架（hub 起、注册、mint），加 revoke 步骤
• 预算 ≤ 30s warm（同级别）

R6 起开 UT-01 server/src/auth.ts 单测（token 生成 + 校验 + 边界），跟 R5 的安全 contract 互相加固。

[s2agi]

R5 — HUB-06 token revoke contract PASS（抠出 3 个非显然契约）

第二条用户视角 L1 contract test 上线，双 token 撤销边界。

commit 6d63443 · warm ~15s

抠出的 3 个非显然契约（这就是「测到点子上」）

⚠️ Gap 1：utok 撤销不级联到 ntok

server/src/auth.ts L267-272：

export function revokeOtherUserTokens(userId: string, exceptTokenId?: string | null): number {
  const result = exceptTokenId
    ? db.run("DELETE FROM api_tokens WHERE user_id = ?1 AND network_id IS NULL AND token_id != ?2", ...)
    : db.run("DELETE FROM api_tokens WHERE user_id = ?1 AND network_id IS NULL", ...);

只删 network_id IS NULL 的行，也就是只撤 utok，不撤 ntok。

admin reset-user bob 改密码 + 撤 bob 的 utok 后，bob 派出去的 agent（用 ntok）继续跑。

设计权衡：

• 维持现状 = 改密码不导致用户的 fleet 掉线（OK if password-reset 频率高）
• 改成 cascade = 安全性更强，admin 一键停一个用户的所有 agent

🙋 请 @通信龙 / Vincent 评：这是设计还是 bug？决策后改 auth.ts L267 并翻转测试 step 7 的断言。

Surprise 2：register() 自动建 default network + default ntok

测试一上来发现 bob 注册后立刻就有 3 个 token（不是 2 个）：

{"tokens":[
  {"name":"default-network","scope":"network","network_id":"net_..."},   // ← auto-created
  {"name":"node:bob-node","scope":"network","network_id":"net_..."},     // ← my mint
  {"name":"admin-reset","scope":"user","network_id":null}                // ← after reset
]}

这影响所有 SDK 用户的初始状态判断。文档值得加一句「register() 副作用：建 default network + ntok」。

Quirk 3：POST /api/auth/node-token 响应不带 token_id

createNetworkTokenForNode 只返回 {ok, token}，没有 token_id。要撤销自己刚 mint 的 ntok，必须再 GET /api/auth/tokens 按 name 匹配。SDK 集成踩坑点。

测试步骤（9 步硬断言）

步骤	断言
[0] hub boot	health 200
[1] register + login bob	utok_bob
[2] bob 建 network	network_id 非空
[3] bob mint ntok（name=node:bob-node）	ntok_bob + 拿到 token_id
[4] sanity	两 token 都能用
[5] anet hub admin reset-user --username bob	CLI 输出 new password + new utok
[6] OLD utok_bob	401
[7] PIN: ntok_bob 仍 200	(当前 cascade 行为)
[8] bob DELETE /api/auth/tokens/<ntok_id>	ok:true
[9] ntok_bob	401

当前 QA 测试库

测试	层	persona	状态	时间
qa-ut-02-password-dict	L0 unit	commhub auth	✅	55ms / 0.5s
qa-hub-05-roundtrip	L1 contract	commhub	✅	11s
qa-hub-06-token-revoke	L1 contract	commhub	✅ NEW	15s
test30 auth-deprecation	L2 CLI	CLI / auth	✅ 历史	60s
test31 claude-code-cli-resume	L0+L2	agent-node	✅ 历史	—
docker-e2e (7 SC)	L3	dashboard + agent-node	🟡 保护资产	90s

R3 后 3 个新增 QA-tagged 测试，每条都抠出协议契约或行为细节。这就是「测到点子上」的 ROI。

Round 规则（每轮固定附）

三目标：① 4 persona（CLI / commhub / agent-node / dashboard）真实测试 ② 性价比优先（≤ 2min） ③ 用户视角 + 代码视角双线

流程节奏：

• 不改业务代码、不改功能
• 每轮 ≤ 1 个新测试 / 1 块文档增量
• R 完成后 commit + push + 评论本 issue
• 评论末尾必须有「本轮产物 + 下轮计划」
• 安全红线：永不放 token / 私有 IP / 本机绝对路径 / maintainer 私有 hub IP

下轮（R6）计划

agent-node persona 还是 0 个新 QA 测试，下轮转向那边。

目标：NODE-02（agent-node 收到 inbound task → 成功回复路径）。docker-e2e SC05 只测了 failed 回复路径，成功路径用真 LLM 太贵 — 用 mock runtime（一个 echo agent，收到 task 直接 send_reply 返回固定字符串）。

预算 ≤ 60s warm。复用 R3 的 qa-hub-05 hub 起法 + 加一个最小 agent-node 容器（不跑真 LLM）。

[s2agi]

R6 — NODE-02 成功回复路径 PASS（~8.5s，0 LLM 调用）

第三条用户视角 L1 contract test 上线，覆盖 agent-node persona 的核心成功路径。

commit fd9afc3 · 矩阵 NODE-02 升 ✅

核心设计 — mock-via-MCP

docker-e2e SC05 已用 fake-key 真 agent 测了 failed 回复。
成功路径需要真 LLM —— 烧钱 + flaky。R6 不真起 agent，直接 curl 打 /mcp tools/call send_reply：

POST /mcp
Authorization: Bearer <ntok>
{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"send_reply",
           "arguments":{"alias":"admin","text":"pong-r6 success-path",
                        "in_reply_to":"<task_id>","status":"replied",
                        "from_session":"mock-echo"}}}

测的是 commhub 的 task 状态机契约（"如果 agent 回 replied，DB 应该正确更新"），不是 agent CLI 自己 —— 后者由 e2e 覆盖。两层互补不重复，0 LLM API 调用。

测试步骤（9 步硬断言）

#	断言
[0] hub boot	health 200
[1] admin login	utok_（带 retry，对抗 bootstrap race）
[2] admin 建 network	network_id
[3] mint ntok（alias=mock-echo）	ntok_
[4] mock agent report_status(idle)	session 行落库
[5] admin POST /api/task	task_id
[6] PRE: task.status = 'delivered'	状态机入口
[7] mock agent send_reply(replied, in_reply_to, text)	response.ok=true
[8] POST: status=replied + result=text + completed_at set	状态机出口
[9] /api/messages 含 reply 文本	sender 可见性

抠出的 3 个非显然契约

1. /api/networks POST 响应 shape 因 caller 而异

// admin caller
{ "ok": true, "network_id": "net_...", "network_name": "..." }    // top-level

// 非 admin caller（R5 bob 看到的）
{ "ok": true, "network": { "network_id": "net_...", ... } }       // nested

SDK 集成必须用 defensive jq：.network.network_id // .network_id。

2. admin login 可能在 /health 200 后短暂 401

bootstrap race —— admin password 写入 DB 跟 HTTP server 就绪不是严格同步。
R2 / R6 都偶然踩到。修法：login 加 retry loop。值得加进 SDK examples。

3. send_reply 对终态 task 静默 no-op

server/src/tools.ts L613-614：

UPDATE tasks SET status = ?, result = ?, completed_at = ...
 WHERE task_id = ? AND status IN ('created', 'delivered', 'acked', 'running')

意味着对一个已经是 replied/failed/cancelled 的 task 再 send_reply，更新被静默吃掉，
但响应仍然 ok。SDK 用户重试时会以为成功。

→ NODE-02b idempotency 测试候选（R8 或 R9）。

当前 QA 测试库

测试	层	persona	状态	时间
qa-ut-02-password-dict	L0 unit	commhub auth	✅	55ms / 0.5s
qa-hub-05-roundtrip	L1 contract	commhub	✅	11s
qa-hub-06-token-revoke	L1 contract	commhub	✅	15s
qa-node-02-success-reply	L1 contract	agent-node	✅ NEW	8.5s
[test30 / test31 / docker-e2e]	L2 / L3	历史	✅ 保护资产	60-90s

每个 persona 都至少有一条新 QA 测试了 —— CLI 在 test30/31 历史覆盖，
commhub R2/R5 ✅，agent-node R6 ✅，dashboard docker-e2e SC01-07 已覆盖（保护资产，跨仓库视觉由 N站马 维护）。

Round 规则（每轮固定附）

三目标：① 4 persona（CLI / commhub / agent-node / dashboard）真实测试 ② 性价比优先（≤ 2min） ③ 用户视角 + 代码视角双线

流程节奏：

• 不改业务代码、不改功能
• 每轮 ≤ 1 个新测试 / 1 块文档增量
• R 完成后 commit + push + 评论本 issue
• 评论末尾必须有「本轮产物 + 下轮计划」
• 安全红线：永不放 token / 私有 IP / 本机绝对路径 / maintainer 私有 hub IP

下轮（R7）计划

4 persona 全覆盖后，转向一键跑入口 —— scripts/qa.sh（strategy.md §5 资源清单里的「pnpm qa 入口脚本」）。

目标：写一个 scripts/qa.sh 串起所有 R1-R6 的 L0+L1 测试，按层级 + 短路退出：

1. L0（password-dict bun test，最快，失败立即停）
2. L1 contract 三连（hub-05 / hub-06 / node-02，并行 docker run）
3. 退出码 = 测试集合的最大失败码
4. 总预算 ≤ 60s（warm 缓存下）

这是 strategy.md §6 R3 行 计划要做的「一键跑入口」，
做完后任何 PR 评审都能 bash scripts/qa.sh 一条命令验证基线，开始让 QA 真正融入研发流程。