mirror of
https://github.com/bmadcode/BMAD-METHOD.git
synced 2025-12-29 16:14:59 +00:00
architecture reorganization in preparation of architecture solutioning rework
This commit is contained in:
Brian Madison
@@ -0,0 +1,74 @@
|
||||
# Architecture Decision Records
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
This document captures all architectural decisions made during the solution architecture process. Each decision includes the context, options considered, chosen solution, and rationale.
|
||||
|
||||
---
|
||||
|
||||
## Decision Format
|
||||
|
||||
Each decision follows this structure:
|
||||
|
||||
### ADR-NNN: [Decision Title]
|
||||
|
||||
**Date:** YYYY-MM-DD
|
||||
**Status:** [Proposed | Accepted | Rejected | Superseded]
|
||||
**Decider:** [User | Agent | Collaborative]
|
||||
|
||||
**Context:**
|
||||
What is the issue we're trying to solve?
|
||||
|
||||
**Options Considered:**
|
||||
|
||||
1. Option A - [brief description]
|
||||
- Pros: ...
|
||||
- Cons: ...
|
||||
2. Option B - [brief description]
|
||||
- Pros: ...
|
||||
- Cons: ...
|
||||
3. Option C - [brief description]
|
||||
- Pros: ...
|
||||
- Cons: ...
|
||||
|
||||
**Decision:**
|
||||
We chose [Option X]
|
||||
|
||||
**Rationale:**
|
||||
Why we chose this option over others.
|
||||
|
||||
**Consequences:**
|
||||
|
||||
- Positive: ...
|
||||
- Negative: ...
|
||||
- Neutral: ...
|
||||
|
||||
**Rejected Options:**
|
||||
|
||||
- Option A rejected because: ...
|
||||
- Option B rejected because: ...
|
||||
|
||||
---
|
||||
|
||||
## Decisions
|
||||
|
||||
{{decisions_list}}
|
||||
|
||||
---
|
||||
|
||||
## Decision Index
|
||||
|
||||
| ID | Title | Status | Date | Decider |
|
||||
| --- | ----- | ------ | ---- | ------- |
|
||||
|
||||
{{decisions_index}}
|
||||
|
||||
---
|
||||
|
||||
_This document is generated and updated during the solution-architecture workflow_
|
||||
@@ -0,0 +1,461 @@
|
||||
# Solution Architecture Workflow Instructions
|
||||
|
||||
<workflow name="solution-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>Communicate all responses in {communication_language} and language MUSt be tailored to {user_skill_level}</critical>
|
||||
<critical>Generate all documents in {document_output_language}</critical>
|
||||
<critical>DOCUMENT OUTPUT: Concise, technical, LLM-optimized. Use tables/lists over prose. Specific versions only. User skill level ({user_skill_level}) affects conversation style ONLY, not documented output content.</critical>
|
||||
|
||||
<step n="0" goal="Validate workflow and extract project configuration">
|
||||
<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
|
||||
<param>mode: data</param>
|
||||
<param>data_request: project_config</param>
|
||||
</invoke-workflow>
|
||||
|
||||
<check if="status_exists == false">
|
||||
<output>**⚠️ No Workflow Status File Found**
|
||||
|
||||
Please run `workflow-init` first to:
|
||||
|
||||
- Define your project type and level
|
||||
- Map out your workflow journey
|
||||
- Create the status file
|
||||
|
||||
Run: `workflow-init`
|
||||
|
||||
After setup, return here to run solution-architecture.
|
||||
</output>
|
||||
<action>Exit workflow - cannot proceed without status file</action>
|
||||
|
||||
</check>
|
||||
|
||||
<check if="status_exists == true">
|
||||
<action>Store {{status_file_path}} for later updates</action>
|
||||
<action>Use extracted project configuration:</action>
|
||||
- project_level: {{project_level}}
|
||||
- field_type: {{field_type}}
|
||||
- project_type: {{project_type}}
|
||||
- has_user_interface: {{has_user_interface}}
|
||||
- ui_complexity: {{ui_complexity}}
|
||||
- ux_spec_path: {{ux_spec_path}}
|
||||
- prd_status: {{prd_status}}
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="0.5" goal="Validate workflow sequencing and prerequisites">
|
||||
|
||||
<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
|
||||
<param>mode: validate</param>
|
||||
<param>calling_workflow: solution-architecture</param>
|
||||
</invoke-workflow>
|
||||
|
||||
<check if="warning != ''">
|
||||
<output>{{warning}}</output>
|
||||
<ask>Continue with solution-architecture anyway? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>{{suggestion}}</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<action>Validate Prerequisites (BLOCKING):
|
||||
|
||||
Check 1: PRD complete?
|
||||
IF prd_status != complete:
|
||||
❌ STOP WORKFLOW
|
||||
Output: "PRD is required before solution architecture.
|
||||
|
||||
REQUIRED: Complete PRD with FRs, NFRs, epics, and stories.
|
||||
|
||||
Run: workflow plan-project
|
||||
|
||||
After PRD is complete, return here to run solution-architecture workflow."
|
||||
END
|
||||
|
||||
Check 2: UX Spec complete (if UI project)?
|
||||
IF has_user_interface == true AND ux_spec_missing:
|
||||
❌ STOP WORKFLOW
|
||||
Output: "UX Spec is required before solution architecture for UI projects.
|
||||
|
||||
REQUIRED: Complete UX specification before proceeding.
|
||||
|
||||
Run: workflow ux-spec
|
||||
|
||||
The UX spec will define:
|
||||
- Screen/page structure
|
||||
- Navigation flows
|
||||
- Key user journeys
|
||||
- UI/UX patterns and components
|
||||
- Responsive requirements
|
||||
- Accessibility requirements
|
||||
|
||||
Once complete, the UX spec will inform:
|
||||
- Frontend architecture and component structure
|
||||
- API design (driven by screen data needs)
|
||||
- State management strategy
|
||||
- Technology choices (component libraries, animation, etc.)
|
||||
- Performance requirements (lazy loading, code splitting)
|
||||
|
||||
After UX spec is complete at /docs/ux-spec.md, return here to run solution-architecture workflow."
|
||||
END
|
||||
|
||||
Check 3: All prerequisites met?
|
||||
IF all prerequisites met:
|
||||
✅ Prerequisites validated - PRD: complete - UX Spec: {{complete | not_applicable}}
|
||||
Proceeding with solution architecture workflow...
|
||||
|
||||
1. Determine workflow path:
|
||||
IF project_level == 0: - Skip solution architecture entirely - Output: "Level 0 project - validate/update tech-spec.md only" - STOP WORKFLOW
|
||||
ELSE: - Proceed with full solution architecture workflow
|
||||
</action>
|
||||
<template-output>prerequisites_and_scale_assessment</template-output>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Analyze requirements and identify project characteristics">
|
||||
|
||||
<action>Load and deeply understand the requirements documents (PRD/GDD), epics and the stories to complete them and any UX specifications.</action>
|
||||
|
||||
<action>Intelligently determine the true nature of this project by analyzing:
|
||||
|
||||
- The primary document type (PRD for software, GDD for games)
|
||||
- Core functionality and features described
|
||||
- Technical constraints and requirements mentioned
|
||||
- User interface complexity and interaction patterns
|
||||
- Performance and scalability requirements
|
||||
- Integration needs with external services
|
||||
</action>
|
||||
|
||||
<action>Extract and synthesize the essential architectural drivers:
|
||||
|
||||
- What type of system is being built (web, mobile, game, library, etc.)
|
||||
- What are the critical quality attributes (performance, security, usability)
|
||||
- What constraints exist (technical, business, regulatory)
|
||||
- What integrations are required
|
||||
- What scale is expected
|
||||
</action>
|
||||
|
||||
<action>If UX specifications exist, understand the user experience requirements and how they drive technical architecture:
|
||||
|
||||
- Screen/page inventory and complexity
|
||||
- Navigation patterns and user flows
|
||||
- Real-time vs. static interactions
|
||||
- Accessibility and responsive design needs
|
||||
- Performance expectations from a user perspective
|
||||
</action>
|
||||
|
||||
<action>Identify gaps between requirements and technical specifications:
|
||||
|
||||
- What architectural decisions are already made vs. what needs determination
|
||||
- Misalignments between UX designs and functional requirements
|
||||
- Missing enabler requirements that will be needed for implementation
|
||||
</action>
|
||||
|
||||
<template-output>requirements_analysis</template-output>
|
||||
</step>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Understand user context and preferences">
|
||||
|
||||
<action>Engage with the user to understand their technical context and preferences:
|
||||
|
||||
- Note: User skill level is {user_skill_level} (from config)
|
||||
- Learn about any existing technical decisions or constraints
|
||||
- Understand team capabilities and preferences
|
||||
- Identify any existing infrastructure or systems to integrate with
|
||||
</action>
|
||||
|
||||
<action>Based on {user_skill_level}, adapt YOUR CONVERSATIONAL STYLE:
|
||||
|
||||
<check if="{user_skill_level} == 'beginner'">
|
||||
- Explain architectural concepts as you discuss them
|
||||
- Be patient and educational in your responses
|
||||
- Clarify technical terms when introducing them
|
||||
</check>
|
||||
|
||||
<check if="{user_skill_level} == 'intermediate'">
|
||||
- Balance explanations with efficiency
|
||||
- Assume familiarity with common concepts
|
||||
- Explain only complex or unusual patterns
|
||||
</check>
|
||||
|
||||
<check if="{user_skill_level} == 'expert'">
|
||||
- Be direct and technical in discussions
|
||||
- Skip basic explanations
|
||||
- Focus on advanced considerations and edge cases
|
||||
</check>
|
||||
|
||||
NOTE: This affects only how you TALK to the user, NOT the documents you generate.
|
||||
The architecture document itself should always be concise and technical.
|
||||
</action>
|
||||
|
||||
<template-output>user_context</template-output>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Determine overall architecture approach">
|
||||
|
||||
<action>Based on the requirements analysis, determine the most appropriate architectural patterns:
|
||||
|
||||
- Consider the scale, complexity, and team size to choose between monolith, microservices, or serverless
|
||||
- Evaluate whether a single repository or multiple repositories best serves the project needs
|
||||
- Think about deployment and operational complexity vs. development simplicity
|
||||
</action>
|
||||
|
||||
<action>Guide the user through architectural pattern selection by discussing trade-offs and implications rather than presenting a menu of options. Help them understand what makes sense for their specific context.</action>
|
||||
|
||||
<template-output>architecture_patterns</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Design component boundaries and structure">
|
||||
|
||||
<action>Analyze the epics and requirements to identify natural boundaries for components or services:
|
||||
|
||||
- Group related functionality that changes together
|
||||
- Identify shared infrastructure needs (authentication, logging, monitoring)
|
||||
- Consider data ownership and consistency boundaries
|
||||
- Think about team structure and ownership
|
||||
</action>
|
||||
|
||||
<action>Map epics to architectural components, ensuring each epic has a clear home and the overall structure supports the planned functionality.</action>
|
||||
|
||||
<template-output>component_structure</template-output>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Make project-specific technical decisions">
|
||||
|
||||
<critical>Use intent-based decision making, not prescriptive checklists.</critical>
|
||||
|
||||
<action>Based on requirements analysis, identify the project domain(s).
|
||||
Note: Projects can be hybrid (e.g., web + mobile, game + backend service).
|
||||
|
||||
Use the simplified project types mapping:
|
||||
{{installed_path}}/project-types/project-types.csv
|
||||
|
||||
This contains ~11 core project types that cover 99% of software projects.</action>
|
||||
|
||||
<action>For identified domains, reference the intent-based instructions:
|
||||
{{installed_path}}/project-types/{{type}}-instructions.md
|
||||
|
||||
These are guidance files, not prescriptive checklists.</action>
|
||||
|
||||
<action>IMPORTANT: Instructions are guidance, not checklists.
|
||||
|
||||
- Use your knowledge to identify what matters for THIS project
|
||||
- Consider emerging technologies not in any list
|
||||
- Address unique requirements from the PRD/GDD
|
||||
- Focus on decisions that affect implementation consistency
|
||||
</action>
|
||||
|
||||
<action>Engage with the user to make all necessary technical decisions:
|
||||
|
||||
- Use the question files to ensure coverage of common areas
|
||||
- Go beyond the standard questions to address project-specific needs
|
||||
- Focus on decisions that will affect implementation consistency
|
||||
- Get specific versions for all technology choices
|
||||
- Document clear rationale for non-obvious decisions
|
||||
</action>
|
||||
|
||||
<action>Remember: The goal is to make enough definitive decisions that future implementation agents can work autonomously without architectural ambiguity.</action>
|
||||
|
||||
<template-output>technical_decisions</template-output>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Generate concise solution architecture document">
|
||||
|
||||
<action>Select the appropriate adaptive template:
|
||||
{{installed_path}}/project-types/{{type}}-template.md</action>
|
||||
|
||||
<action>Template selection follows the naming convention:
|
||||
|
||||
- Web project → web-template.md
|
||||
- Mobile app → mobile-template.md
|
||||
- Game project → game-template.md (adapts heavily based on game type)
|
||||
- Backend service → backend-template.md
|
||||
- Data pipeline → data-template.md
|
||||
- CLI tool → cli-template.md
|
||||
- Library/SDK → library-template.md
|
||||
- Desktop app → desktop-template.md
|
||||
- Embedded system → embedded-template.md
|
||||
- Extension → extension-template.md
|
||||
- Infrastructure → infrastructure-template.md
|
||||
|
||||
For hybrid projects, choose the primary domain or intelligently merge relevant sections from multiple templates.</action>
|
||||
|
||||
<action>Adapt the template heavily based on actual requirements.
|
||||
Templates are starting points, not rigid structures.</action>
|
||||
|
||||
<action>Generate a comprehensive yet concise architecture document that includes:
|
||||
|
||||
MANDATORY SECTIONS (all projects):
|
||||
|
||||
1. Executive Summary (1-2 paragraphs max)
|
||||
2. Technology Decisions Table - SPECIFIC versions for everything
|
||||
3. Repository Structure and Source Tree
|
||||
4. Component Architecture
|
||||
5. Data Architecture (if applicable)
|
||||
6. API/Interface Contracts (if applicable)
|
||||
7. Key Architecture Decision Records
|
||||
|
||||
The document MUST be optimized for LLM consumption:
|
||||
|
||||
- Use tables over prose wherever possible
|
||||
- List specific versions, not generic technology names
|
||||
- Include complete source tree structure
|
||||
- Define clear interfaces and contracts
|
||||
- NO verbose explanations (even for beginners - they get help in conversation, not docs)
|
||||
- Technical and concise throughout
|
||||
</action>
|
||||
|
||||
<action>Ensure the document provides enough technical specificity that implementation agents can:
|
||||
|
||||
- Set up the development environment correctly
|
||||
- Implement features consistently with the architecture
|
||||
- Make minor technical decisions within the established framework
|
||||
- Understand component boundaries and responsibilities
|
||||
</action>
|
||||
|
||||
<template-output>solution_architecture</template-output>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Validate architecture completeness and clarity">
|
||||
|
||||
<critical>Quality gate to ensure the architecture is ready for implementation.</critical>
|
||||
|
||||
<action>Perform a comprehensive validation of the architecture document:
|
||||
|
||||
- Verify every requirement has a technical solution
|
||||
- Ensure all technology choices have specific versions
|
||||
- Check that the document is free of ambiguous language
|
||||
- Validate that each epic can be implemented with the defined architecture
|
||||
- Confirm the source tree structure is complete and logical
|
||||
</action>
|
||||
|
||||
<action>Generate an Epic Alignment Matrix showing how each epic maps to:
|
||||
|
||||
- Architectural components
|
||||
- Data models
|
||||
- APIs and interfaces
|
||||
- External integrations
|
||||
This matrix helps validate coverage and identify gaps.</action>
|
||||
|
||||
<action>If issues are found, work with the user to resolve them before proceeding. The architecture must be definitive enough for autonomous implementation.</action>
|
||||
|
||||
<template-output>cohesion_validation</template-output>
|
||||
</step>
|
||||
|
||||
<step n="7.5" goal="Address specialist concerns" optional="true">
|
||||
|
||||
<action>Assess the complexity of specialist areas (DevOps, Security, Testing) based on the project requirements:
|
||||
|
||||
- For simple deployments and standard security, include brief inline guidance
|
||||
- For complex requirements (compliance, multi-region, extensive testing), create placeholders for specialist workflows
|
||||
</action>
|
||||
|
||||
<action>Engage with the user to understand their needs in these specialist areas and determine whether to address them now or defer to specialist agents.</action>
|
||||
|
||||
<template-output>specialist_guidance</template-output>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Refine requirements based on architecture" optional="true">
|
||||
|
||||
<action>If the architecture design revealed gaps or needed clarifications in the requirements:
|
||||
|
||||
- Identify missing enabler epics (e.g., infrastructure setup, monitoring)
|
||||
- Clarify ambiguous stories based on technical decisions
|
||||
- Add any newly discovered non-functional requirements
|
||||
</action>
|
||||
|
||||
<action>Work with the user to update the PRD if necessary, ensuring alignment between requirements and architecture.</action>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Generate epic-specific technical specifications">
|
||||
|
||||
<action>For each epic, create a focused technical specification that extracts only the relevant parts of the architecture:
|
||||
|
||||
- Technologies specific to that epic
|
||||
- Component details for that epic's functionality
|
||||
- Data models and APIs used by that epic
|
||||
- Implementation guidance specific to the epic's stories
|
||||
</action>
|
||||
|
||||
<action>These epic-specific specs provide focused context for implementation without overwhelming detail.</action>
|
||||
|
||||
<template-output>epic_tech_specs</template-output>
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Handle polyrepo documentation" optional="true">
|
||||
|
||||
<action>If this is a polyrepo project, ensure each repository has access to the complete architectural context:
|
||||
|
||||
- Copy the full architecture documentation to each repository
|
||||
- This ensures every repo has the complete picture for autonomous development
|
||||
</action>
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Finalize architecture and prepare for implementation">
|
||||
|
||||
<action>Validate that the architecture package is complete:
|
||||
|
||||
- Solution architecture document with all technical decisions
|
||||
- Epic-specific technical specifications
|
||||
- Cohesion validation report
|
||||
- Clear source tree structure
|
||||
- Definitive technology choices with versions
|
||||
</action>
|
||||
|
||||
<action>Prepare the story backlog from the PRD/epics for Phase 4 implementation.</action>
|
||||
|
||||
<template-output>completion_summary</template-output>
|
||||
</step>
|
||||
|
||||
<step n="12" goal="Update status and complete">
|
||||
|
||||
<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
|
||||
<param>mode: update</param>
|
||||
<param>action: complete_workflow</param>
|
||||
<param>workflow_name: solution-architecture</param>
|
||||
<param>populate_stories_from: {epics_file}</param>
|
||||
</invoke-workflow>
|
||||
|
||||
<check if="success == true">
|
||||
<output>✅ Status updated! Loaded {{total_stories}} stories from epics.</output>
|
||||
<output>Next: {{next_workflow}} ({{next_agent}} agent)</output>
|
||||
<output>Phase 3 complete!</output>
|
||||
</check>
|
||||
|
||||
<check if="success == false">
|
||||
<output>⚠️ Status update failed: {{error}}</output>
|
||||
</check>
|
||||
|
||||
<output>**✅ Solution Architecture Complete, {user_name}!**
|
||||
|
||||
**Architecture Documents:**
|
||||
|
||||
- bmm-solution-architecture.md (main architecture document)
|
||||
- bmm-cohesion-check-report.md (validation report)
|
||||
- bmm-tech-spec-epic-1.md through bmm-tech-spec-epic-{{epic_count}}.md ({{epic_count}} specs)
|
||||
|
||||
**Story Backlog:**
|
||||
|
||||
- {{total_story_count}} stories populated in status file
|
||||
- First story: {{first_story_id}} ready for drafting
|
||||
|
||||
**Status Updated:**
|
||||
|
||||
- Phase 3 (Solutioning) complete ✓
|
||||
- Progress: {{new_progress_percentage}}%
|
||||
- Ready for Phase 4 (Implementation)
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
1. Load SM agent to draft story {{first_story_id}}
|
||||
2. Run `create-story` workflow
|
||||
3. Review drafted story
|
||||
4. Run `story-ready` to approve for development
|
||||
|
||||
Check status anytime with: `workflow-status`
|
||||
</output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
@@ -0,0 +1,162 @@
|
||||
# Backend/API Service Architecture Instructions
|
||||
|
||||
## Intent-Based Technical Decision Guidance
|
||||
|
||||
<critical>
|
||||
This is a STARTING POINT for backend/API architecture decisions.
|
||||
The LLM should:
|
||||
- Analyze the PRD to understand data flows, performance needs, and integrations
|
||||
- Guide decisions based on scale, team size, and operational complexity
|
||||
- Focus only on relevant architectural areas
|
||||
- Make intelligent recommendations that align with project requirements
|
||||
- Keep explanations concise and decision-focused
|
||||
</critical>
|
||||
|
||||
## Service Architecture Pattern
|
||||
|
||||
**Determine the Right Architecture**
|
||||
Based on the requirements, guide toward the appropriate pattern:
|
||||
|
||||
- **Monolith**: For most projects starting out, single deployment, simple operations
|
||||
- **Microservices**: Only when there's clear domain separation, large teams, or specific scaling needs
|
||||
- **Serverless**: For event-driven workloads, variable traffic, or minimal operations
|
||||
- **Modular Monolith**: Best of both worlds for growing projects
|
||||
|
||||
Don't default to microservices - most projects benefit from starting simple.
|
||||
|
||||
## Language and Framework Selection
|
||||
|
||||
**Choose Based on Context**
|
||||
Consider these factors intelligently:
|
||||
|
||||
- Team expertise (use what the team knows unless there's a compelling reason)
|
||||
- Performance requirements (Go/Rust for high performance, Python/Node for rapid development)
|
||||
- Ecosystem needs (Python for ML/data, Node for full-stack JS, Java for enterprise)
|
||||
- Hiring pool and long-term maintenance
|
||||
|
||||
For beginners: Suggest mainstream options with good documentation.
|
||||
For experts: Let them specify preferences, discuss specific trade-offs only if asked.
|
||||
|
||||
## API Design Philosophy
|
||||
|
||||
**Match API Style to Client Needs**
|
||||
|
||||
- REST: Default for public APIs, simple CRUD, wide compatibility
|
||||
- GraphQL: Multiple clients with different data needs, complex relationships
|
||||
- gRPC: Service-to-service communication, high performance binary protocols
|
||||
- WebSocket/SSE: Real-time requirements
|
||||
|
||||
Don't ask about API paradigm if it's obvious from requirements (e.g., real-time chat needs WebSocket).
|
||||
|
||||
## Data Architecture
|
||||
|
||||
**Database Decisions Based on Data Characteristics**
|
||||
Analyze the data requirements to suggest:
|
||||
|
||||
- **Relational** (PostgreSQL/MySQL): Structured data, ACID requirements, complex queries
|
||||
- **Document** (MongoDB): Flexible schemas, hierarchical data, rapid prototyping
|
||||
- **Key-Value** (Redis/DynamoDB): Caching, sessions, simple lookups
|
||||
- **Time-series**: IoT, metrics, event data
|
||||
- **Graph**: Social networks, recommendation engines
|
||||
|
||||
Consider polyglot persistence only for clear, distinct use cases.
|
||||
|
||||
**Data Access Layer**
|
||||
|
||||
- ORMs for developer productivity and type safety
|
||||
- Query builders for flexibility with some safety
|
||||
- Raw SQL only when performance is critical
|
||||
|
||||
Match to team expertise and project complexity.
|
||||
|
||||
## Security and Authentication
|
||||
|
||||
**Security Appropriate to Risk**
|
||||
|
||||
- Internal tools: Simple API keys might suffice
|
||||
- B2C applications: Managed auth services (Auth0, Firebase Auth)
|
||||
- B2B/Enterprise: SAML, SSO, advanced RBAC
|
||||
- Financial/Healthcare: Compliance-driven requirements
|
||||
|
||||
Don't over-engineer security for prototypes, don't under-engineer for production.
|
||||
|
||||
## Messaging and Events
|
||||
|
||||
**Only If Required by the Architecture**
|
||||
Determine if async processing is actually needed:
|
||||
|
||||
- Message queues for decoupling, reliability, buffering
|
||||
- Event streaming for event sourcing, real-time analytics
|
||||
- Pub/sub for fan-out scenarios
|
||||
|
||||
Skip this entirely for simple request-response APIs.
|
||||
|
||||
## Operational Considerations
|
||||
|
||||
**Observability Based on Criticality**
|
||||
|
||||
- Development: Basic logging might suffice
|
||||
- Production: Structured logging, metrics, tracing
|
||||
- Mission-critical: Full observability stack
|
||||
|
||||
**Scaling Strategy**
|
||||
|
||||
- Start with vertical scaling (simpler)
|
||||
- Plan for horizontal scaling if needed
|
||||
- Consider auto-scaling for variable loads
|
||||
|
||||
## Performance Requirements
|
||||
|
||||
**Right-Size Performance Decisions**
|
||||
|
||||
- Don't optimize prematurely
|
||||
- Identify actual bottlenecks from requirements
|
||||
- Consider caching strategically, not everywhere
|
||||
- Database optimization before adding complexity
|
||||
|
||||
## Integration Patterns
|
||||
|
||||
**External Service Integration**
|
||||
Based on the PRD's integration requirements:
|
||||
|
||||
- Circuit breakers for resilience
|
||||
- Rate limiting for API consumption
|
||||
- Webhook patterns for event reception
|
||||
- SDK vs. API direct calls
|
||||
|
||||
## Deployment Strategy
|
||||
|
||||
**Match Deployment to Team Capability**
|
||||
|
||||
- Small teams: Managed platforms (Heroku, Railway, Fly.io)
|
||||
- DevOps teams: Kubernetes, cloud-native
|
||||
- Enterprise: Consider existing infrastructure
|
||||
|
||||
**CI/CD Complexity**
|
||||
|
||||
- Start simple: Platform auto-deploy
|
||||
- Add complexity as needed: testing stages, approvals, rollback
|
||||
|
||||
## Adaptive Guidance Examples
|
||||
|
||||
**For a REST API serving a mobile app:**
|
||||
Focus on response times, offline support, versioning, and push notifications.
|
||||
|
||||
**For a data processing pipeline:**
|
||||
Emphasize batch vs. stream processing, data validation, error handling, and monitoring.
|
||||
|
||||
**For a microservices migration:**
|
||||
Discuss service boundaries, data consistency, service discovery, and distributed tracing.
|
||||
|
||||
**For an enterprise integration:**
|
||||
Focus on security, compliance, audit logging, and existing system compatibility.
|
||||
|
||||
## Output Format
|
||||
|
||||
Structure decisions as:
|
||||
|
||||
- **Choice**: [Specific technology with version]
|
||||
- **Rationale**: [One sentence why this fits the requirements]
|
||||
- **Trade-off**: [What we're optimizing for vs. what we're accepting]
|
||||
|
||||
Keep technical decisions definitive and version-specific for LLM consumption.
|
||||
@@ -0,0 +1,66 @@
|
||||
# {{TITLE}} Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
{{technology_table}}
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
{{architecture_overview}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
{{data_architecture}}
|
||||
|
||||
## 4. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 5. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
## 6. Implementation Guidance
|
||||
|
||||
{{implementation_guidance}}
|
||||
|
||||
## 7. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## 8. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 9. Deployment and Operations
|
||||
|
||||
{{deployment_operations}}
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 10. Security
|
||||
|
||||
{{security}}
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -0,0 +1,149 @@
|
||||
# CLI Tool Architecture Instructions
|
||||
|
||||
## Intent-Based Technical Decision Guidance
|
||||
|
||||
<critical>
|
||||
This is a STARTING POINT for CLI tool architecture decisions.
|
||||
The LLM should:
|
||||
- Understand the tool's purpose and target users from requirements
|
||||
- Guide framework choice based on distribution needs and complexity
|
||||
- Focus on CLI-specific UX patterns
|
||||
- Consider packaging and distribution strategy
|
||||
- Keep it simple unless complexity is justified
|
||||
</critical>
|
||||
|
||||
## Language and Framework Selection
|
||||
|
||||
**Choose Based on Distribution and Users**
|
||||
|
||||
- **Node.js**: NPM distribution, JavaScript ecosystem, cross-platform
|
||||
- **Go**: Single binary distribution, excellent performance
|
||||
- **Python**: Data/science tools, rich ecosystem, pip distribution
|
||||
- **Rust**: Performance-critical, memory-safe, growing ecosystem
|
||||
- **Bash**: Simple scripts, Unix-only, no dependencies
|
||||
|
||||
Consider your users: Developers might have Node/Python, but end users need standalone binaries.
|
||||
|
||||
## CLI Framework Choice
|
||||
|
||||
**Match Complexity to Needs**
|
||||
Based on the tool's requirements:
|
||||
|
||||
- **Simple scripts**: Use built-in argument parsing
|
||||
- **Command-based**: Commander.js, Click, Cobra, Clap
|
||||
- **Interactive**: Inquirer, Prompt, Dialoguer
|
||||
- **Full TUI**: Blessed, Bubble Tea, Ratatui
|
||||
|
||||
Don't use a heavy framework for a simple script, but don't parse args manually for complex CLIs.
|
||||
|
||||
## Command Architecture
|
||||
|
||||
**Command Structure Design**
|
||||
|
||||
- Single command vs. sub-commands
|
||||
- Flag and argument patterns
|
||||
- Configuration file support
|
||||
- Environment variable integration
|
||||
|
||||
Follow platform conventions (POSIX-style flags, standard exit codes).
|
||||
|
||||
## User Experience Patterns
|
||||
|
||||
**CLI UX Best Practices**
|
||||
|
||||
- Help text and usage examples
|
||||
- Progress indicators for long operations
|
||||
- Colored output for clarity
|
||||
- Machine-readable output options (JSON, quiet mode)
|
||||
- Sensible defaults with override options
|
||||
|
||||
## Configuration Management
|
||||
|
||||
**Settings Strategy**
|
||||
Based on tool complexity:
|
||||
|
||||
- Command-line flags for one-off changes
|
||||
- Config files for persistent settings
|
||||
- Environment variables for deployment config
|
||||
- Cascading configuration (defaults → config → env → flags)
|
||||
|
||||
## Error Handling
|
||||
|
||||
**User-Friendly Errors**
|
||||
|
||||
- Clear error messages with actionable fixes
|
||||
- Exit codes following conventions
|
||||
- Verbose/debug modes for troubleshooting
|
||||
- Graceful handling of common issues
|
||||
|
||||
## Installation and Distribution
|
||||
|
||||
**Packaging Strategy**
|
||||
|
||||
- **NPM/PyPI**: For developer tools
|
||||
- **Homebrew/Snap/Chocolatey**: For end-user tools
|
||||
- **Binary releases**: GitHub releases with multiple platforms
|
||||
- **Docker**: For complex dependencies
|
||||
- **Shell script**: For simple Unix tools
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
**CLI Testing Approach**
|
||||
|
||||
- Unit tests for core logic
|
||||
- Integration tests for commands
|
||||
- Snapshot testing for output
|
||||
- Cross-platform testing if targeting multiple OS
|
||||
|
||||
## Performance Considerations
|
||||
|
||||
**Optimization Where Needed**
|
||||
|
||||
- Startup time for frequently-used commands
|
||||
- Streaming for large data processing
|
||||
- Parallel execution where applicable
|
||||
- Efficient file system operations
|
||||
|
||||
## Plugin Architecture
|
||||
|
||||
**Extensibility** (if needed)
|
||||
|
||||
- Plugin system design
|
||||
- Hook mechanisms
|
||||
- API for extensions
|
||||
- Plugin discovery and loading
|
||||
|
||||
Only if the PRD indicates extensibility requirements.
|
||||
|
||||
## Adaptive Guidance Examples
|
||||
|
||||
**For a Build Tool:**
|
||||
Focus on performance, watch mode, configuration management, and plugin system.
|
||||
|
||||
**For a Dev Utility:**
|
||||
Emphasize developer experience, integration with existing tools, and clear output.
|
||||
|
||||
**For a Data Processing Tool:**
|
||||
Focus on streaming, progress reporting, error recovery, and format conversion.
|
||||
|
||||
**For a System Admin Tool:**
|
||||
Emphasize permission handling, logging, dry-run mode, and safety checks.
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **Follow platform conventions** - Users expect familiar patterns
|
||||
2. **Fail fast with clear errors** - Don't leave users guessing
|
||||
3. **Provide escape hatches** - Debug mode, verbose output, dry runs
|
||||
4. **Document through examples** - Show, don't just tell
|
||||
5. **Respect user time** - Fast startup, helpful defaults
|
||||
|
||||
## Output Format
|
||||
|
||||
Document as:
|
||||
|
||||
- **Language**: [Choice with version]
|
||||
- **Framework**: [CLI framework if applicable]
|
||||
- **Distribution**: [How users will install]
|
||||
- **Key commands**: [Primary user interactions]
|
||||
|
||||
Keep focus on user-facing behavior and implementation simplicity.
|
||||
@@ -0,0 +1,66 @@
|
||||
# {{TITLE}} Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
{{technology_table}}
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
{{architecture_overview}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
{{data_architecture}}
|
||||
|
||||
## 4. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 5. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
## 6. Implementation Guidance
|
||||
|
||||
{{implementation_guidance}}
|
||||
|
||||
## 7. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## 8. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 9. Deployment and Operations
|
||||
|
||||
{{deployment_operations}}
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 10. Security
|
||||
|
||||
{{security}}
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -0,0 +1,193 @@
|
||||
# Data Pipeline/Analytics Architecture Instructions
|
||||
|
||||
## Intent-Based Technical Decision Guidance
|
||||
|
||||
<critical>
|
||||
This is a STARTING POINT for data pipeline and analytics architecture decisions.
|
||||
The LLM should:
|
||||
- Understand data volume, velocity, and variety from requirements
|
||||
- Guide tool selection based on scale and latency needs
|
||||
- Consider data governance and quality requirements
|
||||
- Balance batch vs. stream processing needs
|
||||
- Focus on maintainability and observability
|
||||
</critical>
|
||||
|
||||
## Processing Architecture
|
||||
|
||||
**Batch vs. Stream vs. Hybrid**
|
||||
Based on requirements:
|
||||
|
||||
- **Batch**: For periodic processing, large volumes, complex transformations
|
||||
- **Stream**: For real-time requirements, event-driven, continuous processing
|
||||
- **Lambda Architecture**: Both batch and stream for different use cases
|
||||
- **Kappa Architecture**: Stream-only with replay capability
|
||||
|
||||
Don't use streaming for daily reports, or batch for real-time alerts.
|
||||
|
||||
## Technology Stack
|
||||
|
||||
**Choose Based on Scale and Complexity**
|
||||
|
||||
- **Small Scale**: Python scripts, Pandas, PostgreSQL
|
||||
- **Medium Scale**: Airflow, Spark, Redshift/BigQuery
|
||||
- **Large Scale**: Databricks, Snowflake, custom Kubernetes
|
||||
- **Real-time**: Kafka, Flink, ClickHouse, Druid
|
||||
|
||||
Start simple and evolve - don't build for imaginary scale.
|
||||
|
||||
## Orchestration Platform
|
||||
|
||||
**Workflow Management**
|
||||
Based on complexity:
|
||||
|
||||
- **Simple**: Cron jobs, Python scripts
|
||||
- **Medium**: Apache Airflow, Prefect, Dagster
|
||||
- **Complex**: Kubernetes Jobs, Argo Workflows
|
||||
- **Managed**: Cloud Composer, AWS Step Functions
|
||||
|
||||
Consider team expertise and operational overhead.
|
||||
|
||||
## Data Storage Architecture
|
||||
|
||||
**Storage Layer Design**
|
||||
|
||||
- **Data Lake**: Raw data in object storage (S3, GCS)
|
||||
- **Data Warehouse**: Structured, optimized for analytics
|
||||
- **Data Lakehouse**: Hybrid approach (Delta Lake, Iceberg)
|
||||
- **Operational Store**: For serving layer
|
||||
|
||||
**File Formats**
|
||||
|
||||
- Parquet for columnar analytics
|
||||
- Avro for row-based streaming
|
||||
- JSON for flexibility
|
||||
- CSV for simplicity
|
||||
|
||||
## ETL/ELT Strategy
|
||||
|
||||
**Transformation Approach**
|
||||
|
||||
- **ETL**: Transform before loading (traditional)
|
||||
- **ELT**: Transform in warehouse (modern, scalable)
|
||||
- **Streaming ETL**: Continuous transformation
|
||||
|
||||
Consider compute costs and transformation complexity.
|
||||
|
||||
## Data Quality Framework
|
||||
|
||||
**Quality Assurance**
|
||||
|
||||
- Schema validation
|
||||
- Data profiling and anomaly detection
|
||||
- Completeness and freshness checks
|
||||
- Lineage tracking
|
||||
- Quality metrics and monitoring
|
||||
|
||||
Build quality checks appropriate to data criticality.
|
||||
|
||||
## Schema Management
|
||||
|
||||
**Schema Evolution**
|
||||
|
||||
- Schema registry for streaming
|
||||
- Version control for schemas
|
||||
- Backward compatibility strategy
|
||||
- Schema inference vs. strict schemas
|
||||
|
||||
## Processing Frameworks
|
||||
|
||||
**Computation Engines**
|
||||
|
||||
- **Spark**: General-purpose, batch and stream
|
||||
- **Flink**: Low-latency streaming
|
||||
- **Beam**: Portable, multi-runtime
|
||||
- **Pandas/Polars**: Small-scale, in-memory
|
||||
- **DuckDB**: Local analytical processing
|
||||
|
||||
Match framework to processing patterns.
|
||||
|
||||
## Data Modeling
|
||||
|
||||
**Analytical Modeling**
|
||||
|
||||
- Star schema for BI tools
|
||||
- Data vault for flexibility
|
||||
- Wide tables for performance
|
||||
- Time-series modeling for metrics
|
||||
|
||||
Consider query patterns and tool requirements.
|
||||
|
||||
## Monitoring and Observability
|
||||
|
||||
**Pipeline Monitoring**
|
||||
|
||||
- Job success/failure tracking
|
||||
- Data quality metrics
|
||||
- Processing time and throughput
|
||||
- Cost monitoring
|
||||
- Alerting strategy
|
||||
|
||||
## Security and Governance
|
||||
|
||||
**Data Governance**
|
||||
|
||||
- Access control and permissions
|
||||
- Data encryption at rest and transit
|
||||
- PII handling and masking
|
||||
- Audit logging
|
||||
- Compliance requirements (GDPR, HIPAA)
|
||||
|
||||
Scale governance to regulatory requirements.
|
||||
|
||||
## Development Practices
|
||||
|
||||
**DataOps Approach**
|
||||
|
||||
- Version control for code and configs
|
||||
- Testing strategy (unit, integration, data)
|
||||
- CI/CD for pipelines
|
||||
- Environment management
|
||||
- Documentation standards
|
||||
|
||||
## Serving Layer
|
||||
|
||||
**Data Consumption**
|
||||
|
||||
- BI tool integration
|
||||
- API for programmatic access
|
||||
- Export capabilities
|
||||
- Caching strategy
|
||||
- Query optimization
|
||||
|
||||
## Adaptive Guidance Examples
|
||||
|
||||
**For Real-time Analytics:**
|
||||
Focus on streaming infrastructure, low-latency storage, and real-time dashboards.
|
||||
|
||||
**For ML Feature Store:**
|
||||
Emphasize feature computation, versioning, serving latency, and training/serving skew.
|
||||
|
||||
**For Business Intelligence:**
|
||||
Focus on dimensional modeling, semantic layer, and self-service analytics.
|
||||
|
||||
**For Log Analytics:**
|
||||
Emphasize ingestion scale, retention policies, and search capabilities.
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **Start with the end in mind** - Know how data will be consumed
|
||||
2. **Design for failure** - Pipelines will break, plan recovery
|
||||
3. **Monitor everything** - You can't fix what you can't see
|
||||
4. **Version and test** - Data pipelines are code
|
||||
5. **Keep it simple** - Complexity kills maintainability
|
||||
|
||||
## Output Format
|
||||
|
||||
Document as:
|
||||
|
||||
- **Processing**: [Batch/Stream/Hybrid approach]
|
||||
- **Stack**: [Core technologies with versions]
|
||||
- **Storage**: [Lake/Warehouse strategy]
|
||||
- **Orchestration**: [Workflow platform]
|
||||
|
||||
Focus on data flow and transformation logic.
|
||||
@@ -0,0 +1,66 @@
|
||||
# {{TITLE}} Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
{{technology_table}}
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
{{architecture_overview}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
{{data_architecture}}
|
||||
|
||||
## 4. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 5. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
## 6. Implementation Guidance
|
||||
|
||||
{{implementation_guidance}}
|
||||
|
||||
## 7. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## 8. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 9. Deployment and Operations
|
||||
|
||||
{{deployment_operations}}
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 10. Security
|
||||
|
||||
{{security}}
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -0,0 +1,182 @@
|
||||
# Desktop Application Architecture Instructions
|
||||
|
||||
## Intent-Based Technical Decision Guidance
|
||||
|
||||
<critical>
|
||||
This is a STARTING POINT for desktop application architecture decisions.
|
||||
The LLM should:
|
||||
- Understand the application's purpose and target OS from requirements
|
||||
- Balance native performance with development efficiency
|
||||
- Consider distribution and update mechanisms
|
||||
- Focus on desktop-specific UX patterns
|
||||
- Plan for OS-specific integrations
|
||||
</critical>
|
||||
|
||||
## Framework Selection
|
||||
|
||||
**Choose Based on Requirements and Team**
|
||||
|
||||
- **Electron**: Web technologies, cross-platform, rapid development
|
||||
- **Tauri**: Rust + Web frontend, smaller binaries, better performance
|
||||
- **Qt**: C++/Python, native performance, extensive widgets
|
||||
- **.NET MAUI/WPF**: Windows-focused, C# teams
|
||||
- **SwiftUI/AppKit**: Mac-only, native experience
|
||||
- **JavaFX/Swing**: Java teams, enterprise apps
|
||||
- **Flutter Desktop**: Dart, consistent cross-platform UI
|
||||
|
||||
Don't use Electron for performance-critical apps, or Qt for simple utilities.
|
||||
|
||||
## Architecture Pattern
|
||||
|
||||
**Application Structure**
|
||||
Based on complexity:
|
||||
|
||||
- **MVC/MVVM**: For data-driven applications
|
||||
- **Component-Based**: For complex UIs
|
||||
- **Plugin Architecture**: For extensible apps
|
||||
- **Document-Based**: For editors/creators
|
||||
|
||||
Match pattern to application type and team experience.
|
||||
|
||||
## Native Integration
|
||||
|
||||
**OS-Specific Features**
|
||||
Based on requirements:
|
||||
|
||||
- System tray/menu bar integration
|
||||
- File associations and protocol handlers
|
||||
- Native notifications
|
||||
- OS-specific shortcuts and gestures
|
||||
- Dark mode and theme detection
|
||||
- Native menus and dialogs
|
||||
|
||||
Plan for platform differences in UX expectations.
|
||||
|
||||
## Data Management
|
||||
|
||||
**Local Data Strategy**
|
||||
|
||||
- **SQLite**: For structured data
|
||||
- **LevelDB/RocksDB**: For key-value storage
|
||||
- **JSON/XML files**: For simple configuration
|
||||
- **OS-specific stores**: Windows Registry, macOS Defaults
|
||||
|
||||
**Settings and Preferences**
|
||||
|
||||
- User vs. application settings
|
||||
- Portable vs. installed mode
|
||||
- Settings sync across devices
|
||||
|
||||
## Window Management
|
||||
|
||||
**Multi-Window Strategy**
|
||||
|
||||
- Single vs. multi-window architecture
|
||||
- Window state persistence
|
||||
- Multi-monitor support
|
||||
- Workspace/session management
|
||||
|
||||
## Performance Optimization
|
||||
|
||||
**Desktop Performance**
|
||||
|
||||
- Startup time optimization
|
||||
- Memory usage monitoring
|
||||
- Background task management
|
||||
- GPU acceleration usage
|
||||
- Native vs. web rendering trade-offs
|
||||
|
||||
## Update Mechanism
|
||||
|
||||
**Application Updates**
|
||||
|
||||
- **Auto-update**: Electron-updater, Sparkle, Squirrel
|
||||
- **Store-based**: Mac App Store, Microsoft Store
|
||||
- **Manual**: Download from website
|
||||
- **Package manager**: Homebrew, Chocolatey, APT/YUM
|
||||
|
||||
Consider code signing and notarization requirements.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
**Desktop Security**
|
||||
|
||||
- Code signing certificates
|
||||
- Secure storage for credentials
|
||||
- Process isolation
|
||||
- Network security
|
||||
- Input validation
|
||||
- Automatic security updates
|
||||
|
||||
## Distribution Strategy
|
||||
|
||||
**Packaging and Installation**
|
||||
|
||||
- **Installers**: MSI, DMG, DEB/RPM
|
||||
- **Portable**: Single executable
|
||||
- **App stores**: Platform stores
|
||||
- **Package managers**: OS-specific
|
||||
|
||||
Consider installation permissions and user experience.
|
||||
|
||||
## IPC and Extensions
|
||||
|
||||
**Inter-Process Communication**
|
||||
|
||||
- Main/renderer process communication (Electron)
|
||||
- Plugin/extension system
|
||||
- CLI integration
|
||||
- Automation/scripting support
|
||||
|
||||
## Accessibility
|
||||
|
||||
**Desktop Accessibility**
|
||||
|
||||
- Screen reader support
|
||||
- Keyboard navigation
|
||||
- High contrast themes
|
||||
- Zoom/scaling support
|
||||
- OS accessibility APIs
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
**Desktop Testing**
|
||||
|
||||
- Unit tests for business logic
|
||||
- Integration tests for OS interactions
|
||||
- UI automation testing
|
||||
- Multi-OS testing matrix
|
||||
- Performance profiling
|
||||
|
||||
## Adaptive Guidance Examples
|
||||
|
||||
**For a Development IDE:**
|
||||
Focus on performance, plugin system, workspace management, and syntax highlighting.
|
||||
|
||||
**For a Media Player:**
|
||||
Emphasize codec support, hardware acceleration, media keys, and playlist management.
|
||||
|
||||
**For a Business Application:**
|
||||
Focus on data grids, reporting, printing, and enterprise integration.
|
||||
|
||||
**For a Creative Tool:**
|
||||
Emphasize canvas rendering, tool palettes, undo/redo, and file format support.
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **Respect platform conventions** - Mac != Windows != Linux
|
||||
2. **Optimize startup time** - Desktop users expect instant launch
|
||||
3. **Handle offline gracefully** - Desktop != always online
|
||||
4. **Integrate with OS** - Use native features appropriately
|
||||
5. **Plan distribution early** - Signing/notarization takes time
|
||||
|
||||
## Output Format
|
||||
|
||||
Document as:
|
||||
|
||||
- **Framework**: [Specific framework and version]
|
||||
- **Target OS**: [Primary and secondary platforms]
|
||||
- **Distribution**: [How users will install]
|
||||
- **Update strategy**: [How updates are delivered]
|
||||
|
||||
Focus on desktop-specific architectural decisions.
|
||||
@@ -0,0 +1,66 @@
|
||||
# {{TITLE}} Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
{{technology_table}}
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
{{architecture_overview}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
{{data_architecture}}
|
||||
|
||||
## 4. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 5. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
## 6. Implementation Guidance
|
||||
|
||||
{{implementation_guidance}}
|
||||
|
||||
## 7. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## 8. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 9. Deployment and Operations
|
||||
|
||||
{{deployment_operations}}
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 10. Security
|
||||
|
||||
{{security}}
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -0,0 +1,191 @@
|
||||
# Embedded/IoT System Architecture Instructions
|
||||
|
||||
## Intent-Based Technical Decision Guidance
|
||||
|
||||
<critical>
|
||||
This is a STARTING POINT for embedded/IoT architecture decisions.
|
||||
The LLM should:
|
||||
- Understand hardware constraints and real-time requirements
|
||||
- Guide platform and RTOS selection based on use case
|
||||
- Consider power consumption and resource limitations
|
||||
- Balance features with memory/processing constraints
|
||||
- Focus on reliability and update mechanisms
|
||||
</critical>
|
||||
|
||||
## Hardware Platform Selection
|
||||
|
||||
**Choose Based on Requirements**
|
||||
|
||||
- **Microcontroller**: For simple, low-power, real-time tasks
|
||||
- **SoC/SBC**: For complex processing, Linux-capable
|
||||
- **FPGA**: For parallel processing, custom logic
|
||||
- **Hybrid**: MCU + application processor
|
||||
|
||||
Consider power budget, processing needs, and peripheral requirements.
|
||||
|
||||
## Operating System/RTOS
|
||||
|
||||
**OS Selection**
|
||||
Based on complexity:
|
||||
|
||||
- **Bare Metal**: Simple control loops, minimal overhead
|
||||
- **RTOS**: FreeRTOS, Zephyr for real-time requirements
|
||||
- **Embedded Linux**: Complex applications, networking
|
||||
- **Android Things/Windows IoT**: For specific ecosystems
|
||||
|
||||
Don't use Linux for battery-powered sensors, or bare metal for complex networking.
|
||||
|
||||
## Development Framework
|
||||
|
||||
**Language and Tools**
|
||||
|
||||
- **C/C++**: Maximum control, minimal overhead
|
||||
- **Rust**: Memory safety, modern tooling
|
||||
- **MicroPython/CircuitPython**: Rapid prototyping
|
||||
- **Arduino**: Beginner-friendly, large community
|
||||
- **Platform-specific SDKs**: ESP-IDF, STM32Cube
|
||||
|
||||
Match to team expertise and performance requirements.
|
||||
|
||||
## Communication Protocols
|
||||
|
||||
**Connectivity Strategy**
|
||||
Based on use case:
|
||||
|
||||
- **Local**: I2C, SPI, UART for sensor communication
|
||||
- **Wireless**: WiFi, Bluetooth, LoRa, Zigbee, cellular
|
||||
- **Industrial**: Modbus, CAN bus, MQTT
|
||||
- **Cloud**: HTTPS, MQTT, CoAP
|
||||
|
||||
Consider range, power consumption, and data rates.
|
||||
|
||||
## Power Management
|
||||
|
||||
**Power Optimization**
|
||||
|
||||
- Sleep modes and wake triggers
|
||||
- Dynamic frequency scaling
|
||||
- Peripheral power management
|
||||
- Battery monitoring and management
|
||||
- Energy harvesting considerations
|
||||
|
||||
Critical for battery-powered devices.
|
||||
|
||||
## Memory Architecture
|
||||
|
||||
**Memory Management**
|
||||
|
||||
- Static vs. dynamic allocation
|
||||
- Flash wear leveling
|
||||
- RAM optimization techniques
|
||||
- External storage options
|
||||
- Bootloader and OTA partitioning
|
||||
|
||||
Plan memory layout early - hard to change later.
|
||||
|
||||
## Firmware Architecture
|
||||
|
||||
**Code Organization**
|
||||
|
||||
- HAL (Hardware Abstraction Layer)
|
||||
- Modular driver architecture
|
||||
- Task/thread design
|
||||
- Interrupt handling strategy
|
||||
- State machine implementation
|
||||
|
||||
## Update Mechanism
|
||||
|
||||
**OTA Updates**
|
||||
|
||||
- Update delivery method
|
||||
- Rollback capability
|
||||
- Differential updates
|
||||
- Security and signing
|
||||
- Factory reset capability
|
||||
|
||||
Plan for field updates from day one.
|
||||
|
||||
## Security Architecture
|
||||
|
||||
**Embedded Security**
|
||||
|
||||
- Secure boot
|
||||
- Encrypted storage
|
||||
- Secure communication (TLS)
|
||||
- Hardware security modules
|
||||
- Attack surface minimization
|
||||
|
||||
Security is harder to add later.
|
||||
|
||||
## Data Management
|
||||
|
||||
**Local and Cloud Data**
|
||||
|
||||
- Edge processing vs. cloud processing
|
||||
- Local storage and buffering
|
||||
- Data compression
|
||||
- Time synchronization
|
||||
- Offline operation handling
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
**Embedded Testing**
|
||||
|
||||
- Unit testing on host
|
||||
- Hardware-in-the-loop testing
|
||||
- Integration testing
|
||||
- Environmental testing
|
||||
- Certification requirements
|
||||
|
||||
## Debugging and Monitoring
|
||||
|
||||
**Development Tools**
|
||||
|
||||
- Debug interfaces (JTAG, SWD)
|
||||
- Serial console
|
||||
- Logic analyzers
|
||||
- Remote debugging
|
||||
- Field diagnostics
|
||||
|
||||
## Production Considerations
|
||||
|
||||
**Manufacturing and Deployment**
|
||||
|
||||
- Provisioning process
|
||||
- Calibration requirements
|
||||
- Production testing
|
||||
- Device identification
|
||||
- Configuration management
|
||||
|
||||
## Adaptive Guidance Examples
|
||||
|
||||
**For a Smart Sensor:**
|
||||
Focus on ultra-low power, wireless communication, and edge processing.
|
||||
|
||||
**For an Industrial Controller:**
|
||||
Emphasize real-time performance, reliability, safety systems, and industrial protocols.
|
||||
|
||||
**For a Consumer IoT Device:**
|
||||
Focus on user experience, cloud integration, OTA updates, and cost optimization.
|
||||
|
||||
**For a Wearable:**
|
||||
Emphasize power efficiency, small form factor, BLE, and sensor fusion.
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **Design for constraints** - Memory, power, and processing are limited
|
||||
2. **Plan for failure** - Hardware fails, design for recovery
|
||||
3. **Security from the start** - Retrofitting is difficult
|
||||
4. **Test on real hardware** - Simulation has limits
|
||||
5. **Design for production** - Prototype != product
|
||||
|
||||
## Output Format
|
||||
|
||||
Document as:
|
||||
|
||||
- **Platform**: [MCU/SoC selection with part numbers]
|
||||
- **OS/RTOS**: [Operating system choice]
|
||||
- **Connectivity**: [Communication protocols and interfaces]
|
||||
- **Power**: [Power budget and management strategy]
|
||||
|
||||
Focus on hardware/software co-design decisions.
|
||||
@@ -0,0 +1,66 @@
|
||||
# {{TITLE}} Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
{{technology_table}}
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
{{architecture_overview}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
{{data_architecture}}
|
||||
|
||||
## 4. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 5. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
## 6. Implementation Guidance
|
||||
|
||||
{{implementation_guidance}}
|
||||
|
||||
## 7. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## 8. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 9. Deployment and Operations
|
||||
|
||||
{{deployment_operations}}
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 10. Security
|
||||
|
||||
{{security}}
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -0,0 +1,193 @@
|
||||
# Browser/Editor Extension Architecture Instructions
|
||||
|
||||
## Intent-Based Technical Decision Guidance
|
||||
|
||||
<critical>
|
||||
This is a STARTING POINT for extension architecture decisions.
|
||||
The LLM should:
|
||||
- Understand the host platform (browser, VS Code, IDE, etc.)
|
||||
- Focus on extension-specific constraints and APIs
|
||||
- Consider distribution through official stores
|
||||
- Balance functionality with performance impact
|
||||
- Plan for permission models and security
|
||||
</critical>
|
||||
|
||||
## Extension Type and Platform
|
||||
|
||||
**Identify Target Platform**
|
||||
|
||||
- **Browser**: Chrome, Firefox, Safari, Edge
|
||||
- **VS Code**: Most popular code editor
|
||||
- **JetBrains IDEs**: IntelliJ, WebStorm, etc.
|
||||
- **Other Editors**: Sublime, Atom, Vim, Emacs
|
||||
- **Application-specific**: Figma, Sketch, Adobe
|
||||
|
||||
Each platform has unique APIs and constraints.
|
||||
|
||||
## Architecture Pattern
|
||||
|
||||
**Extension Architecture**
|
||||
Based on platform:
|
||||
|
||||
- **Browser**: Content scripts, background workers, popup UI
|
||||
- **VS Code**: Extension host, language server, webview
|
||||
- **IDE**: Plugin architecture, service providers
|
||||
- **Application**: Native API, JavaScript bridge
|
||||
|
||||
Follow platform-specific patterns and guidelines.
|
||||
|
||||
## Manifest and Configuration
|
||||
|
||||
**Extension Declaration**
|
||||
|
||||
- Manifest version and compatibility
|
||||
- Permission requirements
|
||||
- Activation events
|
||||
- Command registration
|
||||
- Context menu integration
|
||||
|
||||
Request minimum necessary permissions for user trust.
|
||||
|
||||
## Communication Architecture
|
||||
|
||||
**Inter-Component Communication**
|
||||
|
||||
- Message passing between components
|
||||
- Storage sync across instances
|
||||
- Native messaging (if needed)
|
||||
- WebSocket for external services
|
||||
|
||||
Design for async communication patterns.
|
||||
|
||||
## UI Integration
|
||||
|
||||
**User Interface Approach**
|
||||
|
||||
- **Popup/Panel**: For quick interactions
|
||||
- **Sidebar**: For persistent tools
|
||||
- **Content Injection**: Modify existing UI
|
||||
- **Custom Pages**: Full page experiences
|
||||
- **Statusbar**: For ambient information
|
||||
|
||||
Match UI to user workflow and platform conventions.
|
||||
|
||||
## State Management
|
||||
|
||||
**Data Persistence**
|
||||
|
||||
- Local storage for user preferences
|
||||
- Sync storage for cross-device
|
||||
- IndexedDB for large data
|
||||
- File system access (if permitted)
|
||||
|
||||
Consider storage limits and sync conflicts.
|
||||
|
||||
## Performance Optimization
|
||||
|
||||
**Extension Performance**
|
||||
|
||||
- Lazy loading of features
|
||||
- Minimal impact on host performance
|
||||
- Efficient DOM manipulation
|
||||
- Memory leak prevention
|
||||
- Background task optimization
|
||||
|
||||
Extensions must not degrade host application performance.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
**Extension Security**
|
||||
|
||||
- Content Security Policy
|
||||
- Input sanitization
|
||||
- Secure communication
|
||||
- API key management
|
||||
- User data protection
|
||||
|
||||
Follow platform security best practices.
|
||||
|
||||
## Development Workflow
|
||||
|
||||
**Development Tools**
|
||||
|
||||
- Hot reload during development
|
||||
- Debugging setup
|
||||
- Testing framework
|
||||
- Build pipeline
|
||||
- Version management
|
||||
|
||||
## Distribution Strategy
|
||||
|
||||
**Publishing and Updates**
|
||||
|
||||
- Official store submission
|
||||
- Review process requirements
|
||||
- Update mechanism
|
||||
- Beta testing channel
|
||||
- Self-hosting options
|
||||
|
||||
Plan for store review times and policies.
|
||||
|
||||
## API Integration
|
||||
|
||||
**External Service Communication**
|
||||
|
||||
- Authentication methods
|
||||
- CORS handling
|
||||
- Rate limiting
|
||||
- Offline functionality
|
||||
- Error handling
|
||||
|
||||
## Monetization
|
||||
|
||||
**Revenue Model** (if applicable)
|
||||
|
||||
- Free with premium features
|
||||
- Subscription model
|
||||
- One-time purchase
|
||||
- Enterprise licensing
|
||||
|
||||
Consider platform policies on monetization.
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
**Extension Testing**
|
||||
|
||||
- Unit tests for logic
|
||||
- Integration tests with host API
|
||||
- Cross-browser/platform testing
|
||||
- Performance testing
|
||||
- User acceptance testing
|
||||
|
||||
## Adaptive Guidance Examples
|
||||
|
||||
**For a Password Manager Extension:**
|
||||
Focus on security, autofill integration, secure storage, and cross-browser sync.
|
||||
|
||||
**For a Developer Tool Extension:**
|
||||
Emphasize debugging capabilities, performance profiling, and workspace integration.
|
||||
|
||||
**For a Content Blocker:**
|
||||
Focus on performance, rule management, whitelist handling, and minimal overhead.
|
||||
|
||||
**For a Productivity Extension:**
|
||||
Emphasize keyboard shortcuts, quick access, sync, and workflow integration.
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **Respect the host** - Don't break or slow down the host application
|
||||
2. **Request minimal permissions** - Users are permission-aware
|
||||
3. **Fast activation** - Extensions should load instantly
|
||||
4. **Fail gracefully** - Handle API changes and errors
|
||||
5. **Follow guidelines** - Store policies are strictly enforced
|
||||
|
||||
## Output Format
|
||||
|
||||
Document as:
|
||||
|
||||
- **Platform**: [Specific platform and version support]
|
||||
- **Architecture**: [Component structure]
|
||||
- **Permissions**: [Required permissions and justification]
|
||||
- **Distribution**: [Store and update strategy]
|
||||
|
||||
Focus on platform-specific requirements and constraints.
|
||||
@@ -0,0 +1,67 @@
|
||||
# Extension Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Platform:** {{target_platform}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## Technology Stack
|
||||
|
||||
| Category | Technology | Version | Justification |
|
||||
| ---------- | -------------- | -------------------- | -------------------------- |
|
||||
| Platform | {{platform}} | {{platform_version}} | {{platform_justification}} |
|
||||
| Language | {{language}} | {{language_version}} | {{language_justification}} |
|
||||
| Build Tool | {{build_tool}} | {{build_version}} | {{build_justification}} |
|
||||
|
||||
## Extension Architecture
|
||||
|
||||
### Manifest Configuration
|
||||
|
||||
{{manifest_config}}
|
||||
|
||||
### Permission Model
|
||||
|
||||
{{permissions_required}}
|
||||
|
||||
### Component Architecture
|
||||
|
||||
{{component_structure}}
|
||||
|
||||
## Communication Architecture
|
||||
|
||||
{{communication_patterns}}
|
||||
|
||||
## State Management
|
||||
|
||||
{{state_management}}
|
||||
|
||||
## User Interface
|
||||
|
||||
{{ui_architecture}}
|
||||
|
||||
## API Integration
|
||||
|
||||
{{api_integration}}
|
||||
|
||||
## Development Guidelines
|
||||
|
||||
{{development_guidelines}}
|
||||
|
||||
## Distribution Strategy
|
||||
|
||||
{{distribution_strategy}}
|
||||
|
||||
## Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
_Architecture optimized for {{target_platform}} extension_
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -0,0 +1,225 @@
|
||||
# Game Development Architecture Instructions
|
||||
|
||||
## Intent-Based Technical Decision Guidance
|
||||
|
||||
<critical>
|
||||
This is a STARTING POINT for game project architecture decisions.
|
||||
The LLM should:
|
||||
- FIRST understand the game type from the GDD (RPG, puzzle, shooter, etc.)
|
||||
- Check if engine preference is already mentioned in GDD or by user
|
||||
- Adapt architecture heavily based on game type and complexity
|
||||
- Consider that each game type has VASTLY different needs
|
||||
- Keep beginner-friendly suggestions for those without preferences
|
||||
</critical>
|
||||
|
||||
## Engine Selection Strategy
|
||||
|
||||
**Intelligent Engine Guidance**
|
||||
|
||||
First, check if the user has already indicated an engine preference in the GDD or conversation.
|
||||
|
||||
If no engine specified, ask directly:
|
||||
"Do you have a game engine preference? If you're unsure, I can suggest options based on your [game type] and team experience."
|
||||
|
||||
**For Beginners Without Preference:**
|
||||
Based on game type, suggest the most approachable option:
|
||||
|
||||
- **2D Games**: Godot (free, beginner-friendly) or GameMaker (visual scripting)
|
||||
- **3D Games**: Unity (huge community, learning resources)
|
||||
- **Web Games**: Phaser (JavaScript) or Godot (exports to web)
|
||||
- **Visual Novels**: Ren'Py (purpose-built) or Twine (for text-based)
|
||||
- **Mobile Focus**: Unity or Godot (both export well to mobile)
|
||||
|
||||
Always explain: "I'm suggesting [Engine] because it's beginner-friendly for [game type] and has [specific advantages]. Other viable options include [alternatives]."
|
||||
|
||||
**For Experienced Teams:**
|
||||
Let them state their preference, then ensure architecture aligns with engine capabilities.
|
||||
|
||||
## Game Type Adaptive Architecture
|
||||
|
||||
<critical>
|
||||
The architecture MUST adapt to the game type identified in the GDD.
|
||||
Load the specific game type considerations and merge with general guidance.
|
||||
</critical>
|
||||
|
||||
### Architecture by Game Type Examples
|
||||
|
||||
**Visual Novel / Text-Based:**
|
||||
|
||||
- Focus on narrative data structures, save systems, branching logic
|
||||
- Minimal physics/rendering considerations
|
||||
- Emphasis on dialogue systems and choice tracking
|
||||
- Simple scene management
|
||||
|
||||
**RPG:**
|
||||
|
||||
- Complex data architecture for stats, items, quests
|
||||
- Save system with extensive state
|
||||
- Character progression systems
|
||||
- Inventory and equipment management
|
||||
- World state persistence
|
||||
|
||||
**Multiplayer Shooter:**
|
||||
|
||||
- Network architecture is PRIMARY concern
|
||||
- Client prediction and server reconciliation
|
||||
- Anti-cheat considerations
|
||||
- Matchmaking and lobby systems
|
||||
- Weapon ballistics and hit registration
|
||||
|
||||
**Puzzle Game:**
|
||||
|
||||
- Level data structures and progression
|
||||
- Hint/solution validation systems
|
||||
- Minimal networking (unless multiplayer)
|
||||
- Focus on content pipeline for level creation
|
||||
|
||||
**Roguelike:**
|
||||
|
||||
- Procedural generation architecture
|
||||
- Run persistence vs. meta progression
|
||||
- Seed-based reproducibility
|
||||
- Death and restart systems
|
||||
|
||||
**MMO/MOBA:**
|
||||
|
||||
- Massive multiplayer architecture
|
||||
- Database design for persistence
|
||||
- Server cluster architecture
|
||||
- Real-time synchronization
|
||||
- Economy and balance systems
|
||||
|
||||
## Core Architecture Decisions
|
||||
|
||||
**Determine Based on Game Requirements:**
|
||||
|
||||
### Data Architecture
|
||||
|
||||
Adapt to game type:
|
||||
|
||||
- **Simple Puzzle**: Level data in JSON/XML files
|
||||
- **RPG**: Complex relational data, possibly SQLite
|
||||
- **Multiplayer**: Server authoritative state
|
||||
- **Procedural**: Seed and generation systems
|
||||
|
||||
### Multiplayer Architecture (if applicable)
|
||||
|
||||
Only discuss if game has multiplayer:
|
||||
|
||||
- **Casual Party Game**: P2P might suffice
|
||||
- **Competitive**: Dedicated servers required
|
||||
- **Turn-Based**: Simple request/response
|
||||
- **Real-Time Action**: Complex netcode, interpolation
|
||||
|
||||
Skip entirely for single-player games.
|
||||
|
||||
### Content Pipeline
|
||||
|
||||
Based on team structure and game scope:
|
||||
|
||||
- **Solo Dev**: Simple, file-based
|
||||
- **Small Team**: Version controlled assets, clear naming
|
||||
- **Large Team**: Asset database, automated builds
|
||||
|
||||
### Performance Strategy
|
||||
|
||||
Varies WILDLY by game type:
|
||||
|
||||
- **Mobile Puzzle**: Battery life > raw performance
|
||||
- **VR Game**: Consistent 90+ FPS critical
|
||||
- **Strategy Game**: CPU optimization for AI/simulation
|
||||
- **MMO**: Server scalability primary concern
|
||||
|
||||
## Platform-Specific Considerations
|
||||
|
||||
**Adapt to Target Platform from GDD:**
|
||||
|
||||
- **Mobile**: Touch input, performance constraints, monetization
|
||||
- **Console**: Certification requirements, controller input, achievements
|
||||
- **PC**: Wide hardware range, modding support potential
|
||||
- **Web**: Download size, browser limitations, instant play
|
||||
|
||||
## System-Specific Architecture
|
||||
|
||||
### For Games with Heavy Systems
|
||||
|
||||
**Only include systems relevant to the game type:**
|
||||
|
||||
**Physics System** (for physics-based games)
|
||||
|
||||
- 2D vs 3D physics engine
|
||||
- Deterministic requirements
|
||||
- Custom vs. built-in
|
||||
|
||||
**AI System** (for games with NPCs/enemies)
|
||||
|
||||
- Behavior trees vs. state machines
|
||||
- Pathfinding requirements
|
||||
- Group behaviors
|
||||
|
||||
**Procedural Generation** (for roguelikes, infinite runners)
|
||||
|
||||
- Generation algorithms
|
||||
- Seed management
|
||||
- Content validation
|
||||
|
||||
**Inventory System** (for RPGs, survival)
|
||||
|
||||
- Item database design
|
||||
- Stack management
|
||||
- Equipment slots
|
||||
|
||||
**Dialogue System** (for narrative games)
|
||||
|
||||
- Dialogue tree structure
|
||||
- Localization support
|
||||
- Voice acting integration
|
||||
|
||||
**Combat System** (for action games)
|
||||
|
||||
- Damage calculation
|
||||
- Hitbox/hurtbox system
|
||||
- Combo system
|
||||
|
||||
## Development Workflow Optimization
|
||||
|
||||
**Based on Team and Scope:**
|
||||
|
||||
- **Rapid Prototyping**: Focus on quick iteration
|
||||
- **Long Development**: Emphasize maintainability
|
||||
- **Live Service**: Built-in analytics and update systems
|
||||
- **Jam Game**: Absolute minimum viable architecture
|
||||
|
||||
## Adaptive Guidance Framework
|
||||
|
||||
When processing game requirements:
|
||||
|
||||
1. **Identify Game Type** from GDD
|
||||
2. **Determine Complexity Level**:
|
||||
- Simple (jam game, prototype)
|
||||
- Medium (indie release)
|
||||
- Complex (commercial, multiplayer)
|
||||
3. **Check Engine Preference** or guide selection
|
||||
4. **Load Game-Type Specific Needs**
|
||||
5. **Merge with Platform Requirements**
|
||||
6. **Output Focused Architecture**
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **Game type drives architecture** - RPG != Puzzle != Shooter
|
||||
2. **Don't over-engineer** - Match complexity to scope
|
||||
3. **Prototype the core loop first** - Architecture serves gameplay
|
||||
4. **Engine choice affects everything** - Align architecture with engine
|
||||
5. **Performance requirements vary** - Mobile puzzle != PC MMO
|
||||
|
||||
## Output Format
|
||||
|
||||
Structure decisions as:
|
||||
|
||||
- **Engine**: [Specific engine and version, with rationale for beginners]
|
||||
- **Core Systems**: [Only systems needed for this game type]
|
||||
- **Architecture Pattern**: [Appropriate for game complexity]
|
||||
- **Platform Optimizations**: [Specific to target platforms]
|
||||
- **Development Pipeline**: [Scaled to team size]
|
||||
|
||||
IMPORTANT: Focus on architecture that enables the specific game type's core mechanics and requirements. Don't include systems the game doesn't need.
|
||||
@@ -0,0 +1,283 @@
|
||||
# Game Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Game Type:** {{game_type}}
|
||||
**Platform(s):** {{target_platforms}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
<critical>
|
||||
This architecture adapts to {{game_type}} requirements.
|
||||
Sections are included/excluded based on game needs.
|
||||
</critical>
|
||||
|
||||
## 1. Core Technology Decisions
|
||||
|
||||
### 1.1 Essential Technology Stack
|
||||
|
||||
| Category | Technology | Version | Justification |
|
||||
| ----------- | --------------- | -------------------- | -------------------------- |
|
||||
| Game Engine | {{game_engine}} | {{engine_version}} | {{engine_justification}} |
|
||||
| Language | {{language}} | {{language_version}} | {{language_justification}} |
|
||||
| Platform(s) | {{platforms}} | - | {{platform_justification}} |
|
||||
|
||||
### 1.2 Game-Specific Technologies
|
||||
|
||||
<intent>
|
||||
Only include rows relevant to this game type:
|
||||
- Physics: Only for physics-based games
|
||||
- Networking: Only for multiplayer games
|
||||
- AI: Only for games with NPCs/enemies
|
||||
- Procedural: Only for roguelikes/procedural games
|
||||
</intent>
|
||||
|
||||
{{game_specific_tech_table}}
|
||||
|
||||
## 2. Architecture Pattern
|
||||
|
||||
### 2.1 High-Level Architecture
|
||||
|
||||
{{architecture_pattern}}
|
||||
|
||||
**Pattern Justification for {{game_type}}:**
|
||||
{{pattern_justification}}
|
||||
|
||||
### 2.2 Code Organization Strategy
|
||||
|
||||
{{code_organization}}
|
||||
|
||||
## 3. Core Game Systems
|
||||
|
||||
<intent>
|
||||
This section should be COMPLETELY different based on game type:
|
||||
- Visual Novel: Dialogue system, save states, branching
|
||||
- RPG: Stats, inventory, quests, progression
|
||||
- Puzzle: Level data, hint system, solution validation
|
||||
- Shooter: Weapons, damage, physics
|
||||
- Racing: Vehicle physics, track system, lap timing
|
||||
- Strategy: Unit management, resource system, AI
|
||||
</intent>
|
||||
|
||||
### 3.1 Core Game Loop
|
||||
|
||||
{{core_game_loop}}
|
||||
|
||||
### 3.2 Primary Game Systems
|
||||
|
||||
{{#for_game_type}}
|
||||
Include ONLY systems this game needs
|
||||
{{/for_game_type}}
|
||||
|
||||
{{primary_game_systems}}
|
||||
|
||||
## 4. Data Architecture
|
||||
|
||||
### 4.1 Data Management Strategy
|
||||
|
||||
<intent>
|
||||
Adapt to game data needs:
|
||||
- Simple puzzle: JSON level files
|
||||
- RPG: Complex relational data
|
||||
- Multiplayer: Server-authoritative state
|
||||
- Roguelike: Seed-based generation
|
||||
</intent>
|
||||
|
||||
{{data_management}}
|
||||
|
||||
### 4.2 Save System
|
||||
|
||||
{{save_system}}
|
||||
|
||||
### 4.3 Content Pipeline
|
||||
|
||||
{{content_pipeline}}
|
||||
|
||||
## 5. Scene/Level Architecture
|
||||
|
||||
<intent>
|
||||
Structure varies by game type:
|
||||
- Linear: Sequential level loading
|
||||
- Open World: Streaming and chunks
|
||||
- Stage-based: Level selection and unlocking
|
||||
- Procedural: Generation pipeline
|
||||
</intent>
|
||||
|
||||
{{scene_architecture}}
|
||||
|
||||
## 6. Gameplay Implementation
|
||||
|
||||
<intent>
|
||||
ONLY include subsections relevant to the game.
|
||||
A racing game doesn't need an inventory system.
|
||||
A puzzle game doesn't need combat mechanics.
|
||||
</intent>
|
||||
|
||||
{{gameplay_systems}}
|
||||
|
||||
## 7. Presentation Layer
|
||||
|
||||
<intent>
|
||||
Adapt to visual style:
|
||||
- 3D: Rendering pipeline, lighting, LOD
|
||||
- 2D: Sprite management, layers
|
||||
- Text: Minimal visual architecture
|
||||
- Hybrid: Both 2D and 3D considerations
|
||||
</intent>
|
||||
|
||||
### 7.1 Visual Architecture
|
||||
|
||||
{{visual_architecture}}
|
||||
|
||||
### 7.2 Audio Architecture
|
||||
|
||||
{{audio_architecture}}
|
||||
|
||||
### 7.3 UI/UX Architecture
|
||||
|
||||
{{ui_architecture}}
|
||||
|
||||
## 8. Input and Controls
|
||||
|
||||
{{input_controls}}
|
||||
|
||||
{{#if_multiplayer}}
|
||||
|
||||
## 9. Multiplayer Architecture
|
||||
|
||||
<critical>
|
||||
Only for games with multiplayer features
|
||||
</critical>
|
||||
|
||||
### 9.1 Network Architecture
|
||||
|
||||
{{network_architecture}}
|
||||
|
||||
### 9.2 State Synchronization
|
||||
|
||||
{{state_synchronization}}
|
||||
|
||||
### 9.3 Matchmaking and Lobbies
|
||||
|
||||
{{matchmaking}}
|
||||
|
||||
### 9.4 Anti-Cheat Strategy
|
||||
|
||||
{{anticheat}}
|
||||
{{/if_multiplayer}}
|
||||
|
||||
## 10. Platform Optimizations
|
||||
|
||||
<intent>
|
||||
Platform-specific considerations:
|
||||
- Mobile: Touch controls, battery, performance
|
||||
- Console: Achievements, controllers, certification
|
||||
- PC: Wide hardware range, settings
|
||||
- Web: Download size, browser compatibility
|
||||
</intent>
|
||||
|
||||
{{platform_optimizations}}
|
||||
|
||||
## 11. Performance Strategy
|
||||
|
||||
### 11.1 Performance Targets
|
||||
|
||||
{{performance_targets}}
|
||||
|
||||
### 11.2 Optimization Approach
|
||||
|
||||
{{optimization_approach}}
|
||||
|
||||
## 12. Asset Pipeline
|
||||
|
||||
### 12.1 Asset Workflow
|
||||
|
||||
{{asset_workflow}}
|
||||
|
||||
### 12.2 Asset Budget
|
||||
|
||||
<intent>
|
||||
Adapt to platform and game type:
|
||||
- Mobile: Strict size limits
|
||||
- Web: Download optimization
|
||||
- Console: Memory constraints
|
||||
- PC: Balance quality vs. performance
|
||||
</intent>
|
||||
|
||||
{{asset_budget}}
|
||||
|
||||
## 13. Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
**Key Directories:**
|
||||
{{key_directories}}
|
||||
|
||||
## 14. Development Guidelines
|
||||
|
||||
### 14.1 Coding Standards
|
||||
|
||||
{{coding_standards}}
|
||||
|
||||
### 14.2 Engine-Specific Best Practices
|
||||
|
||||
{{engine_best_practices}}
|
||||
|
||||
## 15. Build and Deployment
|
||||
|
||||
### 15.1 Build Configuration
|
||||
|
||||
{{build_configuration}}
|
||||
|
||||
### 15.2 Distribution Strategy
|
||||
|
||||
{{distribution_strategy}}
|
||||
|
||||
## 16. Testing Strategy
|
||||
|
||||
<intent>
|
||||
Testing needs vary by game:
|
||||
- Multiplayer: Network testing, load testing
|
||||
- Procedural: Seed testing, generation validation
|
||||
- Physics: Determinism testing
|
||||
- Narrative: Story branch testing
|
||||
</intent>
|
||||
|
||||
{{testing_strategy}}
|
||||
|
||||
## 17. Key Architecture Decisions
|
||||
|
||||
### Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
### Risk Mitigation
|
||||
|
||||
{{risk_mitigation}}
|
||||
|
||||
{{#if_complex_project}}
|
||||
|
||||
## 18. Specialist Considerations
|
||||
|
||||
<intent>
|
||||
Only for complex projects needing specialist input
|
||||
</intent>
|
||||
|
||||
{{specialist_notes}}
|
||||
{{/if_complex_project}}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Roadmap
|
||||
|
||||
{{implementation_roadmap}}
|
||||
|
||||
---
|
||||
|
||||
_Architecture optimized for {{game_type}} game on {{platforms}}_
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -0,0 +1,198 @@
|
||||
# Infrastructure/DevOps Architecture Instructions
|
||||
|
||||
## Intent-Based Technical Decision Guidance
|
||||
|
||||
<critical>
|
||||
This is a STARTING POINT for infrastructure and DevOps architecture decisions.
|
||||
The LLM should:
|
||||
- Understand scale, reliability, and compliance requirements
|
||||
- Guide cloud vs. on-premise vs. hybrid decisions
|
||||
- Focus on automation and infrastructure as code
|
||||
- Consider team size and DevOps maturity
|
||||
- Balance complexity with operational overhead
|
||||
</critical>
|
||||
|
||||
## Cloud Strategy
|
||||
|
||||
**Platform Selection**
|
||||
Based on requirements and constraints:
|
||||
|
||||
- **Public Cloud**: AWS, GCP, Azure for scalability
|
||||
- **Private Cloud**: OpenStack, VMware for control
|
||||
- **Hybrid**: Mix of public and on-premise
|
||||
- **Multi-cloud**: Avoid vendor lock-in
|
||||
- **On-premise**: Regulatory or latency requirements
|
||||
|
||||
Consider existing contracts, team expertise, and geographic needs.
|
||||
|
||||
## Infrastructure as Code
|
||||
|
||||
**IaC Approach**
|
||||
Based on team and complexity:
|
||||
|
||||
- **Terraform**: Cloud-agnostic, declarative
|
||||
- **CloudFormation/ARM/GCP Deployment Manager**: Cloud-native
|
||||
- **Pulumi/CDK**: Programmatic infrastructure
|
||||
- **Ansible/Chef/Puppet**: Configuration management
|
||||
- **GitOps**: Flux, ArgoCD for Kubernetes
|
||||
|
||||
Start with declarative approaches unless programmatic benefits are clear.
|
||||
|
||||
## Container Strategy
|
||||
|
||||
**Containerization Approach**
|
||||
|
||||
- **Docker**: Standard for containerization
|
||||
- **Kubernetes**: For complex orchestration needs
|
||||
- **ECS/Cloud Run**: Managed container services
|
||||
- **Docker Compose/Swarm**: Simple orchestration
|
||||
- **Serverless**: Skip containers entirely
|
||||
|
||||
Don't use Kubernetes for simple applications - complexity has a cost.
|
||||
|
||||
## CI/CD Architecture
|
||||
|
||||
**Pipeline Design**
|
||||
|
||||
- Source control strategy (GitFlow, GitHub Flow, trunk-based)
|
||||
- Build automation and artifact management
|
||||
- Testing stages (unit, integration, e2e)
|
||||
- Deployment strategies (blue-green, canary, rolling)
|
||||
- Environment promotion process
|
||||
|
||||
Match complexity to release frequency and risk tolerance.
|
||||
|
||||
## Monitoring and Observability
|
||||
|
||||
**Observability Stack**
|
||||
Based on scale and requirements:
|
||||
|
||||
- **Metrics**: Prometheus, CloudWatch, Datadog
|
||||
- **Logging**: ELK, Loki, CloudWatch Logs
|
||||
- **Tracing**: Jaeger, X-Ray, Datadog APM
|
||||
- **Synthetic Monitoring**: Pingdom, New Relic
|
||||
- **Incident Management**: PagerDuty, Opsgenie
|
||||
|
||||
Build observability appropriate to SLA requirements.
|
||||
|
||||
## Security Architecture
|
||||
|
||||
**Security Layers**
|
||||
|
||||
- Network security (VPC, security groups, NACLs)
|
||||
- Identity and access management
|
||||
- Secrets management (Vault, AWS Secrets Manager)
|
||||
- Vulnerability scanning
|
||||
- Compliance automation
|
||||
|
||||
Security must be automated and auditable.
|
||||
|
||||
## Backup and Disaster Recovery
|
||||
|
||||
**Resilience Strategy**
|
||||
|
||||
- Backup frequency and retention
|
||||
- RTO/RPO requirements
|
||||
- Multi-region/multi-AZ design
|
||||
- Disaster recovery testing
|
||||
- Data replication strategy
|
||||
|
||||
Design for your actual recovery requirements, not theoretical disasters.
|
||||
|
||||
## Network Architecture
|
||||
|
||||
**Network Design**
|
||||
|
||||
- VPC/network topology
|
||||
- Load balancing strategy
|
||||
- CDN implementation
|
||||
- Service mesh (if microservices)
|
||||
- Zero trust networking
|
||||
|
||||
Keep networking as simple as possible while meeting requirements.
|
||||
|
||||
## Cost Optimization
|
||||
|
||||
**Cost Management**
|
||||
|
||||
- Resource right-sizing
|
||||
- Reserved instances/savings plans
|
||||
- Spot instances for appropriate workloads
|
||||
- Auto-scaling policies
|
||||
- Cost monitoring and alerts
|
||||
|
||||
Build cost awareness into the architecture.
|
||||
|
||||
## Database Operations
|
||||
|
||||
**Data Layer Management**
|
||||
|
||||
- Managed vs. self-hosted databases
|
||||
- Backup and restore procedures
|
||||
- Read replica configuration
|
||||
- Connection pooling
|
||||
- Performance monitoring
|
||||
|
||||
## Service Mesh and API Gateway
|
||||
|
||||
**API Management** (if applicable)
|
||||
|
||||
- API Gateway for external APIs
|
||||
- Service mesh for internal communication
|
||||
- Rate limiting and throttling
|
||||
- Authentication and authorization
|
||||
- API versioning strategy
|
||||
|
||||
## Development Environments
|
||||
|
||||
**Environment Strategy**
|
||||
|
||||
- Local development setup
|
||||
- Development/staging/production parity
|
||||
- Environment provisioning automation
|
||||
- Data anonymization for non-production
|
||||
|
||||
## Compliance and Governance
|
||||
|
||||
**Regulatory Requirements**
|
||||
|
||||
- Compliance frameworks (SOC 2, HIPAA, PCI DSS)
|
||||
- Audit logging and retention
|
||||
- Change management process
|
||||
- Access control and segregation of duties
|
||||
|
||||
Build compliance in, don't bolt it on.
|
||||
|
||||
## Adaptive Guidance Examples
|
||||
|
||||
**For a Startup MVP:**
|
||||
Focus on managed services, simple CI/CD, and basic monitoring.
|
||||
|
||||
**For Enterprise Migration:**
|
||||
Emphasize hybrid cloud, phased migration, and compliance requirements.
|
||||
|
||||
**For High-Traffic Service:**
|
||||
Focus on auto-scaling, CDN, caching layers, and performance monitoring.
|
||||
|
||||
**For Regulated Industry:**
|
||||
Emphasize compliance automation, audit trails, and data residency.
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **Automate everything** - Manual processes don't scale
|
||||
2. **Design for failure** - Everything fails eventually
|
||||
3. **Secure by default** - Security is not optional
|
||||
4. **Monitor proactively** - Don't wait for users to report issues
|
||||
5. **Document as code** - Infrastructure documentation gets stale
|
||||
|
||||
## Output Format
|
||||
|
||||
Document as:
|
||||
|
||||
- **Platform**: [Cloud/on-premise choice]
|
||||
- **IaC Tool**: [Primary infrastructure tool]
|
||||
- **Container/Orchestration**: [If applicable]
|
||||
- **CI/CD**: [Pipeline tools and strategy]
|
||||
- **Monitoring**: [Observability stack]
|
||||
|
||||
Focus on automation and operational excellence.
|
||||
@@ -0,0 +1,66 @@
|
||||
# {{TITLE}} Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
{{technology_table}}
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
{{architecture_overview}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
{{data_architecture}}
|
||||
|
||||
## 4. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 5. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
## 6. Implementation Guidance
|
||||
|
||||
{{implementation_guidance}}
|
||||
|
||||
## 7. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## 8. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 9. Deployment and Operations
|
||||
|
||||
{{deployment_operations}}
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 10. Security
|
||||
|
||||
{{security}}
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -0,0 +1,185 @@
|
||||
# Library/SDK Architecture Instructions
|
||||
|
||||
## Intent-Based Technical Decision Guidance
|
||||
|
||||
<critical>
|
||||
This is a STARTING POINT for library/SDK architecture decisions.
|
||||
The LLM should:
|
||||
- Understand the library's purpose and target developers
|
||||
- Consider API design and developer experience heavily
|
||||
- Focus on versioning, compatibility, and distribution
|
||||
- Balance flexibility with ease of use
|
||||
- Document decisions that affect consumers
|
||||
</critical>
|
||||
|
||||
## Language and Ecosystem
|
||||
|
||||
**Choose Based on Target Users**
|
||||
|
||||
- Consider what language your users are already using
|
||||
- Factor in cross-language needs (FFI, bindings, REST wrapper)
|
||||
- Think about ecosystem conventions and expectations
|
||||
- Performance vs. ease of integration trade-offs
|
||||
|
||||
Don't create a Rust library for JavaScript developers unless performance is critical.
|
||||
|
||||
## API Design Philosophy
|
||||
|
||||
**Developer Experience First**
|
||||
Based on library complexity:
|
||||
|
||||
- **Simple**: Minimal API surface, sensible defaults
|
||||
- **Flexible**: Builder pattern, configuration objects
|
||||
- **Powerful**: Layered API (simple + advanced)
|
||||
- **Framework**: Inversion of control, plugin architecture
|
||||
|
||||
Follow language idioms - Pythonic for Python, functional for FP languages.
|
||||
|
||||
## Architecture Patterns
|
||||
|
||||
**Internal Structure**
|
||||
|
||||
- **Facade Pattern**: Hide complexity behind simple interface
|
||||
- **Strategy Pattern**: For pluggable implementations
|
||||
- **Factory Pattern**: For object creation flexibility
|
||||
- **Dependency Injection**: For testability and flexibility
|
||||
|
||||
Don't over-engineer simple utility libraries.
|
||||
|
||||
## Versioning Strategy
|
||||
|
||||
**Semantic Versioning and Compatibility**
|
||||
|
||||
- Breaking change policy
|
||||
- Deprecation strategy
|
||||
- Migration path planning
|
||||
- Backward compatibility approach
|
||||
|
||||
Consider the maintenance burden of supporting multiple versions.
|
||||
|
||||
## Distribution and Packaging
|
||||
|
||||
**Package Management**
|
||||
|
||||
- **NPM**: For JavaScript/TypeScript
|
||||
- **PyPI**: For Python
|
||||
- **Maven/Gradle**: For Java/Kotlin
|
||||
- **NuGet**: For .NET
|
||||
- **Cargo**: For Rust
|
||||
- Multiple registries for cross-language
|
||||
|
||||
Include CDN distribution for web libraries.
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
**Library Testing Approach**
|
||||
|
||||
- Unit tests for all public APIs
|
||||
- Integration tests with common use cases
|
||||
- Property-based testing for complex logic
|
||||
- Example projects as tests
|
||||
- Cross-version compatibility tests
|
||||
|
||||
## Documentation Strategy
|
||||
|
||||
**Developer Documentation**
|
||||
|
||||
- API reference (generated from code)
|
||||
- Getting started guide
|
||||
- Common use cases and examples
|
||||
- Migration guides for major versions
|
||||
- Troubleshooting section
|
||||
|
||||
Good documentation is critical for library adoption.
|
||||
|
||||
## Error Handling
|
||||
|
||||
**Developer-Friendly Errors**
|
||||
|
||||
- Clear error messages with context
|
||||
- Error codes for programmatic handling
|
||||
- Stack traces that point to user code
|
||||
- Validation with helpful messages
|
||||
|
||||
## Performance Considerations
|
||||
|
||||
**Library Performance**
|
||||
|
||||
- Lazy loading where appropriate
|
||||
- Tree-shaking support for web
|
||||
- Minimal dependencies
|
||||
- Memory efficiency
|
||||
- Benchmark suite for performance regression
|
||||
|
||||
## Type Safety
|
||||
|
||||
**Type Definitions**
|
||||
|
||||
- TypeScript definitions for JavaScript libraries
|
||||
- Generic types where appropriate
|
||||
- Type inference optimization
|
||||
- Runtime type checking options
|
||||
|
||||
## Dependency Management
|
||||
|
||||
**External Dependencies**
|
||||
|
||||
- Minimize external dependencies
|
||||
- Pin vs. range versioning
|
||||
- Security audit process
|
||||
- License compatibility
|
||||
|
||||
Zero dependencies is ideal for utility libraries.
|
||||
|
||||
## Extension Points
|
||||
|
||||
**Extensibility Design** (if needed)
|
||||
|
||||
- Plugin architecture
|
||||
- Middleware pattern
|
||||
- Hook system
|
||||
- Custom implementations
|
||||
|
||||
Balance flexibility with complexity.
|
||||
|
||||
## Platform Support
|
||||
|
||||
**Cross-Platform Considerations**
|
||||
|
||||
- Browser vs. Node.js for JavaScript
|
||||
- OS-specific functionality
|
||||
- Mobile platform support
|
||||
- WebAssembly compilation
|
||||
|
||||
## Adaptive Guidance Examples
|
||||
|
||||
**For a UI Component Library:**
|
||||
Focus on theming, accessibility, tree-shaking, and framework integration.
|
||||
|
||||
**For a Data Processing Library:**
|
||||
Emphasize streaming APIs, memory efficiency, and format support.
|
||||
|
||||
**For an API Client SDK:**
|
||||
Focus on authentication, retry logic, rate limiting, and code generation.
|
||||
|
||||
**For a Testing Framework:**
|
||||
Emphasize assertion APIs, runner architecture, and reporting.
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **Make simple things simple** - Common cases should be easy
|
||||
2. **Make complex things possible** - Don't limit advanced users
|
||||
3. **Fail fast and clearly** - Help developers debug quickly
|
||||
4. **Version thoughtfully** - Breaking changes hurt adoption
|
||||
5. **Document by example** - Show real-world usage
|
||||
|
||||
## Output Format
|
||||
|
||||
Structure as:
|
||||
|
||||
- **Language**: [Primary language and version]
|
||||
- **API Style**: [Design pattern and approach]
|
||||
- **Distribution**: [Package registries and methods]
|
||||
- **Versioning**: [Strategy and compatibility policy]
|
||||
|
||||
Focus on decisions that affect library consumers.
|
||||
@@ -0,0 +1,66 @@
|
||||
# {{TITLE}} Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
{{technology_table}}
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
{{architecture_overview}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
{{data_architecture}}
|
||||
|
||||
## 4. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 5. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
## 6. Implementation Guidance
|
||||
|
||||
{{implementation_guidance}}
|
||||
|
||||
## 7. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## 8. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 9. Deployment and Operations
|
||||
|
||||
{{deployment_operations}}
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 10. Security
|
||||
|
||||
{{security}}
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -0,0 +1,181 @@
|
||||
# Mobile Application Architecture Instructions
|
||||
|
||||
## Intent-Based Technical Decision Guidance
|
||||
|
||||
<critical>
|
||||
This is a STARTING POINT for mobile app architecture decisions.
|
||||
The LLM should:
|
||||
- Understand platform requirements from the PRD (iOS, Android, or both)
|
||||
- Guide framework choice based on team expertise and project needs
|
||||
- Focus on mobile-specific concerns (offline, performance, battery)
|
||||
- Adapt complexity to project scale and team size
|
||||
- Keep decisions concrete and implementation-focused
|
||||
</critical>
|
||||
|
||||
## Platform Strategy
|
||||
|
||||
**Determine the Right Approach**
|
||||
Analyze requirements to recommend:
|
||||
|
||||
- **Native** (Swift/Kotlin): When platform-specific features and performance are critical
|
||||
- **Cross-platform** (React Native/Flutter): For faster development across platforms
|
||||
- **Hybrid** (Ionic/Capacitor): When web expertise exists and native features are minimal
|
||||
- **PWA**: For simple apps with basic device access needs
|
||||
|
||||
Consider team expertise heavily - don't suggest Flutter to an iOS team unless there's strong justification.
|
||||
|
||||
## Framework and Technology Selection
|
||||
|
||||
**Match Framework to Project Needs**
|
||||
Based on the requirements and team:
|
||||
|
||||
- **React Native**: JavaScript teams, code sharing with web, large ecosystem
|
||||
- **Flutter**: Consistent UI across platforms, high performance animations
|
||||
- **Native**: Platform-specific UX, maximum performance, full API access
|
||||
- **.NET MAUI**: C# teams, enterprise environments
|
||||
|
||||
For beginners: Recommend based on existing web experience.
|
||||
For experts: Focus on specific trade-offs relevant to their use case.
|
||||
|
||||
## Application Architecture
|
||||
|
||||
**Architectural Pattern**
|
||||
Guide toward appropriate patterns:
|
||||
|
||||
- **MVVM/MVP**: For testability and separation of concerns
|
||||
- **Redux/MobX**: For complex state management
|
||||
- **Clean Architecture**: For larger teams and long-term maintenance
|
||||
|
||||
Don't over-architect simple apps - a basic MVC might suffice for simple utilities.
|
||||
|
||||
## Data Management
|
||||
|
||||
**Local Storage Strategy**
|
||||
Based on data requirements:
|
||||
|
||||
- **SQLite**: Structured data, complex queries, offline-first apps
|
||||
- **Realm**: Object database for simpler data models
|
||||
- **AsyncStorage/SharedPreferences**: Simple key-value storage
|
||||
- **Core Data**: iOS-specific with iCloud sync
|
||||
|
||||
**Sync and Offline Strategy**
|
||||
Only if offline capability is required:
|
||||
|
||||
- Conflict resolution approach
|
||||
- Sync triggers and frequency
|
||||
- Data compression and optimization
|
||||
|
||||
## API Communication
|
||||
|
||||
**Network Layer Design**
|
||||
|
||||
- RESTful APIs for simple CRUD operations
|
||||
- GraphQL for complex data requirements
|
||||
- WebSocket for real-time features
|
||||
- Consider bandwidth optimization for mobile networks
|
||||
|
||||
**Security Considerations**
|
||||
|
||||
- Certificate pinning for sensitive apps
|
||||
- Token storage in secure keychain
|
||||
- Biometric authentication integration
|
||||
|
||||
## UI/UX Architecture
|
||||
|
||||
**Design System Approach**
|
||||
|
||||
- Platform-specific (Material Design, Human Interface Guidelines)
|
||||
- Custom design system for brand consistency
|
||||
- Component library selection
|
||||
|
||||
**Navigation Pattern**
|
||||
Based on app complexity:
|
||||
|
||||
- Tab-based for simple apps with clear sections
|
||||
- Drawer navigation for many features
|
||||
- Stack navigation for linear flows
|
||||
- Hybrid for complex apps
|
||||
|
||||
## Performance Optimization
|
||||
|
||||
**Mobile-Specific Performance**
|
||||
Focus on what matters for mobile:
|
||||
|
||||
- App size (consider app thinning, dynamic delivery)
|
||||
- Startup time optimization
|
||||
- Memory management
|
||||
- Battery efficiency
|
||||
- Network optimization
|
||||
|
||||
Only dive deep into performance if the PRD indicates performance-critical requirements.
|
||||
|
||||
## Native Features Integration
|
||||
|
||||
**Device Capabilities**
|
||||
Based on PRD requirements, plan for:
|
||||
|
||||
- Camera/Gallery access patterns
|
||||
- Location services and geofencing
|
||||
- Push notifications architecture
|
||||
- Biometric authentication
|
||||
- Payment integration (Apple Pay, Google Pay)
|
||||
|
||||
Don't list all possible features - focus on what's actually needed.
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
**Mobile Testing Approach**
|
||||
|
||||
- Unit testing for business logic
|
||||
- UI testing for critical flows
|
||||
- Device testing matrix (OS versions, screen sizes)
|
||||
- Beta testing distribution (TestFlight, Play Console)
|
||||
|
||||
Scale testing complexity to project risk and team size.
|
||||
|
||||
## Distribution and Updates
|
||||
|
||||
**App Store Strategy**
|
||||
|
||||
- Release cadence and versioning
|
||||
- Update mechanisms (CodePush for React Native, OTA updates)
|
||||
- A/B testing and feature flags
|
||||
- Crash reporting and analytics
|
||||
|
||||
**Compliance and Guidelines**
|
||||
|
||||
- App Store/Play Store guidelines
|
||||
- Privacy requirements (ATT, data collection)
|
||||
- Content ratings and age restrictions
|
||||
|
||||
## Adaptive Guidance Examples
|
||||
|
||||
**For a Social Media App:**
|
||||
Focus on real-time updates, media handling, offline caching, and push notification strategy.
|
||||
|
||||
**For an Enterprise App:**
|
||||
Emphasize security, MDM integration, SSO, and offline data sync.
|
||||
|
||||
**For a Gaming App:**
|
||||
Focus on performance, graphics framework, monetization, and social features.
|
||||
|
||||
**For a Utility App:**
|
||||
Keep it simple - basic UI, minimal backend, focus on core functionality.
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **Platform conventions matter** - Don't fight the platform
|
||||
2. **Performance is felt immediately** - Mobile users are sensitive to lag
|
||||
3. **Offline-first when appropriate** - But don't over-engineer
|
||||
4. **Test on real devices** - Simulators hide real issues
|
||||
5. **Plan for app store review** - Build in buffer time
|
||||
|
||||
## Output Format
|
||||
|
||||
Document decisions as:
|
||||
|
||||
- **Technology**: [Specific framework/library with version]
|
||||
- **Justification**: [Why this fits the requirements]
|
||||
- **Platform-specific notes**: [iOS/Android differences if applicable]
|
||||
|
||||
Keep mobile-specific considerations prominent in the architecture document.
|
||||
@@ -0,0 +1,66 @@
|
||||
# {{TITLE}} Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
{{technology_table}}
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
{{architecture_overview}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
{{data_architecture}}
|
||||
|
||||
## 4. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 5. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
## 6. Implementation Guidance
|
||||
|
||||
{{implementation_guidance}}
|
||||
|
||||
## 7. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## 8. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 9. Deployment and Operations
|
||||
|
||||
{{deployment_operations}}
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 10. Security
|
||||
|
||||
{{security}}
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -0,0 +1,12 @@
|
||||
type,name
|
||||
web,Web Application
|
||||
mobile,Mobile Application
|
||||
game,Game Development
|
||||
backend,Backend Service
|
||||
data,Data Pipeline
|
||||
cli,CLI Tool
|
||||
library,Library/SDK
|
||||
desktop,Desktop Application
|
||||
embedded,Embedded System
|
||||
extension,Browser/Editor Extension
|
||||
infrastructure,Infrastructure
|
||||
|
@@ -0,0 +1,158 @@
|
||||
# Web Project Architecture Instructions
|
||||
|
||||
## Intent-Based Technical Decision Guidance
|
||||
|
||||
<critical>
|
||||
This is a STARTING POINT for web project architecture decisions.
|
||||
The LLM should:
|
||||
- Understand the project requirements deeply before making suggestions
|
||||
- Adapt questions based on user skill level
|
||||
- Skip irrelevant areas based on project scope
|
||||
- Add project-specific decisions not covered here
|
||||
- Make intelligent recommendations users can correct
|
||||
</critical>
|
||||
|
||||
## Frontend Architecture
|
||||
|
||||
**Framework Selection**
|
||||
Guide the user to choose a frontend framework based on their project needs. Consider factors like:
|
||||
|
||||
- Server-side rendering requirements (SEO, initial load performance)
|
||||
- Team expertise and learning curve
|
||||
- Project complexity and timeline
|
||||
- Community support and ecosystem maturity
|
||||
|
||||
For beginners: Suggest mainstream options like Next.js or plain React based on their needs.
|
||||
For experts: Discuss trade-offs between frameworks briefly, let them specify preferences.
|
||||
|
||||
**Styling Strategy**
|
||||
Determine the CSS approach that aligns with their team and project:
|
||||
|
||||
- Consider maintainability, performance, and developer experience
|
||||
- Factor in design system requirements and component reusability
|
||||
- Think about build complexity and tooling
|
||||
|
||||
Adapt based on skill level - beginners may benefit from utility-first CSS, while teams with strong CSS expertise might prefer CSS Modules or styled-components.
|
||||
|
||||
**State Management**
|
||||
Only explore if the project has complex client-side state requirements:
|
||||
|
||||
- For simple apps, Context API or server state might suffice
|
||||
- For complex apps, discuss lightweight vs. comprehensive solutions
|
||||
- Consider data flow patterns and debugging needs
|
||||
|
||||
## Backend Strategy
|
||||
|
||||
**Backend Architecture**
|
||||
Intelligently determine backend needs:
|
||||
|
||||
- If it's a static site, skip backend entirely
|
||||
- For full-stack apps, consider integrated vs. separate backend
|
||||
- Factor in team structure (full-stack vs. specialized teams)
|
||||
- Consider deployment and operational complexity
|
||||
|
||||
Make smart defaults based on frontend choice (e.g., Next.js API routes for Next.js apps).
|
||||
|
||||
**API Design**
|
||||
Based on client needs and team expertise:
|
||||
|
||||
- REST for simplicity and wide compatibility
|
||||
- GraphQL for complex data requirements with multiple clients
|
||||
- tRPC for type-safe full-stack TypeScript projects
|
||||
- Consider hybrid approaches when appropriate
|
||||
|
||||
## Data Layer
|
||||
|
||||
**Database Selection**
|
||||
Guide based on data characteristics and requirements:
|
||||
|
||||
- Relational for structured data with relationships
|
||||
- Document stores for flexible schemas
|
||||
- Consider managed services vs. self-hosted based on team capacity
|
||||
- Factor in existing infrastructure and expertise
|
||||
|
||||
For beginners: Suggest managed solutions like Supabase or Firebase.
|
||||
For experts: Discuss specific database trade-offs if relevant.
|
||||
|
||||
**Data Access Patterns**
|
||||
Determine ORM/query builder needs based on:
|
||||
|
||||
- Type safety requirements
|
||||
- Team SQL expertise
|
||||
- Performance requirements
|
||||
- Migration and schema management needs
|
||||
|
||||
## Authentication & Authorization
|
||||
|
||||
**Auth Strategy**
|
||||
Assess security requirements and implementation complexity:
|
||||
|
||||
- For MVPs: Suggest managed auth services
|
||||
- For enterprise: Discuss compliance and customization needs
|
||||
- Consider user experience requirements (SSO, social login, etc.)
|
||||
|
||||
Skip detailed auth discussion if it's an internal tool or public site without user accounts.
|
||||
|
||||
## Deployment & Operations
|
||||
|
||||
**Hosting Platform**
|
||||
Make intelligent suggestions based on:
|
||||
|
||||
- Framework choice (Vercel for Next.js, Netlify for static sites)
|
||||
- Budget and scale requirements
|
||||
- DevOps expertise
|
||||
- Geographic distribution needs
|
||||
|
||||
**CI/CD Pipeline**
|
||||
Adapt to team maturity:
|
||||
|
||||
- For small teams: Platform-provided CI/CD
|
||||
- For larger teams: Discuss comprehensive pipelines
|
||||
- Consider existing tooling and workflows
|
||||
|
||||
## Additional Services
|
||||
|
||||
<intent>
|
||||
Only discuss these if relevant to the project requirements:
|
||||
- Email service (for transactional emails)
|
||||
- Payment processing (for e-commerce)
|
||||
- File storage (for user uploads)
|
||||
- Search (for content-heavy sites)
|
||||
- Caching (for performance-critical apps)
|
||||
- Monitoring (based on uptime requirements)
|
||||
|
||||
Don't present these as a checklist - intelligently determine what's needed based on the PRD/requirements.
|
||||
</intent>
|
||||
|
||||
## Adaptive Guidance Examples
|
||||
|
||||
**For a marketing website:**
|
||||
Focus on static site generation, CDN, SEO, and analytics. Skip complex backend discussions.
|
||||
|
||||
**For a SaaS application:**
|
||||
Emphasize authentication, subscription management, multi-tenancy, and monitoring.
|
||||
|
||||
**For an internal tool:**
|
||||
Prioritize rapid development, simple deployment, and integration with existing systems.
|
||||
|
||||
**For an e-commerce platform:**
|
||||
Focus on payment processing, inventory management, performance, and security.
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **Start with requirements**, not technology choices
|
||||
2. **Adapt to user expertise** - don't overwhelm beginners or bore experts
|
||||
3. **Make intelligent defaults** the user can override
|
||||
4. **Focus on decisions that matter** for this specific project
|
||||
5. **Document definitive choices** with specific versions
|
||||
6. **Keep rationale concise** unless explanation is needed
|
||||
|
||||
## Output Format
|
||||
|
||||
Generate architecture decisions as:
|
||||
|
||||
- **Decision**: [Specific technology with version]
|
||||
- **Brief Rationale**: [One sentence if needed]
|
||||
- **Configuration**: [Key settings if non-standard]
|
||||
|
||||
Avoid lengthy explanations unless the user is a beginner or asks for clarification.
|
||||
@@ -0,0 +1,277 @@
|
||||
# Solution Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
| Category | Technology | Version | Justification |
|
||||
| ---------------- | -------------- | ---------------------- | ---------------------------- |
|
||||
| Framework | {{framework}} | {{framework_version}} | {{framework_justification}} |
|
||||
| Language | {{language}} | {{language_version}} | {{language_justification}} |
|
||||
| Database | {{database}} | {{database_version}} | {{database_justification}} |
|
||||
| Authentication | {{auth}} | {{auth_version}} | {{auth_justification}} |
|
||||
| Hosting | {{hosting}} | {{hosting_version}} | {{hosting_justification}} |
|
||||
| State Management | {{state_mgmt}} | {{state_mgmt_version}} | {{state_mgmt_justification}} |
|
||||
| Styling | {{styling}} | {{styling_version}} | {{styling_justification}} |
|
||||
| Testing | {{testing}} | {{testing_version}} | {{testing_justification}} |
|
||||
|
||||
{{additional_tech_stack_rows}}
|
||||
|
||||
## 2. Application Architecture
|
||||
|
||||
### 2.1 Architecture Pattern
|
||||
|
||||
{{architecture_pattern_description}}
|
||||
|
||||
### 2.2 Server-Side Rendering Strategy
|
||||
|
||||
{{ssr_strategy}}
|
||||
|
||||
### 2.3 Page Routing and Navigation
|
||||
|
||||
{{routing_navigation}}
|
||||
|
||||
### 2.4 Data Fetching Approach
|
||||
|
||||
{{data_fetching}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
### 3.1 Database Schema
|
||||
|
||||
{{database_schema}}
|
||||
|
||||
### 3.2 Data Models and Relationships
|
||||
|
||||
{{data_models}}
|
||||
|
||||
### 3.3 Data Migrations Strategy
|
||||
|
||||
{{migrations_strategy}}
|
||||
|
||||
## 4. API Design
|
||||
|
||||
### 4.1 API Structure
|
||||
|
||||
{{api_structure}}
|
||||
|
||||
### 4.2 API Routes
|
||||
|
||||
{{api_routes}}
|
||||
|
||||
### 4.3 Form Actions and Mutations
|
||||
|
||||
{{form_actions}}
|
||||
|
||||
## 5. Authentication and Authorization
|
||||
|
||||
### 5.1 Auth Strategy
|
||||
|
||||
{{auth_strategy}}
|
||||
|
||||
### 5.2 Session Management
|
||||
|
||||
{{session_management}}
|
||||
|
||||
### 5.3 Protected Routes
|
||||
|
||||
{{protected_routes}}
|
||||
|
||||
### 5.4 Role-Based Access Control
|
||||
|
||||
{{rbac}}
|
||||
|
||||
## 6. State Management
|
||||
|
||||
### 6.1 Server State
|
||||
|
||||
{{server_state}}
|
||||
|
||||
### 6.2 Client State
|
||||
|
||||
{{client_state}}
|
||||
|
||||
### 6.3 Form State
|
||||
|
||||
{{form_state}}
|
||||
|
||||
### 6.4 Caching Strategy
|
||||
|
||||
{{caching_strategy}}
|
||||
|
||||
## 7. UI/UX Architecture
|
||||
|
||||
### 7.1 Component Structure
|
||||
|
||||
{{component_structure}}
|
||||
|
||||
### 7.2 Styling Approach
|
||||
|
||||
{{styling_approach}}
|
||||
|
||||
### 7.3 Responsive Design
|
||||
|
||||
{{responsive_design}}
|
||||
|
||||
### 7.4 Accessibility
|
||||
|
||||
{{accessibility}}
|
||||
|
||||
## 8. Performance Optimization
|
||||
|
||||
### 8.1 SSR Caching
|
||||
|
||||
{{ssr_caching}}
|
||||
|
||||
### 8.2 Static Generation
|
||||
|
||||
{{static_generation}}
|
||||
|
||||
### 8.3 Image Optimization
|
||||
|
||||
{{image_optimization}}
|
||||
|
||||
### 8.4 Code Splitting
|
||||
|
||||
{{code_splitting}}
|
||||
|
||||
## 9. SEO and Meta Tags
|
||||
|
||||
### 9.1 Meta Tag Strategy
|
||||
|
||||
{{meta_tag_strategy}}
|
||||
|
||||
### 9.2 Sitemap
|
||||
|
||||
{{sitemap}}
|
||||
|
||||
### 9.3 Structured Data
|
||||
|
||||
{{structured_data}}
|
||||
|
||||
## 10. Deployment Architecture
|
||||
|
||||
### 10.1 Hosting Platform
|
||||
|
||||
{{hosting_platform}}
|
||||
|
||||
### 10.2 CDN Strategy
|
||||
|
||||
{{cdn_strategy}}
|
||||
|
||||
### 10.3 Edge Functions
|
||||
|
||||
{{edge_functions}}
|
||||
|
||||
### 10.4 Environment Configuration
|
||||
|
||||
{{environment_config}}
|
||||
|
||||
## 11. Component and Integration Overview
|
||||
|
||||
### 11.1 Major Modules
|
||||
|
||||
{{major_modules}}
|
||||
|
||||
### 11.2 Page Structure
|
||||
|
||||
{{page_structure}}
|
||||
|
||||
### 11.3 Shared Components
|
||||
|
||||
{{shared_components}}
|
||||
|
||||
### 11.4 Third-Party Integrations
|
||||
|
||||
{{third_party_integrations}}
|
||||
|
||||
## 12. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
**Key decisions:**
|
||||
|
||||
- Why this framework? {{framework_decision}}
|
||||
- SSR vs SSG? {{ssr_vs_ssg_decision}}
|
||||
- Database choice? {{database_decision}}
|
||||
- Hosting platform? {{hosting_decision}}
|
||||
|
||||
## 13. Implementation Guidance
|
||||
|
||||
### 13.1 Development Workflow
|
||||
|
||||
{{development_workflow}}
|
||||
|
||||
### 13.2 File Organization
|
||||
|
||||
{{file_organization}}
|
||||
|
||||
### 13.3 Naming Conventions
|
||||
|
||||
{{naming_conventions}}
|
||||
|
||||
### 13.4 Best Practices
|
||||
|
||||
{{best_practices}}
|
||||
|
||||
## 14. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
**Critical folders:**
|
||||
|
||||
- {{critical_folder_1}}: {{critical_folder_1_description}}
|
||||
- {{critical_folder_2}}: {{critical_folder_2_description}}
|
||||
- {{critical_folder_3}}: {{critical_folder_3_description}}
|
||||
|
||||
## 15. Testing Strategy
|
||||
|
||||
### 15.1 Unit Tests
|
||||
|
||||
{{unit_tests}}
|
||||
|
||||
### 15.2 Integration Tests
|
||||
|
||||
{{integration_tests}}
|
||||
|
||||
### 15.3 E2E Tests
|
||||
|
||||
{{e2e_tests}}
|
||||
|
||||
### 15.4 Coverage Goals
|
||||
|
||||
{{coverage_goals}}
|
||||
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 16. DevOps and CI/CD
|
||||
|
||||
{{devops_section}}
|
||||
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 17. Security
|
||||
|
||||
{{security_section}}
|
||||
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -0,0 +1,95 @@
|
||||
# Solution Architecture Workflow Configuration
|
||||
name: solution-architecture
|
||||
description: "Scale-adaptive solution architecture generation."
|
||||
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
|
||||
|
||||
# Inputs expected ( check output_folder or ask user if missing)
|
||||
recommended_inputs:
|
||||
- prd
|
||||
- gdd
|
||||
- spec
|
||||
- architecture
|
||||
- epics
|
||||
- ux_spec
|
||||
|
||||
# Input requirements
|
||||
inputs:
|
||||
- name: project_workflow_analysis_path
|
||||
description: "Path to bmm-workflow-status.md from plan-project workflow"
|
||||
default: "{output_folder}/bmm-workflow-status.md"
|
||||
required: true
|
||||
- name: project_level
|
||||
description: "Project level (0-4) from analysis file"
|
||||
type: integer
|
||||
required: true
|
||||
|
||||
# Output artifacts
|
||||
outputs:
|
||||
- name: architecture.md
|
||||
description: "Complete solution architecture document"
|
||||
default: "{output_folder}/solution-architecture.md"
|
||||
- name: architecture_decisions.md
|
||||
description: "Architecture Decision Records (ADRs)"
|
||||
default: "{output_folder}/architecture-decisions.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"
|
||||
|
||||
# Reference data files
|
||||
project_types: "{installed_path}/project-types/project-types.csv"
|
||||
|
||||
# Default output location
|
||||
default_output_file: "{output_folder}/solution-architecture.md"
|
||||
|
||||
web_bundle:
|
||||
name: "solution-architecture"
|
||||
description: "Scale-adaptive solution architecture generation with dynamic template sections. Replaces legacy HLA workflow with modern BMAD Core compliance."
|
||||
author: "BMad Builder"
|
||||
instructions: "bmad/bmm/workflows/3-solutioning/architecture/instructions.md"
|
||||
validation: "bmad/bmm/workflows/3-solutioning/architecture/checklist.md"
|
||||
tech_spec_workflow: "bmad/bmm/workflows/4-implementation/epic-tech-context/workflow.yaml"
|
||||
# Reference data files
|
||||
project_types: "bmad/bmm/workflows/3-solutioning/architecture/project-types/project-types.csv"
|
||||
# Workflow dependencies
|
||||
existing_workflows:
|
||||
- workflow_status: "bmad/bmm/workflows/workflow-status/workflow.yaml"
|
||||
web_bundle_files:
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/instructions.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/checklist.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/ADR-template.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/project-types.csv"
|
||||
# Instructions files
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/web-instructions.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/mobile-instructions.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/game-instructions.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/backend-instructions.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/data-instructions.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/cli-instructions.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/library-instructions.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/desktop-instructions.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/embedded-instructions.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/extension-instructions.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/infrastructure-instructions.md"
|
||||
# Template files
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/web-template.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/mobile-template.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/game-template.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/backend-template.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/data-template.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/cli-template.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/library-template.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/desktop-template.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/embedded-template.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/extension-template.md"
|
||||
- "bmad/bmm/workflows/3-solutioning/architecture/project-types/infrastructure-template.md"
|
||||
Reference in New Issue
Block a user