bmad初始化
This commit is contained in:
1
bmad/bmm/workflows/3-solutioning/README.md
Normal file
1
bmad/bmm/workflows/3-solutioning/README.md
Normal file
@@ -0,0 +1 @@
|
||||
New Doc Incoming...
|
||||
318
bmad/bmm/workflows/3-solutioning/architecture/README.md
Normal file
318
bmad/bmm/workflows/3-solutioning/architecture/README.md
Normal file
@@ -0,0 +1,318 @@
|
||||
# Decision Architecture Workflow
|
||||
|
||||
## Overview
|
||||
|
||||
The Decision Architecture workflow is a complete reimagining of how architectural decisions are made in the BMAD Method. Instead of template-driven documentation, this workflow facilitates an intelligent conversation that produces a **decision-focused architecture document** optimized for preventing AI agent conflicts during implementation.
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
**The Problem**: When multiple AI agents implement different parts of a system, they make conflicting technical decisions leading to incompatible implementations.
|
||||
|
||||
**The Solution**: A "consistency contract" that documents all critical technical decisions upfront, ensuring every agent follows the same patterns and uses the same technologies.
|
||||
|
||||
## Key Features
|
||||
|
||||
### 1. Starter Template Intelligence ⭐ NEW
|
||||
|
||||
- Discovers relevant starter templates (create-next-app, create-t3-app, etc.)
|
||||
- Considers UX requirements when selecting templates (animations, accessibility, etc.)
|
||||
- Searches for current CLI options and defaults
|
||||
- Documents decisions made BY the starter template
|
||||
- Makes remaining architectural decisions around the starter foundation
|
||||
- First implementation story becomes "initialize with starter command"
|
||||
|
||||
### 2. Adaptive Facilitation
|
||||
|
||||
- Adjusts conversation style based on user skill level (beginner/intermediate/expert)
|
||||
- Experts get rapid, technical discussions
|
||||
- Beginners receive education and protection from complexity
|
||||
- Everyone produces the same high-quality output
|
||||
|
||||
### 3. Dynamic Version Verification
|
||||
|
||||
- NEVER trusts hardcoded version numbers
|
||||
- Uses WebSearch to find current stable versions
|
||||
- Verifies versions during the conversation
|
||||
- Documents only verified, current versions
|
||||
|
||||
### 4. Intelligent Discovery
|
||||
|
||||
- No rigid project type templates
|
||||
- Analyzes PRD to identify which decisions matter for THIS project
|
||||
- Uses knowledge base of decisions and patterns
|
||||
- Scales to infinite project types
|
||||
|
||||
### 5. Collaborative Decision Making
|
||||
|
||||
- Facilitates discussion for each critical decision
|
||||
- Presents options with trade-offs
|
||||
- Integrates advanced elicitation for innovative approaches
|
||||
- Ensures decisions are coherent and compatible
|
||||
|
||||
### 6. Consistent Output
|
||||
|
||||
- Structured decision collection during conversation
|
||||
- Strict document generation from collected decisions
|
||||
- Validated against hard requirements
|
||||
- Optimized for AI agent consumption
|
||||
|
||||
## Workflow Structure
|
||||
|
||||
```
|
||||
Step 0: Validate workflow and extract project configuration
|
||||
Step 0.5: Validate workflow sequencing
|
||||
Step 1: Load PRD and understand project context
|
||||
Step 2: Discover and evaluate starter templates ⭐ NEW
|
||||
Step 3: Adapt facilitation style and identify remaining decisions
|
||||
Step 4: Facilitate collaborative decision making (with version verification)
|
||||
Step 5: Address cross-cutting concerns
|
||||
Step 6: Define project structure and boundaries
|
||||
Step 7: Design novel architectural patterns (when needed) ⭐ NEW
|
||||
Step 8: Define implementation patterns to prevent agent conflicts
|
||||
Step 9: Validate architectural coherence
|
||||
Step 10: Generate decision architecture document (with initialization commands)
|
||||
Step 11: Validate document completeness
|
||||
Step 12: Final review and update workflow status
|
||||
```
|
||||
|
||||
## Files in This Workflow
|
||||
|
||||
- **workflow.yaml** - Configuration and metadata
|
||||
- **instructions.md** - The adaptive facilitation flow
|
||||
- **decision-catalog.yaml** - Knowledge base of all architectural decisions
|
||||
- **architecture-patterns.yaml** - Common patterns identified from requirements
|
||||
- **pattern-categories.csv** - Pattern principles that teach LLM what needs defining
|
||||
- **checklist.md** - Validation requirements for the output document
|
||||
- **architecture-template.md** - Strict format for the final document
|
||||
|
||||
## How It's Different from Old architecture
|
||||
|
||||
| Aspect | Old Workflow | New Workflow |
|
||||
| -------------------- | -------------------------------------------- | ----------------------------------------------- |
|
||||
| **Approach** | Template-driven | Conversation-driven |
|
||||
| **Project Types** | 11 rigid types with 22+ files | Infinite flexibility with intelligent discovery |
|
||||
| **User Interaction** | Output sections with "Continue?" | Collaborative decision facilitation |
|
||||
| **Skill Adaptation** | One-size-fits-all | Adapts to beginner/intermediate/expert |
|
||||
| **Decision Making** | Late in process (Step 5) | Upfront and central focus |
|
||||
| **Output** | Multiple documents including faux tech-specs | Single decision-focused architecture |
|
||||
| **Time** | Confusing and slow | 30-90 minutes depending on skill level |
|
||||
| **Elicitation** | Never used | Integrated at decision points |
|
||||
|
||||
## Expected Inputs
|
||||
|
||||
- **PRD** (Product Requirements Document) with:
|
||||
- Functional Requirements
|
||||
- Non-Functional Requirements
|
||||
- Performance and compliance needs
|
||||
|
||||
- **Epics** file with:
|
||||
- User stories
|
||||
- Acceptance criteria
|
||||
- Dependencies
|
||||
|
||||
- **UX Spec** (Optional but valuable) with:
|
||||
- Interface designs and interaction patterns
|
||||
- Accessibility requirements (WCAG levels)
|
||||
- Animation and transition needs
|
||||
- Platform-specific UI requirements
|
||||
- Performance expectations for interactions
|
||||
|
||||
## Output Document
|
||||
|
||||
A single `architecture.md` file containing:
|
||||
|
||||
- Executive summary (2-3 sentences)
|
||||
- Project initialization command (if using starter template)
|
||||
- Decision summary table with verified versions and epic mapping
|
||||
- Complete project structure
|
||||
- Integration specifications
|
||||
- Consistency rules for AI agents
|
||||
|
||||
## How Novel Pattern Design Works
|
||||
|
||||
Step 7 handles unique or complex patterns that need to be INVENTED:
|
||||
|
||||
1. **Detection**:
|
||||
The workflow analyzes the PRD for concepts that don't have standard solutions:
|
||||
- Novel interaction patterns (e.g., "swipe to match" when Tinder doesn't exist)
|
||||
- Complex multi-epic workflows (e.g., "viral invitation system")
|
||||
- Unique data relationships (e.g., "social graph" before Facebook)
|
||||
- New paradigms (e.g., "ephemeral messages" before Snapchat)
|
||||
|
||||
2. **Design Collaboration**:
|
||||
Instead of just picking technologies, the workflow helps DESIGN the solution:
|
||||
- Identifies the core problem to solve
|
||||
- Explores different approaches with the user
|
||||
- Documents how components interact
|
||||
- Creates sequence diagrams for complex flows
|
||||
- Uses elicitation to find innovative solutions
|
||||
|
||||
3. **Documentation**:
|
||||
Novel patterns become part of the architecture with:
|
||||
- Pattern name and purpose
|
||||
- Component interactions
|
||||
- Data flow diagrams
|
||||
- Which epics/stories are affected
|
||||
- Implementation guidance for agents
|
||||
|
||||
4. **Example**:
|
||||
```
|
||||
PRD: "Users can create 'circles' of friends with overlapping membership"
|
||||
↓
|
||||
Workflow detects: This is a novel social structure pattern
|
||||
↓
|
||||
Designs with user: Circle membership model, permission cascading, UI patterns
|
||||
↓
|
||||
Documents: "Circle Pattern" with component design and data flow
|
||||
↓
|
||||
All agents understand how to implement circle-related features consistently
|
||||
```
|
||||
|
||||
## How Implementation Patterns Work
|
||||
|
||||
Step 8 prevents agent conflicts by defining patterns for consistency:
|
||||
|
||||
1. **The Core Principle**:
|
||||
|
||||
> "Any time multiple agents might make the SAME decision DIFFERENTLY, that's a pattern to capture"
|
||||
|
||||
The LLM asks: "What could an agent encounter where they'd have to guess?"
|
||||
|
||||
2. **Pattern Categories** (principles, not prescriptions):
|
||||
- **Naming**: How things are named (APIs, database fields, files)
|
||||
- **Structure**: How things are organized (folders, modules, layers)
|
||||
- **Format**: How data is formatted (JSON structures, responses)
|
||||
- **Communication**: How components talk (events, messages, protocols)
|
||||
- **Lifecycle**: How states change (workflows, transitions)
|
||||
- **Location**: Where things go (URLs, paths, storage)
|
||||
- **Consistency**: Cross-cutting concerns (dates, errors, logs)
|
||||
|
||||
3. **LLM Intelligence**:
|
||||
- Uses the principle to identify patterns beyond the 7 categories
|
||||
- Figures out what specific patterns matter for chosen tech
|
||||
- Only asks about patterns that could cause conflicts
|
||||
- Skips obvious patterns that the tech choice determines
|
||||
|
||||
4. **Example**:
|
||||
```
|
||||
Tech chosen: REST API + PostgreSQL + React
|
||||
↓
|
||||
LLM identifies needs:
|
||||
- REST: URL structure, response format, status codes
|
||||
- PostgreSQL: table naming, column naming, FK patterns
|
||||
- React: component structure, state management, test location
|
||||
↓
|
||||
Facilitates each with user
|
||||
↓
|
||||
Documents as Implementation Patterns in architecture
|
||||
```
|
||||
|
||||
## How Starter Templates Work
|
||||
|
||||
When the workflow detects a project type that has a starter template:
|
||||
|
||||
1. **Discovery**: Searches for relevant starter templates based on PRD
|
||||
2. **Investigation**: Looks up current CLI options and defaults
|
||||
3. **Presentation**: Shows user what the starter provides
|
||||
4. **Integration**: Documents starter decisions as "PROVIDED BY STARTER"
|
||||
5. **Continuation**: Only asks about decisions NOT made by starter
|
||||
6. **Documentation**: Includes exact initialization command in architecture
|
||||
|
||||
### Example Flow
|
||||
|
||||
```
|
||||
PRD says: "Next.js web application with authentication"
|
||||
↓
|
||||
Workflow finds: create-next-app and create-t3-app
|
||||
↓
|
||||
User chooses: create-t3-app (includes auth setup)
|
||||
↓
|
||||
Starter provides: Next.js, TypeScript, tRPC, Prisma, NextAuth, Tailwind
|
||||
↓
|
||||
Workflow only asks about: Database choice, deployment target, additional services
|
||||
↓
|
||||
First story becomes: "npx create t3-app@latest my-app --trpc --nextauth --prisma"
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
# In your BMAD-enabled project
|
||||
workflow architecture
|
||||
```
|
||||
|
||||
The AI agent will:
|
||||
|
||||
1. Load your PRD and epics
|
||||
2. Identify critical decisions needed
|
||||
3. Facilitate discussion on each decision
|
||||
4. Generate a comprehensive architecture document
|
||||
5. Validate completeness
|
||||
|
||||
## Design Principles
|
||||
|
||||
1. **Facilitation over Prescription** - Guide users to good decisions rather than imposing templates
|
||||
2. **Intelligence over Templates** - Use AI understanding rather than rigid structures
|
||||
3. **Decisions over Details** - Focus on what prevents agent conflicts, not implementation minutiae
|
||||
4. **Adaptation over Uniformity** - Meet users where they are while ensuring quality output
|
||||
5. **Collaboration over Output** - The conversation matters as much as the document
|
||||
|
||||
## For Developers
|
||||
|
||||
This workflow assumes:
|
||||
|
||||
- Single developer + AI agents (not teams)
|
||||
- Speed matters (decisions in minutes, not days)
|
||||
- AI agents need clear constraints to prevent conflicts
|
||||
- The architecture document is for agents, not humans
|
||||
|
||||
## Migration from architecture
|
||||
|
||||
Projects using the old `architecture` workflow should:
|
||||
|
||||
1. Complete any in-progress architecture work
|
||||
2. Use `architecture` for new projects
|
||||
3. The old workflow remains available but is deprecated
|
||||
|
||||
## Version
|
||||
|
||||
1.3.2 - UX specification integration and fuzzy file matching
|
||||
|
||||
- Added UX spec as optional input with fuzzy file matching
|
||||
- Updated workflow.yaml with input file references
|
||||
- Starter template selection now considers UX requirements
|
||||
- Added UX alignment validation to checklist
|
||||
- Instructions use variable references for flexible file names
|
||||
|
||||
1.3.1 - Workflow refinement and standardization
|
||||
|
||||
- Added workflow status checking at start (Steps 0 and 0.5)
|
||||
- Added workflow status updating at end (Step 12)
|
||||
- Reorganized step numbering for clarity (removed fractional steps)
|
||||
- Enhanced with intent-based approach throughout
|
||||
- Improved cohesiveness across all workflow components
|
||||
|
||||
1.3.0 - Novel pattern design for unique architectures
|
||||
|
||||
- Added novel pattern design (now Step 7, formerly Step 5.3)
|
||||
- Detects novel concepts in PRD that need architectural invention
|
||||
- Facilitates design collaboration with sequence diagrams
|
||||
- Uses elicitation for innovative approaches
|
||||
- Documents custom patterns for multi-epic consistency
|
||||
|
||||
1.2.0 - Implementation patterns for agent consistency
|
||||
|
||||
- Added implementation patterns (now Step 8, formerly Step 5.5)
|
||||
- Created principle-based pattern-categories.csv (7 principles, not 118 prescriptions)
|
||||
- Core principle: "What could agents decide differently?"
|
||||
- LLM uses principle to identify patterns beyond the categories
|
||||
- Prevents agent conflicts through intelligent pattern discovery
|
||||
|
||||
1.1.0 - Enhanced with starter template discovery and version verification
|
||||
|
||||
- Added intelligent starter template detection and integration (now Step 2)
|
||||
- Added dynamic version verification via web search
|
||||
- Starter decisions are documented as "PROVIDED BY STARTER"
|
||||
- First implementation story uses starter initialization command
|
||||
|
||||
1.0.0 - Initial release replacing architecture workflow
|
||||
@@ -0,0 +1,347 @@
|
||||
# Architecture Patterns - Common patterns identified from requirements
|
||||
|
||||
requirement_patterns:
|
||||
realtime_collaboration:
|
||||
triggers:
|
||||
- "real-time"
|
||||
- "collaborative"
|
||||
- "live updates"
|
||||
- "multi-user"
|
||||
- "simultaneous editing"
|
||||
decisions_needed:
|
||||
- websocket_solution
|
||||
- conflict_resolution
|
||||
- state_synchronization
|
||||
- presence_tracking
|
||||
- optimistic_updates
|
||||
suggested_stack:
|
||||
- "Socket.io or WebSocket native"
|
||||
- "Redis for pub/sub"
|
||||
- "Operational Transforms or CRDTs for conflict resolution"
|
||||
- "PostgreSQL for persistence"
|
||||
|
||||
ecommerce:
|
||||
triggers:
|
||||
- "shopping cart"
|
||||
- "checkout"
|
||||
- "payments"
|
||||
- "inventory"
|
||||
- "product catalog"
|
||||
decisions_needed:
|
||||
- payment_processor
|
||||
- cart_persistence
|
||||
- inventory_management
|
||||
- order_workflow
|
||||
- tax_calculation
|
||||
suggested_stack:
|
||||
- "Stripe or PayPal for payments"
|
||||
- "PostgreSQL for products and orders"
|
||||
- "Redis for cart sessions"
|
||||
- "BullMQ for order processing"
|
||||
|
||||
saas_platform:
|
||||
triggers:
|
||||
- "multi-tenant"
|
||||
- "subscription"
|
||||
- "billing"
|
||||
- "team management"
|
||||
- "roles and permissions"
|
||||
decisions_needed:
|
||||
- tenancy_model
|
||||
- subscription_billing
|
||||
- permission_system
|
||||
- team_collaboration
|
||||
- usage_tracking
|
||||
suggested_stack:
|
||||
- "PostgreSQL with Row Level Security"
|
||||
- "Stripe Billing for subscriptions"
|
||||
- "RBAC or ABAC for permissions"
|
||||
- "NextAuth or Clerk for auth"
|
||||
|
||||
content_platform:
|
||||
triggers:
|
||||
- "CMS"
|
||||
- "blog"
|
||||
- "publishing"
|
||||
- "content management"
|
||||
- "editorial workflow"
|
||||
decisions_needed:
|
||||
- content_storage
|
||||
- rich_text_editor
|
||||
- media_handling
|
||||
- version_control
|
||||
- publishing_workflow
|
||||
suggested_stack:
|
||||
- "PostgreSQL for structured content"
|
||||
- "S3 or Cloudinary for media"
|
||||
- "Tiptap or Slate for rich text"
|
||||
- "Algolia for search"
|
||||
|
||||
data_analytics:
|
||||
triggers:
|
||||
- "dashboards"
|
||||
- "reporting"
|
||||
- "metrics"
|
||||
- "analytics"
|
||||
- "data visualization"
|
||||
decisions_needed:
|
||||
- data_warehouse
|
||||
- etl_pipeline
|
||||
- visualization_library
|
||||
- query_optimization
|
||||
- caching_strategy
|
||||
suggested_stack:
|
||||
- "PostgreSQL or ClickHouse"
|
||||
- "Apache Airflow or Temporal for ETL"
|
||||
- "Chart.js or D3 for visualization"
|
||||
- "Redis for query caching"
|
||||
|
||||
social_platform:
|
||||
triggers:
|
||||
- "social network"
|
||||
- "feed"
|
||||
- "following"
|
||||
- "likes"
|
||||
- "comments"
|
||||
decisions_needed:
|
||||
- graph_relationships
|
||||
- feed_algorithm
|
||||
- notification_system
|
||||
- content_moderation
|
||||
- privacy_controls
|
||||
suggested_stack:
|
||||
- "PostgreSQL with graph extensions or Neo4j"
|
||||
- "Redis for feed caching"
|
||||
- "Elasticsearch for user search"
|
||||
- "WebSockets for notifications"
|
||||
|
||||
marketplace:
|
||||
triggers:
|
||||
- "marketplace"
|
||||
- "vendors"
|
||||
- "buyers and sellers"
|
||||
- "transactions"
|
||||
- "escrow"
|
||||
decisions_needed:
|
||||
- payment_splitting
|
||||
- escrow_handling
|
||||
- vendor_management
|
||||
- dispute_resolution
|
||||
- commission_model
|
||||
suggested_stack:
|
||||
- "Stripe Connect for payments"
|
||||
- "PostgreSQL for transactions"
|
||||
- "BullMQ for async processing"
|
||||
- "S3 for vendor assets"
|
||||
|
||||
streaming_platform:
|
||||
triggers:
|
||||
- "video streaming"
|
||||
- "live streaming"
|
||||
- "media delivery"
|
||||
- "broadcast"
|
||||
decisions_needed:
|
||||
- video_encoding
|
||||
- cdn_strategy
|
||||
- streaming_protocol
|
||||
- bandwidth_optimization
|
||||
- drm_protection
|
||||
suggested_stack:
|
||||
- "AWS MediaConvert or Mux"
|
||||
- "CloudFront or Fastly CDN"
|
||||
- "HLS or DASH protocol"
|
||||
- "S3 for video storage"
|
||||
|
||||
iot_platform:
|
||||
triggers:
|
||||
- "IoT"
|
||||
- "sensors"
|
||||
- "device management"
|
||||
- "telemetry"
|
||||
- "edge computing"
|
||||
decisions_needed:
|
||||
- message_protocol
|
||||
- time_series_database
|
||||
- device_authentication
|
||||
- data_ingestion
|
||||
- edge_processing
|
||||
suggested_stack:
|
||||
- "MQTT or CoAP protocol"
|
||||
- "TimescaleDB or InfluxDB"
|
||||
- "Apache Kafka for ingestion"
|
||||
- "Grafana for monitoring"
|
||||
|
||||
ai_application:
|
||||
triggers:
|
||||
- "machine learning"
|
||||
- "AI features"
|
||||
- "LLM integration"
|
||||
- "computer vision"
|
||||
- "NLP"
|
||||
decisions_needed:
|
||||
- model_serving
|
||||
- vector_database
|
||||
- prompt_management
|
||||
- token_optimization
|
||||
- fallback_strategy
|
||||
suggested_stack:
|
||||
- "OpenAI or Anthropic API"
|
||||
- "Pinecone or pgvector for embeddings"
|
||||
- "Redis for prompt caching"
|
||||
- "Langchain or LlamaIndex"
|
||||
|
||||
# Quality attribute patterns
|
||||
quality_attributes:
|
||||
high_availability:
|
||||
triggers:
|
||||
- "99.9% uptime"
|
||||
- "high availability"
|
||||
- "fault tolerance"
|
||||
- "disaster recovery"
|
||||
architectural_needs:
|
||||
- load_balancing
|
||||
- database_replication
|
||||
- health_checks
|
||||
- circuit_breakers
|
||||
- graceful_degradation
|
||||
|
||||
high_performance:
|
||||
triggers:
|
||||
- "millisecond response"
|
||||
- "high throughput"
|
||||
- "low latency"
|
||||
- "performance critical"
|
||||
architectural_needs:
|
||||
- caching_layers
|
||||
- database_optimization
|
||||
- cdn_strategy
|
||||
- code_splitting
|
||||
- lazy_loading
|
||||
|
||||
high_security:
|
||||
triggers:
|
||||
- "compliance"
|
||||
- "HIPAA"
|
||||
- "GDPR"
|
||||
- "financial data"
|
||||
- "PCI DSS"
|
||||
architectural_needs:
|
||||
- encryption_at_rest
|
||||
- encryption_in_transit
|
||||
- audit_logging
|
||||
- access_controls
|
||||
- data_isolation
|
||||
|
||||
scalability:
|
||||
triggers:
|
||||
- "millions of users"
|
||||
- "elastic scale"
|
||||
- "global reach"
|
||||
- "viral growth"
|
||||
architectural_needs:
|
||||
- horizontal_scaling
|
||||
- database_sharding
|
||||
- microservices
|
||||
- queue_systems
|
||||
- auto_scaling
|
||||
|
||||
# Integration patterns
|
||||
integration_requirements:
|
||||
payment_processing:
|
||||
common_choices:
|
||||
- "Stripe - most developer friendly"
|
||||
- "PayPal - widest consumer adoption"
|
||||
- "Square - best for in-person + online"
|
||||
considerations:
|
||||
- transaction_fees
|
||||
- international_support
|
||||
- subscription_handling
|
||||
- marketplace_capabilities
|
||||
|
||||
email_service:
|
||||
common_choices:
|
||||
- "Resend - modern, developer friendly"
|
||||
- "SendGrid - mature, scalable"
|
||||
- "Amazon SES - cost effective at scale"
|
||||
- "Postmark - transactional focus"
|
||||
considerations:
|
||||
- deliverability
|
||||
- template_management
|
||||
- analytics_needs
|
||||
- cost_per_email
|
||||
|
||||
sms_notifications:
|
||||
common_choices:
|
||||
- "Twilio - most comprehensive"
|
||||
- "Amazon SNS - AWS integrated"
|
||||
- "Vonage - competitive pricing"
|
||||
considerations:
|
||||
- international_coverage
|
||||
- delivery_rates
|
||||
- two_way_messaging
|
||||
- cost_per_message
|
||||
|
||||
authentication_providers:
|
||||
social_providers:
|
||||
- "Google - highest adoption"
|
||||
- "GitHub - developer focused"
|
||||
- "Microsoft - enterprise"
|
||||
- "Apple - iOS users"
|
||||
enterprise_providers:
|
||||
- "SAML 2.0"
|
||||
- "OAuth 2.0"
|
||||
- "OpenID Connect"
|
||||
- "Active Directory"
|
||||
|
||||
# Decision heuristics
|
||||
decision_rules:
|
||||
database_selection:
|
||||
if_requirements_include:
|
||||
- complex_relationships: "PostgreSQL"
|
||||
- flexible_schema: "MongoDB"
|
||||
- time_series: "TimescaleDB"
|
||||
- graph_data: "Neo4j or PostgreSQL with extensions"
|
||||
- key_value: "Redis"
|
||||
- wide_column: "Cassandra"
|
||||
|
||||
api_pattern_selection:
|
||||
if_requirements_include:
|
||||
- simple_crud: "REST"
|
||||
- complex_queries: "GraphQL"
|
||||
- type_safety_critical: "tRPC"
|
||||
- microservices: "gRPC"
|
||||
- public_api: "REST with OpenAPI"
|
||||
|
||||
deployment_selection:
|
||||
if_requirements_include:
|
||||
- nextjs_only: "Vercel"
|
||||
- complex_infrastructure: "AWS"
|
||||
- quick_prototype: "Railway"
|
||||
- global_edge: "Fly.io"
|
||||
- kubernetes_needed: "GCP or AWS EKS"
|
||||
|
||||
# Anti-patterns to avoid
|
||||
anti_patterns:
|
||||
overengineering:
|
||||
signs:
|
||||
- "Microservices for < 10k users"
|
||||
- "Kubernetes for single app"
|
||||
- "GraphQL for 5 endpoints"
|
||||
- "Event sourcing for CRUD app"
|
||||
recommendation: "Start simple, evolve as needed"
|
||||
|
||||
underengineering:
|
||||
signs:
|
||||
- "No authentication strategy"
|
||||
- "No error handling plan"
|
||||
- "No monitoring approach"
|
||||
- "No backup strategy"
|
||||
recommendation: "Cover the fundamentals"
|
||||
|
||||
technology_soup:
|
||||
signs:
|
||||
- "5+ different databases"
|
||||
- "Multiple frontend frameworks"
|
||||
- "Inconsistent patterns"
|
||||
- "Too many languages"
|
||||
recommendation: "Maintain consistency"
|
||||
@@ -0,0 +1,103 @@
|
||||
# Decision Architecture
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
{{project_initialization_section}}
|
||||
|
||||
## Decision Summary
|
||||
|
||||
| Category | Decision | Version | Affects Epics | Rationale |
|
||||
| -------- | -------- | ------- | ------------- | --------- |
|
||||
|
||||
{{decision_table_rows}}
|
||||
|
||||
## Project Structure
|
||||
|
||||
```
|
||||
{{project_root}}/
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## Epic to Architecture Mapping
|
||||
|
||||
{{epic_mapping_table}}
|
||||
|
||||
## Technology Stack Details
|
||||
|
||||
### Core Technologies
|
||||
|
||||
{{core_stack_details}}
|
||||
|
||||
### Integration Points
|
||||
|
||||
{{integration_details}}
|
||||
|
||||
{{novel_pattern_designs_section}}
|
||||
|
||||
## Implementation Patterns
|
||||
|
||||
These patterns ensure consistent implementation across all AI agents:
|
||||
|
||||
{{implementation_patterns}}
|
||||
|
||||
## Consistency Rules
|
||||
|
||||
### Naming Conventions
|
||||
|
||||
{{naming_conventions}}
|
||||
|
||||
### Code Organization
|
||||
|
||||
{{code_organization_patterns}}
|
||||
|
||||
### Error Handling
|
||||
|
||||
{{error_handling_approach}}
|
||||
|
||||
### Logging Strategy
|
||||
|
||||
{{logging_approach}}
|
||||
|
||||
## Data Architecture
|
||||
|
||||
{{data_models_and_relationships}}
|
||||
|
||||
## API Contracts
|
||||
|
||||
{{api_specifications}}
|
||||
|
||||
## Security Architecture
|
||||
|
||||
{{security_approach}}
|
||||
|
||||
## Performance Considerations
|
||||
|
||||
{{performance_strategies}}
|
||||
|
||||
## Deployment Architecture
|
||||
|
||||
{{deployment_approach}}
|
||||
|
||||
## Development Environment
|
||||
|
||||
### Prerequisites
|
||||
|
||||
{{development_prerequisites}}
|
||||
|
||||
### Setup Commands
|
||||
|
||||
```bash
|
||||
{{setup_commands}}
|
||||
```
|
||||
|
||||
## Architecture Decision Records (ADRs)
|
||||
|
||||
{{key_architecture_decisions}}
|
||||
|
||||
---
|
||||
|
||||
_Generated by BMAD Decision Architecture Workflow v1.0_
|
||||
_Date: {{date}}_
|
||||
_For: {{user_name}}_
|
||||
244
bmad/bmm/workflows/3-solutioning/architecture/checklist.md
Normal file
244
bmad/bmm/workflows/3-solutioning/architecture/checklist.md
Normal file
@@ -0,0 +1,244 @@
|
||||
# Architecture Document Validation Checklist
|
||||
|
||||
**Purpose**: Validate the architecture document itself is complete, implementable, and provides clear guidance for AI agents.
|
||||
|
||||
**Note**: This checklist validates the ARCHITECTURE DOCUMENT only. For cross-workflow validation (PRD → Architecture → Stories alignment), use the solutioning-gate-check workflow.
|
||||
|
||||
---
|
||||
|
||||
## 1. Decision Completeness
|
||||
|
||||
### All Decisions Made
|
||||
|
||||
- [ ] Every critical decision category has been resolved
|
||||
- [ ] All important decision categories addressed
|
||||
- [ ] No placeholder text like "TBD", "[choose]", or "{TODO}" remains
|
||||
- [ ] Optional decisions either resolved or explicitly deferred with rationale
|
||||
|
||||
### Decision Coverage
|
||||
|
||||
- [ ] Data persistence approach decided
|
||||
- [ ] API pattern chosen
|
||||
- [ ] Authentication/authorization strategy defined
|
||||
- [ ] Deployment target selected
|
||||
- [ ] All functional requirements have architectural support
|
||||
|
||||
---
|
||||
|
||||
## 2. Version Specificity
|
||||
|
||||
### Technology Versions
|
||||
|
||||
- [ ] Every technology choice includes a specific version number
|
||||
- [ ] Version numbers are current (verified via WebSearch, not hardcoded)
|
||||
- [ ] Compatible versions selected (e.g., Node.js version supports chosen packages)
|
||||
- [ ] Verification dates noted for version checks
|
||||
|
||||
### Version Verification Process
|
||||
|
||||
- [ ] WebSearch used during workflow to verify current versions
|
||||
- [ ] No hardcoded versions from decision catalog trusted without verification
|
||||
- [ ] LTS vs. latest versions considered and documented
|
||||
- [ ] Breaking changes between versions noted if relevant
|
||||
|
||||
---
|
||||
|
||||
## 3. Starter Template Integration (if applicable)
|
||||
|
||||
### Template Selection
|
||||
|
||||
- [ ] Starter template chosen (or "from scratch" decision documented)
|
||||
- [ ] Project initialization command documented with exact flags
|
||||
- [ ] Starter template version is current and specified
|
||||
- [ ] Command search term provided for verification
|
||||
|
||||
### Starter-Provided Decisions
|
||||
|
||||
- [ ] Decisions provided by starter marked as "PROVIDED BY STARTER"
|
||||
- [ ] List of what starter provides is complete
|
||||
- [ ] Remaining decisions (not covered by starter) clearly identified
|
||||
- [ ] No duplicate decisions that starter already makes
|
||||
|
||||
---
|
||||
|
||||
## 4. Novel Pattern Design (if applicable)
|
||||
|
||||
### Pattern Detection
|
||||
|
||||
- [ ] All unique/novel concepts from PRD identified
|
||||
- [ ] Patterns that don't have standard solutions documented
|
||||
- [ ] Multi-epic workflows requiring custom design captured
|
||||
|
||||
### Pattern Documentation Quality
|
||||
|
||||
- [ ] Pattern name and purpose clearly defined
|
||||
- [ ] Component interactions specified
|
||||
- [ ] Data flow documented (with sequence diagrams if complex)
|
||||
- [ ] Implementation guide provided for agents
|
||||
- [ ] Edge cases and failure modes considered
|
||||
- [ ] States and transitions clearly defined
|
||||
|
||||
### Pattern Implementability
|
||||
|
||||
- [ ] Pattern is implementable by AI agents with provided guidance
|
||||
- [ ] No ambiguous decisions that could be interpreted differently
|
||||
- [ ] Clear boundaries between components
|
||||
- [ ] Explicit integration points with standard patterns
|
||||
|
||||
---
|
||||
|
||||
## 5. Implementation Patterns
|
||||
|
||||
### Pattern Categories Coverage
|
||||
|
||||
- [ ] **Naming Patterns**: API routes, database tables, components, files
|
||||
- [ ] **Structure Patterns**: Test organization, component organization, shared utilities
|
||||
- [ ] **Format Patterns**: API responses, error formats, date handling
|
||||
- [ ] **Communication Patterns**: Events, state updates, inter-component messaging
|
||||
- [ ] **Lifecycle Patterns**: Loading states, error recovery, retry logic
|
||||
- [ ] **Location Patterns**: URL structure, asset organization, config placement
|
||||
- [ ] **Consistency Patterns**: UI date formats, logging, user-facing errors
|
||||
|
||||
### Pattern Quality
|
||||
|
||||
- [ ] Each pattern has concrete examples
|
||||
- [ ] Conventions are unambiguous (agents can't interpret differently)
|
||||
- [ ] Patterns cover all technologies in the stack
|
||||
- [ ] No gaps where agents would have to guess
|
||||
- [ ] Implementation patterns don't conflict with each other
|
||||
|
||||
---
|
||||
|
||||
## 6. Technology Compatibility
|
||||
|
||||
### Stack Coherence
|
||||
|
||||
- [ ] Database choice compatible with ORM choice
|
||||
- [ ] Frontend framework compatible with deployment target
|
||||
- [ ] Authentication solution works with chosen frontend/backend
|
||||
- [ ] All API patterns consistent (not mixing REST and GraphQL for same data)
|
||||
- [ ] Starter template compatible with additional choices
|
||||
|
||||
### Integration Compatibility
|
||||
|
||||
- [ ] Third-party services compatible with chosen stack
|
||||
- [ ] Real-time solutions (if any) work with deployment target
|
||||
- [ ] File storage solution integrates with framework
|
||||
- [ ] Background job system compatible with infrastructure
|
||||
|
||||
---
|
||||
|
||||
## 7. Document Structure
|
||||
|
||||
### Required Sections Present
|
||||
|
||||
- [ ] Executive summary exists (2-3 sentences maximum)
|
||||
- [ ] Project initialization section (if using starter template)
|
||||
- [ ] Decision summary table with ALL required columns:
|
||||
- Category
|
||||
- Decision
|
||||
- Version
|
||||
- Rationale
|
||||
- [ ] Project structure section shows complete source tree
|
||||
- [ ] Implementation patterns section comprehensive
|
||||
- [ ] Novel patterns section (if applicable)
|
||||
|
||||
### Document Quality
|
||||
|
||||
- [ ] Source tree reflects actual technology decisions (not generic)
|
||||
- [ ] Technical language used consistently
|
||||
- [ ] Tables used instead of prose where appropriate
|
||||
- [ ] No unnecessary explanations or justifications
|
||||
- [ ] Focused on WHAT and HOW, not WHY (rationale is brief)
|
||||
|
||||
---
|
||||
|
||||
## 8. AI Agent Clarity
|
||||
|
||||
### Clear Guidance for Agents
|
||||
|
||||
- [ ] No ambiguous decisions that agents could interpret differently
|
||||
- [ ] Clear boundaries between components/modules
|
||||
- [ ] Explicit file organization patterns
|
||||
- [ ] Defined patterns for common operations (CRUD, auth checks, etc.)
|
||||
- [ ] Novel patterns have clear implementation guidance
|
||||
- [ ] Document provides clear constraints for agents
|
||||
- [ ] No conflicting guidance present
|
||||
|
||||
### Implementation Readiness
|
||||
|
||||
- [ ] Sufficient detail for agents to implement without guessing
|
||||
- [ ] File paths and naming conventions explicit
|
||||
- [ ] Integration points clearly defined
|
||||
- [ ] Error handling patterns specified
|
||||
- [ ] Testing patterns documented
|
||||
|
||||
---
|
||||
|
||||
## 9. Practical Considerations
|
||||
|
||||
### Technology Viability
|
||||
|
||||
- [ ] Chosen stack has good documentation and community support
|
||||
- [ ] Development environment can be set up with specified versions
|
||||
- [ ] No experimental or alpha technologies for critical path
|
||||
- [ ] Deployment target supports all chosen technologies
|
||||
- [ ] Starter template (if used) is stable and well-maintained
|
||||
|
||||
### Scalability
|
||||
|
||||
- [ ] Architecture can handle expected user load
|
||||
- [ ] Data model supports expected growth
|
||||
- [ ] Caching strategy defined if performance is critical
|
||||
- [ ] Background job processing defined if async work needed
|
||||
- [ ] Novel patterns scalable for production use
|
||||
|
||||
---
|
||||
|
||||
## 10. Common Issues to Check
|
||||
|
||||
### Beginner Protection
|
||||
|
||||
- [ ] Not overengineered for actual requirements
|
||||
- [ ] Standard patterns used where possible (starter templates leveraged)
|
||||
- [ ] Complex technologies justified by specific needs
|
||||
- [ ] Maintenance complexity appropriate for team size
|
||||
|
||||
### Expert Validation
|
||||
|
||||
- [ ] No obvious anti-patterns present
|
||||
- [ ] Performance bottlenecks addressed
|
||||
- [ ] Security best practices followed
|
||||
- [ ] Future migration paths not blocked
|
||||
- [ ] Novel patterns follow architectural principles
|
||||
|
||||
---
|
||||
|
||||
## Validation Summary
|
||||
|
||||
### Document Quality Score
|
||||
|
||||
- Architecture Completeness: [Complete / Mostly Complete / Partial / Incomplete]
|
||||
- Version Specificity: [All Verified / Most Verified / Some Missing / Many Missing]
|
||||
- Pattern Clarity: [Crystal Clear / Clear / Somewhat Ambiguous / Ambiguous]
|
||||
- AI Agent Readiness: [Ready / Mostly Ready / Needs Work / Not Ready]
|
||||
|
||||
### Critical Issues Found
|
||||
|
||||
- [ ] Issue 1: **\*\***\_\_\_**\*\***
|
||||
- [ ] Issue 2: **\*\***\_\_\_**\*\***
|
||||
- [ ] Issue 3: **\*\***\_\_\_**\*\***
|
||||
|
||||
### Recommended Actions Before Implementation
|
||||
|
||||
1. ***
|
||||
2. ***
|
||||
3. ***
|
||||
|
||||
---
|
||||
|
||||
**Next Step**: Run the **solutioning-gate-check** workflow to validate alignment between PRD, Architecture, and Stories before beginning implementation.
|
||||
|
||||
---
|
||||
|
||||
_This checklist validates architecture document quality only. Use solutioning-gate-check for comprehensive readiness validation._
|
||||
@@ -0,0 +1,222 @@
|
||||
# Decision Catalog - Composability knowledge for architectural decisions
|
||||
# This provides RELATIONSHIPS and WORKFLOW LOGIC, not generic tech knowledge
|
||||
#
|
||||
# ⚠️ CRITICAL: All version/feature info MUST be verified via WebSearch during workflow
|
||||
# This file only provides: triggers, relationships (pairs_with), and opinionated stacks
|
||||
|
||||
decision_categories:
|
||||
data_persistence:
|
||||
triggers: ["database", "storage", "data model", "persistence", "state management"]
|
||||
importance: "critical"
|
||||
affects: "most epics"
|
||||
options:
|
||||
postgresql:
|
||||
pairs_with: ["Prisma ORM", "TypeORM", "Drizzle", "node-postgres"]
|
||||
mongodb:
|
||||
pairs_with: ["Mongoose", "Prisma", "MongoDB driver"]
|
||||
redis:
|
||||
pairs_with: ["ioredis", "node-redis"]
|
||||
supabase:
|
||||
pairs_with: ["@supabase/supabase-js"]
|
||||
firebase:
|
||||
pairs_with: ["firebase-admin"]
|
||||
|
||||
api_pattern:
|
||||
triggers: ["API", "client communication", "frontend backend", "service communication"]
|
||||
importance: "critical"
|
||||
affects: "all client-facing epics"
|
||||
options:
|
||||
rest:
|
||||
pairs_with: ["Express", "Fastify", "NestJS", "Hono"]
|
||||
graphql:
|
||||
pairs_with: ["Apollo Server", "GraphQL Yoga", "Mercurius"]
|
||||
trpc:
|
||||
pairs_with: ["Next.js", "React Query"]
|
||||
grpc:
|
||||
pairs_with: ["@grpc/grpc-js", "protobufjs"]
|
||||
|
||||
authentication:
|
||||
triggers: ["auth", "login", "user management", "security", "identity"]
|
||||
importance: "critical"
|
||||
affects: "security and user epics"
|
||||
options:
|
||||
nextauth:
|
||||
pairs_with: ["Next.js", "Prisma"]
|
||||
auth0:
|
||||
pairs_with: ["@auth0/nextjs-auth0"]
|
||||
clerk:
|
||||
pairs_with: ["@clerk/nextjs"]
|
||||
supabase_auth:
|
||||
pairs_with: ["@supabase/supabase-js"]
|
||||
firebase_auth:
|
||||
pairs_with: ["firebase-admin"]
|
||||
|
||||
real_time:
|
||||
triggers: ["real-time", "websocket", "live updates", "chat", "collaboration"]
|
||||
importance: "medium"
|
||||
affects: "real-time features"
|
||||
options:
|
||||
socket_io:
|
||||
pairs_with: ["Express", "socket.io-client"]
|
||||
pusher:
|
||||
pairs_with: ["pusher-js"]
|
||||
ably:
|
||||
pairs_with: ["ably"]
|
||||
supabase_realtime:
|
||||
pairs_with: ["@supabase/supabase-js"]
|
||||
firebase_realtime:
|
||||
pairs_with: ["firebase"]
|
||||
|
||||
email:
|
||||
triggers: ["email", "notifications", "transactional email"]
|
||||
importance: "medium"
|
||||
affects: "notification epics"
|
||||
options:
|
||||
resend:
|
||||
pairs_with: ["resend", "react-email"]
|
||||
sendgrid:
|
||||
pairs_with: ["@sendgrid/mail"]
|
||||
postmark:
|
||||
pairs_with: ["postmark"]
|
||||
ses:
|
||||
pairs_with: ["@aws-sdk/client-ses"]
|
||||
|
||||
file_storage:
|
||||
triggers: ["upload", "file storage", "images", "media", "CDN"]
|
||||
importance: "medium"
|
||||
affects: "media handling epics"
|
||||
options:
|
||||
s3:
|
||||
pairs_with: ["@aws-sdk/client-s3", "multer"]
|
||||
cloudinary:
|
||||
pairs_with: ["cloudinary"]
|
||||
uploadthing:
|
||||
pairs_with: ["uploadthing"]
|
||||
supabase_storage:
|
||||
pairs_with: ["@supabase/supabase-js"]
|
||||
|
||||
search:
|
||||
triggers: ["search", "full text", "elasticsearch", "algolia", "fuzzy"]
|
||||
importance: "medium"
|
||||
affects: "search and discovery epics"
|
||||
options:
|
||||
postgres_fts:
|
||||
pairs_with: ["PostgreSQL"]
|
||||
elasticsearch:
|
||||
pairs_with: ["@elastic/elasticsearch"]
|
||||
algolia:
|
||||
pairs_with: ["algoliasearch"]
|
||||
typesense:
|
||||
pairs_with: ["typesense"]
|
||||
|
||||
background_jobs:
|
||||
triggers: ["queue", "jobs", "workers", "async", "background processing", "scheduled"]
|
||||
importance: "medium"
|
||||
affects: "async processing epics"
|
||||
options:
|
||||
bullmq:
|
||||
pairs_with: ["Redis"]
|
||||
sqs:
|
||||
pairs_with: ["@aws-sdk/client-sqs"]
|
||||
temporal:
|
||||
pairs_with: ["@temporalio/client"]
|
||||
inngest:
|
||||
pairs_with: ["inngest"]
|
||||
|
||||
deployment_target:
|
||||
triggers: ["deployment", "hosting", "infrastructure", "cloud", "server"]
|
||||
importance: "high"
|
||||
affects: "all epics"
|
||||
options:
|
||||
vercel:
|
||||
pairs_with: ["Next.js", "serverless functions"]
|
||||
aws:
|
||||
pairs_with: ["any stack"]
|
||||
railway:
|
||||
pairs_with: ["any stack", "managed databases"]
|
||||
fly_io:
|
||||
pairs_with: ["Docker containers"]
|
||||
|
||||
# Opinionated stack combinations (BMM methodology)
|
||||
common_stacks:
|
||||
modern_fullstack:
|
||||
name: "Modern Full-Stack"
|
||||
components: ["Next.js", "PostgreSQL or Supabase", "Prisma ORM", "NextAuth.js", "Tailwind CSS", "TypeScript", "Vercel"]
|
||||
good_for: "Most web applications"
|
||||
|
||||
enterprise_stack:
|
||||
name: "Enterprise Stack"
|
||||
components: ["NestJS", "PostgreSQL", "TypeORM", "Auth0", "Redis", "Docker", "AWS"]
|
||||
good_for: "Large-scale enterprise applications"
|
||||
|
||||
rapid_prototype:
|
||||
name: "Rapid Prototype"
|
||||
components: ["Next.js", "Supabase", "shadcn/ui", "Vercel"]
|
||||
good_for: "MVP and rapid development"
|
||||
|
||||
real_time_app:
|
||||
name: "Real-Time Application"
|
||||
components: ["Next.js", "Supabase Realtime", "PostgreSQL", "Prisma", "Socket.io fallback"]
|
||||
good_for: "Chat, collaboration, live updates"
|
||||
|
||||
mobile_app:
|
||||
name: "Mobile Application"
|
||||
components: ["Expo", "React Native", "Supabase or Firebase", "React Query"]
|
||||
good_for: "Cross-platform mobile apps"
|
||||
|
||||
# Starter templates and what decisions they make
|
||||
starter_templates:
|
||||
create_next_app:
|
||||
name: "Create Next App"
|
||||
command_search: "npx create-next-app@latest"
|
||||
decisions_provided: ["Next.js framework", "TypeScript option", "App Router vs Pages", "Tailwind CSS option", "ESLint"]
|
||||
good_for: ["React web applications", "Full-stack apps", "SSR/SSG"]
|
||||
|
||||
create_t3_app:
|
||||
name: "Create T3 App"
|
||||
command_search: "npm create t3-app@latest"
|
||||
decisions_provided: ["Next.js", "TypeScript", "tRPC", "Prisma", "NextAuth", "Tailwind CSS"]
|
||||
good_for: ["Type-safe full-stack apps"]
|
||||
|
||||
create_vite:
|
||||
name: "Create Vite"
|
||||
command_search: "npm create vite@latest"
|
||||
decisions_provided: ["Framework choice (React/Vue/Svelte)", "TypeScript option", "Vite bundler"]
|
||||
good_for: ["Fast dev SPAs", "Library development"]
|
||||
|
||||
create_remix:
|
||||
name: "Create Remix"
|
||||
command_search: "npx create-remix@latest"
|
||||
decisions_provided: ["Remix framework", "TypeScript option", "Deployment target", "CSS solution"]
|
||||
good_for: ["Web standards", "Nested routing", "Progressive enhancement"]
|
||||
|
||||
nest_new:
|
||||
name: "NestJS CLI"
|
||||
command_search: "nest new project"
|
||||
decisions_provided: ["TypeScript (always)", "Package manager", "Testing framework (Jest)", "Project structure"]
|
||||
good_for: ["Enterprise APIs", "Microservices", "GraphQL APIs"]
|
||||
|
||||
create_expo_app:
|
||||
name: "Create Expo App"
|
||||
command_search: "npx create-expo-app"
|
||||
decisions_provided: ["React Native", "Expo SDK", "TypeScript option", "Navigation option"]
|
||||
good_for: ["Cross-platform mobile", "React Native apps"]
|
||||
|
||||
# Starter selection heuristics (workflow logic)
|
||||
starter_selection_rules:
|
||||
by_project_type:
|
||||
web_application:
|
||||
recommended: ["create_next_app", "create_t3_app", "create_vite"]
|
||||
considerations: "SSR needs? → Next.js. Type safety critical? → T3. SPA only? → Vite"
|
||||
|
||||
mobile_app:
|
||||
recommended: ["create_expo_app"]
|
||||
considerations: "Cross-platform → Expo. Native-heavy → React Native CLI"
|
||||
|
||||
api_backend:
|
||||
recommended: ["nest_new"]
|
||||
considerations: "Enterprise → NestJS. Simple → Express starter. Performance → Fastify"
|
||||
|
||||
full_stack:
|
||||
recommended: ["create_t3_app", "create_remix"]
|
||||
considerations: "Type safety → T3. Web standards → Remix. Monolith → RedwoodJS"
|
||||
696
bmad/bmm/workflows/3-solutioning/architecture/instructions.md
Normal file
696
bmad/bmm/workflows/3-solutioning/architecture/instructions.md
Normal file
@@ -0,0 +1,696 @@
|
||||
# Decision Architecture Workflow Instructions
|
||||
|
||||
<workflow name="architecture">
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
|
||||
<critical>This workflow uses ADAPTIVE FACILITATION - adjust your communication style based on {user_skill_level}</critical>
|
||||
<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 architecture with a conversation-driven approach</critical>
|
||||
|
||||
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
|
||||
<check if="status file not found">
|
||||
<output>No workflow status file found. Decision Architecture can run standalone or as part of BMM workflow path.</output>
|
||||
<output>**Recommended:** Run `workflow-init` first for project context tracking and workflow sequencing.</output>
|
||||
<ask>Continue in standalone mode or exit to run workflow-init? (continue/exit)</ask>
|
||||
<check if="continue">
|
||||
<action>Set standalone_mode = true</action>
|
||||
</check>
|
||||
<check if="exit">
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="status file found">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Parse workflow_status section</action>
|
||||
<action>Check status of "create-architecture" workflow</action>
|
||||
<action>Get project_level from YAML metadata</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<check if="project_level < 3">
|
||||
<output>**Note: Level {{project_level}} Project**
|
||||
|
||||
Decision Architecture is typically for Level 3-4 projects, but can be used for any project that needs architectural planning.
|
||||
|
||||
For Level {{project_level}}, we'll keep the architecture appropriately scoped.
|
||||
</output>
|
||||
</check>
|
||||
|
||||
<check if="create-architecture status is file path (already completed)">
|
||||
<output>⚠️ Architecture already completed: {{create-architecture status}}</output>
|
||||
<ask>Re-running will overwrite the existing architecture. Continue? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Use workflow-status to see your next step.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="create-architecture is not the next expected workflow">
|
||||
<output>⚠️ Next expected workflow: {{next_workflow}}. Architecture is out of sequence.</output>
|
||||
<ask>Continue with Architecture anyway? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Run {{next_workflow}} instead.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<action>Set standalone_mode = false</action>
|
||||
</check>
|
||||
|
||||
<action>Check for existing PRD and epics files using fuzzy matching</action>
|
||||
|
||||
<action>Fuzzy match PRD file: {prd_file}</action>
|
||||
<check if="PRD_not_found">
|
||||
<output>**PRD Not Found**
|
||||
|
||||
Decision Architecture works from your Product Requirements Document (PRD).
|
||||
|
||||
Looking for: bmm-PRD.md, PRD.md, or product-requirements.md in {output_folder}
|
||||
|
||||
Please run the PRD workflow first to define your requirements.
|
||||
|
||||
Run: `workflow prd`
|
||||
</output>
|
||||
<action>Exit workflow - PRD required</action>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Load and understand project context">
|
||||
<action>Load the PRD using fuzzy matching: {prd_file}</action>
|
||||
<action>Load epics file using fuzzy matching: {epics_file}</action>
|
||||
|
||||
<action>Check for UX specification using fuzzy matching:
|
||||
<action>Attempt to locate: {ux_spec_file}</action>
|
||||
<check if="ux_spec_found">
|
||||
<action>Load UX spec and extract architectural implications: - Component complexity (simple forms vs rich interactions) - Animation/transition requirements - Real-time update needs (live data, collaborative features) - Platform-specific UI requirements - Accessibility standards (WCAG compliance level) - Responsive design breakpoints - Offline capability requirements - Performance expectations (load times, interaction responsiveness)
|
||||
</action>
|
||||
</check>
|
||||
</action>
|
||||
|
||||
<action>Extract and understand from PRD: - Functional Requirements (what it must do) - Non-Functional Requirements (performance, security, compliance, etc.) - Epic structure and user stories - Acceptance criteria - Any technical constraints mentioned
|
||||
</action>
|
||||
|
||||
<action>Count and assess project scale: - Number of epics: {{epic_count}} - Number of stories: {{story_count}} - Complexity indicators (real-time, multi-tenant, regulated, etc.) - UX complexity level (if UX spec exists)
|
||||
</action>
|
||||
|
||||
<action>Reflect understanding back to {user_name}:
|
||||
"I'm reviewing your project documentation for {{project_name}}.
|
||||
I see {{epic_count}} epics with {{story_count}} total stories.
|
||||
{{if_ux_spec}}I also found your UX specification which defines the user experience requirements.{{/if_ux_spec}}
|
||||
|
||||
Key aspects I notice:
|
||||
- [Summarize core functionality]
|
||||
- [Note critical NFRs]
|
||||
{{if_ux_spec}}- [Note UX complexity and requirements]{{/if_ux_spec}}
|
||||
- [Identify unique challenges]
|
||||
|
||||
This will help me guide you through the architectural decisions needed
|
||||
to ensure AI agents implement this consistently."
|
||||
|
||||
</action>
|
||||
|
||||
<ask>Does this match your understanding of the project?</ask>
|
||||
<template-output>project_context_understanding</template-output>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Discover and evaluate starter templates">
|
||||
<critical>Modern starter templates make many good architectural decisions by default</critical>
|
||||
|
||||
<action>Based on PRD analysis, identify the primary technology domain: - Web application → Look for Next.js, Vite, Remix starters - Mobile app → Look for React Native, Expo, Flutter starters - API/Backend → Look for NestJS, Express, Fastify starters - CLI tool → Look for CLI framework starters - Full-stack → Look for T3, RedwoodJS, Blitz starters
|
||||
</action>
|
||||
|
||||
<check if="ux_spec_loaded">
|
||||
<action>Consider UX requirements when selecting starter:
|
||||
- Rich animations → Framer Motion compatible starter
|
||||
- Complex forms → React Hook Form included starter
|
||||
- Real-time features → Socket.io or WebSocket ready starter
|
||||
- Accessibility focus → WCAG-compliant component library starter
|
||||
- Design system → Storybook-enabled starter
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<action>Search for relevant starter templates:
|
||||
<WebSearch>{{primary_technology}} starter template CLI create command latest 2024</WebSearch>
|
||||
<WebSearch>{{primary_technology}} boilerplate generator latest options</WebSearch>
|
||||
</action>
|
||||
|
||||
<check if="starter_templates_found">
|
||||
<action>Investigate what each starter provides:
|
||||
<WebSearch>{{starter_name}} default setup technologies included latest</WebSearch>
|
||||
<WebSearch>{{starter_name}} project structure file organization</WebSearch>
|
||||
</action>
|
||||
|
||||
<check if="{user_skill_level} == 'expert'">
|
||||
<action>Present starter options concisely:
|
||||
"Found {{starter_name}} which provides:
|
||||
{{quick_decision_list}}
|
||||
|
||||
This would establish our base architecture. Use it?"
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<check if="{user_skill_level} == 'beginner'">
|
||||
<action>Explain starter benefits:
|
||||
"I found {{starter_name}}, which is like a pre-built foundation for your project.
|
||||
|
||||
Think of it like buying a prefab house frame instead of cutting each board yourself.
|
||||
|
||||
It makes these decisions for you:
|
||||
{{friendly_decision_list}}
|
||||
|
||||
This is a great starting point that follows best practices. Should we use it?"
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<ask>Use {{starter_name}} as the foundation? (recommended) [y/n]</ask>
|
||||
|
||||
<check if="user_accepts_starter">
|
||||
<action>Get current starter command and options:
|
||||
<WebSearch>{{starter_name}} CLI command options flags latest 2024</WebSearch>
|
||||
</action>
|
||||
|
||||
<action>Document the initialization command:
|
||||
Store command: {{full_starter_command_with_options}}
|
||||
Example: "npx create-next-app@latest my-app --typescript --tailwind --app"
|
||||
</action>
|
||||
|
||||
<action>Extract and document starter-provided decisions:
|
||||
Starter provides these architectural decisions:
|
||||
- Language/TypeScript: {{provided_or_not}}
|
||||
- Styling solution: {{provided_or_not}}
|
||||
- Testing framework: {{provided_or_not}}
|
||||
- Linting/Formatting: {{provided_or_not}}
|
||||
- Build tooling: {{provided_or_not}}
|
||||
- Project structure: {{provided_pattern}}
|
||||
</action>
|
||||
|
||||
<action>Mark these decisions as "PROVIDED BY STARTER" in our decision tracking</action>
|
||||
|
||||
<action>Note for first implementation story:
|
||||
"Project initialization using {{starter_command}} should be the first implementation story"
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<check if="user_rejects_starter">
|
||||
<ask>Any specific reason to avoid the starter? (helps me understand constraints)</ask>
|
||||
<action>Note: Manual setup required, all decisions need to be made explicitly</action>
|
||||
</check>
|
||||
|
||||
</check>
|
||||
|
||||
<check if="no_starter_found_or_applicable">
|
||||
<action>Note: No standard starter template found for this project type.
|
||||
Will need to make all architectural decisions explicitly.</action>
|
||||
</check>
|
||||
|
||||
<template-output>starter_template_decision</template-output>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Adapt facilitation style and identify remaining decisions">
|
||||
<action>Based on {user_skill_level} from config, set facilitation approach:
|
||||
|
||||
<check if="{user_skill_level} == 'expert'">
|
||||
Set mode: EXPERT
|
||||
- Use technical terminology freely
|
||||
- Move quickly through decisions
|
||||
- Assume familiarity with patterns and tools
|
||||
- Focus on edge cases and advanced concerns
|
||||
</check>
|
||||
|
||||
<check if="{user_skill_level} == 'intermediate'">
|
||||
Set mode: INTERMEDIATE
|
||||
- Balance technical accuracy with clarity
|
||||
- Explain complex patterns briefly
|
||||
- Confirm understanding at key points
|
||||
- Provide context for non-obvious choices
|
||||
</check>
|
||||
|
||||
<check if="{user_skill_level} == 'beginner'">
|
||||
Set mode: BEGINNER
|
||||
- Use analogies and real-world examples
|
||||
- Explain technical concepts in simple terms
|
||||
- Provide education about why decisions matter
|
||||
- Protect from complexity overload
|
||||
</check>
|
||||
</action>
|
||||
|
||||
<action>Load decision catalog: {decision_catalog}</action>
|
||||
<action>Load architecture patterns: {architecture_patterns}</action>
|
||||
|
||||
<action>Analyze PRD against patterns to identify needed decisions: - Match functional requirements to known patterns - Identify which categories of decisions are needed - Flag any novel/unique aspects requiring special attention - Consider which decisions the starter template already made (if applicable)
|
||||
</action>
|
||||
|
||||
<action>Create decision priority list:
|
||||
CRITICAL (blocks everything): - {{list_of_critical_decisions}}
|
||||
|
||||
IMPORTANT (shapes architecture):
|
||||
- {{list_of_important_decisions}}
|
||||
|
||||
NICE-TO-HAVE (can defer):
|
||||
- {{list_of_optional_decisions}}
|
||||
|
||||
</action>
|
||||
|
||||
<action>Announce plan to {user_name} based on mode:
|
||||
<check if="mode == 'EXPERT'">
|
||||
"Based on your PRD, we need to make {{total_decision_count}} architectural decisions.
|
||||
{{starter_covered_count}} are covered by the starter template.
|
||||
Let's work through the remaining {{remaining_count}} decisions."
|
||||
</check>
|
||||
|
||||
<check if="mode == 'BEGINNER'">
|
||||
"Great! I've analyzed your requirements and found {{total_decision_count}} technical
|
||||
choices we need to make. Don't worry - I'll guide you through each one and explain
|
||||
why it matters. {{if_starter}}The starter template handles {{starter_covered_count}}
|
||||
of these automatically.{{/if_starter}}"
|
||||
</check>
|
||||
|
||||
</action>
|
||||
|
||||
<template-output>decision_identification</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Facilitate collaborative decision making" repeat="for-each-decision">
|
||||
<critical>Each decision must be made WITH the user, not FOR them</critical>
|
||||
<critical>ALWAYS verify current versions using WebSearch - NEVER trust hardcoded versions</critical>
|
||||
|
||||
<action>For each decision in priority order:</action>
|
||||
|
||||
<action>Present the decision based on mode:
|
||||
<check if="mode == 'EXPERT'">
|
||||
"{{Decision_Category}}: {{Specific_Decision}}
|
||||
Options: {{concise_option_list_with_tradeoffs}}
|
||||
Recommendation: {{recommendation}} for {{reason}}"
|
||||
</check>
|
||||
|
||||
<check if="mode == 'INTERMEDIATE'">
|
||||
"Next decision: {{Human_Friendly_Category}}
|
||||
|
||||
We need to choose {{Specific_Decision}}.
|
||||
|
||||
Common options:
|
||||
{{option_list_with_brief_explanations}}
|
||||
|
||||
For your project, {{recommendation}} would work well because {{reason}}."
|
||||
</check>
|
||||
|
||||
<check if="mode == 'BEGINNER'">
|
||||
"Let's talk about {{Human_Friendly_Category}}.
|
||||
|
||||
{{Educational_Context_About_Why_This_Matters}}
|
||||
|
||||
Think of it like {{real_world_analogy}}.
|
||||
|
||||
Your main options:
|
||||
{{friendly_options_with_pros_cons}}
|
||||
|
||||
My suggestion: {{recommendation}}
|
||||
This is good for you because {{beginner_friendly_reason}}."
|
||||
</check>
|
||||
|
||||
</action>
|
||||
|
||||
<check if="decision_involves_specific_technology">
|
||||
<action>Verify current stable version:
|
||||
<WebSearch>{{technology}} latest stable version 2024</WebSearch>
|
||||
<WebSearch>{{technology}} current LTS version</WebSearch>
|
||||
</action>
|
||||
|
||||
<action>Update decision record with verified version:
|
||||
Technology: {{technology}}
|
||||
Verified Version: {{version_from_search}}
|
||||
Verification Date: {{today}}
|
||||
</action>
|
||||
|
||||
</check>
|
||||
|
||||
<ask>What's your preference? (or 'explain more' for details)</ask>
|
||||
|
||||
<check if="user_wants_more_info">
|
||||
<action>Provide deeper explanation appropriate to skill level</action>
|
||||
<check if="complex_tradeoffs">
|
||||
<action>Consider using advanced elicitation:
|
||||
"Would you like to explore innovative approaches to this decision?
|
||||
I can help brainstorm unconventional solutions if you have specific goals."
|
||||
</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<action>Record decision:
|
||||
Category: {{category}}
|
||||
Decision: {{user_choice}}
|
||||
Version: {{verified_version_if_applicable}}
|
||||
Affects Epics: {{list_of_affected_epics}}
|
||||
Rationale: {{user_reasoning_or_default}}
|
||||
Provided by Starter: {{yes_if_from_starter}}
|
||||
</action>
|
||||
|
||||
<action>Check for cascading implications:
|
||||
"This choice means we'll also need to {{related_decisions}}"
|
||||
</action>
|
||||
|
||||
<template-output>decision_record</template-output>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Address cross-cutting concerns">
|
||||
<critical>These decisions affect EVERY epic and story</critical>
|
||||
|
||||
<action>Facilitate decisions for consistency patterns: - Error handling strategy (How will all agents handle errors?) - Logging approach (Structured? Format? Levels?) - Date/time handling (Timezone? Format? Library?) - Authentication pattern (Where? How? Token format?) - API response format (Structure? Status codes? Errors?) - Testing strategy (Unit? Integration? E2E?)
|
||||
</action>
|
||||
|
||||
<check if="{user_skill_level} == 'beginner'">
|
||||
<action>Explain why these matter:
|
||||
"These are rules that EVERY part of your app must follow.
|
||||
If we don't decide now, each AI agent will do it differently,
|
||||
and your app won't work properly when the pieces come together."
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<template-output>cross_cutting_decisions</template-output>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Define project structure and boundaries">
|
||||
<action>Based on all decisions made, define the project structure</action>
|
||||
|
||||
<action>Create comprehensive source tree: - Root configuration files - Source code organization - Test file locations - Build/dist directories - Documentation structure
|
||||
</action>
|
||||
|
||||
<action>Map epics to architectural boundaries:
|
||||
"Epic: {{epic_name}} → Lives in {{module/directory/service}}"
|
||||
</action>
|
||||
|
||||
<action>Define integration points: - Where do components communicate? - What are the API boundaries? - How do services interact?
|
||||
</action>
|
||||
|
||||
<template-output>project_structure</template-output>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Design novel architectural patterns" optional="true">
|
||||
<critical>Some projects require INVENTING new patterns, not just choosing existing ones</critical>
|
||||
|
||||
<action>Scan PRD for concepts that don't have standard solutions: - Novel interaction patterns (e.g., "swipe to match" before Tinder existed) - Unique multi-component workflows (e.g., "viral invitation system") - New data relationships (e.g., "social graph" before Facebook) - Unprecedented user experiences (e.g., "ephemeral messages" before Snapchat) - Complex state machines crossing multiple epics
|
||||
</action>
|
||||
|
||||
<check if="novel_patterns_detected">
|
||||
<action>For each novel pattern identified:</action>
|
||||
|
||||
<action>Engage user in design collaboration:
|
||||
<check if="{user_skill_level} == 'expert'">
|
||||
"The {{pattern_name}} concept requires architectural innovation.
|
||||
|
||||
Core challenge: {{challenge_description}}
|
||||
|
||||
Let's design the component interaction model:"
|
||||
</check>
|
||||
|
||||
<check if="{user_skill_level} == 'beginner'">
|
||||
"Your idea about {{pattern_name}} is unique - there isn't a standard way to build this yet!
|
||||
|
||||
This is exciting - we get to invent the architecture together.
|
||||
|
||||
Let me help you think through how this should work:"
|
||||
</check>
|
||||
</action>
|
||||
|
||||
<action>Facilitate pattern design:
|
||||
1. Identify core components involved
|
||||
2. Map data flow between components
|
||||
3. Design state management approach
|
||||
4. Create sequence diagrams for complex flows
|
||||
5. Define API contracts for the pattern
|
||||
6. Consider edge cases and failure modes
|
||||
</action>
|
||||
|
||||
<action>Use advanced elicitation for innovation:
|
||||
"What if we approached this differently?
|
||||
- What would the ideal user experience look like?
|
||||
- Are there analogies from other domains we could apply?
|
||||
- What constraints can we challenge?"
|
||||
</action>
|
||||
|
||||
<action>Document the novel pattern:
|
||||
Pattern Name: {{pattern_name}}
|
||||
Purpose: {{what_problem_it_solves}}
|
||||
Components:
|
||||
{{component_list_with_responsibilities}}
|
||||
Data Flow:
|
||||
{{sequence_description_or_diagram}}
|
||||
Implementation Guide:
|
||||
{{how_agents_should_build_this}}
|
||||
Affects Epics:
|
||||
{{epics_that_use_this_pattern}}
|
||||
</action>
|
||||
|
||||
<action>Validate pattern completeness:
|
||||
"Does this {{pattern_name}} design cover all the use cases in your epics?
|
||||
- {{use_case_1}}: ✓ Handled by {{component}}
|
||||
- {{use_case_2}}: ✓ Handled by {{component}}
|
||||
..."
|
||||
</action>
|
||||
|
||||
</check>
|
||||
|
||||
<check if="no_novel_patterns">
|
||||
<action>Note: All patterns in this project have established solutions.
|
||||
Proceeding with standard architectural patterns.</action>
|
||||
</check>
|
||||
|
||||
<template-output>novel_pattern_designs</template-output>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Define implementation patterns to prevent agent conflicts">
|
||||
<critical>These patterns ensure multiple AI agents write compatible code</critical>
|
||||
<critical>Focus on what agents could decide DIFFERENTLY if not specified</critical>
|
||||
|
||||
<action>Load pattern categories: {pattern_categories}</action>
|
||||
|
||||
<action>Based on chosen technologies, identify potential conflict points:
|
||||
"Given that we're using {{tech_stack}}, agents need consistency rules for:"
|
||||
</action>
|
||||
|
||||
<action>For each relevant pattern category, facilitate decisions:
|
||||
|
||||
NAMING PATTERNS (How things are named):
|
||||
<check if="has_api">
|
||||
- REST endpoint naming: /users or /user? Plural or singular?
|
||||
- Route parameter format: :id or {id}?
|
||||
</check>
|
||||
<check if="has_database">
|
||||
- Table naming: users or Users or user?
|
||||
- Column naming: user_id or userId?
|
||||
- Foreign key format: user_id or fk_user?
|
||||
</check>
|
||||
<check if="has_frontend">
|
||||
- Component naming: UserCard or user-card?
|
||||
- File naming: UserCard.tsx or user-card.tsx?
|
||||
</check>
|
||||
|
||||
STRUCTURE PATTERNS (How things are organized):
|
||||
- Where do tests live? __tests__/ or *.test.ts co-located?
|
||||
- How are components organized? By feature or by type?
|
||||
- Where do shared utilities go?
|
||||
|
||||
FORMAT PATTERNS (Data exchange formats):
|
||||
<check if="has_api">
|
||||
- API response wrapper? {data: ..., error: ...} or direct response?
|
||||
- Error format? {message, code} or {error: {type, detail}}?
|
||||
- Date format in JSON? ISO strings or timestamps?
|
||||
</check>
|
||||
|
||||
COMMUNICATION PATTERNS (How components interact):
|
||||
<check if="has_events">
|
||||
- Event naming convention?
|
||||
- Event payload structure?
|
||||
</check>
|
||||
<check if="has_state_management">
|
||||
- State update pattern?
|
||||
- Action naming convention?
|
||||
</check>
|
||||
|
||||
LIFECYCLE PATTERNS (State and flow):
|
||||
- How are loading states handled?
|
||||
- What's the error recovery pattern?
|
||||
- How are retries implemented?
|
||||
|
||||
LOCATION PATTERNS (Where things go):
|
||||
- API route structure?
|
||||
- Static asset organization?
|
||||
- Config file locations?
|
||||
|
||||
CONSISTENCY PATTERNS (Cross-cutting):
|
||||
- How are dates formatted in the UI?
|
||||
- What's the logging format?
|
||||
- How are user-facing errors written?
|
||||
|
||||
</action>
|
||||
|
||||
<check if="{user_skill_level} == 'expert'">
|
||||
<action>Rapid-fire through patterns:
|
||||
"Quick decisions on implementation patterns:
|
||||
- {{pattern}}: {{suggested_convention}} OK? [y/n/specify]"
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<check if="{user_skill_level} == 'beginner'">
|
||||
<action>Explain each pattern's importance:
|
||||
"Let me explain why this matters:
|
||||
If one AI agent names database tables 'users' and another names them 'Users',
|
||||
your app will crash. We need to pick one style and make sure everyone follows it."
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<action>Document implementation patterns:
|
||||
Category: {{pattern_category}}
|
||||
Pattern: {{specific_pattern}}
|
||||
Convention: {{decided_convention}}
|
||||
Example: {{concrete_example}}
|
||||
Enforcement: "All agents MUST follow this pattern"
|
||||
</action>
|
||||
|
||||
<template-output>implementation_patterns</template-output>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Validate architectural coherence">
|
||||
<action>Run coherence checks:</action>
|
||||
|
||||
<action>Check decision compatibility: - Do all decisions work together? - Are there any conflicting choices? - Do the versions align properly?
|
||||
</action>
|
||||
|
||||
<action>Verify epic coverage: - Does every epic have architectural support? - Are all user stories implementable with these decisions? - Are there any gaps?
|
||||
</action>
|
||||
|
||||
<action>Validate pattern completeness: - Are there any patterns we missed that agents would need? - Do novel patterns integrate with standard architecture? - Are implementation patterns comprehensive enough?
|
||||
</action>
|
||||
|
||||
<check if="issues_found">
|
||||
<action>Address issues with {user_name}:
|
||||
"I notice {{issue_description}}.
|
||||
We should {{suggested_resolution}}."
|
||||
</action>
|
||||
<ask>How would you like to resolve this?</ask>
|
||||
<action>Update decisions based on resolution</action>
|
||||
</check>
|
||||
|
||||
<template-output>coherence_validation</template-output>
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Generate decision architecture document">
|
||||
<critical>The document must be complete, specific, and validation-ready</critical>
|
||||
<critical>This is the consistency contract for all AI agents</critical>
|
||||
|
||||
<action>Load template: {architecture_template}</action>
|
||||
|
||||
<action>Generate sections: 1. Executive Summary (2-3 sentences about the architecture approach) 2. Project Initialization (starter command if applicable) 3. Decision Summary Table (with verified versions and epic mapping) 4. Complete Project Structure (full tree, no placeholders) 5. Epic to Architecture Mapping (every epic placed) 6. Technology Stack Details (versions, configurations) 7. Integration Points (how components connect) 8. Novel Pattern Designs (if any were created) 9. Implementation Patterns (all consistency rules) 10. Consistency Rules (naming, organization, formats) 11. Data Architecture (models and relationships) 12. API Contracts (request/response formats) 13. Security Architecture (auth, authorization, data protection) 14. Performance Considerations (from NFRs) 15. Deployment Architecture (where and how) 16. Development Environment (setup and prerequisites) 17. Architecture Decision Records (key decisions with rationale)
|
||||
</action>
|
||||
|
||||
<action>Fill template with all collected decisions and patterns</action>
|
||||
|
||||
<action>Ensure starter command is first implementation story:
|
||||
<check if="using_starter_template">
|
||||
"## Project Initialization
|
||||
|
||||
First implementation story should execute:
|
||||
```bash
|
||||
{{starter_command_with_options}}
|
||||
```
|
||||
|
||||
This establishes the base architecture with these decisions:
|
||||
{{starter_provided_decisions}}"
|
||||
</check>
|
||||
|
||||
</action>
|
||||
|
||||
<template-output>architecture_document</template-output>
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Validate document completeness">
|
||||
<action>Load validation checklist: {installed_path}/checklist.md</action>
|
||||
|
||||
<action>Run validation checklist from {installed_path}/checklist.md</action>
|
||||
|
||||
<action>Verify MANDATORY items:
|
||||
□ Decision table has Version column with specific versions
|
||||
□ Every epic is mapped to architecture components
|
||||
□ Source tree is complete, not generic
|
||||
□ No placeholder text remains
|
||||
□ All FRs from PRD have architectural support
|
||||
□ All NFRs from PRD are addressed
|
||||
□ Implementation patterns cover all potential conflicts
|
||||
□ Novel patterns are fully documented (if applicable)
|
||||
</action>
|
||||
|
||||
<check if="validation_failed">
|
||||
<action>Fix missing items automatically</action>
|
||||
<goto step="10">Regenerate document section</goto>
|
||||
</check>
|
||||
|
||||
<template-output>validation_results</template-output>
|
||||
</step>
|
||||
|
||||
<step n="12" goal="Final review and update workflow status">
|
||||
<action>Present completion summary:</action>
|
||||
|
||||
<check if="{user_skill_level} == 'expert'">
|
||||
"Architecture complete. {{decision_count}} decisions documented.
|
||||
Ready for implementation phase."
|
||||
</check>
|
||||
|
||||
<check if="{user_skill_level} == 'beginner'">
|
||||
"Excellent! Your architecture is complete. You made {{decision_count}} important
|
||||
decisions that will keep AI agents consistent as they build your app.
|
||||
|
||||
What happens next:
|
||||
1. AI agents will read this architecture before implementing each story
|
||||
2. They'll follow your technical choices exactly
|
||||
3. Your app will be built with consistent patterns throughout
|
||||
|
||||
You're ready to move to the implementation phase!"
|
||||
|
||||
</check>
|
||||
|
||||
<action>Save document to {output_folder}/architecture.md</action>
|
||||
|
||||
<check if="standalone_mode != true">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Find workflow_status key "create-architecture"</action>
|
||||
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
|
||||
<action>Update workflow_status["create-architecture"] = "{output_folder}/bmm-architecture-{{date}}.md"</action>
|
||||
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
|
||||
|
||||
<action>Find first non-completed workflow in workflow_status (next workflow to do)</action>
|
||||
<action>Determine next agent from path file based on next workflow</action>
|
||||
|
||||
</check>
|
||||
|
||||
<output>✅ Decision Architecture workflow complete!</output>
|
||||
|
||||
<output>**Deliverables Created:**
|
||||
|
||||
- ✅ architecture.md - Complete architectural decisions document
|
||||
{{if_novel_patterns}}
|
||||
- ✅ Novel pattern designs for unique concepts
|
||||
{{/if_novel_patterns}}
|
||||
{{if_starter_template}}
|
||||
- ✅ Project initialization command documented
|
||||
{{/if_starter_template}}
|
||||
|
||||
The architecture is ready to guide AI agents through consistent implementation.
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
- **Next required:** {{next_workflow}} ({{next_agent}} agent)
|
||||
- Review the architecture.md document before proceeding
|
||||
|
||||
Check status anytime with: `workflow-status`
|
||||
</output>
|
||||
|
||||
<template-output>completion_summary</template-output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
@@ -0,0 +1,13 @@
|
||||
category,when_needed,what_to_define,why_critical
|
||||
naming_patterns,Any technology with named entities,How things are named (format/case/structure),Agents will create different names for same concept
|
||||
structure_patterns,Any technology with organization,How things are organized (folders/modules/layers),Agents will put things in different places
|
||||
format_patterns,Any technology with data exchange,How data is formatted (JSON/XML/responses),Agents will use incompatible formats
|
||||
communication_patterns,Any technology with inter-component communication,How components talk (protocols/events/messages),Agents will use different communication methods
|
||||
lifecycle_patterns,Any technology with state or flow,How state changes and flows work,Agents will handle state transitions differently
|
||||
location_patterns,Any technology with storage or routing,Where things go (URLs/paths/storage),Agents will put things in different locations
|
||||
consistency_patterns,Always,Cross-cutting concerns (dates/errors/logs),Every agent will do these differently
|
||||
|
||||
# PRINCIPLE FOR LLM:
|
||||
# Any time multiple agents might make the SAME decision DIFFERENTLY, that's a pattern to capture.
|
||||
# Think about: What could an agent encounter where they'd have to guess?
|
||||
# If they'd guess, define the pattern. If it's obvious from the tech choice, skip it.
|
||||
|
54
bmad/bmm/workflows/3-solutioning/architecture/workflow.yaml
Normal file
54
bmad/bmm/workflows/3-solutioning/architecture/workflow.yaml
Normal file
@@ -0,0 +1,54 @@
|
||||
# Architecture Workflow Configuration
|
||||
name: architecture
|
||||
description: "Collaborative architectural decision facilitation for AI-agent consistency. Replaces template-driven architecture with intelligent, adaptive conversation that produces a decision-focused architecture document optimized for preventing agent conflicts."
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables
|
||||
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 - We work from PRD, Epics, and optionally UX Spec
|
||||
recommended_inputs:
|
||||
- prd: "Product Requirements Document with FRs and NFRs"
|
||||
- epics: "Epic definitions with user stories and acceptance criteria"
|
||||
- ux_spec: "UX specification with interface designs and interaction patterns (optional)"
|
||||
|
||||
# Input file references (fuzzy matched from output folder)
|
||||
prd_file: "{output_folder}/bmm-PRD.md or PRD.md or product-requirements.md"
|
||||
epics_file: "{output_folder}/bmm-epics.md or epics.md or user-stories.md"
|
||||
ux_spec_file: "{output_folder}/ux-spec.md or ux-specification.md or user-experience.md"
|
||||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/bmad/bmm/workflows/3-solutioning/architecture"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
validation: "{installed_path}/checklist.md"
|
||||
template: "{installed_path}/architecture-template.md"
|
||||
|
||||
# Knowledge bases for intelligent decision making
|
||||
decision_catalog: "{installed_path}/decision-catalog.yaml"
|
||||
architecture_patterns: "{installed_path}/architecture-patterns.yaml"
|
||||
pattern_categories: "{installed_path}/pattern-categories.csv"
|
||||
|
||||
# Output configuration
|
||||
default_output_file: "{output_folder}/architecture.md"
|
||||
|
||||
# Workflow metadata
|
||||
version: "1.3.2"
|
||||
replaces: "architecture"
|
||||
paradigm: "facilitation-driven"
|
||||
execution_time: "30-90 minutes depending on user skill level"
|
||||
features:
|
||||
- "Starter template discovery and integration"
|
||||
- "Dynamic version verification via web search"
|
||||
- "Adaptive facilitation by skill level"
|
||||
- "Decision-focused architecture"
|
||||
- "Novel pattern design for unique concepts"
|
||||
- "Intelligent pattern identification - LLM figures out what patterns matter"
|
||||
- "Implementation patterns for agent consistency"
|
||||
|
||||
standalone: true
|
||||
@@ -0,0 +1,177 @@
|
||||
# Implementation Ready Check Workflow
|
||||
|
||||
## Overview
|
||||
|
||||
The Implementation Ready Check workflow provides a systematic validation of all planning and solutioning artifacts before transitioning from Phase 3 (Solutioning) to Phase 4 (Implementation) in the BMad Method. This workflow ensures that PRDs, architecture documents, and story breakdowns are properly aligned with no critical gaps or contradictions.
|
||||
|
||||
## Purpose
|
||||
|
||||
This workflow is designed to:
|
||||
|
||||
- **Validate Completeness**: Ensure all required planning documents exist and are complete
|
||||
- **Verify Alignment**: Check that PRD, architecture, and stories are cohesive and aligned
|
||||
- **Identify Gaps**: Detect missing stories, unaddressed requirements, or sequencing issues
|
||||
- **Assess Risks**: Find contradictions, conflicts, or potential implementation blockers
|
||||
- **Provide Confidence**: Give teams confidence that planning is solid before starting development
|
||||
|
||||
## When to Use
|
||||
|
||||
This workflow should be invoked:
|
||||
|
||||
- At the end of Phase 3 (Solutioning) for Level 2-4 projects
|
||||
- Before beginning Phase 4 (Implementation)
|
||||
- After significant planning updates or architectural changes
|
||||
- When validating readiness for Level 0-1 projects (simplified validation)
|
||||
|
||||
## Project Level Adaptations
|
||||
|
||||
The workflow adapts its validation based on project level:
|
||||
|
||||
### Level 0-1 Projects
|
||||
|
||||
- Validates tech spec and simple stories only
|
||||
- Checks internal consistency and basic coverage
|
||||
- Lighter validation appropriate for simple projects
|
||||
|
||||
### Level 2 Projects
|
||||
|
||||
- Validates PRD, tech spec (with embedded architecture), and stories
|
||||
- Ensures PRD requirements are fully covered
|
||||
- Verifies technical approach aligns with business goals
|
||||
|
||||
### Level 3-4 Projects
|
||||
|
||||
- Full validation of PRD, architecture document, and comprehensive stories
|
||||
- Deep cross-reference checking across all artifacts
|
||||
- Validates architectural decisions don't introduce scope creep
|
||||
- Checks UX artifacts if applicable
|
||||
|
||||
## How to Invoke
|
||||
|
||||
### Via Scrum Master Agent
|
||||
|
||||
```
|
||||
*solutioning-gate-check
|
||||
```
|
||||
|
||||
### Direct Workflow Invocation
|
||||
|
||||
```
|
||||
workflow solutioning-gate-check
|
||||
```
|
||||
|
||||
## Expected Inputs
|
||||
|
||||
The workflow will automatically search your project's output folder for:
|
||||
|
||||
- Product Requirements Documents (PRD)
|
||||
- Architecture documents
|
||||
- Technical Specifications
|
||||
- Epic and Story breakdowns
|
||||
- UX artifacts (if applicable)
|
||||
|
||||
No manual input file specification needed - the workflow discovers documents automatically.
|
||||
|
||||
## Generated Output
|
||||
|
||||
The workflow produces a comprehensive **Implementation Readiness Report** containing:
|
||||
|
||||
1. **Executive Summary** - Overall readiness status
|
||||
2. **Document Inventory** - What was found and reviewed
|
||||
3. **Alignment Validation** - Cross-reference analysis results
|
||||
4. **Gap Analysis** - Missing items and risks identified
|
||||
5. **Findings by Severity** - Critical, High, Medium, Low issues
|
||||
6. **Recommendations** - Specific actions to address issues
|
||||
7. **Readiness Decision** - Ready, Ready with Conditions, or Not Ready
|
||||
|
||||
Output Location: `{output_folder}/implementation-readiness-report-{date}.md`
|
||||
|
||||
## Workflow Steps
|
||||
|
||||
1. **Initialize** - Get current workflow status and project level
|
||||
2. **Document Discovery** - Find all planning artifacts
|
||||
3. **Deep Analysis** - Extract requirements, decisions, and stories
|
||||
4. **Cross-Reference Validation** - Check alignment between all documents
|
||||
5. **Gap and Risk Analysis** - Identify issues and conflicts
|
||||
6. **UX Validation** (optional) - Verify UX concerns are addressed
|
||||
7. **Generate Report** - Compile comprehensive readiness assessment
|
||||
8. **Status Update** (optional) - Offer to advance workflow to next phase
|
||||
|
||||
## Validation Criteria
|
||||
|
||||
The workflow uses systematic validation rules adapted to each project level:
|
||||
|
||||
- **Document completeness and quality**
|
||||
- **Requirement to story traceability**
|
||||
- **Architecture to implementation alignment**
|
||||
- **Story sequencing and dependencies**
|
||||
- **Greenfield project setup coverage**
|
||||
- **Risk identification and mitigation**
|
||||
|
||||
For projects using the new architecture workflow (decision-architecture.md), additional validations include:
|
||||
|
||||
- **Implementation patterns defined for consistency**
|
||||
- **Technology versions verified and current**
|
||||
- **Starter template initialization as first story**
|
||||
- **UX specification alignment (if provided)**
|
||||
|
||||
## Special Features
|
||||
|
||||
### Intelligent Adaptation
|
||||
|
||||
- Automatically adjusts validation based on project level
|
||||
- Recognizes when UX workflow is active
|
||||
- Handles greenfield vs. brownfield projects differently
|
||||
|
||||
### Comprehensive Coverage
|
||||
|
||||
- Validates not just presence but quality and alignment
|
||||
- Checks for both gaps and gold-plating
|
||||
- Ensures logical story sequencing
|
||||
|
||||
### Actionable Output
|
||||
|
||||
- Provides specific, actionable recommendations
|
||||
- Categorizes issues by severity
|
||||
- Includes positive findings and commendations
|
||||
|
||||
## Integration with BMad Method
|
||||
|
||||
This workflow integrates seamlessly with the BMad Method workflow system:
|
||||
|
||||
- Uses workflow-status to understand project context
|
||||
- Can update workflow status to advance to next phase
|
||||
- Follows standard BMad document naming conventions
|
||||
- Searches standard output folders automatically
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Documents Not Found
|
||||
|
||||
- Ensure documents are in the configured output folder
|
||||
- Check that document names follow BMad conventions
|
||||
- Verify workflow-status is properly configured
|
||||
|
||||
### Validation Too Strict
|
||||
|
||||
- The workflow adapts to project level automatically
|
||||
- Level 0-1 projects get lighter validation
|
||||
- Consider if your project level is set correctly
|
||||
|
||||
### Report Too Long
|
||||
|
||||
- Focus on Critical and High priority issues first
|
||||
- Use the executive summary for quick decisions
|
||||
- Review detailed findings only for areas of concern
|
||||
|
||||
## Support
|
||||
|
||||
For issues or questions about this workflow:
|
||||
|
||||
- Consult the BMad Method documentation
|
||||
- Check the SM agent for workflow guidance
|
||||
- Review validation-criteria.yaml for detailed rules
|
||||
|
||||
---
|
||||
|
||||
_This workflow is part of the BMad Method v6-alpha suite of planning and solutioning tools_
|
||||
@@ -0,0 +1,175 @@
|
||||
# Implementation Readiness Validation Checklist
|
||||
|
||||
## Document Completeness
|
||||
|
||||
### Core Planning Documents
|
||||
|
||||
- [ ] PRD exists and is complete (Level 2-4 projects)
|
||||
- [ ] PRD contains measurable success criteria
|
||||
- [ ] PRD defines clear scope boundaries and exclusions
|
||||
- [ ] Architecture document exists (architecture\*.md) (Level 3-4 projects)
|
||||
- [ ] Technical Specification exists with implementation details
|
||||
- [ ] Epic and story breakdown document exists
|
||||
- [ ] All documents are dated and versioned
|
||||
|
||||
### Document Quality
|
||||
|
||||
- [ ] No placeholder sections remain in any document
|
||||
- [ ] All documents use consistent terminology
|
||||
- [ ] Technical decisions include rationale and trade-offs
|
||||
- [ ] Assumptions and risks are explicitly documented
|
||||
- [ ] Dependencies are clearly identified and documented
|
||||
|
||||
## Alignment Verification
|
||||
|
||||
### PRD to Architecture Alignment (Level 3-4)
|
||||
|
||||
- [ ] Every functional requirement in PRD has architectural support documented
|
||||
- [ ] All non-functional requirements from PRD are addressed in architecture
|
||||
- [ ] Architecture doesn't introduce features beyond PRD scope
|
||||
- [ ] Performance requirements from PRD match architecture capabilities
|
||||
- [ ] Security requirements from PRD are fully addressed in architecture
|
||||
- [ ] If architecture.md: Implementation patterns are defined for consistency
|
||||
- [ ] If architecture.md: All technology choices have verified versions
|
||||
- [ ] If UX spec exists: Architecture supports UX requirements
|
||||
|
||||
### PRD to Stories Coverage (Level 2-4)
|
||||
|
||||
- [ ] Every PRD requirement maps to at least one story
|
||||
- [ ] All user journeys in PRD have complete story coverage
|
||||
- [ ] Story acceptance criteria align with PRD success criteria
|
||||
- [ ] Priority levels in stories match PRD feature priorities
|
||||
- [ ] No stories exist without PRD requirement traceability
|
||||
|
||||
### Architecture to Stories Implementation
|
||||
|
||||
- [ ] All architectural components have implementation stories
|
||||
- [ ] Infrastructure setup stories exist for each architectural layer
|
||||
- [ ] Integration points defined in architecture have corresponding stories
|
||||
- [ ] Data migration/setup stories exist if required by architecture
|
||||
- [ ] Security implementation stories cover all architecture security decisions
|
||||
|
||||
## Story and Sequencing Quality
|
||||
|
||||
### Story Completeness
|
||||
|
||||
- [ ] All stories have clear acceptance criteria
|
||||
- [ ] Technical tasks are defined within relevant stories
|
||||
- [ ] Stories include error handling and edge cases
|
||||
- [ ] Each story has clear definition of done
|
||||
- [ ] Stories are appropriately sized (no epic-level stories remaining)
|
||||
|
||||
### Sequencing and Dependencies
|
||||
|
||||
- [ ] Stories are sequenced in logical implementation order
|
||||
- [ ] Dependencies between stories are explicitly documented
|
||||
- [ ] No circular dependencies exist
|
||||
- [ ] Prerequisite technical tasks precede dependent stories
|
||||
- [ ] Foundation/infrastructure stories come before feature stories
|
||||
|
||||
### Greenfield Project Specifics
|
||||
|
||||
- [ ] Initial project setup and configuration stories exist
|
||||
- [ ] If using architecture.md: First story is starter template initialization command
|
||||
- [ ] Development environment setup is documented
|
||||
- [ ] CI/CD pipeline stories are included early in sequence
|
||||
- [ ] Database/storage initialization stories are properly placed
|
||||
- [ ] Authentication/authorization stories precede protected features
|
||||
|
||||
## Risk and Gap Assessment
|
||||
|
||||
### Critical Gaps
|
||||
|
||||
- [ ] No core PRD requirements lack story coverage
|
||||
- [ ] No architectural decisions lack implementation stories
|
||||
- [ ] All integration points have implementation plans
|
||||
- [ ] Error handling strategy is defined and implemented
|
||||
- [ ] Security concerns are all addressed
|
||||
|
||||
### Technical Risks
|
||||
|
||||
- [ ] No conflicting technical approaches between stories
|
||||
- [ ] Technology choices are consistent across all documents
|
||||
- [ ] Performance requirements are achievable with chosen architecture
|
||||
- [ ] Scalability concerns are addressed if applicable
|
||||
- [ ] Third-party dependencies are identified with fallback plans
|
||||
|
||||
## UX and Special Concerns (if applicable)
|
||||
|
||||
### UX Coverage
|
||||
|
||||
- [ ] UX requirements are documented in PRD
|
||||
- [ ] UX implementation tasks exist in relevant stories
|
||||
- [ ] Accessibility requirements have story coverage
|
||||
- [ ] Responsive design requirements are addressed
|
||||
- [ ] User flow continuity is maintained across stories
|
||||
|
||||
### Special Considerations
|
||||
|
||||
- [ ] Compliance requirements are fully addressed
|
||||
- [ ] Internationalization needs are covered if required
|
||||
- [ ] Performance benchmarks are defined and measurable
|
||||
- [ ] Monitoring and observability stories exist
|
||||
- [ ] Documentation stories are included where needed
|
||||
|
||||
## Overall Readiness
|
||||
|
||||
### Ready to Proceed Criteria
|
||||
|
||||
- [ ] All critical issues have been resolved
|
||||
- [ ] High priority concerns have mitigation plans
|
||||
- [ ] Story sequencing supports iterative delivery
|
||||
- [ ] Team has necessary skills for implementation
|
||||
- [ ] No blocking dependencies remain unresolved
|
||||
|
||||
### Quality Indicators
|
||||
|
||||
- [ ] Documents demonstrate thorough analysis
|
||||
- [ ] Clear traceability exists across all artifacts
|
||||
- [ ] Consistent level of detail throughout documents
|
||||
- [ ] Risks are identified with mitigation strategies
|
||||
- [ ] Success criteria are measurable and achievable
|
||||
|
||||
## Assessment Completion
|
||||
|
||||
### Report Quality
|
||||
|
||||
- [ ] All findings are supported by specific examples
|
||||
- [ ] Recommendations are actionable and specific
|
||||
- [ ] Severity levels are appropriately assigned
|
||||
- [ ] Positive findings are highlighted
|
||||
- [ ] Next steps are clearly defined
|
||||
|
||||
### Process Validation
|
||||
|
||||
- [ ] All expected documents were reviewed
|
||||
- [ ] Cross-references were systematically checked
|
||||
- [ ] Project level considerations were applied correctly
|
||||
- [ ] Workflow status was checked and considered
|
||||
- [ ] Output folder was thoroughly searched for artifacts
|
||||
|
||||
---
|
||||
|
||||
## Issue Log
|
||||
|
||||
### Critical Issues Found
|
||||
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
|
||||
### High Priority Issues Found
|
||||
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
|
||||
### Medium Priority Issues Found
|
||||
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
- [ ] ***
|
||||
|
||||
---
|
||||
|
||||
_Use this checklist to ensure comprehensive validation of implementation readiness_
|
||||
@@ -0,0 +1,304 @@
|
||||
# Implementation Ready Check - Workflow Instructions
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {project-root}/bmad/bmm/workflows/3-solutioning/solutioning-gate-check/workflow.yaml</critical>
|
||||
<critical>Communicate all findings and analysis in {communication_language} throughout the assessment</critical>
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
|
||||
<check if="status file not found">
|
||||
<output>No workflow status file found. Implementation Ready Check can run standalone or as part of BMM workflow path.</output>
|
||||
<output>**Recommended:** Run `workflow-init` first for project context tracking and workflow sequencing.</output>
|
||||
<ask>Continue in standalone mode or exit to run workflow-init? (continue/exit)</ask>
|
||||
<check if="continue">
|
||||
<action>Set standalone_mode = true</action>
|
||||
</check>
|
||||
<check if="exit">
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="status file found">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Parse workflow_status section</action>
|
||||
<action>Check status of "solutioning-gate-check" workflow</action>
|
||||
<action>Get project_level from YAML metadata</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<action>Based on the project_level, understand what artifacts should exist: - Level 0-1: Tech spec and simple stories only (no PRD, minimal solutioning) - Level 2: PRD, tech spec, epics/stories (no separate architecture doc) - Level 3-4: Full suite - PRD, architecture document, epics/stories, possible UX artifacts
|
||||
</action>
|
||||
|
||||
<check if="solutioning-gate-check status is file path (already completed)">
|
||||
<output>⚠️ Gate check already completed: {{solutioning-gate-check status}}</output>
|
||||
<ask>Re-running will create a new validation report. Continue? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Use workflow-status to see your next step.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="solutioning-gate-check is not the next expected workflow">
|
||||
<output>⚠️ Next expected workflow: {{next_workflow}}. Gate check is out of sequence.</output>
|
||||
<ask>Continue with gate check anyway? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Run {{next_workflow}} instead.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<action>Set standalone_mode = false</action>
|
||||
</check>
|
||||
|
||||
<critical>The validation approach must adapt to the project level - don't look for documents that shouldn't exist at lower levels</critical>
|
||||
|
||||
<template-output>project_context</template-output>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Discover and inventory project artifacts">
|
||||
<action>Search the {output_folder} for relevant planning and solutioning documents based on project level identified in Step 0</action>
|
||||
|
||||
<action>For Level 0-1 projects, locate:
|
||||
|
||||
- Technical specification document(s)
|
||||
- Story/task lists or simple epic breakdowns
|
||||
- Any API or interface definitions
|
||||
</action>
|
||||
|
||||
<action>For Level 2-4 projects, locate:
|
||||
|
||||
- Product Requirements Document (PRD)
|
||||
- Architecture document (architecture.md) (Level 3-4 only)
|
||||
- Technical Specification (Level 2 includes architecture within)
|
||||
- Epic and story breakdowns
|
||||
- UX artifacts if the active path includes UX workflow
|
||||
- Any supplementary planning documents
|
||||
</action>
|
||||
|
||||
<action>Create an inventory of found documents with:
|
||||
|
||||
- Document type and purpose
|
||||
- File path and last modified date
|
||||
- Brief description of what each contains
|
||||
- Any missing expected documents flagged as potential issues
|
||||
</action>
|
||||
|
||||
<template-output>document_inventory</template-output>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Deep analysis of core planning documents">
|
||||
<action>Load and thoroughly analyze each discovered document to extract:
|
||||
- Core requirements and success criteria
|
||||
- Architectural decisions and constraints
|
||||
- Technical implementation approaches
|
||||
- User stories and acceptance criteria
|
||||
- Dependencies and sequencing requirements
|
||||
- Any assumptions or risks documented
|
||||
</action>
|
||||
|
||||
<action>For PRD analysis (Level 2-4), focus on:
|
||||
|
||||
- User requirements and use cases
|
||||
- Functional and non-functional requirements
|
||||
- Success metrics and acceptance criteria
|
||||
- Scope boundaries and explicitly excluded items
|
||||
- Priority levels for different features
|
||||
</action>
|
||||
|
||||
<action>For Architecture/Tech Spec analysis, focus on:
|
||||
|
||||
- System design decisions and rationale
|
||||
- Technology stack and framework choices
|
||||
- Integration points and APIs
|
||||
- Data models and storage decisions
|
||||
- Security and performance considerations
|
||||
- Any architectural constraints that might affect story implementation
|
||||
</action>
|
||||
|
||||
<action>For Epic/Story analysis, focus on:
|
||||
|
||||
- Coverage of PRD requirements
|
||||
- Story sequencing and dependencies
|
||||
- Acceptance criteria completeness
|
||||
- Technical tasks within stories
|
||||
- Estimated complexity and effort indicators
|
||||
</action>
|
||||
|
||||
<template-output>document_analysis</template-output>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Cross-reference validation and alignment check">
|
||||
<action>Systematically validate alignment between all artifacts, adapting validation based on project level</action>
|
||||
|
||||
<action>PRD ↔ Architecture Alignment (Level 3-4):
|
||||
|
||||
- Verify every PRD requirement has corresponding architectural support
|
||||
- Check that architectural decisions don't contradict PRD constraints
|
||||
- Identify any architectural additions beyond PRD scope (potential gold-plating)
|
||||
- Ensure non-functional requirements from PRD are addressed in architecture document
|
||||
- If using new architecture workflow: verify implementation patterns are defined
|
||||
</action>
|
||||
|
||||
<action>PRD ↔ Stories Coverage (Level 2-4):
|
||||
|
||||
- Map each PRD requirement to implementing stories
|
||||
- Identify any PRD requirements without story coverage
|
||||
- Find stories that don't trace back to PRD requirements
|
||||
- Validate that story acceptance criteria align with PRD success criteria
|
||||
</action>
|
||||
|
||||
<action>Architecture ↔ Stories Implementation Check:
|
||||
|
||||
- Verify architectural decisions are reflected in relevant stories
|
||||
- Check that story technical tasks align with architectural approach
|
||||
- Identify any stories that might violate architectural constraints
|
||||
- Ensure infrastructure and setup stories exist for architectural components
|
||||
</action>
|
||||
|
||||
<action>For Level 0-1 projects (Tech Spec only):
|
||||
|
||||
- Validate internal consistency within tech spec
|
||||
- Check that all specified features have corresponding stories
|
||||
- Verify story sequencing matches technical dependencies
|
||||
</action>
|
||||
|
||||
<template-output>alignment_validation</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Gap and risk analysis">
|
||||
<action>Identify and categorize all gaps, risks, and potential issues discovered during validation</action>
|
||||
|
||||
<action>Check for Critical Gaps:
|
||||
|
||||
- Missing stories for core requirements
|
||||
- Unaddressed architectural concerns
|
||||
- Absent infrastructure or setup stories for greenfield projects
|
||||
- Missing error handling or edge case coverage
|
||||
- Security or compliance requirements not addressed
|
||||
</action>
|
||||
|
||||
<action>Identify Sequencing Issues:
|
||||
|
||||
- Dependencies not properly ordered
|
||||
- Stories that assume components not yet built
|
||||
- Parallel work that should be sequential
|
||||
- Missing prerequisite technical tasks
|
||||
</action>
|
||||
|
||||
<action>Detect Potential Contradictions:
|
||||
|
||||
- Conflicts between PRD and architecture approaches
|
||||
- Stories with conflicting technical approaches
|
||||
- Acceptance criteria that contradict requirements
|
||||
- Resource or technology conflicts
|
||||
</action>
|
||||
|
||||
<action>Find Gold-Plating and Scope Creep:
|
||||
|
||||
- Features in architecture not required by PRD
|
||||
- Stories implementing beyond requirements
|
||||
- Technical complexity beyond project needs
|
||||
- Over-engineering indicators
|
||||
</action>
|
||||
|
||||
<template-output>gap_risk_analysis</template-output>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="UX and special concerns validation" optional="true">
|
||||
<check if="UX artifacts exist or UX workflow in active path">
|
||||
<action>Review UX artifacts and validate integration:
|
||||
- Check that UX requirements are reflected in PRD
|
||||
- Verify stories include UX implementation tasks
|
||||
- Ensure architecture supports UX requirements (performance, responsiveness)
|
||||
- Identify any UX concerns not addressed in stories
|
||||
</action>
|
||||
|
||||
<action>Validate accessibility and usability coverage:
|
||||
|
||||
- Check for accessibility requirement coverage in stories
|
||||
- Verify responsive design considerations if applicable
|
||||
- Ensure user flow completeness across stories
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<template-output>ux_validation</template-output>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Generate comprehensive readiness assessment">
|
||||
<action>Compile all findings into a structured readiness report with:
|
||||
- Executive summary of readiness status
|
||||
- Project context and validation scope
|
||||
- Document inventory and coverage assessment
|
||||
- Detailed findings organized by severity (Critical, High, Medium, Low)
|
||||
- Specific recommendations for each issue
|
||||
- Overall readiness recommendation (Ready, Ready with Conditions, Not Ready)
|
||||
</action>
|
||||
|
||||
<action>Provide actionable next steps:
|
||||
|
||||
- List any critical issues that must be resolved
|
||||
- Suggest specific document updates needed
|
||||
- Recommend additional stories or tasks required
|
||||
- Propose sequencing adjustments if needed
|
||||
</action>
|
||||
|
||||
<action>Include positive findings:
|
||||
|
||||
- Highlight well-aligned areas
|
||||
- Note particularly thorough documentation
|
||||
- Recognize good architectural decisions
|
||||
- Commend comprehensive story coverage where found
|
||||
</action>
|
||||
|
||||
<template-output>readiness_assessment</template-output>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Update status and complete" tag="workflow-status">
|
||||
<check if="standalone_mode != true">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Find workflow_status key "solutioning-gate-check"</action>
|
||||
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
|
||||
<action>Update workflow_status["solutioning-gate-check"] = "{output_folder}/bmm-readiness-assessment-{{date}}.md"</action>
|
||||
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
|
||||
|
||||
<action>Find first non-completed workflow in workflow_status (next workflow to do)</action>
|
||||
<action>Determine next agent from path file based on next workflow</action>
|
||||
</check>
|
||||
|
||||
<output>**✅ Implementation Ready Check Complete!**
|
||||
|
||||
**Assessment Report:**
|
||||
|
||||
- Readiness assessment saved to: {output_folder}/bmm-readiness-assessment-{{date}}.md
|
||||
|
||||
{{#if standalone_mode != true}}
|
||||
**Status Updated:**
|
||||
|
||||
- Progress tracking updated: solutioning-gate-check marked complete
|
||||
- Next workflow: {{next_workflow}}
|
||||
{{else}}
|
||||
**Note:** Running in standalone mode (no progress tracking)
|
||||
{{/if}}
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
{{#if standalone_mode != true}}
|
||||
|
||||
- **Next workflow:** {{next_workflow}} ({{next_agent}} agent)
|
||||
- Review the assessment report and address any critical issues before proceeding
|
||||
|
||||
Check status anytime with: `workflow-status`
|
||||
{{else}}
|
||||
Since no workflow is in progress:
|
||||
|
||||
- Refer to the BMM workflow guide if unsure what to do next
|
||||
- Or run `workflow-init` to create a workflow path and get guided next steps
|
||||
{{/if}}
|
||||
</output>
|
||||
|
||||
<template-output>status_update_result</template-output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
@@ -0,0 +1,146 @@
|
||||
# Implementation Readiness Assessment Report
|
||||
|
||||
**Date:** {{date}}
|
||||
**Project:** {{project_name}}
|
||||
**Assessed By:** {{user_name}}
|
||||
**Assessment Type:** Phase 3 to Phase 4 Transition Validation
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{readiness_assessment}}
|
||||
|
||||
---
|
||||
|
||||
## Project Context
|
||||
|
||||
{{project_context}}
|
||||
|
||||
---
|
||||
|
||||
## Document Inventory
|
||||
|
||||
### Documents Reviewed
|
||||
|
||||
{{document_inventory}}
|
||||
|
||||
### Document Analysis Summary
|
||||
|
||||
{{document_analysis}}
|
||||
|
||||
---
|
||||
|
||||
## Alignment Validation Results
|
||||
|
||||
### Cross-Reference Analysis
|
||||
|
||||
{{alignment_validation}}
|
||||
|
||||
---
|
||||
|
||||
## Gap and Risk Analysis
|
||||
|
||||
### Critical Findings
|
||||
|
||||
{{gap_risk_analysis}}
|
||||
|
||||
---
|
||||
|
||||
## UX and Special Concerns
|
||||
|
||||
{{ux_validation}}
|
||||
|
||||
---
|
||||
|
||||
## Detailed Findings
|
||||
|
||||
### 🔴 Critical Issues
|
||||
|
||||
_Must be resolved before proceeding to implementation_
|
||||
|
||||
{{critical_issues}}
|
||||
|
||||
### 🟠 High Priority Concerns
|
||||
|
||||
_Should be addressed to reduce implementation risk_
|
||||
|
||||
{{high_priority_concerns}}
|
||||
|
||||
### 🟡 Medium Priority Observations
|
||||
|
||||
_Consider addressing for smoother implementation_
|
||||
|
||||
{{medium_priority_observations}}
|
||||
|
||||
### 🟢 Low Priority Notes
|
||||
|
||||
_Minor items for consideration_
|
||||
|
||||
{{low_priority_notes}}
|
||||
|
||||
---
|
||||
|
||||
## Positive Findings
|
||||
|
||||
### ✅ Well-Executed Areas
|
||||
|
||||
{{positive_findings}}
|
||||
|
||||
---
|
||||
|
||||
## Recommendations
|
||||
|
||||
### Immediate Actions Required
|
||||
|
||||
{{immediate_actions}}
|
||||
|
||||
### Suggested Improvements
|
||||
|
||||
{{suggested_improvements}}
|
||||
|
||||
### Sequencing Adjustments
|
||||
|
||||
{{sequencing_adjustments}}
|
||||
|
||||
---
|
||||
|
||||
## Readiness Decision
|
||||
|
||||
### Overall Assessment: {{overall_readiness_status}}
|
||||
|
||||
{{readiness_rationale}}
|
||||
|
||||
### Conditions for Proceeding (if applicable)
|
||||
|
||||
{{conditions_for_proceeding}}
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
{{recommended_next_steps}}
|
||||
|
||||
### Workflow Status Update
|
||||
|
||||
{{status_update_result}}
|
||||
|
||||
---
|
||||
|
||||
## Appendices
|
||||
|
||||
### A. Validation Criteria Applied
|
||||
|
||||
{{validation_criteria_used}}
|
||||
|
||||
### B. Traceability Matrix
|
||||
|
||||
{{traceability_matrix}}
|
||||
|
||||
### C. Risk Mitigation Strategies
|
||||
|
||||
{{risk_mitigation_strategies}}
|
||||
|
||||
---
|
||||
|
||||
_This readiness assessment was generated using the BMad Method Implementation Ready Check workflow (v6-alpha)_
|
||||
@@ -0,0 +1,189 @@
|
||||
# Implementation Readiness Validation Criteria
|
||||
# Defines systematic validation rules by project level
|
||||
|
||||
validation_rules:
|
||||
# Level 0-1 Projects (Simple, minimal planning)
|
||||
level_0_1:
|
||||
required_documents:
|
||||
- tech_spec
|
||||
- stories_or_tasks
|
||||
|
||||
validations:
|
||||
- name: "Tech Spec Completeness"
|
||||
checks:
|
||||
- "All features defined with implementation approach"
|
||||
- "Technical dependencies identified"
|
||||
- "API contracts defined if applicable"
|
||||
- "Data models specified"
|
||||
|
||||
- name: "Story Coverage"
|
||||
checks:
|
||||
- "All tech spec features have corresponding stories"
|
||||
- "Stories are sequenced logically"
|
||||
- "Technical tasks are defined"
|
||||
- "No critical gaps in coverage"
|
||||
|
||||
# Level 2 Projects (PRD + Tech Spec, no separate architecture)
|
||||
level_2:
|
||||
required_documents:
|
||||
- prd
|
||||
- tech_spec # Includes architecture decisions
|
||||
- epics_and_stories
|
||||
|
||||
validations:
|
||||
- name: "PRD to Tech Spec Alignment"
|
||||
checks:
|
||||
- "All PRD requirements addressed in tech spec"
|
||||
- "Architecture embedded in tech spec covers PRD needs"
|
||||
- "Non-functional requirements are specified"
|
||||
- "Technical approach supports business goals"
|
||||
|
||||
- name: "Story Coverage and Alignment"
|
||||
checks:
|
||||
- "Every PRD requirement has story coverage"
|
||||
- "Stories align with tech spec approach"
|
||||
- "Epic breakdown is complete"
|
||||
- "Acceptance criteria match PRD success criteria"
|
||||
|
||||
- name: "Sequencing Validation"
|
||||
checks:
|
||||
- "Foundation stories come first"
|
||||
- "Dependencies are properly ordered"
|
||||
- "Iterative delivery is possible"
|
||||
- "No circular dependencies"
|
||||
|
||||
# Level 3-4 Projects (Full planning with separate architecture)
|
||||
level_3_4:
|
||||
required_documents:
|
||||
- prd
|
||||
- architecture
|
||||
- epics_and_stories
|
||||
|
||||
validations:
|
||||
- name: "PRD Completeness"
|
||||
checks:
|
||||
- "User requirements fully documented"
|
||||
- "Success criteria are measurable"
|
||||
- "Scope boundaries clearly defined"
|
||||
- "Priorities are assigned"
|
||||
|
||||
- name: "Architecture Coverage"
|
||||
checks:
|
||||
- "All PRD requirements have architectural support"
|
||||
- "System design is complete"
|
||||
- "Integration points defined"
|
||||
- "Security architecture specified"
|
||||
- "Performance considerations addressed"
|
||||
- "If architecture.md: Implementation patterns defined"
|
||||
- "If architecture.md: Technology versions verified and current"
|
||||
- "If architecture.md: Starter template command documented (if applicable)"
|
||||
|
||||
- name: "PRD-Architecture Alignment"
|
||||
checks:
|
||||
- "No architecture gold-plating beyond PRD"
|
||||
- "NFRs from PRD reflected in architecture"
|
||||
- "Technology choices support requirements"
|
||||
- "Scalability matches expected growth"
|
||||
- "If UX spec exists: Architecture supports UX requirements"
|
||||
- "If UX spec exists: Component library supports interaction patterns"
|
||||
|
||||
- name: "Story Implementation Coverage"
|
||||
checks:
|
||||
- "All architectural components have stories"
|
||||
- "Infrastructure setup stories exist"
|
||||
- "Integration implementation planned"
|
||||
- "Security implementation stories present"
|
||||
|
||||
- name: "Comprehensive Sequencing"
|
||||
checks:
|
||||
- "Infrastructure before features"
|
||||
- "Authentication before protected resources"
|
||||
- "Core features before enhancements"
|
||||
- "Dependencies properly ordered"
|
||||
- "Allows for iterative releases"
|
||||
|
||||
# Special validation contexts
|
||||
special_contexts:
|
||||
greenfield:
|
||||
additional_checks:
|
||||
- "Project initialization stories exist"
|
||||
- "If using architecture.md: First story is starter template initialization"
|
||||
- "Development environment setup documented"
|
||||
- "CI/CD pipeline stories included"
|
||||
- "Initial data/schema setup planned"
|
||||
- "Deployment infrastructure stories present"
|
||||
|
||||
ux_workflow_active:
|
||||
additional_checks:
|
||||
- "UX requirements in PRD"
|
||||
- "UX implementation stories exist"
|
||||
- "Accessibility requirements covered"
|
||||
- "Responsive design addressed"
|
||||
- "User flow continuity maintained"
|
||||
|
||||
api_heavy:
|
||||
additional_checks:
|
||||
- "API contracts fully defined"
|
||||
- "Versioning strategy documented"
|
||||
- "Authentication/authorization specified"
|
||||
- "Rate limiting considered"
|
||||
- "API documentation stories included"
|
||||
|
||||
# Severity definitions
|
||||
severity_levels:
|
||||
critical:
|
||||
description: "Must be resolved before implementation"
|
||||
examples:
|
||||
- "Missing stories for core requirements"
|
||||
- "Conflicting technical approaches"
|
||||
- "No infrastructure setup for greenfield"
|
||||
- "Security requirements not addressed"
|
||||
|
||||
high:
|
||||
description: "Should be addressed to reduce risk"
|
||||
examples:
|
||||
- "Incomplete acceptance criteria"
|
||||
- "Unclear story dependencies"
|
||||
- "Missing error handling coverage"
|
||||
- "Performance requirements not validated"
|
||||
|
||||
medium:
|
||||
description: "Consider addressing for smoother implementation"
|
||||
examples:
|
||||
- "Documentation gaps"
|
||||
- "Test strategy not defined"
|
||||
- "Monitoring approach unclear"
|
||||
- "Minor sequencing improvements possible"
|
||||
|
||||
low:
|
||||
description: "Minor improvements for consideration"
|
||||
examples:
|
||||
- "Formatting inconsistencies"
|
||||
- "Optional enhancements identified"
|
||||
- "Style guide compliance"
|
||||
- "Nice-to-have features noted"
|
||||
|
||||
# Readiness decision criteria
|
||||
readiness_decisions:
|
||||
ready:
|
||||
criteria:
|
||||
- "No critical issues found"
|
||||
- "All required documents present"
|
||||
- "Core alignments validated"
|
||||
- "Story sequencing logical"
|
||||
- "Team can begin implementation"
|
||||
|
||||
ready_with_conditions:
|
||||
criteria:
|
||||
- "Only high/medium issues found"
|
||||
- "Mitigation plans identified"
|
||||
- "Core path to MVP clear"
|
||||
- "Issues won't block initial stories"
|
||||
|
||||
not_ready:
|
||||
criteria:
|
||||
- "Critical issues identified"
|
||||
- "Major gaps in coverage"
|
||||
- "Conflicting approaches found"
|
||||
- "Required documents missing"
|
||||
- "Blocking dependencies unresolved"
|
||||
@@ -0,0 +1,38 @@
|
||||
# Implementation Ready Check - Workflow Configuration
|
||||
name: solutioning-gate-check
|
||||
description: "Systematically validate that all planning and solutioning phases are complete and properly aligned before transitioning to Phase 4 implementation. Ensures PRD, architecture, and stories are cohesive with no gaps or contradictions."
|
||||
author: "BMad Builder"
|
||||
|
||||
# Critical variables from config
|
||||
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
|
||||
workflow_status_workflow: "{project-root}/bmad/bmm/workflows/workflow-status/workflow.yaml"
|
||||
workflow_paths_dir: "{project-root}/bmad/bmm/workflows/workflow-status/paths"
|
||||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/bmad/bmm/workflows/3-solutioning/solutioning-gate-check"
|
||||
template: "{installed_path}/template.md"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
validation: "{installed_path}/checklist.md"
|
||||
|
||||
# Output configuration
|
||||
default_output_file: "{output_folder}/implementation-readiness-report-{{date}}.md"
|
||||
|
||||
# Expected input documents (varies by project level)
|
||||
recommended_inputs:
|
||||
- prd: "{output_folder}/prd*.md"
|
||||
- architecture: "{output_folder}/architecture*.md or {output_folder}/architecture*.md"
|
||||
- tech_spec: "{output_folder}/tech-spec*.md"
|
||||
- epics_stories: "{output_folder}/epic*.md"
|
||||
- ux_artifacts: "{output_folder}/ux*.md"
|
||||
|
||||
# Validation criteria data
|
||||
validation_criteria: "{installed_path}/validation-criteria.yaml"
|
||||
|
||||
standalone: true
|
||||
Reference in New Issue
Block a user