diff --git a/src/modules/bmm/_module-installer/install-menu-config.yaml b/src/modules/bmm/_module-installer/install-menu-config.yaml
index e9403441..b6c1272b 100644
--- a/src/modules/bmm/_module-installer/install-menu-config.yaml
+++ b/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"
diff --git a/src/modules/bmm/workflows/1-analysis/brainstorm-game/workflow.yaml b/src/modules/bmm/workflows/1-analysis/brainstorm-game/workflow.yaml
index 7c6a1caf..454954e9 100644
--- a/src/modules/bmm/workflows/1-analysis/brainstorm-game/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/1-analysis/brainstorm-project/workflow.yaml b/src/modules/bmm/workflows/1-analysis/brainstorm-project/workflow.yaml
index a221a7ce..77ad3370 100644
--- a/src/modules/bmm/workflows/1-analysis/brainstorm-project/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/1-analysis/document-project/workflow.yaml b/src/modules/bmm/workflows/1-analysis/document-project/workflow.yaml
index b618e33b..ec932f76 100644
--- a/src/modules/bmm/workflows/1-analysis/document-project/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/1-analysis/game-brief/instructions.md b/src/modules/bmm/workflows/1-analysis/game-brief/instructions.md
index d321ffa2..3631f021 100644
--- a/src/modules/bmm/workflows/1-analysis/game-brief/instructions.md
+++ b/src/modules/bmm/workflows/1-analysis/game-brief/instructions.md
@@ -2,7 +2,10 @@
The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml
You MUST have already loaded and processed: {installed_path}/workflow.yaml
-Communicate all responses in {communication_language}
+Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}
+Generate all documents in {document_output_language}
+
+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.
diff --git a/src/modules/bmm/workflows/1-analysis/game-brief/workflow.yaml b/src/modules/bmm/workflows/1-analysis/game-brief/workflow.yaml
index 1a7681b3..1c40b09e 100644
--- a/src/modules/bmm/workflows/1-analysis/game-brief/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/1-analysis/product-brief/instructions.md b/src/modules/bmm/workflows/1-analysis/product-brief/instructions.md
index 6851833f..0378c354 100644
--- a/src/modules/bmm/workflows/1-analysis/product-brief/instructions.md
+++ b/src/modules/bmm/workflows/1-analysis/product-brief/instructions.md
@@ -2,7 +2,10 @@
The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml
You MUST have already loaded and processed: {installed_path}/workflow.yaml
-Communicate all responses in {communication_language}
+Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}
+Generate all documents in {document_output_language}
+
+DOCUMENT OUTPUT: Concise, professional, strategically focused. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.
diff --git a/src/modules/bmm/workflows/1-analysis/product-brief/workflow.yaml b/src/modules/bmm/workflows/1-analysis/product-brief/workflow.yaml
index c4550bac..cd07fa7a 100644
--- a/src/modules/bmm/workflows/1-analysis/product-brief/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/1-analysis/research/workflow.yaml b/src/modules/bmm/workflows/1-analysis/research/workflow.yaml
index b31a9404..9b2f1596 100644
--- a/src/modules/bmm/workflows/1-analysis/research/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/1-analysis/workflow-init/workflow.yaml b/src/modules/bmm/workflows/1-analysis/workflow-init/workflow.yaml
index b6bae27b..00ea96f6 100644
--- a/src/modules/bmm/workflows/1-analysis/workflow-init/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/1-analysis/workflow-status/workflow.yaml b/src/modules/bmm/workflows/1-analysis/workflow-status/workflow.yaml
index 4b2f9b17..e109373a 100644
--- a/src/modules/bmm/workflows/1-analysis/workflow-status/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/2-plan-workflows/gdd/instructions-gdd.md b/src/modules/bmm/workflows/2-plan-workflows/gdd/instructions-gdd.md
index f372549c..0bd8f1f3 100644
--- a/src/modules/bmm/workflows/2-plan-workflows/gdd/instructions-gdd.md
+++ b/src/modules/bmm/workflows/2-plan-workflows/gdd/instructions-gdd.md
@@ -4,13 +4,16 @@
The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.xml
You MUST have already loaded and processed: {installed_path}/workflow.yaml
-Communicate all responses in {communication_language}
+Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}
+Generate all documents in {document_output_language}
This is the GDD instruction set for GAME projects - replaces PRD with Game Design Document
Project analysis already completed - proceeding with game-specific design
Uses gdd_template for GDD output, game_types.csv for type-specific sections
Routes to 3-solutioning for architecture (platform-specific decisions handled there)
If users mention technical details, append to technical_preferences with timestamp
+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.
+
diff --git a/src/modules/bmm/workflows/2-plan-workflows/gdd/workflow.yaml b/src/modules/bmm/workflows/2-plan-workflows/gdd/workflow.yaml
index 421102f2..0bef9b35 100644
--- a/src/modules/bmm/workflows/2-plan-workflows/gdd/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/2-plan-workflows/narrative/workflow.yaml b/src/modules/bmm/workflows/2-plan-workflows/narrative/workflow.yaml
index 11e92bb6..fa0eefe2 100644
--- a/src/modules/bmm/workflows/2-plan-workflows/narrative/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/2-plan-workflows/prd/instructions.md b/src/modules/bmm/workflows/2-plan-workflows/prd/instructions.md
index 26d3350a..cbf9b2aa 100644
--- a/src/modules/bmm/workflows/2-plan-workflows/prd/instructions.md
+++ b/src/modules/bmm/workflows/2-plan-workflows/prd/instructions.md
@@ -2,11 +2,14 @@
The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml
You MUST have already loaded and processed: {installed_path}/workflow.yaml
-Communicate all responses in {communication_language}
+Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}
+Generate all documents in {document_output_language}
This workflow is for Level 2-4 projects. Level 0-1 use tech-spec workflow.
Produces TWO outputs: PRD.md (strategic) and epics.md (tactical implementation)
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}
+DOCUMENT OUTPUT: Concise, clear, actionable requirements. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.
+
diff --git a/src/modules/bmm/workflows/2-plan-workflows/prd/workflow.yaml b/src/modules/bmm/workflows/2-plan-workflows/prd/workflow.yaml
index fb1321a7..420444d1 100644
--- a/src/modules/bmm/workflows/2-plan-workflows/prd/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/2-plan-workflows/tech-spec/instructions.md b/src/modules/bmm/workflows/2-plan-workflows/tech-spec/instructions.md
index 9d7249a0..3b55d4d6 100644
--- a/src/modules/bmm/workflows/2-plan-workflows/tech-spec/instructions.md
+++ b/src/modules/bmm/workflows/2-plan-workflows/tech-spec/instructions.md
@@ -4,12 +4,15 @@
The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.xml
You MUST have already loaded and processed: {installed_path}/workflow.yaml
-Communicate all responses in {communication_language}
+Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}
+Generate all documents in {document_output_language}
This is the SMALL instruction set for Level 0-1 projects - tech-spec with story generation
Level 0: tech-spec + single user story | Level 1: tech-spec + epic/stories
Project analysis already completed - proceeding directly to technical specification
NO PRD generated - uses tech_spec_template + story templates
+DOCUMENT OUTPUT: Technical, precise, definitive. Specific versions only. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.
+
diff --git a/src/modules/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml b/src/modules/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml
index 5e530581..c0e8b42c 100644
--- a/src/modules/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/2-plan-workflows/ux/instructions-ux.md b/src/modules/bmm/workflows/2-plan-workflows/ux/instructions-ux.md
index 65367221..64cb4c69 100644
--- a/src/modules/bmm/workflows/2-plan-workflows/ux/instructions-ux.md
+++ b/src/modules/bmm/workflows/2-plan-workflows/ux/instructions-ux.md
@@ -4,11 +4,14 @@
The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.xml
You MUST have already loaded and processed: {installed_path}/workflow.yaml
-Communicate all responses in {communication_language}
+Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}
+Generate all documents in {document_output_language}
This workflow creates comprehensive UX/UI specifications - can run standalone or as part of plan-project
Uses ux-spec-template.md for structured output generation
Can optionally generate AI Frontend Prompts for tools like Vercel v0, Lovable.ai
+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.
+
diff --git a/src/modules/bmm/workflows/2-plan-workflows/ux/workflow.yaml b/src/modules/bmm/workflows/2-plan-workflows/ux/workflow.yaml
index 4a18aa01..fb032a7b 100644
--- a/src/modules/bmm/workflows/2-plan-workflows/ux/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/3-solutioning/README.md b/src/modules/bmm/workflows/3-solutioning/README.md
index 30c3b3d4..97f09cc7 100644
--- a/src/modules/bmm/workflows/3-solutioning/README.md
+++ b/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`
---
diff --git a/src/modules/bmm/workflows/3-solutioning/implementation-ready-check/workflow.yaml b/src/modules/bmm/workflows/3-solutioning/implementation-ready-check/workflow.yaml
index 50f4683d..444282f5 100644
--- a/src/modules/bmm/workflows/3-solutioning/implementation-ready-check/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/3-solutioning/instructions.md b/src/modules/bmm/workflows/3-solutioning/instructions.md
index 5824377c..c482063d 100644
--- a/src/modules/bmm/workflows/3-solutioning/instructions.md
+++ b/src/modules/bmm/workflows/3-solutioning/instructions.md
@@ -6,26 +6,10 @@ This workflow generates scale-adaptive solution architecture documentation that
The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.xml
You MUST have already loaded and processed: {installed_path}/workflow.yaml
-Communicate all responses in {communication_language}
+Communicate all responses in {communication_language} and language MUSt be tailored to {user_skill_level}
+Generate all documents in {document_output_language}
-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.
-
+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.
@@ -182,19 +166,34 @@ Proceeding with solution architecture workflow...
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
-Based on the conversation, determine the appropriate level of detail for the architecture document:
+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
+
+ - Explain architectural concepts as you discuss them
+ - Be patient and educational in your responses
+ - Clarify technical terms when introducing them
+
-Remember the OUTPUT OPTIMIZATION critical - even beginner explanations should be concise.
+
+ - Balance explanations with efficiency
+ - Assume familiarity with common concepts
+ - Explain only complex or unusual patterns
+
+
+
+ - Be direct and technical in discussions
+ - Skip basic explanations
+ - Focus on advanced considerations and edge cases
+
+
+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.
user_context
@@ -231,20 +230,27 @@ Remember the OUTPUT OPTIMIZATION critical - even beginner explanations should be
-This is a crucial step where we ensure comprehensive architectural coverage.
+Use intent-based decision making, not prescriptive checklists.
-Load the project type registry from: {{installed_path}}/project-types/project-types.csv
+Based on requirements analysis, identify the project domain(s).
+Note: Projects can be hybrid (e.g., web + mobile, game + backend service).
-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).
+Use the simplified project types mapping:
+{{installed_path}}/project-types/project-types.csv
-For each identified project type, load the corresponding questions from: {{installed_path}}/project-types/{{question_file}}
+This contains ~11 core project types that cover 99% of software projects.
-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:
+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.
+
+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
Engage with the user to make all necessary technical decisions:
@@ -263,17 +269,27 @@ Remember the OUTPUT OPTIMIZATION critical - even beginner explanations should be
-Load the template registry from: {{installed_path}}/templates/registry.csv
+Select the appropriate adaptive template:
+{{installed_path}}/project-types/{{type}}-template.md
-Select the most appropriate template based on:
+Template selection follows the naming convention:
-- The identified project type(s)
-- The chosen architecture style
-- The repository strategy
-- The primary technologies selected
-
+- 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
-Load the selected template and any associated guides to understand the document structure needed for this type of project.
+For hybrid projects, choose the primary domain or intelligently merge relevant sections from multiple templates.
+
+Adapt the template heavily based on actual requirements.
+Templates are starting points, not rigid structures.
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
Ensure the document provides enough technical specificity that implementation agents can:
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/backend-instructions.md b/src/modules/bmm/workflows/3-solutioning/project-types/backend-instructions.md
new file mode 100644
index 00000000..d785ce61
--- /dev/null
+++ b/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
+
+
+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
+
+
+## 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.
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/backend-questions.md b/src/modules/bmm/workflows/3-solutioning/project-types/backend-questions.md
deleted file mode 100644
index 290440fe..00000000
--- a/src/modules/bmm/workflows/3-solutioning/project-types/backend-questions.md
+++ /dev/null
@@ -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
diff --git a/src/modules/bmm/workflows/3-solutioning/templates/backend-service-architecture.md b/src/modules/bmm/workflows/3-solutioning/project-types/backend-template.md
similarity index 100%
rename from src/modules/bmm/workflows/3-solutioning/templates/backend-service-architecture.md
rename to src/modules/bmm/workflows/3-solutioning/project-types/backend-template.md
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/cli-instructions.md b/src/modules/bmm/workflows/3-solutioning/project-types/cli-instructions.md
new file mode 100644
index 00000000..0053842d
--- /dev/null
+++ b/src/modules/bmm/workflows/3-solutioning/project-types/cli-instructions.md
@@ -0,0 +1,149 @@
+# CLI Tool Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+
+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
+
+
+## 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.
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/cli-questions.md b/src/modules/bmm/workflows/3-solutioning/project-types/cli-questions.md
deleted file mode 100644
index dfa29497..00000000
--- a/src/modules/bmm/workflows/3-solutioning/project-types/cli-questions.md
+++ /dev/null
@@ -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
diff --git a/src/modules/bmm/workflows/3-solutioning/templates/cli-tool-architecture.md b/src/modules/bmm/workflows/3-solutioning/project-types/cli-template.md
similarity index 100%
rename from src/modules/bmm/workflows/3-solutioning/templates/cli-tool-architecture.md
rename to src/modules/bmm/workflows/3-solutioning/project-types/cli-template.md
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/data-instructions.md b/src/modules/bmm/workflows/3-solutioning/project-types/data-instructions.md
new file mode 100644
index 00000000..5ba5ee4a
--- /dev/null
+++ b/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
+
+
+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
+
+
+## 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.
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/data-questions.md b/src/modules/bmm/workflows/3-solutioning/project-types/data-questions.md
deleted file mode 100644
index 3d68025d..00000000
--- a/src/modules/bmm/workflows/3-solutioning/project-types/data-questions.md
+++ /dev/null
@@ -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)
diff --git a/src/modules/bmm/workflows/3-solutioning/templates/data-pipeline-architecture.md b/src/modules/bmm/workflows/3-solutioning/project-types/data-template.md
similarity index 100%
rename from src/modules/bmm/workflows/3-solutioning/templates/data-pipeline-architecture.md
rename to src/modules/bmm/workflows/3-solutioning/project-types/data-template.md
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/desktop-instructions.md b/src/modules/bmm/workflows/3-solutioning/project-types/desktop-instructions.md
new file mode 100644
index 00000000..59f96624
--- /dev/null
+++ b/src/modules/bmm/workflows/3-solutioning/project-types/desktop-instructions.md
@@ -0,0 +1,182 @@
+# Desktop Application Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+
+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
+
+
+## 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.
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/desktop-questions.md b/src/modules/bmm/workflows/3-solutioning/project-types/desktop-questions.md
deleted file mode 100644
index a6d1c1ef..00000000
--- a/src/modules/bmm/workflows/3-solutioning/project-types/desktop-questions.md
+++ /dev/null
@@ -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
diff --git a/src/modules/bmm/workflows/3-solutioning/templates/desktop-app-architecture.md b/src/modules/bmm/workflows/3-solutioning/project-types/desktop-template.md
similarity index 100%
rename from src/modules/bmm/workflows/3-solutioning/templates/desktop-app-architecture.md
rename to src/modules/bmm/workflows/3-solutioning/project-types/desktop-template.md
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/embedded-instructions.md b/src/modules/bmm/workflows/3-solutioning/project-types/embedded-instructions.md
new file mode 100644
index 00000000..edf1c067
--- /dev/null
+++ b/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
+
+
+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
+
+
+## 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.
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/embedded-questions.md b/src/modules/bmm/workflows/3-solutioning/project-types/embedded-questions.md
deleted file mode 100644
index 62146454..00000000
--- a/src/modules/bmm/workflows/3-solutioning/project-types/embedded-questions.md
+++ /dev/null
@@ -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
diff --git a/src/modules/bmm/workflows/3-solutioning/templates/embedded-firmware-architecture.md b/src/modules/bmm/workflows/3-solutioning/project-types/embedded-template.md
similarity index 100%
rename from src/modules/bmm/workflows/3-solutioning/templates/embedded-firmware-architecture.md
rename to src/modules/bmm/workflows/3-solutioning/project-types/embedded-template.md
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/extension-instructions.md b/src/modules/bmm/workflows/3-solutioning/project-types/extension-instructions.md
new file mode 100644
index 00000000..6399772d
--- /dev/null
+++ b/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
+
+
+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
+
+
+## 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.
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/extension-questions.md b/src/modules/bmm/workflows/3-solutioning/project-types/extension-questions.md
deleted file mode 100644
index 87125555..00000000
--- a/src/modules/bmm/workflows/3-solutioning/project-types/extension-questions.md
+++ /dev/null
@@ -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: )
- - 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 ()
- - 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
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/extension-template.md b/src/modules/bmm/workflows/3-solutioning/project-types/extension-template.md
new file mode 100644
index 00000000..fb372b20
--- /dev/null
+++ b/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_
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/game-instructions.md b/src/modules/bmm/workflows/3-solutioning/project-types/game-instructions.md
new file mode 100644
index 00000000..273c74b3
--- /dev/null
+++ b/src/modules/bmm/workflows/3-solutioning/project-types/game-instructions.md
@@ -0,0 +1,225 @@
+# Game Development Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+
+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
+
+
+## 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
+
+
+The architecture MUST adapt to the game type identified in the GDD.
+Load the specific game type considerations and merge with general guidance.
+
+
+### 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.
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/game-questions.md b/src/modules/bmm/workflows/3-solutioning/project-types/game-questions.md
deleted file mode 100644
index 5e4812bf..00000000
--- a/src/modules/bmm/workflows/3-solutioning/project-types/game-questions.md
+++ /dev/null
@@ -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)
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/game-template.md b/src/modules/bmm/workflows/3-solutioning/project-types/game-template.md
new file mode 100644
index 00000000..5e78469a
--- /dev/null
+++ b/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}}
+
+
+This architecture adapts to {{game_type}} requirements.
+Sections are included/excluded based on game needs.
+
+
+## 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
+
+
+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
+
+
+{{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
+
+
+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
+
+
+### 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
+
+
+Adapt to game data needs:
+- Simple puzzle: JSON level files
+- RPG: Complex relational data
+- Multiplayer: Server-authoritative state
+- Roguelike: Seed-based generation
+
+
+{{data_management}}
+
+### 4.2 Save System
+
+{{save_system}}
+
+### 4.3 Content Pipeline
+
+{{content_pipeline}}
+
+## 5. Scene/Level Architecture
+
+
+Structure varies by game type:
+- Linear: Sequential level loading
+- Open World: Streaming and chunks
+- Stage-based: Level selection and unlocking
+- Procedural: Generation pipeline
+
+
+{{scene_architecture}}
+
+## 6. Gameplay Implementation
+
+
+ONLY include subsections relevant to the game.
+A racing game doesn't need an inventory system.
+A puzzle game doesn't need combat mechanics.
+
+
+{{gameplay_systems}}
+
+## 7. Presentation Layer
+
+
+Adapt to visual style:
+- 3D: Rendering pipeline, lighting, LOD
+- 2D: Sprite management, layers
+- Text: Minimal visual architecture
+- Hybrid: Both 2D and 3D considerations
+
+
+### 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
+
+
+Only for games with multiplayer features
+
+
+### 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
+
+
+Platform-specific considerations:
+- Mobile: Touch controls, battery, performance
+- Console: Achievements, controllers, certification
+- PC: Wide hardware range, settings
+- Web: Download size, browser compatibility
+
+
+{{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
+
+
+Adapt to platform and game type:
+- Mobile: Strict size limits
+- Web: Download optimization
+- Console: Memory constraints
+- PC: Balance quality vs. performance
+
+
+{{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
+
+
+Testing needs vary by game:
+- Multiplayer: Network testing, load testing
+- Procedural: Seed testing, generation validation
+- Physics: Determinism testing
+- Narrative: Story branch testing
+
+
+{{testing_strategy}}
+
+## 17. Key Architecture Decisions
+
+### Decision Records
+
+{{architecture_decisions}}
+
+### Risk Mitigation
+
+{{risk_mitigation}}
+
+{{#if_complex_project}}
+
+## 18. Specialist Considerations
+
+
+Only for complex projects needing specialist input
+
+
+{{specialist_notes}}
+{{/if_complex_project}}
+
+---
+
+## Implementation Roadmap
+
+{{implementation_roadmap}}
+
+---
+
+_Architecture optimized for {{game_type}} game on {{platforms}}_
+_Generated using BMad Method Solution Architecture workflow_
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/infra-questions.md b/src/modules/bmm/workflows/3-solutioning/project-types/infra-questions.md
deleted file mode 100644
index 40e95041..00000000
--- a/src/modules/bmm/workflows/3-solutioning/project-types/infra-questions.md
+++ /dev/null
@@ -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
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/infrastructure-instructions.md b/src/modules/bmm/workflows/3-solutioning/project-types/infrastructure-instructions.md
new file mode 100644
index 00000000..4fd46f6e
--- /dev/null
+++ b/src/modules/bmm/workflows/3-solutioning/project-types/infrastructure-instructions.md
@@ -0,0 +1,198 @@
+# Infrastructure/DevOps Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+
+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
+
+
+## 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.
diff --git a/src/modules/bmm/workflows/3-solutioning/templates/infrastructure-architecture.md b/src/modules/bmm/workflows/3-solutioning/project-types/infrastructure-template.md
similarity index 100%
rename from src/modules/bmm/workflows/3-solutioning/templates/infrastructure-architecture.md
rename to src/modules/bmm/workflows/3-solutioning/project-types/infrastructure-template.md
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/library-instructions.md b/src/modules/bmm/workflows/3-solutioning/project-types/library-instructions.md
new file mode 100644
index 00000000..e18c776b
--- /dev/null
+++ b/src/modules/bmm/workflows/3-solutioning/project-types/library-instructions.md
@@ -0,0 +1,185 @@
+# Library/SDK Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+
+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
+
+
+## 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.
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/library-questions.md b/src/modules/bmm/workflows/3-solutioning/project-types/library-questions.md
deleted file mode 100644
index 0b6d8004..00000000
--- a/src/modules/bmm/workflows/3-solutioning/project-types/library-questions.md
+++ /dev/null
@@ -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
diff --git a/src/modules/bmm/workflows/3-solutioning/templates/library-package-architecture.md b/src/modules/bmm/workflows/3-solutioning/project-types/library-template.md
similarity index 100%
rename from src/modules/bmm/workflows/3-solutioning/templates/library-package-architecture.md
rename to src/modules/bmm/workflows/3-solutioning/project-types/library-template.md
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/mobile-instructions.md b/src/modules/bmm/workflows/3-solutioning/project-types/mobile-instructions.md
new file mode 100644
index 00000000..2cee3d0d
--- /dev/null
+++ b/src/modules/bmm/workflows/3-solutioning/project-types/mobile-instructions.md
@@ -0,0 +1,181 @@
+# Mobile Application Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+
+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
+
+
+## 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.
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/mobile-questions.md b/src/modules/bmm/workflows/3-solutioning/project-types/mobile-questions.md
deleted file mode 100644
index 92269750..00000000
--- a/src/modules/bmm/workflows/3-solutioning/project-types/mobile-questions.md
+++ /dev/null
@@ -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
diff --git a/src/modules/bmm/workflows/3-solutioning/templates/mobile-app-architecture.md b/src/modules/bmm/workflows/3-solutioning/project-types/mobile-template.md
similarity index 100%
rename from src/modules/bmm/workflows/3-solutioning/templates/mobile-app-architecture.md
rename to src/modules/bmm/workflows/3-solutioning/project-types/mobile-template.md
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/project-types.csv b/src/modules/bmm/workflows/3-solutioning/project-types/project-types.csv
index ea63dc25..74aef1b3 100644
--- a/src/modules/bmm/workflows/3-solutioning/project-types/project-types.csv
+++ b/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"
\ No newline at end of file
+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
\ No newline at end of file
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/web-instructions.md b/src/modules/bmm/workflows/3-solutioning/project-types/web-instructions.md
new file mode 100644
index 00000000..4299818a
--- /dev/null
+++ b/src/modules/bmm/workflows/3-solutioning/project-types/web-instructions.md
@@ -0,0 +1,158 @@
+# Web Project Architecture Instructions
+
+## Intent-Based Technical Decision Guidance
+
+
+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
+
+
+## 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
+
+
+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.
+
+
+## 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.
diff --git a/src/modules/bmm/workflows/3-solutioning/project-types/web-questions.md b/src/modules/bmm/workflows/3-solutioning/project-types/web-questions.md
deleted file mode 100644
index 05c1f830..00000000
--- a/src/modules/bmm/workflows/3-solutioning/project-types/web-questions.md
+++ /dev/null
@@ -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
diff --git a/src/modules/bmm/workflows/3-solutioning/templates/web-fullstack-architecture.md b/src/modules/bmm/workflows/3-solutioning/project-types/web-template.md
similarity index 100%
rename from src/modules/bmm/workflows/3-solutioning/templates/web-fullstack-architecture.md
rename to src/modules/bmm/workflows/3-solutioning/project-types/web-template.md
diff --git a/src/modules/bmm/workflows/3-solutioning/tech-spec/workflow.yaml b/src/modules/bmm/workflows/3-solutioning/tech-spec/workflow.yaml
index 12b0a788..a4cbad1e 100644
--- a/src/modules/bmm/workflows/3-solutioning/tech-spec/workflow.yaml
+++ b/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)
diff --git a/src/modules/bmm/workflows/3-solutioning/templates/game-engine-architecture.md b/src/modules/bmm/workflows/3-solutioning/templates/game-engine-architecture.md
deleted file mode 100644
index b4641da4..00000000
--- a/src/modules/bmm/workflows/3-solutioning/templates/game-engine-architecture.md
+++ /dev/null
@@ -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_
diff --git a/src/modules/bmm/workflows/3-solutioning/templates/game-engine-godot-guide.md b/src/modules/bmm/workflows/3-solutioning/templates/game-engine-godot-guide.md
deleted file mode 100644
index 37c4ae80..00000000
--- a/src/modules/bmm/workflows/3-solutioning/templates/game-engine-godot-guide.md
+++ /dev/null
@@ -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()` | `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
diff --git a/src/modules/bmm/workflows/3-solutioning/templates/game-engine-unity-guide.md b/src/modules/bmm/workflows/3-solutioning/templates/game-engine-unity-guide.md
deleted file mode 100644
index c695dd07..00000000
--- a/src/modules/bmm/workflows/3-solutioning/templates/game-engine-unity-guide.md
+++ /dev/null
@@ -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 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.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
diff --git a/src/modules/bmm/workflows/3-solutioning/templates/game-engine-web-guide.md b/src/modules/bmm/workflows/3-solutioning/templates/game-engine-web-guide.md
deleted file mode 100644
index ad73364c..00000000
--- a/src/modules/bmm/workflows/3-solutioning/templates/game-engine-web-guide.md
+++ /dev/null
@@ -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
diff --git a/src/modules/bmm/workflows/3-solutioning/templates/registry.csv b/src/modules/bmm/workflows/3-solutioning/templates/registry.csv
deleted file mode 100644
index 92579105..00000000
--- a/src/modules/bmm/workflows/3-solutioning/templates/registry.csv
+++ /dev/null
@@ -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,,
diff --git a/src/modules/bmm/workflows/3-solutioning/templates/web-api-architecture.md b/src/modules/bmm/workflows/3-solutioning/templates/web-api-architecture.md
deleted file mode 100644
index 8d58e102..00000000
--- a/src/modules/bmm/workflows/3-solutioning/templates/web-api-architecture.md
+++ /dev/null
@@ -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_
diff --git a/src/modules/bmm/workflows/3-solutioning/workflow.yaml b/src/modules/bmm/workflows/3-solutioning/workflow.yaml
index a8e9cee7..70ee8dae 100644
--- a/src/modules/bmm/workflows/3-solutioning/workflow.yaml
+++ b/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"
diff --git a/src/modules/bmm/workflows/4-implementation/correct-course/workflow.yaml b/src/modules/bmm/workflows/4-implementation/correct-course/workflow.yaml
index 551c9751..64c52e41 100644
--- a/src/modules/bmm/workflows/4-implementation/correct-course/workflow.yaml
+++ b/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"
diff --git a/src/modules/bmm/workflows/4-implementation/create-story/workflow.yaml b/src/modules/bmm/workflows/4-implementation/create-story/workflow.yaml
index 6a77fda4..929c8c8c 100644
--- a/src/modules/bmm/workflows/4-implementation/create-story/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/4-implementation/dev-story/workflow.yaml b/src/modules/bmm/workflows/4-implementation/dev-story/workflow.yaml
index 613031c2..65650dfc 100644
--- a/src/modules/bmm/workflows/4-implementation/dev-story/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/4-implementation/retrospective/workflow.yaml b/src/modules/bmm/workflows/4-implementation/retrospective/workflow.yaml
index 39a23c2d..83f077ad 100644
--- a/src/modules/bmm/workflows/4-implementation/retrospective/workflow.yaml
+++ b/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"
diff --git a/src/modules/bmm/workflows/4-implementation/review-story/workflow.yaml b/src/modules/bmm/workflows/4-implementation/review-story/workflow.yaml
index c8446f0f..4d3af44a 100644
--- a/src/modules/bmm/workflows/4-implementation/review-story/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/4-implementation/story-approved/workflow.yaml b/src/modules/bmm/workflows/4-implementation/story-approved/workflow.yaml
index 018b9086..bcb4650e 100644
--- a/src/modules/bmm/workflows/4-implementation/story-approved/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/4-implementation/story-context/workflow.yaml b/src/modules/bmm/workflows/4-implementation/story-context/workflow.yaml
index b5cb838d..2d10b74c 100644
--- a/src/modules/bmm/workflows/4-implementation/story-context/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/4-implementation/story-ready/workflow.yaml b/src/modules/bmm/workflows/4-implementation/story-ready/workflow.yaml
index 87bac3f2..7ae72aaa 100644
--- a/src/modules/bmm/workflows/4-implementation/story-ready/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/testarch/atdd/workflow.yaml b/src/modules/bmm/workflows/testarch/atdd/workflow.yaml
index d1e0fa10..8054a2d9 100644
--- a/src/modules/bmm/workflows/testarch/atdd/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/testarch/automate/workflow.yaml b/src/modules/bmm/workflows/testarch/automate/workflow.yaml
index 5f536528..0e896941 100644
--- a/src/modules/bmm/workflows/testarch/automate/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/testarch/ci/workflow.yaml b/src/modules/bmm/workflows/testarch/ci/workflow.yaml
index 9593b82d..3fbbf246 100644
--- a/src/modules/bmm/workflows/testarch/ci/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/testarch/framework/workflow.yaml b/src/modules/bmm/workflows/testarch/framework/workflow.yaml
index 0b66c96a..4ecf08cb 100644
--- a/src/modules/bmm/workflows/testarch/framework/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/testarch/nfr-assess/workflow.yaml b/src/modules/bmm/workflows/testarch/nfr-assess/workflow.yaml
index 77eb1126..5c09060a 100644
--- a/src/modules/bmm/workflows/testarch/nfr-assess/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/testarch/test-design/workflow.yaml b/src/modules/bmm/workflows/testarch/test-design/workflow.yaml
index 47888019..662a42b0 100644
--- a/src/modules/bmm/workflows/testarch/test-design/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/testarch/test-review/workflow.yaml b/src/modules/bmm/workflows/testarch/test-review/workflow.yaml
index 15d9b0dc..0863ef65 100644
--- a/src/modules/bmm/workflows/testarch/test-review/workflow.yaml
+++ b/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
diff --git a/src/modules/bmm/workflows/testarch/trace/workflow.yaml b/src/modules/bmm/workflows/testarch/trace/workflow.yaml
index 8edd94dd..667c55ac 100644
--- a/src/modules/bmm/workflows/testarch/trace/workflow.yaml
+++ b/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