@codemcp/workflows 5.3.0 → 6.0.2

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/game.md

@@ -0,0 +1,250 @@
+# Game Architecture 🏗️
+
+**Game**: [GAME_NAME]  
+**Platform**: [PLATFORM_CHOICE]  
+**Created**: [DATE]
+
+---
+
+## What This Document Is For
+
+This document explains the **BIG PICTURE** of your game:
+
+- What platform we're building on (Scratch? Browser? Python?)
+- What the main building blocks are
+- What each building block is responsible for
+- How they work together
+
+Think of it like planning with LEGO:
+
+- **Platform** = What type of LEGO we're using
+- **Building Blocks** = The main pieces we need
+- **Responsibilities** = What each piece does
+
+**No code, no files - just the big ideas!**
+
+---
+
+## Platform Decision
+
+<!-- LLM: Document the platform choice based on conversation with child -->
+
+**We chose [PLATFORM] because:**
+
+- [REASON_1]
+- [REASON_2]
+- [REASON_3]
+
+**Platform Options We Considered:**
+
+| Platform                       | Best For                   | Pros                                                  | Cons                       |
+| ------------------------------ | -------------------------- | ----------------------------------------------------- | -------------------------- |
+| **Scratch**                    | Total beginners, ages 8-10 | Visual blocks, can't make syntax errors, easy sharing | Less control over graphics |
+| **Browser (HTML5/JavaScript)** | Kids ready for "real" code | Works anywhere, full control, easy to share links     | Need to type carefully     |
+| **Python + Pygame**            | Kids who know Python       | Desktop games, powerful                               | Need to install Python     |
+
+---
+
+## The Big Picture
+
+<!-- LLM: Create a simple ASCII diagram showing main components and their relationships -->
+
+```
+┌─────────────────────────────────┐
+│      GAME MANAGER 🎮            │
+│   (The Boss - Runs Everything)  │
+└─────────────────────────────────┘
+              |
+              |
+    ┌─────────┴─────────┐
+    |                   |
+    v                   v
+┌─────────┐       ┌─────────┐
+│ PLAYER  │       │ ENEMIES │
+│  🧍     │       │  👾     │
+└─────────┘       └─────────┘
+    |                   |
+    └─────────┬─────────┘
+              v
+       ┌──────────────┐
+       │   DISPLAY    │
+       │   (Screen)   │
+       └──────────────┘
+```
+
+**How it works:**
+
+1. **Game Manager** is the boss - it controls everything
+2. **Player** and **Enemies** do their own things
+3. **Display** shows what's happening on screen
+4. Game Manager makes sure they all work together!
+
+---
+
+## Building Blocks
+
+<!-- LLM: For each building block, explain WHAT it does and its responsibilities.
+Keep it conceptual - no code examples, no specific implementation details.
+Focus on helping child understand the PURPOSE and ROLE of each block.
+Use simple analogies they can relate to. -->
+
+### 🎮 Game Manager
+
+The main controller that runs the whole game.
+
+**Responsibilities:**
+
+- Keeps the game running
+- Tells all the other parts when to do their jobs
+- Checks if the player won or lost
+- Keeps track of the score
+
+**Why we need it:**
+Every game needs someone in charge, like a referee in sports or a conductor in an orchestra.
+
+---
+
+### 🧍 Player
+
+The character the player controls in the game.
+
+**Responsibilities:**
+
+- Knows where it is in the game world
+- Remembers its health and score
+- Moves when the player presses keys
+- Checks if it touched something important
+
+**Why we need it:**
+This is YOU in the game! Without it, there's no way to play.
+
+---
+
+### 👾 Enemies
+
+The obstacles or challenges in the game.
+
+**Responsibilities:**
+
+- Knows where they are
+- Moves around in the game world
+- Checks if they touched the player
+- Makes the game challenging
+
+**Why we need it:**
+Games need challenges! Without enemies or obstacles, there's nothing to overcome.
+
+---
+
+### 🎯 [Additional Building Block]
+
+<!-- LLM: Add other building blocks based on the specific game type.
+Common examples:
+- Collectibles (coins, power-ups, items)
+- Projectiles (bullets, arrows, fireballs)
+- Obstacles (walls, platforms, hazards)
+- Level Manager (handles switching between levels)
+- Sound Manager (plays music and sound effects)
+- UI Manager (shows menus, buttons, messages)
+
+Keep each description simple and focused on responsibilities. -->
+
+[Describe building blocks specific to this game]
+
+---
+
+### 🖥️ Display
+
+Shows everything on the screen.
+
+**Responsibilities:**
+
+- Draws the player
+- Draws enemies and other game objects
+- Shows the score and health
+- Displays messages like "Game Over"
+
+**Why we need it:**
+We need to SEE what's happening! The display makes the invisible game visible.
+
+---
+
+## How They Work Together
+
+<!-- LLM: Explain the overall flow in simple terms. Focus on relationships, not implementation. -->
+
+Think of it like a team working together:
+
+**The Game Loop** (what happens over and over, very fast):
+
+1. **Game Manager** wakes everyone up: "Time to do your jobs!"
+2. **Player** checks if keys were pressed and moves
+3. **Enemies** move according to their patterns
+4. **Game Manager** asks: "Did anything touch anything?"
+   - Player hit enemy? → Player takes damage
+   - Player got coin? → Score goes up
+5. **Game Manager** asks **Display**: "Show what changed!"
+6. **Display** redraws everything on screen
+7. **Repeat!** This happens 60 times per second!
+
+**This is like a movie** - it happens so fast your eyes see smooth movement!
+
+---
+
+## Why Separate Into Building Blocks?
+
+Imagine your room:
+
+- **Messy**: Everything in one big pile - hard to find anything
+- **Organized**: Toys in toy box, books on shelf, clothes in closet - easy to find!
+
+**Same with games!**
+
+**All in one piece (BAD):**
+
+- Hard to understand
+- Hard to fix bugs
+- Hard to add new features
+- Confusing for everyone
+
+**Separated into building blocks (GOOD):**
+
+- Each block has ONE clear job
+- Easy to find where something happens
+- Easy to fix: "Enemy not moving? Check the Enemy block!"
+- Easy to add: "Want new enemy types? Make a new Enemy block!"
+
+**Professional game developers ALWAYS organize their games this way!**
+
+---
+
+## Key Decisions
+
+<!-- LLM: Document important architectural decisions in simple terms -->
+
+**Decision 1: [DECISION_TITLE]**
+
+- **What we decided**: [Simple explanation]
+- **Why**: [Reason in terms child understands]
+- **Impact**: [How this helps the game]
+
+**Decision 2: [DECISION_TITLE]**
+
+- **What we decided**: [Simple explanation]
+- **Why**: [Reason in terms child understands]
+- **Impact**: [How this helps the game]
+
+---
+
+## Remember
+
+**This is your game's blueprint!**
+
+- It shows WHO does WHAT
+- Each building block has its own job
+- They work together like a team
+- This is the BIG PICTURE - details come later!
+
+**Next**: Look at the Design document to see HOW to build each block with actual code! 🛠️
+
+Let's build something amazing! 🚀

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.