ring-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