Dev Validation (Gate 5)

Overview

Final validation gate requiring explicit user approval. Present evidence that each acceptance criterion is met and obtain APPROVED or REJECTED decision.

Core principle: Passing tests and code review DO NOT guarantee requirements are met. User validation confirms implementation matches intent.

Pressure Resistance

See shared-patterns/shared-pressure-resistance.md for universal pressure scenarios.

Gate 5-specific note: User MUST respond with "APPROVED" or "REJECTED: [reason]". No other responses accepted. Silence ≠ approval.

Self-Approval Prohibition

HARD GATE: The agent that implemented code CANNOT approve validation for that same code.

Scenario Allowed? Action

Different agent/human approves YES Proceed with approval

Same agent self-approves no STOP - requires external approval

User explicitly approves YES User approval always valid

If you implemented the code, you CANNOT approve it. Wait for user or different reviewer.

Important: "Different agent" means different human/entity. The same human using different agent roles (ring:backend-engineer-* → ring:code-reviewer) is STILL self-approval and PROHIBITED.

See CLAUDE.md for the canonical validation policy.

Severity Calibration

When presenting validation results to user, issues are categorized by severity:

Severity Criteria Examples Action Required

CRITICAL Acceptance criterion completely unmet AC-1: "User can login" but login doesn't work at all MUST fix before approval. Return to Gate 0.

HIGH Acceptance criterion partially met or degraded AC-2: "Response < 200ms" but actually 800ms MUST fix before approval. Return to Gate 0.

MEDIUM Edge case or non-critical requirement gap AC-3 met for happy path, fails for empty input SHOULD fix before approval. User decides.

LOW Quality issue, requirement technically met Code works but is hard to understand/maintain MAY fix or document. User decides.

Severity Assignment Rules:

• Unmet acceptance criterion = CRITICAL (requirement not satisfied)

• Degraded performance/quality vs criterion = HIGH (requirement barely met)

