2.7 KiB
Context
当前系统采用 success + matched 两层判定模型：
success：拨测是否成功完成（HTTP 收到响应 / Command 正常退出）matched：expect 规则是否匹配- UP =
success AND matched
但实际代码中 fetcher.ts 和 command-runner.ts 均将 success 设为 expectResult.matched，导致 success ≡ matched。两层模型从未真正生效，success 字段是冗余的。
同时发现两个附带问题：
- 分组排序使用
ORDER BY grp（字母序），spec 要求按 YAML 首现顺序 command-runner未设置stdin: "ignore"，spec 要求禁止写入 stdin
Goals / Non-Goals
Goals:
- 移除
success字段，将判定模型简化为matched单层判定 - 修复分组排序为 YAML 首现顺序
- 确保 command-runner 禁用 stdin
Non-Goals:
- 不涉及
success以外的其他字段变更 - 不涉及前端 UI 样式或布局调整
- 不涉及新增功能特性
- 不处理代码质量问题（P2/P3 级别留给后续 change）
Decisions
1. 判定模型简化为 matched 单层
选择: 移除 success，仅保留 matched
理由: success 与 matched 在实现中始终同值，没有独立语义。执行失败（网络错误、超时、进程崩溃）和 expect 不匹配都统一为 matched=false，通过 failure.kind 区分（"error" vs "mismatch"）。
替代方案: 修复 success 使其真正独立（如 HTTP 返回 404 时 success=true, matched=false）。被否决——当前项目不需要区分"请求成功但内容不符"和"请求失败"，单层判定更简洁。
2. 可用率计算基于 matched
选择: availability = matched=true 的记录数 / 总记录数 * 100
avgDurationMs 仅计算 matched=true 记录的平均耗时：AVG(CASE WHEN matched = 1 THEN duration_ms END)
理由: 用户关心的是"健康请求"的性能趋势，排除失败请求的干扰。
3. 分组排序改为按 id 排序
选择: ORDER BY CASE WHEN grp='default' THEN 0 ELSE 1 END, id
理由: 目标按 YAML 顺序插入，id 自增，ORDER BY id 天然等于 YAML 首现顺序。无需额外存储排序权重。
4. 数据库迁移策略
选择: 直接删除旧数据库文件重新创建
理由: 项目未上线，无向前兼容要求。SQLite 不支持 DROP COLUMN（需重建表），直接删除是最简方案。
Risks / Trade-offs
- [风险] 数据库 schema 变更导致已有数据丢失 → 项目未上线，可接受
- [风险] 前端 API 响应格式变更 → 前端代码同步修改，全量测试覆盖
- [风险] 大量文件同时修改可能引入遗漏 → 通过
bun run verify全量验证