metacoding 1.0.0 → 1.1.0

package/templates/react/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 (React/Frontend):** COMP, HOOK, PAGE, STORE, API, UTIL, AUTH, FORM, 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/react/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/react/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 (React/Frontend specific):**
-
-- `COMP` - React component tests
-- `HOOK` - Custom hooks tests
-- `PAGE` - Page/Route component tests
-- `STORE` - State management tests (Redux/Zustand)
-- `API` - API service layer tests
-- `UTIL` - Utility function tests
-- `AUTH` - Authentication flow tests
-- `FORM` - Form validation 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:**
-
-- `COMP-UNIT-001` - First unit test for React Components
-- `HOOK-UNIT-001` - First unit test for Custom Hooks
-- `API-INT-001` - First integration test for API Services
-- `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.)