doc output lang vs com lang

src/modules/bmm/_module-installer/install-menu-config.yaml

@@ -19,6 +19,26 @@ project_name:
   default: "{directory_name}"
   result: "{value}"
 
+user_skill_level:
+  prompt:
+    - "What is your technical experience level?"
+    - "This affects how agents explain concepts to you (NOT document content)."
+    - "Documents are always concise for LLM efficiency."
+  default: "intermediate"
+  result: "{value}"
+  single-select:
+    - value: "beginner"
+      label: "Beginner - New to development, explain concepts clearly"
+    - value: "intermediate"
+      label: "Intermediate - Familiar with development, balance explanation with efficiency"
+    - value: "expert"
+      label: "Expert - Deep technical knowledge, be direct and technical"
+
+document_output_language:
+  prompt: "In which language should project documents be generated?"
+  default: "{communication_language}"
+  result: "{value}"
+
 tech_docs:
   prompt: "Where is Technical Documentation located within the project?"
   default: "docs"

src/modules/bmm/workflows/1-analysis/brainstorm-game/workflow.yaml

@@ -8,6 +8,8 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+user_skill_level: "{config_source}:user_skill_level"
 date: system-generated
 
 # Module path and component files

src/modules/bmm/workflows/1-analysis/brainstorm-project/workflow.yaml

@@ -8,6 +8,8 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+user_skill_level: "{config_source}:user_skill_level"
 date: system-generated
 
 # Module path and component files

src/modules/bmm/workflows/1-analysis/document-project/workflow.yaml

@@ -9,6 +9,8 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+user_skill_level: "{config_source}:user_skill_level"
 date: system-generated
 
 # Module path and component files

src/modules/bmm/workflows/1-analysis/game-brief/instructions.md

@@ -2,7 +2,10 @@
 
 <critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
 <critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
-<critical>Communicate all responses in {communication_language}</critical>
+<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
+<critical>Generate all documents in {document_output_language}</critical>
+
+<critical>DOCUMENT OUTPUT: Concise, professional, game-design focused. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
 
 <workflow>
 

src/modules/bmm/workflows/1-analysis/game-brief/workflow.yaml

@@ -8,6 +8,8 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+user_skill_level: "{config_source}:user_skill_level"
 date: system-generated
 
 # Optional input documents

src/modules/bmm/workflows/1-analysis/product-brief/instructions.md

@@ -2,7 +2,10 @@
 
 <critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
 <critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
-<critical>Communicate all responses in {communication_language}</critical>
+<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
+<critical>Generate all documents in {document_output_language}</critical>
+
+<critical>DOCUMENT OUTPUT: Concise, professional, strategically focused. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
 
 <workflow>
 

src/modules/bmm/workflows/1-analysis/product-brief/workflow.yaml

@@ -8,6 +8,8 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+user_skill_level: "{config_source}:user_skill_level"
 date: system-generated
 
 # Optional input documents

src/modules/bmm/workflows/1-analysis/research/workflow.yaml

@@ -8,6 +8,8 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+user_skill_level: "{config_source}:user_skill_level"
 date: system-generated
 
 # Workflow components - ROUTER PATTERN

src/modules/bmm/workflows/1-analysis/workflow-init/workflow.yaml

@@ -9,6 +9,8 @@ output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 project_name: "{config_source}:project_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+user_skill_level: "{config_source}:user_skill_level"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/1-analysis/workflow-status/workflow.yaml

@@ -8,6 +8,8 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+user_skill_level: "{config_source}:user_skill_level"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/2-plan-workflows/gdd/instructions-gdd.md

@@ -4,13 +4,16 @@
 
 <critical>The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.xml</critical>
 <critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
-<critical>Communicate all responses in {communication_language}</critical>
+<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
+<critical>Generate all documents in {document_output_language}</critical>
 <critical>This is the GDD instruction set for GAME projects - replaces PRD with Game Design Document</critical>
 <critical>Project analysis already completed - proceeding with game-specific design</critical>
 <critical>Uses gdd_template for GDD output, game_types.csv for type-specific sections</critical>
 <critical>Routes to 3-solutioning for architecture (platform-specific decisions handled there)</critical>
 <critical>If users mention technical details, append to technical_preferences with timestamp</critical>
 
+<critical>DOCUMENT OUTPUT: Concise, clear, actionable game design specs. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
+
 <step n="0" goal="Validate workflow and extract project configuration">
 
 <invoke-workflow path="{project-root}/bmad/bmm/workflows/1-analysis/workflow-status">

src/modules/bmm/workflows/2-plan-workflows/gdd/workflow.yaml

@@ -8,6 +8,8 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+user_skill_level: "{config_source}:user_skill_level"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/2-plan-workflows/narrative/workflow.yaml

@@ -8,6 +8,8 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+user_skill_level: "{config_source}:user_skill_level"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/2-plan-workflows/prd/instructions.md

@@ -2,11 +2,14 @@
 
 <critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
 <critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
-<critical>Communicate all responses in {communication_language}</critical>
+<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
+<critical>Generate all documents in {document_output_language}</critical>
 <critical>This workflow is for Level 2-4 projects. Level 0-1 use tech-spec workflow.</critical>
 <critical>Produces TWO outputs: PRD.md (strategic) and epics.md (tactical implementation)</critical>
 <critical>TECHNICAL NOTES: If ANY technical details, preferences, or constraints are mentioned during PRD discussions, append them to {technical_decisions_file}. If file doesn't exist, create it from {technical_decisions_template}</critical>
 
+<critical>DOCUMENT OUTPUT: Concise, clear, actionable requirements. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
+
 <workflow>
 
 <step n="0" goal="Validate workflow and extract project configuration">

src/modules/bmm/workflows/2-plan-workflows/prd/workflow.yaml

@@ -9,6 +9,8 @@ project_name: "{config_source}:project_name"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+user_skill_level: "{config_source}:user_skill_level"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/2-plan-workflows/tech-spec/instructions.md

@@ -4,12 +4,15 @@
 
 <critical>The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.xml</critical>
 <critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
-<critical>Communicate all responses in {communication_language}</critical>
+<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
+<critical>Generate all documents in {document_output_language}</critical>
 <critical>This is the SMALL instruction set for Level 0-1 projects - tech-spec with story generation</critical>
 <critical>Level 0: tech-spec + single user story | Level 1: tech-spec + epic/stories</critical>
 <critical>Project analysis already completed - proceeding directly to technical specification</critical>
 <critical>NO PRD generated - uses tech_spec_template + story templates</critical>
 
+<critical>DOCUMENT OUTPUT: Technical, precise, definitive. Specific versions only. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
+
 <step n="0" goal="Validate workflow and extract project configuration">
 
 <invoke-workflow path="{project-root}/bmad/bmm/workflows/1-analysis/workflow-status">

src/modules/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml

@@ -9,6 +9,8 @@ project_name: "{config_source}:project_name"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+user_skill_level: "{config_source}:user_skill_level"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/2-plan-workflows/ux/instructions-ux.md

@@ -4,11 +4,14 @@
 
 <critical>The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.xml</critical>
 <critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
-<critical>Communicate all responses in {communication_language}</critical>
+<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
+<critical>Generate all documents in {document_output_language}</critical>
 <critical>This workflow creates comprehensive UX/UI specifications - can run standalone or as part of plan-project</critical>
 <critical>Uses ux-spec-template.md for structured output generation</critical>
 <critical>Can optionally generate AI Frontend Prompts for tools like Vercel v0, Lovable.ai</critical>
 
+<critical>DOCUMENT OUTPUT: Professional, precise, actionable UX specs. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
+
 <step n="0" goal="Check for workflow status">
 
 <invoke-workflow path="{project-root}/bmad/bmm/workflows/1-analysis/workflow-status">

src/modules/bmm/workflows/2-plan-workflows/ux/workflow.yaml

@@ -8,6 +8,8 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+user_skill_level: "{config_source}:user_skill_level"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/3-solutioning/README.md

@@ -11,12 +11,12 @@ This workflow generates comprehensive, scale-adaptive solution architecture docu
 **Unique Features:**
 
 - ✅ **Scale-adaptive**: Level 0 = skip, Levels 1-4 = progressive depth
-- ✅ **Pattern-aware**: 171 technology combinations across 12 project types
-- ✅ **Template-driven**: 11 complete architecture document templates
-- ✅ **Engine-specific guidance**: Unity, Godot, Phaser, and more
+- ✅ **Intent-based**: LLM intelligence over prescriptive lists
+- ✅ **Template-driven**: 11 adaptive architecture document templates
+- ✅ **Game-aware**: Adapts heavily based on game type (RPG, Puzzle, Shooter, etc.)
 - ✅ **GDD/PRD aware**: Uses Game Design Doc for games, PRD for everything else
 - ✅ **ADR tracking**: Separate Architecture Decision Records document
-- ✅ **Specialist integration**: Pattern-specific specialist recommendations
+- ✅ **Simplified structure**: ~11 core project types with consistent naming
 
 ---
 
@@ -71,38 +71,37 @@ workflow solution-architecture
 
 ## Project Types and Templates
 
-### 12 Project Types Supported
+### Simplified Project Type System
 
-| Type          | Examples                     | Template                          | Guide Examples       |
-| ------------- | ---------------------------- | --------------------------------- | -------------------- |
-| **web**       | Next.js, Rails, Django       | web-fullstack-architecture.md     | (TBD)                |
-| **mobile**    | React Native, Flutter, Swift | mobile-app-architecture.md        | (TBD)                |
-| **game**      | Unity, Godot, Phaser         | game-engine-architecture.md       | Unity, Godot, Phaser |
-| **embedded**  | ESP32, STM32, Raspberry Pi   | embedded-firmware-architecture.md | (TBD)                |
-| **backend**   | Express, FastAPI, gRPC       | backend-service-architecture.md   | (TBD)                |
-| **data**      | Spark, Airflow, MLflow       | data-pipeline-architecture.md     | (TBD)                |
-| **cli**       | Commander, Click, Cobra      | cli-tool-architecture.md          | (TBD)                |
-| **desktop**   | Electron, Tauri, Qt          | desktop-app-architecture.md       | (TBD)                |
-| **library**   | npm, PyPI, cargo             | library-package-architecture.md   | (TBD)                |
-| **infra**     | Terraform, K8s Operator      | infrastructure-architecture.md    | (TBD)                |
-| **extension** | Chrome, VS Code plugins      | desktop-app-architecture.md       | (TBD)                |
+The workflow uses ~11 core project types that cover 99% of software projects:
 
-### 171 Technology Combinations
+| Type               | Name                     | Template                   | Instructions                   |
+| ------------------ | ------------------------ | -------------------------- | ------------------------------ |
+| **web**            | Web Application          | web-template.md            | web-instructions.md            |
+| **mobile**         | Mobile Application       | mobile-template.md         | mobile-instructions.md         |
+| **game**           | Game Development         | game-template.md           | game-instructions.md           |
+| **backend**        | Backend Service          | backend-template.md        | backend-instructions.md        |
+| **data**           | Data Pipeline            | data-template.md           | data-instructions.md           |
+| **cli**            | CLI Tool                 | cli-template.md            | cli-instructions.md            |
+| **library**        | Library/SDK              | library-template.md        | library-instructions.md        |
+| **desktop**        | Desktop Application      | desktop-template.md        | desktop-instructions.md        |
+| **embedded**       | Embedded System          | embedded-template.md       | embedded-instructions.md       |
+| **extension**      | Browser/Editor Extension | extension-template.md      | extension-instructions.md      |
+| **infrastructure** | Infrastructure           | infrastructure-template.md | infrastructure-instructions.md |
 
-The workflow maintains a registry (`templates/registry.csv`) with 171 pre-defined technology stack combinations:
+### Intent-Based Architecture
 
-**Examples:**
+Instead of maintaining 171 prescriptive technology combinations, the workflow now:
 
-- `web-nextjs-ssr-monorepo` → Next.js SSR, TypeScript, monorepo
-- `game-unity-3d` → Unity 3D, C#, monorepo
-- `mobile-react-native` → React Native, TypeScript, cross-platform
-- `backend-fastapi-rest` → FastAPI, Python, REST API
-- `data-ml-training` → PyTorch/TensorFlow, Python, ML pipeline
+- **Leverages LLM intelligence** to understand project requirements
+- **Adapts templates dynamically** based on actual needs
+- **Uses intent-based instructions** rather than prescriptive checklists
+- **Allows for emerging technologies** without constant updates
 
-Each row maps to:
+Each project type has:
 
-- **template_path**: Architecture document structure (11 templates)
-- **guide_path**: Engine/framework-specific guidance (optional)
+- **Instruction file**: Intent-based guidance for architecture decisions
+- **Template file**: Adaptive starting point for the architecture document
 
 ---
 
@@ -155,63 +154,56 @@ Analyze PRD epics:
 - Map domain capabilities
 - Determine service boundaries (if microservices)
 
-### Step 5: Project-Type Questions
+### Step 5: Intent-Based Technical Decisions
 
-Load: `project-types/{project_type}-questions.md`
+Load: `project-types/{project_type}-instructions.md`
 
-- Ask project-type-specific questions (not yet engine-specific)
+- Use intent-based guidance, not prescriptive lists
+- Allow LLM intelligence to identify relevant decisions
+- Consider emerging technologies naturally
 
-### Step 6: Load Template + Guide
+### Step 6: Adaptive Template Selection
 
-**6.1: Search Registry**
+**6.1: Simple Template Selection**
 
 ```
-Read: templates/registry.csv
-Match WHERE:
-  - project_types = {determined_type}
-  - languages = {preferred_languages}
-  - architecture_style = {determined_style}
-  - tags overlap with {requirements}
-
-Get: template_path, guide_path
+Based on project_type from analysis:
+  web → web-template.md
+  mobile → mobile-template.md
+  game → game-template.md (adapts heavily by game type)
+  backend → backend-template.md
+  ... (consistent naming pattern)
 ```
 
 **6.2: Load Template**
 
 ```
-Read: templates/{template_path}
-Example: templates/game-engine-architecture.md
+Read: project-types/{type}-template.md
+Example: project-types/game-template.md
 
-This is a COMPLETE document structure with:
+Templates are adaptive starting points:
 - Standard sections (exec summary, tech stack, data arch, etc.)
-- Pattern-specific sections (Gameplay Systems for games, SSR Strategy for web)
-- All {{placeholders}} to fill
+- Pattern-specific sections conditionally included
+- All {{placeholders}} to fill based on requirements
 ```
 
-**6.3: Load Guide (if available)**
+**6.3: Dynamic Adaptation**
 
-```
-IF guide_path not empty:
-  Read: templates/{guide_path}
-  Example: templates/game-engine-unity-guide.md
+Templates adapt based on:
 
-Guide contains:
-- Engine/framework-specific questions
-- Architecture patterns for this tech
-- Common pitfalls
-- Specialist recommendations
-- ADR templates
-```
+- Actual project requirements from PRD/GDD
+- User skill level (beginner/intermediate/expert)
+- Specific technology choices made
+- Game type for game projects (RPG, Puzzle, Shooter, etc.)
 
-**Example Flow for Unity Game:**
+**Example Flow for Unity RPG:**
 
-1. GDD says "Unity 2022 LTS"
-2. Registry match: `game-unity-3d` → `game-engine-architecture.md` + `game-engine-unity-guide.md`
-3. Load complete game architecture template
-4. Load Unity-specific guide
-5. Ask Unity-specific questions (MonoBehaviour vs ECS, ScriptableObjects, etc.)
-6. Fill template placeholders
-7. Generate `solution-architecture.md` + `architecture-decisions.md`
+1. GDD says "Unity 2022 LTS" and "RPG"
+2. Load game-template.md and game-instructions.md
+3. Template adapts to include RPG-specific sections (inventory, quests, dialogue)
+4. Instructions guide Unity-specific decisions (MonoBehaviour vs ECS, etc.)
+5. LLM intelligence fills gaps not in any list
+6. Generate optimized `solution-architecture.md` + `architecture-decisions.md`
 
 ### Step 7: Cohesion Check
 
@@ -234,28 +226,30 @@ Validate architecture quality:
 ├── instructions.md                  # Main workflow logic
 ├── checklist.md                     # Validation checklist
 ├── ADR-template.md                  # ADR document template
