🔍 8. Code Review Checklist & Definition of Done
This document defines the review checklist for code submissions and the criteria required to consider a task complete (Definition of Done).
🛠️ Code Review Checklist
Reviewers (both AI agents and human leads) must verify these items before approving any Pull Request or code change:
1. Architectural & Clean Design
- Code respects boundaries: Presentation layer does not call data layer directly, domain has no outer dependencies.
- No duplicate logic (DRY): Reusable services, models, and helper classes are preferred.
- Naming consistency: Variables, file names, API endpoints, and database columns match project standards.
2. Implementation Quality
- Type safety: Type annotations and return types are specified (e.g., Python Pydantic schemas and Flutter models).
- No hardcoded secrets: Credentials and keys are read from environment variables.
- Error handling: Edge cases, network timeouts, and database failures are caught and handled gracefully.
3. Testing
- Unit tests are written for all new domain use cases.
- API mock tests exist for presentation routers.
✅ Definition of Done (DoD)
A task is officially complete only when all of the following criteria are checked:
- Code Quality: Code passes static analysis (linting) and is reviewed for clean boundaries.
- Testing: All automated tests pass successfully.
- Documentation: Affected markdown documents (such as APIs, DB schema, or Roadmap) are updated.
- Related Links: Broken links in Obsidian or relative references are fixed.
- Risks Documented: Architectural or security risks are logged.
- Future Improvements: Future enhancements or technical debt details are noted.
- Summary Generated: A brief execution summary is written in the session task log.