@codemcp/workflows-core 3.1.22 → 3.2.0

package/resources/templates/architecture/c4.md

@@ -0,0 +1,224 @@
+# System Architecture Documentation (C4 Model)
+
+_This document follows the C4 model for software architecture documentation, focusing on Context, Container, and Component levels._
+
+## 1. System Context (C4 Level 1)
+
+### System Overview
+
+<!-- Brief description of what the system does and its primary purpose -->
+
+### Users and Personas
+
+<!-- Who uses this system? -->
+
+- **[User Type 1]**: Description of user type and their needs
+- **[User Type 2]**: Description of user type and their needs
+
+### External Systems
+
+<!-- What external systems does this system interact with? -->
+
+- **[External System 1]**: Purpose and interaction type
+- **[External System 2]**: Purpose and interaction type
+
+### System Boundaries
+
+<!-- What is inside vs outside the system boundary? -->
+
+- **Inside the system**:
+- **Outside the system**:
+
+### Context Diagram
+
+<!-- Describe or reference a C4 Context diagram showing the system and its environment -->
+
+## 2. Container Architecture (C4 Level 2)
+
+### Container Overview
+
+<!-- High-level containers that make up the system -->
+
+#### [Container Name 1]
+
+- **Technology**:
+- **Responsibilities**:
+- **Interfaces**:
+- **Data Storage**:
+
+#### [Container Name 2]
+
+- **Technology**:
+- **Responsibilities**:
+- **Interfaces**:
+- **Data Storage**:
+
+### Container Interactions
+
+<!-- How do containers communicate with each other? -->
+
+- **[Container A] → [Container B]**: Communication method and purpose
+- **[Container B] → [External System]**: Communication method and purpose
+
+### Deployment Architecture
+
+<!-- How are containers deployed? -->
+
+- **Environment**:
+- **Infrastructure**:
+- **Scaling**:
+
+### Container Diagram
+
+<!-- Describe or reference a C4 Container diagram showing the containers and their relationships -->
+
+## 3. Component Architecture (C4 Level 3)
+
+### Component Analysis by Container
+
+#### [Container Name 1] Components
+
+##### [Component Name 1]
+
+- **Responsibilities**:
+- **Interfaces**:
+- **Dependencies**:
+- **Design Patterns**:
+
+##### [Component Name 2]
+
+- **Responsibilities**:
+- **Interfaces**:
+- **Dependencies**:
+- **Design Patterns**:
+
+#### [Container Name 2] Components
+
+##### [Component Name 3]
+
+- **Responsibilities**:
+- **Interfaces**:
+- **Dependencies**:
+- **Design Patterns**:
+
+### Component Interactions
+
+<!-- How do components within containers interact? -->
+
+- **[Component A] → [Component B]**: Interaction type and purpose
+- **[Component C] → [External Interface]**: Interaction type and purpose
+
+### Component Diagrams
+
+<!-- Describe or reference C4 Component diagrams for each significant container -->
+
+## 4. Architecture Decisions
+
+### Key Architectural Decisions
+
+<!-- Important architectural decisions made during analysis -->
+
+#### Decision 1: [Decision Title]
+
+- **Context**:
+- **Decision**:
+- **Rationale**:
+- **Consequences**:
+
+#### Decision 2: [Decision Title]
+
+- **Context**:
+- **Decision**:
+- **Rationale**:
+- **Consequences**:
+
+### Technology Choices
+
+<!-- Why were specific technologies chosen? -->
+
+- **[Technology 1]**: Rationale for choice
+- **[Technology 2]**: Rationale for choice
+
+## 5. Quality Attributes
+
+### Performance Characteristics
+
+<!-- How does the system perform? -->
+
+- **Response Times**:
+- **Throughput**:
+- **Scalability**:
+
+### Security Considerations
+
+<!-- What security measures are in place? -->
+
+- **Authentication**:
+- **Authorization**:
+- **Data Protection**:
+
+### Reliability and Availability
+
+<!-- How reliable is the system? -->
+
+- **Uptime Requirements**:
+- **Error Handling**:
+- **Recovery Mechanisms**:
+
+## 6. Enhancement Recommendations
+
+### Modernization Opportunities
+
+<!-- Based on the analysis, what modernization opportunities exist? -->
+
+- **[Opportunity 1]**: Description and benefits
+- **[Opportunity 2]**: Description and benefits
+
+### Technical Debt
+
+<!-- What technical debt was identified? -->
+
+- **[Debt Item 1]**: Impact and recommended resolution
+- **[Debt Item 2]**: Impact and recommended resolution
+
+### API Testing Strategy
+
+<!-- Recommendations for end-to-end API testing -->
+
+- **External APIs**: Testing approach for external interfaces
+- **Internal APIs**: Testing approach for internal interfaces
+- **Test Data**: Strategy for test data management
+
+### Enhancement Readiness
+
+<!-- How ready is the system for enhancements? -->
+
+- **Documentation Quality**:
+- **Code Quality**:
+- **Test Coverage**:
+- **Development Environment**:
+
+## 7. References and Resources
+
+### Discovery Notes
+
+- Reference to DISCOVERY.md file with detailed analysis notes
+
+### Existing Documentation
+
+<!-- Links to any existing documentation that was found -->
+
+- **[Document 1]**: Description and relevance
+- **[Document 2]**: Description and relevance
+
+### Analysis Artifacts
+
+<!-- Other artifacts created during the analysis -->
+
+- **Component Analysis**: Detailed component analysis notes
+- **Interface Documentation**: API and interface specifications
+- **Data Flow Diagrams**: Data flow analysis results
+
+---
+
+_This architecture documentation was created through systematic legacy system analysis using the C4 methodology. It provides the foundation for coherent system enhancements and modernization efforts._

