metacoding 1.0.0 → 1.1.0

package/templates/node/files/docs-update.instructions.md

@@ -1,203 +0,0 @@
----
-description: 'Guidelines for maintaining project documentation'
-applyTo: '**/*.md'
----
-
-# Documentation Maintenance Guidelines
-
-## Documentation Architecture Principles
-
-This project enforces a strict distinction between different types of documentation to ensure clarity, maintainability, and appropriate use of status indicators.
-
-### System Documentation (Evergreen, Factual)
-
-**Purpose:** Describes the current state of the system, architecture, and implemented features.
-**Files:** README.md, architecture.md, api-design.md, system-documentation.md, code documentation
-**Language:** Present tense, factual, descriptive
-**Status Indicators:** ❌ **NEVER use status emojis or temporal language**
-**Content Focus:** What exists now, how it works, what it does
-**Examples:**
-
-- ✅ Correct: "The authentication system uses JWT tokens"
-- ❌ Incorrect: "🚧 Authentication system (in progress)"
-- ✅ Correct: "The API supports the following endpoints:"
-- ❌ Incorrect: "📋 Planned API endpoints:"
-
-### Project Management Documentation (Temporal, Status-Oriented)
-
-**Purpose:** Tracks work progress, planning, and execution status.
-**Files:** project-task-list.md, sprint-planning.md, backlog.md
-**Language:** Status-oriented, temporal references allowed
-**Status Indicators:** ✅ **Required - use emojis and progress indicators**
-**Content Focus:** What needs to be done, work progress, planning
-**Examples:**
-
-- ✅ Correct: "🚧 In Progress - Authentication system implementation"
-- ✅ Correct: "✅ Completed - JWT token validation"
-- ✅ Correct: "📋 Backlog - Add OAuth integration"
-
-### User Documentation (Instructional, Current)
-
-**Purpose:** Helps users understand how to use the system.
-**Files:** Installation guides, usage examples, tutorials
-**Language:** Imperative, instructional, present tense
-**Status Indicators:** ⚠️ **Use sparingly** - only for actual user-facing feature status
-**Content Focus:** How to use, what users can do, step-by-step guidance
-
-### Enforcement Rules
-
-1. **No Status Emojis in System Documentation:** Architecture, API docs, and README feature descriptions must be purely factual
-2. **No Temporal Language in System Documentation:** Avoid "currently", "recently", "planned", "upcoming" in system docs
-3. **Status Indicators Required in Project Management:** All task lists and project planning docs must use clear status indicators
-4. **Regular Documentation Audits:** Review and remove status language that has crept into system documentation
-5. **Template Compliance:** All generated documentation must follow these principles
-
-## Documentation Quality Standards
-
-- **Clarity:** Write clear, concise explanations
-- **Completeness:** Ensure documentation covers all necessary aspects
-- **Accuracy:** Verify all information is current and correct
-- **Consistency:** Maintain consistent tone and formatting
-- **Accessibility:** Use clear language and proper formatting for accessibility
-- **Architecture Compliance:** Follow the system vs project documentation distinction
-
-## Status Indication Guidelines (For Project Management Documentation Only)
-
-**⚠️ IMPORTANT: These guidelines apply ONLY to project management documentation (task lists, planning docs). System documentation (README, architecture, API docs) must NEVER use status indicators.**
-
-- **Use checkboxes for task status:** `- [ ]` for incomplete, `- [x]` for complete
-- **Use clear status indicators in project management docs:**
-  - ✅ Complete/Implemented
-  - 🚧 In Progress
-  - ❌ Not Started
-  - ⚠️ Needs Review
-  - 🔄 Under Revision
-- **Examples of correct project management documentation:**
-  - ✅ Good: "🚧 In Progress - User authentication implementation"
-  - ✅ Good: "Development Status" with current checkboxes
-  - ✅ Good: "✅ Completed - API endpoint testing"
-- **Examples of incorrect system documentation:**
-  - ❌ Bad: "🚧 Authentication Features" (in README.md)
-  - ❌ Bad: "Authentication system (planned)" (in architecture.md)
-  - ❌ Bad: "📋 API Endpoints" (in api-design.md)
-
-## Task Management Documentation Guidelines
-
-- **Focus on current state:** Document what needs to be done, not what was recently done
-- **Use project phases:** Organize by logical project phases or milestones, not completion status
-- **Move completed work to changelog:** Record completed work in CHANGELOG.md, not in task lists
-- **Keep task lists current:** Update completed items with current status instead of maintaining "completed" sections
-- **Use descriptive section names:** Use functional names like "Core Features", "Infrastructure", "Testing" instead of "Completed Tasks"
-- **Avoid temporal references:** Don't use "Recent", "Latest", "Upcoming" in section headers - they become outdated quickly
-
-## README.md Standards (System Documentation)
-
-**⚠️ README.md is system documentation - NO status indicators or temporal language allowed**
-
-- **Project Overview:** Keep description current with latest capabilities using factual, present-tense language
-- **Installation Instructions:** Verify and update installation steps with clear, current procedures
-- **Usage Examples:** Ensure all code examples are tested and working, describe what they do
-- **Feature Documentation:** Document all major features with examples using factual descriptions
-- **Version Badges:** Keep version badges synchronized with package.json
-- **Links Verification:** Regularly check that all links work correctly
-- **Screenshots/GIFs:** Update visual documentation when UI changes
-- **Avoid Status Language:** Never use "planned", "upcoming", "in progress", or status emojis
-- **Examples:**
-  - ✅ Correct: "The CLI provides three commands for project setup"
-  - ❌ Incorrect: "🚧 CLI commands (in development)"
-  - ✅ Correct: "Authentication uses JWT tokens with refresh capability"
-  - ❌ Incorrect: "Authentication system (planned for v2.0)"
-
-## CHANGELOG.md Maintenance
-
-- **User-Facing Changes:** Document all changes that affect users
-- **Consistent Format:** Follow established changelog format
-- **Categorization:** Group changes appropriately (Added, Changed, Fixed, etc.)
-- **Breaking Changes:** Clearly mark breaking changes
-- **Migration Guides:** Provide migration guidance for breaking changes
-
-## Code Documentation
-
-- **JSDoc Comments:** Update JSDoc comments when changing public APIs
-- **Inline Comments:** Add comments for complex logic, not obvious code
-- **Function Documentation:** Document parameters, return values, and side effects
-- **Class Documentation:** Explain class purpose, responsibilities, and usage patterns
-- **Type Documentation:** Document complex TypeScript types and interfaces
-
-## API Documentation
-
-- **Endpoint Documentation:** Keep API endpoint documentation current
-- **Parameter Changes:** Update parameter descriptions for any modifications
-- **Response Examples:** Provide realistic response examples
-- **Error Handling:** Document error responses and status codes
-- **Authentication:** Keep authentication documentation accurate
-
-## Architectural Documentation (System Documentation)
-
-**⚠️ Architecture docs are system documentation - NO status indicators or temporal language allowed**
-
-- **Decision Records:** Record significant architectural decisions in `/meta` folder using factual language
-- **System Overview:** Maintain high-level system architecture documentation describing current implementation
-- **Data Flow:** Document data flow and process workflows as they currently exist
-- **Integration Points:** Document external system integrations that are implemented
-- **Performance Considerations:** Document performance implications of current design decisions
-- **Examples:**
-  - ✅ Correct: "The system uses a microservices architecture with three main services"
-  - ❌ Incorrect: "🏗️ Microservices architecture (under development)"
-  - ✅ Correct: "Data flows through the validation layer before storage"
-  - ❌ Incorrect: "Data validation layer (planned implementation)"
-
-## Code Examples and Tutorials
-
-- **Working Examples:** Ensure all code examples compile and run
-- **Complete Examples:** Provide complete, runnable examples when possible
-- **Progressive Complexity:** Start with simple examples, build to complex ones
-- **Error Handling:** Show proper error handling in examples
-- **Best Practices:** Demonstrate best practices in example code
-
-## Test Documentation Standards
-
-Follow the standardized table format for all test case documentation:
-
-### Required Table Format
-
-```markdown
-| Test Case ID  | Description                                 | Type | Status    |
-| :------------ | :------------------------------------------ | :--- | :-------- |
-| AREA-TYPE-001 | Brief but descriptive test case description | Unit | Completed |
-```
-
-### Test Case ID Conventions
-
-- **Format:** `[AREA]-[TYPE]-[NUMBER]`
-- **Area Prefixes (Node.js/Backend):** API, SRV, DB, MW, AUTH, ROUTE, UTIL, CONFIG, DOC, E2E, INT
-- **Type Suffixes:** UNIT, INT, E2E
-- **Sequential Numbering:** 001, 002, 003, etc.
-
-### Table Organization Requirements
-
-- **Functional Grouping:** Group test cases by system area/component
-- **Consistent Formatting:** Maintain proper column alignment using pipes
-- **Clear Headers:** Use descriptive section headers (e.g., "Template System", "CLI Commands")
-- **Status Tracking:** Use simple status values: "Completed", "In Progress", "Not Started"
-
-### Documentation Testing
-
-- **Link Checking:** Regularly verify all links work
-- **Code Testing:** Test all code examples in documentation
-- **Installation Testing:** Verify installation instructions work in clean environment
-- **User Testing:** Occasionally have someone unfamiliar try following docs
-
-## Maintenance Schedule
-
-- **Regular Review:** Schedule regular documentation review cycles
-- **Release Updates:** Update documentation as part of release process
-- **Issue Tracking:** Track documentation issues and improvements
-- **Community Feedback:** Incorporate user feedback on documentation clarity
-
-## Localization Considerations
-
-- **Clear English:** Use clear, simple English for international audiences
-- **Cultural Sensitivity:** Avoid culture-specific references
-- **Technical Terms:** Define technical terms when first introduced
-- **Consistent Terminology:** Use consistent terminology throughout

