metacoding 1.0.0 → 1.1.0

package/templates/{python/files → general}/docs-update.instructions.md

@@ -1,13 +1,13 @@
 ---
-description: 'Guidelines for maintaining project documentation'
+description: 'Universal documentation maintenance guidelines for all project types'
 applyTo: '**/*.md'
 ---
 
-# Documentation Maintenance Guidelines
+# Universal 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.
+This project enforces a strict distinction between different types of documentation to ensure clarity, maintainability, and appropriate use of status indicators across all project types.
 
 ### System Documentation (Evergreen, Factual)
 
@@ -54,10 +54,10 @@ This project enforces a strict distinction between different types of documentat
 
 ## Documentation Quality Standards
 
-- **Clarity:** Write clear, concise explanations
-- **Completeness:** Ensure documentation covers all necessary aspects
+- **Clarity:** Write clear, concise explanations appropriate for the target audience
+- **Completeness:** Ensure documentation covers all necessary aspects of the project
 - **Accuracy:** Verify all information is current and correct
-- **Consistency:** Maintain consistent tone and formatting
+- **Consistency:** Maintain consistent tone and formatting across all documentation
 - **Accessibility:** Use clear language and proper formatting for accessibility
 - **Architecture Compliance:** Follow the system vs project documentation distinction
 
@@ -76,10 +76,6 @@ This project enforces a strict distinction between different types of documentat
   - ✅ 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
 
@@ -98,7 +94,7 @@ This project enforces a strict distinction between different types of documentat
 - **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
+- **Version Badges:** Keep version badges synchronized with package.json (or equivalent for other languages)
 - **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
@@ -111,32 +107,42 @@ This project enforces a strict distinction between different types of documentat
 ## 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.)
+- **Consistent Format:** Follow established changelog format (Keep a Changelog standard)
+- **Categorization:** Group changes appropriately (Added, Changed, Fixed, Security, etc.)
 - **Breaking Changes:** Clearly mark breaking changes
 - **Migration Guides:** Provide migration guidance for breaking changes
+- **Version Dating:** Include release dates in consistent format (YYYY-MM-DD)
 
-## Code Documentation
+## Code Documentation Standards
 
-- **JSDoc Comments:** Update JSDoc comments when changing public APIs
-- **Inline Comments:** Add comments for complex logic, not obvious code
+Refer to language-specific coding instruction files for detailed code documentation standards:
+
+- **TypeScript/Node.js:** See `typescript.coding.instructions.md` for JSDoc standards
+- **Python:** See `python.coding.instructions.md` for docstring standards
+- **React/Frontend:** See `react.coding.instructions.md` for component documentation
+
+### Universal Code Documentation Principles
+
+- **Public APIs:** Always document public interfaces with appropriate documentation format
+- **Complex Logic:** Add comments for complex algorithms or business logic
 - **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
+- **Error Conditions:** Document when and why functions might fail
+- **Usage Examples:** Provide examples for non-trivial usage patterns
 
 ## API Documentation
 
-- **Endpoint Documentation:** Keep API endpoint documentation current
+- **Endpoint Documentation:** Keep API endpoint documentation current with implementation
 - **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
+- **Versioning:** Document API versioning strategy and compatibility
 
 ## 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
+- **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
@@ -149,15 +155,16 @@ This project enforces a strict distinction between different types of documentat
 
 ## Code Examples and Tutorials
 
-- **Working Examples:** Ensure all code examples compile and run
+- **Working Examples:** Ensure all code examples compile and run in the target language
 - **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
+- **Error Handling:** Show proper error handling patterns for the language
 - **Best Practices:** Demonstrate best practices in example code
+- **Language Appropriateness:** Use idiomatic patterns for each language
 
 ## Test Documentation Standards
 
-Follow the standardized table format for all test case documentation:
+Follow the standardized table format for all test case documentation across all project types:
 
 ### Required Table Format
 
@@ -170,7 +177,7 @@ Follow the standardized table format for all test case documentation:
 ### Test Case ID Conventions
 
 - **Format:** `[AREA]-[TYPE]-[NUMBER]`
