architecture name standardization

bmd/bmad-custom-module-installer-plan.md

@@ -207,7 +207,7 @@ User runs: npm run install:bmad
 
 ---
 
-## Proposed Solution Architecture
+## Proposed Architecture
 
 ### New Command: `install-module`
 

src/modules/bmm/testarch/README.md

@@ -139,7 +139,7 @@ This complexity **requires specialized documentation** (this guide), **extensive
 <details>
 <summary>Worked Example – “Nova CRM” Greenfield Feature</summary>
 
-1. **Planning:** Analyst runs `*product-brief`; PM executes `*plan-project` to produce PRD and epics; Architect completes `*solution-architecture` for the new module.
+1. **Planning:** Analyst runs `*product-brief`; PM executes `*plan-project` to produce PRD and epics; Architect completes `*create-architecture` for the new module.
 2. **Setup:** TEA checks harness via `*framework`, configures `*ci`, and runs `*test-design` to capture risk/coverage plans.
 3. **Story Prep:** Scrum Master generates the story via `*create-story`; PO validates using `*solutioning-gate-check`.
 4. **Implementation:** TEA optionally runs `*atdd`; Dev implements with guidance from failing tests and the plan.
@@ -174,7 +174,7 @@ This complexity **requires specialized documentation** (this guide), **extensive
 <details>
 <summary>Worked Example – “Atlas Payments” Brownfield Story</summary>
 
-1. **Context Refresh:** Analyst reruns `*product-brief`; PM executes `*plan-project` to update PRD, analysis, and `epics.md`; Architect triggers `*solution-architecture` capturing legacy payment flows.
+1. **Context Refresh:** Analyst reruns `*product-brief`; PM executes `*plan-project` to update PRD, analysis, and `epics.md`; Architect triggers `*create-architecture` capturing legacy payment flows.
 2. **Baseline Coverage:** TEA executes `*trace` to record current coverage in `docs/qa/assessments/atlas-payment-trace.md`.
 3. **Risk and Design:** `*test-design` flags settlement edge cases, plans mitigations, and allocates new API/E2E scenarios with P0 priorities.
 4. **Story Prep:** Scrum Master generates `stories/story-1.1.md` via `*create-story`, automatically pulling updated context.

src/modules/bmm/workflows/1-analysis/brainstorm-project/README.md

@@ -4,7 +4,7 @@ last-redoc-date: 2025-10-01
 
 # Project Brainstorming Workflow
 
-This workflow facilitates structured ideation for non-game software projects through systematic exploration of problem spaces, solution architectures, and implementation strategies. Unlike traditional requirement gathering, it employs creative techniques to uncover non-obvious approaches and identify innovative solutions that address core business needs while considering technical constraints and organizational capabilities.
+This workflow facilitates structured ideation for non-game software projects through systematic exploration of problem spaces, architectures, and implementation strategies. Unlike traditional requirement gathering, it employs creative techniques to uncover non-obvious approaches and identify innovative solutions that address core business needs while considering technical constraints and organizational capabilities.
 
 The workflow operates through a project-specific context framework that captures business objectives, technical environment, stakeholder needs, and organizational constraints. It generates multiple solution vectors through parallel ideation tracks: architectural approaches, user experience paradigms, integration patterns, and value delivery mechanisms. Each track produces concrete proposals that are evaluated against feasibility, impact, and alignment with strategic objectives.
 
@@ -23,7 +23,7 @@ bmad bmm 1-analysis brainstorm-project
 
 ## Outputs
 
-- **Solution Architecture Proposals**: Multiple technical approaches with trade-off analysis and feasibility assessments
+- **Architecture Proposals**: Multiple technical approaches with trade-off analysis and feasibility assessments
 - **Value Delivery Framework**: Prioritized feature concepts aligned with business objectives and user needs
 - **Risk and Opportunity Analysis**: Identified technical dependencies, integration challenges, and innovation opportunities
 - **Strategic Recommendation**: Synthesized direction with rationale and implementation considerations

src/modules/bmm/workflows/2-plan-workflows/README.md

@@ -27,25 +27,25 @@ The workflow routes to different planning approaches based on project level:
 **Planning:** PRD (product-focused) + Tech-spec (technical planning)
 **Output:** `PRD.md`, `epics.md`, `tech-spec.md`
 **Next Phase:** Tech-spec workflow (lightweight solutioning), then implementation (Phase 4)
