vibe-coding-harness

质检 Agent：产出物合规检查

这不是一个独立使用的 Skill，而是其他 Skill 的"守门员"——在任何 Skill 声称"完成"后，用它来验证产出物是否真正符合规范。

治理规则来自项目根目录的 harness.json（唯一真实来源）和 CLAUDE.md（人类可读宪法）。 本 Skill 把这些规则变成逐条可执行的检查项。

---

检查流程

Step 1：确定检查范围

先确认用户想检查什么：

• 如果用户指定了 Skill（如"检查 PRD"），只检查那个 Skill 的产出
• 如果用户说"全量检查"或没说具体，检查 docs/ 下所有已有产出物
• 如果 docs/ 不存在或为空，直接报告"没有可检查的产出物"

Step 2：加载规则

读取项目根目录的 harness.json，提取：

• 目标 Skill 的 produces（该产出什么文件）
• 目标 Skill 的 required_sections（必须包含的章节）
• 目标 Skill 的 field_requirements（字段级校验规则）
• 目标 Skill 的 validation（内容级校验规则）
• cross_skill_rules（跨 Skill 一致性规则，仅在多 Skill 产出共存时检查）
• quality_gates.before_delivery（交付前必须通过的门）
• workflow（流程定义：阶段、步骤、entry_gate/exit_gate、账本规则）—— 用于新增的流程一致性检查
• progress_cards（项目进度卡规则：低上下文读取、总表/模块卡/任务卡同步）

并读取 docs/进度账本.md（流程状态来源）。若不存在，流程检查记为"未启用账本"。 如果项目存在 .dsu/progress/index.md，读取该文件并按需抽查相关模块卡和任务卡；如果不存在，项目进度卡检查记为"未启用"。

Step 3：逐项检查

按以下顺序逐项检查，每项给出通过/不通过/不适用：

3.0 流程一致性检查（最先做 · 这一版新增）

对照 harness.json.workflow 和 docs/进度账本.md，核对过程有没有跑偏（不只是产出物对不对）：

• 阶段按序：有没有跳过整个阶段而未推进（如账本显示在 S2，但 S1 出口门 ✗）。
• 假完成：账本标「已完成」的阶段，其 exit_gate 是否真的过了（防止"账本说完成、产出物却没达标"）。
• 跳步留痕：被跳过的步骤是否都是 required:false、且在账本"跳步留痕"写了理由；required:true 的步骤被跳 = 🔴 违规。
• 账本与产出物吻合：账本当前阶段/步骤，与 docs/ 下实际存在的产出物对得上。
• 红线：若项目涉及"动钱 / 动别人隐私"，survival 红线提示是否出现过。

输出：🔴 流程违规（如"S1 未过却已在 S2"）／🟡 跳步未留痕、账本与进度说明书不一致／✅ 流程一致。

3.0.5 项目进度卡检查（开发期上下文治理）

如果项目启用了 .dsu/progress/，对照 harness.json.progress_cards 检查：

• 总表是否存在：.dsu/progress/index.md 是否存在且非空。
• 总表是否只放索引级信息：总表应只回答当前阶段、当前主线、完成 DU、进行中 DU、下一步、最大风险，不应堆模块实现细节。
• 读取规则是否清楚：总表必须说明默认只读 index，按需读取模块卡，复盘才读任务卡。
• 模块卡是否可下钻：DU 总进度表中的细节卡路径应指向 .dsu/progress/modules/duXX-xxx.md。
• 任务 closeout 是否同步：最近任务更新后，应能在任务卡、模块卡、总表三处看到一致状态。
• 状态枚举是否合规：只能使用 未开始 / 脚手架 / 进行中 / 已完成 / 阻塞 / 回滚 / 待重构。
• 最小上下文是否可用：总表中的「下一轮 AI 最小上下文」应控制在 150 到 300 字，且不写历史流水账。

输出：🔴 缺少总表或状态冲突／🟡 总表过细、模块卡缺失、任务 closeout 未同步／✅ 项目进度卡可用。

3.1 文件存在检查

对照 produces，确认每个文件是否已创建、是否非空。