-├── templates/                       # Architecture templates and guides
-│   ├── registry.csv                 # 171 tech combinations → templates
-│   ├── game-engine-architecture.md  # Complete game architecture doc
-│   ├── game-engine-unity-guide.md   # Unity-specific guidance
-│   ├── game-engine-godot-guide.md   # Godot-specific guidance
-│   ├── game-engine-web-guide.md     # Phaser/PixiJS/Three.js guidance
-│   ├── web-fullstack-architecture.md
-│   ├── web-api-architecture.md
-│   ├── mobile-app-architecture.md
-│   ├── embedded-firmware-architecture.md
-│   ├── backend-service-architecture.md
-│   ├── data-pipeline-architecture.md
-│   ├── cli-tool-architecture.md
-│   ├── desktop-app-architecture.md
-│   ├── library-package-architecture.md
-│   └── infrastructure-architecture.md
-└── project-types/                   # Project type detection and questions
-    ├── project-types.csv            # 12 project types + detection keywords
-    ├── game-questions.md
-    ├── web-questions.md
-    ├── mobile-questions.md
-    └── ... (12 question files)
+└── project-types/                   # All project type files in one folder
+    ├── project-types.csv            # Simple 2-column mapping (type, name)
+    ├── web-instructions.md          # Intent-based guidance for web projects
+    ├── web-template.md              # Adaptive web architecture template
+    ├── mobile-instructions.md       # Intent-based guidance for mobile
+    ├── mobile-template.md           # Adaptive mobile architecture template
+    ├── game-instructions.md         # Intent-based guidance (adapts by game type)
+    ├── game-template.md             # Highly adaptive game architecture template
+    ├── backend-instructions.md      # Intent-based guidance for backend services
+    ├── backend-template.md          # Adaptive backend architecture template
+    ├── data-instructions.md         # Intent-based guidance for data pipelines
+    ├── data-template.md             # Adaptive data pipeline template
+    ├── cli-instructions.md          # Intent-based guidance for CLI tools
+    ├── cli-template.md              # Adaptive CLI architecture template
+    ├── library-instructions.md      # Intent-based guidance for libraries/SDKs
+    ├── library-template.md          # Adaptive library architecture template
+    ├── desktop-instructions.md      # Intent-based guidance for desktop apps
+    ├── desktop-template.md          # Adaptive desktop architecture template
+    ├── embedded-instructions.md     # Intent-based guidance for embedded systems
+    ├── embedded-template.md         # Adaptive embedded architecture template
+    ├── extension-instructions.md    # Intent-based guidance for extensions
+    ├── extension-template.md        # Adaptive extension architecture template
+    ├── infrastructure-instructions.md  # Intent-based guidance for infra
+    └── infrastructure-template.md   # Adaptive infrastructure template
 ```
 
 ---
@@ -313,60 +307,6 @@ Each template in `templates/` is a **complete** architecture document structure:
 
 ---
 
-## Guide System
-
-### Engine/Framework-Specific Guides
-
-Guides are **workflow instruction documents** that:
-
-- Ask engine-specific questions
-- Provide architecture pattern recommendations
-- Suggest what sections to emphasize
-- Define ADRs to create
-
-**Guides are NOT:**
-
-- ❌ Reference documentation (use official docs)
-- ❌ Tutorials (how to code)
-- ❌ API references
-
-**Guides ARE:**
-
-- ✅ Question flows for architecture decisions
-- ✅ Pattern recommendations specific to the tech
-- ✅ Common pitfalls to avoid
-- ✅ Specialist recommendations
-
-**Example: game-engine-unity-guide.md**
-
-```markdown
-## Unity Architecture Questions
-
-- MonoBehaviour or ECS?
-- ScriptableObjects for game data?
-- Addressables or Resources?
-
-## Unity Patterns
-
-- Singleton GameManager (when to use)
-- Event-driven communication
-- Object pooling strategy
-
-## Unity-Specific Sections to Include
-
-- Unity Project Configuration
-- Scene Architecture
-- Component Organization
-- Package Dependencies
-
-## Common Pitfalls
-
-- Caching GetComponent calls
-- Avoiding empty Update methods
-```
-
----
-
 ## ADR Tracking
 
 Architecture Decision Records are maintained separately in `architecture-decisions.md`.
@@ -531,25 +471,20 @@ Specialists are documented with:
 
 ## Extending the System
 
-### Adding a New Template
-
-1. Create `templates/new-pattern-architecture.md`
-2. Include all standard sections + pattern-specific sections
-3. Add rows to `templates/registry.csv` pointing to new template
-
-### Adding a New Guide
-
-1. Create `templates/new-tech-guide.md`
-2. Include: questions, patterns, pitfalls, specialist recommendations
-3. Update `templates/registry.csv` with `guide_path` column
-
 ### Adding a New Project Type
 
-1. Add row to `project-types/project-types.csv`
-2. Create `project-types/new-type-questions.md`
-3. Ensure templates exist for this type
+1. Add row to `project-types/project-types.csv` (just type and name)
+2. Create `project-types/{type}-instructions.md` with intent-based guidance
+3. Create `project-types/{type}-template.md` with adaptive template
 4. Update instructions.md if special handling needed (like GDD for games)
 
+### Key Principles
+
+- **Intent over prescription**: Guide decisions, don't list every option
+- **Leverage LLM intelligence**: Trust the model to know technologies
+- **Adaptive templates**: Templates should adapt to project needs
+- **Consistent naming**: Always use {type}-instructions.md and {type}-template.md
+
 ---
 
 ## Questions?
@@ -557,8 +492,8 @@ Specialists are documented with:
 - **Validation:** See `checklist.md`
 - **Workflow Logic:** See `instructions.md`
 - **Configuration:** See `workflow.yaml`
-- **Registry Format:** See `templates/registry.csv`
-- **Example Guide:** See `templates/game-engine-unity-guide.md`
+- **Project Types:** See `project-types/project-types.csv`
+- **Example Template:** See `project-types/game-template.md`
 
 ---
 

src/modules/bmm/workflows/3-solutioning/implementation-ready-check/workflow.yaml

@@ -8,6 +8,7 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 # Workflow status integration

src/modules/bmm/workflows/3-solutioning/instructions.md

@@ -6,26 +6,10 @@ This workflow generates scale-adaptive solution architecture documentation that
 
 <critical>The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.xml</critical>
 <critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
-<critical>Communicate all responses in {communication_language}</critical>
+<critical>Communicate all responses in {communication_language} and language MUSt be tailored to {user_skill_level}</critical>
+<critical>Generate all documents in {document_output_language}</critical>
 
-<critical>OUTPUT OPTIMIZATION FOR LLM CONSUMPTION:
-The architecture document will be consumed primarily by LLMs in subsequent workflows, not just humans.
-Therefore, the output MUST be:
-
-- CONCISE: Every word should add value. Avoid verbose explanations.
-- STRUCTURED: Use tables, lists, and clear headers over prose
-- SCANNABLE: Key decisions in obvious places, not buried in paragraphs
-- DEFINITIVE: Specific versions and choices, no ambiguity
-- FOCUSED: Technical decisions over rationale (unless beginner level requested)
-
-Adapt verbosity based on user skill level:
-
-- Beginner: Include explanations, but keep them brief and clear
-- Intermediate: Focus on decisions with minimal explanation
-- Expert: Purely technical specifications, no hand-holding
-
-Remember: Future LLMs need to quickly extract architectural decisions to implement stories consistently.
-</critical>
+<critical>DOCUMENT OUTPUT: Concise, technical, LLM-optimized. Use tables/lists over prose. Specific versions only. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
 
 <step n="0" goal="Validate workflow and extract project configuration">
 
@@ -182,19 +166,34 @@ Proceeding with solution architecture workflow...
 
 <action>Engage with the user to understand their technical context and preferences:
 
-- Gauge their experience level with the identified project type
+- Note: User skill level is {user_skill_level} (from config)
 - Learn about any existing technical decisions or constraints
 - Understand team capabilities and preferences
 - Identify any existing infrastructure or systems to integrate with
   </action>
 
-<action>Based on the conversation, determine the appropriate level of detail for the architecture document:
+<action>Based on {user_skill_level}, adapt YOUR CONVERSATIONAL STYLE:
 
-- For beginners: Include brief explanations of architectural choices
-- For intermediate: Balance decisions with key rationale
-- For experts: Focus purely on technical specifications
+<check if="{user_skill_level} == 'beginner'">
+  - Explain architectural concepts as you discuss them
+  - Be patient and educational in your responses
+  - Clarify technical terms when introducing them
+</check>
 
-Remember the OUTPUT OPTIMIZATION critical - even beginner explanations should be concise.
+<check if="{user_skill_level} == 'intermediate'">
+  - Balance explanations with efficiency
+  - Assume familiarity with common concepts
+  - Explain only complex or unusual patterns
+</check>
+
+<check if="{user_skill_level} == 'expert'">
+  - Be direct and technical in discussions
+  - Skip basic explanations
+  - Focus on advanced considerations and edge cases
+</check>
+
+NOTE: This affects only how you TALK to the user, NOT the documents you generate.
+The architecture document itself should always be concise and technical.
 </action>
 
 <template-output>user_context</template-output>
@@ -231,20 +230,27 @@ Remember the OUTPUT OPTIMIZATION critical - even beginner explanations should be
 
 <step n="5" goal="Make project-specific technical decisions">
 
-<critical>This is a crucial step where we ensure comprehensive architectural coverage.</critical>
+<critical>Use intent-based decision making, not prescriptive checklists.</critical>
 
-<action>Load the project type registry from: {{installed_path}}/project-types/project-types.csv</action>
+<action>Based on requirements analysis, identify the project domain(s).
+Note: Projects can be hybrid (e.g., web + mobile, game + backend service).
 
-<action>Identify the closest matching project type(s) based on the requirements analysis. Note that projects may be hybrid (e.g., web + mobile, game + backend service).</action>
+Use the simplified project types mapping:
+{{installed_path}}/project-types/project-types.csv
 
-<action>For each identified project type, load the corresponding questions from: {{installed_path}}/project-types/{{question_file}}</action>
+This contains ~11 core project types that cover 99% of software projects.</action>
 
-<action>IMPORTANT: Use the question files as a STARTING POINT, not a complete checklist. The questions help ensure we don't miss common decisions, but you must also:
+<action>For identified domains, reference the intent-based instructions:
+{{installed_path}}/project-types/{{type}}-instructions.md
 
-- Think deeply about project-specific needs not covered in the standard questions
-- Consider unique architectural requirements from the PRD/GDD
-- Address specific integrations or constraints mentioned in requirements
-- Add decisions for any specialized functionality or quality attributes
+These are guidance files, not prescriptive checklists.</action>
+
+<action>IMPORTANT: Instructions are guidance, not checklists.
+
+- Use your knowledge to identify what matters for THIS project
+- Consider emerging technologies not in any list
+- Address unique requirements from the PRD/GDD
+- Focus on decisions that affect implementation consistency
   </action>
 
 <action>Engage with the user to make all necessary technical decisions:
@@ -263,17 +269,27 @@ Remember the OUTPUT OPTIMIZATION critical - even beginner explanations should be
 
 <step n="6" goal="Generate concise solution architecture document">
 
-<action>Load the template registry from: {{installed_path}}/templates/registry.csv</action>
+<action>Select the appropriate adaptive template:
+{{installed_path}}/project-types/{{type}}-template.md</action>
 
-<action>Select the most appropriate template based on:
+<action>Template selection follows the naming convention:
 
-- The identified project type(s)
-- The chosen architecture style
-- The repository strategy
-- The primary technologies selected
-  </action>
+- Web project → web-template.md
+- Mobile app → mobile-template.md
+- Game project → game-template.md (adapts heavily based on game type)
+- Backend service → backend-template.md
+- Data pipeline → data-template.md
+- CLI tool → cli-template.md
+- Library/SDK → library-template.md
+- Desktop app → desktop-template.md
+- Embedded system → embedded-template.md
+- Extension → extension-template.md
+- Infrastructure → infrastructure-template.md
 
-<action>Load the selected template and any associated guides to understand the document structure needed for this type of project.</action>
+For hybrid projects, choose the primary domain or intelligently merge relevant sections from multiple templates.</action>
+
+<action>Adapt the template heavily based on actual requirements.
+Templates are starting points, not rigid structures.</action>
 
 <action>Generate a comprehensive yet concise architecture document that includes:
 
@@ -293,7 +309,8 @@ The document MUST be optimized for LLM consumption:
 - List specific versions, not generic technology names
 - Include complete source tree structure
 - Define clear interfaces and contracts
-- Avoid lengthy explanations unless absolutely necessary
+- NO verbose explanations (even for beginners - they get help in conversation, not docs)
+- Technical and concise throughout
   </action>
 
 <action>Ensure the document provides enough technical specificity that implementation agents can:

src/modules/bmm/workflows/3-solutioning/project-types/backend-instructions.md

@@ -0,0 +1,170 @@
+# Backend/API Service Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for backend/API architecture decisions.
+The LLM should:
+- Analyze the PRD to understand data flows, performance needs, and integrations
+- Guide decisions based on scale, team size, and operational complexity
+- Focus only on relevant architectural areas
+- Make intelligent recommendations that align with project requirements
+- Keep explanations concise and decision-focused
+</critical>
+
+## Service Architecture Pattern
+
+**Determine the Right Architecture**
+Based on the requirements, guide toward the appropriate pattern:
+
+- **Monolith**: For most projects starting out, single deployment, simple operations
+- **Microservices**: Only when there's clear domain separation, large teams, or specific scaling needs
+- **Serverless**: For event-driven workloads, variable traffic, or minimal operations
+- **Modular Monolith**: Best of both worlds for growing projects
+
+Don't default to microservices - most projects benefit from starting simple.
+
+## Language and Framework Selection
+
+**Choose Based on Context**
+Consider these factors intelligently:
+
+- Team expertise (use what the team knows unless there's a compelling reason)
+- Performance requirements (Go/Rust for high performance, Python/Node for rapid development)
+- Ecosystem needs (Python for ML/data, Node for full-stack JS, Java for enterprise)
+- Hiring pool and long-term maintenance
+
+For beginners: Suggest mainstream options with good documentation.
+For experts: Let them specify preferences, discuss specific trade-offs only if asked.
+
+## API Design Philosophy
+
+**Match API Style to Client Needs**
+
+- REST: Default for public APIs, simple CRUD, wide compatibility
+- GraphQL: Multiple clients with different data needs, complex relationships
+- gRPC: Service-to-service communication, high performance binary protocols
+- WebSocket/SSE: Real-time requirements
+
+Don't ask about API paradigm if it's obvious from requirements (e.g., real-time chat needs WebSocket).
+
+## Data Architecture
+
+**Database Decisions Based on Data Characteristics**
+Analyze the data requirements to suggest:
+
+- **Relational** (PostgreSQL/MySQL): Structured data, ACID requirements, complex queries
+- **Document** (MongoDB): Flexible schemas, hierarchical data, rapid prototyping
+- **Key-Value** (Redis/DynamoDB): Caching, sessions, simple lookups
+- **Time-series**: IoT, metrics, event data
+- **Graph**: Social networks, recommendation engines
+
+Consider polyglot persistence only for clear, distinct use cases.
+
+**Data Access Layer**
+
+- ORMs for developer productivity and type safety
+- Query builders for flexibility with some safety
+- Raw SQL only when performance is critical
+
+Match to team expertise and project complexity.
+
+## Security and Authentication
+
+**Security Appropriate to Risk**
+
+- Internal tools: Simple API keys might suffice
+- B2C applications: Managed auth services (Auth0, Firebase Auth)
+- B2B/Enterprise: SAML, SSO, advanced RBAC
+- Financial/Healthcare: Compliance-driven requirements
+
+Don't over-engineer security for prototypes, don't under-engineer for production.
+
+## Messaging and Events
+
+**Only If Required by the Architecture**
+Determine if async processing is actually needed:
+
+- Message queues for decoupling, reliability, buffering
+- Event streaming for event sourcing, real-time analytics
+- Pub/sub for fan-out scenarios
+
+Skip this entirely for simple request-response APIs.
+
+## Operational Considerations
+
+**Observability Based on Criticality**
+
+- Development: Basic logging might suffice
+- Production: Structured logging, metrics, tracing
+- Mission-critical: Full observability stack
+
+**Scaling Strategy**
+
+- Start with vertical scaling (simpler)
+- Plan for horizontal scaling if needed
+- Consider auto-scaling for variable loads
+
+## Performance Requirements
+
+**Right-Size Performance Decisions**
+
+- Don't optimize prematurely
+- Identify actual bottlenecks from requirements
+- Consider caching strategically, not everywhere
+- Database optimization before adding complexity
+
+## Integration Patterns
+
+**External Service Integration**
+Based on the PRD's integration requirements:
+
+- Circuit breakers for resilience
+- Rate limiting for API consumption
+- Webhook patterns for event reception
+- SDK vs. API direct calls
+
+## Deployment Strategy
+
+**Match Deployment to Team Capability**
+
+- Small teams: Managed platforms (Heroku, Railway, Fly.io)
+- DevOps teams: Kubernetes, cloud-native
+- Enterprise: Consider existing infrastructure
+
+**CI/CD Complexity**
+
+- Start simple: Platform auto-deploy
+- Add complexity as needed: testing stages, approvals, rollback
+
+## Adaptive Guidance Examples
+
+**For a REST API serving a mobile app:**
+Focus on response times, offline support, versioning, and push notifications.
+
+**For a data processing pipeline:**
+Emphasize batch vs. stream processing, data validation, error handling, and monitoring.
+
+**For a microservices migration:**
+Discuss service boundaries, data consistency, service discovery, and distributed tracing.
+
+**For an enterprise integration:**
+Focus on security, compliance, audit logging, and existing system compatibility.
+
+## Key Principles
+
+1. **Start simple, evolve as needed** - Don't build for imaginary scale
+2. **Use boring technology** - Proven solutions over cutting edge
+3. **Optimize for your constraint** - Development speed, performance, or operations
+4. **Make reversible decisions** - Avoid early lock-in
+5. **Document the "why"** - But keep it brief
+
+## Output Format
+
+Structure decisions as:
+
+- **Choice**: [Specific technology with version]
+- **Rationale**: [One sentence why this fits the requirements]
+- **Trade-off**: [What we're optimizing for vs. what we're accepting]
+
+Keep technical decisions definitive and version-specific for LLM consumption.

src/modules/bmm/workflows/3-solutioning/project-types/backend-questions.md

@@ -1,490 +0,0 @@
-# Backend/API Service Architecture Questions
-
-## Service Type and Architecture
-
-1. **Service architecture:**
-   - Monolithic API (single service)
-   - Microservices (multiple independent services)
-   - Modular monolith (single deployment, modular code)
-   - Serverless (AWS Lambda, Cloud Functions, etc.)
-   - Hybrid
-
-2. **API paradigm:**
-   - REST
-   - GraphQL
-   - gRPC
-   - WebSocket (real-time)
-   - Server-Sent Events (SSE)
-   - Message-based (event-driven)
-   - Multiple paradigms
-
-3. **Communication patterns:**
-   - Synchronous (request-response)
-   - Asynchronous (message queues)
-   - Event-driven (pub/sub)
-   - Webhooks
-   - Multiple patterns
-
-## Framework and Language
-
-4. **Backend language/framework:**
-   - Node.js (Express, Fastify, NestJS, Hono)
-   - Python (FastAPI, Django, Flask)
-   - Go (Gin, Echo, Chi, standard lib)
-   - Java/Kotlin (Spring Boot, Micronaut, Quarkus)
-   - C# (.NET Core, ASP.NET)
-   - Ruby (Rails, Sinatra)
-   - Rust (Axum, Actix, Rocket)
-   - PHP (Laravel, Symfony)
-   - Elixir (Phoenix)
-   - Other: **\_\_\_**
-
-5. **GraphQL implementation (if applicable):**
-   - Apollo Server
-   - GraphQL Yoga
-   - Hasura (auto-generated)
-   - Postgraphile
-   - Custom
-   - Not using GraphQL
-
-6. **gRPC implementation (if applicable):**
-   - Protocol Buffers
-   - Language-specific gRPC libraries
-   - Not using gRPC
-
-## Database and Data Layer
-
-7. **Primary database:**
-   - PostgreSQL
-   - MySQL/MariaDB
-   - MongoDB
-   - DynamoDB (AWS)
-   - Firestore (Google)
-   - CockroachDB
-   - Cassandra
-   - Redis (as primary)
-   - Multiple databases (polyglot persistence)
-   - Other: **\_\_\_**
-
-8. **Database access pattern:**
-   - ORM (Prisma, TypeORM, SQLAlchemy, Hibernate, etc.)
-   - Query builder (Knex, Kysely, jOOQ)
-   - Raw SQL
-   - Database SDK (Supabase, Firebase)
-   - Mix
-
-9. **Caching layer:**
-   - Redis
-   - Memcached
-   - In-memory (application cache)
-   - CDN caching (for static responses)
-   - Database query cache
-   - None needed
-
-10. **Read replicas:**
-    - Yes (separate read/write databases)
-    - No (single database)
-    - Planned for future
-
-11. **Database sharding:**
-    - Yes (horizontal partitioning)
-    - No (single database)
-    - Planned for scale
-
-## Authentication and Authorization
-
-12. **Authentication method:**
-    - JWT (stateless)
-    - Session-based (stateful)
-    - OAuth2 provider (Auth0, Okta, Keycloak)
-    - API keys
-    - Mutual TLS (mTLS)
-    - Multiple methods
-
-13. **Authorization pattern:**
-    - Role-Based Access Control (RBAC)
-    - Attribute-Based Access Control (ABAC)
-    - Access Control Lists (ACL)
-    - Custom logic
-    - None (open API)
-
-14. **Identity provider:**
-    - Self-managed (own user database)
-    - Auth0
-    - AWS Cognito
-    - Firebase Auth
-    - Keycloak
-    - Azure AD / Entra ID
-    - Okta
-    - Other: **\_\_\_**
-
-## Message Queue and Event Streaming
-
-15. **Message queue (if needed):**
-    - RabbitMQ
-    - Apache Kafka
-    - AWS SQS
-    - Google Pub/Sub
-    - Redis (pub/sub)
-    - NATS
-    - None needed
-    - Other: **\_\_\_**
-
-16. **Event streaming (if needed):**
-    - Apache Kafka
-    - AWS Kinesis
-    - Azure Event Hubs
-    - Redis Streams
-    - None needed
-
-17. **Background jobs:**
-    - Queue-based (Bull, Celery, Sidekiq)
-    - Cron-based (node-cron, APScheduler)
-    - Serverless functions (scheduled Lambda)
-    - None needed
-
-## Service Communication (Microservices)
-
-18. **Service mesh (if microservices):**
-    - Istio
-    - Linkerd
-    - Consul
-    - None (direct communication)
-    - Not applicable
-
-19. **Service discovery:**
-    - Kubernetes DNS
-    - Consul
-    - etcd
-    - AWS Cloud Map
-    - Hardcoded (for now)
-    - Not applicable
-
-20. **Inter-service communication:**
-    - HTTP/REST
-    - gRPC
-    - Message queue
-    - Event bus
-    - Not applicable
-
-## API Design and Documentation
-
-21. **API versioning:**
-    - URL versioning (/v1/, /v2/)
-    - Header versioning (Accept-Version)
-    - No versioning (single version)
-    - Semantic versioning
-
-22. **API documentation:**
-    - OpenAPI/Swagger
-    - GraphQL introspection/playground
-    - Postman collections
-    - Custom docs
-    - README only
-
-23. **API testing tools:**
-    - Postman
-    - Insomnia
-    - REST Client (VS Code)
-    - cURL examples
-    - Multiple tools
-
-## Rate Limiting and Throttling
-
-24. **Rate limiting:**
-    - Per-user/API key
-    - Per-IP
-    - Global rate limit
-    - Tiered (different limits per plan)
-    - None (internal API)
-
-25. **Rate limit implementation:**
-    - Application-level (middleware)
-    - API Gateway
-    - Redis-based
-    - None
-
-## Data Validation and Processing
-
-26. **Request validation:**
-    - Schema validation (Zod, Joi, Yup, Pydantic)
-    - Manual validation
-    - Framework built-in
-    - None
-
-27. **Data serialization:**
-    - JSON
-    - Protocol Buffers
-    - MessagePack
-    - XML
-    - Multiple formats
-
-28. **File uploads (if applicable):**
-    - Direct to server (local storage)
-    - S3/Cloud storage
-    - Presigned URLs (client direct upload)
-    - None needed
-
-## Error Handling and Resilience
-
-29. **Error handling strategy:**
-    - Standard HTTP status codes
-    - Custom error codes
-    - RFC 7807 (Problem Details)
-    - GraphQL errors
-    - Mix
-
-30. **Circuit breaker (for external services):**
-    - Yes (Hystrix, Resilience4j, Polly)
-    - No (direct calls)
-    - Not needed
-
-31. **Retry logic:**
-    - Exponential backoff
-    - Fixed retries
-    - No retries
-    - Library-based (axios-retry, etc.)
-
-32. **Graceful shutdown:**
-    - Yes (drain connections, finish requests)
-    - No (immediate shutdown)
-
-## Observability
-
-33. **Logging:**
-    - Structured logging (JSON)
-    - Plain text logs
-    - Library: (Winston, Pino, Logrus, Zap, etc.)
-
-34. **Log aggregation:**
-    - ELK Stack (Elasticsearch, Logstash, Kibana)
-    - Datadog
-    - Splunk
-    - CloudWatch Logs
-    - Loki + Grafana
-    - None (local logs)
-
-35. **Metrics and Monitoring:**
-    - Prometheus
-    - Datadog
-    - New Relic
-    - Application Insights
-    - CloudWatch
-    - Grafana
-    - None
-
-36. **Distributed tracing:**
-    - OpenTelemetry
-    - Jaeger
-    - Zipkin
-    - Datadog APM
-    - AWS X-Ray
-    - None
-
-37. **Health checks:**
-    - Liveness probe (is service up?)
-    - Readiness probe (can accept traffic?)
-    - Startup probe
-    - Dependency checks (database, cache, etc.)
-    - None
-
-38. **Alerting:**
-    - PagerDuty
-    - Opsgenie
-    - Slack/Discord webhooks
-    - Email
-    - Custom
-    - None
-
-## Security
-
-39. **HTTPS/TLS:**
-    - Required (HTTPS only)
-    - Optional (support both)
-    - Terminated at load balancer
-
-40. **CORS configuration:**
-    - Specific origins (whitelist)
-    - All origins (open)
-    - None needed (same-origin clients)
-
-41. **Security headers:**
-    - Helmet.js or equivalent
-    - Custom headers
-    - None (basic)
-
-42. **Input sanitization:**
-    - SQL injection prevention (parameterized queries)
-    - XSS prevention
-    - CSRF protection
-    - All of the above
-
-43. **Secrets management:**
-    - Environment variables
-    - AWS Secrets Manager
-    - HashiCorp Vault
-    - Azure Key Vault
-    - Kubernetes Secrets
-    - Doppler
-    - Other: **\_\_\_**
-
-44. **Compliance requirements:**
-    - GDPR
-    - HIPAA
-    - SOC 2
-    - PCI DSS
-    - None
-
-## Deployment and Infrastructure
-
-45. **Deployment platform:**
-    - AWS (ECS, EKS, Lambda, Elastic Beanstalk)
-    - Google Cloud (GKE, Cloud Run, App Engine)
-    - Azure (AKS, App Service, Container Instances)
-    - Kubernetes (self-hosted)
-    - Docker Swarm
-    - Heroku
-    - Railway
-    - Fly.io
-    - Vercel/Netlify (serverless)
-    - VPS (DigitalOcean, Linode)
-    - On-premise
-    - Other: **\_\_\_**
-
-46. **Containerization:**
-    - Docker
-    - Podman
-    - Not containerized (direct deployment)
-
-47. **Orchestration:**
-    - Kubernetes
-    - Docker Compose (dev/small scale)
-    - AWS ECS
-    - Nomad
-    - None (single server)
-
-48. **Infrastructure as Code:**
-    - Terraform
-    - CloudFormation
-    - Pulumi
-    - Bicep (Azure)
-    - CDK (AWS)
-    - Ansible
-    - Manual setup
-
-49. **Load balancing:**
-    - Application Load Balancer (AWS ALB, Azure App Gateway)
-    - Nginx
-    - HAProxy
-    - Kubernetes Ingress
-    - Traefik
-    - Platform-managed
-    - None (single instance)
-
-50. **Auto-scaling:**
-    - Horizontal (add more instances)
-    - Vertical (increase instance size)
-    - Serverless (automatic)
-    - None (fixed capacity)
-
-## CI/CD
-
-51. **CI/CD platform:**
-    - GitHub Actions
-    - GitLab CI
-    - CircleCI
-    - Jenkins
-    - AWS CodePipeline
-    - Azure DevOps
-    - Google Cloud Build
-    - Other: **\_\_\_**
-
-52. **Deployment strategy:**
-    - Rolling deployment
-    - Blue-green deployment
-    - Canary deployment
-    - Recreate (downtime)
-    - Serverless (automatic)
-
-53. **Testing in CI/CD:**
-    - Unit tests
-    - Integration tests
-    - E2E tests
-    - Load tests
-    - Security scans
-    - All of the above
-
-## Performance
-
-54. **Performance requirements:**
-    - High throughput (1000+ req/s)
-    - Moderate (100-1000 req/s)
-    - Low (< 100 req/s)
-
-55. **Latency requirements:**
-    - Ultra-low (< 10ms)
-    - Low (< 100ms)
-    - Moderate (< 500ms)
-    - No specific requirement
-
-56. **Connection pooling:**
-    - Database connection pool
-    - HTTP connection pool (for external APIs)
-    - None needed
-
-57. **CDN (for static assets):**
-    - CloudFront
-    - Cloudflare
-    - Fastly
-    - None (dynamic only)
-
-## Data and Storage
-
-58. **File storage (if needed):**
-    - AWS S3
-    - Google Cloud Storage
-    - Azure Blob Storage
-    - MinIO (self-hosted)
-    - Local filesystem
-    - None needed
-
-59. **Search functionality:**
-    - Elasticsearch
-    - Algolia
-    - Meilisearch
-    - Typesense
-    - Database full-text search
-    - None needed
-
-60. **Data backup:**
-    - Automated database backups
-    - Point-in-time recovery
-    - Manual backups
-    - Cloud-provider managed
-    - None (dev/test only)
-
-## Additional Features
-
-61. **Webhooks (outgoing):**
-    - Yes (notify external systems)
-    - No
-
-62. **Scheduled tasks/Cron jobs:**
-    - Yes (cleanup, reports, etc.)
-    - No
-
-63. **Multi-tenancy:**
-    - Single tenant
-    - Multi-tenant (shared database)
-    - Multi-tenant (separate databases)
-    - Not applicable
-
-64. **Internationalization (i18n):**
-    - Multiple languages/locales
-    - English only
-    - Not applicable
-
-65. **Audit logging:**
-    - Track all changes (who, what, when)
-    - Critical operations only
-    - None

src/modules/bmm/workflows/3-solutioning/project-types/cli-instructions.md

@@ -0,0 +1,149 @@
+# CLI Tool Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for CLI tool architecture decisions.
+The LLM should:
+- Understand the tool's purpose and target users from requirements
+- Guide framework choice based on distribution needs and complexity
+- Focus on CLI-specific UX patterns
+- Consider packaging and distribution strategy
+- Keep it simple unless complexity is justified
+</critical>
+
+## Language and Framework Selection
+
+**Choose Based on Distribution and Users**
+
+- **Node.js**: NPM distribution, JavaScript ecosystem, cross-platform
+- **Go**: Single binary distribution, excellent performance
+- **Python**: Data/science tools, rich ecosystem, pip distribution
+- **Rust**: Performance-critical, memory-safe, growing ecosystem
+- **Bash**: Simple scripts, Unix-only, no dependencies
+
+Consider your users: Developers might have Node/Python, but end users need standalone binaries.
+
+## CLI Framework Choice
+
+**Match Complexity to Needs**
+Based on the tool's requirements:
+
+- **Simple scripts**: Use built-in argument parsing
+- **Command-based**: Commander.js, Click, Cobra, Clap
+- **Interactive**: Inquirer, Prompt, Dialoguer
+- **Full TUI**: Blessed, Bubble Tea, Ratatui
+
+Don't use a heavy framework for a simple script, but don't parse args manually for complex CLIs.
+
+## Command Architecture
+
+**Command Structure Design**
+
+- Single command vs. sub-commands
+- Flag and argument patterns
+- Configuration file support
+- Environment variable integration
+
+Follow platform conventions (POSIX-style flags, standard exit codes).
+
+## User Experience Patterns
+
+**CLI UX Best Practices**
+
+- Help text and usage examples
+- Progress indicators for long operations
+- Colored output for clarity
+- Machine-readable output options (JSON, quiet mode)
+- Sensible defaults with override options
+
+## Configuration Management
+
+**Settings Strategy**
+Based on tool complexity:
+
+- Command-line flags for one-off changes
+- Config files for persistent settings
+- Environment variables for deployment config
+- Cascading configuration (defaults → config → env → flags)
+
+## Error Handling
+
+**User-Friendly Errors**
+
+- Clear error messages with actionable fixes
+- Exit codes following conventions
+- Verbose/debug modes for troubleshooting
+- Graceful handling of common issues
+
+## Installation and Distribution
+
+**Packaging Strategy**
+
+- **NPM/PyPI**: For developer tools
+- **Homebrew/Snap/Chocolatey**: For end-user tools
+- **Binary releases**: GitHub releases with multiple platforms
+- **Docker**: For complex dependencies
+- **Shell script**: For simple Unix tools
+
+## Testing Strategy
+
+**CLI Testing Approach**
+
+- Unit tests for core logic
+- Integration tests for commands
+- Snapshot testing for output
+- Cross-platform testing if targeting multiple OS
+
+## Performance Considerations
+
+**Optimization Where Needed**
+
+- Startup time for frequently-used commands
+- Streaming for large data processing
+- Parallel execution where applicable
+- Efficient file system operations
+
+## Plugin Architecture
+
+**Extensibility** (if needed)
+
+- Plugin system design
+- Hook mechanisms
+- API for extensions
+- Plugin discovery and loading
+
+Only if the PRD indicates extensibility requirements.
+
+## Adaptive Guidance Examples
+
+**For a Build Tool:**
+Focus on performance, watch mode, configuration management, and plugin system.
+
+**For a Dev Utility:**
+Emphasize developer experience, integration with existing tools, and clear output.
+
+**For a Data Processing Tool:**
+Focus on streaming, progress reporting, error recovery, and format conversion.
+
+**For a System Admin Tool:**
+Emphasize permission handling, logging, dry-run mode, and safety checks.
+
+## Key Principles
+
+1. **Follow platform conventions** - Users expect familiar patterns
+2. **Fail fast with clear errors** - Don't leave users guessing
+3. **Provide escape hatches** - Debug mode, verbose output, dry runs
+4. **Document through examples** - Show, don't just tell
+5. **Respect user time** - Fast startup, helpful defaults
+
+## Output Format
+
+Document as:
+
+- **Language**: [Choice with version]
+- **Framework**: [CLI framework if applicable]
+- **Distribution**: [How users will install]
+- **Key commands**: [Primary user interactions]
+
+Keep focus on user-facing behavior and implementation simplicity.

src/modules/bmm/workflows/3-solutioning/project-types/cli-questions.md

@@ -1,337 +0,0 @@
-# Command-Line Tool Architecture Questions
-
-## Language and Runtime
-
-1. **Primary language:**
-   - Go (compiled, single binary, great for CLIs)
-   - Rust (compiled, safe, performant)
-   - Python (interpreted, easy distribution via pip)
-   - Node.js/TypeScript (npm distribution)
-   - Bash/Shell script (lightweight, ubiquitous)
-   - Ruby (gem distribution)
-   - Java/Kotlin (JVM, jar)
-   - C/C++ (compiled, fastest)
-   - Other: **\_\_\_**
-
-2. **Target platforms:**
-   - Linux only
-   - macOS only
-   - Windows only
-   - Linux + macOS
-   - All three (Linux + macOS + Windows)
-   - Specific Unix variants: **\_\_\_**
-
-3. **Distribution method:**
-   - Single binary (compiled)
-   - Script (interpreted, needs runtime)
-   - Package manager (npm, pip, gem, cargo, etc.)
-   - Installer (brew, apt, yum, scoop, chocolatey)
-   - Container (Docker)
-   - Multiple methods
-
-## CLI Architecture
-
-4. **Command structure:**
-   - Single command (e.g., `grep pattern file`)
-   - Subcommands (e.g., `git commit`, `docker run`)
-   - Hybrid (main command + subcommands)
-   - Interactive shell (REPL)
-
-5. **Argument parsing library:**
-   - Go: cobra, cli, flag
-   - Rust: clap, structopt
-   - Python: argparse, click, typer
-   - Node: commander, yargs, oclif
-   - Bash: getopts, manual parsing
-   - Other: **\_\_\_**
-
-6. **Interactive mode:**
-   - Non-interactive only (runs and exits)
-   - Interactive prompts (inquirer, survey, etc.)
-   - REPL/shell mode
-   - Both modes supported
-
-7. **Long-running process:**
-   - Quick execution (completes immediately)
-   - Long-running (daemon/service)
-   - Can run in background
-   - Watch mode (monitors and reacts)
-
-## Input/Output
-
-8. **Input sources:**
-   - Command-line arguments
-   - Flags/options
-   - Environment variables
-   - Config file (JSON, YAML, TOML, INI)
-   - Interactive prompts
-   - Stdin (pipe input)
-   - Multiple sources
-
-9. **Output format:**
-   - Plain text (human-readable)
-   - JSON
-   - YAML
-   - XML
-   - CSV/TSV
-   - Table format
-   - User-selectable format
-   - Multiple formats
-
-10. **Output destination:**
-    - Stdout (standard output)
-    - Stderr (errors only)
-    - File output
-    - Multiple destinations
-    - Quiet mode (no output)
-
-11. **Colored output:**
-    - ANSI color codes
-    - Auto-detect TTY (color when terminal, plain when piped)
-    - User-configurable (--color flag)
-    - No colors (plain text only)
-
-12. **Progress indication:**
-    - Progress bars (for long operations)
-    - Spinners (for waiting)
-    - Step-by-step output
-    - Verbose/debug logging
-    - Silent mode option
-    - None needed (fast operations)
-
-## Configuration
-
-13. **Configuration file:**
-    - Required (must exist)
-    - Optional (defaults if missing)
-    - Not needed
-    - Generated on first run
-
-14. **Config file format:**
-    - JSON
-    - YAML
-    - TOML
-    - INI
-    - Custom format
-    - Multiple formats supported
-
-15. **Config file location:**
-    - Current directory (project-specific)
-    - User home directory (~/.config, ~/.myapp)
-    - System-wide (/etc/)
-    - User-specified path
-    - Multiple locations (cascade/merge)
-
-16. **Environment variables:**
-    - Used for configuration
-    - Used for secrets/credentials
-    - Used for runtime behavior
-    - Not used
-
-## Data and Storage
-
-17. **Persistent data:**
-    - Cache (temporary, can be deleted)
-    - State (must persist)
-    - User data (important)
-    - No persistent data needed
-
-18. **Data storage location:**
-    - Standard OS locations (XDG Base Directory, AppData, etc.)
-    - Current directory
-    - User-specified
-    - Temporary directory
-
-19. **Database/Data format:**
-    - SQLite
-    - JSON files
-    - Key-value store (BoltDB, etc.)
-    - CSV/plain files
-    - Remote database
-    - None needed
-
-## Execution Model
-
-20. **Execution pattern:**
-    - Run once and exit
-    - Watch mode (monitor changes)
-    - Server/daemon mode
-    - Cron-style (scheduled)
-    - Pipeline component (part of Unix pipeline)
-
-21. **Concurrency:**
-    - Single-threaded (sequential)
-    - Multi-threaded (parallel operations)
-    - Async I/O
-    - Not applicable
-
-22. **Signal handling:**
-    - Graceful shutdown (SIGTERM, SIGINT)
-    - Cleanup on exit
-    - Not needed (quick exit)
-
-## Networking (if applicable)
-
-23. **Network operations:**
-    - HTTP client (REST API calls)
-    - WebSocket client
-    - SSH client
-    - Database connections
-    - Other protocols: **\_\_\_**
-    - No networking
-
-24. **Authentication (if API calls):**
-    - API keys (env vars, config)
-    - OAuth2 flow
-    - Username/password
-    - Certificate-based
-    - None needed
-
-## Error Handling
-
-25. **Error reporting:**
-    - Stderr with error messages
-    - Exit codes (0 = success, non-zero = error)
-    - Detailed error messages
-    - Stack traces (debug mode)
-    - Simple messages (user-friendly)
-
-26. **Exit codes:**
-    - Standard (0 = success, 1 = error)
-    - Multiple exit codes (different error types)
-    - Documented exit codes
-
-27. **Logging:**
-    - Log levels (debug, info, warn, error)
-    - Log file output
-    - Stderr output
-    - Configurable verbosity (--verbose, --quiet)
-    - No logging (simple tool)
-
-## Piping and Integration
-
-28. **Stdin support:**
-    - Reads from stdin (pipe input)
-    - Optional stdin (file or stdin)
-    - No stdin support
-
-29. **Pipeline behavior:**
-    - Filter (reads stdin, writes stdout)
-    - Generator (no input, outputs data)
-    - Consumer (reads input, no stdout)
-    - Transformer (both input and output)
-
-30. **Shell completion:**
-    - Bash completion
-    - Zsh completion
-    - Fish completion
-    - PowerShell completion
-    - All shells
-    - None
-
-## Distribution and Installation
-
-31. **Package managers:**
-    - Homebrew (macOS/Linux)
-    - apt (Debian/Ubuntu)
-    - yum/dnf (RHEL/Fedora)
-    - Chocolatey/Scoop (Windows)
-    - npm/yarn (Node.js)
-    - pip (Python)
-    - cargo (Rust)
-    - Multiple managers
-    - Manual install only
-
-32. **Installation method:**
-    - Download binary (GitHub Releases)
-    - Install script (curl | bash)
-    - Package manager
-    - Build from source
-    - Container image
-    - Multiple methods
-
-33. **Binary distribution:**
-    - Single binary (statically linked)
-    - Multiple binaries (per platform)
-    - With dependencies (bundled)
-
-34. **Cross-compilation:**
-    - Yes (build for all platforms from one machine)
-    - No (need platform-specific builds)
-
-## Updates
-
-35. **Update mechanism:**
-    - Self-update command
-    - Package manager update
-    - Manual download
-    - No updates (stable tool)
-
-36. **Version checking:**
-    - Check for new versions on run
-    - --version flag
-    - No version tracking
-
-## Documentation
-
-37. **Help documentation:**
-    - --help flag (inline help)
-    - Man page
-    - Online docs
-    - README only
-    - All of the above
-
-38. **Examples/Tutorials:**
-    - Built-in examples (--examples)
-    - Online documentation
-    - README with examples
-    - None (self-explanatory)
-
-## Testing
-
-39. **Testing approach:**
-    - Unit tests
-    - Integration tests (full CLI execution)
-    - Snapshot testing (output comparison)
-    - Manual testing
-    - All of the above
-
-40. **CI/CD:**
-    - GitHub Actions
-    - GitLab CI
-    - Travis CI
-    - Cross-platform testing
-    - Manual builds
-
-## Performance
-
-41. **Performance requirements:**
-    - Must be fast (< 100ms)
-    - Moderate (< 1s)
-    - Can be slow (long-running tasks)
-
-42. **Memory usage:**
-    - Minimal (small files/data)
-    - Streaming (large files, low memory)
-    - Can use significant memory
-
-## Special Features
-
-43. **Watch mode:**
-    - Monitor files/directories for changes
-    - Auto-reload/re-run
-    - Not needed
-
-44. **Dry-run mode:**
-    - Preview changes without applying
-    - Not applicable
-
-45. **Verbose/Debug mode:**
-    - --verbose flag (detailed output)
-    - --debug flag (even more detail)
-    - Not needed
-
-46. **Plugins/Extensions:**
-    - Plugin system (user can extend)
-    - Monolithic (no plugins)
-    - Planned for future

src/modules/bmm/workflows/3-solutioning/project-types/data-instructions.md

@@ -0,0 +1,193 @@
+# Data Pipeline/Analytics Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for data pipeline and analytics architecture decisions.
+The LLM should:
+- Understand data volume, velocity, and variety from requirements
+- Guide tool selection based on scale and latency needs
+- Consider data governance and quality requirements
+- Balance batch vs. stream processing needs
+- Focus on maintainability and observability
+</critical>
+
+## Processing Architecture
+
+**Batch vs. Stream vs. Hybrid**
+Based on requirements:
+
+- **Batch**: For periodic processing, large volumes, complex transformations
+- **Stream**: For real-time requirements, event-driven, continuous processing
+- **Lambda Architecture**: Both batch and stream for different use cases
+- **Kappa Architecture**: Stream-only with replay capability
+
+Don't use streaming for daily reports, or batch for real-time alerts.
+
+## Technology Stack
+
+**Choose Based on Scale and Complexity**
+
+- **Small Scale**: Python scripts, Pandas, PostgreSQL
+- **Medium Scale**: Airflow, Spark, Redshift/BigQuery
+- **Large Scale**: Databricks, Snowflake, custom Kubernetes
+- **Real-time**: Kafka, Flink, ClickHouse, Druid
+
+Start simple and evolve - don't build for imaginary scale.
+
+## Orchestration Platform
+
+**Workflow Management**
+Based on complexity:
+
+- **Simple**: Cron jobs, Python scripts
+- **Medium**: Apache Airflow, Prefect, Dagster
+- **Complex**: Kubernetes Jobs, Argo Workflows
+- **Managed**: Cloud Composer, AWS Step Functions
+
+Consider team expertise and operational overhead.
+
+## Data Storage Architecture
+
+**Storage Layer Design**
+
+- **Data Lake**: Raw data in object storage (S3, GCS)
+- **Data Warehouse**: Structured, optimized for analytics
+- **Data Lakehouse**: Hybrid approach (Delta Lake, Iceberg)
+- **Operational Store**: For serving layer
+
+**File Formats**
+
+- Parquet for columnar analytics
+- Avro for row-based streaming
+- JSON for flexibility
+- CSV for simplicity
+
+## ETL/ELT Strategy
+
+**Transformation Approach**
+
+- **ETL**: Transform before loading (traditional)
+- **ELT**: Transform in warehouse (modern, scalable)
+- **Streaming ETL**: Continuous transformation
+
+Consider compute costs and transformation complexity.
+
+## Data Quality Framework
+
+**Quality Assurance**
+
+- Schema validation
+- Data profiling and anomaly detection
+- Completeness and freshness checks
+- Lineage tracking
+- Quality metrics and monitoring
+
+Build quality checks appropriate to data criticality.
+
+## Schema Management
+
+**Schema Evolution**
+
+- Schema registry for streaming
+- Version control for schemas
+- Backward compatibility strategy
+- Schema inference vs. strict schemas
+
+## Processing Frameworks
+
+**Computation Engines**
+
+- **Spark**: General-purpose, batch and stream
+- **Flink**: Low-latency streaming
+- **Beam**: Portable, multi-runtime
+- **Pandas/Polars**: Small-scale, in-memory
+- **DuckDB**: Local analytical processing
+
+Match framework to processing patterns.
+
+## Data Modeling
+
+**Analytical Modeling**
+
+- Star schema for BI tools
+- Data vault for flexibility
+- Wide tables for performance
+- Time-series modeling for metrics
+
+Consider query patterns and tool requirements.
+
+## Monitoring and Observability
+
+**Pipeline Monitoring**
+
+- Job success/failure tracking
+- Data quality metrics
+- Processing time and throughput
+- Cost monitoring
+- Alerting strategy
+
+## Security and Governance
+
+**Data Governance**
+
+- Access control and permissions
+- Data encryption at rest and transit
+- PII handling and masking
+- Audit logging
+- Compliance requirements (GDPR, HIPAA)
+
+Scale governance to regulatory requirements.
+
+## Development Practices
+
+**DataOps Approach**
+
+- Version control for code and configs
+- Testing strategy (unit, integration, data)
+- CI/CD for pipelines
+- Environment management
+- Documentation standards
+
+## Serving Layer
+
+**Data Consumption**
+
+- BI tool integration
+- API for programmatic access
+- Export capabilities
+- Caching strategy
+- Query optimization
+
+## Adaptive Guidance Examples
+
+**For Real-time Analytics:**
+Focus on streaming infrastructure, low-latency storage, and real-time dashboards.
+
+**For ML Feature Store:**
+Emphasize feature computation, versioning, serving latency, and training/serving skew.
+
+**For Business Intelligence:**
+Focus on dimensional modeling, semantic layer, and self-service analytics.
+
+**For Log Analytics:**
+Emphasize ingestion scale, retention policies, and search capabilities.
+
+## Key Principles
+
+1. **Start with the end in mind** - Know how data will be consumed
+2. **Design for failure** - Pipelines will break, plan recovery
+3. **Monitor everything** - You can't fix what you can't see
+4. **Version and test** - Data pipelines are code
+5. **Keep it simple** - Complexity kills maintainability
+
+## Output Format
+
+Document as:
+
+- **Processing**: [Batch/Stream/Hybrid approach]
+- **Stack**: [Core technologies with versions]
+- **Storage**: [Lake/Warehouse strategy]
+- **Orchestration**: [Workflow platform]
+
+Focus on data flow and transformation logic.

src/modules/bmm/workflows/3-solutioning/project-types/data-questions.md

@@ -1,472 +0,0 @@
-# Data/Analytics/ML Project Architecture Questions
-
-## Project Type and Scope
-
-1. **Primary project focus:**
-   - ETL/Data Pipeline (move and transform data)
-   - Data Analytics (BI, dashboards, reports)
-   - Machine Learning Training (build models)
-   - Machine Learning Inference (serve predictions)
-   - Data Warehouse/Lake (centralized data storage)
-   - Real-time Stream Processing
-   - Data Science Research/Exploration
-   - Multiple focuses
-
-2. **Scale of data:**
-   - Small (< 1GB, single machine)
-   - Medium (1GB - 1TB, can fit in memory with careful handling)
-   - Large (1TB - 100TB, distributed processing needed)
-   - Very Large (> 100TB, big data infrastructure)
-
-3. **Data velocity:**
-   - Batch (hourly, daily, weekly)
-   - Micro-batch (every few minutes)
-   - Near real-time (seconds)
-   - Real-time streaming (milliseconds)
-   - Mix
-
-## Programming Language and Environment
-
-4. **Primary language:**
-   - Python (pandas, numpy, sklearn, pytorch, tensorflow)
-   - R (tidyverse, caret)
-   - Scala (Spark)
-   - SQL (analytics, transformations)
-   - Java (enterprise data pipelines)
-   - Julia
-   - Multiple languages
-
-5. **Development environment:**
-   - Jupyter Notebooks (exploration)
-   - Production code (scripts/applications)
-   - Both (notebooks for exploration, code for production)
-   - Cloud notebooks (SageMaker, Vertex AI, Databricks)
-
-6. **Transition from notebooks to production:**
-   - Convert notebooks to scripts
-   - Use notebooks in production (Papermill, nbconvert)
-   - Keep separate (research vs production)
-
-## Data Sources
-
-7. **Data source types:**
-   - Relational databases (PostgreSQL, MySQL, SQL Server)
-   - NoSQL databases (MongoDB, Cassandra)
-   - Data warehouses (Snowflake, BigQuery, Redshift)
-   - APIs (REST, GraphQL)
-   - Files (CSV, JSON, Parquet, Avro)
-   - Streaming sources (Kafka, Kinesis, Pub/Sub)
-   - Cloud storage (S3, GCS, Azure Blob)
-   - SaaS platforms (Salesforce, HubSpot, etc.)
-   - Multiple sources
-
-8. **Data ingestion frequency:**
-   - One-time load
-   - Scheduled batch (daily, hourly)
-   - Real-time/streaming
-   - On-demand
-   - Mix
-
-9. **Data ingestion tools:**
-   - Custom scripts (Python, SQL)
-   - Airbyte
-   - Fivetran
-   - Stitch
-   - Apache NiFi
-   - Kafka Connect
-   - Cloud-native (AWS DMS, Google Datastream)
-   - Multiple tools
-
-## Data Storage
-
-10. **Primary data storage:**
-    - Data Warehouse (Snowflake, BigQuery, Redshift, Synapse)
-    - Data Lake (S3, GCS, ADLS with Parquet/Avro)
-    - Lakehouse (Databricks, Delta Lake, Iceberg, Hudi)
-    - Relational database
-    - NoSQL database
-    - File system
-    - Multiple storage layers
-
-11. **Storage format (for files):**
-    - Parquet (columnar, optimized)
-    - Avro (row-based, schema evolution)
-    - ORC (columnar, Hive)
-    - CSV (simple, human-readable)
-    - JSON/JSONL
-    - Delta Lake format
-    - Iceberg format
-
-12. **Data partitioning strategy:**
-    - By date (year/month/day)
-    - By category/dimension
-    - By hash
-    - No partitioning (small data)
-
-13. **Data retention policy:**
-    - Keep all data forever
-    - Archive old data (move to cold storage)
-    - Delete after X months/years
-    - Compliance-driven retention
-
-## Data Processing and Transformation
-
-14. **Data processing framework:**
-    - pandas (single machine)
-    - Dask (parallel pandas)
-    - Apache Spark (distributed)
-    - Polars (fast, modern dataframes)
-    - SQL (warehouse-native)
-    - Apache Flink (streaming)
-    - dbt (SQL transformations)
-    - Custom code
-    - Multiple frameworks
-
-15. **Compute platform:**
-    - Local machine (development)
-    - Cloud VMs (EC2, Compute Engine)
-    - Serverless (AWS Lambda, Cloud Functions)
-    - Managed Spark (EMR, Dataproc, Synapse)
-    - Databricks
-    - Snowflake (warehouse compute)
-    - Kubernetes (custom containers)
-    - Multiple platforms
-
-16. **ETL tool (if applicable):**
-    - dbt (SQL transformations)
-    - Apache Airflow (orchestration + code)
-    - Dagster (data orchestration)
-    - Prefect (workflow orchestration)
-    - AWS Glue
-    - Azure Data Factory
-    - Google Dataflow
-    - Custom scripts
-    - None needed
-
-17. **Data quality checks:**
-    - Great Expectations
-    - dbt tests
-    - Custom validation scripts
-    - Soda
-    - Monte Carlo
-    - None (trust source data)
-
-18. **Schema management:**
-    - Schema registry (Confluent, AWS Glue)
-    - Version-controlled schema files
-    - Database schema versioning
-    - Ad-hoc (no formal schema)
-
-## Machine Learning (if applicable)
-
-19. **ML framework:**
-    - scikit-learn (classical ML)
-    - PyTorch (deep learning)
-    - TensorFlow/Keras (deep learning)
-    - XGBoost/LightGBM/CatBoost (gradient boosting)
-    - Hugging Face Transformers (NLP)
-    - spaCy (NLP)
-    - Other: **\_\_\_**
-    - Not applicable
-
-20. **ML use case:**
-    - Classification
-    - Regression
-    - Clustering
-    - Recommendation
-    - NLP (text analysis, generation)
-    - Computer Vision
-    - Time Series Forecasting
-    - Anomaly Detection
-    - Other: **\_\_\_**
-
-21. **Model training infrastructure:**
-    - Local machine (GPU/CPU)
-    - Cloud VMs with GPU (EC2 P/G instances, GCE A2)
-    - SageMaker
-    - Vertex AI
-    - Azure ML
-    - Databricks ML
-    - Lambda Labs / Paperspace
-    - On-premise cluster
-
-22. **Experiment tracking:**
-    - MLflow
-    - Weights and Biases
-    - Neptune.ai
-    - Comet
-    - TensorBoard
-    - SageMaker Experiments
-    - Custom logging
-    - None
-
-23. **Model registry:**
-    - MLflow Model Registry
-    - SageMaker Model Registry
-    - Vertex AI Model Registry
-    - Custom (S3/GCS with metadata)
-    - None
-
-24. **Feature store:**
-    - Feast
-    - Tecton
-    - SageMaker Feature Store
-    - Databricks Feature Store
-    - Vertex AI Feature Store
-    - Custom (database + cache)
-    - Not needed
-
-25. **Hyperparameter tuning:**
-    - Manual tuning
-    - Grid search
-    - Random search
-    - Optuna / Hyperopt (Bayesian optimization)
-    - SageMaker/Vertex AI tuning jobs
-    - Ray Tune
-    - Not needed
-
-26. **Model serving (inference):**
-    - Batch inference (process large datasets)
-    - Real-time API (REST/gRPC)
-    - Streaming inference (Kafka, Kinesis)
-    - Edge deployment (mobile, IoT)
-    - Not applicable (training only)
-
-27. **Model serving platform (if real-time):**
-    - FastAPI + container (self-hosted)
-    - SageMaker Endpoints
-    - Vertex AI Predictions
-    - Azure ML Endpoints
-    - Seldon Core
-    - KServe
-    - TensorFlow Serving
-    - TorchServe
-    - BentoML
-    - Other: **\_\_\_**
-
-28. **Model monitoring (in production):**
-    - Data drift detection
-    - Model performance monitoring
-    - Prediction logging
-    - A/B testing infrastructure
-    - None (not in production yet)
-
-29. **AutoML tools:**
-    - H2O AutoML
-    - Auto-sklearn
-    - TPOT
-    - SageMaker Autopilot
-    - Vertex AI AutoML
-    - Azure AutoML
-    - Not using AutoML
-
-## Orchestration and Workflow
-
-30. **Workflow orchestration:**
-    - Apache Airflow
-    - Prefect
-    - Dagster
-    - Argo Workflows
-    - Kubeflow Pipelines
-    - AWS Step Functions
-    - Azure Data Factory
-    - Google Cloud Composer
-    - dbt Cloud
-    - Cron jobs (simple)
-    - None (manual runs)
-
-31. **Orchestration platform:**
-    - Self-hosted (VMs, K8s)
-    - Managed service (MWAA, Cloud Composer, Prefect Cloud)
-    - Serverless
-    - Multiple platforms
-
-32. **Job scheduling:**
-    - Time-based (daily, hourly)
-    - Event-driven (S3 upload, database change)
-    - Manual trigger
-    - Continuous (always running)
-
-33. **Dependency management:**
-    - DAG-based (upstream/downstream tasks)
-    - Data-driven (task runs when data available)
-    - Simple sequential
-    - None (independent tasks)
-
-## Data Analytics and Visualization
-
-34. **BI/Visualization tool:**
-    - Tableau
-    - Power BI
-    - Looker / Looker Studio
-    - Metabase
-    - Superset
-    - Redash
-    - Grafana
-    - Custom dashboards (Plotly Dash, Streamlit)
-    - Jupyter notebooks
-    - None needed
-
-35. **Reporting frequency:**
-    - Real-time dashboards
-    - Daily reports
-    - Weekly/Monthly reports
-    - Ad-hoc queries
-    - Multiple frequencies
-
-36. **Query interface:**
-    - SQL (direct database queries)
-    - BI tool interface
-    - API (programmatic access)
-    - Notebooks
-    - Multiple interfaces
-
-## Data Governance and Security
-
-37. **Data catalog:**
-    - Amundsen
-    - DataHub
-    - AWS Glue Data Catalog
-    - Azure Purview
-    - Alation
-    - Collibra
-    - None (small team)
-
-38. **Data lineage tracking:**
-    - Automated (DataHub, Amundsen)
-    - Manual documentation
-    - Not tracked
-
-39. **Access control:**
-    - Row-level security (RLS)
-    - Column-level security
-    - Database/warehouse roles
-    - IAM policies (cloud)
-    - None (internal team only)
-
-40. **PII/Sensitive data handling:**
-    - Encryption at rest
-    - Encryption in transit
-    - Data masking
-    - Tokenization
-    - Compliance requirements (GDPR, HIPAA)
-    - None (no sensitive data)
-
-41. **Data versioning:**
-    - DVC (Data Version Control)
-    - LakeFS
-    - Delta Lake time travel
-    - Git LFS (for small data)
-    - Manual snapshots
-    - None
-
-## Testing and Validation
-
-42. **Data testing:**
-    - Unit tests (transformation logic)
-    - Integration tests (end-to-end pipeline)
-    - Data quality tests
-    - Schema validation
-    - Manual validation
-    - None
-
-43. **ML model testing (if applicable):**
-    - Unit tests (code)
-    - Model validation (held-out test set)
-    - Performance benchmarks
-    - Fairness/bias testing
-    - A/B testing in production
-    - None
-
-## Deployment and CI/CD
-
-44. **Deployment strategy:**
-    - GitOps (version-controlled config)
-    - Manual deployment
-    - CI/CD pipeline (GitHub Actions, GitLab CI)
-    - Platform-specific (SageMaker, Vertex AI)
-    - Terraform/IaC
-
-45. **Environment separation:**
-    - Dev / Staging / Production
-    - Dev / Production only
-    - Single environment
-
-46. **Containerization:**
-    - Docker
-    - Not containerized (native environments)
-
-## Monitoring and Observability
-
-47. **Pipeline monitoring:**
-    - Orchestrator built-in (Airflow UI, Prefect)
-    - Custom dashboards
-    - Alerts on failures
-    - Data quality monitoring
-    - None
-
-48. **Performance monitoring:**
-    - Query performance (slow queries)
-    - Job duration tracking
-    - Cost monitoring (cloud spend)
-    - Resource utilization
-    - None
-
-49. **Alerting:**
-    - Email
-    - Slack/Discord
-    - PagerDuty
-    - Built-in orchestrator alerts
-    - None
-
-## Cost Optimization
-
-50. **Cost considerations:**
-    - Optimize warehouse queries
-    - Auto-scaling clusters
-    - Spot/preemptible instances
-    - Storage tiering (hot/cold)
-    - Cost monitoring dashboards
-    - Not a priority
-
-## Collaboration and Documentation
-
-51. **Team collaboration:**
-    - Git for code
-    - Shared notebooks (JupyterHub, Databricks)
-    - Documentation wiki
-    - Slack/communication tools
-    - Pair programming
-
-52. **Documentation approach:**
-    - README files
-    - Docstrings in code
-    - Notebooks with markdown
-    - Confluence/Notion
-    - Data catalog (self-documenting)
-    - Minimal
-
-53. **Code review process:**
-    - Pull requests (required)
-    - Peer review (optional)
-    - No formal review
-
-## Performance and Scale
-
-54. **Performance requirements:**
-    - Near real-time (< 1 minute latency)
-    - Batch (hours acceptable)
-    - Interactive queries (< 10 seconds)
-    - No specific requirements
-
-55. **Scalability needs:**
-    - Must scale to 10x data volume
-    - Current scale sufficient
-    - Unknown (future growth)
-
-56. **Query optimization:**
-    - Indexing
-    - Partitioning
-    - Materialized views
-    - Query caching
-    - Not needed (fast enough)

src/modules/bmm/workflows/3-solutioning/project-types/desktop-instructions.md

@@ -0,0 +1,182 @@
+# Desktop Application Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for desktop application architecture decisions.
+The LLM should:
+- Understand the application's purpose and target OS from requirements
+- Balance native performance with development efficiency
+- Consider distribution and update mechanisms
+- Focus on desktop-specific UX patterns
+- Plan for OS-specific integrations
+</critical>
+
+## Framework Selection
+
+**Choose Based on Requirements and Team**
+
+- **Electron**: Web technologies, cross-platform, rapid development
+- **Tauri**: Rust + Web frontend, smaller binaries, better performance
+- **Qt**: C++/Python, native performance, extensive widgets
+- **.NET MAUI/WPF**: Windows-focused, C# teams
+- **SwiftUI/AppKit**: Mac-only, native experience
+- **JavaFX/Swing**: Java teams, enterprise apps
+- **Flutter Desktop**: Dart, consistent cross-platform UI
+
+Don't use Electron for performance-critical apps, or Qt for simple utilities.
+
+## Architecture Pattern
+
+**Application Structure**
+Based on complexity:
+
+- **MVC/MVVM**: For data-driven applications
+- **Component-Based**: For complex UIs
+- **Plugin Architecture**: For extensible apps
+- **Document-Based**: For editors/creators
+
+Match pattern to application type and team experience.
+
+## Native Integration
+
+**OS-Specific Features**
+Based on requirements:
+
+- System tray/menu bar integration
+- File associations and protocol handlers
+- Native notifications
+- OS-specific shortcuts and gestures
+- Dark mode and theme detection
+- Native menus and dialogs
+
+Plan for platform differences in UX expectations.
+
+## Data Management
+
+**Local Data Strategy**
+
+- **SQLite**: For structured data
+- **LevelDB/RocksDB**: For key-value storage
+- **JSON/XML files**: For simple configuration
+- **OS-specific stores**: Windows Registry, macOS Defaults
+
+**Settings and Preferences**
+
+- User vs. application settings
+- Portable vs. installed mode
+- Settings sync across devices
+
+## Window Management
+
+**Multi-Window Strategy**
+
+- Single vs. multi-window architecture
+- Window state persistence
+- Multi-monitor support
+- Workspace/session management
+
+## Performance Optimization
+
+**Desktop Performance**
+
+- Startup time optimization
+- Memory usage monitoring
+- Background task management
+- GPU acceleration usage
+- Native vs. web rendering trade-offs
+
+## Update Mechanism
+
+**Application Updates**
+
+- **Auto-update**: Electron-updater, Sparkle, Squirrel
+- **Store-based**: Mac App Store, Microsoft Store
+- **Manual**: Download from website
+- **Package manager**: Homebrew, Chocolatey, APT/YUM
+
+Consider code signing and notarization requirements.
+
+## Security Considerations
+
+**Desktop Security**
+
+- Code signing certificates
+- Secure storage for credentials
+- Process isolation
+- Network security
+- Input validation
+- Automatic security updates
+
+## Distribution Strategy
+
+**Packaging and Installation**
+
+- **Installers**: MSI, DMG, DEB/RPM
+- **Portable**: Single executable
+- **App stores**: Platform stores
+- **Package managers**: OS-specific
+
+Consider installation permissions and user experience.
+
+## IPC and Extensions
+
+**Inter-Process Communication**
+
+- Main/renderer process communication (Electron)
+- Plugin/extension system
+- CLI integration
+- Automation/scripting support
+
+## Accessibility
+
+**Desktop Accessibility**
+
+- Screen reader support
+- Keyboard navigation
+- High contrast themes
+- Zoom/scaling support
+- OS accessibility APIs
+
+## Testing Strategy
+
+**Desktop Testing**
+
+- Unit tests for business logic
+- Integration tests for OS interactions
+- UI automation testing
+- Multi-OS testing matrix
+- Performance profiling
+
+## Adaptive Guidance Examples
+
+**For a Development IDE:**
+Focus on performance, plugin system, workspace management, and syntax highlighting.
+
+**For a Media Player:**
+Emphasize codec support, hardware acceleration, media keys, and playlist management.
+
+**For a Business Application:**
+Focus on data grids, reporting, printing, and enterprise integration.
+
+**For a Creative Tool:**
+Emphasize canvas rendering, tool palettes, undo/redo, and file format support.
+
+## Key Principles
+
+1. **Respect platform conventions** - Mac != Windows != Linux
+2. **Optimize startup time** - Desktop users expect instant launch
+3. **Handle offline gracefully** - Desktop != always online
+4. **Integrate with OS** - Use native features appropriately
+5. **Plan distribution early** - Signing/notarization takes time
+
+## Output Format
+
+Document as:
+
+- **Framework**: [Specific framework and version]
+- **Target OS**: [Primary and secondary platforms]
+- **Distribution**: [How users will install]
+- **Update strategy**: [How updates are delivered]
+
+Focus on desktop-specific architectural decisions.

src/modules/bmm/workflows/3-solutioning/project-types/desktop-questions.md

@@ -1,299 +0,0 @@
-# Desktop Application Architecture Questions
-
-## Framework and Platform
-
-1. **Primary framework:**
-   - Electron (JavaScript/TypeScript, web tech, cross-platform)
-   - Tauri (Rust backend, web frontend, lightweight)
-   - .NET MAUI (C#, cross-platform, native UI)
-   - Qt (C++/Python, cross-platform, native)
-   - Flutter Desktop (Dart, cross-platform)
-   - JavaFX (Java, cross-platform)
-   - Swift/SwiftUI (macOS only)
-   - WPF/WinUI 3 (Windows only, C#)
-   - GTK (C/Python, Linux-focused)
-   - Other: **\_\_\_**
-
-2. **Target platforms:**
-   - Windows only
-   - macOS only
-   - Linux only
-   - Windows + macOS
-   - Windows + macOS + Linux (full cross-platform)
-   - Specific Linux distros: **\_\_\_**
-
-3. **UI approach:**
-   - Native UI (platform-specific controls)
-   - Web-based UI (HTML/CSS/JS in Electron/Tauri)
-   - Custom-drawn UI (Canvas/OpenGL)
-   - Hybrid (native shell + web content)
-
-4. **Frontend framework (if web-based UI):**
-   - React
-   - Vue
-   - Svelte
-   - Angular
-   - Vanilla JS
-   - Other: **\_\_\_**
-
-## Architecture
-
-5. **Application architecture:**
-   - Single-process (all in one)
-   - Multi-process (main + renderer processes like Electron)
-   - Multi-threaded (background workers)
-   - Plugin-based (extensible architecture)
-
-6. **Backend/Business logic:**
-   - Embedded in app (monolithic)
-   - Separate local service
-   - Connects to remote API
-   - Hybrid (local + remote)
-
-7. **Database/Data storage:**
-   - SQLite (local embedded database)
-   - IndexedDB (if web-based)
-   - File-based storage (JSON, custom)
-   - LevelDB/RocksDB
-   - Remote database only
-   - No persistence needed
-   - Other: **\_\_\_**
-
-## System Integration
-
-8. **Operating system integration needs:**
-   - File system access (read/write user files)
-   - System tray/menu bar icon
-   - Native notifications
-   - Keyboard shortcuts (global hotkeys)
-   - Clipboard integration
-   - Drag-and-drop support
-   - Context menu integration
-   - File type associations
-   - URL scheme handling (deep linking)
-   - System dialogs (file picker, alerts)
-   - None needed (basic app)
-
-9. **Hardware access:**
-   - Camera/Microphone
-   - USB devices
-   - Bluetooth
-   - Printers
-   - Scanners
-   - Serial ports
-   - GPU (for rendering/compute)
-   - None needed
-
-10. **System permissions required:**
-    - Accessibility API (screen reading, input simulation)
-    - Location services
-    - Calendar/Contacts access
-    - Network monitoring
-    - Screen recording
-    - Full disk access
-    - None (sandboxed app)
-
-## Updates and Distribution
-
-11. **Auto-update mechanism:**
-    - Electron's autoUpdater
-    - Squirrel (Windows/Mac)
-    - Sparkle (macOS)
-    - Custom update server
-    - App store updates only
-    - Manual download/install
-    - No updates (fixed version)
-
-12. **Distribution method:**
-    - Microsoft Store (Windows)
-    - Mac App Store
-    - Snap Store (Linux)
-    - Flatpak (Linux)
-    - Homebrew (macOS/Linux)
-    - Direct download from website
-    - Enterprise deployment (MSI, PKG)
-    - Multiple channels
-
-13. **Code signing:**
-    - Yes - Windows (Authenticode)
-    - Yes - macOS (Apple Developer)
-    - Yes - both
-    - No (development/internal only)
-
-14. **Notarization (macOS):**
-    - Required (public distribution)
-    - Not needed (internal only)
-
-## Packaging and Installation
-
-15. **Windows installer:**
-    - NSIS
-    - Inno Setup
-    - WiX Toolset (MSI)
-    - Squirrel.Windows
-    - MSIX (Windows 10+)
-    - Portable (no installer)
-    - Other: **\_\_\_**
-
-16. **macOS installer:**
-    - DMG (drag-to-install)
-    - PKG installer
-    - Mac App Store
-    - Homebrew Cask
-    - Other: **\_\_\_**
-
-17. **Linux packaging:**
-    - AppImage (portable)
-    - Snap
-    - Flatpak
-    - .deb (Debian/Ubuntu)
-    - .rpm (Fedora/RHEL)
-    - Tarball
-    - AUR (Arch)
-    - Multiple formats
-
-## Configuration and Settings
-
-18. **Settings storage:**
-    - OS-specific (Registry on Windows, plist on macOS, config files on Linux)
-    - JSON/YAML config file
-    - SQLite database
-    - Remote/cloud sync
-    - Electron Store
-    - Other: **\_\_\_**
-
-19. **User data location:**
-    - Application Support folder (standard OS location)
-    - User documents folder
-    - Custom location (user selectable)
-    - Cloud storage integration
-
-## Networking
-
-20. **Network connectivity:**
-    - Online-only (requires internet)
-    - Offline-first (works without internet)
-    - Hybrid (enhanced with internet)
-    - No network needed
-
-21. **Backend communication (if applicable):**
-    - REST API
-    - GraphQL
-    - WebSocket
-    - gRPC
-    - Custom protocol
-    - None
-
-## Authentication and Security
-
-22. **Authentication (if applicable):**
-    - OAuth2 (Google, Microsoft, etc.)
-    - Username/password with backend
-    - SSO (enterprise)
-    - OS-level authentication (biometric, Windows Hello)
-    - No authentication needed
-
-23. **Data security:**
-    - Encrypt sensitive data at rest
-    - OS keychain/credential manager
-    - Custom encryption
-    - No sensitive data
-
-24. **Sandboxing:**
-    - Fully sandboxed (Mac App Store requirement)
-    - Partially sandboxed
-    - Not sandboxed (legacy/compatibility)
-
-## Performance and Resources
-
-25. **Performance requirements:**
-    - Lightweight (minimal resource usage)
-    - Moderate (typical desktop app)
-    - Resource-intensive (video editing, 3D, etc.)
-
-26. **Background operation:**
-    - Runs in background/system tray
-    - Active window only
-    - Can minimize to tray
-
-27. **Multi-instance handling:**
-    - Allow multiple instances
-    - Single instance only
-    - Single instance with IPC (communicate between instances)
-
-## Development and Build
-
-28. **Build tooling:**
-    - electron-builder
-    - electron-forge
-    - Tauri CLI
-    - .NET CLI
-    - CMake (for C++/Qt)
-    - Gradle (for Java)
-    - Xcode (for macOS)
-    - Visual Studio (for Windows)
-    - Other: **\_\_\_**
-
-29. **Development environment:**
-    - Cross-platform dev (can build on any OS)
-    - Platform-specific (need macOS for Mac builds, etc.)
-
-30. **CI/CD for builds:**
-    - GitHub Actions
-    - GitLab CI
-    - CircleCI
-    - Azure Pipelines
-    - Custom
-    - Manual builds
-
-## Testing
-
-31. **UI testing approach:**
-    - Spectron (Electron)
-    - Playwright
-    - Selenium
-    - Native UI testing (XCTest, UI Automation)
-    - Manual testing only
-
-32. **End-to-end testing:**
-    - Yes (automated E2E tests)
-    - Limited (smoke tests only)
-    - Manual only
-
-## Additional Features
-
-33. **Internationalization (i18n):**
-    - Multiple languages supported
-    - English only
-    - User-selectable language
-    - OS language detection
-
-34. **Accessibility:**
-    - Full accessibility support (screen readers, keyboard nav)
-    - Basic accessibility
-    - Not a priority
-
-35. **Crash reporting:**
-    - Sentry
-    - BugSnag
-    - Crashpad (for native crashes)
-    - Custom reporting
-    - None
-
-36. **Analytics/Telemetry:**
-    - Google Analytics
-    - Mixpanel
-    - PostHog
-    - Custom telemetry
-    - No telemetry (privacy-focused)
-
-37. **Licensing/DRM (if commercial):**
-    - License key validation
-    - Hardware-locked licenses
-    - Subscription validation
-    - None (free/open-source)
-
-38. **Plugin/Extension system:**
-    - Yes (user can install plugins)
-    - No (monolithic app)
-    - Planned for future

src/modules/bmm/workflows/3-solutioning/project-types/embedded-instructions.md

@@ -0,0 +1,191 @@
+# Embedded/IoT System Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for embedded/IoT architecture decisions.
+The LLM should:
+- Understand hardware constraints and real-time requirements
+- Guide platform and RTOS selection based on use case
+- Consider power consumption and resource limitations
+- Balance features with memory/processing constraints
+- Focus on reliability and update mechanisms
+</critical>
+
+## Hardware Platform Selection
+
+**Choose Based on Requirements**
+
+- **Microcontroller**: For simple, low-power, real-time tasks
+- **SoC/SBC**: For complex processing, Linux-capable
+- **FPGA**: For parallel processing, custom logic
+- **Hybrid**: MCU + application processor
+
+Consider power budget, processing needs, and peripheral requirements.
+
+## Operating System/RTOS
+
+**OS Selection**
+Based on complexity:
+
+- **Bare Metal**: Simple control loops, minimal overhead
+- **RTOS**: FreeRTOS, Zephyr for real-time requirements
+- **Embedded Linux**: Complex applications, networking
+- **Android Things/Windows IoT**: For specific ecosystems
+
+Don't use Linux for battery-powered sensors, or bare metal for complex networking.
+
+## Development Framework
+
+**Language and Tools**
+
+- **C/C++**: Maximum control, minimal overhead
+- **Rust**: Memory safety, modern tooling
+- **MicroPython/CircuitPython**: Rapid prototyping
+- **Arduino**: Beginner-friendly, large community
+- **Platform-specific SDKs**: ESP-IDF, STM32Cube
+
+Match to team expertise and performance requirements.
+
+## Communication Protocols
+
+**Connectivity Strategy**
+Based on use case:
+
+- **Local**: I2C, SPI, UART for sensor communication
+- **Wireless**: WiFi, Bluetooth, LoRa, Zigbee, cellular
+- **Industrial**: Modbus, CAN bus, MQTT
+- **Cloud**: HTTPS, MQTT, CoAP
+
+Consider range, power consumption, and data rates.
+
+## Power Management
+
+**Power Optimization**
+
+- Sleep modes and wake triggers
+- Dynamic frequency scaling
+- Peripheral power management
+- Battery monitoring and management
+- Energy harvesting considerations
+
+Critical for battery-powered devices.
+
+## Memory Architecture
+
+**Memory Management**
+
+- Static vs. dynamic allocation
+- Flash wear leveling
+- RAM optimization techniques
+- External storage options
+- Bootloader and OTA partitioning
+
+Plan memory layout early - hard to change later.
+
+## Firmware Architecture
+
+**Code Organization**
+
+- HAL (Hardware Abstraction Layer)
+- Modular driver architecture
+- Task/thread design
+- Interrupt handling strategy
+- State machine implementation
+
+## Update Mechanism
+
+**OTA Updates**
+
+- Update delivery method
+- Rollback capability
+- Differential updates
+- Security and signing
+- Factory reset capability
+
+Plan for field updates from day one.
+
+## Security Architecture
+
+**Embedded Security**
+
+- Secure boot
+- Encrypted storage
+- Secure communication (TLS)
+- Hardware security modules
+- Attack surface minimization
+
+Security is harder to add later.
+
+## Data Management
+
+**Local and Cloud Data**
+
+- Edge processing vs. cloud processing
+- Local storage and buffering
+- Data compression
+- Time synchronization
+- Offline operation handling
+
+## Testing Strategy
+
+**Embedded Testing**
+
+- Unit testing on host
+- Hardware-in-the-loop testing
+- Integration testing
+- Environmental testing
+- Certification requirements
+
+## Debugging and Monitoring
+
+**Development Tools**
+
+- Debug interfaces (JTAG, SWD)
+- Serial console
+- Logic analyzers
+- Remote debugging
+- Field diagnostics
+
+## Production Considerations
+
+**Manufacturing and Deployment**
+
+- Provisioning process
+- Calibration requirements
+- Production testing
+- Device identification
+- Configuration management
+
+## Adaptive Guidance Examples
+
+**For a Smart Sensor:**
+Focus on ultra-low power, wireless communication, and edge processing.
+
+**For an Industrial Controller:**
+Emphasize real-time performance, reliability, safety systems, and industrial protocols.
+
+**For a Consumer IoT Device:**
+Focus on user experience, cloud integration, OTA updates, and cost optimization.
+
+**For a Wearable:**
+Emphasize power efficiency, small form factor, BLE, and sensor fusion.
+
+## Key Principles
+
+1. **Design for constraints** - Memory, power, and processing are limited
+2. **Plan for failure** - Hardware fails, design for recovery
+3. **Security from the start** - Retrofitting is difficult
+4. **Test on real hardware** - Simulation has limits
+5. **Design for production** - Prototype != product
+
+## Output Format
+
+Document as:
+
+- **Platform**: [MCU/SoC selection with part numbers]
+- **OS/RTOS**: [Operating system choice]
+- **Connectivity**: [Communication protocols and interfaces]
+- **Power**: [Power budget and management strategy]
+
+Focus on hardware/software co-design decisions.

src/modules/bmm/workflows/3-solutioning/project-types/embedded-questions.md

@@ -1,118 +0,0 @@
-# Embedded System Architecture Questions
-
-## Hardware Platform
-
-1. **Microcontroller/SoC:**
-   - ESP32 (WiFi/BLE, popular)
-   - ESP8266 (WiFi, budget)
-   - STM32 (ARM Cortex-M, powerful)
-   - Arduino (AVR, beginner-friendly)
-   - Raspberry Pi Pico (RP2040)
-   - Other: **\_\_\_**
-
-2. **RTOS or Bare Metal:**
-   - FreeRTOS (popular, tasks/queues)
-   - Zephyr RTOS
-   - Bare metal (no OS, full control)
-   - Arduino framework
-   - ESP-IDF
-   - Other: **\_\_\_**
-
-3. **Programming language:**
-   - C
-   - C++
-   - MicroPython
-   - Arduino (C++)
-   - Rust
-
-## Communication
-
-4. **Primary communication protocol:**
-   - MQTT (IoT messaging)
-   - HTTP/HTTPS (REST APIs)
-   - WebSockets
-   - CoAP
-   - Custom binary protocol
-
-5. **Local communication (peripherals):**
-   - UART (serial)
-   - I2C (sensors)
-   - SPI (high-speed devices)
-   - GPIO (simple digital)
-   - Analog (ADC)
-
-6. **Wireless connectivity:**
-   - WiFi
-   - Bluetooth Classic
-   - BLE (Bluetooth Low Energy)
-   - LoRa/LoRaWAN
-   - Zigbee
-   - None (wired only)
-
-## Cloud/Backend
-
-7. **Cloud platform:** (if IoT project)
-   - AWS IoT Core
-   - Azure IoT Hub
-   - Google Cloud IoT
-   - Custom MQTT broker
-   - ThingsBoard
-   - None (local only)
-
-## Power
-
-8. **Power source:**
-   - USB powered (5V constant)
-   - Battery (need power management)
-   - AC adapter
-   - Solar
-   - Other: **\_\_\_**
-
-9. **Low power mode needed:**
-   - Yes (battery-powered, deep sleep)
-   - No (always powered)
-
-## Storage
-
-10. **Data persistence:**
-    - EEPROM (small config)
-    - Flash (larger data)
-    - SD card
-    - None needed
-    - Cloud only
-
-## Updates
-
-11. **Firmware update strategy:**
-    - OTA (Over-The-Air via WiFi)
-    - USB/Serial upload
-    - SD card
-    - No updates (fixed firmware)
-
-## Sensors/Actuators
-
-12. **Sensors used:** (list)
-    - Temperature (DHT22, DS18B20, etc.)
-    - Humidity
-    - Motion (PIR, accelerometer)
-    - Light (LDR, photodiode)
-    - Other: **\_\_\_**
-
-13. **Actuators used:** (list)
-    - LEDs
-    - Motors (DC, servo, stepper)
-    - Relays
-    - Display (LCD, OLED)
-    - Other: **\_\_\_**
-
-## Real-Time Constraints
-
-14. **Hard real-time requirements:**
-    - Yes (must respond within X ms, critical)
-    - Soft real-time (best effort)
-    - No timing constraints
-
-15. **Interrupt-driven or polling:**
-    - Interrupts (responsive)
-    - Polling (simpler)
-    - Mix

src/modules/bmm/workflows/3-solutioning/project-types/extension-instructions.md

@@ -0,0 +1,193 @@
+# Browser/Editor Extension Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for extension architecture decisions.
+The LLM should:
+- Understand the host platform (browser, VS Code, IDE, etc.)
+- Focus on extension-specific constraints and APIs
+- Consider distribution through official stores
+- Balance functionality with performance impact
+- Plan for permission models and security
+</critical>
+
+## Extension Type and Platform
+
+**Identify Target Platform**
+
+- **Browser**: Chrome, Firefox, Safari, Edge
+- **VS Code**: Most popular code editor
+- **JetBrains IDEs**: IntelliJ, WebStorm, etc.
+- **Other Editors**: Sublime, Atom, Vim, Emacs
+- **Application-specific**: Figma, Sketch, Adobe
+
+Each platform has unique APIs and constraints.
+
+## Architecture Pattern
+
+**Extension Architecture**
+Based on platform:
+
+- **Browser**: Content scripts, background workers, popup UI
+- **VS Code**: Extension host, language server, webview
+- **IDE**: Plugin architecture, service providers
+- **Application**: Native API, JavaScript bridge
+
+Follow platform-specific patterns and guidelines.
+
+## Manifest and Configuration
+
+**Extension Declaration**
+
+- Manifest version and compatibility
+- Permission requirements
+- Activation events
+- Command registration
+- Context menu integration
+
+Request minimum necessary permissions for user trust.
+
+## Communication Architecture
+
+**Inter-Component Communication**
+
+- Message passing between components
+- Storage sync across instances
+- Native messaging (if needed)
+- WebSocket for external services
+
+Design for async communication patterns.
+
+## UI Integration
+
+**User Interface Approach**
+
+- **Popup/Panel**: For quick interactions
+- **Sidebar**: For persistent tools
+- **Content Injection**: Modify existing UI
+- **Custom Pages**: Full page experiences
+- **Statusbar**: For ambient information
+
+Match UI to user workflow and platform conventions.
+
+## State Management
+
+**Data Persistence**
+
+- Local storage for user preferences
+- Sync storage for cross-device
+- IndexedDB for large data
+- File system access (if permitted)
+
+Consider storage limits and sync conflicts.
+
+## Performance Optimization
+
+**Extension Performance**
+
+- Lazy loading of features
+- Minimal impact on host performance
+- Efficient DOM manipulation
+- Memory leak prevention
+- Background task optimization
+
+Extensions must not degrade host application performance.
+
+## Security Considerations
+
+**Extension Security**
+
+- Content Security Policy
+- Input sanitization
+- Secure communication
+- API key management
+- User data protection
+
+Follow platform security best practices.
+
+## Development Workflow
+
+**Development Tools**
+
+- Hot reload during development
+- Debugging setup
+- Testing framework
+- Build pipeline
+- Version management
+
+## Distribution Strategy
+
+**Publishing and Updates**
+
+- Official store submission
+- Review process requirements
+- Update mechanism
+- Beta testing channel
+- Self-hosting options
+
+Plan for store review times and policies.
+
+## API Integration
+
+**External Service Communication**
+
+- Authentication methods
+- CORS handling
+- Rate limiting
+- Offline functionality
+- Error handling
+
+## Monetization
+
+**Revenue Model** (if applicable)
+
+- Free with premium features
+- Subscription model
+- One-time purchase
+- Enterprise licensing
+
+Consider platform policies on monetization.
+
+## Testing Strategy
+
+**Extension Testing**
+
+- Unit tests for logic
+- Integration tests with host API
+- Cross-browser/platform testing
+- Performance testing
+- User acceptance testing
+
+## Adaptive Guidance Examples
+
+**For a Password Manager Extension:**
+Focus on security, autofill integration, secure storage, and cross-browser sync.
+
+**For a Developer Tool Extension:**
+Emphasize debugging capabilities, performance profiling, and workspace integration.
+
+**For a Content Blocker:**
+Focus on performance, rule management, whitelist handling, and minimal overhead.
+
+**For a Productivity Extension:**
+Emphasize keyboard shortcuts, quick access, sync, and workflow integration.
+
+## Key Principles
+
+1. **Respect the host** - Don't break or slow down the host application
+2. **Request minimal permissions** - Users are permission-aware
+3. **Fast activation** - Extensions should load instantly
+4. **Fail gracefully** - Handle API changes and errors
+5. **Follow guidelines** - Store policies are strictly enforced
+
+## Output Format
+
+Document as:
+
+- **Platform**: [Specific platform and version support]
+- **Architecture**: [Component structure]
+- **Permissions**: [Required permissions and justification]
+- **Distribution**: [Store and update strategy]
+
+Focus on platform-specific requirements and constraints.

src/modules/bmm/workflows/3-solutioning/project-types/extension-questions.md

@@ -1,374 +0,0 @@
-# Browser Extension Architecture Questions
-
-## Target Browsers
-
-1. **Target browser(s):**
-   - Chrome (most common)
-   - Firefox
-   - Edge (Chromium-based)
-   - Safari
-   - Opera
-   - Brave
-   - Multiple browsers (cross-browser)
-
-2. **Manifest version:**
-   - Manifest V3 (current standard, required for Chrome Web Store)
-   - Manifest V2 (legacy, being phased out)
-   - Both (transition period)
-
-3. **Cross-browser compatibility:**
-   - Chrome/Edge only (same codebase)
-   - Chrome + Firefox (minor differences)
-   - All major browsers (requires polyfills/adapters)
-
-## Extension Type and Architecture
-
-4. **Primary extension type:**
-   - Browser Action (icon in toolbar)
-   - Page Action (icon in address bar, page-specific)
-   - Content Script (runs on web pages)
-   - DevTools Extension (adds features to browser DevTools)
-   - New Tab Override
-   - Bookmarks/History extension
-   - Multiple components
-
-5. **Extension components needed:**
-   - Background script/Service Worker (always running logic)
-   - Content scripts (inject into web pages)
-   - Popup UI (click toolbar icon)
-   - Options page (settings/configuration)
-   - Side panel (persistent panel, MV3)
-   - DevTools page
-   - New Tab page
-
-6. **Content script injection:**
-   - All pages (matches: <all_urls>)
-   - Specific domains (matches: \*.example.com)
-   - User-activated (inject on demand)
-   - Not needed
-
-## UI and Framework
-
-7. **UI framework:**
-   - Vanilla JS (no framework)
-   - React
-   - Vue
-   - Svelte
-   - Preact (lightweight React)
-   - Web Components
-   - Other: **\_\_\_**
-
-8. **Build tooling:**
-   - Webpack
-   - Vite
-   - Rollup
-   - Parcel
-   - esbuild
-   - WXT (extension-specific)
-   - Plasmo (extension framework)
-   - None (plain JS)
-
-9. **CSS framework:**
-   - Tailwind CSS
-   - CSS Modules
-   - Styled Components
-   - Plain CSS
-   - Sass/SCSS
-   - None (minimal styling)
-
-10. **Popup UI:**
-    - Simple (HTML + CSS)
-    - Interactive (full app)
-    - None (no popup)
-
-11. **Options page:**
-    - Simple form (HTML)
-    - Full settings UI (framework-based)
-    - Embedded in popup
-    - None (no settings)
-
-## Permissions
-
-12. **Storage permissions:**
-    - chrome.storage.local (local storage)
-    - chrome.storage.sync (sync across devices)
-    - IndexedDB
-    - None (no data persistence)
-
-13. **Host permissions (access to websites):**
-    - Specific domains only
-    - All URLs (<all_urls>)
-    - ActiveTab only (current tab when clicked)
-    - Optional permissions (user grants on demand)
-
-14. **API permissions needed:**
-    - tabs (query/manipulate tabs)
-    - webRequest (intercept network requests)
-    - cookies
-    - history
-    - bookmarks
-    - downloads
-    - notifications
-    - contextMenus (right-click menu)
-    - clipboardWrite/Read
-    - identity (OAuth)
-    - Other: **\_\_\_**
-
-15. **Sensitive permissions:**
-    - webRequestBlocking (modify requests, requires justification)
-    - declarativeNetRequest (MV3 alternative)
-    - None
-
-## Data and Storage
-
-16. **Data storage:**
-    - chrome.storage.local
-    - chrome.storage.sync (synced across devices)
-    - IndexedDB
-    - localStorage (limited, not recommended)
-    - Remote storage (own backend)
-    - Multiple storage types
-
-17. **Storage size:**
-    - Small (< 100KB)
-    - Medium (100KB - 5MB, storage.sync limit)
-    - Large (> 5MB, need storage.local or IndexedDB)
-
-18. **Data sync:**
-    - Sync across user's devices (chrome.storage.sync)
-    - Local only (storage.local)
-    - Custom backend sync
-
-## Communication
-
-19. **Message passing (internal):**
-    - Content script <-> Background script
-    - Popup <-> Background script
-    - Content script <-> Content script
-    - Not needed
-
-20. **Messaging library:**
-    - Native chrome.runtime.sendMessage
-    - Wrapper library (webext-bridge, etc.)
-    - Custom messaging layer
-
-21. **Backend communication:**
-    - REST API
-    - WebSocket
-    - GraphQL
-    - Firebase/Supabase
-    - None (client-only extension)
-
-## Web Integration
-
-22. **DOM manipulation:**
-    - Read DOM (observe, analyze)
-    - Modify DOM (inject, hide, change elements)
-    - Both
-    - None (no content scripts)
-
-23. **Page interaction method:**
-    - Content scripts (extension context)
-    - Injected scripts (page context, access page variables)
-    - Both (communicate via postMessage)
-
-24. **CSS injection:**
-    - Inject custom styles
-    - Override site styles
-    - None
-
-25. **Network request interception:**
-    - Read requests (webRequest)
-    - Block/modify requests (declarativeNetRequest in MV3)
-    - Not needed
-
-## Background Processing
-
-26. **Background script type (MV3):**
-    - Service Worker (MV3, event-driven, terminates when idle)
-    - Background page (MV2, persistent)
-
-27. **Background tasks:**
-    - Event listeners (tabs, webRequest, etc.)
-    - Periodic tasks (alarms)
-    - Message routing (popup <-> content scripts)
-    - API calls
-    - None
-
-28. **Persistent state (MV3 challenge):**
-    - Store in chrome.storage (service worker can terminate)
-    - Use alarms for periodic tasks
-    - Not applicable (MV2 or stateless)
-
-## Authentication
-
-29. **User authentication:**
-    - OAuth (chrome.identity API)
-    - Custom login (username/password with backend)
-    - API key
-    - No authentication needed
-
-30. **OAuth provider:**
-    - Google
-    - GitHub
-    - Custom OAuth server
-    - Not using OAuth
-
-## Distribution
-
-31. **Distribution method:**
-    - Chrome Web Store (public)
-    - Chrome Web Store (unlisted)
-    - Firefox Add-ons (AMO)
-    - Edge Add-ons Store
-    - Self-hosted (enterprise, sideload)
-    - Multiple stores
-
-32. **Pricing model:**
-    - Free
-    - Freemium (basic free, premium paid)
-    - Paid (one-time purchase)
-    - Subscription
-    - Enterprise licensing
-
-33. **In-extension purchases:**
-    - Via web (redirect to website)
-    - Stripe integration
-    - No purchases
-
-## Privacy and Security
-
-34. **User privacy:**
-    - No data collection
-    - Anonymous analytics
-    - User data collected (with consent)
-    - Data sent to server
-
-35. **Content Security Policy (CSP):**
-    - Default CSP (secure)
-    - Custom CSP (if needed for external scripts)
-
-36. **External scripts:**
-    - None (all code bundled)
-    - CDN scripts (requires CSP relaxation)
-    - Inline scripts (avoid in MV3)
-
-37. **Sensitive data handling:**
-    - Encrypt stored data
-    - Use native credential storage
-    - No sensitive data
-
-## Testing
-
-38. **Testing approach:**
-    - Manual testing (load unpacked)
-    - Unit tests (Jest, Vitest)
-    - E2E tests (Puppeteer, Playwright)
-    - Cross-browser testing
-    - Minimal testing
-
-39. **Test automation:**
-    - Automated tests in CI
-    - Manual testing only
-
-## Updates and Deployment
-
-40. **Update strategy:**
-    - Auto-update (store handles)
-    - Manual updates (enterprise)
-
-41. **Versioning:**
-    - Semantic versioning (1.2.3)
-    - Chrome Web Store version requirements
-
-42. **CI/CD:**
-    - GitHub Actions
-    - GitLab CI
-    - Manual builds/uploads
-    - Web Store API (automated publishing)
-
-## Features
-
-43. **Context menu integration:**
-    - Right-click menu items
-    - Not needed
-
-44. **Omnibox integration:**
-    - Custom omnibox keyword
-    - Not needed
-
-45. **Browser notifications:**
-    - Chrome notifications API
-    - Not needed
-
-46. **Keyboard shortcuts:**
-    - chrome.commands API
-    - Not needed
-
-47. **Clipboard access:**
-    - Read clipboard
-    - Write to clipboard
-    - Not needed
-
-48. **Side panel (MV3):**
-    - Persistent side panel UI
-    - Not needed
-
-49. **DevTools integration:**
-    - Add DevTools panel
-    - Not needed
-
-50. **Internationalization (i18n):**
-    - Multiple languages
-    - English only
-
-## Analytics and Monitoring
-
-51. **Analytics:**
-    - Google Analytics (with privacy considerations)
-    - PostHog
-    - Mixpanel
-    - Custom analytics
-    - None
-
-52. **Error tracking:**
-    - Sentry
-    - Bugsnag
-    - Custom error logging
-    - None
-
-53. **User feedback:**
-    - In-extension feedback form
-    - External form (website)
-    - Email/support
-    - None
-
-## Performance
-
-54. **Performance considerations:**
-    - Minimal memory footprint
-    - Lazy loading
-    - Efficient DOM queries
-    - Not a priority
-
-55. **Bundle size:**
-    - Keep small (< 1MB)
-    - Moderate (1-5MB)
-    - Large (> 5MB, media/assets)
-
-## Compliance and Review
-
-56. **Chrome Web Store review:**
-    - Standard review (automated + manual)
-    - Sensitive permissions (extra scrutiny)
-    - Not yet submitted
-
-57. **Privacy policy:**
-    - Required (collecting data)
-    - Not required (no data collection)
-    - Already prepared
-
-58. **Code obfuscation:**
-    - Minified only
-    - Not allowed (stores require readable code)
-    - Using source maps

src/modules/bmm/workflows/3-solutioning/project-types/extension-template.md

@@ -0,0 +1,67 @@
+# Extension Architecture Document
+
+**Project:** {{project_name}}
+**Platform:** {{target_platform}}
+**Date:** {{date}}
+**Author:** {{user_name}}
+
+## Executive Summary
+
+{{executive_summary}}
+
+## Technology Stack
+
+| Category   | Technology     | Version              | Justification              |
+| ---------- | -------------- | -------------------- | -------------------------- |
+| Platform   | {{platform}}   | {{platform_version}} | {{platform_justification}} |
+| Language   | {{language}}   | {{language_version}} | {{language_justification}} |
+| Build Tool | {{build_tool}} | {{build_version}}    | {{build_justification}}    |
+
+## Extension Architecture
+
+### Manifest Configuration
+
+{{manifest_config}}
+
+### Permission Model
+
+{{permissions_required}}
+
+### Component Architecture
+
+{{component_structure}}
+
+## Communication Architecture
+
+{{communication_patterns}}
+
+## State Management
+
+{{state_management}}
+
+## User Interface
+
+{{ui_architecture}}
+
+## API Integration
+
+{{api_integration}}
+
+## Development Guidelines
+
+{{development_guidelines}}
+
+## Distribution Strategy
+
+{{distribution_strategy}}
+
+## Source Tree
+
+```
+{{source_tree}}
+```
+
+---
+
+_Architecture optimized for {{target_platform}} extension_
+_Generated using BMad Method Solution Architecture workflow_

src/modules/bmm/workflows/3-solutioning/project-types/game-instructions.md

@@ -0,0 +1,225 @@
+# Game Development Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for game project architecture decisions.
+The LLM should:
+- FIRST understand the game type from the GDD (RPG, puzzle, shooter, etc.)
+- Check if engine preference is already mentioned in GDD or by user
+- Adapt architecture heavily based on game type and complexity
+- Consider that each game type has VASTLY different needs
+- Keep beginner-friendly suggestions for those without preferences
+</critical>
+
+## Engine Selection Strategy
+
+**Intelligent Engine Guidance**
+
+First, check if the user has already indicated an engine preference in the GDD or conversation.
+
+If no engine specified, ask directly:
+"Do you have a game engine preference? If you're unsure, I can suggest options based on your [game type] and team experience."
+
+**For Beginners Without Preference:**
+Based on game type, suggest the most approachable option:
+
+- **2D Games**: Godot (free, beginner-friendly) or GameMaker (visual scripting)
+- **3D Games**: Unity (huge community, learning resources)
+- **Web Games**: Phaser (JavaScript) or Godot (exports to web)
+- **Visual Novels**: Ren'Py (purpose-built) or Twine (for text-based)
+- **Mobile Focus**: Unity or Godot (both export well to mobile)
+
+Always explain: "I'm suggesting [Engine] because it's beginner-friendly for [game type] and has [specific advantages]. Other viable options include [alternatives]."
+
+**For Experienced Teams:**
+Let them state their preference, then ensure architecture aligns with engine capabilities.
+
+## Game Type Adaptive Architecture
+
+<critical>
+The architecture MUST adapt to the game type identified in the GDD.
+Load the specific game type considerations and merge with general guidance.
+</critical>
+
+### Architecture by Game Type Examples
+
+**Visual Novel / Text-Based:**
+
+- Focus on narrative data structures, save systems, branching logic
+- Minimal physics/rendering considerations
+- Emphasis on dialogue systems and choice tracking
+- Simple scene management
+
+**RPG:**
+
+- Complex data architecture for stats, items, quests
+- Save system with extensive state
+- Character progression systems
+- Inventory and equipment management
+- World state persistence
+
+**Multiplayer Shooter:**
+
+- Network architecture is PRIMARY concern
+- Client prediction and server reconciliation
+- Anti-cheat considerations
+- Matchmaking and lobby systems
+- Weapon ballistics and hit registration
+
+**Puzzle Game:**
+
+- Level data structures and progression
+- Hint/solution validation systems
+- Minimal networking (unless multiplayer)
+- Focus on content pipeline for level creation
+
+**Roguelike:**
+
+- Procedural generation architecture
+- Run persistence vs. meta progression
+- Seed-based reproducibility
+- Death and restart systems
+
+**MMO/MOBA:**
+
+- Massive multiplayer architecture
+- Database design for persistence
+- Server cluster architecture
+- Real-time synchronization
+- Economy and balance systems
+
+## Core Architecture Decisions
+
+**Determine Based on Game Requirements:**
+
+### Data Architecture
+
+Adapt to game type:
+
+- **Simple Puzzle**: Level data in JSON/XML files
+- **RPG**: Complex relational data, possibly SQLite
+- **Multiplayer**: Server authoritative state
+- **Procedural**: Seed and generation systems
+
+### Multiplayer Architecture (if applicable)
+
+Only discuss if game has multiplayer:
+
+- **Casual Party Game**: P2P might suffice
+- **Competitive**: Dedicated servers required
+- **Turn-Based**: Simple request/response
+- **Real-Time Action**: Complex netcode, interpolation
+
+Skip entirely for single-player games.
+
+### Content Pipeline
+
+Based on team structure and game scope:
+
+- **Solo Dev**: Simple, file-based
+- **Small Team**: Version controlled assets, clear naming
+- **Large Team**: Asset database, automated builds
+
+### Performance Strategy
+
+Varies WILDLY by game type:
+
+- **Mobile Puzzle**: Battery life > raw performance
+- **VR Game**: Consistent 90+ FPS critical
+- **Strategy Game**: CPU optimization for AI/simulation
+- **MMO**: Server scalability primary concern
+
+## Platform-Specific Considerations
+
+**Adapt to Target Platform from GDD:**
+
+- **Mobile**: Touch input, performance constraints, monetization
+- **Console**: Certification requirements, controller input, achievements
+- **PC**: Wide hardware range, modding support potential
+- **Web**: Download size, browser limitations, instant play
+
+## System-Specific Architecture
+
+### For Games with Heavy Systems
+
+**Only include systems relevant to the game type:**
+
+**Physics System** (for physics-based games)
+
+- 2D vs 3D physics engine
+- Deterministic requirements
+- Custom vs. built-in
+
+**AI System** (for games with NPCs/enemies)
+
+- Behavior trees vs. state machines
+- Pathfinding requirements
+- Group behaviors
+
+**Procedural Generation** (for roguelikes, infinite runners)
+
+- Generation algorithms
+- Seed management
+- Content validation
+
+**Inventory System** (for RPGs, survival)
+
+- Item database design
+- Stack management
+- Equipment slots
+
+**Dialogue System** (for narrative games)
+
+- Dialogue tree structure
+- Localization support
+- Voice acting integration
+
+**Combat System** (for action games)
+
+- Damage calculation
+- Hitbox/hurtbox system
+- Combo system
+
+## Development Workflow Optimization
+
+**Based on Team and Scope:**
+
+- **Rapid Prototyping**: Focus on quick iteration
+- **Long Development**: Emphasize maintainability
+- **Live Service**: Built-in analytics and update systems
+- **Jam Game**: Absolute minimum viable architecture
+
+## Adaptive Guidance Framework
+
+When processing game requirements:
+
+1. **Identify Game Type** from GDD
+2. **Determine Complexity Level**:
+   - Simple (jam game, prototype)
+   - Medium (indie release)
+   - Complex (commercial, multiplayer)
+3. **Check Engine Preference** or guide selection
+4. **Load Game-Type Specific Needs**
+5. **Merge with Platform Requirements**
+6. **Output Focused Architecture**
+
+## Key Principles
+
+1. **Game type drives architecture** - RPG != Puzzle != Shooter
+2. **Don't over-engineer** - Match complexity to scope
+3. **Prototype the core loop first** - Architecture serves gameplay
+4. **Engine choice affects everything** - Align architecture with engine
+5. **Performance requirements vary** - Mobile puzzle != PC MMO
+
+## Output Format
+
+Structure decisions as:
+
+- **Engine**: [Specific engine and version, with rationale for beginners]
+- **Core Systems**: [Only systems needed for this game type]
+- **Architecture Pattern**: [Appropriate for game complexity]
+- **Platform Optimizations**: [Specific to target platforms]
+- **Development Pipeline**: [Scaled to team size]
+
+IMPORTANT: Focus on architecture that enables the specific game type's core mechanics and requirements. Don't include systems the game doesn't need.

src/modules/bmm/workflows/3-solutioning/project-types/game-questions.md

@@ -1,133 +0,0 @@
-# Game Architecture Questions
-
-## Engine and Platform
-
-1. **Game engine:**
-   - Unity (C#, versatile, large ecosystem)
-   - Unreal Engine (C++, AAA graphics)
-   - Godot (GDScript/C#, open-source)
-   - Custom engine
-   - Other: **\_\_\_**
-
-2. **Target platforms:**
-   - PC (Windows, Mac, Linux)
-   - Mobile (iOS, Android)
-   - Console (Xbox, PlayStation, Switch)
-   - Web (WebGL)
-   - Mix: **\_\_\_**
-
-3. **2D or 3D:**
-   - 2D
-   - 3D
-   - 2.5D (3D with 2D gameplay)
-
-## Architecture Pattern
-
-4. **Core architecture:**
-   - ECS (Entity Component System) - Unity DOTS, Bevy
-   - OOP (Object-Oriented) - Unity MonoBehaviours, Unreal Actors
-   - Data-Oriented Design
-   - Mix
-
-5. **Scene structure:**
-   - Single scene (load/unload prefabs)
-   - Multi-scene (additive loading)
-   - Scene per level
-
-## Multiplayer (if applicable)
-
-6. **Multiplayer type:**
-   - Single-player only
-   - Local multiplayer (same device/splitscreen)
-   - Online multiplayer
-   - Both local + online
-
-7. **If online multiplayer - networking:**
-   - Photon (popular, managed)
-   - Mirror (Unity, open-source)
-   - Netcode for GameObjects (Unity, official)
-   - Unreal Replication
-   - Custom netcode
-   - Other: **\_\_\_**
-
-8. **Multiplayer architecture:**
-   - Client-Server (authoritative server)
-   - Peer-to-Peer
-   - Dedicated servers
-   - Listen server (player hosts)
-
-9. **Backend for multiplayer:**
-   - PlayFab (Microsoft, game backend)
-   - Nakama (open-source game server)
-   - GameSparks (AWS)
-   - Firebase
-   - Custom backend
-
-## Save System
-
-10. **Save/persistence:**
-    - Local only (PlayerPrefs, file)
-    - Cloud save (Steam Cloud, PlayFab)
-    - Both local + cloud sync
-    - No saves needed
-
-## Monetization (if applicable)
-
-11. **Monetization model:**
-    - Paid (one-time purchase)
-    - Free-to-play + IAP
-    - Free-to-play + Ads
-    - Subscription
-    - None (hobby/portfolio)
-
-12. **If IAP - platform:**
-    - Unity IAP (cross-platform)
-    - Steam microtransactions
-    - Mobile stores (App Store, Google Play)
-    - Custom (virtual currency)
-
-13. **If Ads:**
-    - Unity Ads
-    - AdMob (Google)
-    - IronSource
-    - Other: **\_\_\_**
-
-## Assets
-
-14. **Asset pipeline:**
-    - Unity Asset Bundles
-    - Unreal Pak files
-    - Addressables (Unity)
-    - Streaming from CDN
-    - All assets in build
-
-15. **Art creation tools:**
-    - Blender (3D modeling)
-    - Maya/3DS Max
-    - Photoshop (textures)
-    - Substance (materials)
-    - Aseprite (pixel art)
-    - Other: **\_\_\_**
-
-## Analytics and LiveOps
-
-16. **Analytics:**
-    - Unity Analytics
-    - GameAnalytics
-    - Firebase Analytics
-    - PlayFab Analytics
-    - None
-
-17. **LiveOps/Events:**
-    - Remote config (Unity, Firebase)
-    - In-game events
-    - Season passes
-    - None (fixed content)
-
-## Audio
-
-18. **Audio middleware:**
-    - Unity Audio (built-in)
-    - FMOD
-    - Wwise
-    - Simple (no middleware)

src/modules/bmm/workflows/3-solutioning/project-types/game-template.md

@@ -0,0 +1,283 @@
+# Game Architecture Document
+
+**Project:** {{project_name}}
+**Game Type:** {{game_type}}
+**Platform(s):** {{target_platforms}}
+**Date:** {{date}}
+**Author:** {{user_name}}
+
+## Executive Summary
+
+{{executive_summary}}
+
+<critical>
+This architecture adapts to {{game_type}} requirements.
+Sections are included/excluded based on game needs.
+</critical>
+
+## 1. Core Technology Decisions
+
+### 1.1 Essential Technology Stack
+
+| Category    | Technology      | Version              | Justification              |
+| ----------- | --------------- | -------------------- | -------------------------- |
+| Game Engine | {{game_engine}} | {{engine_version}}   | {{engine_justification}}   |
+| Language    | {{language}}    | {{language_version}} | {{language_justification}} |
+| Platform(s) | {{platforms}}   | -                    | {{platform_justification}} |
+
+### 1.2 Game-Specific Technologies
+
+<intent>
+Only include rows relevant to this game type:
+- Physics: Only for physics-based games
+- Networking: Only for multiplayer games
+- AI: Only for games with NPCs/enemies
+- Procedural: Only for roguelikes/procedural games
+</intent>
+
+{{game_specific_tech_table}}
+
+## 2. Architecture Pattern
+
+### 2.1 High-Level Architecture
+
+{{architecture_pattern}}
+
+**Pattern Justification for {{game_type}}:**
+{{pattern_justification}}
+
+### 2.2 Code Organization Strategy
+
+{{code_organization}}
+
+## 3. Core Game Systems
+
+<intent>
+This section should be COMPLETELY different based on game type:
+- Visual Novel: Dialogue system, save states, branching
+- RPG: Stats, inventory, quests, progression
+- Puzzle: Level data, hint system, solution validation
+- Shooter: Weapons, damage, physics
+- Racing: Vehicle physics, track system, lap timing
+- Strategy: Unit management, resource system, AI
+</intent>
+
+### 3.1 Core Game Loop
+
+{{core_game_loop}}
+
+### 3.2 Primary Game Systems
+
+{{#for_game_type}}
+Include ONLY systems this game needs
+{{/for_game_type}}
+
+{{primary_game_systems}}
+
+## 4. Data Architecture
+
+### 4.1 Data Management Strategy
+
+<intent>
+Adapt to game data needs:
+- Simple puzzle: JSON level files
+- RPG: Complex relational data
+- Multiplayer: Server-authoritative state
+- Roguelike: Seed-based generation
+</intent>
+
+{{data_management}}
+
+### 4.2 Save System
+
+{{save_system}}
+
+### 4.3 Content Pipeline
+
+{{content_pipeline}}
+
+## 5. Scene/Level Architecture
+
+<intent>
+Structure varies by game type:
+- Linear: Sequential level loading
+- Open World: Streaming and chunks
+- Stage-based: Level selection and unlocking
+- Procedural: Generation pipeline
+</intent>
+
+{{scene_architecture}}
+
+## 6. Gameplay Implementation
+
+<intent>
+ONLY include subsections relevant to the game.
+A racing game doesn't need an inventory system.
+A puzzle game doesn't need combat mechanics.
+</intent>
+
+{{gameplay_systems}}
+
+## 7. Presentation Layer
+
+<intent>
+Adapt to visual style:
+- 3D: Rendering pipeline, lighting, LOD
+- 2D: Sprite management, layers
+- Text: Minimal visual architecture
+- Hybrid: Both 2D and 3D considerations
+</intent>
+
+### 7.1 Visual Architecture
+
+{{visual_architecture}}
+
+### 7.2 Audio Architecture
+
+{{audio_architecture}}
+
+### 7.3 UI/UX Architecture
+
+{{ui_architecture}}
+
+## 8. Input and Controls
+
+{{input_controls}}
+
+{{#if_multiplayer}}
+
+## 9. Multiplayer Architecture
+
+<critical>
+Only for games with multiplayer features
+</critical>
+
+### 9.1 Network Architecture
+
+{{network_architecture}}
+
+### 9.2 State Synchronization
+
+{{state_synchronization}}
+
+### 9.3 Matchmaking and Lobbies
+
+{{matchmaking}}
+
+### 9.4 Anti-Cheat Strategy
+
+{{anticheat}}
+{{/if_multiplayer}}
+
+## 10. Platform Optimizations
+
+<intent>
+Platform-specific considerations:
+- Mobile: Touch controls, battery, performance
+- Console: Achievements, controllers, certification
+- PC: Wide hardware range, settings
+- Web: Download size, browser compatibility
+</intent>
+
+{{platform_optimizations}}
+
+## 11. Performance Strategy
+
+### 11.1 Performance Targets
+
+{{performance_targets}}
+
+### 11.2 Optimization Approach
+
+{{optimization_approach}}
+
+## 12. Asset Pipeline
+
+### 12.1 Asset Workflow
+
+{{asset_workflow}}
+
+### 12.2 Asset Budget
+
+<intent>
+Adapt to platform and game type:
+- Mobile: Strict size limits
+- Web: Download optimization
+- Console: Memory constraints
+- PC: Balance quality vs. performance
+</intent>
+
+{{asset_budget}}
+
+## 13. Source Tree
+
+```
+{{source_tree}}
+```
+
+**Key Directories:**
+{{key_directories}}
+
+## 14. Development Guidelines
+
+### 14.1 Coding Standards
+
+{{coding_standards}}
+
+### 14.2 Engine-Specific Best Practices
+
+{{engine_best_practices}}
+
+## 15. Build and Deployment
+
+### 15.1 Build Configuration
+
+{{build_configuration}}
+
+### 15.2 Distribution Strategy
+
+{{distribution_strategy}}
+
+## 16. Testing Strategy
+
+<intent>
+Testing needs vary by game:
+- Multiplayer: Network testing, load testing
+- Procedural: Seed testing, generation validation
+- Physics: Determinism testing
+- Narrative: Story branch testing
+</intent>
+
+{{testing_strategy}}
+
+## 17. Key Architecture Decisions
+
+### Decision Records
+
+{{architecture_decisions}}
+
+### Risk Mitigation
+
+{{risk_mitigation}}
+
+{{#if_complex_project}}
+
+## 18. Specialist Considerations
+
+<intent>
+Only for complex projects needing specialist input
+</intent>
+
+{{specialist_notes}}
+{{/if_complex_project}}
+
+---
+
+## Implementation Roadmap
+
+{{implementation_roadmap}}
+
+---
+
+_Architecture optimized for {{game_type}} game on {{platforms}}_
+_Generated using BMad Method Solution Architecture workflow_

src/modules/bmm/workflows/3-solutioning/project-types/infra-questions.md

@@ -1,484 +0,0 @@
-# Infrastructure/DevOps Tool Architecture Questions
-
-## Tool Type
-
-1. **Primary tool category:**
-   - Infrastructure as Code (IaC) module/provider
-   - Kubernetes Operator
-   - CI/CD plugin/action
-   - Monitoring/Observability tool
-   - Configuration management tool
-   - Deployment automation tool
-   - GitOps tool
-   - Security/Compliance scanner
-   - Cost optimization tool
-   - Multi-tool platform
-
-## Infrastructure as Code (IaC)
-
-2. **IaC platform (if applicable):**
-   - Terraform
-   - Pulumi
-   - CloudFormation (AWS)
-   - Bicep (Azure)
-   - CDK (AWS, TypeScript/Python)
-   - CDKTF (Terraform with CDK)
-   - Ansible
-   - Chef
-   - Puppet
-   - Not applicable
-
-3. **IaC language:**
-   - HCL (Terraform)
-   - TypeScript (Pulumi, CDK)
-   - Python (Pulumi, CDK)
-   - Go (Pulumi)
-   - YAML (CloudFormation, Ansible)
-   - JSON
-   - Domain-specific language
-   - Other: **\_\_\_**
-
-4. **Terraform specifics (if applicable):**
-   - Terraform module (reusable component)
-   - Terraform provider (new resource types)
-   - Terraform backend (state storage)
-   - Not using Terraform
-
-5. **Target cloud platforms:**
-   - AWS
-   - Azure
-   - Google Cloud
-   - Multi-cloud
-   - On-premise (VMware, OpenStack)
-   - Hybrid cloud
-   - Kubernetes (cloud-agnostic)
-
-## Kubernetes Operator (if applicable)
-
-6. **Operator framework:**
-   - Operator SDK (Go)
-   - Kubebuilder (Go)
-   - KUDO
-   - Kopf (Python)
-   - Java Operator SDK
-   - Metacontroller
-   - Custom (raw client-go)
-   - Not applicable
-
-7. **Operator type:**
-   - Application operator (manage app lifecycle)
-   - Infrastructure operator (manage resources)
-   - Data operator (databases, queues)
-   - Security operator
-   - Other: **\_\_\_**
-
-8. **Custom Resource Definitions (CRDs):**
-   - Define new CRDs
-   - Use existing CRDs
-   - Multiple CRDs
-
-9. **Operator scope:**
-   - Namespace-scoped
-   - Cluster-scoped
-   - Both
-
-10. **Reconciliation pattern:**
-    - Level-based (check desired vs actual state)
-    - Edge-triggered (react to changes)
-    - Hybrid
-
-## CI/CD Integration
-
-11. **CI/CD platform (if plugin/action):**
-    - GitHub Actions
-    - GitLab CI
-    - Jenkins
-    - CircleCI
-    - Azure DevOps
-    - Bitbucket Pipelines
-    - Drone CI
-    - Tekton
-    - Argo Workflows
-    - Not applicable
-
-12. **Plugin type (if CI/CD plugin):**
-    - Build step
-    - Test step
-    - Deployment step
-    - Security scan
-    - Notification
-    - Custom action
-    - Not applicable
-
-13. **GitHub Action specifics (if applicable):**
-    - JavaScript action
-    - Docker container action
-    - Composite action (reusable workflow)
-    - Not using GitHub Actions
-
-## Configuration and State Management
-
-14. **Configuration approach:**
-    - Configuration files (YAML, JSON, HCL)
-
-- Environment variables
-- Command-line flags
-- API-based configuration
-- Multiple methods
-
-15. **State management:**
-    - Stateless (idempotent operations)
-    - Local state file
-    - Remote state (S3, Consul, Terraform Cloud)
-    - Database state
-    - Kubernetes ConfigMaps/Secrets
-    - Not applicable
-
-16. **Secrets management:**
-    - Vault (HashiCorp)
-    - AWS Secrets Manager
-    - Azure Key Vault
-    - Google Secret Manager
-    - Kubernetes Secrets
-    - SOPS (encrypted files)
-    - Sealed Secrets
-    - External Secrets Operator
-    - Environment variables
-    - Not applicable
-
-## Execution Model
-
-17. **Execution pattern:**
-    - CLI tool (run locally or in CI)
-    - Kubernetes controller (runs in cluster)
-    - Daemon/agent (runs on nodes/VMs)
-    - Web service (API-driven)
-    - Scheduled job (cron, K8s CronJob)
-    - Event-driven (webhook, queue)
-
-18. **Deployment model:**
-    - Single binary (Go, Rust)
-    - Container image
-    - Script (Python, Bash)
-    - Helm chart
-    - Kustomize
-    - Installed via package manager
-    - Multiple deployment methods
-
-19. **Concurrency:**
-    - Single-threaded (sequential)
-    - Multi-threaded (parallel operations)
-    - Async I/O
-    - Not applicable
-
-## Resource Management
-
-20. **Resources managed:**
-    - Compute (VMs, containers, functions)
-    - Networking (VPC, load balancers, DNS)
-    - Storage (disks, buckets, databases)
-    - Identity (IAM, service accounts)
-    - Security (firewall, policies)
-    - Kubernetes resources (pods, services, etc.)
-    - Multiple resource types
-
-21. **Resource lifecycle:**
-    - Create/provision
-    - Update/modify
-    - Delete/destroy
-    - Import existing resources
-    - All of the above
-
-22. **Dependency management:**
-    - Explicit dependencies (depends_on)
-    - Implicit dependencies (reference outputs)
-    - DAG-based (topological sort)
-    - None (independent resources)
-
-## Language and Framework
-
-23. **Implementation language:**
-    - Go (common for K8s, CLI tools)
-    - Python (scripting, automation)
-    - TypeScript/JavaScript (Pulumi, CDK)
-    - Rust (performance-critical tools)
-    - Bash/Shell (simple scripts)
-    - Java (enterprise tools)
-    - Ruby (Chef, legacy tools)
-    - Other: **\_\_\_**
-
-24. **Key libraries/SDKs:**
-    - AWS SDK
-    - Azure SDK
-    - Google Cloud SDK
-    - Kubernetes client-go
-    - Terraform Plugin SDK
-    - Ansible modules
-    - Custom libraries
-    - Other: **\_\_\_**
-
-## API and Integration
-
-25. **API exposure:**
-    - REST API
-    - gRPC API
-    - CLI only (no API)
-    - Kubernetes API (CRDs)
-    - Webhook receiver
-    - Multiple interfaces
-
-26. **External integrations:**
-    - Cloud provider APIs (AWS, Azure, GCP)
-    - Kubernetes API
-    - Monitoring systems (Prometheus, Datadog)
-    - Notification services (Slack, PagerDuty)
-    - Version control (Git)
-    - Other: **\_\_\_**
-
-## Idempotency and Safety
-
-27. **Idempotency:**
-    - Fully idempotent (safe to run multiple times)
-    - Conditionally idempotent (with flags)
-    - Not idempotent (manual cleanup needed)
-
-28. **Dry-run/Plan mode:**
-    - Yes (preview changes before applying)
-    - No (immediate execution)
-
-29. **Rollback capability:**
-    - Automatic rollback on failure
-    - Manual rollback (previous state)
-    - No rollback (manual cleanup)
-
-30. **Destructive operations:**
-    - Confirmation required (--force flag)
-    - Automatic (with safeguards)
-    - Not applicable (read-only tool)
-
-## Observability
-
-31. **Logging:**
-    - Structured logging (JSON)
-    - Plain text logs
-    - Library: (logrus, zap, winston, etc.)
-    - Multiple log levels (debug, info, warn, error)
-
-32. **Metrics:**
-    - Prometheus metrics
-    - CloudWatch metrics
-    - Datadog metrics
-    - Custom metrics
-    - None
-
-33. **Tracing:**
-    - OpenTelemetry
-    - Jaeger
-    - Not applicable
-
-34. **Health checks:**
-    - Kubernetes liveness/readiness probes
-    - HTTP health endpoint
-    - Not applicable (CLI tool)
-
-## Testing
-
-35. **Testing approach:**
-    - Unit tests (mock external APIs)
-    - Integration tests (real cloud resources)
-    - E2E tests (full workflow)
-    - Contract tests (API compatibility)
-    - Manual testing
-    - All of the above
-
-36. **Test environment:**
-    - Local (mocked)
-    - Dev/staging cloud account
-    - Kind/minikube (for K8s)
-    - Multiple environments
-
-37. **Terraform testing (if applicable):**
-    - Terratest (Go-based testing)
-    - terraform validate
-    - terraform plan (in CI)
-    - Not applicable
-
-38. **Kubernetes testing (if operator):**
-    - Unit tests (Go testing)
-    - envtest (fake API server)
-    - Kind cluster (real cluster)
-    - Not applicable
-
-## Documentation
-
-39. **Documentation format:**
-    - README (basic)
-    - Detailed docs (Markdown files)
-    - Generated docs (godoc, Sphinx, etc.)
-    - Doc website (MkDocs, Docusaurus)
-    - Interactive examples
-    - All of the above
-
-40. **Usage examples:**
-    - Code examples
-    - Tutorial walkthroughs
-    - Video demos
-    - Sample configurations
-    - Minimal (README only)
-
-## Distribution
-
-41. **Distribution method:**
-    - GitHub Releases (binaries)
-    - Package manager (homebrew, apt, yum)
-    - Container registry (Docker Hub, ghcr.io)
-    - Terraform Registry
-    - Helm chart repository
-    - Language package manager (npm, pip, gem)
-    - Multiple methods
-
-42. **Installation:**
-    - Download binary
-    - Package manager install
-    - Helm install (for K8s)
-    - Container image pull
-    - Build from source
-    - Multiple methods
-
-43. **Versioning:**
-    - Semantic versioning (semver)
-    - Calendar versioning
-    - API version compatibility
-
-## Updates and Lifecycle
-
-44. **Update mechanism:**
-    - Manual download/install
-    - Package manager update
-    - Auto-update (self-update command)
-    - Helm upgrade
-    - Not applicable
-
-45. **Backward compatibility:**
-    - Fully backward compatible
-    - Breaking changes documented
-    - Migration guides provided
-
-46. **Deprecation policy:**
-    - Formal deprecation warnings
-    - Support for N-1 versions
-    - No formal policy
-
-## Security
-
-47. **Credentials handling:**
-    - Environment variables
-    - Config file (encrypted)
-    - Cloud provider IAM (instance roles, IRSA)
-    - Kubernetes ServiceAccount
-    - Vault integration
-    - Multiple methods
-
-48. **Least privilege:**
-    - Minimal permissions documented
-    - Permission templates provided (IAM policies)
-    - No specific guidance
-
-49. **Code signing:**
-    - Signed binaries
-    - Container image signing (cosign)
-    - Not signed
-
-50. **Supply chain security:**
-    - SBOM (Software Bill of Materials)
-    - Provenance attestation
-    - Dependency scanning
-    - None
-
-## Compliance and Governance
-
-51. **Compliance focus:**
-    - Policy enforcement (OPA, Kyverno)
-    - Audit logging
-    - Cost tagging
-    - Security posture
-    - Not applicable
-
-52. **Policy as Code:**
-    - OPA (Open Policy Agent)
-    - Sentinel (Terraform)
-    - Kyverno (Kubernetes)
-    - Custom policies
-    - Not applicable
-
-53. **Audit trail:**
-    - Change tracking
-    - GitOps audit (Git history)
-    - CloudTrail/Activity logs
-    - Not applicable
-
-## Performance and Scale
-
-54. **Performance requirements:**
-    - Fast execution (seconds)
-    - Moderate (minutes)
-    - Long-running (hours acceptable)
-    - Background reconciliation (continuous)
-
-55. **Scale considerations:**
-    - Small scale (< 10 resources)
-    - Medium (10-100 resources)
-    - Large (100-1000 resources)
-    - Very large (1000+ resources)
-
-56. **Rate limiting:**
-    - Respect cloud API limits
-    - Configurable rate limits
-    - Not applicable
-
-## CI/CD and Automation
-
-57. **CI/CD for the tool itself:**
-    - GitHub Actions
-    - GitLab CI
-    - CircleCI
-    - Custom
-    - Manual builds
-
-58. **Release automation:**
-    - Automated releases (tags trigger build)
-    - Manual releases
-    - GoReleaser (for Go projects)
-    - Semantic release
-
-59. **Pre-commit hooks:**
-    - Linting
-    - Formatting
-    - Security scans
-    - None
-
-## Community and Ecosystem
-
-60. **Open source:**
-    - Fully open source
-    - Proprietary
-    - Open core (free + paid features)
-
-61. **License:**
-    - MIT
-    - Apache 2.0
-    - GPL
-    - Proprietary
-    - Other: **\_\_\_**
-
-62. **Community support:**
-    - GitHub issues
-    - Slack/Discord community
-    - Forum
-    - Commercial support
-    - Minimal (internal tool)
-
-63. **Plugin/Extension system:**
-    - Extensible (plugins supported)
-    - Monolithic
-    - Planned for future

src/modules/bmm/workflows/3-solutioning/project-types/infrastructure-instructions.md

@@ -0,0 +1,198 @@
+# Infrastructure/DevOps Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for infrastructure and DevOps architecture decisions.
+The LLM should:
+- Understand scale, reliability, and compliance requirements
+- Guide cloud vs. on-premise vs. hybrid decisions
+- Focus on automation and infrastructure as code
+- Consider team size and DevOps maturity
+- Balance complexity with operational overhead
+</critical>
+
+## Cloud Strategy
+
+**Platform Selection**
+Based on requirements and constraints:
+
+- **Public Cloud**: AWS, GCP, Azure for scalability
+- **Private Cloud**: OpenStack, VMware for control
+- **Hybrid**: Mix of public and on-premise
+- **Multi-cloud**: Avoid vendor lock-in
+- **On-premise**: Regulatory or latency requirements
+
+Consider existing contracts, team expertise, and geographic needs.
+
+## Infrastructure as Code
+
+**IaC Approach**
+Based on team and complexity:
+
+- **Terraform**: Cloud-agnostic, declarative
+- **CloudFormation/ARM/GCP Deployment Manager**: Cloud-native
+- **Pulumi/CDK**: Programmatic infrastructure
+- **Ansible/Chef/Puppet**: Configuration management
+- **GitOps**: Flux, ArgoCD for Kubernetes
+
+Start with declarative approaches unless programmatic benefits are clear.
+
+## Container Strategy
+
+**Containerization Approach**
+
+- **Docker**: Standard for containerization
+- **Kubernetes**: For complex orchestration needs
+- **ECS/Cloud Run**: Managed container services
+- **Docker Compose/Swarm**: Simple orchestration
+- **Serverless**: Skip containers entirely
+
+Don't use Kubernetes for simple applications - complexity has a cost.
+
+## CI/CD Architecture
+
+**Pipeline Design**
+
+- Source control strategy (GitFlow, GitHub Flow, trunk-based)
+- Build automation and artifact management
+- Testing stages (unit, integration, e2e)
+- Deployment strategies (blue-green, canary, rolling)
+- Environment promotion process
+
+Match complexity to release frequency and risk tolerance.
+
+## Monitoring and Observability
+
+**Observability Stack**
+Based on scale and requirements:
+
+- **Metrics**: Prometheus, CloudWatch, Datadog
+- **Logging**: ELK, Loki, CloudWatch Logs
+- **Tracing**: Jaeger, X-Ray, Datadog APM
+- **Synthetic Monitoring**: Pingdom, New Relic
+- **Incident Management**: PagerDuty, Opsgenie
+
+Build observability appropriate to SLA requirements.
+
+## Security Architecture
+
+**Security Layers**
+
+- Network security (VPC, security groups, NACLs)
+- Identity and access management
+- Secrets management (Vault, AWS Secrets Manager)
+- Vulnerability scanning
+- Compliance automation
+
+Security must be automated and auditable.
+
+## Backup and Disaster Recovery
+
+**Resilience Strategy**
+
+- Backup frequency and retention
+- RTO/RPO requirements
+- Multi-region/multi-AZ design
+- Disaster recovery testing
+- Data replication strategy
+
+Design for your actual recovery requirements, not theoretical disasters.
+
+## Network Architecture
+
+**Network Design**
+
+- VPC/network topology
+- Load balancing strategy
+- CDN implementation
+- Service mesh (if microservices)
+- Zero trust networking
+
+Keep networking as simple as possible while meeting requirements.
+
+## Cost Optimization
+
+**Cost Management**
+
+- Resource right-sizing
+- Reserved instances/savings plans
+- Spot instances for appropriate workloads
+- Auto-scaling policies
+- Cost monitoring and alerts
+
+Build cost awareness into the architecture.
+
+## Database Operations
+
+**Data Layer Management**
+
+- Managed vs. self-hosted databases
+- Backup and restore procedures
+- Read replica configuration
+- Connection pooling
+- Performance monitoring
+
+## Service Mesh and API Gateway
+
+**API Management** (if applicable)
+
+- API Gateway for external APIs
+- Service mesh for internal communication
+- Rate limiting and throttling
+- Authentication and authorization
+- API versioning strategy
+
+## Development Environments
+
+**Environment Strategy**
+
+- Local development setup
+- Development/staging/production parity
+- Environment provisioning automation
+- Data anonymization for non-production
+
+## Compliance and Governance
+
+**Regulatory Requirements**
+
+- Compliance frameworks (SOC 2, HIPAA, PCI DSS)
+- Audit logging and retention
+- Change management process
+- Access control and segregation of duties
+
+Build compliance in, don't bolt it on.
+
+## Adaptive Guidance Examples
+
+**For a Startup MVP:**
+Focus on managed services, simple CI/CD, and basic monitoring.
+
+**For Enterprise Migration:**
+Emphasize hybrid cloud, phased migration, and compliance requirements.
+
+**For High-Traffic Service:**
+Focus on auto-scaling, CDN, caching layers, and performance monitoring.
+
+**For Regulated Industry:**
+Emphasize compliance automation, audit trails, and data residency.
+
+## Key Principles
+
+1. **Automate everything** - Manual processes don't scale
+2. **Design for failure** - Everything fails eventually
+3. **Secure by default** - Security is not optional
+4. **Monitor proactively** - Don't wait for users to report issues
+5. **Document as code** - Infrastructure documentation gets stale
+
+## Output Format
+
+Document as:
+
+- **Platform**: [Cloud/on-premise choice]
+- **IaC Tool**: [Primary infrastructure tool]
+- **Container/Orchestration**: [If applicable]
+- **CI/CD**: [Pipeline tools and strategy]
+- **Monitoring**: [Observability stack]
+
+Focus on automation and operational excellence.

src/modules/bmm/workflows/3-solutioning/project-types/library-instructions.md

@@ -0,0 +1,185 @@
+# Library/SDK Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for library/SDK architecture decisions.
+The LLM should:
+- Understand the library's purpose and target developers
+- Consider API design and developer experience heavily
+- Focus on versioning, compatibility, and distribution
+- Balance flexibility with ease of use
+- Document decisions that affect consumers
+</critical>
+
+## Language and Ecosystem
+
+**Choose Based on Target Users**
+
+- Consider what language your users are already using
+- Factor in cross-language needs (FFI, bindings, REST wrapper)
+- Think about ecosystem conventions and expectations
+- Performance vs. ease of integration trade-offs
+
+Don't create a Rust library for JavaScript developers unless performance is critical.
+
+## API Design Philosophy
+
+**Developer Experience First**
+Based on library complexity:
+
+- **Simple**: Minimal API surface, sensible defaults
+- **Flexible**: Builder pattern, configuration objects
+- **Powerful**: Layered API (simple + advanced)
+- **Framework**: Inversion of control, plugin architecture
+
+Follow language idioms - Pythonic for Python, functional for FP languages.
+
+## Architecture Patterns
+
+**Internal Structure**
+
+- **Facade Pattern**: Hide complexity behind simple interface
+- **Strategy Pattern**: For pluggable implementations
+- **Factory Pattern**: For object creation flexibility
+- **Dependency Injection**: For testability and flexibility
+
+Don't over-engineer simple utility libraries.
+
+## Versioning Strategy
+
+**Semantic Versioning and Compatibility**
+
+- Breaking change policy
+- Deprecation strategy
+- Migration path planning
+- Backward compatibility approach
+
+Consider the maintenance burden of supporting multiple versions.
+
+## Distribution and Packaging
+
+**Package Management**
+
+- **NPM**: For JavaScript/TypeScript
+- **PyPI**: For Python
+- **Maven/Gradle**: For Java/Kotlin
+- **NuGet**: For .NET
+- **Cargo**: For Rust
+- Multiple registries for cross-language
+
+Include CDN distribution for web libraries.
+
+## Testing Strategy
+
+**Library Testing Approach**
+
+- Unit tests for all public APIs
+- Integration tests with common use cases
+- Property-based testing for complex logic
+- Example projects as tests
+- Cross-version compatibility tests
+
+## Documentation Strategy
+
+**Developer Documentation**
+
+- API reference (generated from code)
+- Getting started guide
+- Common use cases and examples
+- Migration guides for major versions
+- Troubleshooting section
+
+Good documentation is critical for library adoption.
+
+## Error Handling
+
+**Developer-Friendly Errors**
+
+- Clear error messages with context
+- Error codes for programmatic handling
+- Stack traces that point to user code
+- Validation with helpful messages
+
+## Performance Considerations
+
+**Library Performance**
+
+- Lazy loading where appropriate
+- Tree-shaking support for web
+- Minimal dependencies
+- Memory efficiency
+- Benchmark suite for performance regression
+
+## Type Safety
+
+**Type Definitions**
+
+- TypeScript definitions for JavaScript libraries
+- Generic types where appropriate
+- Type inference optimization
+- Runtime type checking options
+
+## Dependency Management
+
+**External Dependencies**
+
+- Minimize external dependencies
+- Pin vs. range versioning
+- Security audit process
+- License compatibility
+
+Zero dependencies is ideal for utility libraries.
+
+## Extension Points
+
+**Extensibility Design** (if needed)
+
+- Plugin architecture
+- Middleware pattern
+- Hook system
+- Custom implementations
+
+Balance flexibility with complexity.
+
+## Platform Support
+
+**Cross-Platform Considerations**
+
+- Browser vs. Node.js for JavaScript
+- OS-specific functionality
+- Mobile platform support
+- WebAssembly compilation
+
+## Adaptive Guidance Examples
+
+**For a UI Component Library:**
+Focus on theming, accessibility, tree-shaking, and framework integration.
+
+**For a Data Processing Library:**
+Emphasize streaming APIs, memory efficiency, and format support.
+
+**For an API Client SDK:**
+Focus on authentication, retry logic, rate limiting, and code generation.
+
+**For a Testing Framework:**
+Emphasize assertion APIs, runner architecture, and reporting.
+
+## Key Principles
+
+1. **Make simple things simple** - Common cases should be easy
+2. **Make complex things possible** - Don't limit advanced users
+3. **Fail fast and clearly** - Help developers debug quickly
+4. **Version thoughtfully** - Breaking changes hurt adoption
+5. **Document by example** - Show real-world usage
+
+## Output Format
+
+Structure as:
+
+- **Language**: [Primary language and version]
+- **API Style**: [Design pattern and approach]
+- **Distribution**: [Package registries and methods]
+- **Versioning**: [Strategy and compatibility policy]
+
+Focus on decisions that affect library consumers.

src/modules/bmm/workflows/3-solutioning/project-types/library-questions.md

@@ -1,146 +0,0 @@
-# Library/SDK Architecture Questions
-
-## Language and Platform
-
-1. **Primary language:**
-   - TypeScript/JavaScript
-   - Python
-   - Rust
-   - Go
-   - Java/Kotlin
-   - C#
-   - Other: **\_\_\_**
-
-2. **Target runtime:**
-   - Node.js
-   - Browser (frontend)
-   - Both Node.js + Browser (isomorphic)
-   - Deno
-   - Bun
-   - Python runtime
-   - Other: **\_\_\_**
-
-3. **Package registry:**
-   - npm (JavaScript)
-   - PyPI (Python)
-   - crates.io (Rust)
-   - Maven Central (Java)
-   - NuGet (.NET)
-   - Go modules
-   - Other: **\_\_\_**
-
-## API Design
-
-4. **Public API style:**
-   - Functional (pure functions)
-   - OOP (classes/instances)
-   - Fluent/Builder pattern
-   - Mix
-
-5. **API surface size:**
-   - Minimal (focused, single purpose)
-   - Comprehensive (many features)
-
-6. **Async handling:**
-   - Promises (async/await)
-   - Callbacks
-   - Observables (RxJS)
-   - Synchronous only
-   - Mix
-
-## Type Safety
-
-7. **Type system:**
-   - TypeScript (JavaScript)
-   - Type hints (Python)
-   - Strongly typed (Rust, Go, Java)
-   - Runtime validation (Zod, Yup)
-   - None (JavaScript)
-
-8. **Type definitions:**
-   - Bundled with package
-   - @types package (DefinitelyTyped)
-   - Not applicable
-
-## Build and Distribution
-
-9. **Build tool:**
-   - tsup (TypeScript, simple)
-   - esbuild (fast)
-   - Rollup
-   - Webpack
-   - Vite
-   - tsc (TypeScript compiler only)
-   - Not needed (pure JS)
-
-10. **Output format:**
-    - ESM (modern)
-    - CommonJS (Node.js)
-    - UMD (universal)
-    - Multiple formats
-
-11. **Minification:**
-    - Yes (production bundle)
-    - No (source code)
-    - Source + minified both
-
-## Dependencies
-
-12. **Dependency strategy:**
-    - Zero dependencies (standalone)
-    - Minimal dependencies
-    - Standard dependencies OK
-
-13. **Peer dependencies:**
-    - Yes (e.g., React library requires React)
-    - No
-
-## Documentation
-
-14. **Documentation approach:**
-    - README only
-    - API docs (JSDoc, TypeDoc)
-    - Full docs site (VitePress, Docusaurus)
-    - Examples repo
-    - All of the above
-
-## Testing
-
-15. **Test framework:**
-    - Jest (JavaScript)
-    - Vitest (Vite-compatible)
-    - Pytest (Python)
-    - Cargo test (Rust)
-    - Go test
-    - Other: **\_\_\_**
-
-16. **Test coverage goal:**
-    - High (80%+)
-    - Moderate (50-80%)
-    - Critical paths only
-
-## Versioning and Releases
-
-17. **Versioning:**
-    - Semantic versioning (semver)
-    - Calendar versioning (calver)
-    - Other
-
-18. **Release automation:**
-    - Changesets
-    - Semantic Release
-    - Manual
-    - GitHub Releases
-    - Other: **\_\_\_**
-
-## Additional
-
-19. **CLI included:** (if applicable)
-    - Yes (command-line tool)
-    - No (library only)
-
-20. **Configuration:**
-    - Config file (JSON, YAML)
-    - Programmatic only
-    - Both
-    - None needed

src/modules/bmm/workflows/3-solutioning/project-types/mobile-instructions.md

@@ -0,0 +1,181 @@
+# Mobile Application Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for mobile app architecture decisions.
+The LLM should:
+- Understand platform requirements from the PRD (iOS, Android, or both)
+- Guide framework choice based on team expertise and project needs
+- Focus on mobile-specific concerns (offline, performance, battery)
+- Adapt complexity to project scale and team size
+- Keep decisions concrete and implementation-focused
+</critical>
+
+## Platform Strategy
+
+**Determine the Right Approach**
+Analyze requirements to recommend:
+
+- **Native** (Swift/Kotlin): When platform-specific features and performance are critical
+- **Cross-platform** (React Native/Flutter): For faster development across platforms
+- **Hybrid** (Ionic/Capacitor): When web expertise exists and native features are minimal
+- **PWA**: For simple apps with basic device access needs
+
+Consider team expertise heavily - don't suggest Flutter to an iOS team unless there's strong justification.
+
+## Framework and Technology Selection
+
+**Match Framework to Project Needs**
+Based on the requirements and team:
+
+- **React Native**: JavaScript teams, code sharing with web, large ecosystem
+- **Flutter**: Consistent UI across platforms, high performance animations
+- **Native**: Platform-specific UX, maximum performance, full API access
+- **.NET MAUI**: C# teams, enterprise environments
+
+For beginners: Recommend based on existing web experience.
+For experts: Focus on specific trade-offs relevant to their use case.
+
+## Application Architecture
+
+**Architectural Pattern**
+Guide toward appropriate patterns:
+
+- **MVVM/MVP**: For testability and separation of concerns
+- **Redux/MobX**: For complex state management
+- **Clean Architecture**: For larger teams and long-term maintenance
+
+Don't over-architect simple apps - a basic MVC might suffice for simple utilities.
+
+## Data Management
+
+**Local Storage Strategy**
+Based on data requirements:
+
+- **SQLite**: Structured data, complex queries, offline-first apps
+- **Realm**: Object database for simpler data models
+- **AsyncStorage/SharedPreferences**: Simple key-value storage
+- **Core Data**: iOS-specific with iCloud sync
+
+**Sync and Offline Strategy**
+Only if offline capability is required:
+
+- Conflict resolution approach
+- Sync triggers and frequency
+- Data compression and optimization
+
+## API Communication
+
+**Network Layer Design**
+
+- RESTful APIs for simple CRUD operations
+- GraphQL for complex data requirements
+- WebSocket for real-time features
+- Consider bandwidth optimization for mobile networks
+
+**Security Considerations**
+
+- Certificate pinning for sensitive apps
+- Token storage in secure keychain
+- Biometric authentication integration
+
+## UI/UX Architecture
+
+**Design System Approach**
+
+- Platform-specific (Material Design, Human Interface Guidelines)
+- Custom design system for brand consistency
+- Component library selection
+
+**Navigation Pattern**
+Based on app complexity:
+
+- Tab-based for simple apps with clear sections
+- Drawer navigation for many features
+- Stack navigation for linear flows
+- Hybrid for complex apps
+
+## Performance Optimization
+
+**Mobile-Specific Performance**
+Focus on what matters for mobile:
+
+- App size (consider app thinning, dynamic delivery)
+- Startup time optimization
+- Memory management
+- Battery efficiency
+- Network optimization
+
+Only dive deep into performance if the PRD indicates performance-critical requirements.
+
+## Native Features Integration
+
+**Device Capabilities**
+Based on PRD requirements, plan for:
+
+- Camera/Gallery access patterns
+- Location services and geofencing
+- Push notifications architecture
+- Biometric authentication
+- Payment integration (Apple Pay, Google Pay)
+
+Don't list all possible features - focus on what's actually needed.
+
+## Testing Strategy
+
+**Mobile Testing Approach**
+
+- Unit testing for business logic
+- UI testing for critical flows
+- Device testing matrix (OS versions, screen sizes)
+- Beta testing distribution (TestFlight, Play Console)
+
+Scale testing complexity to project risk and team size.
+
+## Distribution and Updates
+
+**App Store Strategy**
+
+- Release cadence and versioning
+- Update mechanisms (CodePush for React Native, OTA updates)
+- A/B testing and feature flags
+- Crash reporting and analytics
+
+**Compliance and Guidelines**
+
+- App Store/Play Store guidelines
+- Privacy requirements (ATT, data collection)
+- Content ratings and age restrictions
+
+## Adaptive Guidance Examples
+
+**For a Social Media App:**
+Focus on real-time updates, media handling, offline caching, and push notification strategy.
+
+**For an Enterprise App:**
+Emphasize security, MDM integration, SSO, and offline data sync.
+
+**For a Gaming App:**
+Focus on performance, graphics framework, monetization, and social features.
+
+**For a Utility App:**
+Keep it simple - basic UI, minimal backend, focus on core functionality.
+
+## Key Principles
+
+1. **Platform conventions matter** - Don't fight the platform
+2. **Performance is felt immediately** - Mobile users are sensitive to lag
+3. **Offline-first when appropriate** - But don't over-engineer
+4. **Test on real devices** - Simulators hide real issues
+5. **Plan for app store review** - Build in buffer time
+
+## Output Format
+
+Document decisions as:
+
+- **Technology**: [Specific framework/library with version]
+- **Justification**: [Why this fits the requirements]
+- **Platform-specific notes**: [iOS/Android differences if applicable]
+
+Keep mobile-specific considerations prominent in the architecture document.

src/modules/bmm/workflows/3-solutioning/project-types/mobile-questions.md

@@ -1,110 +0,0 @@
-# Mobile Project Architecture Questions
-
-## Platform
-
-1. **Target platforms:**
-   - iOS only
-   - Android only
-   - Both iOS + Android
-
-2. **Framework choice:**
-   - React Native (JavaScript/TypeScript, large ecosystem)
-   - Flutter (Dart, high performance, beautiful UI)
-   - Native (Swift for iOS, Kotlin for Android)
-   - Expo (React Native with managed workflow)
-   - Other: **\_\_\_**
-
-3. **If React Native - workflow:**
-   - Expo (managed, easier, some limitations)
-   - React Native CLI (bare workflow, full control)
-
-## Backend and Data
-
-4. **Backend approach:**
-   - Firebase (BaaS, real-time, easy)
-   - Supabase (BaaS, PostgreSQL, open-source)
-   - Custom API (REST/GraphQL)
-   - AWS Amplify
-   - Other BaaS: **\_\_\_**
-
-5. **Local data persistence:**
-   - AsyncStorage (simple key-value)
-   - SQLite (relational, offline-first)
-   - Realm (NoSQL, sync)
-   - WatermelonDB (reactive, performance)
-   - MMKV (fast key-value)
-
-6. **State management:**
-   - Redux Toolkit
-   - Zustand
-   - MobX
-   - Context API + useReducer
-   - Jotai/Recoil
-   - React Query (server state)
-
-## Navigation
-
-7. **Navigation library:**
-   - React Navigation (standard for RN)
-   - Expo Router (file-based)
-   - React Native Navigation (native navigation)
-
-## Authentication
-
-8. **Auth approach:**
-   - Firebase Auth
-   - Supabase Auth
-   - Auth0
-   - Social auth (Google, Apple, Facebook)
-   - Custom
-   - None
-
-## Push Notifications
-
-9. **Push notifications:** (if needed)
-   - Firebase Cloud Messaging
-   - Expo Notifications
-   - OneSignal
-   - AWS SNS
-   - None needed
-
-## Payments (if applicable)
-
-10. **In-app purchases:**
-    - RevenueCat (cross-platform, subscriptions)
-    - expo-in-app-purchases
-    - react-native-iap
-    - Stripe (external payments)
-    - None needed
-
-## Additional
-
-11. **Maps integration:** (if needed)
-    - Google Maps
-    - Apple Maps
-    - Mapbox
-    - None needed
-
-12. **Analytics:**
-    - Firebase Analytics
-    - Amplitude
-    - Mixpanel
-    - PostHog
-    - None needed
-
-13. **Crash reporting:**
-    - Sentry
-    - Firebase Crashlytics
-    - Bugsnag
-    - None needed
-
-14. **Offline-first requirement:**
-    - Yes (sync when online)
-    - No (online-only)
-    - Partial (some features offline)
-
-15. **App distribution:**
-    - App Store + Google Play (public)
-    - TestFlight + Internal Testing (beta)
-    - Enterprise distribution
-    - Expo EAS Build

src/modules/bmm/workflows/3-solutioning/project-types/project-types.csv

@@ -1,12 +1,12 @@
-project_type_id,display_name,question_file,description,characteristics,typical_stacks,detection_keywords
-web,Web Application,web-questions.md,"Web applications with frontend and/or backend components","has_ui,server_side,browser_based","Next.js+Supabase, React+Django, Vue+Rails","website,web app,frontend,backend,browser,responsive,SPA,SSR,API"
-mobile,Mobile Application,mobile-questions.md,"Native or cross-platform mobile applications for iOS/Android","has_ui,native_app,mobile_platform","React Native+Firebase, Flutter+Supabase","mobile,iOS,Android,app store,react native,flutter,smartphone,tablet"
-embedded,Embedded System,embedded-questions.md,"Embedded systems, IoT devices, and firmware","hardware,firmware,microcontroller,iot","ESP32+FreeRTOS+MQTT, STM32+Bare Metal","embedded,IoT,microcontroller,firmware,sensor,ESP32,Arduino,hardware,MQTT,real-time"
-game,Game,game-questions.md,"Video games for PC, console, mobile, or web","has_ui,real_time,game_engine,interactive","Unity+Photon+PlayFab, Godot+Nakama","game,unity,unreal,godot,multiplayer,gameplay,3D,2D,player,level"
-library,Library/SDK,library-questions.md,"Reusable libraries, SDKs, and packages","no_ui,package,reusable,developer_tool","TypeScript+tsup+npm, Python+pip","library,SDK,package,npm,pip,gem,cargo,reusable,API wrapper,utility"
-desktop,Desktop Application,desktop-questions.md,"Native desktop applications for Windows/Mac/Linux","has_ui,native_app,cross_platform,installable","Electron+React, Tauri+Svelte, .NET MAUI","desktop,Electron,Tauri,Windows,macOS,Linux,installer,native app,system tray"
-cli,Command-Line Tool,cli-questions.md,"Command-line tools and terminal applications","no_ui,terminal,executable,developer_tool","Go+cobra, Rust+clap, Python+click","CLI,command line,terminal,bash,shell,tool,utility,script,console"
-backend,Backend/API Service,backend-questions.md,"Backend services and APIs (no frontend)","no_ui,server_side,api,microservices","Node.js+Express+PostgreSQL, FastAPI+Redis","API,backend,microservice,REST,GraphQL,gRPC,server,service,endpoint,database"
-data,Data/Analytics/ML,data-questions.md,"Data pipelines, analytics, machine learning projects","data_pipeline,analytics,ml,batch_processing","Airflow+Spark+Snowflake, PyTorch+MLflow","ETL,data pipeline,analytics,machine learning,ML,AI,Spark,Airflow,model,dataset,training"
-extension,Browser Extension,extension-questions.md,"Browser extensions for Chrome, Firefox, Safari, etc.","has_ui,browser_specific,client_side","React+Manifest V3, Plasmo+TypeScript","browser extension,Chrome extension,Firefox addon,manifest,content script,popup"
-infra,Infrastructure/DevOps,infra-questions.md,"Infrastructure as Code, K8s operators, CI/CD plugins","automation,infrastructure,devops,tooling","Terraform+AWS, Kubernetes Operator (Go), GitHub Actions","Terraform,Kubernetes,operator,IaC,infrastructure,CI/CD,DevOps,automation,deployment"
+type,name
+web,Web Application
+mobile,Mobile Application
+game,Game Development
+backend,Backend Service
+data,Data Pipeline
+cli,CLI Tool
+library,Library/SDK
+desktop,Desktop Application
+embedded,Embedded System
+extension,Browser/Editor Extension
+infrastructure,Infrastructure

src/modules/bmm/workflows/3-solutioning/project-types/web-instructions.md

@@ -0,0 +1,158 @@
+# Web Project Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+<critical>
+This is a STARTING POINT for web project architecture decisions.
+The LLM should:
+- Understand the project requirements deeply before making suggestions
+- Adapt questions based on user skill level
+- Skip irrelevant areas based on project scope
+- Add project-specific decisions not covered here
+- Make intelligent recommendations users can correct
+</critical>
+
+## Frontend Architecture
+
+**Framework Selection**
+Guide the user to choose a frontend framework based on their project needs. Consider factors like:
+
+- Server-side rendering requirements (SEO, initial load performance)
+- Team expertise and learning curve
+- Project complexity and timeline
+- Community support and ecosystem maturity
+
+For beginners: Suggest mainstream options like Next.js or plain React based on their needs.
+For experts: Discuss trade-offs between frameworks briefly, let them specify preferences.
+
+**Styling Strategy**
+Determine the CSS approach that aligns with their team and project:
+
+- Consider maintainability, performance, and developer experience
+- Factor in design system requirements and component reusability
+- Think about build complexity and tooling
+
+Adapt based on skill level - beginners may benefit from utility-first CSS, while teams with strong CSS expertise might prefer CSS Modules or styled-components.
+
+**State Management**
+Only explore if the project has complex client-side state requirements:
+
+- For simple apps, Context API or server state might suffice
+- For complex apps, discuss lightweight vs. comprehensive solutions
+- Consider data flow patterns and debugging needs
+
+## Backend Strategy
+
+**Backend Architecture**
+Intelligently determine backend needs:
+
+- If it's a static site, skip backend entirely
+- For full-stack apps, consider integrated vs. separate backend
+- Factor in team structure (full-stack vs. specialized teams)
+- Consider deployment and operational complexity
+
+Make smart defaults based on frontend choice (e.g., Next.js API routes for Next.js apps).
+
+**API Design**
+Based on client needs and team expertise:
+
+- REST for simplicity and wide compatibility
+- GraphQL for complex data requirements with multiple clients
+- tRPC for type-safe full-stack TypeScript projects
+- Consider hybrid approaches when appropriate
+
+## Data Layer
+
+**Database Selection**
+Guide based on data characteristics and requirements:
+
+- Relational for structured data with relationships
+- Document stores for flexible schemas
+- Consider managed services vs. self-hosted based on team capacity
+- Factor in existing infrastructure and expertise
+
+For beginners: Suggest managed solutions like Supabase or Firebase.
+For experts: Discuss specific database trade-offs if relevant.
+
+**Data Access Patterns**
+Determine ORM/query builder needs based on:
+
+- Type safety requirements
+- Team SQL expertise
+- Performance requirements
+- Migration and schema management needs
+
+## Authentication & Authorization
+
+**Auth Strategy**
+Assess security requirements and implementation complexity:
+
+- For MVPs: Suggest managed auth services
+- For enterprise: Discuss compliance and customization needs
+- Consider user experience requirements (SSO, social login, etc.)
+
+Skip detailed auth discussion if it's an internal tool or public site without user accounts.
+
+## Deployment & Operations
+
+**Hosting Platform**
+Make intelligent suggestions based on:
+
+- Framework choice (Vercel for Next.js, Netlify for static sites)
+- Budget and scale requirements
+- DevOps expertise
+- Geographic distribution needs
+
+**CI/CD Pipeline**
+Adapt to team maturity:
+
+- For small teams: Platform-provided CI/CD
+- For larger teams: Discuss comprehensive pipelines
+- Consider existing tooling and workflows
+
+## Additional Services
+
+<intent>
+Only discuss these if relevant to the project requirements:
+- Email service (for transactional emails)
+- Payment processing (for e-commerce)
+- File storage (for user uploads)
+- Search (for content-heavy sites)
+- Caching (for performance-critical apps)
+- Monitoring (based on uptime requirements)
+
+Don't present these as a checklist - intelligently determine what's needed based on the PRD/requirements.
+</intent>
+
+## Adaptive Guidance Examples
+
+**For a marketing website:**
+Focus on static site generation, CDN, SEO, and analytics. Skip complex backend discussions.
+
+**For a SaaS application:**
+Emphasize authentication, subscription management, multi-tenancy, and monitoring.
+
+**For an internal tool:**
+Prioritize rapid development, simple deployment, and integration with existing systems.
+
+**For an e-commerce platform:**
+Focus on payment processing, inventory management, performance, and security.
+
+## Key Principles
+
+1. **Start with requirements**, not technology choices
+2. **Adapt to user expertise** - don't overwhelm beginners or bore experts
+3. **Make intelligent defaults** the user can override
+4. **Focus on decisions that matter** for this specific project
+5. **Document definitive choices** with specific versions
+6. **Keep rationale concise** unless explanation is needed
+
+## Output Format
+
+Generate architecture decisions as:
+
+- **Decision**: [Specific technology with version]
+- **Brief Rationale**: [One sentence if needed]
+- **Configuration**: [Key settings if non-standard]
+
+Avoid lengthy explanations unless the user is a beginner or asks for clarification.

src/modules/bmm/workflows/3-solutioning/project-types/web-questions.md

@@ -1,136 +0,0 @@
-# Web Project Architecture Questions
-
-## Frontend
-
-1. **Framework choice:**
-   - Next.js (React, App Router, SSR)
-   - React (SPA, client-only)
-   - Vue 3 + Nuxt
-   - Svelte + SvelteKit
-   - Other: **\_\_\_**
-
-2. **Styling approach:**
-   - Tailwind CSS (utility-first)
-   - CSS Modules
-   - Styled Components (CSS-in-JS)
-   - Sass/SCSS
-   - Other: **\_\_\_**
-
-3. **State management:** (if complex client state)
-   - Zustand (lightweight)
-   - Redux Toolkit
-   - Jotai/Recoil (atomic)
-   - Context API only
-   - Server state only (React Query/SWR)
-
-## Backend
-
-4. **Backend approach:**
-   - Next.js API Routes (integrated)
-   - Express.js (Node.js)
-   - Nest.js (Node.js, structured)
-   - FastAPI (Python)
-   - Django (Python)
-   - Rails (Ruby)
-   - Other: **\_\_\_**
-
-5. **API paradigm:**
-   - REST
-   - GraphQL (Apollo, Relay)
-   - tRPC (type-safe)
-   - gRPC
-   - Mix: **\_\_\_**
-
-## Database
-
-6. **Primary database:**
-   - PostgreSQL (relational, ACID)
-   - MySQL
-   - MongoDB (document)
-   - Supabase (PostgreSQL + backend services)
-   - Firebase Firestore
-   - Other: **\_\_\_**
-
-7. **ORM/Query builder:**
-   - Prisma (type-safe, modern)
-   - Drizzle ORM
-   - TypeORM
-   - Sequelize
-   - Mongoose (for MongoDB)
-   - Raw SQL
-   - Database client directly (Supabase SDK)
-
-## Authentication
-
-8. **Auth approach:**
-   - Supabase Auth (managed, built-in)
-   - Auth0 (managed, enterprise)
-   - Clerk (managed, developer-friendly)
-   - NextAuth.js (self-hosted)
-   - Firebase Auth
-   - Custom JWT implementation
-   - Passport.js
-
-## Deployment
-
-9. **Hosting platform:**
-   - Vercel (optimal for Next.js)
-   - Netlify
-   - AWS (EC2, ECS, Lambda)
-   - Google Cloud
-   - Heroku
-   - Railway
-   - Self-hosted
-
-10. **CI/CD:**
-    - GitHub Actions
-    - GitLab CI
-    - CircleCI
-    - Vercel/Netlify auto-deploy
-    - Other: **\_\_\_**
-
-## Additional Services (if applicable)
-
-11. **Email service:** (if transactional emails needed)
-    - Resend (developer-friendly, modern)
-    - SendGrid
-    - AWS SES
-    - Postmark
-    - None needed
-
-12. **Payment processing:** (if e-commerce/subscriptions)
-    - Stripe (comprehensive)
-    - Lemon Squeezy (SaaS-focused)
-    - PayPal
-    - Square
-    - None needed
-
-13. **File storage:** (if user uploads)
-    - Supabase Storage
-    - AWS S3
-    - Cloudflare R2
-    - Vercel Blob
-    - Uploadthing
-    - None needed
-
-14. **Search:** (if full-text search beyond database)
-    - Elasticsearch
-    - Algolia
-    - Meilisearch
-    - Typesense
-    - Database full-text (PostgreSQL)
-    - None needed
-
-15. **Caching:** (if performance critical)
-    - Redis (external cache)
-    - In-memory (Node.js cache)
-    - CDN caching (Cloudflare/Vercel)
-    - None needed
-
-16. **Monitoring/Error Tracking:**
-    - Sentry (error tracking)
-    - PostHog (product analytics)
-    - Datadog
-    - LogRocket
-    - Vercel Analytics
-    - None needed

src/modules/bmm/workflows/3-solutioning/tech-spec/workflow.yaml

@@ -7,6 +7,8 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+user_skill_level: "{config_source}:user_skill_level"
 date: system-generated
 
 # Inputs expected (ask user if missing)

src/modules/bmm/workflows/3-solutioning/templates/game-engine-architecture.md

@@ -1,244 +0,0 @@
-# Game Architecture Document
-
-**Project:** {{project_name}}
-**Date:** {{date}}
-**Author:** {{user_name}}
-
-## Executive Summary
-
-{{executive_summary}}
-
-## 1. Technology Stack and Decisions
-
-### 1.1 Technology and Library Decision Table
-
-| Category           | Technology             | Version                | Justification                |
-| ------------------ | ---------------------- | ---------------------- | ---------------------------- |
-| Game Engine        | {{game_engine}}        | {{engine_version}}     | {{engine_justification}}     |
-| Language           | {{language}}           | {{language_version}}   | {{language_justification}}   |
-| Rendering Pipeline | {{rendering_pipeline}} | {{rendering_version}}  | {{rendering_justification}}  |
-| Physics Engine     | {{physics}}            | {{physics_version}}    | {{physics_justification}}    |
-| Audio Middleware   | {{audio}}              | {{audio_version}}      | {{audio_justification}}      |
-| Networking         | {{networking}}         | {{networking_version}} | {{networking_justification}} |
-| Backend Services   | {{backend}}            | {{backend_version}}    | {{backend_justification}}    |
-| Analytics          | {{analytics}}          | {{analytics_version}}  | {{analytics_justification}}  |
-
-{{additional_tech_stack_rows}}
-
-## 2. Engine and Platform
-
-### 2.1 Game Engine Choice
-
-{{engine_choice}}
-
-### 2.2 Target Platforms
-
-{{target_platforms}}
-
-### 2.3 Rendering Pipeline
-
-{{rendering_pipeline_details}}
-
-## 3. Game Architecture
-
-### 3.1 Architecture Pattern
-
-{{architecture_pattern}}
-
-### 3.2 Scene Structure
-
-{{scene_structure}}
-
-### 3.3 Game Loop
-
-{{game_loop}}
-
-### 3.4 State Machine
-
-{{state_machine}}
-
-## 4. Scene and Level Architecture
-
-### 4.1 Scene Organization
-
-{{scene_organization}}
-
-### 4.2 Level Streaming
-
-{{level_streaming}}
-
-### 4.3 Additive Loading
-
-{{additive_loading}}
-
-### 4.4 Memory Management
-
-{{memory_management}}
-
-## 5. Gameplay Systems
-
-### 5.1 Player Controller
-
-{{player_controller}}
-
-### 5.2 Game State Management
-
-{{game_state}}
-
-### 5.3 Inventory System
-
-{{inventory}}
-
-### 5.4 Progression System
-
-{{progression}}
-
-### 5.5 Combat/Core Mechanics
-
-{{core_mechanics}}
-
-## 6. Rendering Architecture
-
-### 6.1 Rendering Pipeline
-
-{{rendering_pipeline_architecture}}
-
-### 6.2 Shaders
-
-{{shaders}}
-
-### 6.3 Post-Processing
-
-{{post_processing}}
-
-### 6.4 LOD System
-
-{{lod_system}}
-
-### 6.5 Occlusion Culling
-
-{{occlusion}}
-
-## 7. Asset Pipeline
-
-### 7.1 Model Import
-
-{{model_import}}
-
-### 7.2 Textures and Materials
-
-{{textures_materials}}
-
-### 7.3 Asset Bundles/Addressables
-
-{{asset_bundles}}
-
-### 7.4 Asset Optimization
-
-{{asset_optimization}}
-
-## 8. Animation System
-
-{{animation_system}}
-
-## 9. Physics and Collision
-
-{{physics_collision}}
-
-## 10. Multiplayer Architecture
-
-{{multiplayer_section}}
-
-**Note:** {{multiplayer_note}}
-
-## 11. Backend Services
-
-{{backend_services}}
-
-**Note:** {{backend_note}}
-
-## 12. Save System
-
-{{save_system}}
-
-## 13. UI/UX Architecture
-
-{{ui_architecture}}
-
-## 14. Audio Architecture
-
-{{audio_architecture}}
-
-{{audio_specialist_section}}
-
-## 15. Component and Integration Overview
-
-{{component_overview}}
-
-## 16. Architecture Decision Records
-
-{{architecture_decisions}}
-
-**Key decisions:**
-
-- Why this engine? {{engine_decision}}
-- ECS vs OOP? {{ecs_vs_oop_decision}}
-- Multiplayer approach? {{multiplayer_decision}}
-- Asset streaming? {{asset_streaming_decision}}
-
-## 17. Implementation Guidance
-
-### 17.1 Prefab/Blueprint Conventions
-
-{{prefab_conventions}}
-
-### 17.2 Coding Patterns
-
-{{coding_patterns}}
-
-### 17.3 Performance Guidelines
-
-{{performance_guidelines}}
-
-## 18. Proposed Source Tree
-
-```
-{{source_tree}}
-```
-
-**Critical folders:**
-
-- {{critical_folder_1}}: {{critical_folder_1_description}}
-- {{critical_folder_2}}: {{critical_folder_2_description}}
-- {{critical_folder_3}}: {{critical_folder_3_description}}
-
-## 19. Performance and Optimization
-
-{{performance_optimization}}
-
-{{performance_specialist_section}}
-
-## 20. Testing Strategy
-
-{{testing_strategy}}
-
-## 21. Build and Distribution
-
-{{build_distribution}}
-
----
-
-## Specialist Sections
-
-{{specialist_sections_summary}}
-
-### Recommended Specialists:
-
-- {{audio_specialist_recommendation}}
-- {{performance_specialist_recommendation}}
-- {{multiplayer_specialist_recommendation}}
-- {{monetization_specialist_recommendation}}
-
----
-
-_Generated using BMad Method Solution Architecture workflow_

src/modules/bmm/workflows/3-solutioning/templates/game-engine-godot-guide.md

@@ -1,428 +0,0 @@
-# Godot Game Engine Architecture Guide
-
-This guide provides Godot-specific guidance for solution architecture generation.
-
----
-
-## Godot-Specific Questions
-
-### 1. Godot Version and Language Strategy
-
-**Ask:**
-
-- Which Godot version? (3.x, 4.x)
-- Language preference? (GDScript only, C# only, or Mixed GDScript+C#)
-- Target platform(s)? (PC, Mobile, Web, Console)
-
-**Guidance:**
-
-- **Godot 4.x**: Modern, Vulkan renderer, better 3D, C# improving
-- **Godot 3.x**: Stable, mature ecosystem, OpenGL
-- **GDScript**: Python-like, fast iteration, integrated with editor
-- **C#**: Better performance for complex systems, familiar to Unity devs
-- **Mixed**: GDScript for game logic, C# for performance-critical (physics, AI)
-
-**Record ADR:** Godot version and language strategy
-
----
-
-### 2. Node-Based Architecture
-
-**Ask:**
-
-- Scene composition strategy? (Nested scenes, scene inheritance, or flat hierarchy)
-- Node organization patterns? (By feature, by type, or hybrid)
-
-**Guidance:**
-
-- **Scenes as Prefabs**: Each reusable entity is a scene (Player.tscn, Enemy.tscn)
-- **Scene Inheritance**: Extend base scenes for variations (BaseEnemy → FlyingEnemy)
-- **Node Signals**: Use built-in signal system for decoupled communication
-- **Autoload Singletons**: For global managers (GameManager, AudioManager)
-
-**Godot Pattern:**
-
-```gdscript
-# Player.gd
-extends CharacterBody2D
-
-signal health_changed(new_health)
-signal died
-
-@export var max_health: int = 100
-var health: int = max_health
-
-func take_damage(amount: int) -> void:
-    health -= amount
-    health_changed.emit(health)
-    if health <= 0:
-        died.emit()
-        queue_free()
-```
-
-**Record ADR:** Scene architecture and node organization
-
----
-
-### 3. Resource Management
-
-**Ask:**
-
-- Use Godot Resources for data? (Custom Resource types for game data)
-- Asset loading strategy? (preload vs load vs ResourceLoader)
-
-**Guidance:**
-
-- **Resources**: Like Unity ScriptableObjects, serializable data containers
-- **preload()**: Load at compile time (fast, but increases binary size)
-- **load()**: Load at runtime (slower, but smaller binary)
-- **ResourceLoader.load_threaded_request()**: Async loading for large assets
-
-**Pattern:**
-
-```gdscript
-# EnemyData.gd
-class_name EnemyData
-extends Resource
-
-@export var enemy_name: String
-@export var health: int
-@export var speed: float
-@export var prefab_scene: PackedScene
-```
-
-**Record ADR:** Resource and asset loading strategy
-
----
-
-## Godot-Specific Architecture Sections
-
-### Signal-Driven Communication
-
-**Godot's built-in Observer pattern:**
-
-```gdscript
-# GameManager.gd (Autoload singleton)
-extends Node
-
-signal game_started
-signal game_paused
-signal game_over(final_score: int)
-
-func start_game() -> void:
-    game_started.emit()
-
-func pause_game() -> void:
-    get_tree().paused = true
-    game_paused.emit()
-
-# In Player.gd
-func _ready() -> void:
-    GameManager.game_started.connect(_on_game_started)
-    GameManager.game_over.connect(_on_game_over)
-
-func _on_game_started() -> void:
-    position = Vector2.ZERO
-    health = max_health
-```
-
-**Benefits:**
-
-- Decoupled systems
-- No FindNode or get_node everywhere
-- Type-safe with typed signals (Godot 4)
-
----
-
-### Godot Scene Architecture
-
-**Scene organization patterns:**
-
-**1. Composition Pattern:**
-
-```
-Player (CharacterBody2D)
-├── Sprite2D
-├── CollisionShape2D
-├── AnimationPlayer
-├── HealthComponent (Node - custom script)
-├── InputComponent (Node - custom script)
-└── WeaponMount (Node2D)
-    └── Weapon (instanced scene)
-```
-
-**2. Scene Inheritance:**
-
-```
-BaseEnemy.tscn
-├── Inherits → FlyingEnemy.tscn (adds wings, aerial movement)
-└── Inherits → GroundEnemy.tscn (adds ground collision)
-```
-
-**3. Autoload Singletons:**
-
-```
-# In Project Settings > Autoload:
-GameManager → res://scripts/managers/game_manager.gd
-AudioManager → res://scripts/managers/audio_manager.gd
-SaveManager → res://scripts/managers/save_manager.gd
-```
-
----
-
-### Performance Optimization
-
-**Godot-specific considerations:**
-
-- **Static Typing**: Use type hints for GDScript performance (`var health: int = 100`)
-- **Object Pooling**: Implement manually or use addons
-- **CanvasItem batching**: Reduce draw calls with texture atlases
-- **Viewport rendering**: Offload effects to separate viewports
-- **GDScript vs C#**: C# faster for heavy computation, GDScript faster for simple logic
-
-**Target Performance:**
-
-- **PC**: 60 FPS minimum
-- **Mobile**: 60 FPS (high-end), 30 FPS (low-end)
-- **Web**: 30-60 FPS depending on complexity
-
-**Profiler:**
-
-- Use Godot's built-in profiler (Debug > Profiler)
-- Monitor FPS, draw calls, physics time
-
----
-
-### Testing Strategy
-
-**GUT (Godot Unit Test):**
-
-```gdscript
-# test_player.gd
-extends GutTest
-
-func test_player_takes_damage():
-    var player = Player.new()
-    add_child(player)
-    player.health = 100
-
-    player.take_damage(20)
-
-    assert_eq(player.health, 80, "Player health should decrease")
-```
-
-**GoDotTest for C#:**
-
-```csharp
-[Test]
-public void PlayerTakesDamage_DecreasesHealth()
-{
-    var player = new Player();
-    player.Health = 100;
-
-    player.TakeDamage(20);
-
-    Assert.That(player.Health, Is.EqualTo(80));
-}
-```
-
-**Recommended Coverage:**
-
-- 80% minimum test coverage (from expansion pack)
-- Test game systems, not rendering
-- Use GUT for GDScript, GoDotTest for C#
-
----
-
-### Source Tree Structure
-
-**Godot-specific folders:**
-
-```
-project/
-├── scenes/              # All .tscn scene files
-│   ├── main_menu.tscn
-│   ├── levels/
-│   │   ├── level_1.tscn
-│   │   └── level_2.tscn
-│   ├── player/
-│   │   └── player.tscn
-│   └── enemies/
-│       ├── base_enemy.tscn
-│       └── flying_enemy.tscn
-├── scripts/             # GDScript and C# files
-│   ├── player/
-│   │   ├── player.gd
-│   │   └── player_input.gd
-│   ├── enemies/
-│   ├── managers/
-│   │   ├── game_manager.gd  (Autoload)
-│   │   └── audio_manager.gd (Autoload)
-│   └── ui/
-├── resources/           # Custom Resource types
-│   ├── enemy_data.gd
-│   └── level_data.gd
-├── assets/
-│   ├── sprites/
-│   ├── textures/
-│   ├── audio/
-│   │   ├── music/
-│   │   └── sfx/
-│   ├── fonts/
-│   └── shaders/
-├── addons/              # Godot plugins
-└── project.godot        # Project settings
-```
-
----
-
-### Deployment and Build
-
-**Platform-specific:**
-
-- **PC**: Export presets for Windows, Linux, macOS
-- **Mobile**: Android (APK/AAB), iOS (Xcode project)
-- **Web**: HTML5 export (SharedArrayBuffer requirements)
-- **Console**: Partner programs for Switch, Xbox, PlayStation
-
-**Export templates:**
-
-- Download from Godot website for each platform
-- Configure export presets in Project > Export
-
-**Build automation:**
-
-- Use `godot --export` command-line for CI/CD
-- Example: `godot --export-release "Windows Desktop" output/game.exe`
-
----
-
-## Specialist Recommendations
-
-### Audio Designer
-
-**When needed:** Games with music, sound effects, ambience
-**Responsibilities:**
-
-- AudioStreamPlayer node architecture (2D vs 3D audio)
-- Audio bus setup in Godot's audio mixer
-- Music transitions with AudioStreamPlayer.finished signal
-- Sound effect implementation
-- Audio performance optimization
-
-### Performance Optimizer
-
-**When needed:** Mobile games, large-scale games, complex 3D
-**Responsibilities:**
-
-- Godot profiler analysis
-- Static typing optimization
-- Draw call reduction
-- Physics optimization (collision layers/masks)
-- Memory management
-- C# performance optimization for heavy systems
-
-### Multiplayer Architect
-
-**When needed:** Multiplayer/co-op games
-**Responsibilities:**
-
-- High-level multiplayer API or ENet
-- RPC architecture (remote procedure calls)
-- State synchronization patterns
-- Client-server vs peer-to-peer
-- Anti-cheat considerations
-- Latency compensation
-
-### Monetization Specialist
-
-**When needed:** F2P, mobile games with IAP
-**Responsibilities:**
-
-- In-app purchase integration (via plugins)
-- Ad network integration
-- Analytics integration
-- Economy design
-- Godot-specific monetization patterns
-
----
-
-## Common Pitfalls
-
-1. **Over-using get_node()** - Cache node references in `@onready` variables
-2. **Not using type hints** - Static typing improves GDScript performance
-3. **Deep node hierarchies** - Keep scene trees shallow for performance
-4. **Ignoring signals** - Use signals instead of polling or direct coupling
-5. **Not leveraging autoload** - Use autoload singletons for global state
-6. **Poor scene organization** - Plan scene structure before building
-7. **Forgetting to queue_free()** - Memory leaks from unreleased nodes
-
----
-
-## Godot vs Unity Differences
-
-### Architecture Differences:
-
-| Unity                  | Godot          | Notes                                   |
-| ---------------------- | -------------- | --------------------------------------- |
-| GameObject + Component | Node hierarchy | Godot nodes have built-in functionality |
-| MonoBehaviour          | Node + Script  | Attach scripts to nodes                 |
-| ScriptableObject       | Resource       | Custom data containers                  |
-| UnityEvent             | Signal         | Godot signals are built-in              |
-| Prefab                 | Scene (.tscn)  | Scenes are reusable like prefabs        |
-| Singleton pattern      | Autoload       | Built-in singleton system               |
-
-### Language Differences:
-
-| Unity C#                              | GDScript                                    | Notes                       |
-| ------------------------------------- | ------------------------------------------- | --------------------------- |
-| `public class Player : MonoBehaviour` | `class_name Player extends CharacterBody2D` | GDScript more concise       |
-| `void Start()`                        | `func _ready():`                            | Initialization              |
-| `void Update()`                       | `func _process(delta):`                     | Per-frame update            |
-| `void FixedUpdate()`                  | `func _physics_process(delta):`             | Physics update              |
-| `[SerializeField]`                    | `@export`                                   | Inspector-visible variables |
-| `GetComponent<T>()`                   | `get_node("NodeName")` or `$NodeName`       | Node access                 |
-
----
-
-## Key Architecture Decision Records
-
-### ADR Template for Godot Projects
-
-**ADR-XXX: [Title]**
-
-**Context:**
-What Godot-specific issue are we solving?
-
-**Options:**
-
-1. GDScript solution
-2. C# solution
-3. GDScript + C# hybrid
-4. Third-party addon (Godot Asset Library)
-
-**Decision:**
-We chose [Option X]
-
-**Godot-specific Rationale:**
-
-- GDScript vs C# performance tradeoffs
-- Engine integration (signals, nodes, resources)
-- Community support and addons
-- Team expertise
-- Platform compatibility
-
-**Consequences:**
-
-- Impact on performance
-- Learning curve
-- Maintenance considerations
-- Platform limitations (Web export with C#)
-
----
-
-_This guide is specific to Godot Engine. For other engines, see:_
-
-- game-engine-unity-guide.md
-- game-engine-unreal-guide.md
-- game-engine-web-guide.md

src/modules/bmm/workflows/3-solutioning/templates/game-engine-unity-guide.md

@@ -1,333 +0,0 @@
-# Unity Game Engine Architecture Guide
-
-This guide provides Unity-specific guidance for solution architecture generation.
-
----
-
-## Unity-Specific Questions
-
-### 1. Unity Version and Render Pipeline
-
-**Ask:**
-
-- Which Unity version are you targeting? (2021 LTS, 2022 LTS, 2023+, 6000+)
-- Which render pipeline? (Built-in, URP Universal Render Pipeline, HDRP High Definition)
-- Target platform(s)? (PC, Mobile, Console, WebGL)
-
-**Guidance:**
-
-- **2021/2022 LTS**: Stable, well-supported, good for production
-- **URP**: Best for mobile and cross-platform (lower overhead)
-- **HDRP**: High-fidelity graphics for PC/console only
-- **Built-in**: Legacy, avoid for new projects
-
-**Record ADR:** Unity version and render pipeline choice
-
----
-
-### 2. Architecture Pattern
-
-**Ask:**
-
-- Component-based MonoBehaviour architecture? (Unity standard)
-- ECS (Entity Component System) for performance-critical systems?
-- Hybrid (MonoBehaviour + ECS where needed)?
-
-**Guidance:**
-
-- **MonoBehaviour**: Standard, easy to use, good for most games
-- **ECS/DOTS**: High performance, steep learning curve, use for massive scale (1000s of entities)
-- **Hybrid**: MonoBehaviour for gameplay, ECS for particles/crowds
-
-**Record ADR:** Architecture pattern choice and justification
-
----
-
-### 3. Data Management Strategy
-
-**Ask:**
-
-- ScriptableObjects for data-driven design?
-- JSON/XML config files?
-- Addressables for asset management?
-
-**Guidance:**
-
-- **ScriptableObjects**: Unity-native, inspector-friendly, good for game data (enemies, items, levels)
-- **Addressables**: Essential for large games, enables asset streaming and DLC
-- Avoid Resources folder (deprecated pattern)
-
-**Record ADR:** Data management approach
-
----
-
-## Unity-Specific Architecture Sections
-
-### Game Systems Architecture
-
-**Components to define:**
-
-- **Player Controller**: Character movement, input handling
-- **Camera System**: Follow camera, cinemachine usage
-- **Game State Manager**: Scene transitions, game modes, pause/resume
-- **Save System**: PlayerPrefs vs JSON vs Cloud Save
-- **Input System**: New Input System vs Legacy
-
-**Unity-specific patterns:**
-
-```csharp
-// Singleton GameManager pattern
-public class GameManager : MonoBehaviour
-{
-    public static GameManager Instance { get; private set; }
-
-    void Awake()
-    {
-        if (Instance == null) Instance = this;
-        else Destroy(gameObject);
-        DontDestroyOnLoad(gameObject);
-    }
-}
-
-// ScriptableObject data pattern
-[CreateAssetMenu(fileName = "EnemyData", menuName = "Game/Enemy")]
-public class EnemyData : ScriptableObject
-{
-    public string enemyName;
-    public int health;
-    public float speed;
-    public GameObject prefab;
-}
-```
-
----
-
-### Unity Events and Communication
-
-**Ask:**
-
-- UnityEvents for inspector-wired connections?
-- C# Events for code-based pub/sub?
-- Message system for decoupled communication?
-
-**Guidance:**
-
-- **UnityEvents**: Good for designer-configurable connections
-- **C# Events**: Better performance, type-safe
-- **Avoid** FindObjectOfType and GetComponent in Update()
-
-**Pattern:**
-
-```csharp
-// Event-driven damage system
-public class HealthSystem : MonoBehaviour
-{
-    public UnityEvent<int> OnDamaged;
-    public UnityEvent OnDeath;
-
-    public void TakeDamage(int amount)
-    {
-        health -= amount;
-        OnDamaged?.Invoke(amount);
-        if (health <= 0) OnDeath?.Invoke();
-    }
-}
-```
-
----
-
-### Performance Optimization
-
-**Unity-specific considerations:**
-
-- **Object Pooling**: Essential for bullets, particles, enemies
-- **Sprite Batching**: Use sprite atlases, minimize draw calls
-- **Physics Optimization**: Layer-based collision matrix
-- **Profiler Usage**: CPU, GPU, Memory, Physics profilers
-- **IL2CPP vs Mono**: Build performance differences
-
-**Target Performance:**
-
-- Mobile: 60 FPS minimum (30 FPS for complex 3D)
-- PC: 60 FPS minimum
-- Monitor with Unity Profiler
-
----
-
-### Testing Strategy
-
-**Unity Test Framework:**
-
-- **Edit Mode Tests**: Test pure C# logic, no Unity lifecycle
-- **Play Mode Tests**: Test MonoBehaviour components in play mode
-- Use `[UnityTest]` attribute for coroutine tests
-- Mock Unity APIs with interfaces
-
-**Example:**
-
-```csharp
-[UnityTest]
-public IEnumerator Player_TakesDamage_DecreasesHealth()
-{
-    var player = new GameObject().AddComponent<Player>();
-    player.health = 100;
-
-    player.TakeDamage(20);
-
-    yield return null; // Wait one frame
-
-    Assert.AreEqual(80, player.health);
-}
-```
-
----
-
-### Source Tree Structure
-
-**Unity-specific folders:**
-
-```
-Assets/
-├── Scenes/              # All .unity scene files
-│   ├── MainMenu.unity
-│   ├── Level1.unity
-│   └── Level2.unity
-├── Scripts/             # All C# code
-│   ├── Player/
-│   ├── Enemies/
-│   ├── Managers/
-│   ├── UI/
-│   └── Utilities/
-├── Prefabs/             # Reusable game objects
-├── ScriptableObjects/   # Game data assets
-│   ├── Enemies/
-│   ├── Items/
-│   └── Levels/
-├── Materials/
-├── Textures/
-├── Audio/
-│   ├── Music/
-│   └── SFX/
-├── Fonts/
-├── Animations/
-├── Resources/           # Avoid - use Addressables instead
-└── Plugins/             # Third-party SDKs
-```
-
----
-
-### Deployment and Build
-
-**Platform-specific:**
-
-- **PC**: Standalone builds (Windows/Mac/Linux)
-- **Mobile**: IL2CPP mandatory for iOS, recommended for Android
-- **WebGL**: Compression, memory limitations
-- **Console**: Platform-specific SDKs and certification
-
-**Build pipeline:**
-
-- Unity Cloud Build OR
-- CI/CD with command-line builds: `Unity -batchmode -buildTarget ...`
-
----
-
-## Specialist Recommendations
-
-### Audio Designer
-
-**When needed:** Games with music, sound effects, ambience
-**Responsibilities:**
-
-- Audio system architecture (2D vs 3D audio)
-- Audio mixer setup
-- Music transitions and adaptive audio
-- Sound effect implementation
-- Audio performance optimization
-
-### Performance Optimizer
-
-**When needed:** Mobile games, large-scale games, VR
-**Responsibilities:**
-
-- Profiling and optimization
-- Memory management
-- Draw call reduction
-- Physics optimization
-- Asset optimization (textures, meshes, audio)
-
-### Multiplayer Architect
-
-**When needed:** Multiplayer/co-op games
-**Responsibilities:**
-
-- Netcode architecture (Netcode for GameObjects, Mirror, Photon)
-- Client-server vs peer-to-peer
-- State synchronization
-- Anti-cheat considerations
-- Latency compensation
-
-### Monetization Specialist
-
-**When needed:** F2P, mobile games with IAP
-**Responsibilities:**
-
-- Unity IAP integration
-- Ad network integration (AdMob, Unity Ads)
-- Analytics integration
-- Economy design (virtual currency, shop)
-
----
-
-## Common Pitfalls
-
-1. **Over-using GetComponent** - Cache references in Awake/Start
-2. **Empty Update methods** - Remove them, they have overhead
-3. **String comparisons for tags** - Use CompareTag() instead
-4. **Resources folder abuse** - Migrate to Addressables
-5. **Not using object pooling** - Instantiate/Destroy is expensive
-6. **Ignoring the Profiler** - Profile early, profile often
-7. **Not testing on target hardware** - Mobile performance differs vastly
-
----
-
-## Key Architecture Decision Records
-
-### ADR Template for Unity Projects
-
-**ADR-XXX: [Title]**
-
-**Context:**
-What Unity-specific issue are we solving?
-
-**Options:**
-
-1. Unity Built-in Solution (e.g., Built-in Input System)
-2. Unity Package (e.g., New Input System)
-3. Third-party Asset (e.g., Rewired)
-4. Custom Implementation
-
-**Decision:**
-We chose [Option X]
-
-**Unity-specific Rationale:**
-
-- Version compatibility
-- Performance characteristics
-- Community support
-- Asset Store availability
-- License considerations
-
-**Consequences:**
-
-- Impact on build size
-- Platform compatibility
-- Learning curve for team
-
----
-
-_This guide is specific to Unity Engine. For other engines, see:_
-
-- game-engine-godot-guide.md
-- game-engine-unreal-guide.md
-- game-engine-web-guide.md

src/modules/bmm/workflows/3-solutioning/templates/game-engine-web-guide.md

@@ -1,528 +0,0 @@
-# Web Game Engine Architecture Guide
-
-This guide provides web game engine-specific guidance (Phaser, PixiJS, Three.js, Babylon.js) for solution architecture generation.
-
----
-
-## Web Game-Specific Questions
-
-### 1. Engine and Technology Selection
-
-**Ask:**
-
-- Which engine? (Phaser 3, PixiJS, Three.js, Babylon.js, custom Canvas/WebGL)
-- TypeScript or JavaScript?
-- Build tool? (Vite, Webpack, Rollup, Parcel)
-- Target platform(s)? (Desktop web, mobile web, PWA, Cordova/Capacitor wrapper)
-
-**Guidance:**
-
-- **Phaser 3**: Full-featured 2D game framework, great for beginners
-- **PixiJS**: 2D rendering library, more low-level than Phaser
-- **Three.js**: 3D graphics library, mature ecosystem
-- **Babylon.js**: Complete 3D game engine, WebXR support
-- **TypeScript**: Recommended for all web games (type safety, better tooling)
-- **Vite**: Modern, fast, HMR - best for development
-
-**Record ADR:** Engine selection and build tooling
-
----
-
-### 2. Architecture Pattern
-
-**Ask:**
-
-- Scene-based architecture? (Phaser scenes, custom scene manager)
-- ECS (Entity Component System)? (Libraries: bitECS, ecsy)
-- State management? (Redux, Zustand, custom FSM)
-
-**Guidance:**
-
-- **Scene-based**: Natural for Phaser, good for level-based games
-- **ECS**: Better performance for large entity counts (100s+)
-- **FSM**: Good for simple state transitions (menu → game → gameover)
-
-**Phaser Pattern:**
-
-```typescript
-// MainMenuScene.ts
-export class MainMenuScene extends Phaser.Scene {
-  constructor() {
-    super({ key: 'MainMenu' });
-  }
-
-  create() {
-    this.add.text(400, 300, 'Main Menu', { fontSize: '32px' });
-
-    const startButton = this.add
-      .text(400, 400, 'Start Game', { fontSize: '24px' })
-      .setInteractive()
-      .on('pointerdown', () => {
-        this.scene.start('GameScene');
-      });
-  }
-}
-```
-
-**Record ADR:** Architecture pattern and scene management
-
----
-
-### 3. Asset Management
-
-**Ask:**
-
-- Asset loading strategy? (Preload all, lazy load, progressive)
-- Texture atlas usage? (TexturePacker, built-in tools)
-- Audio format strategy? (MP3, OGG, WebM)
-
-**Guidance:**
-
-- **Preload**: Load all assets at start (simple, small games)
-- **Lazy load**: Load per-level (better for larger games)
-- **Texture atlases**: Essential for performance (reduce draw calls)
-- **Audio**: MP3 for compatibility, OGG for smaller size, use both
-
-**Phaser loading:**
-
-```typescript
-class PreloadScene extends Phaser.Scene {
-  preload() {
-    // Show progress bar
-    this.load.on('progress', (value: number) => {
-      console.log('Loading: ' + Math.round(value * 100) + '%');
-    });
-
-    // Load assets
-    this.load.atlas('sprites', 'assets/sprites.png', 'assets/sprites.json');
-    this.load.audio('music', ['assets/music.mp3', 'assets/music.ogg']);
-    this.load.audio('jump', ['assets/sfx/jump.mp3', 'assets/sfx/jump.ogg']);
-  }
-
-  create() {
-    this.scene.start('MainMenu');
-  }
-}
-```
-
-**Record ADR:** Asset loading and management strategy
-
----
-
-## Web Game-Specific Architecture Sections
-
-### Performance Optimization
-
-**Web-specific considerations:**
-
-- **Object Pooling**: Mandatory for bullets, particles, enemies (avoid GC pauses)
-- **Sprite Batching**: Use texture atlases, minimize state changes
-- **Canvas vs WebGL**: WebGL for better performance (most games)
-- **Draw Call Reduction**: Batch similar sprites, use sprite sheets
-- **Memory Management**: Watch heap size, profile with Chrome DevTools
-
-**Object Pooling Pattern:**
-
-```typescript
-class BulletPool {
-  private pool: Bullet[] = [];
-  private scene: Phaser.Scene;
-
-  constructor(scene: Phaser.Scene, size: number) {
-    this.scene = scene;
-    for (let i = 0; i < size; i++) {
-      const bullet = new Bullet(scene);
-      bullet.setActive(false).setVisible(false);
-      this.pool.push(bullet);
-    }
-  }
-
-  spawn(x: number, y: number, velocityX: number, velocityY: number): Bullet | null {
-    const bullet = this.pool.find((b) => !b.active);
-    if (bullet) {
-      bullet.spawn(x, y, velocityX, velocityY);
-    }
-    return bullet || null;
-  }
-}
-```
-
-**Target Performance:**
-
-- **Desktop**: 60 FPS minimum
-- **Mobile**: 60 FPS (high-end), 30 FPS (low-end)
-- **Profile with**: Chrome DevTools Performance tab, Phaser Debug plugin
-
----
-
-### Input Handling
-
-**Multi-input support:**
-
-```typescript
-class GameScene extends Phaser.Scene {
-  private cursors?: Phaser.Types.Input.Keyboard.CursorKeys;
-  private wasd?: { [key: string]: Phaser.Input.Keyboard.Key };
-
-  create() {
-    // Keyboard
-    this.cursors = this.input.keyboard?.createCursorKeys();
-    this.wasd = this.input.keyboard?.addKeys('W,S,A,D') as any;
-
-    // Mouse/Touch
-    this.input.on('pointerdown', (pointer: Phaser.Input.Pointer) => {
-      this.handleClick(pointer.x, pointer.y);
-    });
-
-    // Gamepad (optional)
-    this.input.gamepad?.on('down', (pad, button, index) => {
-      this.handleGamepadButton(button);
-    });
-  }
-
-  update() {
-    // Handle keyboard input
-    if (this.cursors?.left.isDown || this.wasd?.A.isDown) {
-      this.player.moveLeft();
-    }
-  }
-}
-```
-
----
-
-### State Persistence
-
-**LocalStorage pattern:**
-
-```typescript
-interface GameSaveData {
-  level: number;
-  score: number;
-  playerStats: {
-    health: number;
-    lives: number;
-  };
-}
-
-class SaveManager {
-  private static SAVE_KEY = 'game_save_data';
-
-  static save(data: GameSaveData): void {
-    localStorage.setItem(this.SAVE_KEY, JSON.stringify(data));
-  }
-
-  static load(): GameSaveData | null {
-    const data = localStorage.getItem(this.SAVE_KEY);
-    return data ? JSON.parse(data) : null;
-  }
-
-  static clear(): void {
-    localStorage.removeItem(this.SAVE_KEY);
-  }
-}
-```
-
----
-
-### Source Tree Structure
-
-**Phaser + TypeScript + Vite:**
-
-```
-project/
-├── public/              # Static assets
-│   ├── assets/
-│   │   ├── sprites/
-│   │   ├── audio/
-│   │   │   ├── music/
-│   │   │   └── sfx/
-│   │   └── fonts/
-│   └── index.html
-├── src/
-│   ├── main.ts         # Game initialization
-│   ├── config.ts       # Phaser config
-│   ├── scenes/         # Game scenes
-│   │   ├── PreloadScene.ts
-│   │   ├── MainMenuScene.ts
-│   │   ├── GameScene.ts
-│   │   └── GameOverScene.ts
-│   ├── entities/       # Game objects
-│   │   ├── Player.ts
-│   │   ├── Enemy.ts
-│   │   └── Bullet.ts
-│   ├── systems/        # Game systems
-│   │   ├── InputManager.ts
-│   │   ├── AudioManager.ts
-│   │   └── SaveManager.ts
-│   ├── utils/          # Utilities
-│   │   ├── ObjectPool.ts
-│   │   └── Constants.ts
-│   └── types/          # TypeScript types
-│       └── index.d.ts
-├── tests/              # Unit tests
-├── package.json
-├── tsconfig.json
-├── vite.config.ts
-└── README.md
-```
-
----
-
-### Testing Strategy
-
-**Jest + TypeScript:**
-
-```typescript
-// Player.test.ts
-import { Player } from '../entities/Player';
-
-describe('Player', () => {
-  let player: Player;
-
-  beforeEach(() => {
-    // Mock Phaser scene
-    const mockScene = {
-      add: { sprite: jest.fn() },
-      physics: { add: { sprite: jest.fn() } },
-    } as any;
-
-    player = new Player(mockScene, 0, 0);
-  });
-
-  test('takes damage correctly', () => {
-    player.health = 100;
-    player.takeDamage(20);
-    expect(player.health).toBe(80);
-  });
-
-  test('dies when health reaches zero', () => {
-    player.health = 10;
-    player.takeDamage(20);
-    expect(player.alive).toBe(false);
-  });
-});
-```
-
-**E2E Testing:**
-
-- Playwright for browser automation
-- Cypress for interactive testing
-- Test game states, not individual frames
-
----
-
-### Deployment and Build
-
-**Build for production:**
-
-```json
-// package.json scripts
-{
-  "scripts": {
-    "dev": "vite",
-    "build": "tsc andand vite build",
-    "preview": "vite preview",
-    "test": "jest"
-  }
-}
-```
-
-**Deployment targets:**
-
-- **Static hosting**: Netlify, Vercel, GitHub Pages, AWS S3
-- **CDN**: Cloudflare, Fastly for global distribution
-- **PWA**: Service worker for offline play
-- **Mobile wrapper**: Cordova or Capacitor for app stores
-
-**Optimization:**
-
-```typescript
-// vite.config.ts
-export default defineConfig({
-  build: {
-    rollupOptions: {
-      output: {
-        manualChunks: {
-          phaser: ['phaser'], // Separate Phaser bundle
-        },
-      },
-    },
-    minify: 'terser',
-    terserOptions: {
-      compress: {
-        drop_console: true, // Remove console.log in prod
-      },
-    },
-  },
-});
-```
-
----
-
-## Specialist Recommendations
-
-### Audio Designer
-
-**When needed:** Games with music, sound effects, ambience
-**Responsibilities:**
-
-- Web Audio API architecture
-- Audio sprite creation (combine sounds into one file)
-- Music loop management
-- Sound effect implementation
-- Audio performance on web (decode strategy)
-
-### Performance Optimizer
-
-**When needed:** Mobile web games, complex games
-**Responsibilities:**
-
-- Chrome DevTools profiling
-- Object pooling implementation
-- Draw call optimization
-- Memory management
-- Bundle size optimization
-- Network performance (asset loading)
-
-### Monetization Specialist
-
-**When needed:** F2P web games
-**Responsibilities:**
-
-- Ad network integration (Google AdSense, AdMob for web)
-- In-game purchases (Stripe, PayPal)
-- Analytics (Google Analytics, custom events)
-- A/B testing frameworks
-- Economy design
-
-### Platform Specialist
-
-**When needed:** Mobile wrapper apps (Cordova/Capacitor)
-**Responsibilities:**
-
-- Native plugin integration
-- Platform-specific performance tuning
-- App store submission
-- Device compatibility testing
-- Push notification setup
-
----
-
-## Common Pitfalls
-
-1. **Not using object pooling** - Frequent instantiation causes GC pauses
-2. **Too many draw calls** - Use texture atlases and sprite batching
-3. **Loading all assets at once** - Causes long initial load times
-4. **Not testing on mobile** - Performance vastly different on phones
-5. **Ignoring bundle size** - Large bundles = slow load times
-6. **Not handling window resize** - Web games run in resizable windows
-7. **Forgetting audio autoplay restrictions** - Browsers block auto-play without user interaction
-
----
-
-## Engine-Specific Patterns
-
-### Phaser 3
-
-```typescript
-const config: Phaser.Types.Core.GameConfig = {
-  type: Phaser.AUTO, // WebGL with Canvas fallback
-  width: 800,
-  height: 600,
-  physics: {
-    default: 'arcade',
-    arcade: { gravity: { y: 300 }, debug: false },
-  },
-  scene: [PreloadScene, MainMenuScene, GameScene, GameOverScene],
-};
-
-const game = new Phaser.Game(config);
-```
-
-### PixiJS
-
-```typescript
-const app = new PIXI.Application({
-  width: 800,
-  height: 600,
-  backgroundColor: 0x1099bb,
-});
-
-document.body.appendChild(app.view);
-
-const sprite = PIXI.Sprite.from('assets/player.png');
-app.stage.addChild(sprite);
-
-app.ticker.add((delta) => {
-  sprite.rotation += 0.01 * delta;
-});
-```
-
-### Three.js
-
-```typescript
-const scene = new THREE.Scene();
-const camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000);
-const renderer = new THREE.WebGLRenderer();
-
-renderer.setSize(window.innerWidth, window.innerHeight);
-document.body.appendChild(renderer.domElement);
-
-const geometry = new THREE.BoxGeometry();
-const material = new THREE.MeshBasicMaterial({ color: 0x00ff00 });
-const cube = new THREE.Mesh(geometry, material);
-scene.add(cube);
-
-function animate() {
-  requestAnimationFrame(animate);
-  cube.rotation.x += 0.01;
-  renderer.render(scene, camera);
-}
-animate();
-```
-
----
-
-## Key Architecture Decision Records
-
-### ADR Template for Web Games
-
-**ADR-XXX: [Title]**
-
-**Context:**
-What web game-specific issue are we solving?
-
-**Options:**
-
-1. Phaser 3 (full framework)
-2. PixiJS (rendering library)
-3. Three.js/Babylon.js (3D)
-4. Custom Canvas/WebGL
-
-**Decision:**
-We chose [Option X]
-
-**Web-specific Rationale:**
-
-- Engine features vs bundle size
-- Community and plugin ecosystem
-- TypeScript support
-- Performance on target devices (mobile web)
-- Browser compatibility
-- Development velocity
-
-**Consequences:**
-
-- Impact on bundle size (Phaser ~1.2MB gzipped)
-- Learning curve
-- Platform limitations
-- Plugin availability
-
----
-
-_This guide is specific to web game engines. For native engines, see:_
-
-- game-engine-unity-guide.md
-- game-engine-godot-guide.md
-- game-engine-unreal-guide.md

src/modules/bmm/workflows/3-solutioning/templates/registry.csv

@@ -1,172 +0,0 @@
-id,name,project_types,languages,architecture_style,repo_strategy,tags,template_path,reference_architecture_path,guide_path
-web-nextjs-ssr-monorepo,Next.js SSR Monolith,web,TypeScript,monolith,monorepo,"ssr,react,fullstack,vercel",web-fullstack-architecture.md,,
-web-nuxt-ssr-monorepo,Nuxt SSR Monolith,web,TypeScript,monolith,monorepo,"ssr,vue,fullstack",web-fullstack-architecture.md,,
-web-sveltekit-ssr-monorepo,SvelteKit SSR Monolith,web,TypeScript,monolith,monorepo,"ssr,svelte,fullstack",web-fullstack-architecture.md,,
-web-remix-ssr-monorepo,Remix SSR Monolith,web,TypeScript,monolith,monorepo,"ssr,react,fullstack",web-fullstack-architecture.md,,
-web-rails-monolith,Rails Monolith,web,Ruby,monolith,monorepo,"ssr,mvc,fullstack",web-fullstack-architecture.md,,
-web-django-templates,Django with Templates,web,Python,monolith,monorepo,"ssr,mvc,fullstack",web-fullstack-architecture.md,,
-web-laravel-monolith,Laravel Monolith,web,PHP,monolith,monorepo,"ssr,mvc,fullstack",web-fullstack-architecture.md,,
-web-aspnet-mvc,ASP.NET MVC,web,C#,monolith,monorepo,"ssr,mvc,fullstack,dotnet",web-fullstack-architecture.md,,
-web-express-api,Express REST API,web,TypeScript,monolith,monorepo,"api,rest,backend",web-api-architecture.md,,
-web-fastapi,FastAPI,web,Python,monolith,monorepo,"api,rest,backend,async",web-api-architecture.md,,
-web-flask-api,Flask REST API,web,Python,monolith,monorepo,"api,rest,backend",web-api-architecture.md,,
-web-django-rest,Django REST Framework,web,Python,monolith,monorepo,"api,rest,backend",web-api-architecture.md,,
-web-rails-api,Rails API Mode,web,Ruby,monolith,monorepo,"api,rest,backend",web-api-architecture.md,,
-web-gin-api,Gin API (Go),web,Go,monolith,monorepo,"api,rest,backend",web-api-architecture.md,,
-web-spring-boot-api,Spring Boot API,web,Java,monolith,monorepo,"api,rest,backend",web-api-architecture.md,,
-web-aspnet-api,ASP.NET Web API,web,C#,monolith,monorepo,"api,rest,backend,dotnet",web-api-architecture.md,,
-web-react-django-separate,React + Django (Separate),web,"TypeScript,Python",spa-with-api,monorepo,"spa,react,django",web-fullstack-architecture.md,,
-web-react-express-separate,React + Express (Separate),web,TypeScript,spa-with-api,monorepo,"spa,react,node",web-fullstack-architecture.md,,
-web-vue-rails-separate,Vue + Rails (Separate),web,"TypeScript,Ruby",spa-with-api,monorepo,"spa,vue,rails",web-fullstack-architecture.md,,
-web-vue-laravel-separate,Vue + Laravel (Separate),web,"TypeScript,PHP",spa-with-api,monorepo,"spa,vue,laravel",web-fullstack-architecture.md,,
-web-angular-spring-separate,Angular + Spring Boot,web,"TypeScript,Java",spa-with-api,monorepo,"spa,angular,spring",web-fullstack-architecture.md,,
-web-angular-dotnet-separate,Angular + .NET API,web,"TypeScript,C#",spa-with-api,monorepo,"spa,angular,dotnet",web-fullstack-architecture.md,,
-web-svelte-go-separate,Svelte + Go API,web,"TypeScript,Go",spa-with-api,monorepo,"spa,svelte,go",web-fullstack-architecture.md,,
-web-nextjs-microservices-mono,Next.js Microservices (Monorepo),web,TypeScript,microservices,monorepo,"microservices,react,nx,turborepo",web-fullstack-architecture.md,,
-web-node-microservices-mono,Node.js Microservices (Monorepo),web,TypeScript,microservices,monorepo,"microservices,node,nx",web-fullstack-architecture.md,,
-web-go-microservices-mono,Go Microservices (Monorepo),web,Go,microservices,monorepo,"microservices,go,grpc",web-fullstack-architecture.md,,
-web-python-microservices-mono,Python Microservices (Monorepo),web,Python,microservices,monorepo,"microservices,python,fastapi",web-fullstack-architecture.md,,
-web-nextjs-microservices-poly,Next.js Microservices (Polyrepo),web,TypeScript,microservices,polyrepo,"microservices,react,kubernetes",web-fullstack-architecture.md,,
-web-node-microservices-poly,Node.js Microservices (Polyrepo),web,TypeScript,microservices,polyrepo,"microservices,node,kubernetes",web-fullstack-architecture.md,,
-web-go-microservices-poly,Go Microservices (Polyrepo),web,Go,microservices,polyrepo,"microservices,go,kubernetes,grpc",web-fullstack-architecture.md,,
-web-java-microservices-poly,Java Microservices (Polyrepo),web,Java,microservices,polyrepo,"microservices,spring,kubernetes",web-fullstack-architecture.md,,
-web-nextjs-vercel-serverless,Next.js Serverless (Vercel),web,TypeScript,serverless,monorepo,"serverless,vercel,edge",web-fullstack-architecture.md,,
-web-lambda-node-serverless,AWS Lambda (Node.js),web,TypeScript,serverless,monorepo,"serverless,aws,lambda",web-api-architecture.md,,
-web-lambda-python-serverless,AWS Lambda (Python),web,Python,serverless,monorepo,"serverless,aws,lambda",web-api-architecture.md,,
-web-lambda-go-serverless,AWS Lambda (Go),web,Go,serverless,monorepo,"serverless,aws,lambda",web-api-architecture.md,,
-web-cloudflare-workers,Cloudflare Workers,web,TypeScript,serverless,monorepo,"serverless,cloudflare,edge",web-api-architecture.md,,
-web-netlify-functions,Netlify Functions,web,TypeScript,serverless,monorepo,"serverless,netlify,edge",web-api-architecture.md,,
-web-astro-jamstack,Astro Static Site,web,TypeScript,jamstack,monorepo,"static,ssg,content",web-fullstack-architecture.md,,
-web-hugo-jamstack,Hugo Static Site,web,Go,jamstack,monorepo,"static,ssg,content",web-fullstack-architecture.md,,
-web-gatsby-jamstack,Gatsby Static Site,web,TypeScript,jamstack,monorepo,"static,ssg,react",web-fullstack-architecture.md,,
-web-eleventy-jamstack,Eleventy Static Site,web,JavaScript,jamstack,monorepo,"static,ssg,content",web-fullstack-architecture.md,,
-web-jekyll-jamstack,Jekyll Static Site,web,Ruby,jamstack,monorepo,"static,ssg,content",web-fullstack-architecture.md,,
-mobile-swift-native,iOS Native (Swift),mobile,Swift,native,monorepo,"ios,native,xcode,uikit",mobile-app-architecture.md,,
-mobile-swiftui-native,iOS Native (SwiftUI),mobile,Swift,native,monorepo,"ios,native,xcode,swiftui",mobile-app-architecture.md,,
-mobile-kotlin-native,Android Native (Kotlin),mobile,Kotlin,native,monorepo,"android,native,android-studio",mobile-app-architecture.md,,
-mobile-compose-native,Android Native (Compose),mobile,Kotlin,native,monorepo,"android,native,compose",mobile-app-architecture.md,,
-mobile-react-native,React Native,mobile,TypeScript,cross-platform,monorepo,"cross-platform,react,expo",mobile-app-architecture.md,,
-mobile-flutter,Flutter,mobile,Dart,cross-platform,monorepo,"cross-platform,flutter,material",mobile-app-architecture.md,,
-mobile-xamarin,Xamarin,mobile,C#,cross-platform,monorepo,"cross-platform,xamarin,dotnet",mobile-app-architecture.md,,
-mobile-ionic-hybrid,Ionic Hybrid,mobile,TypeScript,hybrid,monorepo,"hybrid,ionic,capacitor",mobile-app-architecture.md,,
-mobile-capacitor-hybrid,Capacitor Hybrid,mobile,TypeScript,hybrid,monorepo,"hybrid,capacitor,webview",mobile-app-architecture.md,,
-mobile-cordova-hybrid,Cordova Hybrid,mobile,JavaScript,hybrid,monorepo,"hybrid,cordova,webview",mobile-app-architecture.md,,
-mobile-pwa,Progressive Web App,mobile,TypeScript,pwa,monorepo,"pwa,service-worker,offline",mobile-app-architecture.md,,
-game-unity-3d,Unity 3D,game,C#,monolith,monorepo,"3d,unity,game-engine",game-engine-architecture.md,,game-engine-unity-guide.md
-game-unreal-3d,Unreal Engine 3D,game,"C++,Blueprint",monolith,monorepo,"3d,unreal,aaa",game-engine-architecture.md,,game-engine-unreal-guide.md
-game-godot-3d,Godot 3D,game,GDScript,monolith,monorepo,"3d,godot,open-source",game-engine-architecture.md,,game-engine-godot-guide.md
-game-custom-3d-cpp,Custom 3D Engine (C++),game,C++,monolith,monorepo,"3d,custom,opengl",game-engine-architecture.md,,game-engine-general-guide.md
-game-custom-3d-rust,Custom 3D Engine (Rust),game,Rust,monolith,monorepo,"3d,custom,vulkan",game-engine-architecture.md,,game-engine-general-guide.md
-game-unity-2d,Unity 2D,game,C#,monolith,monorepo,"2d,unity,game-engine",game-engine-architecture.md,,game-engine-unity-guide.md
-game-godot-2d,Godot 2D,game,GDScript,monolith,monorepo,"2d,godot,open-source",game-engine-architecture.md,,game-engine-godot-guide.md
-game-gamemaker,GameMaker,game,GML,monolith,monorepo,"2d,gamemaker,indie",game-engine-architecture.md,,game-engine-general-guide.md
-game-phaser,Phaser (Web),game,TypeScript,monolith,monorepo,"2d,phaser,html5",game-engine-architecture.md,,game-engine-web-guide.md
-game-pixijs,PixiJS (Web),game,TypeScript,monolith,monorepo,"2d,pixijs,canvas",game-engine-architecture.md,,game-engine-web-guide.md
-game-threejs,Three.js (Web),game,TypeScript,monolith,monorepo,"3d,threejs,webgl",game-engine-architecture.md,,game-engine-web-guide.md
-game-babylonjs,Babylon.js (Web),game,TypeScript,monolith,monorepo,"3d,babylonjs,webgl",game-engine-architecture.md,,game-engine-web-guide.md
-game-text-python,Text-Based (Python),game,Python,monolith,monorepo,"text,roguelike",game-engine-architecture.md,,game-engine-general-guide.md
-game-text-js,Text-Based (JavaScript),game,JavaScript,monolith,monorepo,"text,interactive-fiction",game-engine-architecture.md,,game-engine-general-guide.md
-game-text-cpp,Text-Based (C++),game,C++,monolith,monorepo,"text,roguelike,mud",game-engine-architecture.md,,game-engine-general-guide.md
-backend-express-rest,Express REST,backend,TypeScript,monolith,monorepo,"rest,express",backend-service-architecture.md,,
-backend-fastapi-rest,FastAPI REST,backend,Python,monolith,monorepo,"rest,fastapi,async",backend-service-architecture.md,,
-backend-django-rest-fw,Django REST Framework,backend,Python,monolith,monorepo,"rest,django",backend-service-architecture.md,,
-backend-flask-rest,Flask REST,backend,Python,monolith,monorepo,"rest,flask,lightweight",backend-service-architecture.md,,
-backend-spring-boot-rest,Spring Boot REST,backend,Java,monolith,monorepo,"rest,spring,enterprise",backend-service-architecture.md,,
-backend-gin-rest,Gin REST (Go),backend,Go,monolith,monorepo,"rest,gin,performance",backend-service-architecture.md,,
-backend-actix-rest,Actix Web (Rust),backend,Rust,monolith,monorepo,"rest,actix,performance",backend-service-architecture.md,,
-backend-rails-api,Rails API,backend,Ruby,monolith,monorepo,"rest,rails",backend-service-architecture.md,,
-backend-apollo-graphql,Apollo GraphQL,backend,TypeScript,monolith,monorepo,"graphql,apollo",backend-service-architecture.md,,
-backend-hasura-graphql,Hasura GraphQL,backend,any,monolith,monorepo,"graphql,hasura,postgres",backend-service-architecture.md,,
-backend-strawberry-graphql,Strawberry GraphQL (Python),backend,Python,monolith,monorepo,"graphql,strawberry,async",backend-service-architecture.md,,
-backend-graphql-go,gqlgen (Go),backend,Go,monolith,monorepo,"graphql,gqlgen,type-safe",backend-service-architecture.md,,
-backend-grpc-go,gRPC Service (Go),backend,Go,monolith,monorepo,"grpc,protobuf",backend-service-architecture.md,,
-backend-grpc-node,gRPC Service (Node.js),backend,TypeScript,monolith,monorepo,"grpc,protobuf",backend-service-architecture.md,,
-backend-grpc-rust,gRPC Service (Rust),backend,Rust,monolith,monorepo,"grpc,tonic",backend-service-architecture.md,,
-backend-grpc-java,gRPC Service (Java),backend,Java,monolith,monorepo,"grpc,protobuf",backend-service-architecture.md,,
-backend-socketio-realtime,Socket.IO Realtime,backend,TypeScript,monolith,monorepo,"realtime,socketio",backend-service-architecture.md,,
-backend-phoenix-realtime,Phoenix Channels,backend,Elixir,monolith,monorepo,"realtime,phoenix",backend-service-architecture.md,,
-backend-ably-realtime,Ably Realtime,backend,any,monolith,monorepo,"realtime,ably,managed",backend-service-architecture.md,,
-backend-pusher-realtime,Pusher Realtime,backend,any,monolith,monorepo,"realtime,pusher,managed",backend-service-architecture.md,,
-backend-kafka-event,Kafka Event-Driven,backend,"Java,Go,Python",event-driven,monorepo,"event-driven,kafka,streaming",backend-service-architecture.md,,
-backend-rabbitmq-event,RabbitMQ Event-Driven,backend,"Python,Go,Node",event-driven,monorepo,"event-driven,rabbitmq,amqp",backend-service-architecture.md,,
-backend-nats-event,NATS Event-Driven,backend,Go,event-driven,monorepo,"event-driven,nats,messaging",backend-service-architecture.md,,
-backend-sqs-event,AWS SQS Event-Driven,backend,"Python,Node",event-driven,monorepo,"event-driven,aws,sqs",backend-service-architecture.md,,
-backend-celery-batch,Celery Batch (Python),backend,Python,batch,monorepo,"batch,celery,redis,async",backend-service-architecture.md,,
-backend-airflow-batch,Airflow Pipelines,backend,Python,batch,monorepo,"batch,airflow,orchestration,dags",backend-service-architecture.md,,
-backend-prefect-batch,Prefect Pipelines,backend,Python,batch,monorepo,"batch,prefect,orchestration",backend-service-architecture.md,,
-backend-temporal-batch,Temporal Workflows,backend,"Go,TypeScript",batch,monorepo,"batch,temporal,workflows",backend-service-architecture.md,,
-embedded-freertos-esp32,FreeRTOS ESP32,embedded,C,rtos,monorepo,"iot,freertos,wifi",embedded-firmware-architecture.md,,
-embedded-freertos-stm32,FreeRTOS STM32,embedded,C,rtos,monorepo,"stm32,freertos,arm,cortex",embedded-firmware-architecture.md,,
-embedded-zephyr,Zephyr RTOS,embedded,C,rtos,monorepo,"zephyr,iot,bluetooth",embedded-firmware-architecture.md,,
-embedded-nuttx,NuttX RTOS,embedded,C,rtos,monorepo,"nuttx,posix",embedded-firmware-architecture.md,,
-embedded-arduino-bare,Arduino Bare Metal,embedded,"C,C++",bare-metal,monorepo,"arduino,bare-metal,avr",embedded-firmware-architecture.md,,
-embedded-stm32-bare,STM32 Bare Metal,embedded,C,bare-metal,monorepo,"stm32,bare-metal,arm",embedded-firmware-architecture.md,,
-embedded-pic-bare,PIC Microcontroller,embedded,C,bare-metal,monorepo,"pic,microchip",embedded-firmware-architecture.md,,
-embedded-avr-bare,AVR Bare Metal,embedded,C,bare-metal,monorepo,"avr,atmega",embedded-firmware-architecture.md,,
-embedded-raspberrypi,Raspberry Pi (Linux),embedded,Python,linux,monorepo,"raspberry-pi,gpio,python",embedded-firmware-architecture.md,,
-embedded-beaglebone,BeagleBone (Linux),embedded,Python,linux,monorepo,"beaglebone,gpio",embedded-firmware-architecture.md,,
-embedded-jetson,NVIDIA Jetson,embedded,Python,linux,monorepo,"jetson,ai,gpu",embedded-firmware-architecture.md,,
-embedded-esp32-iot,ESP32 IoT Cloud,embedded,C,iot-cloud,monorepo,"esp32,mqtt,aws-iot",embedded-firmware-architecture.md,,
-embedded-arduino-iot,Arduino IoT Cloud,embedded,"C,C++",iot-cloud,monorepo,"arduino,iot,mqtt,cloud",embedded-firmware-architecture.md,,
-embedded-particle,Particle IoT,embedded,"C,C++",iot-cloud,monorepo,"particle,iot,cellular,cloud",embedded-firmware-architecture.md,,
-library-npm-ts,NPM Library (TypeScript),library,TypeScript,library,monorepo,"npm,package,tsup",library-package-architecture.md,,
-library-npm-js,NPM Library (JavaScript),library,JavaScript,library,monorepo,"npm,package,rollup",library-package-architecture.md,,
-library-pypi,PyPI Package,library,Python,library,monorepo,"pypi,wheel,setuptools",library-package-architecture.md,,
-library-cargo,Cargo Crate (Rust),library,Rust,library,monorepo,"cargo,crate,docs-rs",library-package-architecture.md,,
-library-go-modules,Go Module,library,Go,library,monorepo,"go,pkg-go-dev",library-package-architecture.md,,
-library-maven-java,Maven Library (Java),library,Java,library,monorepo,"maven,jar,central",library-package-architecture.md,,
-library-nuget-csharp,NuGet Package (C#),library,C#,library,monorepo,"nuget,dotnet,package",library-package-architecture.md,,
-library-cpp-cmake,C++ Library (CMake),library,C++,library,monorepo,"cpp,conan,vcpkg",library-package-architecture.md,,
-library-c-shared,C Shared Library,library,C,library,monorepo,"c,header-only",library-package-architecture.md,,
-cli-node-simple,CLI Tool (Node.js),cli,TypeScript,cli,monorepo,"cli,commander,yargs",cli-tool-architecture.md,,
-cli-python-simple,CLI Tool (Python),cli,Python,cli,monorepo,"cli,click,argparse",cli-tool-architecture.md,,
-cli-go-simple,CLI Tool (Go),cli,Go,cli,monorepo,"cli,cobra,single-binary",cli-tool-architecture.md,,
-cli-rust-simple,CLI Tool (Rust),cli,Rust,cli,monorepo,"cli,clap,single-binary",cli-tool-architecture.md,,
-cli-node-interactive,Interactive CLI (Node.js),cli,TypeScript,cli-interactive,monorepo,"cli,ink,blessed",cli-tool-architecture.md,,
-cli-python-interactive,Interactive CLI (Python),cli,Python,cli-interactive,monorepo,"cli,rich,textual,prompt-toolkit",cli-tool-architecture.md,,
-cli-rust-interactive,Interactive TUI (Rust),cli,Rust,cli-interactive,monorepo,"cli,ratatui,crossterm",cli-tool-architecture.md,,
-cli-go-interactive,Interactive TUI (Go),cli,Go,cli-interactive,monorepo,"cli,bubbletea,charm",cli-tool-architecture.md,,
-cli-node-daemon,CLI with Daemon (Node.js),cli,TypeScript,cli-daemon,monorepo,"cli,service,systemd",cli-tool-architecture.md,,
-cli-python-daemon,CLI with Daemon (Python),cli,Python,cli-daemon,monorepo,"cli,service,systemd",cli-tool-architecture.md,,
-cli-go-daemon,CLI with Service (Go),cli,Go,cli-daemon,monorepo,"cli,service,systemd",cli-tool-architecture.md,,
-desktop-electron,Electron App,desktop,TypeScript,desktop,monorepo,"electron,cross-platform,chromium",desktop-app-architecture.md,,
-desktop-tauri,Tauri App,desktop,"TypeScript,Rust",desktop,monorepo,"tauri,rust,webview,lightweight",desktop-app-architecture.md,,
-desktop-wails,Wails App (Go),desktop,"TypeScript,Go",desktop,monorepo,"wails,go,webview",desktop-app-architecture.md,,
-desktop-qt-cpp,Qt Desktop (C++),desktop,C++,desktop,monorepo,"qt,cpp,native,cross-platform",desktop-app-architecture.md,,
-desktop-qt-python,Qt Desktop (Python),desktop,Python,desktop,monorepo,"qt,python,pyside6",desktop-app-architecture.md,,
-desktop-dotnet-wpf,WPF Desktop (.NET),desktop,C#,desktop,monorepo,"dotnet,windows,xaml",desktop-app-architecture.md,,
-desktop-dotnet-maui,MAUI Desktop (.NET),desktop,C#,desktop,monorepo,"dotnet,cross-platform,xaml",desktop-app-architecture.md,,
-desktop-swiftui-macos,SwiftUI macOS,desktop,Swift,desktop,monorepo,"swiftui,macos,native,declarative",desktop-app-architecture.md,,
-desktop-gtk,GTK Desktop,desktop,"C,Python",desktop,monorepo,"gtk,linux,gnome",desktop-app-architecture.md,,
-desktop-tkinter,Tkinter Desktop (Python),desktop,Python,desktop,monorepo,"tkinter,simple,cross-platform",desktop-app-architecture.md,,
-data-etl-python,Python ETL,data,Python,pipeline,monorepo,"etl,pandas,dask",data-pipeline-architecture.md,,
-data-etl-spark,Spark ETL,data,"Scala,Python",pipeline,monorepo,"etl,spark,big-data,pyspark",data-pipeline-architecture.md,,
-data-dbt,dbt Transformations,data,SQL,pipeline,monorepo,"etl,dbt,sql,analytics-engineering",data-pipeline-architecture.md,,
-data-ml-training,ML Training Pipeline,data,Python,pipeline,monorepo,"ml,mlflow,pytorch,tensorflow",data-pipeline-architecture.md,,
-data-ml-inference,ML Inference Service,data,Python,pipeline,monorepo,"ml,serving,triton,torchserve",data-pipeline-architecture.md,,
-data-kubeflow,Kubeflow Pipelines,data,Python,pipeline,monorepo,"ml,kubeflow,kubernetes,pipelines",data-pipeline-architecture.md,,
-data-analytics-superset,Superset Analytics,data,Python,analytics,monorepo,"analytics,superset,dashboards,bi",data-pipeline-architecture.md,,
-data-analytics-metabase,Metabase Analytics,data,any,analytics,monorepo,"analytics,metabase,dashboards,bi",data-pipeline-architecture.md,,
-data-looker,Looker/LookML,data,LookML,analytics,monorepo,"analytics,looker,bi,enterprise",data-pipeline-architecture.md,,
-data-warehouse-snowflake,Snowflake Warehouse,data,SQL,warehouse,monorepo,"warehouse,snowflake,cloud,dbt",data-pipeline-architecture.md,,
-data-warehouse-bigquery,BigQuery Warehouse,data,SQL,warehouse,monorepo,"warehouse,bigquery,gcp,dbt",data-pipeline-architecture.md,,
-data-warehouse-redshift,Redshift Warehouse,data,SQL,warehouse,monorepo,"warehouse,redshift,aws,dbt",data-pipeline-architecture.md,,
-data-streaming-kafka,Kafka Streaming,data,"Java,Scala",streaming,monorepo,"streaming,kafka,confluent,real-time",data-pipeline-architecture.md,,
-data-streaming-flink,Flink Streaming,data,"Java,Python",streaming,monorepo,"streaming,flink,stateful,real-time",data-pipeline-architecture.md,,
-data-streaming-spark,Spark Streaming,data,"Scala,Python",streaming,monorepo,"streaming,spark,micro-batch",data-pipeline-architecture.md,,
-extension-chrome,Chrome Extension,extension,TypeScript,extension,monorepo,"browser,extension,manifest-v3",desktop-app-architecture.md,,
-extension-firefox,Firefox Extension,extension,TypeScript,extension,monorepo,"browser,webextensions,manifest-v2",desktop-app-architecture.md,,
-extension-safari,Safari Extension,extension,Swift,extension,monorepo,"browser,safari,xcode,app-extension",desktop-app-architecture.md,,
-extension-vscode,VS Code Extension,extension,TypeScript,extension,monorepo,"vscode,ide,language-server",desktop-app-architecture.md,,
-extension-intellij,IntelliJ Plugin,extension,Kotlin,extension,monorepo,"jetbrains,plugin,ide",desktop-app-architecture.md,,
-extension-sublime,Sublime Text Plugin,extension,Python,extension,monorepo,"sublime,editor",desktop-app-architecture.md,,
-infra-terraform,Terraform IaC,infra,HCL,iac,monorepo,"terraform,iac,cloud,multi-cloud",infrastructure-architecture.md,,
-infra-pulumi,Pulumi IaC,infra,"TypeScript,Python,Go",iac,monorepo,"pulumi,iac,cloud,programming",infrastructure-architecture.md,,
-infra-cdk-aws,AWS CDK,infra,TypeScript,iac,monorepo,"cdk,iac,cloudformation",infrastructure-architecture.md,,
-infra-cdktf,CDK for Terraform,infra,TypeScript,iac,monorepo,"cdktf,iac,typescript",infrastructure-architecture.md,,
-infra-k8s-operator,Kubernetes Operator,infra,Go,k8s-operator,monorepo,"kubernetes,operator,controller,crd",infrastructure-architecture.md,,
-infra-helm-charts,Helm Charts,infra,YAML,k8s-package,monorepo,"kubernetes,helm,package,templating",infrastructure-architecture.md,,
-infra-ansible,Ansible Playbooks,infra,YAML,config-mgmt,monorepo,"ansible,automation,idempotent",infrastructure-architecture.md,,
-infra-chef,Chef Cookbooks,infra,Ruby,config-mgmt,monorepo,"chef,automation,ruby-dsl",infrastructure-architecture.md,,
-infra-puppet,Puppet Manifests,infra,Puppet,config-mgmt,monorepo,"puppet,automation,declarative",infrastructure-architecture.md,,
-infra-saltstack,SaltStack,infra,YAML,config-mgmt,monorepo,"salt,automation,python",infrastructure-architecture.md,,

src/modules/bmm/workflows/3-solutioning/templates/web-api-architecture.md

@@ -1,66 +0,0 @@
-# {{TITLE}} Architecture Document
-
-**Project:** {{project_name}}
-**Date:** {{date}}
-**Author:** {{user_name}}
-
-## Executive Summary
-
-{{executive_summary}}
-
-## 1. Technology Stack and Decisions
-
-### 1.1 Technology and Library Decision Table
-
-{{technology_table}}
-
-## 2. Architecture Overview
-
-{{architecture_overview}}
-
-## 3. Data Architecture
-
-{{data_architecture}}
-
-## 4. Component and Integration Overview
-
-{{component_overview}}
-
-## 5. Architecture Decision Records
-
-{{architecture_decisions}}
-
-## 6. Implementation Guidance
-
-{{implementation_guidance}}
-
-## 7. Proposed Source Tree
-
-```
-{{source_tree}}
-```
-
-## 8. Testing Strategy
-
-{{testing_strategy}}
-{{testing_specialist_section}}
-
-## 9. Deployment and Operations
-
-{{deployment_operations}}
-{{devops_specialist_section}}
-
-## 10. Security
-
-{{security}}
-{{security_specialist_section}}
-
----
-
-## Specialist Sections
-
-{{specialist_sections_summary}}
-
----
-
-_Generated using BMad Method Solution Architecture workflow_

src/modules/bmm/workflows/3-solutioning/workflow.yaml

@@ -8,6 +8,8 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+user_skill_level: "{config_source}:user_skill_level"
 date: system-generated
 
 # Input requirements
@@ -40,7 +42,6 @@ outputs:
 
 # Workflow variables (set during execution)
 variables:
-  user_skill_level: "intermediate"
   project_type: ""
   architecture_style: ""
   repo_strategy: ""
@@ -53,8 +54,8 @@ instructions: "{installed_path}/instructions.md"
 validation: "{installed_path}/checklist.md"
 
 # Reference data files
-architecture_registry: "{installed_path}/templates/registry.csv"
-project_types_questions: "{installed_path}/project-types"
+project_types: "{installed_path}/project-types/project-types.csv"
+templates: "{installed_path}/project-types"
 
 # Default output location
 default_output_file: "{output_folder}/solution-architecture.md"
@@ -70,35 +71,33 @@ web_bundle:
   validation: "bmad/bmm/workflows/3-solutioning/checklist.md"
   tech_spec_workflow: "bmad/bmm/workflows/3-solutioning/tech-spec/workflow.yaml"
   # Reference data files
-  architecture_registry: "bmad/bmm/workflows/3-solutioning/templates/registry.csv"
-  project_types_questions: "bmad/bmm/workflows/3-solutioning/project-types"
+  project_types: "bmad/bmm/workflows/3-solutioning/project-types/project-types.csv"
   web_bundle_files:
     - "bmad/bmm/workflows/3-solutioning/instructions.md"
     - "bmad/bmm/workflows/3-solutioning/checklist.md"
     - "bmad/bmm/workflows/3-solutioning/ADR-template.md"
-    - "bmad/bmm/workflows/3-solutioning/templates/registry.csv"
-    - "bmad/bmm/workflows/3-solutioning/templates/backend-service-architecture.md"
-    - "bmad/bmm/workflows/3-solutioning/templates/cli-tool-architecture.md"
-    - "bmad/bmm/workflows/3-solutioning/templates/data-pipeline-architecture.md"
-    - "bmad/bmm/workflows/3-solutioning/templates/desktop-app-architecture.md"
-    - "bmad/bmm/workflows/3-solutioning/templates/embedded-firmware-architecture.md"
-    - "bmad/bmm/workflows/3-solutioning/templates/game-engine-architecture.md"
-    - "bmad/bmm/workflows/3-solutioning/templates/game-engine-godot-guide.md"
-    - "bmad/bmm/workflows/3-solutioning/templates/game-engine-unity-guide.md"
-    - "bmad/bmm/workflows/3-solutioning/templates/game-engine-web-guide.md"
-    - "bmad/bmm/workflows/3-solutioning/templates/infrastructure-architecture.md"
-    - "bmad/bmm/workflows/3-solutioning/templates/library-package-architecture.md"
-    - "bmad/bmm/workflows/3-solutioning/templates/mobile-app-architecture.md"
-    - "bmad/bmm/workflows/3-solutioning/templates/web-api-architecture.md"
-    - "bmad/bmm/workflows/3-solutioning/templates/web-fullstack-architecture.md"
-    - "bmad/bmm/workflows/3-solutioning/project-types/backend-questions.md"
-    - "bmad/bmm/workflows/3-solutioning/project-types/cli-questions.md"
-    - "bmad/bmm/workflows/3-solutioning/project-types/data-questions.md"
-    - "bmad/bmm/workflows/3-solutioning/project-types/desktop-questions.md"
-    - "bmad/bmm/workflows/3-solutioning/project-types/embedded-questions.md"
-    - "bmad/bmm/workflows/3-solutioning/project-types/extension-questions.md"
-    - "bmad/bmm/workflows/3-solutioning/project-types/game-questions.md"
-    - "bmad/bmm/workflows/3-solutioning/project-types/infra-questions.md"
-    - "bmad/bmm/workflows/3-solutioning/project-types/library-questions.md"
-    - "bmad/bmm/workflows/3-solutioning/project-types/mobile-questions.md"
-    - "bmad/bmm/workflows/3-solutioning/project-types/web-questions.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/project-types.csv"
+    # Instructions files
+    - "bmad/bmm/workflows/3-solutioning/project-types/web-instructions.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/mobile-instructions.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/game-instructions.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/backend-instructions.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/data-instructions.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/cli-instructions.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/library-instructions.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/desktop-instructions.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/embedded-instructions.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/extension-instructions.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/infrastructure-instructions.md"
+    # Template files
+    - "bmad/bmm/workflows/3-solutioning/project-types/web-template.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/mobile-template.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/game-template.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/backend-template.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/data-template.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/cli-template.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/library-template.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/desktop-template.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/embedded-template.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/extension-template.md"
+    - "bmad/bmm/workflows/3-solutioning/project-types/infrastructure-template.md"

src/modules/bmm/workflows/4-implementation/correct-course/workflow.yaml

@@ -7,6 +7,7 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 installed_path: "{project-root}/bmad/bmm/workflows/4-implementation/correct-course"

src/modules/bmm/workflows/4-implementation/create-story/workflow.yaml

@@ -7,6 +7,7 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/4-implementation/dev-story/workflow.yaml

@@ -7,6 +7,7 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/4-implementation/retrospective/workflow.yaml

@@ -7,6 +7,7 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 installed_path: "{project-root}/bmad/bmm/workflows/4-implementation/retrospective"

src/modules/bmm/workflows/4-implementation/review-story/workflow.yaml

@@ -8,6 +8,7 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/4-implementation/story-approved/workflow.yaml

@@ -8,6 +8,7 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/4-implementation/story-context/workflow.yaml

@@ -8,6 +8,7 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/4-implementation/story-ready/workflow.yaml

@@ -8,6 +8,7 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/testarch/atdd/workflow.yaml

@@ -8,6 +8,7 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/testarch/automate/workflow.yaml

@@ -8,6 +8,7 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/testarch/ci/workflow.yaml

@@ -8,6 +8,7 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/testarch/framework/workflow.yaml

@@ -8,6 +8,7 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/testarch/nfr-assess/workflow.yaml

@@ -8,6 +8,7 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/testarch/test-design/workflow.yaml

@@ -8,6 +8,7 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/testarch/test-review/workflow.yaml

@@ -8,6 +8,7 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 # Workflow components

src/modules/bmm/workflows/testarch/trace/workflow.yaml

@@ -8,6 +8,7 @@ config_source: "{project-root}/bmad/bmm/config.yaml"
 output_folder: "{config_source}:output_folder"
 user_name: "{config_source}:user_name"
 communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 # Workflow components