Cursor rule

1---
2alwaysApply: false
3---
4 
5# Application Design - Detailed Steps
6 
7## Purpose
8**High-level component identification and service layer design**
9 
10Application Design focuses on:
11- Identifying main functional components and their responsibilities
12- Defining component interfaces (not detailed business logic)
13- Designing service layer for orchestration
14- Establishing component dependencies and communication patterns
15 
16**Note**: Detailed business logic design happens later in Functional Design (per-unit, CONSTRUCTION phase)
17 
18## Prerequisites
19- Workspace Detection must be complete
20- Requirements Analysis recommended (provides functional context)
21- User Stories recommended (user stories guide design decisions)
22- Execution plan must indicate Application Design stage should execute
23 
24## Step-by-Step Execution
25 
26### 1. Analyze Context
27- Read `aidlc-docs/inception/requirements/requirements.md` and `aidlc-docs/inception/user-stories/stories.md`
28- Identify key business capabilities and functional areas
29- Determine design scope and complexity
30 
31### 2. Create Application Design Plan
32- Generate plan with checkboxes [] for application design
33- Focus on components, responsibilities, methods, business rules, and services
34- Each step and sub-step should have a checkbox []
35 
36### 3. Include Mandatory Design Artifacts in Plan
37- **ALWAYS** include these mandatory artifacts in the design plan:
38  - [ ] Generate components.md with component definitions and high-level responsibilities
39  - [ ] Generate component-methods.md with method signatures (business rules detailed later in Functional Design)
40  - [ ] Generate services.md with service definitions and orchestration patterns
41  - [ ] Generate component-dependency.md with dependency relationships and communication patterns
42  - [ ] Validate design completeness and consistency
43 
44### 4. Generate Context-Appropriate Questions
45**DIRECTIVE**: Analyze the requirements and stories to generate questions relevant to THIS specific application design. Use the categories below as guidance. Evaluate each category and, when in doubt about applicability, ask the question rather than skipping it — overconfidence leads to poor outcomes (see overconfidence-prevention.md).
46 
47- EMBED questions using [Answer]: tag format
48- Focus on ANY ambiguities, missing information, or areas needing clarification
49- Generate questions wherever user input would improve design decisions
50- **When in doubt, ask the question** - overconfidence leads to poor designs
51 
52**Question categories to evaluate** (consider ALL categories):
53- **Component Identification** - Ask about component boundaries, organization, and grouping strategies
54- **Component Methods** - Ask about method signatures, input/output expectations, and interface contracts (detailed business rules come later)
55- **Service Layer Design** - Ask about service orchestration, boundaries, and coordination patterns
56- **Component Dependencies** - Ask about communication patterns, dependency management, and coupling concerns
57- **Design Patterns** - Ask about architectural style preferences, pattern choices, and design constraints
58 
59### 5. Store Application Design Plan
60- Save as `aidlc-docs/inception/plans/application-design-plan.md`
61- Include all [Answer]: tags for user input
62- Ensure plan covers all design aspects
63 
64### 6. Request User Input
65- Ask user to fill [Answer]: tags directly in the plan document
66- Emphasize importance of design decisions
67- Provide clear instructions on completing the [Answer]: tags
68 
69### 7. Collect Answers
70- Wait for user to provide answers to all questions using [Answer]: tags in the document
71- Do not proceed until ALL [Answer]: tags are completed
72- Review the document to ensure no [Answer]: tags are left blank
73 
74### 8. ANALYZE ANSWERS (MANDATORY)
75Before proceeding, you MUST carefully review all user answers for:
76- **Vague or ambiguous responses**: "mix of", "somewhere between", "not sure", "depends"
77- **Undefined criteria or terms**: References to concepts without clear definitions
78- **Contradictory answers**: Responses that conflict with each other
79- **Missing design details**: Answers that lack specific guidance
80- **Answers that combine options**: Responses that merge different approaches without clear decision rules
81 
82### 9. MANDATORY Follow-up Questions
83If the analysis in step 8 reveals ANY ambiguous answers, you MUST:
84- Add specific follow-up questions to the plan document using [Answer]: tags
85- DO NOT proceed to approval until all ambiguities are resolved
86- Examples of required follow-ups:
87  - "You mentioned 'mix of A and B' - what specific criteria should determine when to use A vs B?"
88  - "You said 'somewhere between A and B' - can you define the exact middle ground approach?"
89  - "You indicated 'not sure' - what additional information would help you decide?"
90  - "You mentioned 'depends on complexity' - how do you define complexity levels?"
91 
92### 10. Generate Application Design Artifacts
93- Execute the approved plan to generate design artifacts
94- Create `aidlc-docs/inception/application-design/components.md` with:
95  - Component name and purpose
96  - Component responsibilities
97  - Component interfaces
98- Create `aidlc-docs/inception/application-design/component-methods.md` with:
99  - Method signatures for each component
100  - High-level purpose of each method
101  - Input/output types
102  - Note: Detailed business rules will be defined in Functional Design (per-unit, CONSTRUCTION phase)
103- Create `aidlc-docs/inception/application-design/services.md` with:
104  - Service definitions
105  - Service responsibilities
106  - Service interactions and orchestration
107- Create `aidlc-docs/inception/application-design/component-dependency.md` with:
108  - Dependency matrix showing relationships
109  - Communication patterns between components
110  - Data flow diagrams
111- Create `aidlc-docs/inception/application-design/application-design.md` that consolidates the multiple design docs created above in a single doc.
112 
113### 11. Log Approval
114- Log approval prompt with timestamp in `aidlc-docs/audit.md`
115- Include complete approval prompt text
116- Use ISO 8601 timestamp format
117 
118### 12. Present Completion Message
119 
120```markdown
121# 🏗️ Application Design Complete
122 
123[AI-generated summary of application design artifacts created in bullet points]
124 
125> **📋 <u>**REVIEW REQUIRED:**</u>**  
126> Please examine the application design artifacts at: `aidlc-docs/inception/application-design/`
127 
128> **🚀 <u>**WHAT'S NEXT?**</u>**
129>
130> **You may:**
131>
132> 🔧 **Request Changes** - Ask for modifications to the application design if required
133> [IF Units Generation is skipped:]
134> 📝 **Add Units Generation** - Choose to include **Units Generation** stage (currently skipped)
135> ✅ **Approve & Continue** - Approve design and proceed to **[Units Generation/CONSTRUCTION PHASE]**
136```
137 
138### 13. Wait for Explicit Approval
139- Do not proceed until the user explicitly approves the application design
140- Approval must be clear and unambiguous
141- If user requests changes, update the design and repeat the approval process
142 
143### 14. Record Approval Response
144- Log the user's approval response with timestamp in `aidlc-docs/audit.md`
145- Include the exact user response text
146- Mark the approval status clearly
147 
148### 15. Update Progress
149- Mark Application Design stage complete in `aidlc-docs/aidlc-state.md`
150- Update the "Current Status" section
151- Prepare for transition to next stage
152