verify

Verify — Validate Implementation (Expanded Workflow)

You are validating that the implementation matches the planning artifacts for an OpenSpec change. This is a read-only analysis — you identify gaps but don't fix them automatically.

Note: This is part of the expanded workflow.

Upstream source: Fission-AI/OpenSpec

Workflow

Step 1: Identify the Change

• If the user specified a change name, use that
• Otherwise, find the active change in openspec/changes/ that has the most recently updated tasks.md
• Ask if multiple changes are active

Step 2: Load Artifacts

Read all artifacts from openspec/changes/<change-name>/:

• tasks.md — implementation checklist (check completion status)
• specs/**/*.md — requirements and scenarios
• design.md — technical approach (if exists)
• proposal.md — original intent (if exists)

Report what was loaded and task completion status:

Change: [change-name]
Tasks: [N] complete, [N] remaining

Artifacts:
  ✓ proposal.md
  ✓ specs/[capability]/spec.md
  ✓ design.md
  ✓ tasks.md

Step 3: Verify Each Requirement

For each ### Requirement: in each spec file, check:

1. Code evidence: Is there code in the repository that implements this requirement?
2. Scenario coverage: Is each #### Scenario: verifiable in the current code?
3. Test coverage: If the requirement has test-related scenarios, are they tested?

Report each requirement:

Requirement: User can export data
  ✓ Code found: src/export/ExportService.ts
  ✓ Scenario: Successful export — implemented in exportData()
  ✗ Scenario: Export with empty dataset — no handling found

Step 4: Verify Design Decisions (if design.md exists)

For each key decision in design.md, verify it was followed in the implementation:

• Check that the chosen architecture/pattern is actually used
• Look for deviations from the design and note them

Step 5: Check Task Completion

Review tasks.md:

• Count checked [x] vs unchecked [ ] items
• Flag any unchecked tasks that appear to have corresponding code already written
• Flag any checked tasks where the described work doesn't appear in the codebase

Step 6: Generate Verification Report

Output a verification report (do NOT modify any files):

## Verification Report: [change-name]

**Date**: [TODAY]
**Tasks**: [N] complete, [N] remaining

### Requirement Coverage

| Requirement | Status | Evidence | Notes |
|-------------|--------|----------|-------|
| User can export data | ⚠️ Partial | src/export/ExportService.ts | Missing empty-dataset scenario |
| User can import CSV | ✅ Full | src/import/CsvImporter.ts | All scenarios verified |

### Design Compliance

| Decision | Status | Notes |
|----------|--------|-------|
| Use streaming for large exports | ✅ Followed | Found in ExportService.ts |
| Use worker threads | ⚠️ Deviation | Direct processing used instead |

### Summary

  Requirements fully verified: [N]/[total]
  Requirements partially verified: [N]/[total]
  Requirements not found: [N]/[total]
  
  Design decisions followed: [N]/[total]
  Design deviations: [N]/[total]

  Overall status: [✅ Verified / ⚠️ Partial / ❌ Gaps Found]

Step 7: Provide Next Steps

Based on the verification results:

If all requirements are verified:

✅ Implementation verified! Ready to archive.
Next step: Run /openspec:archive to archive this change.

If gaps were found:

⚠️ [N] gaps found. Recommended actions:
  1. Complete missing implementation: [list unverified requirements]
  2. Update specs if requirements changed during implementation
  3. Add/update tests for unverified scenarios
  
After addressing gaps, run /openspec:verify again to confirm.

Behavior Rules

• Strictly read-only: Never modify any files — only report findings
• Be specific: Reference actual file paths and function names when citing evidence
• Be lenient with deviations: Implementation details often differ from initial design. Note deviations but don't treat them as failures unless they contradict requirements.
• Focus on requirements: The spec requirements are the source of truth, not the design or tasks