architecture name standardization
This commit is contained in:
Brian Madison
Dave Dittrich
parent
f0a60e55f3
commit
569e21ae8f
|
|
@ -207,7 +207,7 @@ User runs: npm run install:bmad
|
|||
|
||||
---
|
||||
|
||||
## Proposed Solution Architecture
|
||||
## Proposed Architecture
|
||||
|
||||
### New Command: `install-module`
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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}}
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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">
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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'
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:**
|
||||
|
|
|
|||
|
|
@ -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:**
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
Loading…
Reference in New Issue