olympus-ai 4.5.13 → 4.5.14

package/resources/rules/common/terminology.md

@@ -1,189 +1,189 @@
-# AI-DLC Terminology Glossary
-
-## Core Terminology
-
-### Phase vs Stage
-
-**Phase**: One of the three high-level lifecycle phases in AI-DLC
-- 🔵 **INCEPTION PHASE** - Planning & Architecture (WHAT and WHY)
-- 🟢 **CONSTRUCTION PHASE** - Design, Implementation & Test (HOW)
-- 🟡 **OPERATIONS PHASE** - Deployment & Monitoring (future expansion)
-
-**Stage**: An individual workflow activity within a phase
-- Examples: Context Assessment stage, Requirements Assessment stage, Code Planning stage
-- Each stage has specific prerequisites, steps, and outputs
-- Stages can be ALWAYS-EXECUTE or CONDITIONAL
-
-**Usage Examples**:
-- ✅ "The CONSTRUCTION phase contains 7 stages"
-- ✅ "The Code Planning stage is always executed"
-- ✅ "We're in the INCEPTION phase, executing the Requirements Assessment stage"
-- ❌ "The Requirements Assessment phase" (should be "stage")
-- ❌ "The CONSTRUCTION stage" (should be "phase")
-
-## Three-Phase Lifecycle
-
-### INCEPTION PHASE
-**Purpose**: Planning and architectural decisions  
-**Focus**: Determine WHAT to build and WHY  
-**Location**: `inception/` directory
-
-**Stages**:
-- Workspace Detection (ALWAYS)
-- Reverse Engineering (CONDITIONAL - Brownfield only)
-- Requirements Analysis (ALWAYS - Adaptive depth)
-- User Stories (CONDITIONAL)
-- Workflow Planning (ALWAYS)
-- Units Generation (CONDITIONAL)
-
-**Outputs**: Requirements, user stories, architectural decisions, unit definitions
-
-### CONSTRUCTION PHASE
-**Purpose**: Detailed design and implementation  
-**Focus**: Determine HOW to build it  
-**Location**: `construction/` directory
-
-**Stages**:
-- Functional Design (CONDITIONAL, per-unit)
-- NFR Requirements (CONDITIONAL, per-unit)
-- NFR Design (CONDITIONAL, per-unit)
-- Infrastructure Design (CONDITIONAL, per-unit)
-- Code Planning (ALWAYS)
-- Code Generation (ALWAYS)
-- Build and Test (ALWAYS)
-
-**Outputs**: Design artifacts, NFR implementations, code, tests
-
-### OPERATIONS PHASE
-**Purpose**: Deployment and operational readiness  
-**Focus**: How to DEPLOY and RUN it  
-**Location**: `operations/` directory
-
-**Stages**:
-- Operations (PLACEHOLDER)
-
-**Outputs**: Build instructions, deployment guides, monitoring setup, verification procedures
-
----
-
-## Workflow Stages
-
-### Always-Execute Stages
-- **Workspace Detection**: Initial analysis of workspace state and project type
-- **Requirements Analysis**: Gathering requirements (depth varies based on complexity)
-- **Workflow Planning**: Creating execution plan for which phases to run
-- **Code Planning**: Creating detailed implementation plans for code generation
-- **Code Generation**: Generating actual code based on plans and prior artifacts
-- **Build and Test**: Building all units and executing comprehensive testing
-
-### Conditional Stages
-- **Reverse Engineering**: Analyzing existing codebase (brownfield projects only)
-- **User Stories**: Creating user stories and personas (includes Story Planning and Story Generation)
-- **Units Generation**: Decomposing the system into independent domain units
-- **Functional Design**: Technology-agnostic business logic design (per-unit)
-- **NFR Requirements**: Determining NFRs and selecting tech stack (per-unit)
-- **NFR Design**: Incorporating NFR patterns and logical components (per-unit)
-- **Infrastructure Design**: Mapping to actual infrastructure services (per-unit)
-
-## Domain Design Terms
-
-_Application Design stage was merged into Units Generation (INCEPTION phase)._
-
-- **Component**: A functional unit with specific responsibilities
-- **Method**: A function or operation within a component with defined business rules
-- **Business Rule**: Logic that governs method behavior and validation
-- **Service**: Orchestration layer that coordinates business logic across components
-- **Component Dependency**: Relationship and communication pattern between components
-
-## Architecture Terms (Infrastructure)
-
-### Unit of Work
-A logical grouping of user stories for development purposes. The term used during planning and decomposition.
-
-**Usage**: "We need to decompose the system into units of work"
-
-### Service
-An independently deployable component in a microservices architecture. Each service is a separate unit of work.
-
-**Usage**: "The Payment Service handles all payment processing"
-
-### Module
-A logical grouping of functionality within a single service or monolith. Modules are not independently deployable.
-
-**Usage**: "The authentication module within the User Service"
-
-### Component
-A reusable building block within a service or module. Components are classes, functions, or packages that provide specific functionality.
-
-**Usage**: "The EmailValidator component validates email addresses"
-
-## Terminology Guidelines
-
-### When to Use Each Term
-
-**Unit of Work**:
-- During Units Planning and Units Generation phases
-- When discussing system decomposition
-- In planning documents and discussions
-- Example: "How should we decompose this into units of work?"
-
-**Service**:
-- When referring to independently deployable components
-- In microservices architecture contexts
-- In deployment and infrastructure discussions
-- Example: "The Order Service will be deployed to ECS"
-
-**Module**:
-- When referring to logical groupings within a service
-- In monolith architecture contexts
-- When discussing internal organization
-- Example: "The reporting module generates all reports"
-
-**Component**:
-- When referring to specific classes, functions, or packages
-- In design and implementation discussions
-- When discussing reusable building blocks
-- Example: "The DatabaseConnection component manages connections"
-
-## Stage Terminology
-
-### Planning vs Generation
-- **Planning**: Creating a plan with questions and checkboxes for execution
-- **Generation**: Executing the plan to create artifacts
-
-Examples:
-- Story Planning → Story Generation
-- Units Planning → Units Generation
-- Unit Design Planning → Unit Design Generation
-- NFR Planning → NFR Generation
-- Code Planning → Code Generation
-
-### Depth Levels
-- **Minimal**: Quick, focused execution for simple changes
-- **Standard**: Normal depth with standard artifacts for typical projects
-- **Comprehensive**: Full depth with all artifacts for complex/high-risk projects
-
-## Artifact Types
-
-### Plans
-Documents with checkboxes and questions that guide execution.
-- Located in `aidlc-docs/plans/`
-- Examples: `story-generation-plan.md`, `unit-of-work-plan.md`
-
-### Artifacts
-Generated outputs from executing plans.
-- Located in various `aidlc-docs/` subdirectories
-- Examples: `requirements.md`, `stories.md`, `design.md`
-
-### State Files
-Files tracking workflow progress and status.
-- `aidlc-state.md`: Overall workflow state
-- `audit.md`: Complete audit trail of all interactions
-
-## Common Abbreviations
-
-- **AI-DLC**: AI-Driven Development Life Cycle
-- **NFR**: Non-Functional Requirements
-- **UOW**: Unit of Work
-- **API**: Application Programming Interface
-- **CDK**: Cloud Development Kit (AWS)
+# AI-DLC Terminology Glossary
+
+## Core Terminology
+
+### Phase vs Stage
+
+**Phase**: One of the three high-level lifecycle phases in AI-DLC
+- 🔵 **INCEPTION PHASE** - Planning & Architecture (WHAT and WHY)
+- 🟢 **CONSTRUCTION PHASE** - Design, Implementation & Test (HOW)
+- 🟡 **OPERATIONS PHASE** - Deployment & Monitoring (future expansion)
+
+**Stage**: An individual workflow activity within a phase
+- Examples: Context Assessment stage, Requirements Assessment stage, Code Planning stage
+- Each stage has specific prerequisites, steps, and outputs
+- Stages can be ALWAYS-EXECUTE or CONDITIONAL
+
+**Usage Examples**:
+- ✅ "The CONSTRUCTION phase contains 7 stages"
+- ✅ "The Code Planning stage is always executed"
+- ✅ "We're in the INCEPTION phase, executing the Requirements Assessment stage"
+- ❌ "The Requirements Assessment phase" (should be "stage")
+- ❌ "The CONSTRUCTION stage" (should be "phase")
+
+## Three-Phase Lifecycle
+
+### INCEPTION PHASE
+**Purpose**: Planning and architectural decisions  
+**Focus**: Determine WHAT to build and WHY  
+**Location**: `inception/` directory
+
+**Stages**:
+- Workspace Detection (ALWAYS)
+- Reverse Engineering (CONDITIONAL - Brownfield only)
+- Requirements Analysis (ALWAYS - Adaptive depth)
+- User Stories (CONDITIONAL)
+- Workflow Planning (ALWAYS)
+- Units Generation (CONDITIONAL)
+
+**Outputs**: Requirements, user stories, architectural decisions, unit definitions
+
+### CONSTRUCTION PHASE
+**Purpose**: Detailed design and implementation  
+**Focus**: Determine HOW to build it  
+**Location**: `construction/` directory
+
+**Stages**:
+- Functional Design (CONDITIONAL, per-unit)
+- NFR Requirements (CONDITIONAL, per-unit)
+- NFR Design (CONDITIONAL, per-unit)
+- Infrastructure Design (CONDITIONAL, per-unit)
+- Code Planning (ALWAYS)
+- Code Generation (ALWAYS)
+- Build and Test (ALWAYS)
+
+**Outputs**: Design artifacts, NFR implementations, code, tests
+
+### OPERATIONS PHASE
+**Purpose**: Deployment and operational readiness  
+**Focus**: How to DEPLOY and RUN it  
+**Location**: `operations/` directory
+
+**Stages**:
+- Operations (PLACEHOLDER)
+
+**Outputs**: Build instructions, deployment guides, monitoring setup, verification procedures
+
+---
+
+## Workflow Stages
+
+### Always-Execute Stages
+- **Workspace Detection**: Initial analysis of workspace state and project type
+- **Requirements Analysis**: Gathering requirements (depth varies based on complexity)
+- **Workflow Planning**: Creating execution plan for which phases to run
+- **Code Planning**: Creating detailed implementation plans for code generation
+- **Code Generation**: Generating actual code based on plans and prior artifacts
+- **Build and Test**: Building all units and executing comprehensive testing
+
+### Conditional Stages
+- **Reverse Engineering**: Analyzing existing codebase (brownfield projects only)
+- **User Stories**: Creating user stories and personas (includes Story Planning and Story Generation)
+- **Units Generation**: Decomposing the system into independent domain units
+- **Functional Design**: Technology-agnostic business logic design (per-unit)
+- **NFR Requirements**: Determining NFRs and selecting tech stack (per-unit)
+- **NFR Design**: Incorporating NFR patterns and logical components (per-unit)
+- **Infrastructure Design**: Mapping to actual infrastructure services (per-unit)
+
+## Domain Design Terms
+
+_Application Design stage was merged into Units Generation (INCEPTION phase)._
+
+- **Component**: A functional unit with specific responsibilities
+- **Method**: A function or operation within a component with defined business rules
+- **Business Rule**: Logic that governs method behavior and validation
+- **Service**: Orchestration layer that coordinates business logic across components
+- **Component Dependency**: Relationship and communication pattern between components
+
+## Architecture Terms (Infrastructure)
+
+### Unit of Work
+A logical grouping of user stories for development purposes. The term used during planning and decomposition.
+
+**Usage**: "We need to decompose the system into units of work"
+
+### Service
+An independently deployable component in a microservices architecture. Each service is a separate unit of work.
+
+**Usage**: "The Payment Service handles all payment processing"
+
+### Module
+A logical grouping of functionality within a single service or monolith. Modules are not independently deployable.
+
+**Usage**: "The authentication module within the User Service"
+
+### Component
+A reusable building block within a service or module. Components are classes, functions, or packages that provide specific functionality.
+
+**Usage**: "The EmailValidator component validates email addresses"
+
+## Terminology Guidelines
+
+### When to Use Each Term
+
+**Unit of Work**:
+- During Units Planning and Units Generation phases
+- When discussing system decomposition
+- In planning documents and discussions
+- Example: "How should we decompose this into units of work?"
+
+**Service**:
+- When referring to independently deployable components
+- In microservices architecture contexts
+- In deployment and infrastructure discussions
+- Example: "The Order Service will be deployed to ECS"
+
+**Module**:
+- When referring to logical groupings within a service
+- In monolith architecture contexts
+- When discussing internal organization
+- Example: "The reporting module generates all reports"
+
+**Component**:
+- When referring to specific classes, functions, or packages
+- In design and implementation discussions
+- When discussing reusable building blocks
+- Example: "The DatabaseConnection component manages connections"
+
+## Stage Terminology
+
+### Planning vs Generation
+- **Planning**: Creating a plan with questions and checkboxes for execution
+- **Generation**: Executing the plan to create artifacts
+
+Examples:
+- Story Planning → Story Generation
+- Units Planning → Units Generation
+- Unit Design Planning → Unit Design Generation
+- NFR Planning → NFR Generation
+- Code Planning → Code Generation
+
+### Depth Levels
+- **Minimal**: Quick, focused execution for simple changes
+- **Standard**: Normal depth with standard artifacts for typical projects
+- **Comprehensive**: Full depth with all artifacts for complex/high-risk projects
+
+## Artifact Types
+
+### Plans
+Documents with checkboxes and questions that guide execution.
+- Located in `aidlc-docs/plans/`
+- Examples: `story-generation-plan.md`, `unit-of-work-plan.md`
+
+### Artifacts
+Generated outputs from executing plans.
+- Located in various `aidlc-docs/` subdirectories
+- Examples: `requirements.md`, `stories.md`, `design.md`
+
+### State Files
+Files tracking workflow progress and status.
+- `aidlc-state.md`: Overall workflow state
+- `audit.md`: Complete audit trail of all interactions
+
+## Common Abbreviations
+
+- **AI-DLC**: AI-Driven Development Life Cycle
+- **NFR**: Non-Functional Requirements
+- **UOW**: Unit of Work
+- **API**: Application Programming Interface
+- **CDK**: Cloud Development Kit (AWS)

