| name | 5d-verify |
| description | Multi-layer verification of implementation against spec and intent. Use when: (1) After BUILD phase in 5D-SDD workflow, (2) Implementation is complete and needs validation, (3) User asks to 'test,' 'verify,' or 'check' the implementation, (4) Before considering a feature done. This phase catches errors at multiple levels and routes fixes appropriately. |
| user-invocable | true |
VERIFY Phase
Verify implementation at multiple levels and route failures appropriately.
Verification Layers
Layer 1: Technical Correctness
- Does it build/compile without errors?
- Do tests pass?
- Does linting pass?
- Does it run without crashing?
Failure routing: Return to BUILD
Layer 2: Spec Fidelity
- Does implementation match spec interfaces?
- Are all spec requirements addressed?
- Do outputs match spec definitions?
Failure routing: Return to BUILD (if code error) or SPEC (if spec error)
Layer 3: Plan Validity
- Does this solve the problem stated in the plan?
- Does user testing confirm expected behavior?
- Are the original assumptions holding?
Failure routing: Return to PLAN or SPAR
Layer 4: Epistemic Update (Depth + Time)
- Did we learn anything that changes our assumptions?
- Are there new risks or opportunities?
- Should the spec be updated for future work?
- What patterns emerged that apply to future projects?
- What should we "transcend and include" going forward?
Failure routing: Document for REFLECT phase
Layer 5: Multi-Dimensional Check
Quadrant coverage:
- Individual Outer: Are artifacts complete and correct?
- Individual Inner: Is understanding documented?
- Collective Outer: Are system integrations verified?
- Collective Inner: Is stakeholder alignment confirmed?
Height (Skill Dependencies):
- Did capability gaps cause failures?
- What skills were developed during implementation?
- What remains blocked by missing capabilities?
Identity Trap:
- Are we declaring success to avoid examining failures?
- Are failures being minimized because they threaten assumptions?
- What are we not looking at?
Verification Process
- Run automated checks (build, lint, test)
- Manual spec comparison
- User acceptance testing (if applicable)
- Collect all failures and discoveries
Failure Diagnosis
When something fails, identify which layer:
| Symptom | Likely Layer | Action |
|---|
| Code doesn't run | Layer 1 | Fix in BUILD |
| Works but wrong output | Layer 2 | Check spec, fix in BUILD or SPEC |
| Works but users confused | Layer 3 | Return to PLAN |
| Works but solves wrong problem | Layer 3-4 | Return to SPAR |
Critical: Don't keep fixing code if the spec is wrong. Don't keep fixing spec if the understanding is wrong.
Output Format
## Verification Report
### Layer 1: Technical
- Build: ✓/✗
- Tests: ✓/✗ ([pass]/[total])
- Lint: ✓/✗
### Layer 2: Spec Fidelity
- [Spec item]: ✓/✗
- [Spec item]: ✓/✗
### Layer 3: Plan Validity
- User testing: [results]
- Problem solved: [yes/no/partial]
### Layer 4: Learnings
- [Discovery or assumption update]
### Failures Requiring Action
| Issue | Layer | Routing |
|-------|-------|---------|
| [issue] | [1-4] | [phase to return to] |
**Verification status:** pass / fail-minor / fail-major
Exit Criteria
Feature complete when:
- All Layer 1-3 checks pass
- No unresolved failures
- User confirms acceptance
Proceed to REFLECT when feature is complete or iteration is ending.
