/validating-acceptance-criteria

name: ring:validating-acceptance-criteria
description: "Validating a completed task against its acceptance criteria, mapping each AC to evidence, and gating completion on explicit user sign-off (self-approval prohibited). Gate 5 of ring:running-dev-cycle / ring:running-dev-cycle-frontend, run at task cadence after ring:reviewing-code. Use when implementation and tests are done and you need approval to close the task. Skip outside a dev-cycle, or for doc-only or non-code tasks."

Validation Gate (Gate 5)

When to use

• After review gate passes (Gate 4)
• Implementation and tests complete
• Need user sign-off on acceptance criteria

Skip when

• Not inside a development cycle (ring:running-dev-cycle or ring:running-dev-cycle-frontend)
• Task is documentation-only, configuration-only, or non-code
• No implementation or tests were produced

Sequence

**Runs after:** ring:reviewing-code

Related

**Complementary:** ring:running-dev-cycle, ring:reviewing-code

Validates acceptance criteria and requires explicit user approval.

**Self-approval PROHIBITED.** If you implemented the code, you CANNOT approve it. Wait for user or different reviewer.

Approval Authority

| Who | Can Approve? | |-----|-------------| | User (original requester) | ✅ YES | | Different agent/human | ✅ YES | | Same agent that implemented | ❌ NO — self-approval prohibited |

Step 1: Build Validation Report

Map each acceptance criterion to evidence (tests, PRs, manual verification):

## Validation Results

| AC # | Criterion | Evidence | Status | Severity |
|------|-----------|----------|--------|----------|
| AC-1 | {criterion} | {tests pass / file:line / manual} | MET / NOT MET / PARTIAL | - / HIGH / MEDIUM / LOW |

Severity calibration:

• CRITICAL: acceptance criterion completely unmet
• HIGH: criterion partially met or performance degraded
• MEDIUM: edge case or non-critical gap (main path works)
• LOW: code works but quality suboptimal

Step 2: Present to User

## Gate 5: Validation

### Summary
- Task: {unit_id}
- ACs: {N}/{total} met
- Recommendation: APPROVED / REJECTED

### Validation Table
{validation_table from Step 1}

### Issues (if any)
| Severity | AC # | Description | Recommendation |
|----------|------|-------------|----------------|

### Decision Required
Reply with one of:
- APPROVED — proceed to completion
- REJECTED — return to Gate 0 with comments
- FIX {AC#} then APPROVED — fix specific items first

Step 3: Interpret Response

Explicit approval keywords: `APPROVED`, `YES`, `GO AHEAD`, `SHIP IT`, `PROCEED`, `LOOKS GOOD`. Explicit rejection keywords: `REJECTED`, `REWORK`, `FIX`, `NEEDS CHANGES`.

Ambiguous responses (👍, "ok", "sure") → Ask for clarification: > "To confirm: are you APPROVING this for completion, or requesting changes?"

Step 4: Handle Decision

**APPROVED:**

• Record approval with timestamp + approver identity
• Proceed to next gate

**REJECTED:**

• Record rejection with specific feedback
• Return to Gate 0 with explicit gap list
• Track iteration count (max 3 cycles before escalation)

Output Format

## Validation Summary
- unit_id / ACs met: X/Y / recommendation / decision

## Acceptance Criteria Status
{validation table}

## Decision
APPROVED by {approver} at {timestamp}
OR
REJECTED: {feedback} → returning to Gate 0