ring%3adev-validation（环%3adev 验证）

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.

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

| AC # | Criterion | Evidence | Status | Severity |
|------|-----------|----------|--------|----------|
| AC-1 | User can login | ✅ Tests pass, manual verification | MET | - |
| AC-2 | Response < 200ms | ⚠️ Measured 350ms average | not MET | HIGH |
| AC-3 | Input validation | ⚠️ Works for valid input, crashes on empty | PARTIAL | MEDIUM |
| AC-4 | Error messages clear | ✅ All errors have user-friendly messages | MET | - |

**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:

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:

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:

1. STOP all WORK on this feature, module, and related code
2. DO not proceed to documentation, refactoring, or "quick fixes"
3. DO not work on "unrelated" tasks in the same codebase
4. 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

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

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

Validation Best Practices

Handling Partial Validation

If some criteria pass but others fail:

1. Do not partially approve
2. Mark entire validation as REJECTED
3. Document which criteria passed (won't need re-verification)
4. Document which criteria failed (need fixes)
5. After fixes, re-verify only failed criteria
6. 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.

Edge Cases