validation-pipeline

# Validation Pipeline

## Purpose

Run structured validation pipelines that execute steps sequentially, enforce gates at blocking failures, and produce scored reports. Uses `.claude/helpers/validation-pipeline.cjs` with 13 requirements validation steps (BMAD-003).

## Activation

- When validating requirements documents
- When running structured quality gates
- When assessing document completeness, testability, or traceability
- When invoked via `/validation-pipeline`

## Quick Start

```bash
# Validate a requirements document (all 13 steps)
/validation-pipeline requirements docs/requirements.md

# Validate with specific steps only
/validation-pipeline requirements docs/requirements.md --steps format-check,completeness-check,invest-criteria

# Continue past blocking failures
/validation-pipeline requirements docs/requirements.md --continue-on-failure

# Output as JSON
/validation-pipeline requirements docs/requirements.md --json
```

## Workflow

### Step 1: Read the Target Document

Read the file specified by the user. If no file is provided, ask for one.

```
Read the target document using the Read tool.
Store the content for pipeline execution.
```

### Step 2: Select Pipeline

Choose the appropriate pipeline based on the user's request:

| Pipeline | Steps | Use Case |
|----------|-------|----------|
| `requirements` | 13 | Requirements documents, PRDs, user stories |

Additional pipelines can be added to `.claude/helpers/validation-pipeline.cjs`.

### Step 3: Execute Pipeline

The pipeline helper (`.claude/helpers/validation-pipeline.cjs`) handles execution:

1. **Sequential execution** — steps run in order, each receiving results from prior steps
2. **Gate enforcement** — blocking steps that fail halt the pipeline (unless `--continue-on-failure`)
3. **Per-step scoring** — each step produces a 0-100 score with findings and evidence
4. **Weighted rollup** — overall score uses category weights (format=10%, content=30%, quality=25%, traceability=20%, compliance=15%)

#### Requirements Pipeline Steps (13 total)

| # | Step ID | Category | Severity | What It Checks |
|---|---------|----------|----------|----------------|
| 1 | `format-check` | format | blocking | Headings, required sections, document length |
| 2 | `completeness-check` | content | blocking | Required fields populated, acceptance criteria present |
| 3 | `invest-criteria` | quality | warning | Independent, Negotiable, Valuable, Estimable, Small, Testable |
| 4 | `smart-acceptance` | quality | warning | Specific, Measurable, Achievable, Relevant, Time-bound |
| 5 | `testability-score` | quality | warning | Can each requirement be tested? |
| 6 | `vague-term-detection` | content | info | Flags "should", "might", "various", "etc." |
| 7 | `information-density` | content | info | Every sentence carries weight, no filler |
| 8 | `traceability-check` | traceability | warning | Requirements-to-tests mapping exists |
| 9 | `implementation-leakage` | quality | warning | Requirements don't prescribe implementation |
| 10 | `domain-compliance` | compliance | info | Alignment with domain model |
| 11 | `dependency-analysis` | traceability | info | Cross-requirement dependencies identified |
| 12 | `bdd-scenario-generation` | quality | warning | Can generate Given/When/Then for each requirement |
| 13 | `holistic-quality` | compliance | blocking | Overall coherence, no contradictions |

### Step 4: Report Results

Format the pipeline result as a structured report:

```markdown
# Validation Report: Requirements Pipeline

**Overall**: PASS/FAIL/WARN | **Score**: 85/100 | **Duration**: 42ms

## Step Results
| # | Step | Status | Score | Findings | Duration |
|---|------|--------|-------|----------|----------|
| 1 | Format Check | PASS | 100 | 0 | 2ms |
| 2 | Completeness | WARN | 60 | 2 | 5ms |
...

## Blockers
- (blocking findings listed here)

## All Findings
- [HIGH] Missing acceptance criteria: Requirement US-104 has no AC
- [MEDIUM] Vague term: "should" used 5 times without specifics
...
```

### Step 5: Record Learning

After pipeline execution, record the outcome for learning:

```typescript
// Store validation pattern
memory store --namespace validation-pipeline --key "req-validation-{timestamp}" --value "{score, findings_count, halted}"
```

## Parameters

| Parameter | Type | Default | Description |
|-----------|------|---------|-------------|
| `pipeline` | string | `requirements` | Pipeline type to run |
| `file` | string | required | Path to document to validate |
| `--steps` | string | all | Comma-separated step IDs to run (e.g., `format-check,completeness-check`) |
| `--continue-on-failure` | boolean | false | Skip blocking gates |
| `--json` | boolean | false | Output as JSON instead of markdown |
| `--metadata` | object | {} | Additional context for steps |

## Integration Points

- **qe-requirements-validator agent** — delegates structured validation to this pipeline
- **qe-quality-gate agent** — uses pipeline for gate evaluation
- **YAML Pipelines** — can invoke validation steps as workflow actions
- **MCP** — accessible via `pipeline_validate` tool

## Output Schema

The pipeline produces a `PipelineResult` object (see `schemas/output.json`):

```typescript
{
  pipelineId: string;
  pipelineName: string;
  overall: 'pass' | 'fail' | 'warn';
  score: number;           // 0-100 weighted average
  steps: StepResult[];     // per-step details
  blockers: Finding[];     // blocking findings
  halted: boolean;
  haltedAt?: string;       // step ID where halted
  totalDuration: number;
  timestamp: string;
}
```

## Error Handling

- **Step throws exception** — captured as a FAIL with critical finding, pipeline continues or halts per severity
- **File not found** — report error, do not run pipeline
- **Empty document** — format-check step will catch this as a blocking failure