package/templates/node/files/release.instructions.md

@@ -1,72 +0,0 @@
----
-description: "Step-by-step release process automation"
-applyTo: "package.json"
----
-
-# Release Process Checklist
-
-## Pre-Release Validation
-1. **Test Suite:** Verify all tests pass: `npm test`
-2. **Build Verification:** Ensure clean build without errors: `npm run build`
-3. **Linting:** Check code quality standards: `npm run lint`
-4. **Dependencies:** Review and update dependencies if needed
-5. **Security Audit:** Run security audit: `npm audit`
-
-## Version Management
-1. **Semantic Versioning:** Update version in package.json following SemVer:
-   - **MAJOR:** Breaking changes (X.0.0)
-   - **MINOR:** New features, backward compatible (0.X.0)
-   - **PATCH:** Bug fixes, backward compatible (0.0.X)
-2. **Version Consistency:** Ensure version matches across all relevant files
-3. **Breaking Changes:** Document breaking changes prominently in changelog
-
-## Documentation Updates
-1. **README.md Updates:**
-   - Update version badges to match package.json version
-   - Refresh installation instructions if needed
-   - Update feature descriptions for new capabilities
-   - Verify all links and examples work correctly
-2. **API Documentation:** Update API docs for any interface changes
-
-## Changelog Management
-1. **Add New Entry:** Create new section in CHANGELOG.md with:
-   - Release version number (matching package.json)
-   - Release date in YYYY-MM-DD format
-   - Grouped changes by category:
-     - **Added:** New features
-     - **Changed:** Changes in existing functionality
-     - **Deprecated:** Soon-to-be removed features
-     - **Removed:** Now removed features
-     - **Fixed:** Bug fixes
-     - **Security:** Security vulnerability fixes
-2. **Entry Guidelines:**
-   - Keep entries brief but descriptive (1-2 lines per change)
-   - Focus on user impact rather than technical implementation
-   - Reference issue/PR numbers when applicable: `(#123)`
-   - Highlight breaking changes with ⚠️ or **BREAKING:**
-
-## Git Operations
-1. **Commit Changes:** Stage all release-related changes
-2. **Commit Message:** Use format: `chore: bump version to vX.Y.Z`
-3. **Create Tag:** Tag the commit with version number: `git tag vX.Y.Z`
-4. **Push Changes:** Push commits and tags: `git push && git push --tags`
-
-## GitHub Release
-1. **Create Release:** Create GitHub release with tag matching package.json version
-2. **Release Title:** Use format: `vX.Y.Z - [Brief description]`
-3. **Release Notes:** 
-   - Copy relevant sections from CHANGELOG.md
-   - Include installation instructions
-   - Highlight major changes and breaking changes
-   - Thank contributors if applicable
-
-## Post-Release Verification
-1. **Package Registry:** Verify package published correctly (if applicable)
-2. **Installation Test:** Test installation from registry in clean environment
-3. **Documentation Links:** Ensure all documentation links work correctly
-4. **Monitor Issues:** Watch for any immediate issues reported by users
-
-## Rollback Plan
-- **Git Revert:** Know how to revert problematic releases
-- **Package Unpublish:** Understand package registry policies for unpublishing
-- **Communication:** Prepare communication strategy for critical issues