package/resources/templates/architecture/freestyle.md

@@ -0,0 +1,53 @@
+<!--
+INSTRUCTIONS FOR ARCHITECTURE DOCUMENT (FREESTYLE):
+- Document high-level system architecture and context
+- Focus on system boundaries, external interfaces, and key components
+- Include technology decisions with rationale
+- Keep it concise but comprehensive enough for new team members
+- Update as architecture evolves during development
+-->
+
+# Architecture Document
+
+## System Overview
+
+<!-- Brief description of what the system does and its main purpose -->
+
+## System Context
+
+<!-- External systems, users, and interfaces this system interacts with -->
+
+## High-Level Architecture
+
+<!-- Main components and how they interact, architectural patterns used -->
+
+## Technology Decisions
+
+<!-- Key technology choices with brief rationale -->
+
+- **[Technology Area]:** [Choice] - [Rationale]
+
+## Key Components
+
+<!-- Core components and their responsibilities -->
+
+### [Component Name]
+
+- **Purpose:** [What it does]
+- **Key Interfaces:** [How other components interact with it]
+
+## Data Flow
+
+<!-- How data moves through the system -->
+
+## Deployment Architecture
+
+<!-- How the system is deployed and scaled -->
+
+## Security Architecture
+
+<!-- Security boundaries, authentication, authorization patterns -->
+
+## Quality Attributes
+
+<!-- Performance, scalability, reliability, maintainability considerations -->

package/resources/templates/architecture/none.md

@@ -0,0 +1,17 @@
+# Architecture Placeholder
+
+This is a placeholder document. The user has chosen not to maintain separate architecture documentation for this project.
+
+## INSTRUCTIONS FOR LLM
+
+**DO NOT EDIT THIS FILE**
+
+- Use the current development plan file to specify architecture decisions for ongoing development
+- Reference architecture information from the plan file context when needed
+- Focus architecture discussion in the plan file's "Key Decisions" and "Notes" sections
+- When architecture decisions are needed, document them in the plan file rather than here
+- This placeholder ensures the workflow variables work correctly while respecting the user's choice
+
+## User's Choice
+
+The user has explicitly chosen not to use dedicated architecture documentation for this project. Please respect this decision and work with the plan file for architecture-related information.

package/resources/templates/design/comprehensive.md