-**Note:** Level 2 uses tech-spec instead of full solution-architecture to keep planning lightweight
+**Note:** Level 2 uses tech-spec instead of full architecture to keep planning lightweight
 
 ### Level 3 - Medium Project (15-40 stories, 2-5 epics)
 
 **Planning:** PRD (strategic product document)
 **Output:** `PRD.md`, `epics.md`
-**Next Phase:** Solution-architecture workflow (Phase 3), then implementation (Phase 4)
+**Next Phase:** create-architecture workflow (Phase 3), then implementation (Phase 4)
 
 ### Level 4 - Large/Enterprise Project (40-100+ stories, 5-10 epics)
 
 **Planning:** PRD (comprehensive product specification)
 **Output:** `PRD.md`, `epics.md`
-**Next Phase:** Solution-architecture workflow (Phase 3), then implementation (Phase 4)
+**Next Phase:** create-architecture workflow (Phase 3), then implementation (Phase 4)
 
 **Critical Distinction:**
 
 - **Levels 0-1:** No PRD, tech-spec only
 - **Level 2:** PRD + tech-spec (skips full architecture)
-- **Levels 3-4:** PRD → full solution-architecture workflow
+- **Levels 3-4:** PRD → full create-architecture workflow
 
 Critical to v6's flow improvement is this workflow's integration with the bmm-workflow-status.md tracking document, which maintains project state across sessions, tracks which agents participate in each phase, and provides continuity for multi-session planning efforts. The workflow can resume from any point, intelligently detecting existing artifacts and determining next steps without redundant work. For UX-heavy projects, it can generate standalone UX specifications or AI frontend prompts from existing specs.
 
@@ -138,7 +138,7 @@ The workflow adapts automatically based on project assessment, but key configura
 
 - PRD workflow (comprehensive product specification)
 - Generates `PRD.md` and `epics.md`
-- Hands off to Phase 3 (solution-architecture workflow)
+- Hands off to Phase 3 (create-architecture workflow)
 - Full architecture design before implementation
 
 ### Phase 3: Validation and Handoff (Final steps)
@@ -177,7 +177,7 @@ The workflow adapts automatically based on project assessment, but key configura
 
 - `PRD.md` - Comprehensive product specification
 - `epics.md` - Complete epic/story breakdown
-- Hands off to solution-architecture workflow (Phase 3)
+- Hands off to create-architecture workflow (Phase 3)
 - `architecture.md` - Generated by architect workflow
 - Then to implementation
 

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

@@ -390,10 +390,10 @@ Since this is a Level {{project_level}} game project, you need solutioning for p
 
 <action>Generate comprehensive checklist based on project analysis</action>
 
-### Phase 1: Solution Architecture and Engine Selection
+### Phase 1: Architecture and Engine Selection
 
 - [ ] **Run solutioning workflow** (REQUIRED)
-  - Command: `workflow solution-architecture`
+  - Command: `workflow create-architecture`
   - Input: GDD.md, bmm-workflow-status.md
   - Output: architecture.md with engine/platform specifics
   - Note: Registry.csv will provide engine-specific guidance

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

@@ -84,7 +84,7 @@
 
 ### If Level 3-4:
 
-- [ ] PRD provides sufficient context for solution-architecture workflow
+- [ ] PRD provides sufficient context for create-architecture workflow
 - [ ] Epic structure supports phased delivery approach
 - [ ] Clear value delivery path through epic sequence
 

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