-- **Area Prefixes (Python/Django):** VIEW, MODEL, FORM, MW, AUTH, UTIL, CMD, CONFIG, DOC, E2E, INT
+- **Area Prefixes:** Adapt to your project (CORE, API, UI, DB, AUTH, UTIL, CONFIG, DOC, etc.)
 - **Type Suffixes:** UNIT, INT, E2E
 - **Sequential Numbering:** 001, 002, 003, etc.
 
@@ -178,15 +185,18 @@ Follow the standardized table format for all test case documentation:
 
 - **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")
+- **Clear Headers:** Use descriptive section headers for test groups
 - **Status Tracking:** Use simple status values: "Completed", "In Progress", "Not Started"
+- **Descriptive Test Cases:** Provide clear, concise descriptions for each test case
+- **Text only** Don't use emojis or bold text in the table - keep it simple and readable
 
-### Documentation Testing
+## Documentation Testing
 
-- **Link Checking:** Regularly verify all links work
-- **Code Testing:** Test all code examples in documentation
+- **Link Checking:** Regularly verify all links work across all documentation
+- **Code Testing:** Test all code examples in documentation using appropriate tools
 - **Installation Testing:** Verify installation instructions work in clean environment
-- **User Testing:** Occasionally have someone unfamiliar try following docs
+- **User Testing:** Occasionally have someone unfamiliar try following documentation
+- **Cross-Platform Testing:** Verify instructions work across supported platforms
 
 ## Maintenance Schedule
 
@@ -194,10 +204,13 @@ Follow the standardized table format for all test case documentation:
 - **Release Updates:** Update documentation as part of release process
 - **Issue Tracking:** Track documentation issues and improvements
 - **Community Feedback:** Incorporate user feedback on documentation clarity
+- **Automated Checks:** Use automated tools to check for broken links and outdated content
 
-## Localization Considerations
+## Localization and Accessibility
 
-- **Clear English:** Use clear, simple English for international audiences
+- **Clear Language:** Use clear, simple language for international audiences
 - **Cultural Sensitivity:** Avoid culture-specific references
 - **Technical Terms:** Define technical terms when first introduced
-- **Consistent Terminology:** Use consistent terminology throughout
+- **Consistent Terminology:** Use consistent terminology throughout all documentation
+- **Screen Reader Compatibility:** Ensure proper heading hierarchy and alt text
+- **High Contrast:** Use sufficient color contrast for accessibility

package/templates/general/release.instructions.md

