## Validation Wave Orchestration Strategy

> This file defines the orchestration workflow for the Validation Wave — an adversarial short-circuit model that schedules validation subtasks per defect.

### Core Philosophy

**Your goal is to refute the defect report, not validate it.**

Each validation strategy aims to find reasons to refute the defect. Refutation requires code evidence; speculative refutation is not accepted. If no refutation reason is found, the defect is considered valid (Promote).

### Main Task Responsibilities (Orchestrator)

#### 1. Restore Context

1. Read `<output_dir>/.draft-02-detection/manifest.json` (obtain the defect list)
2. Read file outputs under `.draft-02-detection/` directory as needed (obtain defect details to populate subtask input)
3. Create the `<output_dir>/.draft-03-validation/` directory
4. Write the initial version of `<output_dir>/.draft-03-validation/manifest.json`:
```json
{
  "version": 1,
  "stage": "validation",
  "status": "in_progress",
  "defects": [],
  "summary": {
    "total_defects": 0,
    "promoted": 0,
    "killed": 0,
    "by_confidence": {}
  }
}
```

#### 2. Per-Defect Scheduling

For each defect in `manifest.json`, execute in sequence:

1. Obtain the defect summary from the `defects` array in the Detection Manifest (id, severity, type, title, file, location, source_strategy)
2. Extract the full defect information from `.draft-02-detection/<file>.md` (analysis, impact, issue code, fix code, evidence chain)
3. Read `<skill-root>/references/validation/routing.md`, match the validation strategy list based on the defect's assertion characteristics
4. Launch an Agent subtask, passing in the **subtask execution template** (see below) and filling in the following variables:
   - `<defect_id>`: defect ID (D001, D002, ...)
   - `<defect_info>`: full defect information (title, severity, type, location, analysis, impact, issue code)
   - `<evidence_chain>`: Mermaid evidence chain generated during the Detection stage
   - `<validation_strategies>`: matched validation strategy list with loading signal descriptions
   - `<output_dir>`: output directory path
   - `<skill-root>`: skill root path
5. Wait for the subtask to complete
6. Extract the verdict from the subtask output, update the `defects` array in `manifest.json`
7. Update TodoWrite

#### 3. Aggregation

After all defects have been validated:

1. Calculate `summary` (promoted, killed, by_confidence)
2. Set `manifest.json` `status: "completed"`

### Subtask Execution Template

---

## Role
You are a defect validation expert. Your goal is to refute the defect report, not validate it.
Refutation requires code evidence; speculative refutation is not accepted.

## Input
- **Defect information**:
  - ID: `<defect_id>`
  - Title: <defect_title>
  - Severity: <severity>
  - Type: <defect_type>
  - Location: <location>
  - Analysis: <analysis>
  - Impact assessment: <impact>
  - Issue code: <issue_code>

- **Detection evidence chain**: <evidence_chain>

- **Matched validation strategies** (execute in order):
<validation_strategies>

## Execution Steps

**Warning (mandatory): Use the TodoWrite tool to organize the execution workflow**

1. Read and execute validation strategies **sequentially**, one by one:
   - Read `<skill-root>/references/validation/<strategy>.md`
   - Follow the strategy guidance to find refutation evidence
   - If code verification is needed, read the relevant lines of the source file
   - If LSP tools are needed, read `<skill-root>/references/tools/lsp.md`

2. **Short-circuit evaluation**:
   - Refutation evidence found → Record Kill + reason + code evidence → **stop subsequent strategies**
   - No refutation evidence found → Record Promote → continue to the next strategy

3. After all strategies have been executed (or Kill midway), write the result in the output format

## Output Format

Write to `<output_dir>/.draft-03-validation/<defect_id>.md`:

```
### <Defect Title>
- **Defect ID**: <id>
- **Final verdict**: Kill / Promote
- **Confidence**: High / Medium / Low (Promoted defects only)
- **Execution path**:

| Strategy | Verdict | Key Finding |
|----------|---------|-------------|
| context-gap | Promote | No implicit introduction found |
| defense-existing | Kill | Parameterized query defense found |

**Kill reason**: (if Kill)
<Specific refutation evidence and code references>

**Promote evidence summary**: (if Promote, for all strategies)
<Brief summary of why all refutation attempts failed>

**Evidence chain** (appended with code-level validation findings on top of the Detection evidence chain. The Mermaid diagram must immediately follow this title as the first ```mermaid code block; downstream report generation extracts it by this convention):
```mermaid
graph LR
    A["Source: req.body.username<br>app.ts:12"] -->|"User input"| B["Propagation: const sql = `SELECT...`<br>app.ts:15"]
    B -->|"No parameterized query"| C["Sink: db.query(sql)<br>app.ts:18"]
    C -.->|"defense-existing: No defense found"| D["Sink is exploitable"]
    style B fill:#f96,stroke:#333
```
```
