Nevar pievienot vairāk kā 25 tēmas Tēmai ir jāsākas ar burtu vai ciparu, tā var saturēt domu zīmes ('-') un var būt līdz 35 simboliem gara.

step-06-structure.md 11KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379
  1. # Step 6: Project Structure & Boundaries
  2. ## MANDATORY EXECUTION RULES (READ FIRST):
  3. - 🛑 NEVER generate content without user input
  4. - 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
  5. - 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
  6. - ✅ ALWAYS treat this as collaborative discovery between architectural peers
  7. - 📋 YOU ARE A FACILITATOR, not a content generator
  8. - 💬 FOCUS on defining complete project structure and clear boundaries
  9. - 🗺️ MAP requirements/epics to architectural components
  10. - ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
  11. - ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
  12. ## EXECUTION PROTOCOLS:
  13. - 🎯 Show your analysis before taking any action
  14. - 🗺️ Create complete project tree, not generic placeholders
  15. - ⚠️ Present A/P/C menu after generating project structure
  16. - 💾 ONLY save when user chooses C (Continue)
  17. - 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6]` before loading next step
  18. - 🚫 FORBIDDEN to load next step until C is selected
  19. ## COLLABORATION MENUS (A/P/C):
  20. This step will generate content and present choices:
  21. - **A (Advanced Elicitation)**: Use discovery protocols to explore innovative project organization approaches
  22. - **P (Party Mode)**: Bring multiple perspectives to evaluate project structure trade-offs
  23. - **C (Continue)**: Save the project structure and proceed to validation
  24. ## PROTOCOL INTEGRATION:
  25. - When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
  26. - When 'P' selected: Invoke the `bmad-party-mode` skill
  27. - PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
  28. - User accepts/rejects protocol changes before proceeding
  29. ## CONTEXT BOUNDARIES:
  30. - All previous architectural decisions are complete
  31. - Implementation patterns and consistency rules are defined
  32. - Focus on physical project structure and component boundaries
  33. - Map requirements to specific files and directories
  34. ## YOUR TASK:
  35. Define the complete project structure and architectural boundaries based on all decisions made, creating a concrete implementation guide for AI agents.
  36. ## PROJECT STRUCTURE SEQUENCE:
  37. ### 1. Analyze Requirements Mapping
  38. Map project requirements to architectural components:
  39. **From Epics (if available):**
  40. "Epic: {{epic_name}} → Lives in {{module/directory/service}}"
  41. - User stories within the epic
  42. - Cross-epic dependencies
  43. - Shared components needed
  44. **From FR Categories (if no epics):**
  45. "FR Category: {{fr_category_name}} → Lives in {{module/directory/service}}"
  46. - Related functional requirements
  47. - Shared functionality across categories
  48. - Integration points between categories
  49. ### 2. Define Project Directory Structure
  50. Based on technology stack and patterns, create the complete project structure:
  51. **Root Configuration Files:**
  52. - Package management files (package.json, requirements.txt, etc.)
  53. - Build and development configuration
  54. - Environment configuration files
  55. - CI/CD pipeline files
  56. - Documentation files
  57. **Source Code Organization:**
  58. - Application entry points
  59. - Core application structure
  60. - Feature/module organization
  61. - Shared utilities and libraries
  62. - Configuration and environment files
  63. **Test Organization:**
  64. - Unit test locations and structure
  65. - Integration test organization
  66. - End-to-end test structure
  67. - Test utilities and fixtures
  68. **Build and Distribution:**
  69. - Build output directories
  70. - Distribution files
  71. - Static assets
  72. - Documentation build
  73. ### 3. Define Integration Boundaries
  74. Map how components communicate and where boundaries exist:
  75. **API Boundaries:**
  76. - External API endpoints
  77. - Internal service boundaries
  78. - Authentication and authorization boundaries
  79. - Data access layer boundaries
  80. **Component Boundaries:**
  81. - Frontend component communication patterns
  82. - State management boundaries
  83. - Service communication patterns
  84. - Event-driven integration points
  85. **Data Boundaries:**
  86. - Database schema boundaries
  87. - Data access patterns
  88. - Caching boundaries
  89. - External data integration points
  90. ### 4. Create Complete Project Tree
  91. Generate a comprehensive directory structure showing all files and directories:
  92. **Technology-Specific Structure Examples:**
  93. **Next.js Full-Stack:**
  94. ```
  95. project-name/
  96. ├── README.md
  97. ├── package.json
  98. ├── next.config.js
  99. ├── tailwind.config.js
  100. ├── tsconfig.json
  101. ├── .env.local
  102. ├── .env.example
  103. ├── .gitignore
  104. ├── .github/
  105. │ └── workflows/
  106. │ └── ci.yml
  107. ├── src/
  108. │ ├── app/
  109. │ │ ├── globals.css
  110. │ │ ├── layout.tsx
  111. │ │ └── page.tsx
  112. │ ├── components/
  113. │ │ ├── ui/
  114. │ │ ├── forms/
  115. │ │ └── features/
  116. │ ├── lib/
  117. │ │ ├── db.ts
  118. │ │ ├── auth.ts
  119. │ │ └── utils.ts
  120. │ ├── types/
  121. │ └── middleware.ts
  122. ├── prisma/
  123. │ ├── schema.prisma
  124. │ └── migrations/
  125. ├── tests/
  126. │ ├── __mocks__/
  127. │ ├── components/
  128. │ └── e2e/
  129. └── public/
  130. └── assets/
  131. ```
  132. **API Backend (NestJS):**
  133. ```
  134. project-name/
  135. ├── package.json
  136. ├── nest-cli.json
  137. ├── tsconfig.json
  138. ├── .env
  139. ├── .env.example
  140. ├── .gitignore
  141. ├── README.md
  142. ├── src/
  143. │ ├── main.ts
  144. │ ├── app.module.ts
  145. │ ├── config/
  146. │ ├── modules/
  147. │ │ ├── auth/
  148. │ │ ├── users/
  149. │ │ └── common/
  150. │ ├── services/
  151. │ ├── repositories/
  152. │ ├── decorators/
  153. │ ├── pipes/
  154. │ ├── guards/
  155. │ └── interceptors/
  156. ├── test/
  157. │ ├── unit/
  158. │ ├── integration/
  159. │ └── e2e/
  160. ├── prisma/
  161. │ ├── schema.prisma
  162. │ └── migrations/
  163. └── docker-compose.yml
  164. ```
  165. ### 5. Map Requirements to Structure
  166. Create explicit mapping from project requirements to specific files/directories:
  167. **Epic/Feature Mapping:**
  168. "Epic: User Management
  169. - Components: src/components/features/users/
  170. - Services: src/services/users/
  171. - API Routes: src/app/api/users/
  172. - Database: prisma/migrations/_*users*_
  173. - Tests: tests/features/users/"
  174. **Cross-Cutting Concerns:**
  175. "Authentication System
  176. - Components: src/components/auth/
  177. - Services: src/services/auth/
  178. - Middleware: src/middleware/auth.ts
  179. - Guards: src/guards/auth.guard.ts
  180. - Tests: tests/auth/"
  181. ### 6. Generate Structure Content
  182. Prepare the content to append to the document:
  183. #### Content Structure:
  184. ```markdown
  185. ## Project Structure & Boundaries
  186. ### Complete Project Directory Structure
  187. ```
  188. {{complete_project_tree_with_all_files_and_directories}}
  189. ```
  190. ### Architectural Boundaries
  191. **API Boundaries:**
  192. {{api_boundary_definitions_and_endpoints}}
  193. **Component Boundaries:**
  194. {{component_communication_patterns_and_boundaries}}
  195. **Service Boundaries:**
  196. {{service_integration_patterns_and_boundaries}}
  197. **Data Boundaries:**
  198. {{data_access_patterns_and_boundaries}}
  199. ### Requirements to Structure Mapping
  200. **Feature/Epic Mapping:**
  201. {{mapping_of_epics_or_features_to_specific_directories}}
  202. **Cross-Cutting Concerns:**
  203. {{mapping_of_shared_functionality_to_locations}}
  204. ### Integration Points
  205. **Internal Communication:**
  206. {{how_components_within_the_project_communicate}}
  207. **External Integrations:**
  208. {{third_party_service_integration_points}}
  209. **Data Flow:**
  210. {{how_data_flows_through_the_architecture}}
  211. ### File Organization Patterns
  212. **Configuration Files:**
  213. {{where_and_how_config_files_are_organized}}
  214. **Source Organization:**
  215. {{how_source_code_is_structured_and_organized}}
  216. **Test Organization:**
  217. {{how_tests_are_structured_and_organized}}
  218. **Asset Organization:**
  219. {{how_static_and_dynamic_assets_are_organized}}
  220. ### Development Workflow Integration
  221. **Development Server Structure:**
  222. {{how_the_project_is organized_for_development}}
  223. **Build Process Structure:**
  224. {{how_the_build_process_uses_the_project_structure}}
  225. **Deployment Structure:**
  226. {{how_the_project_structure_supports_deployment}}
  227. ```
  228. ### 7. Present Content and Menu
  229. Show the generated project structure content and present choices:
  230. "I've created a complete project structure based on all our architectural decisions.
  231. **Here's what I'll add to the document:**
  232. [Show the complete markdown content from step 6]
  233. **What would you like to do?**
  234. [A] Advanced Elicitation - Explore innovative project organization approaches
  235. [P] Party Mode - Review structure from different development perspectives
  236. [C] Continue - Save this structure and move to architecture validation"
  237. ### 8. Handle Menu Selection
  238. #### If 'A' (Advanced Elicitation):
  239. - Invoke the `bmad-advanced-elicitation` skill with current project structure
  240. - Process enhanced organizational insights that come back
  241. - Ask user: "Accept these changes to the project structure? (y/n)"
  242. - If yes: Update content, then return to A/P/C menu
  243. - If no: Keep original content, then return to A/P/C menu
  244. #### If 'P' (Party Mode):
  245. - Invoke the `bmad-party-mode` skill with project structure context
  246. - Process collaborative insights about organization trade-offs
  247. - Ask user: "Accept these changes to the project structure? (y/n)"
  248. - If yes: Update content, then return to A/P/C menu
  249. - If no: Keep original content, then return to A/P/C menu
  250. #### If 'C' (Continue):
  251. - Append the final content to `{planning_artifacts}/architecture.md`
  252. - Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6]`
  253. - Load `./step-07-validation.md`
  254. ## APPEND TO DOCUMENT:
  255. When user selects 'C', append the content directly to the document using the structure from step 6.
  256. ## SUCCESS METRICS:
  257. ✅ Complete project tree defined with all files and directories
  258. ✅ All architectural boundaries clearly documented
  259. ✅ Requirements/epics mapped to specific locations
  260. ✅ Integration points and communication patterns defined
  261. ✅ Project structure aligned with chosen technology stack
  262. ✅ A/P/C menu presented and handled correctly
  263. ✅ Content properly appended to document when C selected
  264. ## FAILURE MODES:
  265. ❌ Creating generic placeholder structure instead of specific, complete tree
  266. ❌ Not mapping requirements to specific files and directories
  267. ❌ Missing important integration boundaries
  268. ❌ Not considering the chosen technology stack in structure design
  269. ❌ Not defining how components communicate across boundaries
  270. ❌ Not presenting A/P/C menu after content generation
  271. ❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
  272. ❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
  273. ❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
  274. ## NEXT STEP:
  275. After user selects 'C' and content is saved to document, load `./step-07-validation.md` to validate architectural coherence and completeness.
  276. Remember: Do NOT proceed to step-07 until user explicitly selects 'C' from the A/P/C menu and content is saved!