package/resources/rules/common/welcome-message.md

@@ -1,118 +1,118 @@
-# AI-DLC Welcome Message
-
-**Purpose**: This file contains the user-facing welcome message that should be displayed ONCE at the start of any AI-DLC workflow.
-
----
-
-# 👋 Welcome to AI-DLC (AI-Driven Development Life Cycle)! 👋
-
-I'll guide you through an adaptive software development workflow that intelligently tailors itself to your specific needs.
-
-## What is AI-DLC?
-
-AI-DLC is a structured yet flexible software development process that adapts to your project's needs. Think of it as having an experienced software architect who:
-
-- **Analyzes your requirements** and asks clarifying questions when needed
-- **Plans the optimal approach** based on complexity and risk
-- **Skips unnecessary steps** for simple changes while providing comprehensive coverage for complex projects
-- **Documents everything** so you have a complete record of decisions and rationale
-- **Guides you through each phase** with clear checkpoints and approval gates
-
-## The Three-Phase Lifecycle
-
-```
-                         User Request
-                              |
-                              v
-        ╔═══════════════════════════════════════╗
-        ║     INCEPTION PHASE                   ║
-        ║     Planning & Application Design     ║
-        ╠═══════════════════════════════════════╣
-        ║ • Workspace Detection (ALWAYS)        ║
-        ║ • Reverse Engineering (COND)          ║
-        ║ • Requirements Analysis (ALWAYS)      ║
-        ║ • User Stories (CONDITIONAL)          ║
-        ║ • Workflow Planning (ALWAYS)          ║
-        ║ • Application Design (CONDITIONAL)    ║
-        ║ • Units Generation (CONDITIONAL)      ║
-        ╚═══════════════════════════════════════╝
-                              |
-                              v
-        ╔═══════════════════════════════════════╗
-        ║     CONSTRUCTION PHASE                ║
-        ║     Design, Implementation & Test     ║
-        ╠═══════════════════════════════════════╣
-        ║ • Per-Unit Loop (for each unit):      ║
-        ║   - Functional Design (COND)          ║
-        ║   - NFR Requirements Assess (COND)    ║
-        ║   - NFR Design (COND)                 ║
-        ║   - Infrastructure Design (COND)      ║
-        ║   - Unit → Bolt Decomposition         ║
-        ║                                       ║
-        ║ • Per-Bolt Loop (for each bolt):      ║
-        ║   - Elaboration (COND)                ║
-        ║   - Code Generation (ALWAYS)          ║
-        ║   - Build and Test (ALWAYS)           ║
-        ║   - Review (ALWAYS)                   ║
-        ║                                       ║
-        ║ • Final Build and Test (ALWAYS)       ║
-        ╚═══════════════════════════════════════╝
-                              |
-                              v
-        ╔═══════════════════════════════════════╗
-        ║     OPERATIONS PHASE                  ║
-        ║     Placeholder for Future            ║
-        ╠═══════════════════════════════════════╣
-        ║ • Operations (PLACEHOLDER)            ║
-        ╚═══════════════════════════════════════╝
-                              |
-                              v
-                          Complete
-```
-
-### Phase Breakdown:
-
-**INCEPTION PHASE** - *Planning & Application Design*
-- **Purpose**: Determines WHAT to build and WHY
-- **Activities**: Understanding requirements, analyzing existing code (if any), planning the approach
-- **Output**: Clear requirements, execution plan, decisions on the number of units of work for parallel development
-- **Your Role**: Answer questions, review plans, approve direction
-
-**CONSTRUCTION PHASE** - *Detailed Design, Implementation & Test*
-- **Purpose**: Determines HOW to build it
-- **Activities**: Detailed design (when needed), unit decomposition into bolts, per-bolt code generation and testing
-- **Output**: Working code, tests, build instructions
-- **Your Role**: Review designs, approve bolt plans, validate results
-
-> **What is a Bolt?** A bolt is the smallest unit of execution in AI-DLC — a focused implementation task (typically hours of work, not days). Each unit of work is decomposed into one or more bolts, and each bolt goes through its own lifecycle: **Elaboration** (detailed spec) → **Code Generation** → **Build and Test** → **Review**. Simple bolts run in *express mode*, skipping elaboration for faster delivery.
-
-**OPERATIONS PHASE** - *Deployment & Monitoring (Future)*
-- **Purpose**: How to DEPLOY and RUN it
-- **Status**: Placeholder for future deployment and monitoring workflows
-- **Current State**: Build and test activities handled in CONSTRUCTION phase
-
-## Key Principles:
-
-- ⚡ **Fully Adaptive**: Each stage independently evaluated based on your needs
-- 🎯 **Efficient**: Simple changes execute only essential stages
-- 📋 **Comprehensive**: Complex changes get full treatment with all safeguards
-- 🔍 **Transparent**: You see and approve the execution plan before work begins
-- 📝 **Documented**: Complete audit trail of all decisions and changes
-- 🎛️ **User Control**: You can request stages be included or excluded
-
-## What Happens Next:
-
-1. **I'll analyze your workspace** to understand if this is a new or existing project
-2. **I'll gather requirements** and ask clarifying questions if needed
-3. **I'll create an execution plan** showing which stages I propose to run and why
-4. **You'll review and approve** the plan (or request changes)
-5. **We'll execute the plan** with checkpoints at each major stage
-6. **You'll get working code** with complete documentation and tests
-
-The AI-DLC process adapts to:
-- 📋 Your intent clarity and complexity
-- 🔍 Existing codebase state
-- 🎯 Scope and impact of changes
-- ⚡ Risk and quality requirements
-
-Let's begin!
+# AI-DLC Welcome Message
+
+**Purpose**: This file contains the user-facing welcome message that should be displayed ONCE at the start of any AI-DLC workflow.
+
+---
+
+# 👋 Welcome to AI-DLC (AI-Driven Development Life Cycle)! 👋
+
+I'll guide you through an adaptive software development workflow that intelligently tailors itself to your specific needs.
+
+## What is AI-DLC?
+
+AI-DLC is a structured yet flexible software development process that adapts to your project's needs. Think of it as having an experienced software architect who:
+
+- **Analyzes your requirements** and asks clarifying questions when needed
+- **Plans the optimal approach** based on complexity and risk
+- **Skips unnecessary steps** for simple changes while providing comprehensive coverage for complex projects
+- **Documents everything** so you have a complete record of decisions and rationale
+- **Guides you through each phase** with clear checkpoints and approval gates
+
+## The Three-Phase Lifecycle
+
+```
+                         User Request
+                              |
+                              v
+        ╔═══════════════════════════════════════╗
+        ║     INCEPTION PHASE                   ║
+        ║     Planning & Application Design     ║
+        ╠═══════════════════════════════════════╣
+        ║ • Workspace Detection (ALWAYS)        ║
+        ║ • Reverse Engineering (COND)          ║
+        ║ • Requirements Analysis (ALWAYS)      ║
+        ║ • User Stories (CONDITIONAL)          ║
+        ║ • Workflow Planning (ALWAYS)          ║
+        ║ • Application Design (CONDITIONAL)    ║
+        ║ • Units Generation (CONDITIONAL)      ║
+        ╚═══════════════════════════════════════╝
+                              |
+                              v
+        ╔═══════════════════════════════════════╗
+        ║     CONSTRUCTION PHASE                ║
+        ║     Design, Implementation & Test     ║
+        ╠═══════════════════════════════════════╣
+        ║ • Per-Unit Loop (for each unit):      ║
+        ║   - Functional Design (COND)          ║
+        ║   - NFR Requirements Assess (COND)    ║
+        ║   - NFR Design (COND)                 ║
+        ║   - Infrastructure Design (COND)      ║
+        ║   - Unit → Bolt Decomposition         ║
+        ║                                       ║
+        ║ • Per-Bolt Loop (for each bolt):      ║
+        ║   - Elaboration (COND)                ║
+        ║   - Code Generation (ALWAYS)          ║
+        ║   - Build and Test (ALWAYS)           ║
+        ║   - Review (ALWAYS)                   ║
+        ║                                       ║
+        ║ • Final Build and Test (ALWAYS)       ║
+        ╚═══════════════════════════════════════╝
+                              |
+                              v
+        ╔═══════════════════════════════════════╗
+        ║     OPERATIONS PHASE                  ║
+        ║     Placeholder for Future            ║
+        ╠═══════════════════════════════════════╣
+        ║ • Operations (PLACEHOLDER)            ║
+        ╚═══════════════════════════════════════╝
+                              |
+                              v
+                          Complete
+```
+
+### Phase Breakdown:
+
+**INCEPTION PHASE** - *Planning & Application Design*
+- **Purpose**: Determines WHAT to build and WHY
+- **Activities**: Understanding requirements, analyzing existing code (if any), planning the approach
+- **Output**: Clear requirements, execution plan, decisions on the number of units of work for parallel development
+- **Your Role**: Answer questions, review plans, approve direction
+
+**CONSTRUCTION PHASE** - *Detailed Design, Implementation & Test*
+- **Purpose**: Determines HOW to build it
+- **Activities**: Detailed design (when needed), unit decomposition into bolts, per-bolt code generation and testing
+- **Output**: Working code, tests, build instructions
+- **Your Role**: Review designs, approve bolt plans, validate results
+
+> **What is a Bolt?** A bolt is the smallest unit of execution in AI-DLC — a focused implementation task (typically hours of work, not days). Each unit of work is decomposed into one or more bolts, and each bolt goes through its own lifecycle: **Elaboration** (detailed spec) → **Code Generation** → **Build and Test** → **Review**. Simple bolts run in *express mode*, skipping elaboration for faster delivery.
+
+**OPERATIONS PHASE** - *Deployment & Monitoring (Future)*
+- **Purpose**: How to DEPLOY and RUN it
+- **Status**: Placeholder for future deployment and monitoring workflows
+- **Current State**: Build and test activities handled in CONSTRUCTION phase
+
+## Key Principles:
+
+- ⚡ **Fully Adaptive**: Each stage independently evaluated based on your needs
+- 🎯 **Efficient**: Simple changes execute only essential stages
+- 📋 **Comprehensive**: Complex changes get full treatment with all safeguards
+- 🔍 **Transparent**: You see and approve the execution plan before work begins
+- 📝 **Documented**: Complete audit trail of all decisions and changes
+- 🎛️ **User Control**: You can request stages be included or excluded
+
+## What Happens Next:
+
+1. **I'll analyze your workspace** to understand if this is a new or existing project
+2. **I'll gather requirements** and ask clarifying questions if needed
+3. **I'll create an execution plan** showing which stages I propose to run and why
+4. **You'll review and approve** the plan (or request changes)
+5. **We'll execute the plan** with checkpoints at each major stage
+6. **You'll get working code** with complete documentation and tests
+
+The AI-DLC process adapts to:
+- 📋 Your intent clarity and complexity
+- 🔍 Existing codebase state
+- 🎯 Scope and impact of changes
+- ⚡ Risk and quality requirements
+
+Let's begin!