GAPS FILLED

GAPS FILLED

Phase: {N} — {name} Resolved: {count}/{count}

Tests Created

#	File	Type	Command
1	{path}	{unit/integration/smoke}	{cmd}

Verification Map Updates

Task ID	Requirement	Command	Status
{id}	{req}	{cmd}	green

Files for Commit

{test file paths}

**② PARTIAL——部分解决、部分升级：**

```markdown
## PARTIAL

**Phase:** {N} — {name}
**Resolved:** {M}/{total} | **Escalated:** {K}/{total}

### Resolved
| Task ID | Requirement | File | Command | Status |
|---------|-------------|------|---------|--------|
| {id} | {req} | {file} | `{cmd}` | green |

### Escalated
| Task ID | Requirement | Reason | Iterations |
|---------|-------------|--------|------------|
| {id} | {req} | {reason} | {N}/3 |

### Files for Commit
{test file paths for resolved gaps}

③ ESCALATE——缺口全部挡路、一个都未补上：

## ESCALATE

**Phase:** {N} — {name}
**Resolved:** 0/{total}

### Details
| Task ID | Requirement | Reason | Iterations |
|---------|-------------|--------|------------|
| {id} | {req} | {reason} | {N}/3 |

### Recommendations
- **{req}:** {manual test instructions or implementation fix needed}

在 get-shit-done/workflows/validate-phase.md 中，这三种返回值被编排者这样消化：## GAPS FILLED → 记录测试与映射更新；## PARTIAL → 记录已解决项，把升级项移入 Manual-Only 清单；## ESCALATE → 全部缺口移入 Manual-Only 并提示重试或人工验证。换言之，审计代理永远通过"是否 Escalate"把无法自行裁决的问题归还给人类或后续开发闭环——这正是升级门（Escalation Gate）模式在验证子代理上的落地，与姊妹代理 gsd-verifier 的 BLOCKER/WARNING 分类逻辑一脉相承。

VALIDATION.md：审计结果要回写的"反馈契约"

审计者产出测试后，编排者统一把结果回写到该阶段的验证契约文件中（模板见 get-shit-done/templates/VALIDATION.md），该文件同时是全流程的机器可读状态源。其 frontmatter 含两个关键布尔：

phase: {N}
slug: {phase-slug}
status: draft
nyquist_compliant: false   # 签名关：全部任务 green 后置为 true
wave_0_complete: false     # Wave 0 脚手架是否就绪
created: {date}

模板正文的 Per-Task Verification Map 是全篇核心，列位完整承接了从安全分析（secure-phase）到补测的全链路语义：

| Task ID | Plan | Wave | Requirement | Threat Ref | Secure Behavior | Test Type | Automated Command | File Exists | Status |

其中 Threat Ref（威胁编号，如 T-{N}-01，无威胁时记 —）与 Secure Behavior 列说明 VALIDATION.md 同时承载安全行为的可验证性；File Exists 标记 ✅ / ❌ W0（W0 意为该测试文件属于必须先由 Wave 0 任务搭建的脚手架）；Status 的取值集合是 ⬜ pending · ✅ green · ❌ red · ⚠️ flaky。

Sampling Rate 节定义了反馈信号的采样节奏，也是"奈奎斯特类比"最直接的操作化：每个任务提交后跑 {quick run command}、每个 plan wave 结束后跑 {full suite command}、/gsd:verify-work 前全量套件必须 green，并约束最大反馈延迟（Max feedback latency: {N} seconds）。模板还包含 Test Infrastructure 表、Wave 0 Requirements 清单、Manual-Only Verifications 表（记录为何必须人工、给出测试步骤），以及 Validation Sign-Off 复选框——其中明确要求"不存在连续 3 个任务没有自动化 verify"与"将 nyquist_compliant: true 写入 frontmatter"。它同时呼应计划层的 Dimension 8：在 get-shit-done/workflows/plan-phase.md 中，若 research 被禁用而 nyquist 校验仍开启，编排者会警告"无法创建 VALIDATION.md，计划将缺失验证需求（Dimension 8）"。

审计缺口从哪里来：/gsd:validate-phase 的状态机与回写

gsd-nyquist-auditor 由 commands/gsd/validate-phase.md 定义的前端命令 /gsd:validate-phase {N} 驱动，其用途是"追溯性地审计并填补已完成阶段的 Nyquist 验证缺口"——典型场景是阶段在 Nyquist 验证引入前就已执行完毕，或现有代码库只有传统测试套件。工作流先探测输入状态：

• State A：VALIDATION.md 存在 → 审计既有契约并补缺；
• State B：无 VALIDATION.md 但 SUMMARY.md 存在 → 从产物重建契约；
• State C：SUMMARY.md 都不存在 → 直接退出并提示先跑 /gsd:execute-phase。

在 Discovery 阶段，编排者完成 PLAN/SUMMARY 抽取、构建"需求→任务"映射（{ task_id, plan_id, wave, requirement_ids, has_automated_command }），并用 find 探测测试基建（pytest.ini、jest.config.*、vitest.config.*、pyproject.toml 等），随后做"需求 ↔ 测试文件"交叉引用，把每个需求归类为 COVERED / PARTIAL / MISSING。无缺口时直接置 nyquist_compliant: true；有缺口则先经用户门（AskUserQuestion：全修 / 标记 manual-only / 取消），确认后才 spawn 审计代理。

审计返回后，编排者完成回写与提交：更新 Per-Task Map 状态、把升级项追加进 Manual-Only，并追加审计留痕表：

## Validation Audit {date}
| Metric | Count |
|--------|-------|
| Gaps found | {N} |
| Resolved | {M} |
| Escalated | {K} |