@@ -438,7 +438,7 @@ For each epic from the epic list, expand with full story details:
 {{#if project_level >= 3}}
 
 - Review PRD and epics with stakeholders
-- **Next:** Run `solution-architecture` for full technical design
+- **Next:** Run `create-architecture` for full technical design
 - Then proceed to implementation
   {{/if}}
 

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

@@ -1,6 +1,6 @@
 # Product Requirements Document (PRD) Workflow
 name: prd
-description: "Unified PRD workflow for project levels 2-4. Produces strategic PRD and tactical epic breakdown. Hands off to solution-architecture workflow for technical design. Note: Level 0-1 use tech-spec workflow."
+description: "Unified PRD workflow for project levels 2-4. Produces strategic PRD and tactical epic breakdown. Hands off to architecture workflow for technical design. Note: Level 0-1 use tech-spec workflow."
 author: "BMad"
 
 # Critical variables from config
@@ -35,7 +35,7 @@ recommended_inputs:
 
 web_bundle:
   name: "prd"
-  description: "Unified PRD workflow for project levels 2-4. Produces strategic PRD and tactical epic breakdown. Hands off to solution-architecture workflow for technical design. Note: Level 0-1 use tech-spec workflow."
+  description: "Unified PRD workflow for project levels 2-4. Produces strategic PRD and tactical epic breakdown. Hands off to architecture workflow for technical design. Note: Level 0-1 use tech-spec workflow."
   author: "BMad"
   instructions: "bmad/bmm/workflows/2-plan-workflows/prd/instructions.md"
   web_bundle_files:

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

@@ -8,7 +8,7 @@
 <critical>The goal is ARCHITECTURAL DECISIONS that prevent AI agent conflicts, not detailed implementation specs</critical>
 <critical>Communicate all responses in {communication_language} and tailor to {user_skill_level}</critical>
 <critical>Generate all documents in {document_output_language}</critical>
-<critical>This workflow replaces solution-architecture with a conversation-driven approach</critical>
+<critical>This workflow replaces architecture with a conversation-driven approach</critical>
 
 <step n="0" goal="Validate workflow and extract project configuration">
 

src/modules/bmm/workflows/3-solutioning/architecture/readme.md

@@ -85,7 +85,7 @@ Step 12: Final review and update workflow status
 - **checklist.md** - Validation requirements for the output document
 - **architecture-template.md** - Strict format for the final document
 
-## How It's Different from Old Solution-Architecture
+## How It's Different from Old architecture
 
 | Aspect               | Old Workflow                                 | New Workflow                                    |
 | -------------------- | -------------------------------------------- | ----------------------------------------------- |
@@ -266,9 +266,9 @@ This workflow assumes:
 - AI agents need clear constraints to prevent conflicts
 - The architecture document is for agents, not humans
 
-## Migration from solution-architecture
+## Migration from architecture
 
-Projects using the old `solution-architecture` workflow should:
+Projects using the old `architecture` workflow should:
 
 1. Complete any in-progress architecture work
 2. Use `architecture` for new projects
@@ -315,4 +315,4 @@ Projects using the old `solution-architecture` workflow should:
 - Starter decisions are documented as "PROVIDED BY STARTER"
 - First implementation story uses starter initialization command
 
-  1.0.0 - Initial release replacing solution-architecture workflow
+  1.0.0 - Initial release replacing architecture workflow

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

@@ -39,7 +39,7 @@ default_output_file: "{output_folder}/architecture.md"
 
 # Workflow metadata
 version: "1.3.2"
-replaces: "solution-architecture"
+replaces: "architecture"
 paradigm: "facilitation-driven"
 execution_time: "30-90 minutes depending on user skill level"
 features:

src/modules/bmm/workflows/4-implementation/create-story/checklist.md

@@ -4,7 +4,7 @@ validation-target: 'Newly generated story markdown file'
 required-inputs:
   - 'epics.md (preferred) or PRD'
 optional-inputs:
-  - 'solution-architecture document for architecture context'
+  - 'architecture document for architecture context'
 validation-rules:
   - 'Story structure matches sections: Status, Story, Acceptance Criteria, Tasks/Subtasks, Dev Notes, Change Log, Dev Agent Record'
   - 'Dev Notes include Project Structure Notes and References subsections'

src/modules/bmm/workflows/4-implementation/create-story/instructions.md

@@ -16,7 +16,7 @@
     <action>Resolve variables from config_source: story_dir (dev_story_location), output_folder, user_name, communication_language. If story_dir missing and {{non_interactive}} == false → ASK user to provide a stories directory and update variable. If {{non_interactive}} == true and missing, HALT with a clear message.</action>
     <action>Create {{story_dir}} if it does not exist</action>
     <action>Resolve installed component paths from workflow.yaml: template, instructions, validation</action>
-    <action>Resolve recommended inputs if present: epics_file, prd_file, solution-architecture_file</action>
+    <action>Resolve recommended inputs if present: epics_file, prd_file, architecture_file</action>
   </step>
 
   <step n="2" goal="Discover and load source documents">
@@ -25,7 +25,7 @@
       1) tech_spec_file (epic-scoped)
       2) epics_file (acceptance criteria and breakdown)
       3) prd_file (business requirements and constraints)