@@ -0,0 +1,242 @@
+---
+description: 'Universal release process for all project types'
+applyTo: 'package.json,setup.py,pyproject.toml,Cargo.toml'
+---
+
+# Universal Release Process Guidelines
+
+## Pre-Release Validation
+
+### Code Quality Verification
+
+1. **Test Suite:** Verify all tests pass using project-appropriate test runner
+2. **Build Verification:** Ensure clean build without errors using project build system
+3. **Linting:** Check code quality standards using project linter configuration
+4. **Dependencies:** Review and update dependencies if needed
+5. **Security Audit:** Run security audit using language-appropriate tools
+
+### Language-Specific Pre-Release Steps
+
+For detailed language-specific release steps, refer to:
+
+- **TypeScript/Node.js:** `npm test`, `npm run build`, `npm audit`
+- **Python:** `pytest`, `python -m build`, `pip-audit` or `safety check`
+- **React/Frontend:** `npm test`, `npm run build`, `npm run lint`
+
+## Version Management
+
+### Semantic Versioning
+
+Follow SemVer (Semantic Versioning) principles across all project types:
+
+- **MAJOR (X.0.0):** Breaking changes that require user action
+- **MINOR (0.X.0):** New features that are backward compatible
+- **PATCH (0.0.X):** Bug fixes that are backward compatible
+
+### Version Consistency
+
+1. **Primary Version File:** Update version in main project file:
+   - Node.js: `package.json`
+   - Python: `setup.py`, `pyproject.toml`, or `__version__.py`
+   - Rust: `Cargo.toml`
+   - Other languages: Follow language conventions
+2. **Cross-File Consistency:** Ensure version matches across all relevant files
+3. **Breaking Changes:** Document breaking changes prominently in changelog
+
+## Documentation Updates
+
+### README.md Updates
+
+1. **Version Badges:** Update version badges to match project version
+2. **Installation Instructions:** Refresh installation instructions if needed
+3. **Feature Descriptions:** Update feature descriptions for new capabilities
+4. **Link Verification:** Verify all links and examples work correctly
+5. **Language-Specific Updates:** Update language-specific installation commands
+
+### API Documentation
+
+- **Interface Changes:** Update API documentation for any interface changes
+- **Compatibility Notes:** Document backward compatibility information
+- **Migration Guides:** Provide migration guidance for breaking changes
+
+## Changelog Management
+
+### Entry Structure
+
+Create new section in CHANGELOG.md with:
+
+1. **Release Header:** Version number matching project version file
+2. **Release Date:** Date in YYYY-MM-DD format
+3. **Grouped Changes:** Organize by standard categories:
+   - **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
+
+### Entry Guidelines
+
+- **User Impact Focus:** Write from user perspective, not technical implementation
+- **Descriptive but Brief:** 1-2 lines per change explaining user impact
+- **Issue References:** Include issue/PR numbers when applicable: `(#123)`
+- **Breaking Changes:** Highlight with ⚠️ or **BREAKING:** prefix
+- **Migration Information:** Include migration steps for breaking changes
+
+## Git Operations
+
+### Commit and Tagging
+
+1. **Stage Changes:** Add all release-related changes (version files, changelog, docs)
+2. **Commit Message:** Use consistent format: `chore: bump version to vX.Y.Z`
+3. **Create Tag:** Tag the commit with version:
+   - Git: `git tag vX.Y.Z`
+   - Follow project conventions for tag naming
+4. **Push Changes:** Push commits and tags: `git push && git push --tags`
+
+### Branch Management
+
+- **Release Branches:** Use release branches for complex release processes
+- **Hotfix Handling:** Follow established branching strategy for hotfixes
+- **Merge Strategy:** Use consistent merge strategy (merge commits vs. squash)
+
+## Platform-Specific Release Steps
+
+### Package Registry Publishing
+
+**Node.js/npm:**
+
+```bash
+npm publish
+# Or for scoped packages: npm publish --access public
+```
+
+**Python/PyPI:**
+
+```bash
+python -m build
+twine upload dist/*
+```
+
+**GitHub Releases:**
+
+1. **Create Release:** Create GitHub release with tag matching project version
+2. **Release Title:** Use format: `vX.Y.Z - [Brief description]`
+3. **Release Notes:** Copy relevant sections from CHANGELOG.md
+4. **Asset Uploads:** Include built artifacts if applicable
+
+### Registry-Specific Considerations
+
+- **Package Validation:** Verify package content before publishing
+- **Permissions:** Ensure proper publishing permissions are configured
+- **Registry Status:** Check target registry availability before publishing
+
+## Post-Release Verification
+
+### Publication Verification
+
+1. **Registry Confirmation:** Verify package published correctly to target registry
+2. **Installation Test:** Test installation from registry in clean environment
+3. **Version Verification:** Confirm published version matches expected version
+4. **Metadata Check:** Verify package metadata is correct
+
+### Documentation and Communication
+
+1. **Documentation Links:** Ensure all documentation links work correctly
+2. **Update Notifications:** Notify relevant stakeholders of release
+3. **Community Communication:** Post to relevant community channels if applicable
+4. **Monitor Issues:** Watch for immediate issues reported by users
+
+## Release Monitoring
+
+### Immediate Post-Release
+
+- **Download/Install Metrics:** Monitor initial adoption metrics
+- **Error Monitoring:** Watch for error reports from new version
+- **User Feedback:** Monitor support channels for user feedback
+- **Dependency Issues:** Watch for reports of dependency conflicts
+
+### Issue Response
+
+- **Rapid Response:** Establish process for rapid response to critical issues
+- **Hotfix Process:** Have clear process for emergency hotfixes
+- **Communication Plan:** Prepare communication strategy for critical issues
+- **Rollback Preparedness:** Know how to rollback if necessary
+
+## Rollback and Emergency Procedures
+
+### Rollback Planning
+
+- **Git Revert:** Know how to revert problematic releases
+- **Registry Management:** Understand registry policies for unpublishing
+- **User Communication:** Prepare communication strategy for rollbacks
+- **Data Migration:** Plan for any data migration rollbacks if applicable
+
+### Emergency Release Process
+
+- **Hotfix Workflow:** Streamlined process for critical security fixes
+- **Testing Requirements:** Minimum testing requirements for emergency releases
+- **Approval Process:** Expedited approval process for critical fixes
+- **Communication Protocol:** Emergency communication procedures
+
+## Release Automation
+
+### CI/CD Integration
+
+- **Automated Testing:** All tests must pass before release
+- **Automated Building:** Automated build process for release artifacts
+- **Automated Publishing:** Consider automated publishing for appropriate project types
+- **Release Notes Generation:** Automate generation of release notes from changelog
+
+### Quality Gates
+
+- **Test Coverage:** Minimum test coverage requirements
+- **Security Scanning:** Automated security vulnerability scanning
+- **Dependency Auditing:** Automated dependency security auditing
+- **Performance Benchmarks:** Performance regression testing
+
+## Multi-Language Project Considerations
+
+### Coordinated Releases
+
+- **Version Synchronization:** Keep versions synchronized across language components
+- **Testing Integration:** Test all language components together
+- **Documentation Coordination:** Ensure documentation covers all language components
+- **Compatibility Matrix:** Document compatibility between different language versions
+
+### Release Coordination
+
+- **Release Orchestration:** Coordinate release timing across components
+- **Dependency Management:** Manage dependencies between language components
+- **Testing Strategy:** Test integration between language components
+- **Communication:** Coordinate communication across different language communities
+
+## Compliance and Legal
+
+### License Compliance
+
+- **License Verification:** Ensure all dependencies comply with project license
+- **License Updates:** Update license information for new dependencies
+- **Attribution:** Provide proper attribution for third-party components
+
+### Security and Privacy
+
+- **Security Review:** Review security implications of changes
+- **Privacy Impact:** Assess privacy impact of new features
+- **Compliance Requirements:** Meet relevant compliance requirements (GDPR, HIPAA, etc.)
+
+## Release Metrics and Analytics
+
+### Success Metrics
+
+- **Adoption Rate:** Track adoption of new version
+- **Error Rate:** Monitor error rates in new version
+- **Performance Metrics:** Track performance of new version
+- **User Satisfaction:** Gather user feedback on new features
+
+### Continuous Improvement
+
+- **Release Retrospectives:** Conduct retrospectives after major releases
+- **Process Refinement:** Continuously improve release process
+- **Tool Evaluation:** Regularly evaluate and improve release tooling
+- **Documentation Updates:** Keep release documentation current with process changes

