Cursor rule

1---
2alwaysApply: false
3---
4 
5# AI-DLC Terminology Glossary
6 
7## Core Terminology
8 
9### Phase vs Stage
10 
11**Phase**: One of the three high-level lifecycle phases in AI-DLC
12- 🔵 **INCEPTION PHASE** - Planning & Architecture (WHAT and WHY)
13- 🟢 **CONSTRUCTION PHASE** - Design, Implementation & Test (HOW)
14- 🟡 **OPERATIONS PHASE** - Deployment & Monitoring (future expansion)
15 
16**Stage**: An individual workflow activity within a phase
17- Examples: Context Assessment stage, Requirements Assessment stage, Code Generation stage
18- Each stage has specific prerequisites, steps, and outputs
19- Stages can be ALWAYS-EXECUTE or CONDITIONAL
20 
21**Usage Examples**:
22- ✅ "The CONSTRUCTION phase contains 7 stages"
23- ✅ "The Code Generation stage is always executed"
24- ✅ "We're in the INCEPTION phase, executing the Requirements Assessment stage"
25- ❌ "The Requirements Assessment phase" (should be "stage")
26- ❌ "The CONSTRUCTION stage" (should be "phase")
27 
28## Three-Phase Lifecycle
29 
30### INCEPTION PHASE
31**Purpose**: Planning and architectural decisions  
32**Focus**: Determine WHAT to build and WHY  
33**Location**: `inception/` directory
34 
35**Stages**:
36- Workspace Detection (ALWAYS)
37- Reverse Engineering (CONDITIONAL - Brownfield only)
38- Requirements Analysis (ALWAYS - Adaptive depth)
39- User Stories (CONDITIONAL)
40- Workflow Planning (ALWAYS)
41- Application Design (CONDITIONAL)
42- Design - Units Planning/Generation (CONDITIONAL)
43 
44**Outputs**: Requirements, user stories, architectural decisions, unit definitions
45 
46### CONSTRUCTION PHASE
47**Purpose**: Detailed design and implementation  
48**Focus**: Determine HOW to build it  
49**Location**: `construction/` directory
50 
51**Stages**:
52- Functional Design (CONDITIONAL, per-unit)
53- NFR Requirements (CONDITIONAL, per-unit)
54- NFR Design (CONDITIONAL, per-unit)
55- Infrastructure Design (CONDITIONAL, per-unit)
56- Code Generation (ALWAYS) — includes Part 1: Planning and Part 2: Generation
57- Build and Test (ALWAYS)
58 
59**Outputs**: Design artifacts, NFR implementations, code, tests
60 
61### OPERATIONS PHASE
62**Purpose**: Deployment and operational readiness  
63**Focus**: How to DEPLOY and RUN it  
64**Location**: `operations/` directory
65 
66**Stages**:
67- Operations (PLACEHOLDER)
68 
69**Outputs**: Build instructions, deployment guides, monitoring setup, verification procedures
70 
71---
72 
73## Workflow Stages
74 
75### Always-Execute Stages
76- **Workspace Detection**: Initial analysis of workspace state and project type
77- **Requirements Analysis**: Gathering requirements (depth varies based on complexity)
78- **Workflow Planning**: Creating execution plan for which phases to run
79- **Code Generation**: Single stage with two parts — Part 1 (Planning) creates detailed implementation plans, Part 2 (Generation) generates actual code based on plans and prior artifacts
80- **Build and Test**: Building all units and executing comprehensive testing
81 
82### Conditional Stages
83- **Reverse Engineering**: Analyzing existing codebase (brownfield projects only)
84- **User Stories**: Creating user stories and personas (includes Story Planning and Story Generation)
85- **Application Design**: Designing application components, methods, business rules, and services
86- **Design**: Designing system components (includes Units Planning, Units Generation, per-unit design)
87- **Functional Design**: Technology-agnostic business logic design (per-unit)
88- **NFR Requirements**: Determining NFRs and selecting tech stack (per-unit)
89- **NFR Design**: Incorporating NFR patterns and logical components (per-unit)
90- **Infrastructure Design**: Mapping to actual infrastructure services (per-unit)
91 
92## Application Design Terms
93 
94- **Component**: A functional unit with specific responsibilities
95- **Method**: A function or operation within a component with defined business rules
96- **Business Rule**: Logic that governs method behavior and validation
97- **Service**: Orchestration layer that coordinates business logic across components
98- **Component Dependency**: Relationship and communication pattern between components
99 
100## Architecture Terms (Infrastructure)
101 
102### Unit of Work
103A logical grouping of user stories for development purposes. The term used during planning and decomposition.
104 
105**Usage**: "We need to decompose the system into units of work"
106 
107### Service
108An independently deployable component in a microservices architecture. Each service is a separate unit of work.
109 
110**Usage**: "The Payment Service handles all payment processing"
111 
112### Module
113A logical grouping of functionality within a single service or monolith. Modules are not independently deployable.
114 
115**Usage**: "The authentication module within the User Service"
116 
117### Component
118A reusable building block within a service or module. Components are classes, functions, or packages that provide specific functionality.
119 
120**Usage**: "The EmailValidator component validates email addresses"
121 
122## Terminology Guidelines
123 
124### When to Use Each Term
125 
126**Unit of Work**:
127- During Units Planning and Units Generation stages
128- When discussing system decomposition
129- In planning documents and discussions
130- Example: "How should we decompose this into units of work?"
131 
132**Service**:
133- When referring to independently deployable components
134- In microservices architecture contexts
135- In deployment and infrastructure discussions
136- Example: "The Order Service will be deployed to ECS"
137 
138**Module**:
139- When referring to logical groupings within a service
140- In monolith architecture contexts
141- When discussing internal organization
142- Example: "The reporting module generates all reports"
143 
144**Component**:
145- When referring to specific classes, functions, or packages
146- In design and implementation discussions
147- When discussing reusable building blocks
148- Example: "The DatabaseConnection component manages connections"
149 
150## Stage Terminology
151 
152### Planning vs Generation
153- **Planning**: Creating a plan with questions and checkboxes for execution
154- **Generation**: Executing the plan to create artifacts
155 
156Examples:
157- Story Planning → Story Generation
158- Units Planning → Units Generation
159- Unit Design Planning → Unit Design Generation
160- NFR Planning → NFR Generation
161- Code Generation Part 1 (Planning) → Code Generation Part 2 (Generation)
162 
163### Depth Levels
164- **Minimal**: Quick, focused execution for simple changes
165- **Standard**: Normal depth with standard artifacts for typical projects
166- **Comprehensive**: Full depth with all artifacts for complex/high-risk projects
167 
168## Artifact Types
169 
170### Plans
171Documents with checkboxes and questions that guide execution.
172- Located in `aidlc-docs/plans/`
173- Examples: `story-generation-plan.md`, `unit-of-work-plan.md`
174 
175### Artifacts
176Generated outputs from executing plans.
177- Located in various `aidlc-docs/` subdirectories
178- Examples: `requirements.md`, `stories.md`, `design.md`
179 
180### State Files
181Files tracking workflow progress and status.
182- `aidlc-state.md`: Overall workflow state
183- `audit.md`: Complete audit trail of all interactions
184 
185## Common Abbreviations
186 
187- **AI-DLC**: AI-Driven Development Life Cycle
188- **NFR**: Non-Functional Requirements
189- **UOW**: Unit of Work
190- **API**: Application Programming Interface
191- **CDK**: Cloud Development Kit (AWS)
192