@@ -0,0 +1,207 @@
+<!--
+DESIGN DOCUMENT TEMPLATE - TIERED BY PROJECT COMPLEXITY
+
+PURPOSE: Document design principles, patterns, and standards that guide implementation.
+NOTE: Technology stack decisions belong in the Architecture Document, not here.
+
+PROJECT COMPLEXITY GUIDE:
+🚀 ESSENTIAL (Startup/MVP, 1-3 developers, <6 months): Sections 1-2 only
+🏢 CORE (Small team, 2-5 developers, 6-18 months): Sections 1-4
+🏗️ ADVANCED (Enterprise, 5+ developers, 18+ months): Sections 1-5
+⚡ SPECIALIZED (Mission-critical, high reliability): All sections + custom
+
+WHAT TO INCLUDE:
+✅ Design principles and patterns
+✅ Naming conventions and standards
+✅ Component design approaches
+✅ Data modeling principles
+✅ Quality attribute design strategies
+❌ Technology stack choices (goes in Architecture doc)
+❌ Concrete class names or implementations
+❌ Code snippets or method signatures
+
+START SMALL: Begin with Essential sections, add more as project matures.
+
+IMPORTANT: DO NOT REMOVE THIS COMMENT HOW TO USE THE TEMPLATE!
+-->
+
+# Design Document
+
+<!-- # 🚀 ESSENTIAL - Required for all projects -->
+
+## 1. Naming Conventions
+
+<!-- Standards for naming classes, methods, variables, constants, packages
+     Language-specific conventions and project-specific additions
+     Examples: PascalCase for classes, camelCase for methods, etc. -->
+
+### Classes and Types
+
+<!-- How to name classes, interfaces, enums, type definitions -->
+
+### Methods and Functions
+
+<!-- Method naming patterns, verb conventions, parameter naming -->
+
+### Variables and Constants
+
+<!-- Local variables, class fields, constants, configuration values -->
+
+### Packages and Modules
+
+<!-- Package/namespace organization, module naming patterns -->
+
+## 2. Error Handling Design
+
+<!-- Exception hierarchy design, error propagation strategies
+     How errors should be categorized, handled, and communicated
+     Principles for graceful degradation and error recovery -->
+
+### Exception Design Principles
+
+<!-- When to use checked vs unchecked exceptions, custom exception hierarchy -->
+
+### Error Propagation Strategy
+
+<!-- How errors flow through system layers, error boundaries -->
+
+### Error Recovery Patterns
+
+<!-- How system should behave when errors occur, fallback strategies -->
+
+<!-- # 🏢 CORE - Recommended for professional projects -->
+
+## 3. Architecture Patterns & Principles
+
+<!-- SOLID principles, DRY, KISS, YAGNI applied to this project
+     Which architectural patterns are preferred and why
+     Design pattern selection criteria and usage guidelines -->
+
+### Core Design Principles
+
+<!-- How SOLID, DRY, KISS principles apply to this specific project -->
+
+### Preferred Architectural Patterns
+
+<!-- Which patterns (MVC, Repository, Observer, etc.) to use when -->
+
+### Pattern Selection Guidelines
+
+<!-- Criteria for choosing between different design patterns -->
+
+## 4. Component Design Strategy
+
+<!-- How functionality is organized into components
+     Principles for component boundaries and responsibilities
+     Interface design and dependency management approaches -->
+
+### Component Boundary Principles
+
+<!-- How to determine what belongs in each component, separation of concerns -->
+
+### Responsibility Assignment
+
+<!-- How to distribute functionality across components -->
+
+### Interface Design Standards
+
+<!-- How components should expose functionality, API design principles -->
+
+### Dependency Management
+
+<!-- How components depend on each other, injection patterns -->
+
+<!-- # 🏗️ ADVANCED - For complex systems and mature teams -->
+
+## 5. Data Design Approach
+
+<!-- Domain modeling principles, entity design, data flow patterns
+     How data structures support business requirements
+     Consistency and integrity design strategies -->
+
+### Domain Modeling Principles
+
+<!-- How to model business concepts, entity vs value object decisions -->
+
+### Data Transfer Patterns
+
+<!-- DTOs, mapping between layers, data transformation strategies -->
+
+### Data Consistency Strategy
+
+<!-- How to maintain data integrity, transaction boundaries -->
+
+### Data Access Design
+
+<!-- Repository patterns, abstraction layers, query design -->
+
+## 6. Quality Attribute Implementation
+
+<!-- How design decisions support performance, security, maintainability
+     Trade-off analysis and quality attribute prioritization
+     Specific design strategies for quality goals -->
+
+### Performance Design Strategy
+
+<!-- How design choices impact performance, optimization approaches -->
+
+### Security Design Principles
+
+<!-- How security requirements influence design decisions -->
+
+### Maintainability Design Approach
+
+<!-- Design choices that support long-term maintenance and evolution -->
+
+### Scalability Design Considerations
+
+<!-- How design supports system growth and scaling -->
+
+<!-- # ⚡ SPECIALIZED - Add based on specific project needs -->
+
+## 7. Concurrency Design (If Applicable)
+
+<!-- Thread safety principles, synchronization strategies
+     Asynchronous processing patterns, concurrent data access -->
+
+### Thread Safety Strategy
+
+<!-- How to handle concurrent access, synchronization approaches -->
+
+### Asynchronous Processing Design
+
+<!-- Promise/Future patterns, event-driven design -->
+
+## 8. Testing Design Philosophy (If Complex Testing Needs)
+
+<!-- How design supports testability, test structure principles
+     Mocking strategies, test data management -->
+
+### Testability Design Principles
+
+<!-- How to design for effective testing, dependency injection for tests -->
+
+### Test Structure Standards
+
+<!-- Test organization, naming, assertion patterns -->
+
+## 9. Extension and Evolution Strategy (If Long-term Project)
+
+<!-- How design accommodates future changes
+     Extension points, plugin architectures, versioning strategies -->
+
+### Design for Change Principles
+
+<!-- How to create flexible designs that adapt to requirements -->
+
+### Extension Point Design
+
+<!-- Where and how to build extensibility into the system -->
+
+---
+
+# Implementation Notes
+
+<!-- Any project-specific notes about how these design principles should be applied
+     Exceptions or modifications to standard patterns
+     Team agreements about design trade-offs -->