package/templates/general/test-runner.instructions.md

@@ -0,0 +1,188 @@
+---
+description: 'Universal testing guidelines and workflow for all project types'
+applyTo: 'test/**/*'
+---
+
+# Universal Test Execution Guidelines
+
+## Pre-Commit Testing Workflow
+
+- **Run all tests before committing changes:** Use project-appropriate test command
+- **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**
+- **Verify test coverage meets project standards**
+
+## 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 standardized table format in `test/test-documentation.md` for all test cases
+- **Test Organization:** Group related tests with clear hierarchy and descriptive names
+- **Language-Specific Patterns:** Follow testing patterns appropriate for the project language
+
+## Language-Specific Testing Guidelines
+
+For detailed testing frameworks and patterns, refer to language-specific instruction files:
+
+- **TypeScript/Node.js:** See `typescript.coding.instructions.md` for Jest patterns and best practices
+- **Python:** See `python.coding.instructions.md` for pytest patterns and fixtures
+- **React/Frontend:** See `react.coding.instructions.md` for React Testing Library and component testing
+
+## Test Case Documentation Format
+
+All test cases must be documented using the standardized table format across all project types:
+
+```markdown
+| Test Case ID  | Description                                 | Type | Status    |
+| :------------ | :------------------------------------------ | :--- | :-------- |
+| AREA-TYPE-001 | Brief but descriptive test case description | Unit | Completed |
+```
+
+## Universal Test Case Naming Conventions
+
+### Test Case ID Format: `[AREA]-[TYPE]-[NUMBER]`
+
+**Area Prefixes (adapt to your project):**
+
+- `CORE` - Core application logic tests
+- `API` - API/Service layer tests
+- `UI` - User interface component tests
+- `DB` - Database/Data layer tests
+- `AUTH` - Authentication/Authorization 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 (isolated component testing)
+- `INT` - Integration tests (component interaction testing)
+- `E2E` - End-to-end tests (full workflow testing)
+
+**Examples:**
+
+- `CORE-UNIT-001` - First unit test for Core Logic
+- `API-UNIT-001` - First unit test for API Layer
+- `DB-INT-001` - First integration test for Database
+- `E2E-WF-001` - First end-to-end workflow test
+
+### Test Method Naming
+
+Use language-appropriate naming conventions:
+
+- **TypeScript/JavaScript:** `methodName_scenario_expectedOutcome`
+- **Python:** `test_method_name_scenario_expected_outcome`
+- **Consistent Pattern:** Always include what's being tested, the scenario, and expected result
+
+## 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 Environment:** Use separate test environment/database 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 output 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
+- **Documentation Updates:** Remove temporary test documentation and move useful content to proper locations
+
+## Test Types and Patterns
+
+### Unit Tests
+
+- **Purpose:** Test individual functions, methods, and components in isolation
+- **Scope:** Single unit of functionality
+- **Dependencies:** Mock all external dependencies
+- **Speed:** Fast execution (milliseconds per test)
+- **Coverage:** Focus on logic branches and edge cases
+
+### Integration Tests
+
+- **Purpose:** Test feature workflows and component interactions
+- **Scope:** Multiple components working together
+- **Dependencies:** Use real implementations where practical
+- **Speed:** Moderate execution time
+- **Coverage:** Focus on interface contracts and data flow
+
+### End-to-End Tests
+
+- **Purpose:** Test complete user scenarios and workflows
+- **Scope:** Full application stack
+- **Dependencies:** Real or production-like environment
+- **Speed:** Slower execution time
+- **Coverage:** Focus on user journeys and critical paths
+
+## Performance Testing
+
+- **Test Execution Speed:** Keep unit tests fast (language-specific timing guidelines in coding instructions)
+- **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
+- **CI/CD Optimization:** Consider test execution time in continuous integration
+
+## 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.)
+
+## Cross-Platform Testing Considerations
+
+- **Environment Consistency:** Ensure tests pass across development environments
+- **Path Handling:** Use appropriate path handling for different operating systems
+- **Dependency Versions:** Account for version differences across environments
+- **Resource Availability:** Handle different resource constraints across platforms
+
+## Test Automation and CI/CD
+
+- **Automated Test Execution:** All tests must run automatically in CI/CD pipeline
+- **Test Result Reporting:** Generate and store test reports for analysis
+- **Failure Notification:** Immediate notification for test failures
+- **Coverage Reporting:** Track and report test coverage over time
+- **Quality Gates:** Use test results as quality gates for deployments
+
+## Security Testing
+
+- **Input Validation Testing:** Test with malicious and edge-case inputs
+- **Authentication Testing:** Verify authentication mechanisms work correctly
+- **Authorization Testing:** Ensure proper access controls
+- **Data Protection Testing:** Verify sensitive data handling
+- **Vulnerability Testing:** Include security-focused test cases
+
+## Error Handling and Edge Case Testing
+
+- **Boundary Conditions:** Test at the edges of valid input ranges
+- **Error Scenarios:** Test error handling and recovery mechanisms
+- **Network Failures:** Test behavior during network connectivity issues
+- **Resource Exhaustion:** Test behavior under resource constraints
+- **Invalid Input:** Test with malformed or unexpected input data
+
+## Test Documentation and Reporting
+
+- **Test Case Purpose:** Document why each test exists and what it validates
+- **Test Setup Requirements:** Document any special setup or configuration needed
+- **Known Issues:** Document known test limitations or flaky behaviors
+- **Test Metrics:** Track test execution time, coverage, and success rates
+- **Regular Reporting:** Generate regular test health reports
+
+## Best Practices for Test Development
+
+- **Test Independence:** Each test should be able to run independently
+- **Descriptive Names:** Use clear, descriptive names for tests and test groups
+- **Single Assertion Focus:** Each test should focus on one specific behavior
+- **Arrange-Act-Assert Pattern:** Structure tests with clear setup, execution, and validation phases
+- **Test Data Isolation:** Avoid test data conflicts between different test runs
+- **Maintainable Tests:** Write tests that are easy to understand and modify