refactor: 移除 success 字段，简化为 matched 单层判定模型

openspec/changes/archive/2026-05-11-simplify-judgment-model/design.md

@@ -0,0 +1,63 @@
+## Context
+
+当前系统采用 `success` + `matched` 两层判定模型：
+- `success`：拨测是否成功完成（HTTP 收到响应 / Command 正常退出）
+- `matched`：expect 规则是否匹配
+- UP = `success AND matched`
+
+但实际代码中 `fetcher.ts` 和 `command-runner.ts` 均将 `success` 设为 `expectResult.matched`，导致 `success ≡ matched`。两层模型从未真正生效，`success` 字段是冗余的。
+
+同时发现两个附带问题：
+1. 分组排序使用 `ORDER BY grp`（字母序），spec 要求按 YAML 首现顺序
+2. `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` 全量验证