package/resources/templates/design/freestyle.md

@@ -0,0 +1,37 @@
+<!--
+DESIGN DOCUMENT TEMPLATE - FREESTYLE APPROACH
+
+PURPOSE: Document design principles and standards in your preferred format.
+NOTE: Technology stack decisions belong in the Architecture Document, not here.
+
+DESIGN FOCUS AREAS:
+✅ Design principles and patterns that guide implementation
+✅ Naming conventions and coding standards
+✅ Component design approaches and boundaries
+✅ Data modeling and design principles
+✅ Quality attribute design strategies (performance, security, etc.)
+❌ NO Technology stack choices (goes in Architecture doc)
+❌ NO Concrete class names or implementations
+❌ NO Code snippets or method signatures
+
+TIERED APPROACH SUGGESTION:
+Start with core design principles, add complexity as project grows.
+Consider organizing by: Essential → Core → Advanced → Specialized sections.
+
+EXAMPLES:
+✅ GOOD: "Repository pattern abstracts data access with clean interfaces"
+✅ GOOD: "Components follow single responsibility principle with clear boundaries"
+✅ GOOD: "Error handling uses custom exception hierarchy for different failure types"
+❌ BAD: "PaymentController.processPayment() validates and processes transactions"
+❌ BAD: "UserService extends BaseService and implements AuthService interface"
+
+IMPORTANT: DO NOT REMOVE THIS COMMENT HOW TO USE THE TEMPLATE!
+-->
+
+# Design Document
+
+## Architecture Reference
+
+See [Architecture Document](./architecture.md) for high-level system context and architecture decisions such as chosen technologies and frameworks.
+
+<!-- Here goes your freestyle design -->

package/resources/templates/design/none.md

@@ -0,0 +1,17 @@
+# Design Placeholder
+
+This is a placeholder document. The user has chosen not to maintain separate design documentation for this project.
+
+## INSTRUCTIONS FOR LLM
+
+**DO NOT EDIT THIS FILE**
+
+- Use the current development plan file to specify design decisions for ongoing development
+- Reference design information from the plan file context when needed
+- Focus design discussion in the plan file's "Key Decisions" and implementation task sections
+- When design decisions are needed, document them in the plan file rather than here
+- This placeholder ensures the workflow variables work correctly while respecting the user's choice
+
+## User's Choice
+
+The user has explicitly chosen not to use dedicated design documentation for this project. Please respect this decision and work with the plan file for design-related information.

package/resources/templates/requirements/ears.md