-      4) solution-architecture_file (architecture constraints)
+      4) architecture_file (architecture constraints)
       5) Architecture docs under docs/ and output_folder/: tech-stack.md, unified-project-structure.md, coding-standards.md, testing-strategy.md, backend-architecture.md, frontend-architecture.md, data-models.md, database-schema.md, rest-api-spec.md, external-apis.md (include if present)
     </action>
     <action>READ COMPLETE FILES for all items found in the prioritized set. Store content and paths for citation.</action>
@@ -69,7 +69,7 @@
 
   <step n="4" goal="Extract requirements and derive story statement">
     <action>From tech_spec_file (preferred) or epics_file: extract epic {{epic_num}} title/summary, acceptance criteria for the next story, and any component references. If not present, fall back to PRD sections mapping to this epic/story.</action>
-    <action>From solution-architecture and architecture docs: extract constraints, patterns, component boundaries, and testing guidance relevant to the extracted ACs. ONLY capture information that directly informs implementation of this story.</action>
+    <action>From architecture and architecture docs: extract constraints, patterns, component boundaries, and testing guidance relevant to the extracted ACs. ONLY capture information that directly informs implementation of this story.</action>
     <action>Derive a clear user story statement (role, action, benefit) grounded strictly in the above sources. If ambiguous and {{non_interactive}} == false → ASK user to clarify. If {{non_interactive}} == true → generate the best grounded statement WITHOUT inventing domain facts.</action>
     <template-output file="{default_output_file}">requirements_context_summary</template-output>
   </step>

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

@@ -22,7 +22,7 @@ variables:
   story_dir: "{config_source}:dev_story_location" # Directory where stories are stored
   epics_file: "{output_folder}/epics.md" # Preferred source for epic/story breakdown
   prd_file: "{output_folder}/PRD.md" # Fallback for requirements
-  solution-architecture_file: "{output_folder}/architecture.md" # Optional architecture context
+  architecture_file: "{output_folder}/architecture.md" # Optional architecture context
   tech_spec_file: "" # Will be auto-discovered from docs as tech-spec-epic-{{epic_num}}-*.md
   tech_spec_search_dir: "{project-root}/docs"
   tech_spec_glob_template: "tech-spec-epic-{{epic_num}}*.md"
@@ -44,6 +44,6 @@ default_output_file: "{story_dir}/story-{{epic_num}}.{{story_num}}.md"
 recommended_inputs:
   - epics: "Epic breakdown (epics.md)"
   - prd: "PRD document"
-  - solution-architecture: "Solution Architecture (optional)"
+  - architecture: "Architecture (optional)"
 
 web_bundle: false

src/modules/bmm/workflows/4-implementation/epic-tech-context/README.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-Generate a comprehensive Technical Specification for a single epic from PRD, Epics file and Solution Architecture to produce a document with full acceptance criteria and traceability mapping. Creates detailed implementation guidance that bridges business requirements with technical execution.
+Generate a comprehensive Technical Specification for a single epic from PRD, Epics file and Architecture to produce a document with full acceptance criteria and traceability mapping. Creates detailed implementation guidance that bridges business requirements with technical execution.
 
 ## Key Features
 
@@ -35,7 +35,7 @@ workflow tech-spec --input PRD.md --input architecture.md --input front-end-spec
 
 - **output_folder**: Location for generated technical specification
 - **epic_id**: Used in output filename (extracted from PRD or prompted)
-- **recommended_inputs**: PRD, solution-architecture, front-end spec, brownfield notes
+- **recommended_inputs**: PRD, architecture, front-end spec, brownfield notes
 
 ## Workflow Structure
 
@@ -104,7 +104,7 @@ tech-spec/
 ### Output Structure
 
 1. **Overview and Scope** - Project context and boundaries