package/templates/node/files/test-runner.instructions.md

@@ -1,108 +0,0 @@
----
-description: 'Instructions for running and maintaining tests'
-applyTo: 'test/**/*.ts'
----
-
-# Test Execution Guidelines
-
-## Pre-Commit Testing
-
-- Run all tests before committing changes: `npm test`
-- Ensure tests pass in both development and CI environments
-- Fix failing tests before proceeding with commits
-- Run specific test suites for targeted changes when appropriate
-
-## Test Development Standards
-
-- **New Features:** Ensure all new features have corresponding unit tests
-- **Test Coverage:** Aim for high coverage of critical functionality paths
-- **Test Documentation:** Follow table format in `test/test-documentation.md` for all test cases
-- **Test Organization:** Group related tests in describe blocks with clear hierarchy
-
-## Test Case Documentation Format
-
-All test cases must be documented using the standardized table format:
-
-```markdown
-| Test Case ID  | Description                                 | Type | Status    |
-| :------------ | :------------------------------------------ | :--- | :-------- |
-| AREA-TYPE-001 | Brief but descriptive test case description | Unit | Completed |
-```
-
-## Test Case Naming Conventions
-
-### Test Case ID Format: `[AREA]-[TYPE]-[NUMBER]`
-
-**Area Prefixes (Node.js/Backend specific):**
-
-- `API` - REST API endpoint tests
-- `SRV` - Service layer tests
-- `DB` - Database/ORM tests
-- `MW` - Middleware tests
-- `AUTH` - Authentication/Authorization tests
-- `ROUTE` - Route handler tests
-- `UTIL` - Utility function tests
-- `CONFIG` - Configuration management tests
-- `DOC` - Documentation Quality tests
-- `E2E` - End-to-End workflow tests
-- `INT` - Integration tests
-
-**Type Suffixes:**
-
-- `UNIT` - Unit tests
-- `INT` - Integration tests
-- `E2E` - End-to-end tests
-
-**Examples:**
-
-- `API-UNIT-001` - First unit test for API Endpoints
-- `SRV-UNIT-001` - First unit test for Service Layer
-- `DB-INT-001` - First integration test for Database Layer
-- `E2E-WF-001` - First end-to-end workflow test
-
-### Test Method Naming
-
-- Format: `methodName_scenario_expectedOutcome`
-- Example: `getUserById_userExists_returnsUserObject`
-- Use camelCase for all test method names
-
-## Test Data Management
-
-- **Fixtures:** Update test fixtures when data structures change
-- **Realistic Data:** Use realistic data in integration tests to catch real-world issues
-- **Mock Strategy:** Mock external dependencies in unit tests for isolation
-- **Test Database:** Use separate test database/environment for integration tests
-- **Temporary File Cleanup:** Clean up all temporary test files, debug outputs, and mock data after test execution
-- **Fixture Organization:** Move reusable test data to `/test/fixtures/` directory for proper organization
-
-## Test File Hygiene
-
-- **No Orphaned Files:** Remove temporary test files created during debugging or development
-- **Debug Output Cleanup:** Remove console.log statements and debug files before committing
-- **Test Artifact Management:** Ensure test screenshots, logs, and reports are properly managed or cleaned up
-- **Resource Management:** Properly dispose of file handles, database connections, and other test resources
-
-## Test Types and Patterns
-
-- **Unit Tests:** Test individual functions, methods, and components in isolation
-- **Integration Tests:** Test feature workflows and component interactions
-- **End-to-End Tests:** Test complete user scenarios and workflows
-- **Regression Tests:** Add tests for previously fixed bugs to prevent recurrence
-
-## Performance Testing
-
-- **Test Execution Speed:** Keep unit tests fast (under 100ms each when possible)
-- **Parallel Execution:** Structure tests to run safely in parallel
-- **Resource Cleanup:** Ensure proper cleanup of test resources and temporary data
-- **Memory Management:** Monitor and prevent memory leaks in long-running test suites
-
-## Test Maintenance
-
-- **Regular Review:** Periodically review and refactor outdated tests
-- **Documentation:** Document complex test scenarios and their purposes
-- **Continuous Updates:** Update tests when requirements or APIs change
-- **Test Quality:** Apply the same code quality standards to test code as production code
-- **Update test-documentation.md:** Add new test cases to the appropriate table section
-- **Status Tracking:** Update test status as development progresses
-- **Table Format:** Maintain consistent table formatting and column alignment
-- **ID Assignment:** Assign sequential IDs within each area (AREA-TYPE-001, AREA-TYPE-002, etc.)