@@ -0,0 +1,90 @@
+<!--
+INSTRUCTIONS FOR REQUIREMENTS (EARS FORMAT):
+- Use EARS format
+- Number requirements as REQ-1, REQ-2, etc.
+- Keep user stories concise and focused on user value
+- Make acceptance criteria specific and testable
+- Reference requirements in tasks using: (_Requirements: REQ-1, REQ-3_)
+
+EXAMPLE:
+## REQ-1: User Authentication
+**User Story:** As a website visitor, I want to create an account so that I can access personalized features.
+
+**Acceptance Criteria:**
+- WHEN user provides valid email and password THEN the system SHALL create new account
+- WHEN user provides duplicate email THEN the system SHALL show "email already exists" error
+- WHEN user provides weak password THEN the system SHALL show password strength requirements
+
+FULL EARS SYNTAX:
+While <optional pre-condition>, when <optional trigger>, the <system name> shall <system response>
+
+The EARS ruleset states that a requirement must have: Zero or many preconditions; Zero or one trigger; One system name; One or many system responses.
+
+The application of the EARS notation produces requirements in a small number of patterns, depending on the clauses that are used. The patterns are illustrated below.
+
+Ubiquitous requirements
+Ubiquitous requirements are always active (so there is no EARS keyword)
+
+The <system name> shall <system response>
+
+Example: The mobile phone shall have a mass of less than XX grams.
+
+State driven requirements
+State driven requirements are active as long as the specified state remains true and are denoted by the keyword While.
+
+While <precondition(s)>, the <system name> shall <system response>
+
+Example: While there is no card in the ATM, the ATM shall display “insert card to begin”.
+
+Event driven requirements
+Event driven requirements specify how a system must respond when a triggering event occurs and are denoted by the keyword When.
+
+When <trigger>, the <system name> shall <system response>
+
+Example: When “mute” is selected, the laptop shall suppress all audio output.
+
+Optional feature requirements
+Optional feature requirements apply in products or systems that include the specified feature and are denoted by the keyword Where.
+
+Where <feature is included>, the <system name> shall <system response>
+
+Example: Where the car has a sunroof, the car shall have a sunroof control panel on the driver door.
+
+Unwanted behavior requirements
+Unwanted behavior requirements are used to specify the required system response to undesired situations and are denoted by the keywords If and Then.
+
+If <trigger>, then the <system name> shall <system response>
+
+Example: If an invalid credit card number is entered, then the website shall display “please re-enter credit card details”.
+
+Complex requirements
+The simple building blocks of the EARS patterns described above can be combined to specify requirements for richer system behavior. Requirements that include more than one EARS keyword are called Complex requirements.
+
+While <precondition(s)>, When <trigger>, the <system name> shall <system response>
+
+Example: While the aircraft is on ground, when reverse thrust is commanded, the engine control system shall enable reverse thrust.
+
+Complex requirements for unwanted behavior also include the If-Then keywords.
+-->
+
+# Requirements Document
+
+## REQ-1: [First Requirement Title]
+
+**User Story:** As a [user type], I want [goal] so that [benefit].
+
+**Acceptance Criteria:**
+
+- WHEN [condition] THEN the system SHALL [expected behavior]
+- WHEN [condition] THEN the system SHALL [expected behavior]
+
+## REQ-2: [Second Requirement Title]
+
+**User Story:** As a [user type], I want [goal] so that [benefit].
+
+**Acceptance Criteria:**
+
+- WHEN [condition] THEN the system SHALL [expected behavior]
+- WHEN [condition] THEN the system SHALL [expected behavior]
+
+<!-- Add more requirements as REQ-3, REQ-4, etc. -->

package/resources/templates/requirements/freestyle.md

@@ -0,0 +1,42 @@
+<!--
+INSTRUCTIONS FOR REQUIREMENTS (FREESTYLE):
+- Document user needs and system requirements in any format that works for your project
+- Consider using user stories, use cases, or functional specifications
+- Make requirements specific and testable
+- Number or organize requirements for easy reference
+- Focus on what the system should do, not how it should do it
+-->
+
+# Requirements Document
+
+## Functional Requirements
+
+<!-- What the system should do -->
+
+### [Requirement Category]
+
+<!-- Group related requirements together -->
+
+## Non-Functional Requirements
+
+<!-- Performance, security, usability, etc. -->
+
+### Performance
+
+<!-- Response times, throughput, scalability requirements -->
+
+### Security
+
+<!-- Authentication, authorization, data protection requirements -->
+
+### Usability
+
+<!-- User experience, accessibility requirements -->
+
+## Business Rules
+
+<!-- Constraints and rules that govern system behavior -->
+
+## Assumptions and Dependencies
+
+<!-- External dependencies and assumptions made -->