-2. **System Architecture Alignment** - Connection to solution-architecture
+2. **System Architecture Alignment** - Connection to architecture
 3. **Detailed Design** - Services, data models, APIs, and workflows
 4. **Non-Functional Requirements** - Performance, security, reliability, observability
 5. **Dependencies and Integrations** - External systems and technical dependencies
@@ -116,7 +116,7 @@ tech-spec/
 ## Requirements
 
 - **PRD Document**: Product Requirements Document with clear acceptance criteria
-- **Architecture Document**: solution-architecture or technical design
+- **Architecture Document**: architecture or technical design
 - **Repository Access**: For dependency analysis and framework detection
 - **Epic Context**: Clear epic identification and scope definition
 

src/modules/bmm/workflows/4-implementation/epic-tech-context/instructions.md

@@ -30,11 +30,11 @@
 Status file shows project_level = {{project_level}}.
 
 Tech-spec workflow is typically only needed for Level 3-4 projects.
-For Level 0-2, solution-architecture usually generates tech specs automatically.
+For Level 0-2, architecture usually generates tech specs automatically.
 
 Options:
 1. Continue anyway (manual tech spec generation)
-2. Exit (check if solution-architecture already generated tech specs)
+2. Exit (check if architecture already generated tech specs)
 3. Run workflow-status to verify project configuration
 
 What would you like to do?</ask>
@@ -47,7 +47,7 @@ What would you like to do?</ask>
 
 The status file tracks progress across all workflows and stores project configuration.
 
-Note: This workflow is typically invoked automatically by solution-architecture, or manually for JIT epic tech specs.
+Note: This workflow is typically invoked automatically by architecture, or manually for JIT epic tech specs.
 
 Options:
 1. Run workflow-status first to create the status file (recommended)

src/modules/bmm/workflows/README.md

@@ -174,7 +174,7 @@ workflow-status determines routing:
     └─→ Level 3-4 → bmad pm prd
         └─→ Validates status file + level
         └─→ Generates PRD.md + epics.md
-        └─→ Then: Phase 3 (solution-architecture)
+        └─→ Then: Phase 3 (architecture)
         └─→ Then: Phase 4 (implementation)
 
     GAME PROJECTS:
@@ -475,7 +475,7 @@ bmad architect tech-spec # Level 0-1 software projects
 bmad pm gdd             # Game projects
 
 # Phase 3: Solutioning (L3-4)
-bmad architect solution-architecture
+bmad architect architecture
 bmad architect tech-spec  # Per epic, JIT
 
 # Phase 4: Implementation

src/modules/bmm/workflows/testarch/framework/README.md

@@ -141,7 +141,7 @@ Automatically consults TEA knowledge base:
 
 **Coordinates with:**
 
-- **solution-architecture** (Phase 3): Aligns test structure with system architecture
+- **architecture** (Phase 3): Aligns test structure with system architecture
 - **tech-spec**: Uses technical specifications to inform test configuration
 
 **Updates:**

src/modules/bmm/workflows/testarch/test-design/README.md

@@ -305,7 +305,7 @@ Automatically consults TEA knowledge base:
 **Before test-design:**
 
 - **plan-project** (Phase 2): Creates PRD and epics
-- **solution-architecture** (Phase 3): Defines technical approach
+- **architecture** (Phase 3): Defines technical approach
 - **tech-spec** (Phase 3): Implementation details
 
 **After test-design:**

src/modules/bmm/workflows/workflow-status/init/instructions.md

@@ -9,7 +9,7 @@
 <step n="1" goal="Scan for existing work">
 <action>Search {output_folder}/ for existing BMM artifacts:</action>
 - PRD files (*prd*.md)
-- Architecture docs (architecture*.md, solution-architecture*.md, architecture/*)
+- Architecture docs (architecture*.md, architecture*.md, architecture/*)
 - Briefs (*brief*.md)
 - Brainstorming docs (brainstorm*.md)
 - Research docs (*research*.md)

src/modules/bmm/workflows/workflow-status/project-levels.yaml

@@ -31,7 +31,7 @@ levels:
     title: "Complex System"
     stories: "12-40 stories"
     description: "Subsystems, integrations, full architecture"
-    documentation: "PRD + solution architecture + JIT tech specs"
+    documentation: "PRD + architecture + JIT tech specs"
     architecture: true
 
   4: