verification
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseVerification Before Completion
完成前验证
Overview
概述
Sniper validates CODE QUALITY. Verification validates FUNCTIONAL RESOLUTION. Both are needed before closing any task.
Sniper catches linter errors, SOLID violations, and code style issues. Verification ensures the original request is actually fulfilled -- the right behavior, the right output, the right fix. A task can pass sniper with zero errors and still be functionally wrong.
| Aspect | Sniper | Verification |
|---|---|---|
| Focus | Code quality | Functional correctness |
| Checks | Linting, SOLID, style | Acceptance criteria, regressions, side effects |
| Runs | After any code change | Before marking task as complete |
| Result | Clean code | Solved problem |
Sniper 验证代码质量，而验证环节验证功能问题的解决。在关闭任何任务前，两者缺一不可。
Sniper 会捕获代码检查错误、SOLID原则违规和代码风格问题。验证环节则确保原始需求真正得到满足——行为正确、输出正确、修复有效。一个任务可能在Sniper检查中零错误，但在功能上仍然存在问题。
| 维度 | Sniper | 验证环节 |
|---|---|---|
| 关注点 | 代码质量 | 功能正确性 |
| 检查内容 | 代码检查、SOLID原则、代码风格 | 验收标准、回归问题、副作用 |
| 运行时机 | 代码变更后 | 标记任务完成前 |
| 结果 | 代码整洁 | 问题解决 |
Agent Workflow
Agent工作流
When invoked, follow the 6-step verification process below before marking any task as completed.
当触发此流程时，在标记任何任务完成前，请遵循以下6步验证流程。
6-Step Verification Process
6步验证流程
Step 1: Re-read the original request
Go back to the original issue, task description, or user message. Read it word by word. Do not rely on memory or assumptions.
Step 2: List ALL acceptance criteria
Extract every explicit and implicit requirement from the original request. Number them. If the request is vague, list what a reasonable user would expect.
Step 3: Verify each criterion with evidence
For each criterion, provide concrete evidence of resolution:
- Test output showing the expected behavior
- Log output confirming the fix
- Screenshot of the UI change
- Code diff showing the implementation
Step 4: Check for regressions
Run the full test suite. Compare results before and after. No new failures, no new warnings.
Step 5: Check for side effects
Review every modified file. Confirm no accidental changes to unrelated code. Verify dependencies and configuration are unchanged unless required.
Step 6: Confirm functional resolution
State explicitly: "Original problem is FUNCTIONALLY resolved" with a summary of evidence, or list what remains unresolved.
步骤1：重新阅读原始需求
回到原始问题、任务描述或用户消息，逐字阅读。不要依赖记忆或假设。
步骤2：列出所有验收标准
从原始需求中提取所有明确和隐含的要求，编号列出。如果需求模糊，列出合理用户会期望的内容。
步骤3：为每一项标准提供解决的具体证据
为每一项标准提供解决的具体证据：
- 展示预期行为的测试输出
- 确认修复的日志输出
- UI变更的截图
- 展示实现的代码差异
步骤4：检查回归问题
运行完整测试套件，对比变更前后的结果。确保没有新的失败或警告。
步骤5：检查副作用
审阅所有修改的文件，确认没有对无关代码的意外变更。验证依赖和配置是否未被修改，除非有明确要求。
步骤6：确认功能问题已解决
明确声明：“原始问题已在功能上得到解决”并附上证据摘要，或列出尚未解决的内容。
Reference Guide
参考指南
| Resource | Path | Content |
|---|---|---|
| Checklist | | Full verification checklist with all categories |
| Common Misses | | Frequently forgotten verification items |
| 资源 | 路径 | 内容 |
|---|---|---|
| 检查清单 | | 包含所有类别的完整验证检查清单 |
| 常见遗漏项 | | 经常被忽略的验证项 |
Integration with APEX
与APEX的集成
Verification runs between eLicit and eXamine in the APEX workflow:
Analyze -> Plan -> Execute -> eLicit -> [VERIFICATION] -> eXamine (sniper)This ensures functional correctness is confirmed before code quality validation. A task is only complete when both verification and sniper pass.
验证环节在APEX工作流的eLicit和eXamine步骤之间运行：
Analyze -> Plan -> Execute -> eLicit -> [VERIFICATION] -> eXamine (sniper)这确保在验证代码质量之前，先确认功能正确性。只有当验证和Sniper都通过时，任务才算完成。
Critical Rules
关键规则
| Rule | Reason |
|---|---|
| Never skip re-reading the original request | Prevents solving the wrong problem |
| Evidence required for every criterion | "It works" is not evidence |
| Full test suite, not just new tests | Catches regressions |
| Review ALL modified files | Catches accidental side effects |
| Both verification AND sniper must pass | Quality without correctness is useless |
| 规则 | 原因 |
|---|---|
| 永远不要跳过重新阅读原始需求 | 避免解决错误的问题 |
| 每一项标准都需要提供证据 | “它能运行”不能作为证据 |
| 运行完整测试套件，而非仅新测试 | 发现回归问题 |
| 检查所有修改的文件 | 发现意外的副作用 |
| 验证和Sniper必须都通过 | 没有正确性的质量毫无意义 |