## 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` 全量验证