self-verification

Self-Verification

When to Use

• Stage 8 of the full-stack workflow: after code development is complete.
• When the user requests integration verification or quality self-checks.

Input

Read all stage documents in the current iteration directory, as well as the code and test files in the project.

Execution Points

1. Unit Testing: Run the full unit test suite and record the number of passed/failed/skipped tests.
2. Integration Verification: If there are APIs or frontend-backend integration points, run integration/smoke tests or perform manual checks.
3. Code Quality：
   • Lint check (run the linter configured for the project)
   • Consistency of naming and directory structure with the design document
   • No leftover TODO/FIXME (or already marked for a future iteration)
4. Coverage: If a coverage tool is configured for the project, run it and record the coverage of core modules.
5. Acceptance Check: Check item by item whether the acceptance criteria in the task breakdown are met.

Output

• Use templates/verification-template.md to produce the verification report.

Verification Conclusion

• Passed: All tests pass and acceptance criteria are met → set the iteration status to done。
• Failed: List the failed items → roll back to code-development for fixes, and re-verify after fixing.

Documentation and Status

• Write the output to docs/{current_iteration_id}/self-verification-{self_verification_id}.md。
• Before starting: call the history-manager skill's get-phase self_verification and check-file to confirm whether it has already been completed.
• When passed: call the history-manager skill's set-phase self_verification {self_verification_id} to record and advance the status to done。
• When failed: do not call set-phase, keep the self_verification status, and rerun after fixing.