package/templates/python/files/code-review.instructions.md

@@ -1,215 +0,0 @@
----
-description: 'Python backend code review checklist with Django/Flask/FastAPI focus'
-applyTo: '**/*.py'
----
-
-# Python Backend Code Review Focus Areas
-
-## Python Language and Framework Assessment
-
-### Code Quality and Pythonic Patterns
-
-- **PEP 8 Compliance:** Does the code follow Python style guidelines?
-- **Type Hints:** Are type hints used appropriately for function parameters and returns?
-- **Docstrings:** Are docstrings present for classes, functions, and modules?
-- **Python Idioms:** Does the code use Pythonic patterns (list comprehensions, context managers, etc.)?
-- **Import Organization:** Are imports organized properly (standard library, third-party, local)?
-- **Virtual Environment:** Is the project using virtual environments correctly?
-
-### Django-Specific Review Points
-
-- **Model Design:** Are models properly structured with appropriate fields and relationships?
-- **Migration Safety:** Are database migrations safe and reversible?
-- **View Logic:** Are views handling only HTTP logic, delegating business logic to services?
-- **Template Security:** Are templates using proper escaping and CSRF protection?
-- **Admin Configuration:** Is Django admin configured securely and efficiently?
-- **Settings Management:** Are settings properly organized by environment?
-
-### Flask/FastAPI-Specific Review Points
-
-- **Application Factory:** Is the application using the factory pattern correctly?
-- **Blueprint Organization:** Are blueprints used for modular code organization?
-- **Request Handling:** Are request validation and serialization handled properly?
-- **Error Handling:** Are custom error handlers implemented for different HTTP errors?
-- **Configuration Management:** Is configuration handled securely across environments?
-- **Extension Integration:** Are Flask extensions or FastAPI dependencies configured correctly?
-
-## Security Review for Python Applications
-
-### Authentication and Authorization
-
-- **Password Security:** Are passwords hashed using secure algorithms (bcrypt, scrypt)?
-- **Session Management:** Are sessions handled securely with proper timeouts?
-- **JWT Implementation:** Are JWT tokens implemented with proper signing and validation?
-- **Permission Classes:** Are Django permission classes or Flask decorators used correctly?
-- **CSRF Protection:** Is CSRF protection enabled for state-changing operations?
-- **CORS Configuration:** Are CORS settings configured appropriately for the application?
-
-### Input Validation and Data Security
-
-- **Form Validation:** Are Django forms or serializers validating all inputs?
-- **SQL Injection Prevention:** Is the ORM used properly to prevent SQL injection?
-- **XSS Prevention:** Are user inputs properly escaped in templates?
-- **File Upload Security:** Are file uploads validated and stored securely?
-- **Environment Variables:** Are secrets stored in environment variables, not code?
-- **Database Security:** Are database connections and queries secure?
-
-## Performance and Scalability Review
-
-### Database Optimization
-
-- **Query Efficiency:** Are database queries optimized (select_related, prefetch_related)?
-- **N+1 Query Prevention:** Are N+1 queries identified and resolved?
-- **Database Indexing:** Are appropriate database indexes defined?
-- **Migration Performance:** Do migrations handle large datasets efficiently?
-- **Connection Pooling:** Is database connection pooling configured properly?
-- **Raw SQL Usage:** Is raw SQL avoided where ORM can be used safely?
-
-### Caching and Performance
-
-- **Caching Strategy:** Are appropriate caching mechanisms implemented (Redis, Memcached)?
-- **View Caching:** Are expensive views cached appropriately?
-- **Static Files:** Are static files served efficiently?
-- **Async Implementation:** Are async views used where I/O operations are performed?
-- **Background Tasks:** Are long-running operations moved to background tasks (Celery)?
-- **Pagination:** Is pagination implemented for large datasets?
-
-## Testing and Quality Assurance
-
-### Test Coverage and Quality
-
-- **Test Types:** Are unit, integration, and functional tests present?
-- **Test Organization:** Are tests organized by functionality and easy to understand?
-- **Factory Usage:** Are test factories (factory_boy) used for test data creation?
-- **Mock Usage:** Are external dependencies properly mocked in tests?
-- **Database Testing:** Are database operations tested with test databases?
-- **API Testing:** Are API endpoints tested with proper assertions?
-
-### Testing Frameworks and Tools
-
-- **pytest Configuration:** Is pytest configured correctly with appropriate plugins?
-- **Coverage Reporting:** Is test coverage measured and reported?
-- **Test Fixtures:** Are test fixtures used appropriately for setup and teardown?
-- **Parameterized Tests:** Are parameterized tests used for multiple test scenarios?
-- **Integration Testing:** Are third-party integrations tested appropriately?
-- **Performance Testing:** Are performance-critical paths tested for scalability?
-
-## Error Handling and Logging
-
-### Exception Handling
-
-- **Specific Exceptions:** Are specific exception types caught rather than bare except clauses?
-- **Error Response Format:** Are API error responses consistent and informative?
-- **Graceful Degradation:** Does the application handle failures gracefully?
-- **Custom Exceptions:** Are custom exception classes defined for domain-specific errors?
-- **Error Recovery:** Are there appropriate recovery mechanisms for transient errors?
-- **User-Friendly Messages:** Are error messages helpful for both developers and users?
-
-### Logging and Monitoring
-
-- **Logging Configuration:** Is logging configured appropriately for different environments?
-- **Log Levels:** Are appropriate log levels used (DEBUG, INFO, WARNING, ERROR)?
-- **Structured Logging:** Is structured logging used for easier parsing and analysis?
-- **Sensitive Data:** Are sensitive data excluded from logs?
-- **Performance Logging:** Are performance metrics logged for monitoring?
-- **Error Tracking:** Is error tracking configured (Sentry, Rollbar)?
-
-## Deployment and Environment Configuration
-
-### Environment Management
-
-- **Environment Variables:** Are all configuration values externalized to environment variables?
-- **Settings Organization:** Are settings organized by environment (dev, staging, production)?
-- **Secret Management:** Are secrets managed securely and not committed to version control?
-- **Docker Configuration:** Are Docker configurations optimized for Python applications?
-- **Dependency Management:** Are dependencies pinned to specific versions in requirements.txt?
-- **Environment Isolation:** Are different environments properly isolated?
-
-### Production Readiness
-
-- **WSGI/ASGI Configuration:** Is the WSGI/ASGI server configured correctly for production?
-- **Static File Serving:** Are static files configured for production serving?
-- **Database Configuration:** Is the database configured for production workloads?
-- **Monitoring Setup:** Are monitoring and alerting configured for production?
-- **Backup Strategy:** Is a backup strategy implemented for data protection?
-- **Health Checks:** Are health check endpoints implemented for load balancers?
-
-## Temporary File Management and Cleanup
-
-### Python Artifact cleanup
-
-- **Bytecode Files:** Are `__pycache__` directories and `.pyc` files cleaned up?
-- **Build Artifacts:** Are `build/`, `dist/`, and `*.egg-info/` directories managed?
-- **Test Artifacts:** Are test coverage files and pytest cache cleaned up?
-- **Log File Rotation:** Are application logs rotated and old logs cleaned up?
-- **Media File cleanup:** Are temporary uploaded files cleaned up appropriately?
-- **Virtual Environment cleanup:** Are old virtual environments removed when not needed?
-
-### Cleanup Automation
-
-- **Scheduled cleanup:** Are cleanup tasks scheduled appropriately?
-- **Disk Space Monitoring:** Is disk space monitored to prevent storage issues?
-- **Temporary File Management:** Are temporary files created and cleaned up properly?
-- **Session cleanup:** Are expired sessions cleaned up from the database?
-- **Cache Expiration:** Are cache entries expired and cleaned up appropriately?
-- **Log Retention:** Are log retention policies implemented and enforced?
-
-## Workflow and Process Review
-
-### Development Workflow Compliance
-
-- **7-Step Workflow:** Does the implementation follow the mandatory 7-step development workflow?
-- **Test-Driven Development:** Were tests written before implementation (TDD approach)?
-- **Documentation Updates:** Is all documentation current and accurate?
-- **Task Management:** Are tasks properly tracked and status updated?
-- **Code Review Process:** Has the code been properly reviewed before merging?
-- **Version Control:** Are commits atomic and well-documented?
-
-### Quality Gates and Standards
-
-- **Coding Standards:** Does the code follow established Python and framework-specific standards?
-- **Security Standards:** Are security best practices followed throughout?
-- **Performance Standards:** Does the code meet performance requirements?
-- **Testing Standards:** Is test coverage adequate and tests meaningful?
-- **Documentation Standards:** Is documentation comprehensive and up-to-date?
-- **Deployment Standards:** Is the code ready for production deployment?
-
-## Framework-Specific Anti-Patterns
-
-### Django Anti-Patterns to Flag
-
-- **Fat Models:** Models with too much business logic
-- **Fat Views:** Views handling business logic instead of delegating
-- **Circular Imports:** Apps importing from each other inappropriately
-- **Direct DB Access:** Bypassing Django ORM without good reason
-- **Missing Migrations:** Schema changes without corresponding migrations
-- **Hardcoded URLs:** Using hardcoded URLs instead of reverse() or url names
-
-### Flask/FastAPI Anti-Patterns to Flag
-
-- **Global State:** Using global variables for application state
-- **No Application Factory:** Not using factory pattern for app creation
-- **Missing Error Handling:** No custom error handlers for different scenarios
-- **Blocking Operations:** Synchronous operations in async contexts
-- **No Request Validation:** Missing input validation and serialization
-- **Poor Configuration:** Configuration mixed with application code
-
-## Review Process Guidelines
-
-### Constructive Python-Specific Feedback
-
-- **Framework Best Practices:** Suggest framework-specific improvements
-- **Python Idioms:** Recommend more Pythonic approaches
-- **Security Improvements:** Flag security vulnerabilities specific to Python/Django/Flask
-- **Performance Optimizations:** Suggest Python-specific performance improvements
-- **Testing Improvements:** Recommend better testing strategies for Python applications
-- **Documentation:** Ensure Python docstring conventions are followed
-
-### Review Checklist
-
-- **Code Quality:** Pythonic, PEP 8 compliant, well-documented
-- **Security:** Input validation, authentication, authorization, SQL injection prevention
-- **Performance:** Database optimization, caching, async where appropriate
-- **Testing:** Comprehensive test coverage with appropriate testing strategies
-- **Deployment:** Production-ready configuration and environment management
-- **cleanup:** Proper temporary file and resource management