• Edge case failures = MEDIUM (main path works, edges don't)

• Quality/maintainability with working code = LOW (works but suboptimal)

Why This Matters:

• User needs to understand impact severity when deciding APPROVED vs REJECTED

• CRITICAL/HIGH = automatic REJECTED recommendation

• MEDIUM/LOW = user judgment call with context

Example Validation Checklist with Severity:

Validation Results

Overall Validation: REJECTED (1 HIGH issue: AC-2 response time)

Recommendation: Fix AC-2 (HIGH) before approval. AC-3 (MEDIUM) user can decide.

Common Rationalizations - REJECTED

See shared-patterns/shared-anti-rationalization.md for universal anti-rationalizations (including Validation section).

Gate 5-specific rationalizations:

Excuse Reality

"Async over sync - work in parallel" Validation is a GATE, not async task. STOP means STOP.

"Continue other tasks while waiting" Other tasks may conflict. Validation blocks all related work.

"User delegated approval to X" Delegation ≠ stakeholder approval. Only original requester can approve.

"I implemented it, I know requirements" Knowledge ≠ approval authority. Implementer CANNOT self-approve.

"I'll switch to QA role to approve" Role switching is STILL self-approval. PROHIBITED.

Red Flags - STOP

See shared-patterns/shared-red-flags.md for universal red flags (including Validation section).

If you catch yourself thinking any of those patterns, STOP immediately. Wait for explicit "APPROVED" or "REJECTED".

Ambiguous Response Handling

<block_condition>

• Response is "Looks good", "Sure", "Ok", "Fine"

• Response is emoji only (👍, ✅)

• Response is "Go ahead", "Ship it"

• Response contains conditional ("APPROVED if X", "APPROVED with caveats") </block_condition>

If any condition matches, ask for explicit APPROVED or REJECTED.

User responses that are not valid approvals:

Response Status Action Required

"Looks good" ❌ AMBIGUOUS "To confirm, please respond with APPROVED or REJECTED: [reason]"

"Sure" / "Ok" / "Fine" ❌ AMBIGUOUS Ask for explicit APPROVED

"👍" / "✅" ❌ AMBIGUOUS Emojis are not formal approval. Ask for APPROVED.

"Go ahead" ❌ AMBIGUOUS Ask for explicit APPROVED

"Ship it" ❌ AMBIGUOUS Ask for explicit APPROVED

"APPROVED" ✅ VALID Proceed to next gate

"REJECTED: [reason]" ✅ VALID Document reason, return to Gate 0

"APPROVED if X" ❌ CONDITIONAL Not approved until X is verified. Status = PENDING.

"APPROVED with caveats" ❌ CONDITIONAL Not approved. List caveats, verify each, then re-ask.

"APPROVED but fix Y later" ❌ CONDITIONAL Not approved. Y must be addressed first.

When user gives ambiguous response:

"Thank you for the feedback. For formal validation, please confirm with:

• APPROVED - to proceed with completion
• REJECTED: [reason] - to return for fixes

Which is your decision?"

Never interpret intent. Require explicit keyword.

Awaiting Approval - STOP all WORK

<cannot_skip>

• STOP all work when validation request is presented

• Wait for explicit APPROVED or REJECTED

• Do not proceed with any "quick fixes" while waiting </cannot_skip>

When validation request is presented:

• STOP all WORK on this feature, module, and related code

• DO not proceed to documentation, refactoring, or "quick fixes"

• DO not work on "unrelated" tasks in the same codebase

• WAIT for explicit user response

User unavailability is not permission to:

• Assume approval

• Work on "low-risk" next steps

• Redefine criteria as "already met"

• Proceed with "we'll fix issues later"

Document pending status and WAIT.

Approval Format - MANDATORY

<user_decision> Valid responses:

• "APPROVED" → Proceed to next gate

• "REJECTED: [reason]" → Return for fixes </user_decision>

User MUST respond with exactly one of:

✅ "APPROVED" - All criteria verified, proceed to next gate ✅ "REJECTED: [specific reason]" - Issues found, fix and revalidate

not acceptable:

• ❌ "Looks good" (vague)

• ❌ "👍" (ambiguous)

• ❌ Silence (not a response)

• ❌ "Approved with minor issues" (partial = REJECTED)

If user provides ambiguous response, ask for explicit APPROVED or REJECTED.

Prerequisites

Before starting this gate:

• All tests pass (Gate 3 verified)

• Code review passed (Gate 4 VERDICT: PASS)

• Implementation is complete and stable

Steps 1-4: Evidence Collection and Validation

Step Action Output

1. Gather Evidence Collect proof per criterion Table: Criterion, Evidence Type (Test/Demo/Log/Manual/Metric), Location, Status

2. Verify Execute verification (automated: npm test --grep "AC-X" , manual: documented steps with Result + Screenshot) VERIFIED/FAILED per criterion

3. Build Checklist For each AC: Status + Evidence list + Verification method Validation Checklist

4. Present Request Task Summary + Validation Table + Test Results + Review Summary + Artifacts USER DECISION block with APPROVED/REJECTED options

Validation Request format:

VALIDATION REQUEST - [TASK-ID] Task: [title], [description], [date] Criteria: Table (Criterion | Status | Evidence) Tests: Total/Passed/Failed/Coverage Review: VERDICT + issue counts Artifacts: Code, Tests, Docs links

USER DECISION REQUIRED: [ ] APPROVED - proceed [ ] REJECTED - specify: which criterion, what's missing, what's wrong

Steps 5-6: Handle Decision and Document

Decision Actions Documentation

APPROVED

1. Document (Task, Approver, Date, Notes) → 2. Update status → 3. Proceed to feedback loop Validation Approved record

REJECTED

1. Document (Task, Rejector, Date, Criterion failed, Issue, Expected vs Actual) → 2. Create remediation task → 3. Return to Gate 0 → 4. After fix: restart from Gate 3 → 5. Track in feedback loop Validation Rejected + Remediation Required records

Validation Record format: Date, Validator, Decision, Criteria Summary (X/Y), Evidence Summary (tests/manual/perf), Decision Details, Next Steps

Validation Best Practices

Category Strong Evidence Weak Evidence (avoid)

Evidence Quality Automated test + assertion, Screenshot/recording, Log with exact values, Metrics within threshold "Works on my machine", "Tested manually" (no details), "Should be fine", Indirect evidence

Verifiable Criteria "User can login" → test login + verify session "System is fast" → needs specific metric

"Page loads <2s" → measure + show metric "UX is good" → needs measurable criteria

Handling Partial Validation

If some criteria pass but others fail:

• Do not partially approve

• Mark entire validation as REJECTED

• Document which criteria passed (won't need re-verification)

• Document which criteria failed (need fixes)

• After fixes, re-verify only failed criteria

• Present updated checklist for approval

Anti-Patterns

Never:

• Skip validation because "tests pass"

• Auto-approve without user decision

• Assume criterion is met without evidence

• Accept vague approval ("looks good")

• Proceed while awaiting decision

• Reuse old evidence for new changes

Always:

• Present evidence for every criterion

• Require explicit APPROVED/REJECTED decision

• Document rejection reason in detail

• Track validation metrics

• Re-verify after any changes

Execution Report

Base metrics per shared-patterns/output-execution-report.md.

Metric Value

Duration Xm Ys

Criteria Validated X/Y

Evidence Collected X automated, Y manual

User Decision APPROVED/REJECTED

Rejection Reason [if applicable]

Result Gate passed / Returned to Gate 0

Edge Cases

Scenario Action

User Unavailable Document pending → Do not proceed → Set escalation → Block task completion

Criterion Ambiguity STOP → Ask user to clarify → Update AC → Re-verify with new understanding

New Requirements Document as new req → Complete current validation on original AC → Create new task → no scope creep