debug-my-harness

根据飞行记录器诊断测试框架的异常行为——这是 vigiles 在测试框架运行期间写入 .vigiles/runs.jsonl 的本地、仅追加账本。它记录了实际发生的情况，让你依据证据进行调试，而不是靠猜测。

账本内容

每行一条 JSON 记录，每条都包含一个 kind：

• hook — 编译钩子的门控决策：{event, decision: allow|deny|ask, mode: enforce|observe, rule, cmd, reason}。
• agent — 子 Agent 的工具契约决策：{name, tool, allowed, reason}（值为 false 表示 Agent 越界了）。
• skill — 技能激活情况：{name, fired}。
• eval — 实测指标：{name, metric, value}（例如，触发率召回率／精确率）。
• capability-diff — 影响范围变化：{pr, added, removed, widened}。

说明

步骤 1：读取账本

读取 .vigiles/runs.jsonl（JSONL——每行一条记录；容忍最后一行不完整）。如果文件不存在或为空，请说明这一点——目前还没有记录；建议先运行测试框架（或 vigiles audit）。不要捏造记录。

步骤 2：优先依据证据回答具体问题

将用户的问题与账本记录对应起来：

• “为什么技能 X 不再触发／为什么运行的是错误的技能？”——按名称统计 skill 的触发次数，并比较不同时段。如果 X 的触发率下降，查找在相同类型提示词下触发的同类技能（选择冲突），并检查它们的描述是否重叠。建议区分或合并这些描述。
• “为什么我的钩子没有拦截它？”——查找该事件的 hook 记录。如果本应拒绝的操作出现 decision:allow，或 mode:observe（影子模式，永远不会拦截），又或完全没有记录，就能据此判断原因。建议将 observe→enforce，或修复门控逻辑。
• “子 Agent 是否行为异常？”——列出 allowed:false 的 agent 记录：该 Agent 尝试使用其声明契约之外的工具。指出需要收紧或放宽的契约。
• “情况是否越来越糟？”——比较不同运行中的 eval 指标值（召回率／精确率）；趋势下降就表明发生了漂移（通常出现在测试框架／模型升级后）。

步骤 3：根据证据提出修复建议

优先将被忽略但可判定的规则从文字说明提升为确定性门控：反复出现的 agent 违规，或 Agent 屡次违反的规则 → 编译钩子或更严格的工具契约（strengthen 技能可提供帮助）。描述冲突 → 区分技能描述。务必引用用于诊断的具体记录。

步骤 4：提供后续步骤

如果修复需要修改规范，交给 edit-spec。如果要将指导提升为代码检查器规则，交给 strengthen。如果需要测量行为声明（该技能现在是否会触发？），交给 test-harness（measureTriggerRate）。