completion-examiner

Completion Examiner（完成度审计）

何时必须调用

• 用户要求“你是否 100% 确信实现正确/是否完成”
• 准备交付：要提 PR / 要合并 / 要宣称“已完成”
• 出现疑似回归或测试覆盖不足，且需要把不确定性收敛成证据

输出目标

把“我觉得差不多”变成“有可复现证据链的完成结论”：

• 明确验收标准（Acceptance Criteria）
• 对每条标准提供可复现的验证命令与通过证据
• 对任何疑点补充测试/断言或修复，并再次验证

工作流（循环直到无疑点）

1. 列验收标准

   • 从 issue/用户描述/现有测试提炼 3–10 条验收标准（必须可验证）

2. 做不确定性清单

   • 找出所有“可能不对”的点：边界条件、跨架构差异、feature 组合、构建参数、解析器鲁棒性

3. 把疑点变成可验证项

   • 对每个疑点至少选择一种：
     • 新增/完善自动化测试（单元测试 / e2e / regex 断言）
     • 增加日志证据（但不能替代测试）
     • 最小化修复（修复后必须补回归）

4. 验证并收敛证据

   • 运行最短命令证明结论（prefer CI 同环境，如 Docker）
   • 记录关键输出：通过断言、关键日志片段、版本/commit

5. 复盘剩余风险

   • 若仍有疑点，回到第 2 步继续循环
   • 只有当“疑点清单为空”时才允许宣称完成

6. 交付门禁（宣称“完成”前必过）

   • 必须按 pr-workflow 的 blocking order 逐项通过：cargo fmt --all -- --check → clippy（warnings denied）→ 所改 crate 的单元/集成测试 → E2E（含可复制命令与期望输出）
   • fmt 是本地验证门禁，须在交付前跑通，但 不得 写入 PR 草稿 Test plan/正文（除非用户明确要求）；E2E/clippy/单元测试命令与期望输出才进入 Test plan
   • 宣称完成或准备交付时，必须同时触发 pr-workflow（PR 草稿、手动提交策略）与 report-generator（本地报告更新）；子 agent 在最终总结开头须声明所应用的 skill（如 Applying pr-workflow），见 pr-workflow step 0
   • 未通过 fmt 或任一 blocking gate 时，不得宣称“100% 完成”或“PR ready”

交付格式（必须包含）

• “是否完成”的结论（是/否），以及对应的验收标准列表
• 每条标准的验证命令（PR 草稿 Test plan：E2E/测试/clippy 等；不含 cargo fmt，除非用户明确要求）
• 证据（关键输出片段或测试通过记录）
• 若未完成：剩余疑点 + 下一步最小改动

限制与纪律

• 不允许用“感觉/推测”替代验证
• 不允许引入与本任务无关的大改动
• 若发现 workflow 缺口（例如测试写法不正确），必须同时触发 auto-skill-maintainer 更新技能并提交