hash file change checking integrated
This commit is contained in:
Brian Madison
@@ -1,74 +0,0 @@
|
||||
# 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_
|
||||
@@ -1,565 +0,0 @@
|
||||
# Solution Architecture Workflow
|
||||
|
||||
**Status:** Production-Ready | Scale-Adaptive Architecture Generation
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
This workflow generates comprehensive, scale-adaptive solution architecture documentation tailored to your project type, technology stack, and scale level (0-4).
|
||||
|
||||
**Unique Features:**
|
||||
|
||||
- ✅ **Scale-adaptive**: Level 0 = skip, Levels 1-4 = progressive depth
|
||||
- ✅ **Pattern-aware**: 171 technology combinations across 12 project types
|
||||
- ✅ **Template-driven**: 11 complete architecture document templates
|
||||
- ✅ **Engine-specific guidance**: Unity, Godot, Phaser, and more
|
||||
- ✅ **GDD/PRD aware**: Uses Game Design Doc for games, PRD for everything else
|
||||
- ✅ **ADR tracking**: Separate Architecture Decision Records document
|
||||
- ✅ **Specialist integration**: Pattern-specific specialist recommendations
|
||||
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
Run this workflow **AFTER** completing:
|
||||
|
||||
| Prerequisite | Required For | Location |
|
||||
| -------------------------- | ----------------------------- | ------------------------------------ |
|
||||
| **plan-project workflow** | All projects | `/docs/project-workflow-analysis.md` |
|
||||
| **PRD with epics/stories** | Level 1+ projects | `/docs/PRD.md` |
|
||||
| **GDD (for games)** | Game projects | `/docs/GDD.md` or `/docs/PRD.md` |
|
||||
| **UX Specification** | UI projects (web/mobile/game) | `/docs/ux-specification.md` |
|
||||
|
||||
---
|
||||
|
||||
## Quick Start
|
||||
|
||||
```bash
|
||||
workflow solution-architecture
|
||||
```
|
||||
|
||||
**The workflow will:**
|
||||
|
||||
1. Load `project-workflow-analysis.md` (from plan-project)
|
||||
2. Check prerequisites (PRD/GDD, UX spec if needed)
|
||||
3. Read requirements (PRD for apps, GDD for games)
|
||||
4. Ask architecture pattern questions
|
||||
5. Load appropriate template and guide
|
||||
6. Generate architecture + ADR documents
|
||||
7. Run cohesion check validation
|
||||
|
||||
---
|
||||
|
||||
## Outputs
|
||||
|
||||
### Primary Documents
|
||||
|
||||
| File | Purpose | Notes |
|
||||
| --------------------------- | ------------------------------------ | --------------------------------------------------- |
|
||||
| `solution-architecture.md` | Complete architecture document | Pattern-specific sections |
|
||||
| `architecture-decisions.md` | Architecture Decision Records (ADRs) | Tracks all decisions, options considered, rationale |
|
||||
|
||||
### Validation Outputs
|
||||
|
||||
| File | Purpose |
|
||||
| -------------------------- | ----------------------------------- |
|
||||
| `cohesion-check-report.md` | Validates 100% FR/NFR/Epic coverage |
|
||||
| `epic-alignment-matrix.md` | Maps epics → components/tech/APIs |
|
||||
|
||||
---
|
||||
|
||||
## Project Types and Templates
|
||||
|
||||
### 12 Project Types Supported
|
||||
|
||||
| Type | Examples | Template | Guide Examples |
|
||||
| ------------- | ---------------------------- | --------------------------------- | -------------------- |
|
||||
| **web** | Next.js, Rails, Django | web-fullstack-architecture.md | (TBD) |
|
||||
| **mobile** | React Native, Flutter, Swift | mobile-app-architecture.md | (TBD) |
|
||||
| **game** | Unity, Godot, Phaser | game-engine-architecture.md | Unity, Godot, Phaser |
|
||||
| **embedded** | ESP32, STM32, Raspberry Pi | embedded-firmware-architecture.md | (TBD) |
|
||||
| **backend** | Express, FastAPI, gRPC | backend-service-architecture.md | (TBD) |
|
||||
| **data** | Spark, Airflow, MLflow | data-pipeline-architecture.md | (TBD) |
|
||||
| **cli** | Commander, Click, Cobra | cli-tool-architecture.md | (TBD) |
|
||||
| **desktop** | Electron, Tauri, Qt | desktop-app-architecture.md | (TBD) |
|
||||
| **library** | npm, PyPI, cargo | library-package-architecture.md | (TBD) |
|
||||
| **infra** | Terraform, K8s Operator | infrastructure-architecture.md | (TBD) |
|
||||
| **extension** | Chrome, VS Code plugins | desktop-app-architecture.md | (TBD) |
|
||||
|
||||
### 171 Technology Combinations
|
||||
|
||||
The workflow maintains a registry (`templates/registry.csv`) with 171 pre-defined technology stack combinations:
|
||||
|
||||
**Examples:**
|
||||
|
||||
- `web-nextjs-ssr-monorepo` → Next.js SSR, TypeScript, monorepo
|
||||
- `game-unity-3d` → Unity 3D, C#, monorepo
|
||||
- `mobile-react-native` → React Native, TypeScript, cross-platform
|
||||
- `backend-fastapi-rest` → FastAPI, Python, REST API
|
||||
- `data-ml-training` → PyTorch/TensorFlow, Python, ML pipeline
|
||||
|
||||
Each row maps to:
|
||||
|
||||
- **template_path**: Architecture document structure (11 templates)
|
||||
- **guide_path**: Engine/framework-specific guidance (optional)
|
||||
|
||||
---
|
||||
|
||||
## Architecture Flow
|
||||
|
||||
### Step 0: Prerequisites and Scale Check
|
||||
|
||||
Load `project-workflow-analysis.md`:
|
||||
|
||||
- Extract: `project_level` (0-4), `project_type` (web/game/mobile/etc.), `field_type` (greenfield/brownfield)
|
||||
- Validate: PRD exists, UX spec exists (if UI project)
|
||||
- **Skip if Level 0** (single atomic change)
|
||||
|
||||
### Step 1: Requirements Analysis
|
||||
|
||||
**For Games:**
|
||||
|
||||
- Read **GDD** (Game Design Document)
|
||||
- Extract: gameplay mechanics, engine (Unity/Godot/etc.), platform, multiplayer
|
||||
|
||||
**For Everything Else:**
|
||||
|
||||
- Read **PRD** (Product Requirements Document)
|
||||
- Extract: FRs, NFRs, epics, stories, integrations
|
||||
|
||||
**For UI Projects:**
|
||||
|
||||
- Read **UX Specification**
|
||||
- Extract: screens, flows, component patterns
|
||||
|
||||
### Step 2: User Skill Level
|
||||
|
||||
Ask user: Beginner / Intermediate / Expert
|
||||
|
||||
- Affects verbosity of generated architecture
|
||||
|
||||
### Step 3: Architecture Pattern
|
||||
|
||||
Determine:
|
||||
|
||||
- Architecture style (monolith, microservices, serverless, etc.)
|
||||
- Repository strategy (monorepo, polyrepo, hybrid)
|
||||
- Pattern-specific choices (SSR for web, native vs cross-platform for mobile)
|
||||
|
||||
### Step 4: Epic Analysis
|
||||
|
||||
Analyze PRD epics:
|
||||
|
||||
- Identify component boundaries
|
||||
- Map domain capabilities
|
||||
- Determine service boundaries (if microservices)
|
||||
|
||||
### Step 5: Project-Type Questions
|
||||
|
||||
Load: `project-types/{project_type}-questions.md`
|
||||
|
||||
- Ask project-type-specific questions (not yet engine-specific)
|
||||
|
||||
### Step 6: Load Template + Guide
|
||||
|
||||
**6.1: Search Registry**
|
||||
|
||||
```
|
||||
Read: templates/registry.csv
|
||||
Match WHERE:
|
||||
- project_types = {determined_type}
|
||||
- languages = {preferred_languages}
|
||||
- architecture_style = {determined_style}
|
||||
- tags overlap with {requirements}
|
||||
|
||||
Get: template_path, guide_path
|
||||
```
|
||||
|
||||
**6.2: Load Template**
|
||||
|
||||
```
|
||||
Read: templates/{template_path}
|
||||
Example: templates/game-engine-architecture.md
|
||||
|
||||
This is a COMPLETE document structure with:
|
||||
- Standard sections (exec summary, tech stack, data arch, etc.)
|
||||
- Pattern-specific sections (Gameplay Systems for games, SSR Strategy for web)
|
||||
- All {{placeholders}} to fill
|
||||
```
|
||||
|
||||
**6.3: Load Guide (if available)**
|
||||
|
||||
```
|
||||
IF guide_path not empty:
|
||||
Read: templates/{guide_path}
|
||||
Example: templates/game-engine-unity-guide.md
|
||||
|
||||
Guide contains:
|
||||
- Engine/framework-specific questions
|
||||
- Architecture patterns for this tech
|
||||
- Common pitfalls
|
||||
- Specialist recommendations
|
||||
- ADR templates
|
||||
```
|
||||
|
||||
**Example Flow for Unity Game:**
|
||||
|
||||
1. GDD says "Unity 2022 LTS"
|
||||
2. Registry match: `game-unity-3d` → `game-engine-architecture.md` + `game-engine-unity-guide.md`
|
||||
3. Load complete game architecture template
|
||||
4. Load Unity-specific guide
|
||||
5. Ask Unity-specific questions (MonoBehaviour vs ECS, ScriptableObjects, etc.)
|
||||
6. Fill template placeholders
|
||||
7. Generate `solution-architecture.md` + `architecture-decisions.md`
|
||||
|
||||
### Step 7: Cohesion Check
|
||||
|
||||
Validate architecture quality:
|
||||
|
||||
- 100% FR/NFR/Epic/Story coverage
|
||||
- Technology table has specific versions
|
||||
- No vagueness ("a library", "some framework")
|
||||
- Design-level only (no implementation code)
|
||||
- Generate Epic Alignment Matrix
|
||||
|
||||
---
|
||||
|
||||
## File Structure
|
||||
|
||||
```
|
||||
/solution-architecture/
|
||||
├── README.md # This file
|
||||
├── workflow.yaml # Workflow configuration
|
||||
├── instructions.md # Main workflow logic
|
||||
├── checklist.md # Validation checklist
|
||||
├── ADR-template.md # ADR document template
|
||||
├── templates/ # Architecture templates and guides
|
||||
│ ├── registry.csv # 171 tech combinations → templates
|
||||
│ ├── game-engine-architecture.md # Complete game architecture doc
|
||||
│ ├── game-engine-unity-guide.md # Unity-specific guidance
|
||||
│ ├── game-engine-godot-guide.md # Godot-specific guidance
|
||||
│ ├── game-engine-web-guide.md # Phaser/PixiJS/Three.js guidance
|
||||
│ ├── web-fullstack-architecture.md
|
||||
│ ├── web-api-architecture.md
|
||||
│ ├── mobile-app-architecture.md
|
||||
│ ├── embedded-firmware-architecture.md
|
||||
│ ├── backend-service-architecture.md
|
||||
│ ├── data-pipeline-architecture.md
|
||||
│ ├── cli-tool-architecture.md
|
||||
│ ├── desktop-app-architecture.md
|
||||
│ ├── library-package-architecture.md
|
||||
│ └── infrastructure-architecture.md
|
||||
└── project-types/ # Project type detection and questions
|
||||
├── project-types.csv # 12 project types + detection keywords
|
||||
├── game-questions.md
|
||||
├── web-questions.md
|
||||
├── mobile-questions.md
|
||||
└── ... (12 question files)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template System
|
||||
|
||||
### Complete, Standalone Templates
|
||||
|
||||
Each template in `templates/` is a **complete** architecture document structure:
|
||||
|
||||
**Standard Sections (all templates):**
|
||||
|
||||
1. Executive Summary
|
||||
2. Technology Stack and Decisions (required table)
|
||||
3. Architecture Overview
|
||||
4. Repository and Service Strategy
|
||||
5. Data Architecture
|
||||
6. Component and Integration Overview
|
||||
7-N. **Pattern-Specific Sections** (varies by template)
|
||||
N+1. Proposed Source Tree
|
||||
N+2. Getting Started (Human Setup)
|
||||
N+3. Implementation Patterns and Conventions (Agent Guidance)
|
||||
N+4. Testing Strategy
|
||||
N+5. Deployment and Operations
|
||||
N+6. Security
|
||||
N+7. Specialist Sections
|
||||
|
||||
**Pattern-Specific Sections Examples:**
|
||||
|
||||
**Game Engine Template:**
|
||||
|
||||
- Gameplay Systems (player controller, game state)
|
||||
- Scene Architecture
|
||||
- Asset Pipeline
|
||||
- Audio Architecture
|
||||
- Save System
|
||||
- Multiplayer Architecture (if applicable)
|
||||
|
||||
**Web Fullstack Template:**
|
||||
|
||||
- Frontend Architecture
|
||||
- Backend Architecture
|
||||
- API Design (REST/GraphQL/tRPC)
|
||||
- State Management
|
||||
- SSR/Caching Strategy
|
||||
- Performance Optimization
|
||||
|
||||
**Embedded Firmware Template:**
|
||||
|
||||
- Hardware Architecture
|
||||
- Communication Protocols
|
||||
- Power Management
|
||||
- Sensor/Actuator Integration
|
||||
- OTA Update Strategy
|
||||
|
||||
---
|
||||
|
||||
## Guide System
|
||||
|
||||
### Engine/Framework-Specific Guides
|
||||
|
||||
Guides are **workflow instruction documents** that:
|
||||
|
||||
- Ask engine-specific questions
|
||||
- Provide architecture pattern recommendations
|
||||
- Suggest what sections to emphasize
|
||||
- Define ADRs to create
|
||||
|
||||
**Guides are NOT:**
|
||||
|
||||
- ❌ Reference documentation (use official docs)
|
||||
- ❌ Tutorials (how to code)
|
||||
- ❌ API references
|
||||
|
||||
**Guides ARE:**
|
||||
|
||||
- ✅ Question flows for architecture decisions
|
||||
- ✅ Pattern recommendations specific to the tech
|
||||
- ✅ Common pitfalls to avoid
|
||||
- ✅ Specialist recommendations
|
||||
|
||||
**Example: game-engine-unity-guide.md**
|
||||
|
||||
```markdown
|
||||
## Unity Architecture Questions
|
||||
|
||||
- MonoBehaviour or ECS?
|
||||
- ScriptableObjects for game data?
|
||||
- Addressables or Resources?
|
||||
|
||||
## Unity Patterns
|
||||
|
||||
- Singleton GameManager (when to use)
|
||||
- Event-driven communication
|
||||
- Object pooling strategy
|
||||
|
||||
## Unity-Specific Sections to Include
|
||||
|
||||
- Unity Project Configuration
|
||||
- Scene Architecture
|
||||
- Component Organization
|
||||
- Package Dependencies
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Caching GetComponent calls
|
||||
- Avoiding empty Update methods
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ADR Tracking
|
||||
|
||||
Architecture Decision Records are maintained separately in `architecture-decisions.md`.
|
||||
|
||||
**ADR Format:**
|
||||
|
||||
```markdown
|
||||
### ADR-001: [Decision Title]
|
||||
|
||||
**Date:** YYYY-MM-DD
|
||||
**Status:** Accepted | Rejected | Superseded
|
||||
**Decider:** User | Agent | Collaborative
|
||||
|
||||
**Context:**
|
||||
What problem are we solving?
|
||||
|
||||
**Options Considered:**
|
||||
|
||||
1. Option A - pros/cons
|
||||
2. Option B - pros/cons
|
||||
3. Option C - pros/cons
|
||||
|
||||
**Decision:**
|
||||
We chose Option X
|
||||
|
||||
**Rationale:**
|
||||
Why we chose this over others
|
||||
|
||||
**Consequences:**
|
||||
|
||||
- Positive: ...
|
||||
- Negative: ...
|
||||
|
||||
**Rejected Options:**
|
||||
|
||||
- Option A rejected because: ...
|
||||
```
|
||||
|
||||
**ADRs are populated throughout the workflow** as decisions are made:
|
||||
|
||||
- Step 3: Architecture pattern ADR
|
||||
- Step 5: Technology selection ADRs
|
||||
- Step 6: Engine-specific ADRs (from guide)
|
||||
|
||||
---
|
||||
|
||||
## Scale-Adaptive Behavior
|
||||
|
||||
| Level | Project Size | Architecture Depth | Specialist Sections |
|
||||
| ----- | -------------------------------- | --------------------------- | -------------------------- |
|
||||
| **0** | Single task | Skip architecture | N/A |
|
||||
| **1** | Small feature (1-10 stories) | Lightweight, essential only | Inline guidance |
|
||||
| **2** | Small project (5-15 stories) | Standard depth | Inline guidance |
|
||||
| **3** | Standard project (12-40 stories) | Comprehensive | Specialist placeholders |
|
||||
| **4** | Ambitious product (40+ stories) | Comprehensive + specialists | Specialist recommendations |
|
||||
|
||||
---
|
||||
|
||||
## Specialist Integration
|
||||
|
||||
Pattern-specific specialists are recommended based on project characteristics:
|
||||
|
||||
**Game Projects:**
|
||||
|
||||
- Audio Designer (music, SFX, adaptive audio)
|
||||
- Performance Optimizer (profiling, optimization)
|
||||
- Multiplayer Architect (netcode, state sync)
|
||||
- Monetization Specialist (IAP, ads, economy)
|
||||
|
||||
**Web Projects:**
|
||||
|
||||
- Frontend Architect (component design, state management)
|
||||
- Backend Architect (API design, microservices)
|
||||
- DevOps Specialist (CI/CD, deployment)
|
||||
- Security Specialist (auth, authorization, secrets)
|
||||
|
||||
**Embedded Projects:**
|
||||
|
||||
- Hardware Integration (sensors, actuators, protocols)
|
||||
- Power Management (battery, sleep modes)
|
||||
- RF/Wireless (WiFi, BLE, LoRa)
|
||||
- Safety Certification (if required)
|
||||
|
||||
Specialists are documented with:
|
||||
|
||||
- When they're needed
|
||||
- What they're responsible for
|
||||
- How they integrate with the workflow
|
||||
|
||||
---
|
||||
|
||||
## Key Differences from Legacy HLA Workflow
|
||||
|
||||
| Aspect | Legacy HLA | New Solution Architecture |
|
||||
| ------------------- | --------------- | ----------------------------------------- |
|
||||
| **Templates** | Fixed structure | 11 complete templates, pattern-specific |
|
||||
| **Tech Selection** | Manual | 171 pre-defined combinations |
|
||||
| **Engine Guidance** | Generic | Engine-specific guides (Unity/Godot/etc.) |
|
||||
| **ADRs** | Inline | Separate document |
|
||||
| **GDD Support** | No | Yes, for game projects |
|
||||
| **Guides** | None | Pattern-specific workflow guidance |
|
||||
| **Scale** | One size | Adaptive Levels 0-4 |
|
||||
|
||||
---
|
||||
|
||||
## Validation and Quality Gates
|
||||
|
||||
### Cohesion Check (Step 7)
|
||||
|
||||
**Validates:**
|
||||
|
||||
- ✅ 100% FR coverage (or gaps documented)
|
||||
- ✅ 100% NFR coverage (or gaps documented)
|
||||
- ✅ Every epic has technical foundation
|
||||
- ✅ Every story can be implemented with current architecture
|
||||
- ✅ Technology table complete with specific versions
|
||||
- ✅ No vagueness detected
|
||||
- ✅ Design-level only (no over-implementation)
|
||||
|
||||
**Outputs:**
|
||||
|
||||
- `cohesion-check-report.md` - Pass/fail with detailed gaps
|
||||
- `epic-alignment-matrix.md` - Mapping validation
|
||||
|
||||
**If cohesion check fails:**
|
||||
|
||||
- Document gaps
|
||||
- Update architecture
|
||||
- Re-run check
|
||||
|
||||
---
|
||||
|
||||
## Getting Started for Implementers
|
||||
|
||||
### For Games:
|
||||
|
||||
1. Run `workflow plan-project` → Create GDD
|
||||
2. Specify engine in GDD (Unity/Godot/Phaser/etc.)
|
||||
3. Run `workflow solution-architecture`
|
||||
4. System detects engine from GDD
|
||||
5. Loads game-engine template + engine-specific guide
|
||||
6. Generates Unity/Godot/Phaser-specific architecture
|
||||
|
||||
### For Web Apps:
|
||||
|
||||
1. Run `workflow plan-project` → Create PRD
|
||||
2. Run `workflow ux-spec` → Create UX spec
|
||||
3. Run `workflow solution-architecture`
|
||||
4. Answer: SSR or SPA? Monolith or microservices?
|
||||
5. System loads web-fullstack template
|
||||
6. Generates framework-specific architecture
|
||||
|
||||
### For Other Projects:
|
||||
|
||||
1. Run `workflow plan-project` → Create PRD
|
||||
2. Run `workflow solution-architecture`
|
||||
3. Answer project-type questions
|
||||
4. System loads appropriate template
|
||||
5. Generates pattern-specific architecture
|
||||
|
||||
---
|
||||
|
||||
## Extending the System
|
||||
|
||||
### Adding a New Template
|
||||
|
||||
1. Create `templates/new-pattern-architecture.md`
|
||||
2. Include all standard sections + pattern-specific sections
|
||||
3. Add rows to `templates/registry.csv` pointing to new template
|
||||
|
||||
### Adding a New Guide
|
||||
|
||||
1. Create `templates/new-tech-guide.md`
|
||||
2. Include: questions, patterns, pitfalls, specialist recommendations
|
||||
3. Update `templates/registry.csv` with `guide_path` column
|
||||
|
||||
### Adding a New Project Type
|
||||
|
||||
1. Add row to `project-types/project-types.csv`
|
||||
2. Create `project-types/new-type-questions.md`
|
||||
3. Ensure templates exist for this type
|
||||
4. Update instructions.md if special handling needed (like GDD for games)
|
||||
|
||||
---
|
||||
|
||||
## Questions?
|
||||
|
||||
- **Validation:** See `checklist.md`
|
||||
- **Workflow Logic:** See `instructions.md`
|
||||
- **Configuration:** See `workflow.yaml`
|
||||
- **Registry Format:** See `templates/registry.csv`
|
||||
- **Example Guide:** See `templates/game-engine-unity-guide.md`
|
||||
|
||||
---
|
||||
|
||||
_This workflow replaces the legacy HLA workflow with a modern, scale-adaptive, pattern-aware architecture generation system._
|
||||
@@ -1,170 +0,0 @@
|
||||
# Solution Architecture Checklist
|
||||
|
||||
Use this checklist during workflow execution and review.
|
||||
|
||||
## Pre-Workflow
|
||||
|
||||
- [ ] analysis-template.md exists from plan-project phase
|
||||
- [ ] PRD exists with FRs, NFRs, epics, and stories (for Level 1+)
|
||||
- [ ] UX specification exists (for UI projects at Level 2+)
|
||||
- [ ] Project level determined (0-4)
|
||||
|
||||
## During Workflow
|
||||
|
||||
### Step 0: Scale Assessment
|
||||
|
||||
- [ ] Analysis template loaded
|
||||
- [ ] Project level extracted
|
||||
- [ ] Level 0 → Skip workflow OR Level 1-4 → Proceed
|
||||
|
||||
### Step 1: PRD Analysis
|
||||
|
||||
- [ ] All FRs extracted
|
||||
- [ ] All NFRs extracted
|
||||
- [ ] All epics/stories identified
|
||||
- [ ] Project type detected
|
||||
- [ ] Constraints identified
|
||||
|
||||
### Step 2: User Skill Level
|
||||
|
||||
- [ ] Skill level clarified (beginner/intermediate/expert)
|
||||
- [ ] Technical preferences captured
|
||||
|
||||
### Step 3: Stack Recommendation
|
||||
|
||||
- [ ] Reference architectures searched
|
||||
- [ ] Top 3 presented to user
|
||||
- [ ] Selection made (reference or custom)
|
||||
|
||||
### Step 4: Component Boundaries
|
||||
|
||||
- [ ] Epics analyzed
|
||||
- [ ] Component boundaries identified
|
||||
- [ ] Architecture style determined (monolith/microservices/etc.)
|
||||
- [ ] Repository strategy determined (monorepo/polyrepo)
|
||||
|
||||
### Step 5: Project-Type Questions
|
||||
|
||||
- [ ] Project-type questions loaded
|
||||
- [ ] Only unanswered questions asked (dynamic narrowing)
|
||||
- [ ] All decisions recorded
|
||||
|
||||
### Step 6: Architecture Generation
|
||||
|
||||
- [ ] Template sections determined dynamically
|
||||
- [ ] User approved section list
|
||||
- [ ] architecture.md generated with ALL sections
|
||||
- [ ] Technology and Library Decision Table included with specific versions
|
||||
- [ ] Proposed Source Tree included
|
||||
- [ ] Design-level only (no extensive code)
|
||||
- [ ] Output adapted to user skill level
|
||||
|
||||
### Step 7: Cohesion Check
|
||||
|
||||
- [ ] Requirements coverage validated (FRs, NFRs, epics, stories)
|
||||
- [ ] Technology table validated (no vagueness)
|
||||
- [ ] Code vs design balance checked
|
||||
- [ ] Epic Alignment Matrix generated (separate output)
|
||||
- [ ] Story readiness assessed (X of Y ready)
|
||||
- [ ] Vagueness detected and flagged
|
||||
- [ ] Over-specification detected and flagged
|
||||
- [ ] Cohesion check report generated
|
||||
- [ ] Issues addressed or acknowledged
|
||||
|
||||
### Step 7.5: Specialist Sections
|
||||
|
||||
- [ ] DevOps assessed (simple inline or complex placeholder)
|
||||
- [ ] Security assessed (simple inline or complex placeholder)
|
||||
- [ ] Testing assessed (simple inline or complex placeholder)
|
||||
- [ ] Specialist sections added to END of architecture.md
|
||||
|
||||
### Step 8: PRD Updates (Optional)
|
||||
|
||||
- [ ] Architectural discoveries identified
|
||||
- [ ] PRD updated if needed (enabler epics, story clarifications)
|
||||
|
||||
### Step 9: Tech-Spec Generation
|
||||
|
||||
- [ ] Tech-spec generated for each epic
|
||||
- [ ] Saved as tech-spec-epic-{{N}}.md
|
||||
- [ ] project-workflow-analysis.md updated
|
||||
|
||||
### Step 10: Polyrepo Strategy (Optional)
|
||||
|
||||
- [ ] Polyrepo identified (if applicable)
|
||||
- [ ] Documentation copying strategy determined
|
||||
- [ ] Full docs copied to all repos
|
||||
|
||||
### Step 11: Validation
|
||||
|
||||
- [ ] All required documents exist
|
||||
- [ ] All checklists passed
|
||||
- [ ] Completion summary generated
|
||||
|
||||
## Quality Gates
|
||||
|
||||
### Technology and Library Decision Table
|
||||
|
||||
- [ ] Table exists in architecture.md
|
||||
- [ ] ALL technologies have specific versions (e.g., "pino 8.17.0")
|
||||
- [ ] NO vague entries ("a logging library", "appropriate caching")
|
||||
- [ ] NO multi-option entries without decision ("Pino or Winston")
|
||||
- [ ] Grouped logically (core stack, libraries, devops)
|
||||
|
||||
### Proposed Source Tree
|
||||
|
||||
- [ ] Section exists in architecture.md
|
||||
- [ ] Complete directory structure shown
|
||||
- [ ] For polyrepo: ALL repo structures included
|
||||
- [ ] Matches technology stack conventions
|
||||
|
||||
### Cohesion Check Results
|
||||
|
||||
- [ ] 100% FR coverage OR gaps documented
|
||||
- [ ] 100% NFR coverage OR gaps documented
|
||||
- [ ] 100% epic coverage OR gaps documented
|
||||
- [ ] 100% story readiness OR gaps documented
|
||||
- [ ] Epic Alignment Matrix generated (separate file)
|
||||
- [ ] Readiness score ≥ 90% OR user accepted lower score
|
||||
|
||||
### Design vs Code Balance
|
||||
|
||||
- [ ] No code blocks > 10 lines
|
||||
- [ ] Focus on schemas, patterns, diagrams
|
||||
- [ ] No complete implementations
|
||||
|
||||
## Post-Workflow Outputs
|
||||
|
||||
### Required Files
|
||||
|
||||
- [ ] /docs/architecture.md (or solution-architecture.md)
|
||||
- [ ] /docs/cohesion-check-report.md
|
||||
- [ ] /docs/epic-alignment-matrix.md
|
||||
- [ ] /docs/tech-spec-epic-1.md
|
||||
- [ ] /docs/tech-spec-epic-2.md
|
||||
- [ ] /docs/tech-spec-epic-N.md (for all epics)
|
||||
|
||||
### Optional Files (if specialist placeholders created)
|
||||
|
||||
- [ ] Handoff instructions for devops-architecture workflow
|
||||
- [ ] Handoff instructions for security-architecture workflow
|
||||
- [ ] Handoff instructions for test-architect workflow
|
||||
|
||||
### Updated Files
|
||||
|
||||
- [ ] analysis-template.md (workflow status updated)
|
||||
- [ ] prd.md (if architectural discoveries required updates)
|
||||
|
||||
## Next Steps After Workflow
|
||||
|
||||
If specialist placeholders created:
|
||||
|
||||
- [ ] Run devops-architecture workflow (if placeholder)
|
||||
- [ ] Run security-architecture workflow (if placeholder)
|
||||
- [ ] Run test-architect workflow (if placeholder)
|
||||
|
||||
For implementation:
|
||||
|
||||
- [ ] Review all tech specs
|
||||
- [ ] Set up development environment per architecture
|
||||
- [ ] Begin epic implementation using tech specs
|
||||
@@ -1,661 +0,0 @@
|
||||
# Solution Architecture Workflow Instructions
|
||||
|
||||
This workflow generates scale-adaptive solution architecture documentation that replaces the legacy HLA workflow.
|
||||
|
||||
```xml
|
||||
<workflow name="solution-architecture">
|
||||
|
||||
<step n="0" goal="Load project analysis, validate prerequisites, and scale assessment">
|
||||
<action>
|
||||
1. Read project-workflow-analysis.md:
|
||||
Path: {{project_workflow_analysis_path}}
|
||||
|
||||
2. Extract:
|
||||
- project_level: {{0|1|2|3|4}}
|
||||
- field_type: {{greenfield|brownfield}}
|
||||
- project_type: {{web|mobile|embedded|game|library}}
|
||||
- has_user_interface: {{true|false}}
|
||||
- ui_complexity: {{none|simple|moderate|complex}}
|
||||
- ux_spec_path: /docs/ux-spec.md (if exists)
|
||||
- prd_status: {{complete|incomplete}}
|
||||
|
||||
3. 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...
|
||||
|
||||
4. 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="Deep requirements document and spec analysis">
|
||||
<action>
|
||||
1. Determine requirements document type based on project_type:
|
||||
- IF project_type == "game":
|
||||
Primary Doc: Game Design Document (GDD)
|
||||
Path: {{gdd_path}} OR {{prd_path}}/GDD.md
|
||||
- ELSE:
|
||||
Primary Doc: Product Requirements Document (PRD)
|
||||
Path: {{prd_path}}
|
||||
|
||||
2. Read primary requirements document:
|
||||
Read: {{determined_path}}
|
||||
|
||||
Extract based on document type:
|
||||
|
||||
IF GDD (Game):
|
||||
- Game concept and genre
|
||||
- Core gameplay mechanics
|
||||
- Player progression systems
|
||||
- Game world/levels/scenes
|
||||
- Characters and entities
|
||||
- Win/loss conditions
|
||||
- Game modes (single-player, multiplayer, etc.)
|
||||
- Technical requirements (platform, performance targets)
|
||||
- Art/audio direction
|
||||
- Monetization (if applicable)
|
||||
|
||||
IF PRD (Non-Game):
|
||||
- All Functional Requirements (FRs)
|
||||
- All Non-Functional Requirements (NFRs)
|
||||
- All Epics with user stories
|
||||
- Technical constraints mentioned
|
||||
- Integrations required (payments, email, etc.)
|
||||
|
||||
3. Read UX Spec (if project has UI):
|
||||
IF has_user_interface == true:
|
||||
Read: {{ux_spec_path}}
|
||||
|
||||
Extract:
|
||||
- All screens/pages (list every screen defined)
|
||||
- Navigation structure (how screens connect, patterns)
|
||||
- Key user flows (auth, onboarding, checkout, core features)
|
||||
- UI complexity indicators:
|
||||
* Complex wizards/multi-step forms
|
||||
* Real-time updates/dashboards
|
||||
* Complex state machines
|
||||
* Rich interactions (drag-drop, animations)
|
||||
* Infinite scroll, virtualization needs
|
||||
- Component patterns (from design system/wireframes)
|
||||
- Responsive requirements (mobile-first, desktop-first, adaptive)
|
||||
- Accessibility requirements (WCAG level, screen reader support)
|
||||
- Design system/tokens (colors, typography, spacing if specified)
|
||||
- Performance requirements (page load times, frame rates)
|
||||
|
||||
4. Cross-reference requirements + specs:
|
||||
IF GDD + UX Spec (game with UI):
|
||||
- Each gameplay mechanic should have UI representation
|
||||
- Each scene/level should have visual design
|
||||
- Player controls mapped to UI elements
|
||||
|
||||
IF PRD + UX Spec (non-game):
|
||||
- Each epic should have corresponding screens/flows in UX spec
|
||||
- Each screen should support epic stories
|
||||
- FRs should have UI manifestation (where applicable)
|
||||
- NFRs (performance, accessibility) should inform UX patterns
|
||||
- Identify gaps: Epics without screens, screens without epic mapping
|
||||
|
||||
5. Detect characteristics:
|
||||
- Project type(s): web, mobile, embedded, game, library, desktop
|
||||
- UI complexity: simple (CRUD) | moderate (dashboards) | complex (wizards/real-time)
|
||||
- Architecture style hints: monolith, microservices, modular, etc.
|
||||
- Repository strategy hints: monorepo, polyrepo, hybrid
|
||||
- Special needs: real-time, event-driven, batch, offline-first
|
||||
|
||||
6. Identify what's already specified vs. unknown
|
||||
- Known: Technologies explicitly mentioned in PRD/UX spec
|
||||
- Unknown: Gaps that need decisions
|
||||
|
||||
Output summary:
|
||||
- Project understanding
|
||||
- UI/UX summary (if applicable):
|
||||
* Screen count: N screens
|
||||
* Navigation complexity: simple | moderate | complex
|
||||
* UI complexity: simple | moderate | complex
|
||||
* Key user flows documented
|
||||
- PRD-UX alignment check: Gaps identified (if any)
|
||||
</action>
|
||||
<template-output>prd_and_ux_analysis</template-output>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="User skill level and preference clarification">
|
||||
<ask>
|
||||
What's your experience level with {{project_type}} development?
|
||||
|
||||
1. Beginner - Need detailed explanations and guidance
|
||||
2. Intermediate - Some explanations helpful
|
||||
3. Expert - Concise output, minimal explanations
|
||||
|
||||
Your choice (1/2/3):
|
||||
</ask>
|
||||
|
||||
<action>
|
||||
Set user_skill_level variable for adaptive output:
|
||||
- beginner: Verbose explanations, examples, rationale for every decision
|
||||
- intermediate: Moderate explanations, key rationale, balanced detail
|
||||
- expert: Concise, decision-focused, minimal prose
|
||||
|
||||
This affects ALL subsequent output verbosity.
|
||||
</action>
|
||||
|
||||
<ask optional="true">
|
||||
Any technical preferences or constraints I should know?
|
||||
- Preferred languages/frameworks?
|
||||
- Required platforms/services?
|
||||
- Team expertise areas?
|
||||
- Existing infrastructure (brownfield)?
|
||||
|
||||
(Press enter to skip if none)
|
||||
</ask>
|
||||
|
||||
<action>
|
||||
Record preferences for narrowing recommendations.
|
||||
</action>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Determine architecture pattern">
|
||||
<action>
|
||||
Determine the architectural pattern based on requirements:
|
||||
|
||||
1. Architecture style:
|
||||
- Monolith (single application)
|
||||
- Microservices (multiple services)
|
||||
- Serverless (function-based)
|
||||
- Other (event-driven, JAMstack, etc.)
|
||||
|
||||
2. Repository strategy:
|
||||
- Monorepo (single repo)
|
||||
- Polyrepo (multiple repos)
|
||||
- Hybrid
|
||||
|
||||
3. Pattern-specific characteristics:
|
||||
- For web: SSR vs SPA vs API-only
|
||||
- For mobile: Native vs cross-platform vs hybrid vs PWA
|
||||
- For game: 2D vs 3D vs text-based vs web
|
||||
- For backend: REST vs GraphQL vs gRPC vs realtime
|
||||
- For data: ETL vs ML vs analytics vs streaming
|
||||
- Etc.
|
||||
</action>
|
||||
|
||||
<ask>
|
||||
Based on your requirements, I need to determine the architecture pattern:
|
||||
|
||||
1. Architecture style: {{suggested_style}} - Does this sound right? (or specify: monolith/microservices/serverless/other)
|
||||
|
||||
2. Repository strategy: {{suggested_repo_strategy}} - Monorepo or polyrepo?
|
||||
|
||||
{{project_type_specific_questions}}
|
||||
</ask>
|
||||
|
||||
<elicit-required/>
|
||||
<template-output>architecture_pattern</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Epic analysis and component boundaries">
|
||||
<action>
|
||||
1. Analyze each epic from PRD:
|
||||
- What domain capabilities does it require?
|
||||
- What data does it operate on?
|
||||
- What integrations does it need?
|
||||
|
||||
2. Identify natural component/service boundaries:
|
||||
- Vertical slices (epic-aligned features)
|
||||
- Shared infrastructure (auth, logging, etc.)
|
||||
- Integration points (external services)
|
||||
|
||||
3. Determine architecture style:
|
||||
- Single monolith vs. multiple services
|
||||
- Monorepo vs. polyrepo
|
||||
- Modular monolith vs. microservices
|
||||
|
||||
4. Map epics to proposed components (high-level only)
|
||||
</action>
|
||||
<template-output>component_boundaries</template-output>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Project-type-specific architecture questions">
|
||||
<action>
|
||||
1. Load project types registry:
|
||||
Read: {{installed_path}}/project-types/project-types.csv
|
||||
|
||||
2. Match detected project_type to CSV:
|
||||
- Use project_type from Step 1 (e.g., "web", "mobile", "backend")
|
||||
- Find matching row in CSV
|
||||
- Get question_file path
|
||||
|
||||
3. Load project-type-specific questions:
|
||||
Read: {{installed_path}}/project-types/{{question_file}}
|
||||
|
||||
4. Ask only UNANSWERED questions (dynamic narrowing):
|
||||
- Skip questions already answered by reference architecture
|
||||
- Skip questions already specified in PRD
|
||||
- Focus on gaps and ambiguities
|
||||
|
||||
5. Record all decisions with rationale
|
||||
|
||||
NOTE: For hybrid projects (e.g., "web + mobile"), load multiple question files
|
||||
</action>
|
||||
|
||||
<ask>
|
||||
{{project_type_specific_questions}}
|
||||
</ask>
|
||||
|
||||
<elicit-required/>
|
||||
<template-output>architecture_decisions</template-output>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Generate solution architecture document with dynamic template">
|
||||
<action>
|
||||
Sub-step 6.1: Load Appropriate Template
|
||||
|
||||
1. Analyze project to determine:
|
||||
- Project type(s): {{web|mobile|embedded|game|library|cli|desktop|data|backend|infra|extension}}
|
||||
- Architecture style: {{monolith|microservices|serverless|etc}}
|
||||
- Repository strategy: {{monorepo|polyrepo|hybrid}}
|
||||
- Primary language(s): {{TypeScript|Python|Rust|etc}}
|
||||
|
||||
2. Search template registry:
|
||||
Read: {{installed_path}}/templates/registry.csv
|
||||
|
||||
Filter WHERE:
|
||||
- project_types = {{project_type}}
|
||||
- architecture_style = {{determined_style}}
|
||||
- repo_strategy = {{determined_strategy}}
|
||||
- languages matches {{language_preference}} (if specified)
|
||||
- tags overlap with {{requirements}}
|
||||
|
||||
3. Select best matching row:
|
||||
Get {{template_path}} and {{guide_path}} from matched CSV row
|
||||
Example template: "web-fullstack-architecture.md", "game-engine-architecture.md", etc.
|
||||
Example guide: "game-engine-unity-guide.md", "game-engine-godot-guide.md", etc.
|
||||
|
||||
4. Load markdown template:
|
||||
Read: {{installed_path}}/templates/{{template_path}}
|
||||
|
||||
This template contains:
|
||||
- Complete document structure with all sections
|
||||
- {{placeholder}} variables to fill (e.g., {{project_name}}, {{framework}}, {{database_schema}})
|
||||
- Pattern-specific sections (e.g., SSR sections for web, gameplay sections for games)
|
||||
- Specialist recommendations (e.g., audio-designer for games, hardware-integration for embedded)
|
||||
|
||||
5. Load pattern-specific guide (if available):
|
||||
IF {{guide_path}} is not empty:
|
||||
Read: {{installed_path}}/templates/{{guide_path}}
|
||||
|
||||
This guide contains:
|
||||
- Engine/framework-specific questions
|
||||
- Technology-specific best practices
|
||||
- Common patterns and pitfalls
|
||||
- Specialist recommendations for this specific tech stack
|
||||
- Pattern-specific ADR examples
|
||||
|
||||
6. Present template to user:
|
||||
</action>
|
||||
|
||||
<ask>
|
||||
Based on your {{project_type}} {{architecture_style}} project, I've selected the "{{template_path}}" template.
|
||||
|
||||
This template includes {{section_count}} sections covering:
|
||||
{{brief_section_list}}
|
||||
|
||||
I will now fill in all the {{placeholder}} variables based on our previous discussions and requirements.
|
||||
|
||||
Options:
|
||||
1. Use this template (recommended)
|
||||
2. Use a different template (specify which one)
|
||||
3. Show me the full template structure first
|
||||
|
||||
Your choice (1/2/3):
|
||||
</ask>
|
||||
|
||||
<action>
|
||||
Sub-step 6.2: Fill Template Placeholders
|
||||
|
||||
6. Parse template to identify all {{placeholders}}
|
||||
|
||||
7. Fill each placeholder with appropriate content:
|
||||
- Use information from previous steps (PRD, UX spec, tech decisions)
|
||||
- Ask user for any missing information
|
||||
- Generate appropriate content based on user_skill_level
|
||||
|
||||
8. Generate final architecture.md document
|
||||
|
||||
CRITICAL REQUIREMENTS:
|
||||
- MUST include "Technology and Library Decisions" section with table:
|
||||
| Category | Technology | Version | Rationale |
|
||||
- ALL technologies with SPECIFIC versions (e.g., "pino 8.17.0")
|
||||
- NO vagueness ("a logging library" = FAIL)
|
||||
|
||||
- MUST include "Proposed Source Tree" section:
|
||||
- Complete directory/file structure
|
||||
- For polyrepo: show ALL repo structures
|
||||
|
||||
- Design-level only (NO extensive code implementations):
|
||||
- ✅ DO: Data model schemas, API contracts, diagrams, patterns
|
||||
- ❌ DON'T: 10+ line functions, complete components, detailed implementations
|
||||
|
||||
- Adapt verbosity to user_skill_level:
|
||||
- Beginner: Detailed explanations, examples, rationale
|
||||
- Intermediate: Key explanations, balanced
|
||||
- Expert: Concise, decision-focused
|
||||
|
||||
Common sections (adapt per project):
|
||||
1. Executive Summary
|
||||
2. Technology Stack and Decisions (TABLE REQUIRED)
|
||||
3. Repository and Service Architecture (mono/poly, monolith/microservices)
|
||||
4. System Architecture (diagrams)
|
||||
5. Data Architecture
|
||||
6. API/Interface Design (adapts: REST for web, protocols for embedded, etc.)
|
||||
7. Cross-Cutting Concerns
|
||||
8. Component and Integration Overview (NOT epic alignment - that's cohesion check)
|
||||
9. Architecture Decision Records
|
||||
10. Implementation Guidance
|
||||
11. Proposed Source Tree (REQUIRED)
|
||||
12-14. Specialist sections (DevOps, Security, Testing) - see Step 7.5
|
||||
|
||||
NOTE: Section list is DYNAMIC per project type. Embedded projects have different sections than web apps.
|
||||
</action>
|
||||
|
||||
<template-output>solution_architecture</template-output>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Solution architecture cohesion check (QUALITY GATE)">
|
||||
<action>
|
||||
CRITICAL: This is a validation quality gate before proceeding.
|
||||
|
||||
Run cohesion check validation inline (NO separate workflow for now):
|
||||
|
||||
1. Requirements Coverage:
|
||||
- Every FR mapped to components/technology?
|
||||
- Every NFR addressed in architecture?
|
||||
- Every epic has technical foundation?
|
||||
- Every story can be implemented with current architecture?
|
||||
|
||||
2. Technology and Library Table Validation:
|
||||
- Table exists?
|
||||
- All entries have specific versions?
|
||||
- No vague entries ("a library", "some framework")?
|
||||
- No multi-option entries without decision?
|
||||
|
||||
3. Code vs Design Balance:
|
||||
- Any sections with 10+ lines of code? (FLAG for removal)
|
||||
- Focus on design (schemas, patterns, diagrams)?
|
||||
|
||||
4. Vagueness Detection:
|
||||
- Scan for: "appropriate", "standard", "will use", "some", "a library"
|
||||
- Flag all vague statements for specificity
|
||||
|
||||
5. Generate Epic Alignment Matrix:
|
||||
| Epic | Stories | Components | Data Models | APIs | Integration Points | Status |
|
||||
|
||||
This matrix is SEPARATE OUTPUT (not in architecture.md)
|
||||
|
||||
6. Generate Cohesion Check Report with:
|
||||
- Executive summary (READY vs GAPS)
|
||||
- Requirements coverage table
|
||||
- Technology table validation
|
||||
- Epic Alignment Matrix
|
||||
- Story readiness (X of Y stories ready)
|
||||
- Vagueness detected
|
||||
- Over-specification detected
|
||||
- Recommendations (critical/important/nice-to-have)
|
||||
- Overall readiness score
|
||||
|
||||
7. Present report to user
|
||||
</action>
|
||||
|
||||
<template-output>cohesion_check_report</template-output>
|
||||
|
||||
<ask>
|
||||
Cohesion Check Results: {{readiness_score}}% ready
|
||||
|
||||
{{if_gaps_found}}
|
||||
Issues found:
|
||||
{{list_critical_issues}}
|
||||
|
||||
Options:
|
||||
1. I'll fix these issues now (update architecture.md)
|
||||
2. You'll fix them manually
|
||||
3. Proceed anyway (not recommended)
|
||||
|
||||
Your choice:
|
||||
{{/if}}
|
||||
|
||||
{{if_ready}}
|
||||
✅ Architecture is ready for specialist sections!
|
||||
Proceed? (y/n)
|
||||
{{/if}}
|
||||
</ask>
|
||||
|
||||
<action if="user_chooses_option_1">
|
||||
Update architecture.md to address critical issues, then re-validate.
|
||||
</action>
|
||||
</step>
|
||||
|
||||
<step n="7.5" goal="Scale-adaptive specialist section handling" optional="true">
|
||||
<action>
|
||||
For each specialist area (DevOps, Security, Testing), assess complexity:
|
||||
|
||||
DevOps Assessment:
|
||||
- Simple: Vercel/Heroku, 1-2 envs, simple CI/CD → Handle INLINE
|
||||
- Complex: K8s, 3+ envs, complex IaC, multi-region → Create PLACEHOLDER
|
||||
|
||||
Security Assessment:
|
||||
- Simple: Framework defaults, no compliance → Handle INLINE
|
||||
- Complex: HIPAA/PCI/SOC2, custom auth, high sensitivity → Create PLACEHOLDER
|
||||
|
||||
Testing Assessment:
|
||||
- Simple: Basic unit + E2E → Handle INLINE
|
||||
- Complex: Mission-critical UI, comprehensive coverage needed → Create PLACEHOLDER
|
||||
|
||||
For INLINE: Add 1-3 paragraph sections to architecture.md
|
||||
For PLACEHOLDER: Add handoff section with specialist agent invocation instructions
|
||||
</action>
|
||||
|
||||
<ask for_each="specialist_area">
|
||||
{{specialist_area}} Assessment: {{simple|complex}}
|
||||
|
||||
{{if_complex}}
|
||||
Recommendation: Engage {{specialist_area}} specialist agent after this document.
|
||||
|
||||
Options:
|
||||
1. Create placeholder, I'll engage specialist later (recommended)
|
||||
2. Attempt inline coverage now (may be less detailed)
|
||||
3. Skip (handle later)
|
||||
|
||||
Your choice:
|
||||
{{/if}}
|
||||
|
||||
{{if_simple}}
|
||||
I'll handle {{specialist_area}} inline with essentials.
|
||||
{{/if}}
|
||||
</ask>
|
||||
|
||||
<action>
|
||||
Update architecture.md with specialist sections (inline or placeholders) at the END of document.
|
||||
</action>
|
||||
|
||||
<template-output>specialist_sections</template-output>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="PRD epic/story updates (if needed)" optional="true">
|
||||
<check>
|
||||
Did cohesion check or architecture design reveal:
|
||||
- Missing enabler epics (e.g., "Infrastructure Setup")?
|
||||
- Story modifications needed?
|
||||
- New FRs/NFRs discovered?
|
||||
</check>
|
||||
|
||||
<ask if="changes_needed">
|
||||
Architecture design revealed some PRD updates needed:
|
||||
{{list_suggested_changes}}
|
||||
|
||||
Should I update the PRD? (y/n)
|
||||
</ask>
|
||||
|
||||
<action if="user_approves">
|
||||
Update PRD with architectural discoveries:
|
||||
- Add enabler epics if needed
|
||||
- Clarify stories based on architecture
|
||||
- Update tech-spec.md with architecture reference
|
||||
</action>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Tech-spec generation per epic (INTEGRATED)">
|
||||
<action>
|
||||
For each epic in PRD:
|
||||
1. Extract relevant architecture sections:
|
||||
- Technology stack (full table)
|
||||
- Components for this epic
|
||||
- Data models for this epic
|
||||
- APIs for this epic
|
||||
- Proposed source tree (relevant paths)
|
||||
- Implementation guidance
|
||||
|
||||
2. Generate tech-spec-epic-{{N}}.md using tech-spec workflow logic:
|
||||
Read: {project-root}/bmad/bmm/workflows/3-solutioning/tech-spec/instructions.md
|
||||
|
||||
Include:
|
||||
- Epic overview (from PRD)
|
||||
- Stories (from PRD)
|
||||
- Architecture extract (from solution-architecture.md)
|
||||
- Component-level technical decisions
|
||||
- Implementation notes
|
||||
- Testing approach
|
||||
|
||||
3. Save to: /docs/tech-spec-epic-{{N}}.md
|
||||
</action>
|
||||
|
||||
<template-output>tech_specs</template-output>
|
||||
|
||||
<action>
|
||||
Update project-workflow-analysis.md workflow status:
|
||||
- [x] Solution architecture generated
|
||||
- [x] Cohesion check passed
|
||||
- [x] Tech specs generated for all epics
|
||||
</action>
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Polyrepo documentation strategy" optional="true">
|
||||
<check>
|
||||
Is this a polyrepo project (multiple repositories)?
|
||||
</check>
|
||||
|
||||
<action if="polyrepo">
|
||||
For polyrepo projects:
|
||||
|
||||
1. Identify all repositories from architecture:
|
||||
Example: frontend-repo, api-repo, worker-repo, mobile-repo
|
||||
|
||||
2. Strategy: Copy FULL documentation to ALL repos
|
||||
- architecture.md → Copy to each repo
|
||||
- tech-spec-epic-X.md → Copy to each repo (full set)
|
||||
- cohesion-check-report.md → Copy to each repo
|
||||
|
||||
3. Add repo-specific README pointing to docs:
|
||||
"See /docs/architecture.md for complete solution architecture"
|
||||
|
||||
4. Later phases extract per-epic and per-story contexts as needed
|
||||
|
||||
Rationale: Full context in every repo, extract focused contexts during implementation.
|
||||
</action>
|
||||
|
||||
<action if="monorepo">
|
||||
For monorepo projects:
|
||||
- All docs already in single /docs directory
|
||||
- No special strategy needed
|
||||
</action>
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Validation and completion">
|
||||
<action>
|
||||
Final validation checklist:
|
||||
|
||||
- [x] architecture.md exists and is complete
|
||||
- [x] Technology and Library Decision Table has specific versions
|
||||
- [x] Proposed Source Tree section included
|
||||
- [x] Cohesion check passed (or issues addressed)
|
||||
- [x] Epic Alignment Matrix generated
|
||||
- [x] Specialist sections handled (inline or placeholder)
|
||||
- [x] Tech specs generated for all epics
|
||||
- [x] Analysis template updated
|
||||
|
||||
Generate completion summary:
|
||||
- Document locations
|
||||
- Key decisions made
|
||||
- Next steps (engage specialist agents if placeholders, begin implementation)
|
||||
</action>
|
||||
|
||||
<template-output>completion_summary</template-output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Reference Documentation
|
||||
|
||||
For detailed design specification, rationale, examples, and edge cases, see:
|
||||
`./arch-plan.md` (when available in same directory)
|
||||
|
||||
Key sections:
|
||||
|
||||
- Key Design Decisions (15 critical requirements)
|
||||
- Step 6 - Architecture Generation (examples, guidance)
|
||||
- Step 7 - Cohesion Check (validation criteria, report format)
|
||||
- Dynamic Template Section Strategy
|
||||
- CSV Registry Examples
|
||||
|
||||
This instructions.md is the EXECUTABLE guide.
|
||||
arch-plan.md is the REFERENCE specification.
|
||||
@@ -1,490 +0,0 @@
|
||||
# Backend/API Service Architecture Questions
|
||||
|
||||
## Service Type and Architecture
|
||||
|
||||
1. **Service architecture:**
|
||||
- Monolithic API (single service)
|
||||
- Microservices (multiple independent services)
|
||||
- Modular monolith (single deployment, modular code)
|
||||
- Serverless (AWS Lambda, Cloud Functions, etc.)
|
||||
- Hybrid
|
||||
|
||||
2. **API paradigm:**
|
||||
- REST
|
||||
- GraphQL
|
||||
- gRPC
|
||||
- WebSocket (real-time)
|
||||
- Server-Sent Events (SSE)
|
||||
- Message-based (event-driven)
|
||||
- Multiple paradigms
|
||||
|
||||
3. **Communication patterns:**
|
||||
- Synchronous (request-response)
|
||||
- Asynchronous (message queues)
|
||||
- Event-driven (pub/sub)
|
||||
- Webhooks
|
||||
- Multiple patterns
|
||||
|
||||
## Framework and Language
|
||||
|
||||
4. **Backend language/framework:**
|
||||
- Node.js (Express, Fastify, NestJS, Hono)
|
||||
- Python (FastAPI, Django, Flask)
|
||||
- Go (Gin, Echo, Chi, standard lib)
|
||||
- Java/Kotlin (Spring Boot, Micronaut, Quarkus)
|
||||
- C# (.NET Core, ASP.NET)
|
||||
- Ruby (Rails, Sinatra)
|
||||
- Rust (Axum, Actix, Rocket)
|
||||
- PHP (Laravel, Symfony)
|
||||
- Elixir (Phoenix)
|
||||
- Other: **\_\_\_**
|
||||
|
||||
5. **GraphQL implementation (if applicable):**
|
||||
- Apollo Server
|
||||
- GraphQL Yoga
|
||||
- Hasura (auto-generated)
|
||||
- Postgraphile
|
||||
- Custom
|
||||
- Not using GraphQL
|
||||
|
||||
6. **gRPC implementation (if applicable):**
|
||||
- Protocol Buffers
|
||||
- Language-specific gRPC libraries
|
||||
- Not using gRPC
|
||||
|
||||
## Database and Data Layer
|
||||
|
||||
7. **Primary database:**
|
||||
- PostgreSQL
|
||||
- MySQL/MariaDB
|
||||
- MongoDB
|
||||
- DynamoDB (AWS)
|
||||
- Firestore (Google)
|
||||
- CockroachDB
|
||||
- Cassandra
|
||||
- Redis (as primary)
|
||||
- Multiple databases (polyglot persistence)
|
||||
- Other: **\_\_\_**
|
||||
|
||||
8. **Database access pattern:**
|
||||
- ORM (Prisma, TypeORM, SQLAlchemy, Hibernate, etc.)
|
||||
- Query builder (Knex, Kysely, jOOQ)
|
||||
- Raw SQL
|
||||
- Database SDK (Supabase, Firebase)
|
||||
- Mix
|
||||
|
||||
9. **Caching layer:**
|
||||
- Redis
|
||||
- Memcached
|
||||
- In-memory (application cache)
|
||||
- CDN caching (for static responses)
|
||||
- Database query cache
|
||||
- None needed
|
||||
|
||||
10. **Read replicas:**
|
||||
- Yes (separate read/write databases)
|
||||
- No (single database)
|
||||
- Planned for future
|
||||
|
||||
11. **Database sharding:**
|
||||
- Yes (horizontal partitioning)
|
||||
- No (single database)
|
||||
- Planned for scale
|
||||
|
||||
## Authentication and Authorization
|
||||
|
||||
12. **Authentication method:**
|
||||
- JWT (stateless)
|
||||
- Session-based (stateful)
|
||||
- OAuth2 provider (Auth0, Okta, Keycloak)
|
||||
- API keys
|
||||
- Mutual TLS (mTLS)
|
||||
- Multiple methods
|
||||
|
||||
13. **Authorization pattern:**
|
||||
- Role-Based Access Control (RBAC)
|
||||
- Attribute-Based Access Control (ABAC)
|
||||
- Access Control Lists (ACL)
|
||||
- Custom logic
|
||||
- None (open API)
|
||||
|
||||
14. **Identity provider:**
|
||||
- Self-managed (own user database)
|
||||
- Auth0
|
||||
- AWS Cognito
|
||||
- Firebase Auth
|
||||
- Keycloak
|
||||
- Azure AD / Entra ID
|
||||
- Okta
|
||||
- Other: **\_\_\_**
|
||||
|
||||
## Message Queue and Event Streaming
|
||||
|
||||
15. **Message queue (if needed):**
|
||||
- RabbitMQ
|
||||
- Apache Kafka
|
||||
- AWS SQS
|
||||
- Google Pub/Sub
|
||||
- Redis (pub/sub)
|
||||
- NATS
|
||||
- None needed
|
||||
- Other: **\_\_\_**
|
||||
|
||||
16. **Event streaming (if needed):**
|
||||
- Apache Kafka
|
||||
- AWS Kinesis
|
||||
- Azure Event Hubs
|
||||
- Redis Streams
|
||||
- None needed
|
||||
|
||||
17. **Background jobs:**
|
||||
- Queue-based (Bull, Celery, Sidekiq)
|
||||
- Cron-based (node-cron, APScheduler)
|
||||
- Serverless functions (scheduled Lambda)
|
||||
- None needed
|
||||
|
||||
## Service Communication (Microservices)
|
||||
|
||||
18. **Service mesh (if microservices):**
|
||||
- Istio
|
||||
- Linkerd
|
||||
- Consul
|
||||
- None (direct communication)
|
||||
- Not applicable
|
||||
|
||||
19. **Service discovery:**
|
||||
- Kubernetes DNS
|
||||
- Consul
|
||||
- etcd
|
||||
- AWS Cloud Map
|
||||
- Hardcoded (for now)
|
||||
- Not applicable
|
||||
|
||||
20. **Inter-service communication:**
|
||||
- HTTP/REST
|
||||
- gRPC
|
||||
- Message queue
|
||||
- Event bus
|
||||
- Not applicable
|
||||
|
||||
## API Design and Documentation
|
||||
|
||||
21. **API versioning:**
|
||||
- URL versioning (/v1/, /v2/)
|
||||
- Header versioning (Accept-Version)
|
||||
- No versioning (single version)
|
||||
- Semantic versioning
|
||||
|
||||
22. **API documentation:**
|
||||
- OpenAPI/Swagger
|
||||
- GraphQL introspection/playground
|
||||
- Postman collections
|
||||
- Custom docs
|
||||
- README only
|
||||
|
||||
23. **API testing tools:**
|
||||
- Postman
|
||||
- Insomnia
|
||||
- REST Client (VS Code)
|
||||
- cURL examples
|
||||
- Multiple tools
|
||||
|
||||
## Rate Limiting and Throttling
|
||||
|
||||
24. **Rate limiting:**
|
||||
- Per-user/API key
|
||||
- Per-IP
|
||||
- Global rate limit
|
||||
- Tiered (different limits per plan)
|
||||
- None (internal API)
|
||||
|
||||
25. **Rate limit implementation:**
|
||||
- Application-level (middleware)
|
||||
- API Gateway
|
||||
- Redis-based
|
||||
- None
|
||||
|
||||
## Data Validation and Processing
|
||||
|
||||
26. **Request validation:**
|
||||
- Schema validation (Zod, Joi, Yup, Pydantic)
|
||||
- Manual validation
|
||||
- Framework built-in
|
||||
- None
|
||||
|
||||
27. **Data serialization:**
|
||||
- JSON
|
||||
- Protocol Buffers
|
||||
- MessagePack
|
||||
- XML
|
||||
- Multiple formats
|
||||
|
||||
28. **File uploads (if applicable):**
|
||||
- Direct to server (local storage)
|
||||
- S3/Cloud storage
|
||||
- Presigned URLs (client direct upload)
|
||||
- None needed
|
||||
|
||||
## Error Handling and Resilience
|
||||
|
||||
29. **Error handling strategy:**
|
||||
- Standard HTTP status codes
|
||||
- Custom error codes
|
||||
- RFC 7807 (Problem Details)
|
||||
- GraphQL errors
|
||||
- Mix
|
||||
|
||||
30. **Circuit breaker (for external services):**
|
||||
- Yes (Hystrix, Resilience4j, Polly)
|
||||
- No (direct calls)
|
||||
- Not needed
|
||||
|
||||
31. **Retry logic:**
|
||||
- Exponential backoff
|
||||
- Fixed retries
|
||||
- No retries
|
||||
- Library-based (axios-retry, etc.)
|
||||
|
||||
32. **Graceful shutdown:**
|
||||
- Yes (drain connections, finish requests)
|
||||
- No (immediate shutdown)
|
||||
|
||||
## Observability
|
||||
|
||||
33. **Logging:**
|
||||
- Structured logging (JSON)
|
||||
- Plain text logs
|
||||
- Library: (Winston, Pino, Logrus, Zap, etc.)
|
||||
|
||||
34. **Log aggregation:**
|
||||
- ELK Stack (Elasticsearch, Logstash, Kibana)
|
||||
- Datadog
|
||||
- Splunk
|
||||
- CloudWatch Logs
|
||||
- Loki + Grafana
|
||||
- None (local logs)
|
||||
|
||||
35. **Metrics and Monitoring:**
|
||||
- Prometheus
|
||||
- Datadog
|
||||
- New Relic
|
||||
- Application Insights
|
||||
- CloudWatch
|
||||
- Grafana
|
||||
- None
|
||||
|
||||
36. **Distributed tracing:**
|
||||
- OpenTelemetry
|
||||
- Jaeger
|
||||
- Zipkin
|
||||
- Datadog APM
|
||||
- AWS X-Ray
|
||||
- None
|
||||
|
||||
37. **Health checks:**
|
||||
- Liveness probe (is service up?)
|
||||
- Readiness probe (can accept traffic?)
|
||||
- Startup probe
|
||||
- Dependency checks (database, cache, etc.)
|
||||
- None
|
||||
|
||||
38. **Alerting:**
|
||||
- PagerDuty
|
||||
- Opsgenie
|
||||
- Slack/Discord webhooks
|
||||
- Email
|
||||
- Custom
|
||||
- None
|
||||
|
||||
## Security
|
||||
|
||||
39. **HTTPS/TLS:**
|
||||
- Required (HTTPS only)
|
||||
- Optional (support both)
|
||||
- Terminated at load balancer
|
||||
|
||||
40. **CORS configuration:**
|
||||
- Specific origins (whitelist)
|
||||
- All origins (open)
|
||||
- None needed (same-origin clients)
|
||||
|
||||
41. **Security headers:**
|
||||
- Helmet.js or equivalent
|
||||
- Custom headers
|
||||
- None (basic)
|
||||
|
||||
42. **Input sanitization:**
|
||||
- SQL injection prevention (parameterized queries)
|
||||
- XSS prevention
|
||||
- CSRF protection
|
||||
- All of the above
|
||||
|
||||
43. **Secrets management:**
|
||||
- Environment variables
|
||||
- AWS Secrets Manager
|
||||
- HashiCorp Vault
|
||||
- Azure Key Vault
|
||||
- Kubernetes Secrets
|
||||
- Doppler
|
||||
- Other: **\_\_\_**
|
||||
|
||||
44. **Compliance requirements:**
|
||||
- GDPR
|
||||
- HIPAA
|
||||
- SOC 2
|
||||
- PCI DSS
|
||||
- None
|
||||
|
||||
## Deployment and Infrastructure
|
||||
|
||||
45. **Deployment platform:**
|
||||
- AWS (ECS, EKS, Lambda, Elastic Beanstalk)
|
||||
- Google Cloud (GKE, Cloud Run, App Engine)
|
||||
- Azure (AKS, App Service, Container Instances)
|
||||
- Kubernetes (self-hosted)
|
||||
- Docker Swarm
|
||||
- Heroku
|
||||
- Railway
|
||||
- Fly.io
|
||||
- Vercel/Netlify (serverless)
|
||||
- VPS (DigitalOcean, Linode)
|
||||
- On-premise
|
||||
- Other: **\_\_\_**
|
||||
|
||||
46. **Containerization:**
|
||||
- Docker
|
||||
- Podman
|
||||
- Not containerized (direct deployment)
|
||||
|
||||
47. **Orchestration:**
|
||||
- Kubernetes
|
||||
- Docker Compose (dev/small scale)
|
||||
- AWS ECS
|
||||
- Nomad
|
||||
- None (single server)
|
||||
|
||||
48. **Infrastructure as Code:**
|
||||
- Terraform
|
||||
- CloudFormation
|
||||
- Pulumi
|
||||
- Bicep (Azure)
|
||||
- CDK (AWS)
|
||||
- Ansible
|
||||
- Manual setup
|
||||
|
||||
49. **Load balancing:**
|
||||
- Application Load Balancer (AWS ALB, Azure App Gateway)
|
||||
- Nginx
|
||||
- HAProxy
|
||||
- Kubernetes Ingress
|
||||
- Traefik
|
||||
- Platform-managed
|
||||
- None (single instance)
|
||||
|
||||
50. **Auto-scaling:**
|
||||
- Horizontal (add more instances)
|
||||
- Vertical (increase instance size)
|
||||
- Serverless (automatic)
|
||||
- None (fixed capacity)
|
||||
|
||||
## CI/CD
|
||||
|
||||
51. **CI/CD platform:**
|
||||
- GitHub Actions
|
||||
- GitLab CI
|
||||
- CircleCI
|
||||
- Jenkins
|
||||
- AWS CodePipeline
|
||||
- Azure DevOps
|
||||
- Google Cloud Build
|
||||
- Other: **\_\_\_**
|
||||
|
||||
52. **Deployment strategy:**
|
||||
- Rolling deployment
|
||||
- Blue-green deployment
|
||||
- Canary deployment
|
||||
- Recreate (downtime)
|
||||
- Serverless (automatic)
|
||||
|
||||
53. **Testing in CI/CD:**
|
||||
- Unit tests
|
||||
- Integration tests
|
||||
- E2E tests
|
||||
- Load tests
|
||||
- Security scans
|
||||
- All of the above
|
||||
|
||||
## Performance
|
||||
|
||||
54. **Performance requirements:**
|
||||
- High throughput (1000+ req/s)
|
||||
- Moderate (100-1000 req/s)
|
||||
- Low (< 100 req/s)
|
||||
|
||||
55. **Latency requirements:**
|
||||
- Ultra-low (< 10ms)
|
||||
- Low (< 100ms)
|
||||
- Moderate (< 500ms)
|
||||
- No specific requirement
|
||||
|
||||
56. **Connection pooling:**
|
||||
- Database connection pool
|
||||
- HTTP connection pool (for external APIs)
|
||||
- None needed
|
||||
|
||||
57. **CDN (for static assets):**
|
||||
- CloudFront
|
||||
- Cloudflare
|
||||
- Fastly
|
||||
- None (dynamic only)
|
||||
|
||||
## Data and Storage
|
||||
|
||||
58. **File storage (if needed):**
|
||||
- AWS S3
|
||||
- Google Cloud Storage
|
||||
- Azure Blob Storage
|
||||
- MinIO (self-hosted)
|
||||
- Local filesystem
|
||||
- None needed
|
||||
|
||||
59. **Search functionality:**
|
||||
- Elasticsearch
|
||||
- Algolia
|
||||
- Meilisearch
|
||||
- Typesense
|
||||
- Database full-text search
|
||||
- None needed
|
||||
|
||||
60. **Data backup:**
|
||||
- Automated database backups
|
||||
- Point-in-time recovery
|
||||
- Manual backups
|
||||
- Cloud-provider managed
|
||||
- None (dev/test only)
|
||||
|
||||
## Additional Features
|
||||
|
||||
61. **Webhooks (outgoing):**
|
||||
- Yes (notify external systems)
|
||||
- No
|
||||
|
||||
62. **Scheduled tasks/Cron jobs:**
|
||||
- Yes (cleanup, reports, etc.)
|
||||
- No
|
||||
|
||||
63. **Multi-tenancy:**
|
||||
- Single tenant
|
||||
- Multi-tenant (shared database)
|
||||
- Multi-tenant (separate databases)
|
||||
- Not applicable
|
||||
|
||||
64. **Internationalization (i18n):**
|
||||
- Multiple languages/locales
|
||||
- English only
|
||||
- Not applicable
|
||||
|
||||
65. **Audit logging:**
|
||||
- Track all changes (who, what, when)
|
||||
- Critical operations only
|
||||
- None
|
||||
@@ -1,337 +0,0 @@
|
||||
# Command-Line Tool Architecture Questions
|
||||
|
||||
## Language and Runtime
|
||||
|
||||
1. **Primary language:**
|
||||
- Go (compiled, single binary, great for CLIs)
|
||||
- Rust (compiled, safe, performant)
|
||||
- Python (interpreted, easy distribution via pip)
|
||||
- Node.js/TypeScript (npm distribution)
|
||||
- Bash/Shell script (lightweight, ubiquitous)
|
||||
- Ruby (gem distribution)
|
||||
- Java/Kotlin (JVM, jar)
|
||||
- C/C++ (compiled, fastest)
|
||||
- Other: **\_\_\_**
|
||||
|
||||
2. **Target platforms:**
|
||||
- Linux only
|
||||
- macOS only
|
||||
- Windows only
|
||||
- Linux + macOS
|
||||
- All three (Linux + macOS + Windows)
|
||||
- Specific Unix variants: **\_\_\_**
|
||||
|
||||
3. **Distribution method:**
|
||||
- Single binary (compiled)
|
||||
- Script (interpreted, needs runtime)
|
||||
- Package manager (npm, pip, gem, cargo, etc.)
|
||||
- Installer (brew, apt, yum, scoop, chocolatey)
|
||||
- Container (Docker)
|
||||
- Multiple methods
|
||||
|
||||
## CLI Architecture
|
||||
|
||||
4. **Command structure:**
|
||||
- Single command (e.g., `grep pattern file`)
|
||||
- Subcommands (e.g., `git commit`, `docker run`)
|
||||
- Hybrid (main command + subcommands)
|
||||
- Interactive shell (REPL)
|
||||
|
||||
5. **Argument parsing library:**
|
||||
- Go: cobra, cli, flag
|
||||
- Rust: clap, structopt
|
||||
- Python: argparse, click, typer
|
||||
- Node: commander, yargs, oclif
|
||||
- Bash: getopts, manual parsing
|
||||
- Other: **\_\_\_**
|
||||
|
||||
6. **Interactive mode:**
|
||||
- Non-interactive only (runs and exits)
|
||||
- Interactive prompts (inquirer, survey, etc.)
|
||||
- REPL/shell mode
|
||||
- Both modes supported
|
||||
|
||||
7. **Long-running process:**
|
||||
- Quick execution (completes immediately)
|
||||
- Long-running (daemon/service)
|
||||
- Can run in background
|
||||
- Watch mode (monitors and reacts)
|
||||
|
||||
## Input/Output
|
||||
|
||||
8. **Input sources:**
|
||||
- Command-line arguments
|
||||
- Flags/options
|
||||
- Environment variables
|
||||
- Config file (JSON, YAML, TOML, INI)
|
||||
- Interactive prompts
|
||||
- Stdin (pipe input)
|
||||
- Multiple sources
|
||||
|
||||
9. **Output format:**
|
||||
- Plain text (human-readable)
|
||||
- JSON
|
||||
- YAML
|
||||
- XML
|
||||
- CSV/TSV
|
||||
- Table format
|
||||
- User-selectable format
|
||||
- Multiple formats
|
||||
|
||||
10. **Output destination:**
|
||||
- Stdout (standard output)
|
||||
- Stderr (errors only)
|
||||
- File output
|
||||
- Multiple destinations
|
||||
- Quiet mode (no output)
|
||||
|
||||
11. **Colored output:**
|
||||
- ANSI color codes
|
||||
- Auto-detect TTY (color when terminal, plain when piped)
|
||||
- User-configurable (--color flag)
|
||||
- No colors (plain text only)
|
||||
|
||||
12. **Progress indication:**
|
||||
- Progress bars (for long operations)
|
||||
- Spinners (for waiting)
|
||||
- Step-by-step output
|
||||
- Verbose/debug logging
|
||||
- Silent mode option
|
||||
- None needed (fast operations)
|
||||
|
||||
## Configuration
|
||||
|
||||
13. **Configuration file:**
|
||||
- Required (must exist)
|
||||
- Optional (defaults if missing)
|
||||
- Not needed
|
||||
- Generated on first run
|
||||
|
||||
14. **Config file format:**
|
||||
- JSON
|
||||
- YAML
|
||||
- TOML
|
||||
- INI
|
||||
- Custom format
|
||||
- Multiple formats supported
|
||||
|
||||
15. **Config file location:**
|
||||
- Current directory (project-specific)
|
||||
- User home directory (~/.config, ~/.myapp)
|
||||
- System-wide (/etc/)
|
||||
- User-specified path
|
||||
- Multiple locations (cascade/merge)
|
||||
|
||||
16. **Environment variables:**
|
||||
- Used for configuration
|
||||
- Used for secrets/credentials
|
||||
- Used for runtime behavior
|
||||
- Not used
|
||||
|
||||
## Data and Storage
|
||||
|
||||
17. **Persistent data:**
|
||||
- Cache (temporary, can be deleted)
|
||||
- State (must persist)
|
||||
- User data (important)
|
||||
- No persistent data needed
|
||||
|
||||
18. **Data storage location:**
|
||||
- Standard OS locations (XDG Base Directory, AppData, etc.)
|
||||
- Current directory
|
||||
- User-specified
|
||||
- Temporary directory
|
||||
|
||||
19. **Database/Data format:**
|
||||
- SQLite
|
||||
- JSON files
|
||||
- Key-value store (BoltDB, etc.)
|
||||
- CSV/plain files
|
||||
- Remote database
|
||||
- None needed
|
||||
|
||||
## Execution Model
|
||||
|
||||
20. **Execution pattern:**
|
||||
- Run once and exit
|
||||
- Watch mode (monitor changes)
|
||||
- Server/daemon mode
|
||||
- Cron-style (scheduled)
|
||||
- Pipeline component (part of Unix pipeline)
|
||||
|
||||
21. **Concurrency:**
|
||||
- Single-threaded (sequential)
|
||||
- Multi-threaded (parallel operations)
|
||||
- Async I/O
|
||||
- Not applicable
|
||||
|
||||
22. **Signal handling:**
|
||||
- Graceful shutdown (SIGTERM, SIGINT)
|
||||
- Cleanup on exit
|
||||
- Not needed (quick exit)
|
||||
|
||||
## Networking (if applicable)
|
||||
|
||||
23. **Network operations:**
|
||||
- HTTP client (REST API calls)
|
||||
- WebSocket client
|
||||
- SSH client
|
||||
- Database connections
|
||||
- Other protocols: **\_\_\_**
|
||||
- No networking
|
||||
|
||||
24. **Authentication (if API calls):**
|
||||
- API keys (env vars, config)
|
||||
- OAuth2 flow
|
||||
- Username/password
|
||||
- Certificate-based
|
||||
- None needed
|
||||
|
||||
## Error Handling
|
||||
|
||||
25. **Error reporting:**
|
||||
- Stderr with error messages
|
||||
- Exit codes (0 = success, non-zero = error)
|
||||
- Detailed error messages
|
||||
- Stack traces (debug mode)
|
||||
- Simple messages (user-friendly)
|
||||
|
||||
26. **Exit codes:**
|
||||
- Standard (0 = success, 1 = error)
|
||||
- Multiple exit codes (different error types)
|
||||
- Documented exit codes
|
||||
|
||||
27. **Logging:**
|
||||
- Log levels (debug, info, warn, error)
|
||||
- Log file output
|
||||
- Stderr output
|
||||
- Configurable verbosity (--verbose, --quiet)
|
||||
- No logging (simple tool)
|
||||
|
||||
## Piping and Integration
|
||||
|
||||
28. **Stdin support:**
|
||||
- Reads from stdin (pipe input)
|
||||
- Optional stdin (file or stdin)
|
||||
- No stdin support
|
||||
|
||||
29. **Pipeline behavior:**
|
||||
- Filter (reads stdin, writes stdout)
|
||||
- Generator (no input, outputs data)
|
||||
- Consumer (reads input, no stdout)
|
||||
- Transformer (both input and output)
|
||||
|
||||
30. **Shell completion:**
|
||||
- Bash completion
|
||||
- Zsh completion
|
||||
- Fish completion
|
||||
- PowerShell completion
|
||||
- All shells
|
||||
- None
|
||||
|
||||
## Distribution and Installation
|
||||
|
||||
31. **Package managers:**
|
||||
- Homebrew (macOS/Linux)
|
||||
- apt (Debian/Ubuntu)
|
||||
- yum/dnf (RHEL/Fedora)
|
||||
- Chocolatey/Scoop (Windows)
|
||||
- npm/yarn (Node.js)
|
||||
- pip (Python)
|
||||
- cargo (Rust)
|
||||
- Multiple managers
|
||||
- Manual install only
|
||||
|
||||
32. **Installation method:**
|
||||
- Download binary (GitHub Releases)
|
||||
- Install script (curl | bash)
|
||||
- Package manager
|
||||
- Build from source
|
||||
- Container image
|
||||
- Multiple methods
|
||||
|
||||
33. **Binary distribution:**
|
||||
- Single binary (statically linked)
|
||||
- Multiple binaries (per platform)
|
||||
- With dependencies (bundled)
|
||||
|
||||
34. **Cross-compilation:**
|
||||
- Yes (build for all platforms from one machine)
|
||||
- No (need platform-specific builds)
|
||||
|
||||
## Updates
|
||||
|
||||
35. **Update mechanism:**
|
||||
- Self-update command
|
||||
- Package manager update
|
||||
- Manual download
|
||||
- No updates (stable tool)
|
||||
|
||||
36. **Version checking:**
|
||||
- Check for new versions on run
|
||||
- --version flag
|
||||
- No version tracking
|
||||
|
||||
## Documentation
|
||||
|
||||
37. **Help documentation:**
|
||||
- --help flag (inline help)
|
||||
- Man page
|
||||
- Online docs
|
||||
- README only
|
||||
- All of the above
|
||||
|
||||
38. **Examples/Tutorials:**
|
||||
- Built-in examples (--examples)
|
||||
- Online documentation
|
||||
- README with examples
|
||||
- None (self-explanatory)
|
||||
|
||||
## Testing
|
||||
|
||||
39. **Testing approach:**
|
||||
- Unit tests
|
||||
- Integration tests (full CLI execution)
|
||||
- Snapshot testing (output comparison)
|
||||
- Manual testing
|
||||
- All of the above
|
||||
|
||||
40. **CI/CD:**
|
||||
- GitHub Actions
|
||||
- GitLab CI
|
||||
- Travis CI
|
||||
- Cross-platform testing
|
||||
- Manual builds
|
||||
|
||||
## Performance
|
||||
|
||||
41. **Performance requirements:**
|
||||
- Must be fast (< 100ms)
|
||||
- Moderate (< 1s)
|
||||
- Can be slow (long-running tasks)
|
||||
|
||||
42. **Memory usage:**
|
||||
- Minimal (small files/data)
|
||||
- Streaming (large files, low memory)
|
||||
- Can use significant memory
|
||||
|
||||
## Special Features
|
||||
|
||||
43. **Watch mode:**
|
||||
- Monitor files/directories for changes
|
||||
- Auto-reload/re-run
|
||||
- Not needed
|
||||
|
||||
44. **Dry-run mode:**
|
||||
- Preview changes without applying
|
||||
- Not applicable
|
||||
|
||||
45. **Verbose/Debug mode:**
|
||||
- --verbose flag (detailed output)
|
||||
- --debug flag (even more detail)
|
||||
- Not needed
|
||||
|
||||
46. **Plugins/Extensions:**
|
||||
- Plugin system (user can extend)
|
||||
- Monolithic (no plugins)
|
||||
- Planned for future
|
||||
@@ -1,472 +0,0 @@
|
||||
# Data/Analytics/ML Project Architecture Questions
|
||||
|
||||
## Project Type and Scope
|
||||
|
||||
1. **Primary project focus:**
|
||||
- ETL/Data Pipeline (move and transform data)
|
||||
- Data Analytics (BI, dashboards, reports)
|
||||
- Machine Learning Training (build models)
|
||||
- Machine Learning Inference (serve predictions)
|
||||
- Data Warehouse/Lake (centralized data storage)
|
||||
- Real-time Stream Processing
|
||||
- Data Science Research/Exploration
|
||||
- Multiple focuses
|
||||
|
||||
2. **Scale of data:**
|
||||
- Small (< 1GB, single machine)
|
||||
- Medium (1GB - 1TB, can fit in memory with careful handling)
|
||||
- Large (1TB - 100TB, distributed processing needed)
|
||||
- Very Large (> 100TB, big data infrastructure)
|
||||
|
||||
3. **Data velocity:**
|
||||
- Batch (hourly, daily, weekly)
|
||||
- Micro-batch (every few minutes)
|
||||
- Near real-time (seconds)
|
||||
- Real-time streaming (milliseconds)
|
||||
- Mix
|
||||
|
||||
## Programming Language and Environment
|
||||
|
||||
4. **Primary language:**
|
||||
- Python (pandas, numpy, sklearn, pytorch, tensorflow)
|
||||
- R (tidyverse, caret)
|
||||
- Scala (Spark)
|
||||
- SQL (analytics, transformations)
|
||||
- Java (enterprise data pipelines)
|
||||
- Julia
|
||||
- Multiple languages
|
||||
|
||||
5. **Development environment:**
|
||||
- Jupyter Notebooks (exploration)
|
||||
- Production code (scripts/applications)
|
||||
- Both (notebooks for exploration, code for production)
|
||||
- Cloud notebooks (SageMaker, Vertex AI, Databricks)
|
||||
|
||||
6. **Transition from notebooks to production:**
|
||||
- Convert notebooks to scripts
|
||||
- Use notebooks in production (Papermill, nbconvert)
|
||||
- Keep separate (research vs production)
|
||||
|
||||
## Data Sources
|
||||
|
||||
7. **Data source types:**
|
||||
- Relational databases (PostgreSQL, MySQL, SQL Server)
|
||||
- NoSQL databases (MongoDB, Cassandra)
|
||||
- Data warehouses (Snowflake, BigQuery, Redshift)
|
||||
- APIs (REST, GraphQL)
|
||||
- Files (CSV, JSON, Parquet, Avro)
|
||||
- Streaming sources (Kafka, Kinesis, Pub/Sub)
|
||||
- Cloud storage (S3, GCS, Azure Blob)
|
||||
- SaaS platforms (Salesforce, HubSpot, etc.)
|
||||
- Multiple sources
|
||||
|
||||
8. **Data ingestion frequency:**
|
||||
- One-time load
|
||||
- Scheduled batch (daily, hourly)
|
||||
- Real-time/streaming
|
||||
- On-demand
|
||||
- Mix
|
||||
|
||||
9. **Data ingestion tools:**
|
||||
- Custom scripts (Python, SQL)
|
||||
- Airbyte
|
||||
- Fivetran
|
||||
- Stitch
|
||||
- Apache NiFi
|
||||
- Kafka Connect
|
||||
- Cloud-native (AWS DMS, Google Datastream)
|
||||
- Multiple tools
|
||||
|
||||
## Data Storage
|
||||
|
||||
10. **Primary data storage:**
|
||||
- Data Warehouse (Snowflake, BigQuery, Redshift, Synapse)
|
||||
- Data Lake (S3, GCS, ADLS with Parquet/Avro)
|
||||
- Lakehouse (Databricks, Delta Lake, Iceberg, Hudi)
|
||||
- Relational database
|
||||
- NoSQL database
|
||||
- File system
|
||||
- Multiple storage layers
|
||||
|
||||
11. **Storage format (for files):**
|
||||
- Parquet (columnar, optimized)
|
||||
- Avro (row-based, schema evolution)
|
||||
- ORC (columnar, Hive)
|
||||
- CSV (simple, human-readable)
|
||||
- JSON/JSONL
|
||||
- Delta Lake format
|
||||
- Iceberg format
|
||||
|
||||
12. **Data partitioning strategy:**
|
||||
- By date (year/month/day)
|
||||
- By category/dimension
|
||||
- By hash
|
||||
- No partitioning (small data)
|
||||
|
||||
13. **Data retention policy:**
|
||||
- Keep all data forever
|
||||
- Archive old data (move to cold storage)
|
||||
- Delete after X months/years
|
||||
- Compliance-driven retention
|
||||
|
||||
## Data Processing and Transformation
|
||||
|
||||
14. **Data processing framework:**
|
||||
- pandas (single machine)
|
||||
- Dask (parallel pandas)
|
||||
- Apache Spark (distributed)
|
||||
- Polars (fast, modern dataframes)
|
||||
- SQL (warehouse-native)
|
||||
- Apache Flink (streaming)
|
||||
- dbt (SQL transformations)
|
||||
- Custom code
|
||||
- Multiple frameworks
|
||||
|
||||
15. **Compute platform:**
|
||||
- Local machine (development)
|
||||
- Cloud VMs (EC2, Compute Engine)
|
||||
- Serverless (AWS Lambda, Cloud Functions)
|
||||
- Managed Spark (EMR, Dataproc, Synapse)
|
||||
- Databricks
|
||||
- Snowflake (warehouse compute)
|
||||
- Kubernetes (custom containers)
|
||||
- Multiple platforms
|
||||
|
||||
16. **ETL tool (if applicable):**
|
||||
- dbt (SQL transformations)
|
||||
- Apache Airflow (orchestration + code)
|
||||
- Dagster (data orchestration)
|
||||
- Prefect (workflow orchestration)
|
||||
- AWS Glue
|
||||
- Azure Data Factory
|
||||
- Google Dataflow
|
||||
- Custom scripts
|
||||
- None needed
|
||||
|
||||
17. **Data quality checks:**
|
||||
- Great Expectations
|
||||
- dbt tests
|
||||
- Custom validation scripts
|
||||
- Soda
|
||||
- Monte Carlo
|
||||
- None (trust source data)
|
||||
|
||||
18. **Schema management:**
|
||||
- Schema registry (Confluent, AWS Glue)
|
||||
- Version-controlled schema files
|
||||
- Database schema versioning
|
||||
- Ad-hoc (no formal schema)
|
||||
|
||||
## Machine Learning (if applicable)
|
||||
|
||||
19. **ML framework:**
|
||||
- scikit-learn (classical ML)
|
||||
- PyTorch (deep learning)
|
||||
- TensorFlow/Keras (deep learning)
|
||||
- XGBoost/LightGBM/CatBoost (gradient boosting)
|
||||
- Hugging Face Transformers (NLP)
|
||||
- spaCy (NLP)
|
||||
- Other: **\_\_\_**
|
||||
- Not applicable
|
||||
|
||||
20. **ML use case:**
|
||||
- Classification
|
||||
- Regression
|
||||
- Clustering
|
||||
- Recommendation
|
||||
- NLP (text analysis, generation)
|
||||
- Computer Vision
|
||||
- Time Series Forecasting
|
||||
- Anomaly Detection
|
||||
- Other: **\_\_\_**
|
||||
|
||||
21. **Model training infrastructure:**
|
||||
- Local machine (GPU/CPU)
|
||||
- Cloud VMs with GPU (EC2 P/G instances, GCE A2)
|
||||
- SageMaker
|
||||
- Vertex AI
|
||||
- Azure ML
|
||||
- Databricks ML
|
||||
- Lambda Labs / Paperspace
|
||||
- On-premise cluster
|
||||
|
||||
22. **Experiment tracking:**
|
||||
- MLflow
|
||||
- Weights and Biases
|
||||
- Neptune.ai
|
||||
- Comet
|
||||
- TensorBoard
|
||||
- SageMaker Experiments
|
||||
- Custom logging
|
||||
- None
|
||||
|
||||
23. **Model registry:**
|
||||
- MLflow Model Registry
|
||||
- SageMaker Model Registry
|
||||
- Vertex AI Model Registry
|
||||
- Custom (S3/GCS with metadata)
|
||||
- None
|
||||
|
||||
24. **Feature store:**
|
||||
- Feast
|
||||
- Tecton
|
||||
- SageMaker Feature Store
|
||||
- Databricks Feature Store
|
||||
- Vertex AI Feature Store
|
||||
- Custom (database + cache)
|
||||
- Not needed
|
||||
|
||||
25. **Hyperparameter tuning:**
|
||||
- Manual tuning
|
||||
- Grid search
|
||||
- Random search
|
||||
- Optuna / Hyperopt (Bayesian optimization)
|
||||
- SageMaker/Vertex AI tuning jobs
|
||||
- Ray Tune
|
||||
- Not needed
|
||||
|
||||
26. **Model serving (inference):**
|
||||
- Batch inference (process large datasets)
|
||||
- Real-time API (REST/gRPC)
|
||||
- Streaming inference (Kafka, Kinesis)
|
||||
- Edge deployment (mobile, IoT)
|
||||
- Not applicable (training only)
|
||||
|
||||
27. **Model serving platform (if real-time):**
|
||||
- FastAPI + container (self-hosted)
|
||||
- SageMaker Endpoints
|
||||
- Vertex AI Predictions
|
||||
- Azure ML Endpoints
|
||||
- Seldon Core
|
||||
- KServe
|
||||
- TensorFlow Serving
|
||||
- TorchServe
|
||||
- BentoML
|
||||
- Other: **\_\_\_**
|
||||
|
||||
28. **Model monitoring (in production):**
|
||||
- Data drift detection
|
||||
- Model performance monitoring
|
||||
- Prediction logging
|
||||
- A/B testing infrastructure
|
||||
- None (not in production yet)
|
||||
|
||||
29. **AutoML tools:**
|
||||
- H2O AutoML
|
||||
- Auto-sklearn
|
||||
- TPOT
|
||||
- SageMaker Autopilot
|
||||
- Vertex AI AutoML
|
||||
- Azure AutoML
|
||||
- Not using AutoML
|
||||
|
||||
## Orchestration and Workflow
|
||||
|
||||
30. **Workflow orchestration:**
|
||||
- Apache Airflow
|
||||
- Prefect
|
||||
- Dagster
|
||||
- Argo Workflows
|
||||
- Kubeflow Pipelines
|
||||
- AWS Step Functions
|
||||
- Azure Data Factory
|
||||
- Google Cloud Composer
|
||||
- dbt Cloud
|
||||
- Cron jobs (simple)
|
||||
- None (manual runs)
|
||||
|
||||
31. **Orchestration platform:**
|
||||
- Self-hosted (VMs, K8s)
|
||||
- Managed service (MWAA, Cloud Composer, Prefect Cloud)
|
||||
- Serverless
|
||||
- Multiple platforms
|
||||
|
||||
32. **Job scheduling:**
|
||||
- Time-based (daily, hourly)
|
||||
- Event-driven (S3 upload, database change)
|
||||
- Manual trigger
|
||||
- Continuous (always running)
|
||||
|
||||
33. **Dependency management:**
|
||||
- DAG-based (upstream/downstream tasks)
|
||||
- Data-driven (task runs when data available)
|
||||
- Simple sequential
|
||||
- None (independent tasks)
|
||||
|
||||
## Data Analytics and Visualization
|
||||
|
||||
34. **BI/Visualization tool:**
|
||||
- Tableau
|
||||
- Power BI
|
||||
- Looker / Looker Studio
|
||||
- Metabase
|
||||
- Superset
|
||||
- Redash
|
||||
- Grafana
|
||||
- Custom dashboards (Plotly Dash, Streamlit)
|
||||
- Jupyter notebooks
|
||||
- None needed
|
||||
|
||||
35. **Reporting frequency:**
|
||||
- Real-time dashboards
|
||||
- Daily reports
|
||||
- Weekly/Monthly reports
|
||||
- Ad-hoc queries
|
||||
- Multiple frequencies
|
||||
|
||||
36. **Query interface:**
|
||||
- SQL (direct database queries)
|
||||
- BI tool interface
|
||||
- API (programmatic access)
|
||||
- Notebooks
|
||||
- Multiple interfaces
|
||||
|
||||
## Data Governance and Security
|
||||
|
||||
37. **Data catalog:**
|
||||
- Amundsen
|
||||
- DataHub
|
||||
- AWS Glue Data Catalog
|
||||
- Azure Purview
|
||||
- Alation
|
||||
- Collibra
|
||||
- None (small team)
|
||||
|
||||
38. **Data lineage tracking:**
|
||||
- Automated (DataHub, Amundsen)
|
||||
- Manual documentation
|
||||
- Not tracked
|
||||
|
||||
39. **Access control:**
|
||||
- Row-level security (RLS)
|
||||
- Column-level security
|
||||
- Database/warehouse roles
|
||||
- IAM policies (cloud)
|
||||
- None (internal team only)
|
||||
|
||||
40. **PII/Sensitive data handling:**
|
||||
- Encryption at rest
|
||||
- Encryption in transit
|
||||
- Data masking
|
||||
- Tokenization
|
||||
- Compliance requirements (GDPR, HIPAA)
|
||||
- None (no sensitive data)
|
||||
|
||||
41. **Data versioning:**
|
||||
- DVC (Data Version Control)
|
||||
- LakeFS
|
||||
- Delta Lake time travel
|
||||
- Git LFS (for small data)
|
||||
- Manual snapshots
|
||||
- None
|
||||
|
||||
## Testing and Validation
|
||||
|
||||
42. **Data testing:**
|
||||
- Unit tests (transformation logic)
|
||||
- Integration tests (end-to-end pipeline)
|
||||
- Data quality tests
|
||||
- Schema validation
|
||||
- Manual validation
|
||||
- None
|
||||
|
||||
43. **ML model testing (if applicable):**
|
||||
- Unit tests (code)
|
||||
- Model validation (held-out test set)
|
||||
- Performance benchmarks
|
||||
- Fairness/bias testing
|
||||
- A/B testing in production
|
||||
- None
|
||||
|
||||
## Deployment and CI/CD
|
||||
|
||||
44. **Deployment strategy:**
|
||||
- GitOps (version-controlled config)
|
||||
- Manual deployment
|
||||
- CI/CD pipeline (GitHub Actions, GitLab CI)
|
||||
- Platform-specific (SageMaker, Vertex AI)
|
||||
- Terraform/IaC
|
||||
|
||||
45. **Environment separation:**
|
||||
- Dev / Staging / Production
|
||||
- Dev / Production only
|
||||
- Single environment
|
||||
|
||||
46. **Containerization:**
|
||||
- Docker
|
||||
- Not containerized (native environments)
|
||||
|
||||
## Monitoring and Observability
|
||||
|
||||
47. **Pipeline monitoring:**
|
||||
- Orchestrator built-in (Airflow UI, Prefect)
|
||||
- Custom dashboards
|
||||
- Alerts on failures
|
||||
- Data quality monitoring
|
||||
- None
|
||||
|
||||
48. **Performance monitoring:**
|
||||
- Query performance (slow queries)
|
||||
- Job duration tracking
|
||||
- Cost monitoring (cloud spend)
|
||||
- Resource utilization
|
||||
- None
|
||||
|
||||
49. **Alerting:**
|
||||
- Email
|
||||
- Slack/Discord
|
||||
- PagerDuty
|
||||
- Built-in orchestrator alerts
|
||||
- None
|
||||
|
||||
## Cost Optimization
|
||||
|
||||
50. **Cost considerations:**
|
||||
- Optimize warehouse queries
|
||||
- Auto-scaling clusters
|
||||
- Spot/preemptible instances
|
||||
- Storage tiering (hot/cold)
|
||||
- Cost monitoring dashboards
|
||||
- Not a priority
|
||||
|
||||
## Collaboration and Documentation
|
||||
|
||||
51. **Team collaboration:**
|
||||
- Git for code
|
||||
- Shared notebooks (JupyterHub, Databricks)
|
||||
- Documentation wiki
|
||||
- Slack/communication tools
|
||||
- Pair programming
|
||||
|
||||
52. **Documentation approach:**
|
||||
- README files
|
||||
- Docstrings in code
|
||||
- Notebooks with markdown
|
||||
- Confluence/Notion
|
||||
- Data catalog (self-documenting)
|
||||
- Minimal
|
||||
|
||||
53. **Code review process:**
|
||||
- Pull requests (required)
|
||||
- Peer review (optional)
|
||||
- No formal review
|
||||
|
||||
## Performance and Scale
|
||||
|
||||
54. **Performance requirements:**
|
||||
- Near real-time (< 1 minute latency)
|
||||
- Batch (hours acceptable)
|
||||
- Interactive queries (< 10 seconds)
|
||||
- No specific requirements
|
||||
|
||||
55. **Scalability needs:**
|
||||
- Must scale to 10x data volume
|
||||
- Current scale sufficient
|
||||
- Unknown (future growth)
|
||||
|
||||
56. **Query optimization:**
|
||||
- Indexing
|
||||
- Partitioning
|
||||
- Materialized views
|
||||
- Query caching
|
||||
- Not needed (fast enough)
|
||||
@@ -1,299 +0,0 @@
|
||||
# Desktop Application Architecture Questions
|
||||
|
||||
## Framework and Platform
|
||||
|
||||
1. **Primary framework:**
|
||||
- Electron (JavaScript/TypeScript, web tech, cross-platform)
|
||||
- Tauri (Rust backend, web frontend, lightweight)
|
||||
- .NET MAUI (C#, cross-platform, native UI)
|
||||
- Qt (C++/Python, cross-platform, native)
|
||||
- Flutter Desktop (Dart, cross-platform)
|
||||
- JavaFX (Java, cross-platform)
|
||||
- Swift/SwiftUI (macOS only)
|
||||
- WPF/WinUI 3 (Windows only, C#)
|
||||
- GTK (C/Python, Linux-focused)
|
||||
- Other: **\_\_\_**
|
||||
|
||||
2. **Target platforms:**
|
||||
- Windows only
|
||||
- macOS only
|
||||
- Linux only
|
||||
- Windows + macOS
|
||||
- Windows + macOS + Linux (full cross-platform)
|
||||
- Specific Linux distros: **\_\_\_**
|
||||
|
||||
3. **UI approach:**
|
||||
- Native UI (platform-specific controls)
|
||||
- Web-based UI (HTML/CSS/JS in Electron/Tauri)
|
||||
- Custom-drawn UI (Canvas/OpenGL)
|
||||
- Hybrid (native shell + web content)
|
||||
|
||||
4. **Frontend framework (if web-based UI):**
|
||||
- React
|
||||
- Vue
|
||||
- Svelte
|
||||
- Angular
|
||||
- Vanilla JS
|
||||
- Other: **\_\_\_**
|
||||
|
||||
## Architecture
|
||||
|
||||
5. **Application architecture:**
|
||||
- Single-process (all in one)
|
||||
- Multi-process (main + renderer processes like Electron)
|
||||
- Multi-threaded (background workers)
|
||||
- Plugin-based (extensible architecture)
|
||||
|
||||
6. **Backend/Business logic:**
|
||||
- Embedded in app (monolithic)
|
||||
- Separate local service
|
||||
- Connects to remote API
|
||||
- Hybrid (local + remote)
|
||||
|
||||
7. **Database/Data storage:**
|
||||
- SQLite (local embedded database)
|
||||
- IndexedDB (if web-based)
|
||||
- File-based storage (JSON, custom)
|
||||
- LevelDB/RocksDB
|
||||
- Remote database only
|
||||
- No persistence needed
|
||||
- Other: **\_\_\_**
|
||||
|
||||
## System Integration
|
||||
|
||||
8. **Operating system integration needs:**
|
||||
- File system access (read/write user files)
|
||||
- System tray/menu bar icon
|
||||
- Native notifications
|
||||
- Keyboard shortcuts (global hotkeys)
|
||||
- Clipboard integration
|
||||
- Drag-and-drop support
|
||||
- Context menu integration
|
||||
- File type associations
|
||||
- URL scheme handling (deep linking)
|
||||
- System dialogs (file picker, alerts)
|
||||
- None needed (basic app)
|
||||
|
||||
9. **Hardware access:**
|
||||
- Camera/Microphone
|
||||
- USB devices
|
||||
- Bluetooth
|
||||
- Printers
|
||||
- Scanners
|
||||
- Serial ports
|
||||
- GPU (for rendering/compute)
|
||||
- None needed
|
||||
|
||||
10. **System permissions required:**
|
||||
- Accessibility API (screen reading, input simulation)
|
||||
- Location services
|
||||
- Calendar/Contacts access
|
||||
- Network monitoring
|
||||
- Screen recording
|
||||
- Full disk access
|
||||
- None (sandboxed app)
|
||||
|
||||
## Updates and Distribution
|
||||
|
||||
11. **Auto-update mechanism:**
|
||||
- Electron's autoUpdater
|
||||
- Squirrel (Windows/Mac)
|
||||
- Sparkle (macOS)
|
||||
- Custom update server
|
||||
- App store updates only
|
||||
- Manual download/install
|
||||
- No updates (fixed version)
|
||||
|
||||
12. **Distribution method:**
|
||||
- Microsoft Store (Windows)
|
||||
- Mac App Store
|
||||
- Snap Store (Linux)
|
||||
- Flatpak (Linux)
|
||||
- Homebrew (macOS/Linux)
|
||||
- Direct download from website
|
||||
- Enterprise deployment (MSI, PKG)
|
||||
- Multiple channels
|
||||
|
||||
13. **Code signing:**
|
||||
- Yes - Windows (Authenticode)
|
||||
- Yes - macOS (Apple Developer)
|
||||
- Yes - both
|
||||
- No (development/internal only)
|
||||
|
||||
14. **Notarization (macOS):**
|
||||
- Required (public distribution)
|
||||
- Not needed (internal only)
|
||||
|
||||
## Packaging and Installation
|
||||
|
||||
15. **Windows installer:**
|
||||
- NSIS
|
||||
- Inno Setup
|
||||
- WiX Toolset (MSI)
|
||||
- Squirrel.Windows
|
||||
- MSIX (Windows 10+)
|
||||
- Portable (no installer)
|
||||
- Other: **\_\_\_**
|
||||
|
||||
16. **macOS installer:**
|
||||
- DMG (drag-to-install)
|
||||
- PKG installer
|
||||
- Mac App Store
|
||||
- Homebrew Cask
|
||||
- Other: **\_\_\_**
|
||||
|
||||
17. **Linux packaging:**
|
||||
- AppImage (portable)
|
||||
- Snap
|
||||
- Flatpak
|
||||
- .deb (Debian/Ubuntu)
|
||||
- .rpm (Fedora/RHEL)
|
||||
- Tarball
|
||||
- AUR (Arch)
|
||||
- Multiple formats
|
||||
|
||||
## Configuration and Settings
|
||||
|
||||
18. **Settings storage:**
|
||||
- OS-specific (Registry on Windows, plist on macOS, config files on Linux)
|
||||
- JSON/YAML config file
|
||||
- SQLite database
|
||||
- Remote/cloud sync
|
||||
- Electron Store
|
||||
- Other: **\_\_\_**
|
||||
|
||||
19. **User data location:**
|
||||
- Application Support folder (standard OS location)
|
||||
- User documents folder
|
||||
- Custom location (user selectable)
|
||||
- Cloud storage integration
|
||||
|
||||
## Networking
|
||||
|
||||
20. **Network connectivity:**
|
||||
- Online-only (requires internet)
|
||||
- Offline-first (works without internet)
|
||||
- Hybrid (enhanced with internet)
|
||||
- No network needed
|
||||
|
||||
21. **Backend communication (if applicable):**
|
||||
- REST API
|
||||
- GraphQL
|
||||
- WebSocket
|
||||
- gRPC
|
||||
- Custom protocol
|
||||
- None
|
||||
|
||||
## Authentication and Security
|
||||
|
||||
22. **Authentication (if applicable):**
|
||||
- OAuth2 (Google, Microsoft, etc.)
|
||||
- Username/password with backend
|
||||
- SSO (enterprise)
|
||||
- OS-level authentication (biometric, Windows Hello)
|
||||
- No authentication needed
|
||||
|
||||
23. **Data security:**
|
||||
- Encrypt sensitive data at rest
|
||||
- OS keychain/credential manager
|
||||
- Custom encryption
|
||||
- No sensitive data
|
||||
|
||||
24. **Sandboxing:**
|
||||
- Fully sandboxed (Mac App Store requirement)
|
||||
- Partially sandboxed
|
||||
- Not sandboxed (legacy/compatibility)
|
||||
|
||||
## Performance and Resources
|
||||
|
||||
25. **Performance requirements:**
|
||||
- Lightweight (minimal resource usage)
|
||||
- Moderate (typical desktop app)
|
||||
- Resource-intensive (video editing, 3D, etc.)
|
||||
|
||||
26. **Background operation:**
|
||||
- Runs in background/system tray
|
||||
- Active window only
|
||||
- Can minimize to tray
|
||||
|
||||
27. **Multi-instance handling:**
|
||||
- Allow multiple instances
|
||||
- Single instance only
|
||||
- Single instance with IPC (communicate between instances)
|
||||
|
||||
## Development and Build
|
||||
|
||||
28. **Build tooling:**
|
||||
- electron-builder
|
||||
- electron-forge
|
||||
- Tauri CLI
|
||||
- .NET CLI
|
||||
- CMake (for C++/Qt)
|
||||
- Gradle (for Java)
|
||||
- Xcode (for macOS)
|
||||
- Visual Studio (for Windows)
|
||||
- Other: **\_\_\_**
|
||||
|
||||
29. **Development environment:**
|
||||
- Cross-platform dev (can build on any OS)
|
||||
- Platform-specific (need macOS for Mac builds, etc.)
|
||||
|
||||
30. **CI/CD for builds:**
|
||||
- GitHub Actions
|
||||
- GitLab CI
|
||||
- CircleCI
|
||||
- Azure Pipelines
|
||||
- Custom
|
||||
- Manual builds
|
||||
|
||||
## Testing
|
||||
|
||||
31. **UI testing approach:**
|
||||
- Spectron (Electron)
|
||||
- Playwright
|
||||
- Selenium
|
||||
- Native UI testing (XCTest, UI Automation)
|
||||
- Manual testing only
|
||||
|
||||
32. **End-to-end testing:**
|
||||
- Yes (automated E2E tests)
|
||||
- Limited (smoke tests only)
|
||||
- Manual only
|
||||
|
||||
## Additional Features
|
||||
|
||||
33. **Internationalization (i18n):**
|
||||
- Multiple languages supported
|
||||
- English only
|
||||
- User-selectable language
|
||||
- OS language detection
|
||||
|
||||
34. **Accessibility:**
|
||||
- Full accessibility support (screen readers, keyboard nav)
|
||||
- Basic accessibility
|
||||
- Not a priority
|
||||
|
||||
35. **Crash reporting:**
|
||||
- Sentry
|
||||
- BugSnag
|
||||
- Crashpad (for native crashes)
|
||||
- Custom reporting
|
||||
- None
|
||||
|
||||
36. **Analytics/Telemetry:**
|
||||
- Google Analytics
|
||||
- Mixpanel
|
||||
- PostHog
|
||||
- Custom telemetry
|
||||
- No telemetry (privacy-focused)
|
||||
|
||||
37. **Licensing/DRM (if commercial):**
|
||||
- License key validation
|
||||
- Hardware-locked licenses
|
||||
- Subscription validation
|
||||
- None (free/open-source)
|
||||
|
||||
38. **Plugin/Extension system:**
|
||||
- Yes (user can install plugins)
|
||||
- No (monolithic app)
|
||||
- Planned for future
|
||||
@@ -1,118 +0,0 @@
|
||||
# Embedded System Architecture Questions
|
||||
|
||||
## Hardware Platform
|
||||
|
||||
1. **Microcontroller/SoC:**
|
||||
- ESP32 (WiFi/BLE, popular)
|
||||
- ESP8266 (WiFi, budget)
|
||||
- STM32 (ARM Cortex-M, powerful)
|
||||
- Arduino (AVR, beginner-friendly)
|
||||
- Raspberry Pi Pico (RP2040)
|
||||
- Other: **\_\_\_**
|
||||
|
||||
2. **RTOS or Bare Metal:**
|
||||
- FreeRTOS (popular, tasks/queues)
|
||||
- Zephyr RTOS
|
||||
- Bare metal (no OS, full control)
|
||||
- Arduino framework
|
||||
- ESP-IDF
|
||||
- Other: **\_\_\_**
|
||||
|
||||
3. **Programming language:**
|
||||
- C
|
||||
- C++
|
||||
- MicroPython
|
||||
- Arduino (C++)
|
||||
- Rust
|
||||
|
||||
## Communication
|
||||
|
||||
4. **Primary communication protocol:**
|
||||
- MQTT (IoT messaging)
|
||||
- HTTP/HTTPS (REST APIs)
|
||||
- WebSockets
|
||||
- CoAP
|
||||
- Custom binary protocol
|
||||
|
||||
5. **Local communication (peripherals):**
|
||||
- UART (serial)
|
||||
- I2C (sensors)
|
||||
- SPI (high-speed devices)
|
||||
- GPIO (simple digital)
|
||||
- Analog (ADC)
|
||||
|
||||
6. **Wireless connectivity:**
|
||||
- WiFi
|
||||
- Bluetooth Classic
|
||||
- BLE (Bluetooth Low Energy)
|
||||
- LoRa/LoRaWAN
|
||||
- Zigbee
|
||||
- None (wired only)
|
||||
|
||||
## Cloud/Backend
|
||||
|
||||
7. **Cloud platform:** (if IoT project)
|
||||
- AWS IoT Core
|
||||
- Azure IoT Hub
|
||||
- Google Cloud IoT
|
||||
- Custom MQTT broker
|
||||
- ThingsBoard
|
||||
- None (local only)
|
||||
|
||||
## Power
|
||||
|
||||
8. **Power source:**
|
||||
- USB powered (5V constant)
|
||||
- Battery (need power management)
|
||||
- AC adapter
|
||||
- Solar
|
||||
- Other: **\_\_\_**
|
||||
|
||||
9. **Low power mode needed:**
|
||||
- Yes (battery-powered, deep sleep)
|
||||
- No (always powered)
|
||||
|
||||
## Storage
|
||||
|
||||
10. **Data persistence:**
|
||||
- EEPROM (small config)
|
||||
- Flash (larger data)
|
||||
- SD card
|
||||
- None needed
|
||||
- Cloud only
|
||||
|
||||
## Updates
|
||||
|
||||
11. **Firmware update strategy:**
|
||||
- OTA (Over-The-Air via WiFi)
|
||||
- USB/Serial upload
|
||||
- SD card
|
||||
- No updates (fixed firmware)
|
||||
|
||||
## Sensors/Actuators
|
||||
|
||||
12. **Sensors used:** (list)
|
||||
- Temperature (DHT22, DS18B20, etc.)
|
||||
- Humidity
|
||||
- Motion (PIR, accelerometer)
|
||||
- Light (LDR, photodiode)
|
||||
- Other: **\_\_\_**
|
||||
|
||||
13. **Actuators used:** (list)
|
||||
- LEDs
|
||||
- Motors (DC, servo, stepper)
|
||||
- Relays
|
||||
- Display (LCD, OLED)
|
||||
- Other: **\_\_\_**
|
||||
|
||||
## Real-Time Constraints
|
||||
|
||||
14. **Hard real-time requirements:**
|
||||
- Yes (must respond within X ms, critical)
|
||||
- Soft real-time (best effort)
|
||||
- No timing constraints
|
||||
|
||||
15. **Interrupt-driven or polling:**
|
||||
- Interrupts (responsive)
|
||||
- Polling (simpler)
|
||||
- Mix
|
||||
@@ -1,374 +0,0 @@
|
||||
# Browser Extension Architecture Questions
|
||||
|
||||
## Target Browsers
|
||||
|
||||
1. **Target browser(s):**
|
||||
- Chrome (most common)
|
||||
- Firefox
|
||||
- Edge (Chromium-based)
|
||||
- Safari
|
||||
- Opera
|
||||
- Brave
|
||||
- Multiple browsers (cross-browser)
|
||||
|
||||
2. **Manifest version:**
|
||||
- Manifest V3 (current standard, required for Chrome Web Store)
|
||||
- Manifest V2 (legacy, being phased out)
|
||||
- Both (transition period)
|
||||
|
||||
3. **Cross-browser compatibility:**
|
||||
- Chrome/Edge only (same codebase)
|
||||
- Chrome + Firefox (minor differences)
|
||||
- All major browsers (requires polyfills/adapters)
|
||||
|
||||
## Extension Type and Architecture
|
||||
|
||||
4. **Primary extension type:**
|
||||
- Browser Action (icon in toolbar)
|
||||
- Page Action (icon in address bar, page-specific)
|
||||
- Content Script (runs on web pages)
|
||||
- DevTools Extension (adds features to browser DevTools)
|
||||
- New Tab Override
|
||||
- Bookmarks/History extension
|
||||
- Multiple components
|
||||
|
||||
5. **Extension components needed:**
|
||||
- Background script/Service Worker (always running logic)
|
||||
- Content scripts (inject into web pages)
|
||||
- Popup UI (click toolbar icon)
|
||||
- Options page (settings/configuration)
|
||||
- Side panel (persistent panel, MV3)
|
||||
- DevTools page
|
||||
- New Tab page
|
||||
|
||||
6. **Content script injection:**
|
||||
- All pages (matches: <all_urls>)
|
||||
- Specific domains (matches: \*.example.com)
|
||||
- User-activated (inject on demand)
|
||||
- Not needed
|
||||
|
||||
## UI and Framework
|
||||
|
||||
7. **UI framework:**
|
||||
- Vanilla JS (no framework)
|
||||
- React
|
||||
- Vue
|
||||
- Svelte
|
||||
- Preact (lightweight React)
|
||||
- Web Components
|
||||
- Other: **\_\_\_**
|
||||
|
||||
8. **Build tooling:**
|
||||
- Webpack
|
||||
- Vite
|
||||
- Rollup
|
||||
- Parcel
|
||||
- esbuild
|
||||
- WXT (extension-specific)
|
||||
- Plasmo (extension framework)
|
||||
- None (plain JS)
|
||||
|
||||
9. **CSS framework:**
|
||||
- Tailwind CSS
|
||||
- CSS Modules
|
||||
- Styled Components
|
||||
- Plain CSS
|
||||
- Sass/SCSS
|
||||
- None (minimal styling)
|
||||
|
||||
10. **Popup UI:**
|
||||
- Simple (HTML + CSS)
|
||||
- Interactive (full app)
|
||||
- None (no popup)
|
||||
|
||||
11. **Options page:**
|
||||
- Simple form (HTML)
|
||||
- Full settings UI (framework-based)
|
||||
- Embedded in popup
|
||||
- None (no settings)
|
||||
|
||||
## Permissions
|
||||
|
||||
12. **Storage permissions:**
|
||||
- chrome.storage.local (local storage)
|
||||
- chrome.storage.sync (sync across devices)
|
||||
- IndexedDB
|
||||
- None (no data persistence)
|
||||
|
||||
13. **Host permissions (access to websites):**
|
||||
- Specific domains only
|
||||
- All URLs (<all_urls>)
|
||||
- ActiveTab only (current tab when clicked)
|
||||
- Optional permissions (user grants on demand)
|
||||
|
||||
14. **API permissions needed:**
|
||||
- tabs (query/manipulate tabs)
|
||||
- webRequest (intercept network requests)
|
||||
- cookies
|
||||
- history
|
||||
- bookmarks
|
||||
- downloads
|
||||
- notifications
|
||||
- contextMenus (right-click menu)
|
||||
- clipboardWrite/Read
|
||||
- identity (OAuth)
|
||||
- Other: **\_\_\_**
|
||||
|
||||
15. **Sensitive permissions:**
|
||||
- webRequestBlocking (modify requests, requires justification)
|
||||
- declarativeNetRequest (MV3 alternative)
|
||||
- None
|
||||
|
||||
## Data and Storage
|
||||
|
||||
16. **Data storage:**
|
||||
- chrome.storage.local
|
||||
- chrome.storage.sync (synced across devices)
|
||||
- IndexedDB
|
||||
- localStorage (limited, not recommended)
|
||||
- Remote storage (own backend)
|
||||
- Multiple storage types
|
||||
|
||||
17. **Storage size:**
|
||||
- Small (< 100KB)
|
||||
- Medium (100KB - 5MB, storage.sync limit)
|
||||
- Large (> 5MB, need storage.local or IndexedDB)
|
||||
|
||||
18. **Data sync:**
|
||||
- Sync across user's devices (chrome.storage.sync)
|
||||
- Local only (storage.local)
|
||||
- Custom backend sync
|
||||
|
||||
## Communication
|
||||
|
||||
19. **Message passing (internal):**
|
||||
- Content script <-> Background script
|
||||
- Popup <-> Background script
|
||||
- Content script <-> Content script
|
||||
- Not needed
|
||||
|
||||
20. **Messaging library:**
|
||||
- Native chrome.runtime.sendMessage
|
||||
- Wrapper library (webext-bridge, etc.)
|
||||
- Custom messaging layer
|
||||
|
||||
21. **Backend communication:**
|
||||
- REST API
|
||||
- WebSocket
|
||||
- GraphQL
|
||||
- Firebase/Supabase
|
||||
- None (client-only extension)
|
||||
|
||||
## Web Integration
|
||||
|
||||
22. **DOM manipulation:**
|
||||
- Read DOM (observe, analyze)
|
||||
- Modify DOM (inject, hide, change elements)
|
||||
- Both
|
||||
- None (no content scripts)
|
||||
|
||||
23. **Page interaction method:**
|
||||
- Content scripts (extension context)
|
||||
- Injected scripts (page context, access page variables)
|
||||
- Both (communicate via postMessage)
|
||||
|
||||
24. **CSS injection:**
|
||||
- Inject custom styles
|
||||
- Override site styles
|
||||
- None
|
||||
|
||||
25. **Network request interception:**
|
||||
- Read requests (webRequest)
|
||||
- Block/modify requests (declarativeNetRequest in MV3)
|
||||
- Not needed
|
||||
|
||||
## Background Processing
|
||||
|
||||
26. **Background script type (MV3):**
|
||||
- Service Worker (MV3, event-driven, terminates when idle)
|
||||
- Background page (MV2, persistent)
|
||||
|
||||
27. **Background tasks:**
|
||||
- Event listeners (tabs, webRequest, etc.)
|
||||
- Periodic tasks (alarms)
|
||||
- Message routing (popup <-> content scripts)
|
||||
- API calls
|
||||
- None
|
||||
|
||||
28. **Persistent state (MV3 challenge):**
|
||||
- Store in chrome.storage (service worker can terminate)
|
||||
- Use alarms for periodic tasks
|
||||
- Not applicable (MV2 or stateless)
|
||||
|
||||
## Authentication
|
||||
|
||||
29. **User authentication:**
|
||||
- OAuth (chrome.identity API)
|
||||
- Custom login (username/password with backend)
|
||||
- API key
|
||||
- No authentication needed
|
||||
|
||||
30. **OAuth provider:**
|
||||
- Google
|
||||
- GitHub
|
||||
- Custom OAuth server
|
||||
- Not using OAuth
|
||||
|
||||
## Distribution
|
||||
|
||||
31. **Distribution method:**
|
||||
- Chrome Web Store (public)
|
||||
- Chrome Web Store (unlisted)
|
||||
- Firefox Add-ons (AMO)
|
||||
- Edge Add-ons Store
|
||||
- Self-hosted (enterprise, sideload)
|
||||
- Multiple stores
|
||||
|
||||
32. **Pricing model:**
|
||||
- Free
|
||||
- Freemium (basic free, premium paid)
|
||||
- Paid (one-time purchase)
|
||||
- Subscription
|
||||
- Enterprise licensing
|
||||
|
||||
33. **In-extension purchases:**
|
||||
- Via web (redirect to website)
|
||||
- Stripe integration
|
||||
- No purchases
|
||||
|
||||
## Privacy and Security
|
||||
|
||||
34. **User privacy:**
|
||||
- No data collection
|
||||
- Anonymous analytics
|
||||
- User data collected (with consent)
|
||||
- Data sent to server
|
||||
|
||||
35. **Content Security Policy (CSP):**
|
||||
- Default CSP (secure)
|
||||
- Custom CSP (if needed for external scripts)
|
||||
|
||||
36. **External scripts:**
|
||||
- None (all code bundled)
|
||||
- CDN scripts (requires CSP relaxation)
|
||||
- Inline scripts (avoid in MV3)
|
||||
|
||||
37. **Sensitive data handling:**
|
||||
- Encrypt stored data
|
||||
- Use native credential storage
|
||||
- No sensitive data
|
||||
|
||||
## Testing
|
||||
|
||||
38. **Testing approach:**
|
||||
- Manual testing (load unpacked)
|
||||
- Unit tests (Jest, Vitest)
|
||||
- E2E tests (Puppeteer, Playwright)
|
||||
- Cross-browser testing
|
||||
- Minimal testing
|
||||
|
||||
39. **Test automation:**
|
||||
- Automated tests in CI
|
||||
- Manual testing only
|
||||
|
||||
## Updates and Deployment
|
||||
|
||||
40. **Update strategy:**
|
||||
- Auto-update (store handles)
|
||||
- Manual updates (enterprise)
|
||||
|
||||
41. **Versioning:**
|
||||
- Semantic versioning (1.2.3)
|
||||
- Chrome Web Store version requirements
|
||||
|
||||
42. **CI/CD:**
|
||||
- GitHub Actions
|
||||
- GitLab CI
|
||||
- Manual builds/uploads
|
||||
- Web Store API (automated publishing)
|
||||
|
||||
## Features
|
||||
|
||||
43. **Context menu integration:**
|
||||
- Right-click menu items
|
||||
- Not needed
|
||||
|
||||
44. **Omnibox integration:**
|
||||
- Custom omnibox keyword
|
||||
- Not needed
|
||||
|
||||
45. **Browser notifications:**
|
||||
- Chrome notifications API
|
||||
- Not needed
|
||||
|
||||
46. **Keyboard shortcuts:**
|
||||
- chrome.commands API
|
||||
- Not needed
|
||||
|
||||
47. **Clipboard access:**
|
||||
- Read clipboard
|
||||
- Write to clipboard
|
||||
- Not needed
|
||||
|
||||
48. **Side panel (MV3):**
|
||||
- Persistent side panel UI
|
||||
- Not needed
|
||||
|
||||
49. **DevTools integration:**
|
||||
- Add DevTools panel
|
||||
- Not needed
|
||||
|
||||
50. **Internationalization (i18n):**
|
||||
- Multiple languages
|
||||
- English only
|
||||
|
||||
## Analytics and Monitoring
|
||||
|
||||
51. **Analytics:**
|
||||
- Google Analytics (with privacy considerations)
|
||||
- PostHog
|
||||
- Mixpanel
|
||||
- Custom analytics
|
||||
- None
|
||||
|
||||
52. **Error tracking:**
|
||||
- Sentry
|
||||
- Bugsnag
|
||||
- Custom error logging
|
||||
- None
|
||||
|
||||
53. **User feedback:**
|
||||
- In-extension feedback form
|
||||
- External form (website)
|
||||
- Email/support
|
||||
- None
|
||||
|
||||
## Performance
|
||||
|
||||
54. **Performance considerations:**
|
||||
- Minimal memory footprint
|
||||
- Lazy loading
|
||||
- Efficient DOM queries
|
||||
- Not a priority
|
||||
|
||||
55. **Bundle size:**
|
||||
- Keep small (< 1MB)
|
||||
- Moderate (1-5MB)
|
||||
- Large (> 5MB, media/assets)
|
||||
|
||||
## Compliance and Review
|
||||
|
||||
56. **Chrome Web Store review:**
|
||||
- Standard review (automated + manual)
|
||||
- Sensitive permissions (extra scrutiny)
|
||||
- Not yet submitted
|
||||
|
||||
57. **Privacy policy:**
|
||||
- Required (collecting data)
|
||||
- Not required (no data collection)
|
||||
- Already prepared
|
||||
|
||||
58. **Code obfuscation:**
|
||||
- Minified only
|
||||
- Not allowed (stores require readable code)
|
||||
- Using source maps
|
||||
@@ -1,133 +0,0 @@
|
||||
# Game Architecture Questions
|
||||
|
||||
## Engine and Platform
|
||||
|
||||
1. **Game engine:**
|
||||
- Unity (C#, versatile, large ecosystem)
|
||||
- Unreal Engine (C++, AAA graphics)
|
||||
- Godot (GDScript/C#, open-source)
|
||||
- Custom engine
|
||||
- Other: **\_\_\_**
|
||||
|
||||
2. **Target platforms:**
|
||||
- PC (Windows, Mac, Linux)
|
||||
- Mobile (iOS, Android)
|
||||
- Console (Xbox, PlayStation, Switch)
|
||||
- Web (WebGL)
|
||||
- Mix: **\_\_\_**
|
||||
|
||||
3. **2D or 3D:**
|
||||
- 2D
|
||||
- 3D
|
||||
- 2.5D (3D with 2D gameplay)
|
||||
|
||||
## Architecture Pattern
|
||||
|
||||
4. **Core architecture:**
|
||||
- ECS (Entity Component System) - Unity DOTS, Bevy
|
||||
- OOP (Object-Oriented) - Unity MonoBehaviours, Unreal Actors
|
||||
- Data-Oriented Design
|
||||
- Mix
|
||||
|
||||
5. **Scene structure:**
|
||||
- Single scene (load/unload prefabs)
|
||||
- Multi-scene (additive loading)
|
||||
- Scene per level
|
||||
|
||||
## Multiplayer (if applicable)
|
||||
|
||||
6. **Multiplayer type:**
|
||||
- Single-player only
|
||||
- Local multiplayer (same device/splitscreen)
|
||||
- Online multiplayer
|
||||
- Both local + online
|
||||
|
||||
7. **If online multiplayer - networking:**
|
||||
- Photon (popular, managed)
|
||||
- Mirror (Unity, open-source)
|
||||
- Netcode for GameObjects (Unity, official)
|
||||
- Unreal Replication
|
||||
- Custom netcode
|
||||
- Other: **\_\_\_**
|
||||
|
||||
8. **Multiplayer architecture:**
|
||||
- Client-Server (authoritative server)
|
||||
- Peer-to-Peer
|
||||
- Dedicated servers
|
||||
- Listen server (player hosts)
|
||||
|
||||
9. **Backend for multiplayer:**
|
||||
- PlayFab (Microsoft, game backend)
|
||||
- Nakama (open-source game server)
|
||||
- GameSparks (AWS)
|
||||
- Firebase
|
||||
- Custom backend
|
||||
|
||||
## Save System
|
||||
|
||||
10. **Save/persistence:**
|
||||
- Local only (PlayerPrefs, file)
|
||||
- Cloud save (Steam Cloud, PlayFab)
|
||||
- Both local + cloud sync
|
||||
- No saves needed
|
||||
|
||||
## Monetization (if applicable)
|
||||
|
||||
11. **Monetization model:**
|
||||
- Paid (one-time purchase)
|
||||
- Free-to-play + IAP
|
||||
- Free-to-play + Ads
|
||||
- Subscription
|
||||
- None (hobby/portfolio)
|
||||
|
||||
12. **If IAP - platform:**
|
||||
- Unity IAP (cross-platform)
|
||||
- Steam microtransactions
|
||||
- Mobile stores (App Store, Google Play)
|
||||
- Custom (virtual currency)
|
||||
|
||||
13. **If Ads:**
|
||||
- Unity Ads
|
||||
- AdMob (Google)
|
||||
- IronSource
|
||||
- Other: **\_\_\_**
|
||||
|
||||
## Assets
|
||||
|
||||
14. **Asset pipeline:**
|
||||
- Unity Asset Bundles
|
||||
- Unreal Pak files
|
||||
- Addressables (Unity)
|
||||
- Streaming from CDN
|
||||
- All assets in build
|
||||
|
||||
15. **Art creation tools:**
|
||||
- Blender (3D modeling)
|
||||
- Maya/3DS Max
|
||||
- Photoshop (textures)
|
||||
- Substance (materials)
|
||||
- Aseprite (pixel art)
|
||||
- Other: **\_\_\_**
|
||||
|
||||
## Analytics and LiveOps
|
||||
|
||||
16. **Analytics:**
|
||||
- Unity Analytics
|
||||
- GameAnalytics
|
||||
- Firebase Analytics
|
||||
- PlayFab Analytics
|
||||
- None
|
||||
|
||||
17. **LiveOps/Events:**
|
||||
- Remote config (Unity, Firebase)
|
||||
- In-game events
|
||||
- Season passes
|
||||
- None (fixed content)
|
||||
|
||||
## Audio
|
||||
|
||||
18. **Audio middleware:**
|
||||
- Unity Audio (built-in)
|
||||
- FMOD
|
||||
- Wwise
|
||||
- Simple (no middleware)
|
||||
@@ -1,484 +0,0 @@
|
||||
# Infrastructure/DevOps Tool Architecture Questions
|
||||
|
||||
## Tool Type
|
||||
|
||||
1. **Primary tool category:**
|
||||
- Infrastructure as Code (IaC) module/provider
|
||||
- Kubernetes Operator
|
||||
- CI/CD plugin/action
|
||||
- Monitoring/Observability tool
|
||||
- Configuration management tool
|
||||
- Deployment automation tool
|
||||
- GitOps tool
|
||||
- Security/Compliance scanner
|
||||
- Cost optimization tool
|
||||
- Multi-tool platform
|
||||
|
||||
## Infrastructure as Code (IaC)
|
||||
|
||||
2. **IaC platform (if applicable):**
|
||||
- Terraform
|
||||
- Pulumi
|
||||
- CloudFormation (AWS)
|
||||
- Bicep (Azure)
|
||||
- CDK (AWS, TypeScript/Python)
|
||||
- CDKTF (Terraform with CDK)
|
||||
- Ansible
|
||||
- Chef
|
||||
- Puppet
|
||||
- Not applicable
|
||||
|
||||
3. **IaC language:**
|
||||
- HCL (Terraform)
|
||||
- TypeScript (Pulumi, CDK)
|
||||
- Python (Pulumi, CDK)
|
||||
- Go (Pulumi)
|
||||
- YAML (CloudFormation, Ansible)
|
||||
- JSON
|
||||
- Domain-specific language
|
||||
- Other: **\_\_\_**
|
||||
|
||||
4. **Terraform specifics (if applicable):**
|
||||
- Terraform module (reusable component)
|
||||
- Terraform provider (new resource types)
|
||||
- Terraform backend (state storage)
|
||||
- Not using Terraform
|
||||
|
||||
5. **Target cloud platforms:**
|
||||
- AWS
|
||||
- Azure
|
||||
- Google Cloud
|
||||
- Multi-cloud
|
||||
- On-premise (VMware, OpenStack)
|
||||
- Hybrid cloud
|
||||
- Kubernetes (cloud-agnostic)
|
||||
|
||||
## Kubernetes Operator (if applicable)
|
||||
|
||||
6. **Operator framework:**
|
||||
- Operator SDK (Go)
|
||||
- Kubebuilder (Go)
|
||||
- KUDO
|
||||
- Kopf (Python)
|
||||
- Java Operator SDK
|
||||
- Metacontroller
|
||||
- Custom (raw client-go)
|
||||
- Not applicable
|
||||
|
||||
7. **Operator type:**
|
||||
- Application operator (manage app lifecycle)
|
||||
- Infrastructure operator (manage resources)
|
||||
- Data operator (databases, queues)
|
||||
- Security operator
|
||||
- Other: **\_\_\_**
|
||||
|
||||
8. **Custom Resource Definitions (CRDs):**
|
||||
- Define new CRDs
|
||||
- Use existing CRDs
|
||||
- Multiple CRDs
|
||||
|
||||
9. **Operator scope:**
|
||||
- Namespace-scoped
|
||||
- Cluster-scoped
|
||||
- Both
|
||||
|
||||
10. **Reconciliation pattern:**
|
||||
- Level-based (check desired vs actual state)
|
||||
- Edge-triggered (react to changes)
|
||||
- Hybrid
|
||||
|
||||
## CI/CD Integration
|
||||
|
||||
11. **CI/CD platform (if plugin/action):**
|
||||
- GitHub Actions
|
||||
- GitLab CI
|
||||
- Jenkins
|
||||
- CircleCI
|
||||
- Azure DevOps
|
||||
- Bitbucket Pipelines
|
||||
- Drone CI
|
||||
- Tekton
|
||||
- Argo Workflows
|
||||
- Not applicable
|
||||
|
||||
12. **Plugin type (if CI/CD plugin):**
|
||||
- Build step
|
||||
- Test step
|
||||
- Deployment step
|
||||
- Security scan
|
||||
- Notification
|
||||
- Custom action
|
||||
- Not applicable
|
||||
|
||||
13. **GitHub Action specifics (if applicable):**
|
||||
- JavaScript action
|
||||
- Docker container action
|
||||
- Composite action (reusable workflow)
|
||||
- Not using GitHub Actions
|
||||
|
||||
## Configuration and State Management
|
||||
|
||||
14. **Configuration approach:**
|
||||
- Configuration files (YAML, JSON, HCL)
|
||||
|
||||
- Environment variables
|
||||
- Command-line flags
|
||||
- API-based configuration
|
||||
- Multiple methods
|
||||
|
||||
15. **State management:**
|
||||
- Stateless (idempotent operations)
|
||||
- Local state file
|
||||
- Remote state (S3, Consul, Terraform Cloud)
|
||||
- Database state
|
||||
- Kubernetes ConfigMaps/Secrets
|
||||
- Not applicable
|
||||
|
||||
16. **Secrets management:**
|
||||
- Vault (HashiCorp)
|
||||
- AWS Secrets Manager
|
||||
- Azure Key Vault
|
||||
- Google Secret Manager
|
||||
- Kubernetes Secrets
|
||||
- SOPS (encrypted files)
|
||||
- Sealed Secrets
|
||||
- External Secrets Operator
|
||||
- Environment variables
|
||||
- Not applicable
|
||||
|
||||
## Execution Model
|
||||
|
||||
17. **Execution pattern:**
|
||||
- CLI tool (run locally or in CI)
|
||||
- Kubernetes controller (runs in cluster)
|
||||
- Daemon/agent (runs on nodes/VMs)
|
||||
- Web service (API-driven)
|
||||
- Scheduled job (cron, K8s CronJob)
|
||||
- Event-driven (webhook, queue)
|
||||
|
||||
18. **Deployment model:**
|
||||
- Single binary (Go, Rust)
|
||||
- Container image
|
||||
- Script (Python, Bash)
|
||||
- Helm chart
|
||||
- Kustomize
|
||||
- Installed via package manager
|
||||
- Multiple deployment methods
|
||||
|
||||
19. **Concurrency:**
|
||||
- Single-threaded (sequential)
|
||||
- Multi-threaded (parallel operations)
|
||||
- Async I/O
|
||||
- Not applicable
|
||||
|
||||
## Resource Management
|
||||
|
||||
20. **Resources managed:**
|
||||
- Compute (VMs, containers, functions)
|
||||
- Networking (VPC, load balancers, DNS)
|
||||
- Storage (disks, buckets, databases)
|
||||
- Identity (IAM, service accounts)
|
||||
- Security (firewall, policies)
|
||||
- Kubernetes resources (pods, services, etc.)
|
||||
- Multiple resource types
|
||||
|
||||
21. **Resource lifecycle:**
|
||||
- Create/provision
|
||||
- Update/modify
|
||||
- Delete/destroy
|
||||
- Import existing resources
|
||||
- All of the above
|
||||
|
||||
22. **Dependency management:**
|
||||
- Explicit dependencies (depends_on)
|
||||
- Implicit dependencies (reference outputs)
|
||||
- DAG-based (topological sort)
|
||||
- None (independent resources)
|
||||
|
||||
## Language and Framework
|
||||
|
||||
23. **Implementation language:**
|
||||
- Go (common for K8s, CLI tools)
|
||||
- Python (scripting, automation)
|
||||
- TypeScript/JavaScript (Pulumi, CDK)
|
||||
- Rust (performance-critical tools)
|
||||
- Bash/Shell (simple scripts)
|
||||
- Java (enterprise tools)
|
||||
- Ruby (Chef, legacy tools)
|
||||
- Other: **\_\_\_**
|
||||
|
||||
24. **Key libraries/SDKs:**
|
||||
- AWS SDK
|
||||
- Azure SDK
|
||||
- Google Cloud SDK
|
||||
- Kubernetes client-go
|
||||
- Terraform Plugin SDK
|
||||
- Ansible modules
|
||||
- Custom libraries
|
||||
- Other: **\_\_\_**
|
||||
|
||||
## API and Integration
|
||||
|
||||
25. **API exposure:**
|
||||
- REST API
|
||||
- gRPC API
|
||||
- CLI only (no API)
|
||||
- Kubernetes API (CRDs)
|
||||
- Webhook receiver
|
||||
- Multiple interfaces
|
||||
|
||||
26. **External integrations:**
|
||||
- Cloud provider APIs (AWS, Azure, GCP)
|
||||
- Kubernetes API
|
||||
- Monitoring systems (Prometheus, Datadog)
|
||||
- Notification services (Slack, PagerDuty)
|
||||
- Version control (Git)
|
||||
- Other: **\_\_\_**
|
||||
|
||||
## Idempotency and Safety
|
||||
|
||||
27. **Idempotency:**
|
||||
- Fully idempotent (safe to run multiple times)
|
||||
- Conditionally idempotent (with flags)
|
||||
- Not idempotent (manual cleanup needed)
|
||||
|
||||
28. **Dry-run/Plan mode:**
|
||||
- Yes (preview changes before applying)
|
||||
- No (immediate execution)
|
||||
|
||||
29. **Rollback capability:**
|
||||
- Automatic rollback on failure
|
||||
- Manual rollback (previous state)
|
||||
- No rollback (manual cleanup)
|
||||
|
||||
30. **Destructive operations:**
|
||||
- Confirmation required (--force flag)
|
||||
- Automatic (with safeguards)
|
||||
- Not applicable (read-only tool)
|
||||
|
||||
## Observability
|
||||
|
||||
31. **Logging:**
|
||||
- Structured logging (JSON)
|
||||
- Plain text logs
|
||||
- Library: (logrus, zap, winston, etc.)
|
||||
- Multiple log levels (debug, info, warn, error)
|
||||
|
||||
32. **Metrics:**
|
||||
- Prometheus metrics
|
||||
- CloudWatch metrics
|
||||
- Datadog metrics
|
||||
- Custom metrics
|
||||
- None
|
||||
|
||||
33. **Tracing:**
|
||||
- OpenTelemetry
|
||||
- Jaeger
|
||||
- Not applicable
|
||||
|
||||
34. **Health checks:**
|
||||
- Kubernetes liveness/readiness probes
|
||||
- HTTP health endpoint
|
||||
- Not applicable (CLI tool)
|
||||
|
||||
## Testing
|
||||
|
||||
35. **Testing approach:**
|
||||
- Unit tests (mock external APIs)
|
||||
- Integration tests (real cloud resources)
|
||||
- E2E tests (full workflow)
|
||||
- Contract tests (API compatibility)
|
||||
- Manual testing
|
||||
- All of the above
|
||||
|
||||
36. **Test environment:**
|
||||
- Local (mocked)
|
||||
- Dev/staging cloud account
|
||||
- Kind/minikube (for K8s)
|
||||
- Multiple environments
|
||||
|
||||
37. **Terraform testing (if applicable):**
|
||||
- Terratest (Go-based testing)
|
||||
- terraform validate
|
||||
- terraform plan (in CI)
|
||||
- Not applicable
|
||||
|
||||
38. **Kubernetes testing (if operator):**
|
||||
- Unit tests (Go testing)
|
||||
- envtest (fake API server)
|
||||
- Kind cluster (real cluster)
|
||||
- Not applicable
|
||||
|
||||
## Documentation
|
||||
|
||||
39. **Documentation format:**
|
||||
- README (basic)
|
||||
- Detailed docs (Markdown files)
|
||||
- Generated docs (godoc, Sphinx, etc.)
|
||||
- Doc website (MkDocs, Docusaurus)
|
||||
- Interactive examples
|
||||
- All of the above
|
||||
|
||||
40. **Usage examples:**
|
||||
- Code examples
|
||||
- Tutorial walkthroughs
|
||||
- Video demos
|
||||
- Sample configurations
|
||||
- Minimal (README only)
|
||||
|
||||
## Distribution
|
||||
|
||||
41. **Distribution method:**
|
||||
- GitHub Releases (binaries)
|
||||
- Package manager (homebrew, apt, yum)
|
||||
- Container registry (Docker Hub, ghcr.io)
|
||||
- Terraform Registry
|
||||
- Helm chart repository
|
||||
- Language package manager (npm, pip, gem)
|
||||
- Multiple methods
|
||||
|
||||
42. **Installation:**
|
||||
- Download binary
|
||||
- Package manager install
|
||||
- Helm install (for K8s)
|
||||
- Container image pull
|
||||
- Build from source
|
||||
- Multiple methods
|
||||
|
||||
43. **Versioning:**
|
||||
- Semantic versioning (semver)
|
||||
- Calendar versioning
|
||||
- API version compatibility
|
||||
|
||||
## Updates and Lifecycle
|
||||
|
||||
44. **Update mechanism:**
|
||||
- Manual download/install
|
||||
- Package manager update
|
||||
- Auto-update (self-update command)
|
||||
- Helm upgrade
|
||||
- Not applicable
|
||||
|
||||
45. **Backward compatibility:**
|
||||
- Fully backward compatible
|
||||
- Breaking changes documented
|
||||
- Migration guides provided
|
||||
|
||||
46. **Deprecation policy:**
|
||||
- Formal deprecation warnings
|
||||
- Support for N-1 versions
|
||||
- No formal policy
|
||||
|
||||
## Security
|
||||
|
||||
47. **Credentials handling:**
|
||||
- Environment variables
|
||||
- Config file (encrypted)
|
||||
- Cloud provider IAM (instance roles, IRSA)
|
||||
- Kubernetes ServiceAccount
|
||||
- Vault integration
|
||||
- Multiple methods
|
||||
|
||||
48. **Least privilege:**
|
||||
- Minimal permissions documented
|
||||
- Permission templates provided (IAM policies)
|
||||
- No specific guidance
|
||||
|
||||
49. **Code signing:**
|
||||
- Signed binaries
|
||||
- Container image signing (cosign)
|
||||
- Not signed
|
||||
|
||||
50. **Supply chain security:**
|
||||
- SBOM (Software Bill of Materials)
|
||||
- Provenance attestation
|
||||
- Dependency scanning
|
||||
- None
|
||||
|
||||
## Compliance and Governance
|
||||
|
||||
51. **Compliance focus:**
|
||||
- Policy enforcement (OPA, Kyverno)
|
||||
- Audit logging
|
||||
- Cost tagging
|
||||
- Security posture
|
||||
- Not applicable
|
||||
|
||||
52. **Policy as Code:**
|
||||
- OPA (Open Policy Agent)
|
||||
- Sentinel (Terraform)
|
||||
- Kyverno (Kubernetes)
|
||||
- Custom policies
|
||||
- Not applicable
|
||||
|
||||
53. **Audit trail:**
|
||||
- Change tracking
|
||||
- GitOps audit (Git history)
|
||||
- CloudTrail/Activity logs
|
||||
- Not applicable
|
||||
|
||||
## Performance and Scale
|
||||
|
||||
54. **Performance requirements:**
|
||||
- Fast execution (seconds)
|
||||
- Moderate (minutes)
|
||||
- Long-running (hours acceptable)
|
||||
- Background reconciliation (continuous)
|
||||
|
||||
55. **Scale considerations:**
|
||||
- Small scale (< 10 resources)
|
||||
- Medium (10-100 resources)
|
||||
- Large (100-1000 resources)
|
||||
- Very large (1000+ resources)
|
||||
|
||||
56. **Rate limiting:**
|
||||
- Respect cloud API limits
|
||||
- Configurable rate limits
|
||||
- Not applicable
|
||||
|
||||
## CI/CD and Automation
|
||||
|
||||
57. **CI/CD for the tool itself:**
|
||||
- GitHub Actions
|
||||
- GitLab CI
|
||||
- CircleCI
|
||||
- Custom
|
||||
- Manual builds
|
||||
|
||||
58. **Release automation:**
|
||||
- Automated releases (tags trigger build)
|
||||
- Manual releases
|
||||
- GoReleaser (for Go projects)
|
||||
- Semantic release
|
||||
|
||||
59. **Pre-commit hooks:**
|
||||
- Linting
|
||||
- Formatting
|
||||
- Security scans
|
||||
- None
|
||||
|
||||
## Community and Ecosystem
|
||||
|
||||
60. **Open source:**
|
||||
- Fully open source
|
||||
- Proprietary
|
||||
- Open core (free + paid features)
|
||||
|
||||
61. **License:**
|
||||
- MIT
|
||||
- Apache 2.0
|
||||
- GPL
|
||||
- Proprietary
|
||||
- Other: **\_\_\_**
|
||||
|
||||
62. **Community support:**
|
||||
- GitHub issues
|
||||
- Slack/Discord community
|
||||
- Forum
|
||||
- Commercial support
|
||||
- Minimal (internal tool)
|
||||
|
||||
63. **Plugin/Extension system:**
|
||||
- Extensible (plugins supported)
|
||||
- Monolithic
|
||||
- Planned for future
|
||||
@@ -1,146 +0,0 @@
|
||||
# Library/SDK Architecture Questions
|
||||
|
||||
## Language and Platform
|
||||
|
||||
1. **Primary language:**
|
||||
- TypeScript/JavaScript
|
||||
- Python
|
||||
- Rust
|
||||
- Go
|
||||
- Java/Kotlin
|
||||
- C#
|
||||
- Other: **\_\_\_**
|
||||
|
||||
2. **Target runtime:**
|
||||
- Node.js
|
||||
- Browser (frontend)
|
||||
- Both Node.js + Browser (isomorphic)
|
||||
- Deno
|
||||
- Bun
|
||||
- Python runtime
|
||||
- Other: **\_\_\_**
|
||||
|
||||
3. **Package registry:**
|
||||
- npm (JavaScript)
|
||||
- PyPI (Python)
|
||||
- crates.io (Rust)
|
||||
- Maven Central (Java)
|
||||
- NuGet (.NET)
|
||||
- Go modules
|
||||
- Other: **\_\_\_**
|
||||
|
||||
## API Design
|
||||
|
||||
4. **Public API style:**
|
||||
- Functional (pure functions)
|
||||
- OOP (classes/instances)
|
||||
- Fluent/Builder pattern
|
||||
- Mix
|
||||
|
||||
5. **API surface size:**
|
||||
- Minimal (focused, single purpose)
|
||||
- Comprehensive (many features)
|
||||
|
||||
6. **Async handling:**
|
||||
- Promises (async/await)
|
||||
- Callbacks
|
||||
- Observables (RxJS)
|
||||
- Synchronous only
|
||||
- Mix
|
||||
|
||||
## Type Safety
|
||||
|
||||
7. **Type system:**
|
||||
- TypeScript (JavaScript)
|
||||
- Type hints (Python)
|
||||
- Strongly typed (Rust, Go, Java)
|
||||
- Runtime validation (Zod, Yup)
|
||||
- None (JavaScript)
|
||||
|
||||
8. **Type definitions:**
|
||||
- Bundled with package
|
||||
- @types package (DefinitelyTyped)
|
||||
- Not applicable
|
||||
|
||||
## Build and Distribution
|
||||
|
||||
9. **Build tool:**
|
||||
- tsup (TypeScript, simple)
|
||||
- esbuild (fast)
|
||||
- Rollup
|
||||
- Webpack
|
||||
- Vite
|
||||
- tsc (TypeScript compiler only)
|
||||
- Not needed (pure JS)
|
||||
|
||||
10. **Output format:**
|
||||
- ESM (modern)
|
||||
- CommonJS (Node.js)
|
||||
- UMD (universal)
|
||||
- Multiple formats
|
||||
|
||||
11. **Minification:**
|
||||
- Yes (production bundle)
|
||||
- No (source code)
|
||||
- Source + minified both
|
||||
|
||||
## Dependencies
|
||||
|
||||
12. **Dependency strategy:**
|
||||
- Zero dependencies (standalone)
|
||||
- Minimal dependencies
|
||||
- Standard dependencies OK
|
||||
|
||||
13. **Peer dependencies:**
|
||||
- Yes (e.g., React library requires React)
|
||||
- No
|
||||
|
||||
## Documentation
|
||||
|
||||
14. **Documentation approach:**
|
||||
- README only
|
||||
- API docs (JSDoc, TypeDoc)
|
||||
- Full docs site (VitePress, Docusaurus)
|
||||
- Examples repo
|
||||
- All of the above
|
||||
|
||||
## Testing
|
||||
|
||||
15. **Test framework:**
|
||||
- Jest (JavaScript)
|
||||
- Vitest (Vite-compatible)
|
||||
- Pytest (Python)
|
||||
- Cargo test (Rust)
|
||||
- Go test
|
||||
- Other: **\_\_\_**
|
||||
|
||||
16. **Test coverage goal:**
|
||||
- High (80%+)
|
||||
- Moderate (50-80%)
|
||||
- Critical paths only
|
||||
|
||||
## Versioning and Releases
|
||||
|
||||
17. **Versioning:**
|
||||
- Semantic versioning (semver)
|
||||
- Calendar versioning (calver)
|
||||
- Other
|
||||
|
||||
18. **Release automation:**
|
||||
- Changesets
|
||||
- Semantic Release
|
||||
- Manual
|
||||
- GitHub Releases
|
||||
- Other: **\_\_\_**
|
||||
|
||||
## Additional
|
||||
|
||||
19. **CLI included:** (if applicable)
|
||||
- Yes (command-line tool)
|
||||
- No (library only)
|
||||
|
||||
20. **Configuration:**
|
||||
- Config file (JSON, YAML)
|
||||
- Programmatic only
|
||||
- Both
|
||||
- None needed
|
||||
@@ -1,110 +0,0 @@
|
||||
# Mobile Project Architecture Questions
|
||||
|
||||
## Platform
|
||||
|
||||
1. **Target platforms:**
|
||||
- iOS only
|
||||
- Android only
|
||||
- Both iOS + Android
|
||||
|
||||
2. **Framework choice:**
|
||||
- React Native (JavaScript/TypeScript, large ecosystem)
|
||||
- Flutter (Dart, high performance, beautiful UI)
|
||||
- Native (Swift for iOS, Kotlin for Android)
|
||||
- Expo (React Native with managed workflow)
|
||||
- Other: **\_\_\_**
|
||||
|
||||
3. **If React Native - workflow:**
|
||||
- Expo (managed, easier, some limitations)
|
||||
- React Native CLI (bare workflow, full control)
|
||||
|
||||
## Backend and Data
|
||||
|
||||
4. **Backend approach:**
|
||||
- Firebase (BaaS, real-time, easy)
|
||||
- Supabase (BaaS, PostgreSQL, open-source)
|
||||
- Custom API (REST/GraphQL)
|
||||
- AWS Amplify
|
||||
- Other BaaS: **\_\_\_**
|
||||
|
||||
5. **Local data persistence:**
|
||||
- AsyncStorage (simple key-value)
|
||||
- SQLite (relational, offline-first)
|
||||
- Realm (NoSQL, sync)
|
||||
- WatermelonDB (reactive, performance)
|
||||
- MMKV (fast key-value)
|
||||
|
||||
6. **State management:**
|
||||
- Redux Toolkit
|
||||
- Zustand
|
||||
- MobX
|
||||
- Context API + useReducer
|
||||
- Jotai/Recoil
|
||||
- React Query (server state)
|
||||
|
||||
## Navigation
|
||||
|
||||
7. **Navigation library:**
|
||||
- React Navigation (standard for RN)
|
||||
- Expo Router (file-based)
|
||||
- React Native Navigation (native navigation)
|
||||
|
||||
## Authentication
|
||||
|
||||
8. **Auth approach:**
|
||||
- Firebase Auth
|
||||
- Supabase Auth
|
||||
- Auth0
|
||||
- Social auth (Google, Apple, Facebook)
|
||||
- Custom
|
||||
- None
|
||||
|
||||
## Push Notifications
|
||||
|
||||
9. **Push notifications:** (if needed)
|
||||
- Firebase Cloud Messaging
|
||||
- Expo Notifications
|
||||
- OneSignal
|
||||
- AWS SNS
|
||||
- None needed
|
||||
|
||||
## Payments (if applicable)
|
||||
|
||||
10. **In-app purchases:**
|
||||
- RevenueCat (cross-platform, subscriptions)
|
||||
- expo-in-app-purchases
|
||||
- react-native-iap
|
||||
- Stripe (external payments)
|
||||
- None needed
|
||||
|
||||
## Additional
|
||||
|
||||
11. **Maps integration:** (if needed)
|
||||
- Google Maps
|
||||
- Apple Maps
|
||||
- Mapbox
|
||||
- None needed
|
||||
|
||||
12. **Analytics:**
|
||||
- Firebase Analytics
|
||||
- Amplitude
|
||||
- Mixpanel
|
||||
- PostHog
|
||||
- None needed
|
||||
|
||||
13. **Crash reporting:**
|
||||
- Sentry
|
||||
- Firebase Crashlytics
|
||||
- Bugsnag
|
||||
- None needed
|
||||
|
||||
14. **Offline-first requirement:**
|
||||
- Yes (sync when online)
|
||||
- No (online-only)
|
||||
- Partial (some features offline)
|
||||
|
||||
15. **App distribution:**
|
||||
- App Store + Google Play (public)
|
||||
- TestFlight + Internal Testing (beta)
|
||||
- Enterprise distribution
|
||||
- Expo EAS Build
|
||||
@@ -1,12 +0,0 @@
|
||||
project_type_id,display_name,question_file,description,characteristics,typical_stacks,detection_keywords
|
||||
web,Web Application,web-questions.md,"Web applications with frontend and/or backend components","has_ui,server_side,browser_based","Next.js+Supabase, React+Django, Vue+Rails","website,web app,frontend,backend,browser,responsive,SPA,SSR,API"
|
||||
mobile,Mobile Application,mobile-questions.md,"Native or cross-platform mobile applications for iOS/Android","has_ui,native_app,mobile_platform","React Native+Firebase, Flutter+Supabase","mobile,iOS,Android,app store,react native,flutter,smartphone,tablet"
|
||||
embedded,Embedded System,embedded-questions.md,"Embedded systems, IoT devices, and firmware","hardware,firmware,microcontroller,iot","ESP32+FreeRTOS+MQTT, STM32+Bare Metal","embedded,IoT,microcontroller,firmware,sensor,ESP32,Arduino,hardware,MQTT,real-time"
|
||||
game,Game,game-questions.md,"Video games for PC, console, mobile, or web","has_ui,real_time,game_engine,interactive","Unity+Photon+PlayFab, Godot+Nakama","game,unity,unreal,godot,multiplayer,gameplay,3D,2D,player,level"
|
||||
library,Library/SDK,library-questions.md,"Reusable libraries, SDKs, and packages","no_ui,package,reusable,developer_tool","TypeScript+tsup+npm, Python+pip","library,SDK,package,npm,pip,gem,cargo,reusable,API wrapper,utility"
|
||||
desktop,Desktop Application,desktop-questions.md,"Native desktop applications for Windows/Mac/Linux","has_ui,native_app,cross_platform,installable","Electron+React, Tauri+Svelte, .NET MAUI","desktop,Electron,Tauri,Windows,macOS,Linux,installer,native app,system tray"
|
||||
cli,Command-Line Tool,cli-questions.md,"Command-line tools and terminal applications","no_ui,terminal,executable,developer_tool","Go+cobra, Rust+clap, Python+click","CLI,command line,terminal,bash,shell,tool,utility,script,console"
|
||||
backend,Backend/API Service,backend-questions.md,"Backend services and APIs (no frontend)","no_ui,server_side,api,microservices","Node.js+Express+PostgreSQL, FastAPI+Redis","API,backend,microservice,REST,GraphQL,gRPC,server,service,endpoint,database"
|
||||
data,Data/Analytics/ML,data-questions.md,"Data pipelines, analytics, machine learning projects","data_pipeline,analytics,ml,batch_processing","Airflow+Spark+Snowflake, PyTorch+MLflow","ETL,data pipeline,analytics,machine learning,ML,AI,Spark,Airflow,model,dataset,training"
|
||||
extension,Browser Extension,extension-questions.md,"Browser extensions for Chrome, Firefox, Safari, etc.","has_ui,browser_specific,client_side","React+Manifest V3, Plasmo+TypeScript","browser extension,Chrome extension,Firefox addon,manifest,content script,popup"
|
||||
infra,Infrastructure/DevOps,infra-questions.md,"Infrastructure as Code, K8s operators, CI/CD plugins","automation,infrastructure,devops,tooling","Terraform+AWS, Kubernetes Operator (Go), GitHub Actions","Terraform,Kubernetes,operator,IaC,infrastructure,CI/CD,DevOps,automation,deployment"
|
||||
|
@@ -1,136 +0,0 @@
|
||||
# Web Project Architecture Questions
|
||||
|
||||
## Frontend
|
||||
|
||||
1. **Framework choice:**
|
||||
- Next.js (React, App Router, SSR)
|
||||
- React (SPA, client-only)
|
||||
- Vue 3 + Nuxt
|
||||
- Svelte + SvelteKit
|
||||
- Other: **\_\_\_**
|
||||
|
||||
2. **Styling approach:**
|
||||
- Tailwind CSS (utility-first)
|
||||
- CSS Modules
|
||||
- Styled Components (CSS-in-JS)
|
||||
- Sass/SCSS
|
||||
- Other: **\_\_\_**
|
||||
|
||||
3. **State management:** (if complex client state)
|
||||
- Zustand (lightweight)
|
||||
- Redux Toolkit
|
||||
- Jotai/Recoil (atomic)
|
||||
- Context API only
|
||||
- Server state only (React Query/SWR)
|
||||
|
||||
## Backend
|
||||
|
||||
4. **Backend approach:**
|
||||
- Next.js API Routes (integrated)
|
||||
- Express.js (Node.js)
|
||||
- Nest.js (Node.js, structured)
|
||||
- FastAPI (Python)
|
||||
- Django (Python)
|
||||
- Rails (Ruby)
|
||||
- Other: **\_\_\_**
|
||||
|
||||
5. **API paradigm:**
|
||||
- REST
|
||||
- GraphQL (Apollo, Relay)
|
||||
- tRPC (type-safe)
|
||||
- gRPC
|
||||
- Mix: **\_\_\_**
|
||||
|
||||
## Database
|
||||
|
||||
6. **Primary database:**
|
||||
- PostgreSQL (relational, ACID)
|
||||
- MySQL
|
||||
- MongoDB (document)
|
||||
- Supabase (PostgreSQL + backend services)
|
||||
- Firebase Firestore
|
||||
- Other: **\_\_\_**
|
||||
|
||||
7. **ORM/Query builder:**
|
||||
- Prisma (type-safe, modern)
|
||||
- Drizzle ORM
|
||||
- TypeORM
|
||||
- Sequelize
|
||||
- Mongoose (for MongoDB)
|
||||
- Raw SQL
|
||||
- Database client directly (Supabase SDK)
|
||||
|
||||
## Authentication
|
||||
|
||||
8. **Auth approach:**
|
||||
- Supabase Auth (managed, built-in)
|
||||
- Auth0 (managed, enterprise)
|
||||
- Clerk (managed, developer-friendly)
|
||||
- NextAuth.js (self-hosted)
|
||||
- Firebase Auth
|
||||
- Custom JWT implementation
|
||||
- Passport.js
|
||||
|
||||
## Deployment
|
||||
|
||||
9. **Hosting platform:**
|
||||
- Vercel (optimal for Next.js)
|
||||
- Netlify
|
||||
- AWS (EC2, ECS, Lambda)
|
||||
- Google Cloud
|
||||
- Heroku
|
||||
- Railway
|
||||
- Self-hosted
|
||||
|
||||
10. **CI/CD:**
|
||||
- GitHub Actions
|
||||
- GitLab CI
|
||||
- CircleCI
|
||||
- Vercel/Netlify auto-deploy
|
||||
- Other: **\_\_\_**
|
||||
|
||||
## Additional Services (if applicable)
|
||||
|
||||
11. **Email service:** (if transactional emails needed)
|
||||
- Resend (developer-friendly, modern)
|
||||
- SendGrid
|
||||
- AWS SES
|
||||
- Postmark
|
||||
- None needed
|
||||
|
||||
12. **Payment processing:** (if e-commerce/subscriptions)
|
||||
- Stripe (comprehensive)
|
||||
- Lemon Squeezy (SaaS-focused)
|
||||
- PayPal
|
||||
- Square
|
||||
- None needed
|
||||
|
||||
13. **File storage:** (if user uploads)
|
||||
- Supabase Storage
|
||||
- AWS S3
|
||||
- Cloudflare R2
|
||||
- Vercel Blob
|
||||
- Uploadthing
|
||||
- None needed
|
||||
|
||||
14. **Search:** (if full-text search beyond database)
|
||||
- Elasticsearch
|
||||
- Algolia
|
||||
- Meilisearch
|
||||
- Typesense
|
||||
- Database full-text (PostgreSQL)
|
||||
- None needed
|
||||
|
||||
15. **Caching:** (if performance critical)
|
||||
- Redis (external cache)
|
||||
- In-memory (Node.js cache)
|
||||
- CDN caching (Cloudflare/Vercel)
|
||||
- None needed
|
||||
|
||||
16. **Monitoring/Error Tracking:**
|
||||
- Sentry (error tracking)
|
||||
- PostHog (product analytics)
|
||||
- Datadog
|
||||
- LogRocket
|
||||
- Vercel Analytics
|
||||
- None needed
|
||||
@@ -1,195 +0,0 @@
|
||||
# Technical Specification Workflow
|
||||
|
||||
## Overview
|
||||
|
||||
Generate a comprehensive Technical Specification from PRD and Architecture with acceptance criteria and traceability mapping. Creates detailed implementation guidance that bridges business requirements with technical execution.
|
||||
|
||||
## Key Features
|
||||
|
||||
- **PRD-Architecture Integration** - Synthesizes business requirements with technical constraints
|
||||
- **Traceability Mapping** - Links acceptance criteria to technical components and tests
|
||||
- **Multi-Input Support** - Leverages PRD, architecture, front-end specs, and brownfield notes
|
||||
- **Implementation Focus** - Provides concrete technical guidance for development teams
|
||||
- **Testing Integration** - Includes test strategy aligned with acceptance criteria
|
||||
- **Validation Ready** - Generates specifications suitable for architectural review
|
||||
|
||||
## Usage
|
||||
|
||||
### Basic Invocation
|
||||
|
||||
```bash
|
||||
workflow tech-spec
|
||||
```
|
||||
|
||||
### With Input Documents
|
||||
|
||||
```bash
|
||||
# With specific PRD and architecture
|
||||
workflow tech-spec --input prd.md --input architecture.md
|
||||
|
||||
# With comprehensive inputs
|
||||
workflow tech-spec --input prd.md --input architecture.md --input front-end-spec.md
|
||||
```
|
||||
|
||||
### Configuration
|
||||
|
||||
- **output_folder**: Location for generated technical specification
|
||||
- **epic_id**: Used in output filename (extracted from PRD or prompted)
|
||||
- **recommended_inputs**: PRD, architecture, front-end spec, brownfield notes
|
||||
|
||||
## Workflow Structure
|
||||
|
||||
### Files Included
|
||||
|
||||
```
|
||||
tech-spec/
|
||||
├── workflow.yaml # Configuration and metadata
|
||||
├── instructions.md # Step-by-step execution guide
|
||||
├── template.md # Technical specification structure
|
||||
├── checklist.md # Validation criteria
|
||||
└── README.md # This file
|
||||
```
|
||||
|
||||
## Workflow Process
|
||||
|
||||
### Phase 1: Input Collection and Analysis (Steps 1-2)
|
||||
|
||||
- **Document Discovery**: Locates PRD and Architecture documents
|
||||
- **Epic Extraction**: Identifies epic title and ID from PRD content
|
||||
- **Template Initialization**: Creates tech-spec document from template
|
||||
- **Context Analysis**: Reviews complete PRD and architecture for alignment
|
||||
|
||||
### Phase 2: Technical Design Specification (Step 3)
|
||||
|
||||
- **Service Architecture**: Defines services/modules with responsibilities and interfaces
|
||||
- **Data Modeling**: Specifies entities, schemas, and relationships
|
||||
- **API Design**: Documents endpoints, request/response models, and error handling
|
||||
- **Workflow Definition**: Details sequence flows and data processing patterns
|
||||
|
||||
### Phase 3: Non-Functional Requirements (Step 4)
|
||||
|
||||
- **Performance Specs**: Defines measurable latency, throughput, and scalability targets
|
||||
- **Security Requirements**: Specifies authentication, authorization, and data protection
|
||||
- **Reliability Standards**: Documents availability, recovery, and degradation behavior
|
||||
- **Observability Framework**: Defines logging, metrics, and tracing requirements
|
||||
|
||||
### Phase 4: Dependencies and Integration (Step 5)
|
||||
|
||||
- **Dependency Analysis**: Scans repository for package manifests and frameworks
|
||||
- **Integration Mapping**: Identifies external systems and API dependencies
|
||||
- **Version Management**: Documents version constraints and compatibility requirements
|
||||
- **Infrastructure Needs**: Specifies deployment and runtime dependencies
|
||||
|
||||
### Phase 5: Acceptance and Testing (Step 6)
|
||||
|
||||
- **Criteria Normalization**: Extracts and refines acceptance criteria from PRD
|
||||
- **Traceability Matrix**: Maps acceptance criteria to technical components
|
||||
- **Test Strategy**: Defines testing approach for each acceptance criterion
|
||||
- **Component Mapping**: Links requirements to specific APIs and modules
|
||||
|
||||
### Phase 6: Risk and Validation (Steps 7-8)
|
||||
|
||||
- **Risk Assessment**: Identifies technical risks, assumptions, and open questions
|
||||
- **Mitigation Planning**: Provides strategies for addressing identified risks
|
||||
- **Quality Validation**: Ensures specification meets completeness criteria
|
||||
- **Checklist Verification**: Validates against workflow quality standards
|
||||
|
||||
## Output
|
||||
|
||||
### Generated Files
|
||||
|
||||
- **Primary output**: tech-spec-{epic_id}-{date}.md
|
||||
- **Traceability data**: Embedded mapping tables linking requirements to implementation
|
||||
|
||||
### Output Structure
|
||||
|
||||
1. **Overview and Scope** - Project context and boundaries
|
||||
2. **System Architecture Alignment** - Connection to high-level architecture
|
||||
3. **Detailed Design** - Services, data models, APIs, and workflows
|
||||
4. **Non-Functional Requirements** - Performance, security, reliability, observability
|
||||
5. **Dependencies and Integrations** - External systems and technical dependencies
|
||||
6. **Acceptance Criteria** - Testable requirements from PRD
|
||||
7. **Traceability Mapping** - Requirements-to-implementation mapping
|
||||
8. **Test Strategy** - Testing approach and framework alignment
|
||||
9. **Risks and Assumptions** - Technical risks and mitigation strategies
|
||||
|
||||
## Requirements
|
||||
|
||||
- **PRD Document**: Product Requirements Document with clear acceptance criteria
|
||||
- **Architecture Document**: High-level architecture or technical design
|
||||
- **Repository Access**: For dependency analysis and framework detection
|
||||
- **Epic Context**: Clear epic identification and scope definition
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Before Starting
|
||||
|
||||
1. **Validate Inputs**: Ensure PRD and architecture documents are complete and current
|
||||
2. **Review Requirements**: Confirm acceptance criteria are specific and testable
|
||||
3. **Check Dependencies**: Verify repository structure supports automated dependency analysis
|
||||
|
||||
### During Execution
|
||||
|
||||
1. **Maintain Traceability**: Ensure every acceptance criterion maps to implementation
|
||||
2. **Be Implementation-Specific**: Provide concrete technical guidance, not high-level concepts
|
||||
3. **Consider Constraints**: Factor in existing system limitations and brownfield challenges
|
||||
|
||||
### After Completion
|
||||
|
||||
1. **Architect Review**: Have technical lead validate design decisions
|
||||
2. **Developer Walkthrough**: Ensure implementation team understands specifications
|
||||
3. **Test Planning**: Use traceability matrix for test case development
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
**Issue**: Missing or incomplete technical details
|
||||
|
||||
- **Solution**: Review architecture document for implementation specifics
|
||||
- **Check**: Ensure PRD contains sufficient functional requirements detail
|
||||
|
||||
**Issue**: Acceptance criteria don't map cleanly to technical components
|
||||
|
||||
- **Solution**: Break down complex criteria into atomic, testable statements
|
||||
- **Check**: Verify PRD acceptance criteria are properly structured
|
||||
|
||||
**Issue**: Dependency analysis fails or is incomplete
|
||||
|
||||
- **Solution**: Check repository structure and manifest file locations
|
||||
- **Check**: Verify repository contains standard dependency files (package.json, etc.)
|
||||
|
||||
**Issue**: Non-functional requirements are too vague
|
||||
|
||||
- **Solution**: Extract specific performance and quality targets from architecture
|
||||
- **Check**: Ensure architecture document contains measurable NFR specifications
|
||||
|
||||
## Customization
|
||||
|
||||
To customize this workflow:
|
||||
|
||||
1. **Modify Template**: Update template.md to match organizational technical spec standards
|
||||
2. **Extend Dependencies**: Add support for additional package managers or frameworks
|
||||
3. **Enhance Validation**: Extend checklist.md with company-specific technical criteria
|
||||
4. **Add Sections**: Include additional technical concerns like DevOps or monitoring
|
||||
|
||||
## Version History
|
||||
|
||||
- **v6.0.0** - Comprehensive technical specification with traceability
|
||||
- PRD-Architecture integration
|
||||
- Automated dependency detection
|
||||
- Traceability mapping
|
||||
- Test strategy alignment
|
||||
|
||||
## Support
|
||||
|
||||
For issues or questions:
|
||||
|
||||
- Review the workflow creation guide at `/bmad/bmb/workflows/create-workflow/workflow-creation-guide.md`
|
||||
- Validate output using `checklist.md`
|
||||
- Ensure PRD and architecture documents are complete before starting
|
||||
- Consult BMAD documentation for technical specification standards
|
||||
|
||||
---
|
||||
|
||||
_Part of the BMad Method v6 - BMM (Method) Module_
|
||||
@@ -1,17 +0,0 @@
|
||||
# Tech Spec Validation Checklist
|
||||
|
||||
```xml
|
||||
<checklist id="bmad/bmm/workflows/3-solutioning/tech-spec/checklist">
|
||||
<item>Overview clearly ties to PRD goals</item>
|
||||
<item>Scope explicitly lists in-scope and out-of-scope</item>
|
||||
<item>Design lists all services/modules with responsibilities</item>
|
||||
<item>Data models include entities, fields, and relationships</item>
|
||||
<item>APIs/interfaces are specified with methods and schemas</item>
|
||||
<item>NFRs: performance, security, reliability, observability addressed</item>
|
||||
<item>Dependencies/integrations enumerated with versions where known</item>
|
||||
<item>Acceptance criteria are atomic and testable</item>
|
||||
<item>Traceability maps AC → Spec → Components → Tests</item>
|
||||
<item>Risks/assumptions/questions listed with mitigation/next steps</item>
|
||||
<item>Test strategy covers all ACs and critical paths</item>
|
||||
</checklist>
|
||||
```
|
||||
@@ -1,73 +0,0 @@
|
||||
<!-- BMAD BMM Tech Spec Workflow Instructions (v6) -->
|
||||
|
||||
```xml
|
||||
<critical>The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.md</critical>
|
||||
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
|
||||
<critical>This workflow generates a comprehensive Technical Specification from PRD and Architecture, including detailed design, NFRs, acceptance criteria, and traceability mapping.</critical>
|
||||
<critical>Default execution mode: #yolo (non-interactive). If required inputs cannot be auto-discovered and {{non_interactive}} == true, HALT with a clear message listing missing documents; do not prompt.</critical>
|
||||
|
||||
<workflow>
|
||||
<step n="1" goal="Collect inputs and initialize">
|
||||
<action>Identify PRD and Architecture documents from recommended_inputs. Attempt to auto-discover at default paths.</action>
|
||||
<ask optional="true" if="{{non_interactive}} == false">If inputs are missing, ask the user for file paths.</ask>
|
||||
<check>If inputs are missing and {{non_interactive}} == true → HALT with a clear message listing missing documents.</check>
|
||||
<action>Extract {{epic_title}} and {{epic_id}} from PRD (or ASK if not present).</action>
|
||||
<action>Resolve output file path using workflow variables and initialize by writing the template.</action>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Overview and scope">
|
||||
<action>Read COMPLETE PRD and Architecture files.</action>
|
||||
<template-output file="{default_output_file}">
|
||||
Replace {{overview}} with a concise 1-2 paragraph summary referencing PRD context and goals
|
||||
Replace {{objectives_scope}} with explicit in-scope and out-of-scope bullets
|
||||
Replace {{system_arch_alignment}} with a short alignment summary to the architecture (components referenced, constraints)
|
||||
</template-output>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Detailed design">
|
||||
<action>Derive concrete implementation specifics from Architecture and PRD (NO invention).</action>
|
||||
<template-output file="{default_output_file}">
|
||||
Replace {{services_modules}} with a table or bullets listing services/modules with responsibilities, inputs/outputs, and owners
|
||||
Replace {{data_models}} with normalized data model definitions (entities, fields, types, relationships); include schema snippets where available
|
||||
Replace {{apis_interfaces}} with API endpoint specs or interface signatures (method, path, request/response models, error codes)
|
||||
Replace {{workflows_sequencing}} with sequence notes or diagrams-as-text (steps, actors, data flow)
|
||||
</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Non-functional requirements">
|
||||
<template-output file="{default_output_file}">
|
||||
Replace {{nfr_performance}} with measurable targets (latency, throughput); link to any performance requirements in PRD/Architecture
|
||||
Replace {{nfr_security}} with authn/z requirements, data handling, threat notes; cite source sections
|
||||
Replace {{nfr_reliability}} with availability, recovery, and degradation behavior
|
||||
Replace {{nfr_observability}} with logging, metrics, tracing requirements; name required signals
|
||||
</template-output>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Dependencies and integrations">
|
||||
<action>Scan repository for dependency manifests (e.g., package.json, pyproject.toml, go.mod, Unity Packages/manifest.json).</action>
|
||||
<template-output file="{default_output_file}">
|
||||
Replace {{dependencies_integrations}} with a structured list of dependencies and integration points with version or commit constraints when known
|
||||
</template-output>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Acceptance criteria and traceability">
|
||||
<action>Extract acceptance criteria from PRD; normalize into atomic, testable statements.</action>
|
||||
<template-output file="{default_output_file}">
|
||||
Replace {{acceptance_criteria}} with a numbered list of testable acceptance criteria
|
||||
Replace {{traceability_mapping}} with a table mapping: AC → Spec Section(s) → Component(s)/API(s) → Test Idea
|
||||
</template-output>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Risks and test strategy">
|
||||
<template-output file="{default_output_file}">
|
||||
Replace {{risks_assumptions_questions}} with explicit list (each item labeled as Risk/Assumption/Question) with mitigation or next step
|
||||
Replace {{test_strategy}} with a brief plan (test levels, frameworks, coverage of ACs, edge cases)
|
||||
</template-output>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Validate">
|
||||
<invoke-task>Validate against checklist at {installed_path}/checklist.md using bmad/core/tasks/validate-workflow.md</invoke-task>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
```
|
||||
@@ -1,76 +0,0 @@
|
||||
# Technical Specification: {{epic_title}}
|
||||
|
||||
Date: {{date}}
|
||||
Author: {{user_name}}
|
||||
Epic ID: {{epic_id}}
|
||||
Status: Draft
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
{{overview}}
|
||||
|
||||
## Objectives and Scope
|
||||
|
||||
{{objectives_scope}}
|
||||
|
||||
## System Architecture Alignment
|
||||
|
||||
{{system_arch_alignment}}
|
||||
|
||||
## Detailed Design
|
||||
|
||||
### Services and Modules
|
||||
|
||||
{{services_modules}}
|
||||
|
||||
### Data Models and Contracts
|
||||
|
||||
{{data_models}}
|
||||
|
||||
### APIs and Interfaces
|
||||
|
||||
{{apis_interfaces}}
|
||||
|
||||
### Workflows and Sequencing
|
||||
|
||||
{{workflows_sequencing}}
|
||||
|
||||
## Non-Functional Requirements
|
||||
|
||||
### Performance
|
||||
|
||||
{{nfr_performance}}
|
||||
|
||||
### Security
|
||||
|
||||
{{nfr_security}}
|
||||
|
||||
### Reliability/Availability
|
||||
|
||||
{{nfr_reliability}}
|
||||
|
||||
### Observability
|
||||
|
||||
{{nfr_observability}}
|
||||
|
||||
## Dependencies and Integrations
|
||||
|
||||
{{dependencies_integrations}}
|
||||
|
||||
## Acceptance Criteria (Authoritative)
|
||||
|
||||
{{acceptance_criteria}}
|
||||
|
||||
## Traceability Mapping
|
||||
|
||||
{{traceability_mapping}}
|
||||
|
||||
## Risks, Assumptions, Open Questions
|
||||
|
||||
{{risks_assumptions_questions}}
|
||||
|
||||
## Test Strategy Summary
|
||||
|
||||
{{test_strategy}}
|
||||
@@ -1,51 +0,0 @@
|
||||
name: tech-spec
|
||||
description: "Generate a comprehensive Technical Specification from PRD and Architecture with acceptance criteria and traceability mapping"
|
||||
author: "BMAD BMM"
|
||||
|
||||
# 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"
|
||||
date: system-generated
|
||||
|
||||
# Inputs expected (ask user if missing)
|
||||
recommended_inputs:
|
||||
- prd: "{project-root}/docs/prd.md"
|
||||
- architecture: "{project-root}/docs/architecture.md"
|
||||
- frontend_spec: "{project-root}/docs/front-end-spec.md"
|
||||
- brownfield_notes: "{project-root}/docs/brownfield-notes.md"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/bmad/bmm/workflows/3-solutioning/tech-spec"
|
||||
template: "{installed_path}/template.md"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
validation: "{installed_path}/checklist.md"
|
||||
|
||||
# Output configuration
|
||||
default_output_file: "{project-root}/docs/tech-spec-epic-{{epic_id}}.md"
|
||||
|
||||
# Required tools
|
||||
required_tools:
|
||||
- list_files
|
||||
- file_info
|
||||
- read_file
|
||||
- write_file
|
||||
- search_repo
|
||||
- glob
|
||||
- parse_markdown
|
||||
|
||||
tags:
|
||||
- tech-spec
|
||||
- architecture
|
||||
- planning
|
||||
- bmad-v6
|
||||
|
||||
execution_hints:
|
||||
interactive: false
|
||||
autonomous: true
|
||||
iterative: true
|
||||
|
||||
# Variables
|
||||
variables:
|
||||
non_interactive: true
|
||||
@@ -1,66 +0,0 @@
|
||||
# {{TITLE}} Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
{{technology_table}}
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
{{architecture_overview}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
{{data_architecture}}
|
||||
|
||||
## 4. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 5. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
## 6. Implementation Guidance
|
||||
|
||||
{{implementation_guidance}}
|
||||
|
||||
## 7. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## 8. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 9. Deployment and Operations
|
||||
|
||||
{{deployment_operations}}
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 10. Security
|
||||
|
||||
{{security}}
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -1,66 +0,0 @@
|
||||
# {{TITLE}} Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
{{technology_table}}
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
{{architecture_overview}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
{{data_architecture}}
|
||||
|
||||
## 4. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 5. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
## 6. Implementation Guidance
|
||||
|
||||
{{implementation_guidance}}
|
||||
|
||||
## 7. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## 8. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 9. Deployment and Operations
|
||||
|
||||
{{deployment_operations}}
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 10. Security
|
||||
|
||||
{{security}}
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -1,66 +0,0 @@
|
||||
# {{TITLE}} Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
{{technology_table}}
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
{{architecture_overview}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
{{data_architecture}}
|
||||
|
||||
## 4. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 5. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
## 6. Implementation Guidance
|
||||
|
||||
{{implementation_guidance}}
|
||||
|
||||
## 7. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## 8. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 9. Deployment and Operations
|
||||
|
||||
{{deployment_operations}}
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 10. Security
|
||||
|
||||
{{security}}
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -1,66 +0,0 @@
|
||||
# {{TITLE}} Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
{{technology_table}}
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
{{architecture_overview}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
{{data_architecture}}
|
||||
|
||||
## 4. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 5. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
## 6. Implementation Guidance
|
||||
|
||||
{{implementation_guidance}}
|
||||
|
||||
## 7. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## 8. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 9. Deployment and Operations
|
||||
|
||||
{{deployment_operations}}
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 10. Security
|
||||
|
||||
{{security}}
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -1,66 +0,0 @@
|
||||
# {{TITLE}} Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
{{technology_table}}
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
{{architecture_overview}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
{{data_architecture}}
|
||||
|
||||
## 4. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 5. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
## 6. Implementation Guidance
|
||||
|
||||
{{implementation_guidance}}
|
||||
|
||||
## 7. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## 8. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 9. Deployment and Operations
|
||||
|
||||
{{deployment_operations}}
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 10. Security
|
||||
|
||||
{{security}}
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -1,244 +0,0 @@
|
||||
# Game Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
| Category | Technology | Version | Justification |
|
||||
| ------------------ | ---------------------- | ---------------------- | ---------------------------- |
|
||||
| Game Engine | {{game_engine}} | {{engine_version}} | {{engine_justification}} |
|
||||
| Language | {{language}} | {{language_version}} | {{language_justification}} |
|
||||
| Rendering Pipeline | {{rendering_pipeline}} | {{rendering_version}} | {{rendering_justification}} |
|
||||
| Physics Engine | {{physics}} | {{physics_version}} | {{physics_justification}} |
|
||||
| Audio Middleware | {{audio}} | {{audio_version}} | {{audio_justification}} |
|
||||
| Networking | {{networking}} | {{networking_version}} | {{networking_justification}} |
|
||||
| Backend Services | {{backend}} | {{backend_version}} | {{backend_justification}} |
|
||||
| Analytics | {{analytics}} | {{analytics_version}} | {{analytics_justification}} |
|
||||
|
||||
{{additional_tech_stack_rows}}
|
||||
|
||||
## 2. Engine and Platform
|
||||
|
||||
### 2.1 Game Engine Choice
|
||||
|
||||
{{engine_choice}}
|
||||
|
||||
### 2.2 Target Platforms
|
||||
|
||||
{{target_platforms}}
|
||||
|
||||
### 2.3 Rendering Pipeline
|
||||
|
||||
{{rendering_pipeline_details}}
|
||||
|
||||
## 3. Game Architecture
|
||||
|
||||
### 3.1 Architecture Pattern
|
||||
|
||||
{{architecture_pattern}}
|
||||
|
||||
### 3.2 Scene Structure
|
||||
|
||||
{{scene_structure}}
|
||||
|
||||
### 3.3 Game Loop
|
||||
|
||||
{{game_loop}}
|
||||
|
||||
### 3.4 State Machine
|
||||
|
||||
{{state_machine}}
|
||||
|
||||
## 4. Scene and Level Architecture
|
||||
|
||||
### 4.1 Scene Organization
|
||||
|
||||
{{scene_organization}}
|
||||
|
||||
### 4.2 Level Streaming
|
||||
|
||||
{{level_streaming}}
|
||||
|
||||
### 4.3 Additive Loading
|
||||
|
||||
{{additive_loading}}
|
||||
|
||||
### 4.4 Memory Management
|
||||
|
||||
{{memory_management}}
|
||||
|
||||
## 5. Gameplay Systems
|
||||
|
||||
### 5.1 Player Controller
|
||||
|
||||
{{player_controller}}
|
||||
|
||||
### 5.2 Game State Management
|
||||
|
||||
{{game_state}}
|
||||
|
||||
### 5.3 Inventory System
|
||||
|
||||
{{inventory}}
|
||||
|
||||
### 5.4 Progression System
|
||||
|
||||
{{progression}}
|
||||
|
||||
### 5.5 Combat/Core Mechanics
|
||||
|
||||
{{core_mechanics}}
|
||||
|
||||
## 6. Rendering Architecture
|
||||
|
||||
### 6.1 Rendering Pipeline
|
||||
|
||||
{{rendering_pipeline_architecture}}
|
||||
|
||||
### 6.2 Shaders
|
||||
|
||||
{{shaders}}
|
||||
|
||||
### 6.3 Post-Processing
|
||||
|
||||
{{post_processing}}
|
||||
|
||||
### 6.4 LOD System
|
||||
|
||||
{{lod_system}}
|
||||
|
||||
### 6.5 Occlusion Culling
|
||||
|
||||
{{occlusion}}
|
||||
|
||||
## 7. Asset Pipeline
|
||||
|
||||
### 7.1 Model Import
|
||||
|
||||
{{model_import}}
|
||||
|
||||
### 7.2 Textures and Materials
|
||||
|
||||
{{textures_materials}}
|
||||
|
||||
### 7.3 Asset Bundles/Addressables
|
||||
|
||||
{{asset_bundles}}
|
||||
|
||||
### 7.4 Asset Optimization
|
||||
|
||||
{{asset_optimization}}
|
||||
|
||||
## 8. Animation System
|
||||
|
||||
{{animation_system}}
|
||||
|
||||
## 9. Physics and Collision
|
||||
|
||||
{{physics_collision}}
|
||||
|
||||
## 10. Multiplayer Architecture
|
||||
|
||||
{{multiplayer_section}}
|
||||
|
||||
**Note:** {{multiplayer_note}}
|
||||
|
||||
## 11. Backend Services
|
||||
|
||||
{{backend_services}}
|
||||
|
||||
**Note:** {{backend_note}}
|
||||
|
||||
## 12. Save System
|
||||
|
||||
{{save_system}}
|
||||
|
||||
## 13. UI/UX Architecture
|
||||
|
||||
{{ui_architecture}}
|
||||
|
||||
## 14. Audio Architecture
|
||||
|
||||
{{audio_architecture}}
|
||||
|
||||
{{audio_specialist_section}}
|
||||
|
||||
## 15. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 16. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
**Key decisions:**
|
||||
|
||||
- Why this engine? {{engine_decision}}
|
||||
- ECS vs OOP? {{ecs_vs_oop_decision}}
|
||||
- Multiplayer approach? {{multiplayer_decision}}
|
||||
- Asset streaming? {{asset_streaming_decision}}
|
||||
|
||||
## 17. Implementation Guidance
|
||||
|
||||
### 17.1 Prefab/Blueprint Conventions
|
||||
|
||||
{{prefab_conventions}}
|
||||
|
||||
### 17.2 Coding Patterns
|
||||
|
||||
{{coding_patterns}}
|
||||
|
||||
### 17.3 Performance Guidelines
|
||||
|
||||
{{performance_guidelines}}
|
||||
|
||||
## 18. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
**Critical folders:**
|
||||
|
||||
- {{critical_folder_1}}: {{critical_folder_1_description}}
|
||||
- {{critical_folder_2}}: {{critical_folder_2_description}}
|
||||
- {{critical_folder_3}}: {{critical_folder_3_description}}
|
||||
|
||||
## 19. Performance and Optimization
|
||||
|
||||
{{performance_optimization}}
|
||||
|
||||
{{performance_specialist_section}}
|
||||
|
||||
## 20. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
|
||||
## 21. Build and Distribution
|
||||
|
||||
{{build_distribution}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
### Recommended Specialists:
|
||||
|
||||
- {{audio_specialist_recommendation}}
|
||||
- {{performance_specialist_recommendation}}
|
||||
- {{multiplayer_specialist_recommendation}}
|
||||
- {{monetization_specialist_recommendation}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -1,428 +0,0 @@
|
||||
# Godot Game Engine Architecture Guide
|
||||
|
||||
This guide provides Godot-specific guidance for solution architecture generation.
|
||||
|
||||
---
|
||||
|
||||
## Godot-Specific Questions
|
||||
|
||||
### 1. Godot Version and Language Strategy
|
||||
|
||||
**Ask:**
|
||||
|
||||
- Which Godot version? (3.x, 4.x)
|
||||
- Language preference? (GDScript only, C# only, or Mixed GDScript+C#)
|
||||
- Target platform(s)? (PC, Mobile, Web, Console)
|
||||
|
||||
**Guidance:**
|
||||
|
||||
- **Godot 4.x**: Modern, Vulkan renderer, better 3D, C# improving
|
||||
- **Godot 3.x**: Stable, mature ecosystem, OpenGL
|
||||
- **GDScript**: Python-like, fast iteration, integrated with editor
|
||||
- **C#**: Better performance for complex systems, familiar to Unity devs
|
||||
- **Mixed**: GDScript for game logic, C# for performance-critical (physics, AI)
|
||||
|
||||
**Record ADR:** Godot version and language strategy
|
||||
|
||||
---
|
||||
|
||||
### 2. Node-Based Architecture
|
||||
|
||||
**Ask:**
|
||||
|
||||
- Scene composition strategy? (Nested scenes, scene inheritance, or flat hierarchy)
|
||||
- Node organization patterns? (By feature, by type, or hybrid)
|
||||
|
||||
**Guidance:**
|
||||
|
||||
- **Scenes as Prefabs**: Each reusable entity is a scene (Player.tscn, Enemy.tscn)
|
||||
- **Scene Inheritance**: Extend base scenes for variations (BaseEnemy → FlyingEnemy)
|
||||
- **Node Signals**: Use built-in signal system for decoupled communication
|
||||
- **Autoload Singletons**: For global managers (GameManager, AudioManager)
|
||||
|
||||
**Godot Pattern:**
|
||||
|
||||
```gdscript
|
||||
# Player.gd
|
||||
extends CharacterBody2D
|
||||
|
||||
signal health_changed(new_health)
|
||||
signal died
|
||||
|
||||
@export var max_health: int = 100
|
||||
var health: int = max_health
|
||||
|
||||
func take_damage(amount: int) -> void:
|
||||
health -= amount
|
||||
health_changed.emit(health)
|
||||
if health <= 0:
|
||||
died.emit()
|
||||
queue_free()
|
||||
```
|
||||
|
||||
**Record ADR:** Scene architecture and node organization
|
||||
|
||||
---
|
||||
|
||||
### 3. Resource Management
|
||||
|
||||
**Ask:**
|
||||
|
||||
- Use Godot Resources for data? (Custom Resource types for game data)
|
||||
- Asset loading strategy? (preload vs load vs ResourceLoader)
|
||||
|
||||
**Guidance:**
|
||||
|
||||
- **Resources**: Like Unity ScriptableObjects, serializable data containers
|
||||
- **preload()**: Load at compile time (fast, but increases binary size)
|
||||
- **load()**: Load at runtime (slower, but smaller binary)
|
||||
- **ResourceLoader.load_threaded_request()**: Async loading for large assets
|
||||
|
||||
**Pattern:**
|
||||
|
||||
```gdscript
|
||||
# EnemyData.gd
|
||||
class_name EnemyData
|
||||
extends Resource
|
||||
|
||||
@export var enemy_name: String
|
||||
@export var health: int
|
||||
@export var speed: float
|
||||
@export var prefab_scene: PackedScene
|
||||
```
|
||||
|
||||
**Record ADR:** Resource and asset loading strategy
|
||||
|
||||
---
|
||||
|
||||
## Godot-Specific Architecture Sections
|
||||
|
||||
### Signal-Driven Communication
|
||||
|
||||
**Godot's built-in Observer pattern:**
|
||||
|
||||
```gdscript
|
||||
# GameManager.gd (Autoload singleton)
|
||||
extends Node
|
||||
|
||||
signal game_started
|
||||
signal game_paused
|
||||
signal game_over(final_score: int)
|
||||
|
||||
func start_game() -> void:
|
||||
game_started.emit()
|
||||
|
||||
func pause_game() -> void:
|
||||
get_tree().paused = true
|
||||
game_paused.emit()
|
||||
|
||||
# In Player.gd
|
||||
func _ready() -> void:
|
||||
GameManager.game_started.connect(_on_game_started)
|
||||
GameManager.game_over.connect(_on_game_over)
|
||||
|
||||
func _on_game_started() -> void:
|
||||
position = Vector2.ZERO
|
||||
health = max_health
|
||||
```
|
||||
|
||||
**Benefits:**
|
||||
|
||||
- Decoupled systems
|
||||
- No FindNode or get_node everywhere
|
||||
- Type-safe with typed signals (Godot 4)
|
||||
|
||||
---
|
||||
|
||||
### Godot Scene Architecture
|
||||
|
||||
**Scene organization patterns:**
|
||||
|
||||
**1. Composition Pattern:**
|
||||
|
||||
```
|
||||
Player (CharacterBody2D)
|
||||
├── Sprite2D
|
||||
├── CollisionShape2D
|
||||
├── AnimationPlayer
|
||||
├── HealthComponent (Node - custom script)
|
||||
├── InputComponent (Node - custom script)
|
||||
└── WeaponMount (Node2D)
|
||||
└── Weapon (instanced scene)
|
||||
```
|
||||
|
||||
**2. Scene Inheritance:**
|
||||
|
||||
```
|
||||
BaseEnemy.tscn
|
||||
├── Inherits → FlyingEnemy.tscn (adds wings, aerial movement)
|
||||
└── Inherits → GroundEnemy.tscn (adds ground collision)
|
||||
```
|
||||
|
||||
**3. Autoload Singletons:**
|
||||
|
||||
```
|
||||
# In Project Settings > Autoload:
|
||||
GameManager → res://scripts/managers/game_manager.gd
|
||||
AudioManager → res://scripts/managers/audio_manager.gd
|
||||
SaveManager → res://scripts/managers/save_manager.gd
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Performance Optimization
|
||||
|
||||
**Godot-specific considerations:**
|
||||
|
||||
- **Static Typing**: Use type hints for GDScript performance (`var health: int = 100`)
|
||||
- **Object Pooling**: Implement manually or use addons
|
||||
- **CanvasItem batching**: Reduce draw calls with texture atlases
|
||||
- **Viewport rendering**: Offload effects to separate viewports
|
||||
- **GDScript vs C#**: C# faster for heavy computation, GDScript faster for simple logic
|
||||
|
||||
**Target Performance:**
|
||||
|
||||
- **PC**: 60 FPS minimum
|
||||
- **Mobile**: 60 FPS (high-end), 30 FPS (low-end)
|
||||
- **Web**: 30-60 FPS depending on complexity
|
||||
|
||||
**Profiler:**
|
||||
|
||||
- Use Godot's built-in profiler (Debug > Profiler)
|
||||
- Monitor FPS, draw calls, physics time
|
||||
|
||||
---
|
||||
|
||||
### Testing Strategy
|
||||
|
||||
**GUT (Godot Unit Test):**
|
||||
|
||||
```gdscript
|
||||
# test_player.gd
|
||||
extends GutTest
|
||||
|
||||
func test_player_takes_damage():
|
||||
var player = Player.new()
|
||||
add_child(player)
|
||||
player.health = 100
|
||||
|
||||
player.take_damage(20)
|
||||
|
||||
assert_eq(player.health, 80, "Player health should decrease")
|
||||
```
|
||||
|
||||
**GoDotTest for C#:**
|
||||
|
||||
```csharp
|
||||
[Test]
|
||||
public void PlayerTakesDamage_DecreasesHealth()
|
||||
{
|
||||
var player = new Player();
|
||||
player.Health = 100;
|
||||
|
||||
player.TakeDamage(20);
|
||||
|
||||
Assert.That(player.Health, Is.EqualTo(80));
|
||||
}
|
||||
```
|
||||
|
||||
**Recommended Coverage:**
|
||||
|
||||
- 80% minimum test coverage (from expansion pack)
|
||||
- Test game systems, not rendering
|
||||
- Use GUT for GDScript, GoDotTest for C#
|
||||
|
||||
---
|
||||
|
||||
### Source Tree Structure
|
||||
|
||||
**Godot-specific folders:**
|
||||
|
||||
```
|
||||
project/
|
||||
├── scenes/ # All .tscn scene files
|
||||
│ ├── main_menu.tscn
|
||||
│ ├── levels/
|
||||
│ │ ├── level_1.tscn
|
||||
│ │ └── level_2.tscn
|
||||
│ ├── player/
|
||||
│ │ └── player.tscn
|
||||
│ └── enemies/
|
||||
│ ├── base_enemy.tscn
|
||||
│ └── flying_enemy.tscn
|
||||
├── scripts/ # GDScript and C# files
|
||||
│ ├── player/
|
||||
│ │ ├── player.gd
|
||||
│ │ └── player_input.gd
|
||||
│ ├── enemies/
|
||||
│ ├── managers/
|
||||
│ │ ├── game_manager.gd (Autoload)
|
||||
│ │ └── audio_manager.gd (Autoload)
|
||||
│ └── ui/
|
||||
├── resources/ # Custom Resource types
|
||||
│ ├── enemy_data.gd
|
||||
│ └── level_data.gd
|
||||
├── assets/
|
||||
│ ├── sprites/
|
||||
│ ├── textures/
|
||||
│ ├── audio/
|
||||
│ │ ├── music/
|
||||
│ │ └── sfx/
|
||||
│ ├── fonts/
|
||||
│ └── shaders/
|
||||
├── addons/ # Godot plugins
|
||||
└── project.godot # Project settings
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Deployment and Build
|
||||
|
||||
**Platform-specific:**
|
||||
|
||||
- **PC**: Export presets for Windows, Linux, macOS
|
||||
- **Mobile**: Android (APK/AAB), iOS (Xcode project)
|
||||
- **Web**: HTML5 export (SharedArrayBuffer requirements)
|
||||
- **Console**: Partner programs for Switch, Xbox, PlayStation
|
||||
|
||||
**Export templates:**
|
||||
|
||||
- Download from Godot website for each platform
|
||||
- Configure export presets in Project > Export
|
||||
|
||||
**Build automation:**
|
||||
|
||||
- Use `godot --export` command-line for CI/CD
|
||||
- Example: `godot --export-release "Windows Desktop" output/game.exe`
|
||||
|
||||
---
|
||||
|
||||
## Specialist Recommendations
|
||||
|
||||
### Audio Designer
|
||||
|
||||
**When needed:** Games with music, sound effects, ambience
|
||||
**Responsibilities:**
|
||||
|
||||
- AudioStreamPlayer node architecture (2D vs 3D audio)
|
||||
- Audio bus setup in Godot's audio mixer
|
||||
- Music transitions with AudioStreamPlayer.finished signal
|
||||
- Sound effect implementation
|
||||
- Audio performance optimization
|
||||
|
||||
### Performance Optimizer
|
||||
|
||||
**When needed:** Mobile games, large-scale games, complex 3D
|
||||
**Responsibilities:**
|
||||
|
||||
- Godot profiler analysis
|
||||
- Static typing optimization
|
||||
- Draw call reduction
|
||||
- Physics optimization (collision layers/masks)
|
||||
- Memory management
|
||||
- C# performance optimization for heavy systems
|
||||
|
||||
### Multiplayer Architect
|
||||
|
||||
**When needed:** Multiplayer/co-op games
|
||||
**Responsibilities:**
|
||||
|
||||
- High-level multiplayer API or ENet
|
||||
- RPC architecture (remote procedure calls)
|
||||
- State synchronization patterns
|
||||
- Client-server vs peer-to-peer
|
||||
- Anti-cheat considerations
|
||||
- Latency compensation
|
||||
|
||||
### Monetization Specialist
|
||||
|
||||
**When needed:** F2P, mobile games with IAP
|
||||
**Responsibilities:**
|
||||
|
||||
- In-app purchase integration (via plugins)
|
||||
- Ad network integration
|
||||
- Analytics integration
|
||||
- Economy design
|
||||
- Godot-specific monetization patterns
|
||||
|
||||
---
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
1. **Over-using get_node()** - Cache node references in `@onready` variables
|
||||
2. **Not using type hints** - Static typing improves GDScript performance
|
||||
3. **Deep node hierarchies** - Keep scene trees shallow for performance
|
||||
4. **Ignoring signals** - Use signals instead of polling or direct coupling
|
||||
5. **Not leveraging autoload** - Use autoload singletons for global state
|
||||
6. **Poor scene organization** - Plan scene structure before building
|
||||
7. **Forgetting to queue_free()** - Memory leaks from unreleased nodes
|
||||
|
||||
---
|
||||
|
||||
## Godot vs Unity Differences
|
||||
|
||||
### Architecture Differences:
|
||||
|
||||
| Unity | Godot | Notes |
|
||||
| ---------------------- | -------------- | --------------------------------------- |
|
||||
| GameObject + Component | Node hierarchy | Godot nodes have built-in functionality |
|
||||
| MonoBehaviour | Node + Script | Attach scripts to nodes |
|
||||
| ScriptableObject | Resource | Custom data containers |
|
||||
| UnityEvent | Signal | Godot signals are built-in |
|
||||
| Prefab | Scene (.tscn) | Scenes are reusable like prefabs |
|
||||
| Singleton pattern | Autoload | Built-in singleton system |
|
||||
|
||||
### Language Differences:
|
||||
|
||||
| Unity C# | GDScript | Notes |
|
||||
| ------------------------------------- | ------------------------------------------- | --------------------------- |
|
||||
| `public class Player : MonoBehaviour` | `class_name Player extends CharacterBody2D` | GDScript more concise |
|
||||
| `void Start()` | `func _ready():` | Initialization |
|
||||
| `void Update()` | `func _process(delta):` | Per-frame update |
|
||||
| `void FixedUpdate()` | `func _physics_process(delta):` | Physics update |
|
||||
| `[SerializeField]` | `@export` | Inspector-visible variables |
|
||||
| `GetComponent<T>()` | `get_node("NodeName")` or `$NodeName` | Node access |
|
||||
|
||||
---
|
||||
|
||||
## Key Architecture Decision Records
|
||||
|
||||
### ADR Template for Godot Projects
|
||||
|
||||
**ADR-XXX: [Title]**
|
||||
|
||||
**Context:**
|
||||
What Godot-specific issue are we solving?
|
||||
|
||||
**Options:**
|
||||
|
||||
1. GDScript solution
|
||||
2. C# solution
|
||||
3. GDScript + C# hybrid
|
||||
4. Third-party addon (Godot Asset Library)
|
||||
|
||||
**Decision:**
|
||||
We chose [Option X]
|
||||
|
||||
**Godot-specific Rationale:**
|
||||
|
||||
- GDScript vs C# performance tradeoffs
|
||||
- Engine integration (signals, nodes, resources)
|
||||
- Community support and addons
|
||||
- Team expertise
|
||||
- Platform compatibility
|
||||
|
||||
**Consequences:**
|
||||
|
||||
- Impact on performance
|
||||
- Learning curve
|
||||
- Maintenance considerations
|
||||
- Platform limitations (Web export with C#)
|
||||
|
||||
---
|
||||
|
||||
_This guide is specific to Godot Engine. For other engines, see:_
|
||||
|
||||
- game-engine-unity-guide.md
|
||||
- game-engine-unreal-guide.md
|
||||
- game-engine-web-guide.md
|
||||
@@ -1,333 +0,0 @@
|
||||
# Unity Game Engine Architecture Guide
|
||||
|
||||
This guide provides Unity-specific guidance for solution architecture generation.
|
||||
|
||||
---
|
||||
|
||||
## Unity-Specific Questions
|
||||
|
||||
### 1. Unity Version and Render Pipeline
|
||||
|
||||
**Ask:**
|
||||
|
||||
- Which Unity version are you targeting? (2021 LTS, 2022 LTS, 2023+, 6000+)
|
||||
- Which render pipeline? (Built-in, URP Universal Render Pipeline, HDRP High Definition)
|
||||
- Target platform(s)? (PC, Mobile, Console, WebGL)
|
||||
|
||||
**Guidance:**
|
||||
|
||||
- **2021/2022 LTS**: Stable, well-supported, good for production
|
||||
- **URP**: Best for mobile and cross-platform (lower overhead)
|
||||
- **HDRP**: High-fidelity graphics for PC/console only
|
||||
- **Built-in**: Legacy, avoid for new projects
|
||||
|
||||
**Record ADR:** Unity version and render pipeline choice
|
||||
|
||||
---
|
||||
|
||||
### 2. Architecture Pattern
|
||||
|
||||
**Ask:**
|
||||
|
||||
- Component-based MonoBehaviour architecture? (Unity standard)
|
||||
- ECS (Entity Component System) for performance-critical systems?
|
||||
- Hybrid (MonoBehaviour + ECS where needed)?
|
||||
|
||||
**Guidance:**
|
||||
|
||||
- **MonoBehaviour**: Standard, easy to use, good for most games
|
||||
- **ECS/DOTS**: High performance, steep learning curve, use for massive scale (1000s of entities)
|
||||
- **Hybrid**: MonoBehaviour for gameplay, ECS for particles/crowds
|
||||
|
||||
**Record ADR:** Architecture pattern choice and justification
|
||||
|
||||
---
|
||||
|
||||
### 3. Data Management Strategy
|
||||
|
||||
**Ask:**
|
||||
|
||||
- ScriptableObjects for data-driven design?
|
||||
- JSON/XML config files?
|
||||
- Addressables for asset management?
|
||||
|
||||
**Guidance:**
|
||||
|
||||
- **ScriptableObjects**: Unity-native, inspector-friendly, good for game data (enemies, items, levels)
|
||||
- **Addressables**: Essential for large games, enables asset streaming and DLC
|
||||
- Avoid Resources folder (deprecated pattern)
|
||||
|
||||
**Record ADR:** Data management approach
|
||||
|
||||
---
|
||||
|
||||
## Unity-Specific Architecture Sections
|
||||
|
||||
### Game Systems Architecture
|
||||
|
||||
**Components to define:**
|
||||
|
||||
- **Player Controller**: Character movement, input handling
|
||||
- **Camera System**: Follow camera, cinemachine usage
|
||||
- **Game State Manager**: Scene transitions, game modes, pause/resume
|
||||
- **Save System**: PlayerPrefs vs JSON vs Cloud Save
|
||||
- **Input System**: New Input System vs Legacy
|
||||
|
||||
**Unity-specific patterns:**
|
||||
|
||||
```csharp
|
||||
// Singleton GameManager pattern
|
||||
public class GameManager : MonoBehaviour
|
||||
{
|
||||
public static GameManager Instance { get; private set; }
|
||||
|
||||
void Awake()
|
||||
{
|
||||
if (Instance == null) Instance = this;
|
||||
else Destroy(gameObject);
|
||||
DontDestroyOnLoad(gameObject);
|
||||
}
|
||||
}
|
||||
|
||||
// ScriptableObject data pattern
|
||||
[CreateAssetMenu(fileName = "EnemyData", menuName = "Game/Enemy")]
|
||||
public class EnemyData : ScriptableObject
|
||||
{
|
||||
public string enemyName;
|
||||
public int health;
|
||||
public float speed;
|
||||
public GameObject prefab;
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Unity Events and Communication
|
||||
|
||||
**Ask:**
|
||||
|
||||
- UnityEvents for inspector-wired connections?
|
||||
- C# Events for code-based pub/sub?
|
||||
- Message system for decoupled communication?
|
||||
|
||||
**Guidance:**
|
||||
|
||||
- **UnityEvents**: Good for designer-configurable connections
|
||||
- **C# Events**: Better performance, type-safe
|
||||
- **Avoid** FindObjectOfType and GetComponent in Update()
|
||||
|
||||
**Pattern:**
|
||||
|
||||
```csharp
|
||||
// Event-driven damage system
|
||||
public class HealthSystem : MonoBehaviour
|
||||
{
|
||||
public UnityEvent<int> OnDamaged;
|
||||
public UnityEvent OnDeath;
|
||||
|
||||
public void TakeDamage(int amount)
|
||||
{
|
||||
health -= amount;
|
||||
OnDamaged?.Invoke(amount);
|
||||
if (health <= 0) OnDeath?.Invoke();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Performance Optimization
|
||||
|
||||
**Unity-specific considerations:**
|
||||
|
||||
- **Object Pooling**: Essential for bullets, particles, enemies
|
||||
- **Sprite Batching**: Use sprite atlases, minimize draw calls
|
||||
- **Physics Optimization**: Layer-based collision matrix
|
||||
- **Profiler Usage**: CPU, GPU, Memory, Physics profilers
|
||||
- **IL2CPP vs Mono**: Build performance differences
|
||||
|
||||
**Target Performance:**
|
||||
|
||||
- Mobile: 60 FPS minimum (30 FPS for complex 3D)
|
||||
- PC: 60 FPS minimum
|
||||
- Monitor with Unity Profiler
|
||||
|
||||
---
|
||||
|
||||
### Testing Strategy
|
||||
|
||||
**Unity Test Framework:**
|
||||
|
||||
- **Edit Mode Tests**: Test pure C# logic, no Unity lifecycle
|
||||
- **Play Mode Tests**: Test MonoBehaviour components in play mode
|
||||
- Use `[UnityTest]` attribute for coroutine tests
|
||||
- Mock Unity APIs with interfaces
|
||||
|
||||
**Example:**
|
||||
|
||||
```csharp
|
||||
[UnityTest]
|
||||
public IEnumerator Player_TakesDamage_DecreasesHealth()
|
||||
{
|
||||
var player = new GameObject().AddComponent<Player>();
|
||||
player.health = 100;
|
||||
|
||||
player.TakeDamage(20);
|
||||
|
||||
yield return null; // Wait one frame
|
||||
|
||||
Assert.AreEqual(80, player.health);
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Source Tree Structure
|
||||
|
||||
**Unity-specific folders:**
|
||||
|
||||
```
|
||||
Assets/
|
||||
├── Scenes/ # All .unity scene files
|
||||
│ ├── MainMenu.unity
|
||||
│ ├── Level1.unity
|
||||
│ └── Level2.unity
|
||||
├── Scripts/ # All C# code
|
||||
│ ├── Player/
|
||||
│ ├── Enemies/
|
||||
│ ├── Managers/
|
||||
│ ├── UI/
|
||||
│ └── Utilities/
|
||||
├── Prefabs/ # Reusable game objects
|
||||
├── ScriptableObjects/ # Game data assets
|
||||
│ ├── Enemies/
|
||||
│ ├── Items/
|
||||
│ └── Levels/
|
||||
├── Materials/
|
||||
├── Textures/
|
||||
├── Audio/
|
||||
│ ├── Music/
|
||||
│ └── SFX/
|
||||
├── Fonts/
|
||||
├── Animations/
|
||||
├── Resources/ # Avoid - use Addressables instead
|
||||
└── Plugins/ # Third-party SDKs
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Deployment and Build
|
||||
|
||||
**Platform-specific:**
|
||||
|
||||
- **PC**: Standalone builds (Windows/Mac/Linux)
|
||||
- **Mobile**: IL2CPP mandatory for iOS, recommended for Android
|
||||
- **WebGL**: Compression, memory limitations
|
||||
- **Console**: Platform-specific SDKs and certification
|
||||
|
||||
**Build pipeline:**
|
||||
|
||||
- Unity Cloud Build OR
|
||||
- CI/CD with command-line builds: `Unity -batchmode -buildTarget ...`
|
||||
|
||||
---
|
||||
|
||||
## Specialist Recommendations
|
||||
|
||||
### Audio Designer
|
||||
|
||||
**When needed:** Games with music, sound effects, ambience
|
||||
**Responsibilities:**
|
||||
|
||||
- Audio system architecture (2D vs 3D audio)
|
||||
- Audio mixer setup
|
||||
- Music transitions and adaptive audio
|
||||
- Sound effect implementation
|
||||
- Audio performance optimization
|
||||
|
||||
### Performance Optimizer
|
||||
|
||||
**When needed:** Mobile games, large-scale games, VR
|
||||
**Responsibilities:**
|
||||
|
||||
- Profiling and optimization
|
||||
- Memory management
|
||||
- Draw call reduction
|
||||
- Physics optimization
|
||||
- Asset optimization (textures, meshes, audio)
|
||||
|
||||
### Multiplayer Architect
|
||||
|
||||
**When needed:** Multiplayer/co-op games
|
||||
**Responsibilities:**
|
||||
|
||||
- Netcode architecture (Netcode for GameObjects, Mirror, Photon)
|
||||
- Client-server vs peer-to-peer
|
||||
- State synchronization
|
||||
- Anti-cheat considerations
|
||||
- Latency compensation
|
||||
|
||||
### Monetization Specialist
|
||||
|
||||
**When needed:** F2P, mobile games with IAP
|
||||
**Responsibilities:**
|
||||
|
||||
- Unity IAP integration
|
||||
- Ad network integration (AdMob, Unity Ads)
|
||||
- Analytics integration
|
||||
- Economy design (virtual currency, shop)
|
||||
|
||||
---
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
1. **Over-using GetComponent** - Cache references in Awake/Start
|
||||
2. **Empty Update methods** - Remove them, they have overhead
|
||||
3. **String comparisons for tags** - Use CompareTag() instead
|
||||
4. **Resources folder abuse** - Migrate to Addressables
|
||||
5. **Not using object pooling** - Instantiate/Destroy is expensive
|
||||
6. **Ignoring the Profiler** - Profile early, profile often
|
||||
7. **Not testing on target hardware** - Mobile performance differs vastly
|
||||
|
||||
---
|
||||
|
||||
## Key Architecture Decision Records
|
||||
|
||||
### ADR Template for Unity Projects
|
||||
|
||||
**ADR-XXX: [Title]**
|
||||
|
||||
**Context:**
|
||||
What Unity-specific issue are we solving?
|
||||
|
||||
**Options:**
|
||||
|
||||
1. Unity Built-in Solution (e.g., Built-in Input System)
|
||||
2. Unity Package (e.g., New Input System)
|
||||
3. Third-party Asset (e.g., Rewired)
|
||||
4. Custom Implementation
|
||||
|
||||
**Decision:**
|
||||
We chose [Option X]
|
||||
|
||||
**Unity-specific Rationale:**
|
||||
|
||||
- Version compatibility
|
||||
- Performance characteristics
|
||||
- Community support
|
||||
- Asset Store availability
|
||||
- License considerations
|
||||
|
||||
**Consequences:**
|
||||
|
||||
- Impact on build size
|
||||
- Platform compatibility
|
||||
- Learning curve for team
|
||||
|
||||
---
|
||||
|
||||
_This guide is specific to Unity Engine. For other engines, see:_
|
||||
|
||||
- game-engine-godot-guide.md
|
||||
- game-engine-unreal-guide.md
|
||||
- game-engine-web-guide.md
|
||||
@@ -1,528 +0,0 @@
|
||||
# Web Game Engine Architecture Guide
|
||||
|
||||
This guide provides web game engine-specific guidance (Phaser, PixiJS, Three.js, Babylon.js) for solution architecture generation.
|
||||
|
||||
---
|
||||
|
||||
## Web Game-Specific Questions
|
||||
|
||||
### 1. Engine and Technology Selection
|
||||
|
||||
**Ask:**
|
||||
|
||||
- Which engine? (Phaser 3, PixiJS, Three.js, Babylon.js, custom Canvas/WebGL)
|
||||
- TypeScript or JavaScript?
|
||||
- Build tool? (Vite, Webpack, Rollup, Parcel)
|
||||
- Target platform(s)? (Desktop web, mobile web, PWA, Cordova/Capacitor wrapper)
|
||||
|
||||
**Guidance:**
|
||||
|
||||
- **Phaser 3**: Full-featured 2D game framework, great for beginners
|
||||
- **PixiJS**: 2D rendering library, more low-level than Phaser
|
||||
- **Three.js**: 3D graphics library, mature ecosystem
|
||||
- **Babylon.js**: Complete 3D game engine, WebXR support
|
||||
- **TypeScript**: Recommended for all web games (type safety, better tooling)
|
||||
- **Vite**: Modern, fast, HMR - best for development
|
||||
|
||||
**Record ADR:** Engine selection and build tooling
|
||||
|
||||
---
|
||||
|
||||
### 2. Architecture Pattern
|
||||
|
||||
**Ask:**
|
||||
|
||||
- Scene-based architecture? (Phaser scenes, custom scene manager)
|
||||
- ECS (Entity Component System)? (Libraries: bitECS, ecsy)
|
||||
- State management? (Redux, Zustand, custom FSM)
|
||||
|
||||
**Guidance:**
|
||||
|
||||
- **Scene-based**: Natural for Phaser, good for level-based games
|
||||
- **ECS**: Better performance for large entity counts (100s+)
|
||||
- **FSM**: Good for simple state transitions (menu → game → gameover)
|
||||
|
||||
**Phaser Pattern:**
|
||||
|
||||
```typescript
|
||||
// MainMenuScene.ts
|
||||
export class MainMenuScene extends Phaser.Scene {
|
||||
constructor() {
|
||||
super({ key: 'MainMenu' });
|
||||
}
|
||||
|
||||
create() {
|
||||
this.add.text(400, 300, 'Main Menu', { fontSize: '32px' });
|
||||
|
||||
const startButton = this.add
|
||||
.text(400, 400, 'Start Game', { fontSize: '24px' })
|
||||
.setInteractive()
|
||||
.on('pointerdown', () => {
|
||||
this.scene.start('GameScene');
|
||||
});
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Record ADR:** Architecture pattern and scene management
|
||||
|
||||
---
|
||||
|
||||
### 3. Asset Management
|
||||
|
||||
**Ask:**
|
||||
|
||||
- Asset loading strategy? (Preload all, lazy load, progressive)
|
||||
- Texture atlas usage? (TexturePacker, built-in tools)
|
||||
- Audio format strategy? (MP3, OGG, WebM)
|
||||
|
||||
**Guidance:**
|
||||
|
||||
- **Preload**: Load all assets at start (simple, small games)
|
||||
- **Lazy load**: Load per-level (better for larger games)
|
||||
- **Texture atlases**: Essential for performance (reduce draw calls)
|
||||
- **Audio**: MP3 for compatibility, OGG for smaller size, use both
|
||||
|
||||
**Phaser loading:**
|
||||
|
||||
```typescript
|
||||
class PreloadScene extends Phaser.Scene {
|
||||
preload() {
|
||||
// Show progress bar
|
||||
this.load.on('progress', (value: number) => {
|
||||
console.log('Loading: ' + Math.round(value * 100) + '%');
|
||||
});
|
||||
|
||||
// Load assets
|
||||
this.load.atlas('sprites', 'assets/sprites.png', 'assets/sprites.json');
|
||||
this.load.audio('music', ['assets/music.mp3', 'assets/music.ogg']);
|
||||
this.load.audio('jump', ['assets/sfx/jump.mp3', 'assets/sfx/jump.ogg']);
|
||||
}
|
||||
|
||||
create() {
|
||||
this.scene.start('MainMenu');
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Record ADR:** Asset loading and management strategy
|
||||
|
||||
---
|
||||
|
||||
## Web Game-Specific Architecture Sections
|
||||
|
||||
### Performance Optimization
|
||||
|
||||
**Web-specific considerations:**
|
||||
|
||||
- **Object Pooling**: Mandatory for bullets, particles, enemies (avoid GC pauses)
|
||||
- **Sprite Batching**: Use texture atlases, minimize state changes
|
||||
- **Canvas vs WebGL**: WebGL for better performance (most games)
|
||||
- **Draw Call Reduction**: Batch similar sprites, use sprite sheets
|
||||
- **Memory Management**: Watch heap size, profile with Chrome DevTools
|
||||
|
||||
**Object Pooling Pattern:**
|
||||
|
||||
```typescript
|
||||
class BulletPool {
|
||||
private pool: Bullet[] = [];
|
||||
private scene: Phaser.Scene;
|
||||
|
||||
constructor(scene: Phaser.Scene, size: number) {
|
||||
this.scene = scene;
|
||||
for (let i = 0; i < size; i++) {
|
||||
const bullet = new Bullet(scene);
|
||||
bullet.setActive(false).setVisible(false);
|
||||
this.pool.push(bullet);
|
||||
}
|
||||
}
|
||||
|
||||
spawn(x: number, y: number, velocityX: number, velocityY: number): Bullet | null {
|
||||
const bullet = this.pool.find((b) => !b.active);
|
||||
if (bullet) {
|
||||
bullet.spawn(x, y, velocityX, velocityY);
|
||||
}
|
||||
return bullet || null;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Target Performance:**
|
||||
|
||||
- **Desktop**: 60 FPS minimum
|
||||
- **Mobile**: 60 FPS (high-end), 30 FPS (low-end)
|
||||
- **Profile with**: Chrome DevTools Performance tab, Phaser Debug plugin
|
||||
|
||||
---
|
||||
|
||||
### Input Handling
|
||||
|
||||
**Multi-input support:**
|
||||
|
||||
```typescript
|
||||
class GameScene extends Phaser.Scene {
|
||||
private cursors?: Phaser.Types.Input.Keyboard.CursorKeys;
|
||||
private wasd?: { [key: string]: Phaser.Input.Keyboard.Key };
|
||||
|
||||
create() {
|
||||
// Keyboard
|
||||
this.cursors = this.input.keyboard?.createCursorKeys();
|
||||
this.wasd = this.input.keyboard?.addKeys('W,S,A,D') as any;
|
||||
|
||||
// Mouse/Touch
|
||||
this.input.on('pointerdown', (pointer: Phaser.Input.Pointer) => {
|
||||
this.handleClick(pointer.x, pointer.y);
|
||||
});
|
||||
|
||||
// Gamepad (optional)
|
||||
this.input.gamepad?.on('down', (pad, button, index) => {
|
||||
this.handleGamepadButton(button);
|
||||
});
|
||||
}
|
||||
|
||||
update() {
|
||||
// Handle keyboard input
|
||||
if (this.cursors?.left.isDown || this.wasd?.A.isDown) {
|
||||
this.player.moveLeft();
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### State Persistence
|
||||
|
||||
**LocalStorage pattern:**
|
||||
|
||||
```typescript
|
||||
interface GameSaveData {
|
||||
level: number;
|
||||
score: number;
|
||||
playerStats: {
|
||||
health: number;
|
||||
lives: number;
|
||||
};
|
||||
}
|
||||
|
||||
class SaveManager {
|
||||
private static SAVE_KEY = 'game_save_data';
|
||||
|
||||
static save(data: GameSaveData): void {
|
||||
localStorage.setItem(this.SAVE_KEY, JSON.stringify(data));
|
||||
}
|
||||
|
||||
static load(): GameSaveData | null {
|
||||
const data = localStorage.getItem(this.SAVE_KEY);
|
||||
return data ? JSON.parse(data) : null;
|
||||
}
|
||||
|
||||
static clear(): void {
|
||||
localStorage.removeItem(this.SAVE_KEY);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Source Tree Structure
|
||||
|
||||
**Phaser + TypeScript + Vite:**
|
||||
|
||||
```
|
||||
project/
|
||||
├── public/ # Static assets
|
||||
│ ├── assets/
|
||||
│ │ ├── sprites/
|
||||
│ │ ├── audio/
|
||||
│ │ │ ├── music/
|
||||
│ │ │ └── sfx/
|
||||
│ │ └── fonts/
|
||||
│ └── index.html
|
||||
├── src/
|
||||
│ ├── main.ts # Game initialization
|
||||
│ ├── config.ts # Phaser config
|
||||
│ ├── scenes/ # Game scenes
|
||||
│ │ ├── PreloadScene.ts
|
||||
│ │ ├── MainMenuScene.ts
|
||||
│ │ ├── GameScene.ts
|
||||
│ │ └── GameOverScene.ts
|
||||
│ ├── entities/ # Game objects
|
||||
│ │ ├── Player.ts
|
||||
│ │ ├── Enemy.ts
|
||||
│ │ └── Bullet.ts
|
||||
│ ├── systems/ # Game systems
|
||||
│ │ ├── InputManager.ts
|
||||
│ │ ├── AudioManager.ts
|
||||
│ │ └── SaveManager.ts
|
||||
│ ├── utils/ # Utilities
|
||||
│ │ ├── ObjectPool.ts
|
||||
│ │ └── Constants.ts
|
||||
│ └── types/ # TypeScript types
|
||||
│ └── index.d.ts
|
||||
├── tests/ # Unit tests
|
||||
├── package.json
|
||||
├── tsconfig.json
|
||||
├── vite.config.ts
|
||||
└── README.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Testing Strategy
|
||||
|
||||
**Jest + TypeScript:**
|
||||
|
||||
```typescript
|
||||
// Player.test.ts
|
||||
import { Player } from '../entities/Player';
|
||||
|
||||
describe('Player', () => {
|
||||
let player: Player;
|
||||
|
||||
beforeEach(() => {
|
||||
// Mock Phaser scene
|
||||
const mockScene = {
|
||||
add: { sprite: jest.fn() },
|
||||
physics: { add: { sprite: jest.fn() } },
|
||||
} as any;
|
||||
|
||||
player = new Player(mockScene, 0, 0);
|
||||
});
|
||||
|
||||
test('takes damage correctly', () => {
|
||||
player.health = 100;
|
||||
player.takeDamage(20);
|
||||
expect(player.health).toBe(80);
|
||||
});
|
||||
|
||||
test('dies when health reaches zero', () => {
|
||||
player.health = 10;
|
||||
player.takeDamage(20);
|
||||
expect(player.alive).toBe(false);
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
**E2E Testing:**
|
||||
|
||||
- Playwright for browser automation
|
||||
- Cypress for interactive testing
|
||||
- Test game states, not individual frames
|
||||
|
||||
---
|
||||
|
||||
### Deployment and Build
|
||||
|
||||
**Build for production:**
|
||||
|
||||
```json
|
||||
// package.json scripts
|
||||
{
|
||||
"scripts": {
|
||||
"dev": "vite",
|
||||
"build": "tsc andand vite build",
|
||||
"preview": "vite preview",
|
||||
"test": "jest"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Deployment targets:**
|
||||
|
||||
- **Static hosting**: Netlify, Vercel, GitHub Pages, AWS S3
|
||||
- **CDN**: Cloudflare, Fastly for global distribution
|
||||
- **PWA**: Service worker for offline play
|
||||
- **Mobile wrapper**: Cordova or Capacitor for app stores
|
||||
|
||||
**Optimization:**
|
||||
|
||||
```typescript
|
||||
// vite.config.ts
|
||||
export default defineConfig({
|
||||
build: {
|
||||
rollupOptions: {
|
||||
output: {
|
||||
manualChunks: {
|
||||
phaser: ['phaser'], // Separate Phaser bundle
|
||||
},
|
||||
},
|
||||
},
|
||||
minify: 'terser',
|
||||
terserOptions: {
|
||||
compress: {
|
||||
drop_console: true, // Remove console.log in prod
|
||||
},
|
||||
},
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Specialist Recommendations
|
||||
|
||||
### Audio Designer
|
||||
|
||||
**When needed:** Games with music, sound effects, ambience
|
||||
**Responsibilities:**
|
||||
|
||||
- Web Audio API architecture
|
||||
- Audio sprite creation (combine sounds into one file)
|
||||
- Music loop management
|
||||
- Sound effect implementation
|
||||
- Audio performance on web (decode strategy)
|
||||
|
||||
### Performance Optimizer
|
||||
|
||||
**When needed:** Mobile web games, complex games
|
||||
**Responsibilities:**
|
||||
|
||||
- Chrome DevTools profiling
|
||||
- Object pooling implementation
|
||||
- Draw call optimization
|
||||
- Memory management
|
||||
- Bundle size optimization
|
||||
- Network performance (asset loading)
|
||||
|
||||
### Monetization Specialist
|
||||
|
||||
**When needed:** F2P web games
|
||||
**Responsibilities:**
|
||||
|
||||
- Ad network integration (Google AdSense, AdMob for web)
|
||||
- In-game purchases (Stripe, PayPal)
|
||||
- Analytics (Google Analytics, custom events)
|
||||
- A/B testing frameworks
|
||||
- Economy design
|
||||
|
||||
### Platform Specialist
|
||||
|
||||
**When needed:** Mobile wrapper apps (Cordova/Capacitor)
|
||||
**Responsibilities:**
|
||||
|
||||
- Native plugin integration
|
||||
- Platform-specific performance tuning
|
||||
- App store submission
|
||||
- Device compatibility testing
|
||||
- Push notification setup
|
||||
|
||||
---
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
1. **Not using object pooling** - Frequent instantiation causes GC pauses
|
||||
2. **Too many draw calls** - Use texture atlases and sprite batching
|
||||
3. **Loading all assets at once** - Causes long initial load times
|
||||
4. **Not testing on mobile** - Performance vastly different on phones
|
||||
5. **Ignoring bundle size** - Large bundles = slow load times
|
||||
6. **Not handling window resize** - Web games run in resizable windows
|
||||
7. **Forgetting audio autoplay restrictions** - Browsers block auto-play without user interaction
|
||||
|
||||
---
|
||||
|
||||
## Engine-Specific Patterns
|
||||
|
||||
### Phaser 3
|
||||
|
||||
```typescript
|
||||
const config: Phaser.Types.Core.GameConfig = {
|
||||
type: Phaser.AUTO, // WebGL with Canvas fallback
|
||||
width: 800,
|
||||
height: 600,
|
||||
physics: {
|
||||
default: 'arcade',
|
||||
arcade: { gravity: { y: 300 }, debug: false },
|
||||
},
|
||||
scene: [PreloadScene, MainMenuScene, GameScene, GameOverScene],
|
||||
};
|
||||
|
||||
const game = new Phaser.Game(config);
|
||||
```
|
||||
|
||||
### PixiJS
|
||||
|
||||
```typescript
|
||||
const app = new PIXI.Application({
|
||||
width: 800,
|
||||
height: 600,
|
||||
backgroundColor: 0x1099bb,
|
||||
});
|
||||
|
||||
document.body.appendChild(app.view);
|
||||
|
||||
const sprite = PIXI.Sprite.from('assets/player.png');
|
||||
app.stage.addChild(sprite);
|
||||
|
||||
app.ticker.add((delta) => {
|
||||
sprite.rotation += 0.01 * delta;
|
||||
});
|
||||
```
|
||||
|
||||
### Three.js
|
||||
|
||||
```typescript
|
||||
const scene = new THREE.Scene();
|
||||
const camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000);
|
||||
const renderer = new THREE.WebGLRenderer();
|
||||
|
||||
renderer.setSize(window.innerWidth, window.innerHeight);
|
||||
document.body.appendChild(renderer.domElement);
|
||||
|
||||
const geometry = new THREE.BoxGeometry();
|
||||
const material = new THREE.MeshBasicMaterial({ color: 0x00ff00 });
|
||||
const cube = new THREE.Mesh(geometry, material);
|
||||
scene.add(cube);
|
||||
|
||||
function animate() {
|
||||
requestAnimationFrame(animate);
|
||||
cube.rotation.x += 0.01;
|
||||
renderer.render(scene, camera);
|
||||
}
|
||||
animate();
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Key Architecture Decision Records
|
||||
|
||||
### ADR Template for Web Games
|
||||
|
||||
**ADR-XXX: [Title]**
|
||||
|
||||
**Context:**
|
||||
What web game-specific issue are we solving?
|
||||
|
||||
**Options:**
|
||||
|
||||
1. Phaser 3 (full framework)
|
||||
2. PixiJS (rendering library)
|
||||
3. Three.js/Babylon.js (3D)
|
||||
4. Custom Canvas/WebGL
|
||||
|
||||
**Decision:**
|
||||
We chose [Option X]
|
||||
|
||||
**Web-specific Rationale:**
|
||||
|
||||
- Engine features vs bundle size
|
||||
- Community and plugin ecosystem
|
||||
- TypeScript support
|
||||
- Performance on target devices (mobile web)
|
||||
- Browser compatibility
|
||||
- Development velocity
|
||||
|
||||
**Consequences:**
|
||||
|
||||
- Impact on bundle size (Phaser ~1.2MB gzipped)
|
||||
- Learning curve
|
||||
- Platform limitations
|
||||
- Plugin availability
|
||||
|
||||
---
|
||||
|
||||
_This guide is specific to web game engines. For native engines, see:_
|
||||
|
||||
- game-engine-unity-guide.md
|
||||
- game-engine-godot-guide.md
|
||||
- game-engine-unreal-guide.md
|
||||
@@ -1,66 +0,0 @@
|
||||
# {{TITLE}} Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
{{technology_table}}
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
{{architecture_overview}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
{{data_architecture}}
|
||||
|
||||
## 4. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 5. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
## 6. Implementation Guidance
|
||||
|
||||
{{implementation_guidance}}
|
||||
|
||||
## 7. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## 8. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 9. Deployment and Operations
|
||||
|
||||
{{deployment_operations}}
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 10. Security
|
||||
|
||||
{{security}}
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -1,66 +0,0 @@
|
||||
# {{TITLE}} Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
{{technology_table}}
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
{{architecture_overview}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
{{data_architecture}}
|
||||
|
||||
## 4. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 5. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
## 6. Implementation Guidance
|
||||
|
||||
{{implementation_guidance}}
|
||||
|
||||
## 7. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## 8. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 9. Deployment and Operations
|
||||
|
||||
{{deployment_operations}}
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 10. Security
|
||||
|
||||
{{security}}
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -1,66 +0,0 @@
|
||||
# {{TITLE}} Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
{{technology_table}}
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
{{architecture_overview}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
{{data_architecture}}
|
||||
|
||||
## 4. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 5. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
## 6. Implementation Guidance
|
||||
|
||||
{{implementation_guidance}}
|
||||
|
||||
## 7. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## 8. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 9. Deployment and Operations
|
||||
|
||||
{{deployment_operations}}
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 10. Security
|
||||
|
||||
{{security}}
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -1,172 +0,0 @@
|
||||
id,name,project_types,languages,architecture_style,repo_strategy,tags,template_path,reference_architecture_path,guide_path
|
||||
web-nextjs-ssr-monorepo,Next.js SSR Monolith,web,TypeScript,monolith,monorepo,"ssr,react,fullstack,vercel",web-fullstack-architecture.md,,
|
||||
web-nuxt-ssr-monorepo,Nuxt SSR Monolith,web,TypeScript,monolith,monorepo,"ssr,vue,fullstack",web-fullstack-architecture.md,,
|
||||
web-sveltekit-ssr-monorepo,SvelteKit SSR Monolith,web,TypeScript,monolith,monorepo,"ssr,svelte,fullstack",web-fullstack-architecture.md,,
|
||||
web-remix-ssr-monorepo,Remix SSR Monolith,web,TypeScript,monolith,monorepo,"ssr,react,fullstack",web-fullstack-architecture.md,,
|
||||
web-rails-monolith,Rails Monolith,web,Ruby,monolith,monorepo,"ssr,mvc,fullstack",web-fullstack-architecture.md,,
|
||||
web-django-templates,Django with Templates,web,Python,monolith,monorepo,"ssr,mvc,fullstack",web-fullstack-architecture.md,,
|
||||
web-laravel-monolith,Laravel Monolith,web,PHP,monolith,monorepo,"ssr,mvc,fullstack",web-fullstack-architecture.md,,
|
||||
web-aspnet-mvc,ASP.NET MVC,web,C#,monolith,monorepo,"ssr,mvc,fullstack,dotnet",web-fullstack-architecture.md,,
|
||||
web-express-api,Express REST API,web,TypeScript,monolith,monorepo,"api,rest,backend",web-api-architecture.md,,
|
||||
web-fastapi,FastAPI,web,Python,monolith,monorepo,"api,rest,backend,async",web-api-architecture.md,,
|
||||
web-flask-api,Flask REST API,web,Python,monolith,monorepo,"api,rest,backend",web-api-architecture.md,,
|
||||
web-django-rest,Django REST Framework,web,Python,monolith,monorepo,"api,rest,backend",web-api-architecture.md,,
|
||||
web-rails-api,Rails API Mode,web,Ruby,monolith,monorepo,"api,rest,backend",web-api-architecture.md,,
|
||||
web-gin-api,Gin API (Go),web,Go,monolith,monorepo,"api,rest,backend",web-api-architecture.md,,
|
||||
web-spring-boot-api,Spring Boot API,web,Java,monolith,monorepo,"api,rest,backend",web-api-architecture.md,,
|
||||
web-aspnet-api,ASP.NET Web API,web,C#,monolith,monorepo,"api,rest,backend,dotnet",web-api-architecture.md,,
|
||||
web-react-django-separate,React + Django (Separate),web,"TypeScript,Python",spa-with-api,monorepo,"spa,react,django",web-fullstack-architecture.md,,
|
||||
web-react-express-separate,React + Express (Separate),web,TypeScript,spa-with-api,monorepo,"spa,react,node",web-fullstack-architecture.md,,
|
||||
web-vue-rails-separate,Vue + Rails (Separate),web,"TypeScript,Ruby",spa-with-api,monorepo,"spa,vue,rails",web-fullstack-architecture.md,,
|
||||
web-vue-laravel-separate,Vue + Laravel (Separate),web,"TypeScript,PHP",spa-with-api,monorepo,"spa,vue,laravel",web-fullstack-architecture.md,,
|
||||
web-angular-spring-separate,Angular + Spring Boot,web,"TypeScript,Java",spa-with-api,monorepo,"spa,angular,spring",web-fullstack-architecture.md,,
|
||||
web-angular-dotnet-separate,Angular + .NET API,web,"TypeScript,C#",spa-with-api,monorepo,"spa,angular,dotnet",web-fullstack-architecture.md,,
|
||||
web-svelte-go-separate,Svelte + Go API,web,"TypeScript,Go",spa-with-api,monorepo,"spa,svelte,go",web-fullstack-architecture.md,,
|
||||
web-nextjs-microservices-mono,Next.js Microservices (Monorepo),web,TypeScript,microservices,monorepo,"microservices,react,nx,turborepo",web-fullstack-architecture.md,,
|
||||
web-node-microservices-mono,Node.js Microservices (Monorepo),web,TypeScript,microservices,monorepo,"microservices,node,nx",web-fullstack-architecture.md,,
|
||||
web-go-microservices-mono,Go Microservices (Monorepo),web,Go,microservices,monorepo,"microservices,go,grpc",web-fullstack-architecture.md,,
|
||||
web-python-microservices-mono,Python Microservices (Monorepo),web,Python,microservices,monorepo,"microservices,python,fastapi",web-fullstack-architecture.md,,
|
||||
web-nextjs-microservices-poly,Next.js Microservices (Polyrepo),web,TypeScript,microservices,polyrepo,"microservices,react,kubernetes",web-fullstack-architecture.md,,
|
||||
web-node-microservices-poly,Node.js Microservices (Polyrepo),web,TypeScript,microservices,polyrepo,"microservices,node,kubernetes",web-fullstack-architecture.md,,
|
||||
web-go-microservices-poly,Go Microservices (Polyrepo),web,Go,microservices,polyrepo,"microservices,go,kubernetes,grpc",web-fullstack-architecture.md,,
|
||||
web-java-microservices-poly,Java Microservices (Polyrepo),web,Java,microservices,polyrepo,"microservices,spring,kubernetes",web-fullstack-architecture.md,,
|
||||
web-nextjs-vercel-serverless,Next.js Serverless (Vercel),web,TypeScript,serverless,monorepo,"serverless,vercel,edge",web-fullstack-architecture.md,,
|
||||
web-lambda-node-serverless,AWS Lambda (Node.js),web,TypeScript,serverless,monorepo,"serverless,aws,lambda",web-api-architecture.md,,
|
||||
web-lambda-python-serverless,AWS Lambda (Python),web,Python,serverless,monorepo,"serverless,aws,lambda",web-api-architecture.md,,
|
||||
web-lambda-go-serverless,AWS Lambda (Go),web,Go,serverless,monorepo,"serverless,aws,lambda",web-api-architecture.md,,
|
||||
web-cloudflare-workers,Cloudflare Workers,web,TypeScript,serverless,monorepo,"serverless,cloudflare,edge",web-api-architecture.md,,
|
||||
web-netlify-functions,Netlify Functions,web,TypeScript,serverless,monorepo,"serverless,netlify,edge",web-api-architecture.md,,
|
||||
web-astro-jamstack,Astro Static Site,web,TypeScript,jamstack,monorepo,"static,ssg,content",web-fullstack-architecture.md,,
|
||||
web-hugo-jamstack,Hugo Static Site,web,Go,jamstack,monorepo,"static,ssg,content",web-fullstack-architecture.md,,
|
||||
web-gatsby-jamstack,Gatsby Static Site,web,TypeScript,jamstack,monorepo,"static,ssg,react",web-fullstack-architecture.md,,
|
||||
web-eleventy-jamstack,Eleventy Static Site,web,JavaScript,jamstack,monorepo,"static,ssg,content",web-fullstack-architecture.md,,
|
||||
web-jekyll-jamstack,Jekyll Static Site,web,Ruby,jamstack,monorepo,"static,ssg,content",web-fullstack-architecture.md,,
|
||||
mobile-swift-native,iOS Native (Swift),mobile,Swift,native,monorepo,"ios,native,xcode,uikit",mobile-app-architecture.md,,
|
||||
mobile-swiftui-native,iOS Native (SwiftUI),mobile,Swift,native,monorepo,"ios,native,xcode,swiftui",mobile-app-architecture.md,,
|
||||
mobile-kotlin-native,Android Native (Kotlin),mobile,Kotlin,native,monorepo,"android,native,android-studio",mobile-app-architecture.md,,
|
||||
mobile-compose-native,Android Native (Compose),mobile,Kotlin,native,monorepo,"android,native,compose",mobile-app-architecture.md,,
|
||||
mobile-react-native,React Native,mobile,TypeScript,cross-platform,monorepo,"cross-platform,react,expo",mobile-app-architecture.md,,
|
||||
mobile-flutter,Flutter,mobile,Dart,cross-platform,monorepo,"cross-platform,flutter,material",mobile-app-architecture.md,,
|
||||
mobile-xamarin,Xamarin,mobile,C#,cross-platform,monorepo,"cross-platform,xamarin,dotnet",mobile-app-architecture.md,,
|
||||
mobile-ionic-hybrid,Ionic Hybrid,mobile,TypeScript,hybrid,monorepo,"hybrid,ionic,capacitor",mobile-app-architecture.md,,
|
||||
mobile-capacitor-hybrid,Capacitor Hybrid,mobile,TypeScript,hybrid,monorepo,"hybrid,capacitor,webview",mobile-app-architecture.md,,
|
||||
mobile-cordova-hybrid,Cordova Hybrid,mobile,JavaScript,hybrid,monorepo,"hybrid,cordova,webview",mobile-app-architecture.md,,
|
||||
mobile-pwa,Progressive Web App,mobile,TypeScript,pwa,monorepo,"pwa,service-worker,offline",mobile-app-architecture.md,,
|
||||
game-unity-3d,Unity 3D,game,C#,monolith,monorepo,"3d,unity,game-engine",game-engine-architecture.md,,game-engine-unity-guide.md
|
||||
game-unreal-3d,Unreal Engine 3D,game,"C++,Blueprint",monolith,monorepo,"3d,unreal,aaa",game-engine-architecture.md,,game-engine-unreal-guide.md
|
||||
game-godot-3d,Godot 3D,game,GDScript,monolith,monorepo,"3d,godot,open-source",game-engine-architecture.md,,game-engine-godot-guide.md
|
||||
game-custom-3d-cpp,Custom 3D Engine (C++),game,C++,monolith,monorepo,"3d,custom,opengl",game-engine-architecture.md,,game-engine-general-guide.md
|
||||
game-custom-3d-rust,Custom 3D Engine (Rust),game,Rust,monolith,monorepo,"3d,custom,vulkan",game-engine-architecture.md,,game-engine-general-guide.md
|
||||
game-unity-2d,Unity 2D,game,C#,monolith,monorepo,"2d,unity,game-engine",game-engine-architecture.md,,game-engine-unity-guide.md
|
||||
game-godot-2d,Godot 2D,game,GDScript,monolith,monorepo,"2d,godot,open-source",game-engine-architecture.md,,game-engine-godot-guide.md
|
||||
game-gamemaker,GameMaker,game,GML,monolith,monorepo,"2d,gamemaker,indie",game-engine-architecture.md,,game-engine-general-guide.md
|
||||
game-phaser,Phaser (Web),game,TypeScript,monolith,monorepo,"2d,phaser,html5",game-engine-architecture.md,,game-engine-web-guide.md
|
||||
game-pixijs,PixiJS (Web),game,TypeScript,monolith,monorepo,"2d,pixijs,canvas",game-engine-architecture.md,,game-engine-web-guide.md
|
||||
game-threejs,Three.js (Web),game,TypeScript,monolith,monorepo,"3d,threejs,webgl",game-engine-architecture.md,,game-engine-web-guide.md
|
||||
game-babylonjs,Babylon.js (Web),game,TypeScript,monolith,monorepo,"3d,babylonjs,webgl",game-engine-architecture.md,,game-engine-web-guide.md
|
||||
game-text-python,Text-Based (Python),game,Python,monolith,monorepo,"text,roguelike",game-engine-architecture.md,,game-engine-general-guide.md
|
||||
game-text-js,Text-Based (JavaScript),game,JavaScript,monolith,monorepo,"text,interactive-fiction",game-engine-architecture.md,,game-engine-general-guide.md
|
||||
game-text-cpp,Text-Based (C++),game,C++,monolith,monorepo,"text,roguelike,mud",game-engine-architecture.md,,game-engine-general-guide.md
|
||||
backend-express-rest,Express REST,backend,TypeScript,monolith,monorepo,"rest,express",backend-service-architecture.md,,
|
||||
backend-fastapi-rest,FastAPI REST,backend,Python,monolith,monorepo,"rest,fastapi,async",backend-service-architecture.md,,
|
||||
backend-django-rest-fw,Django REST Framework,backend,Python,monolith,monorepo,"rest,django",backend-service-architecture.md,,
|
||||
backend-flask-rest,Flask REST,backend,Python,monolith,monorepo,"rest,flask,lightweight",backend-service-architecture.md,,
|
||||
backend-spring-boot-rest,Spring Boot REST,backend,Java,monolith,monorepo,"rest,spring,enterprise",backend-service-architecture.md,,
|
||||
backend-gin-rest,Gin REST (Go),backend,Go,monolith,monorepo,"rest,gin,performance",backend-service-architecture.md,,
|
||||
backend-actix-rest,Actix Web (Rust),backend,Rust,monolith,monorepo,"rest,actix,performance",backend-service-architecture.md,,
|
||||
backend-rails-api,Rails API,backend,Ruby,monolith,monorepo,"rest,rails",backend-service-architecture.md,,
|
||||
backend-apollo-graphql,Apollo GraphQL,backend,TypeScript,monolith,monorepo,"graphql,apollo",backend-service-architecture.md,,
|
||||
backend-hasura-graphql,Hasura GraphQL,backend,any,monolith,monorepo,"graphql,hasura,postgres",backend-service-architecture.md,,
|
||||
backend-strawberry-graphql,Strawberry GraphQL (Python),backend,Python,monolith,monorepo,"graphql,strawberry,async",backend-service-architecture.md,,
|
||||
backend-graphql-go,gqlgen (Go),backend,Go,monolith,monorepo,"graphql,gqlgen,type-safe",backend-service-architecture.md,,
|
||||
backend-grpc-go,gRPC Service (Go),backend,Go,monolith,monorepo,"grpc,protobuf",backend-service-architecture.md,,
|
||||
backend-grpc-node,gRPC Service (Node.js),backend,TypeScript,monolith,monorepo,"grpc,protobuf",backend-service-architecture.md,,
|
||||
backend-grpc-rust,gRPC Service (Rust),backend,Rust,monolith,monorepo,"grpc,tonic",backend-service-architecture.md,,
|
||||
backend-grpc-java,gRPC Service (Java),backend,Java,monolith,monorepo,"grpc,protobuf",backend-service-architecture.md,,
|
||||
backend-socketio-realtime,Socket.IO Realtime,backend,TypeScript,monolith,monorepo,"realtime,socketio",backend-service-architecture.md,,
|
||||
backend-phoenix-realtime,Phoenix Channels,backend,Elixir,monolith,monorepo,"realtime,phoenix",backend-service-architecture.md,,
|
||||
backend-ably-realtime,Ably Realtime,backend,any,monolith,monorepo,"realtime,ably,managed",backend-service-architecture.md,,
|
||||
backend-pusher-realtime,Pusher Realtime,backend,any,monolith,monorepo,"realtime,pusher,managed",backend-service-architecture.md,,
|
||||
backend-kafka-event,Kafka Event-Driven,backend,"Java,Go,Python",event-driven,monorepo,"event-driven,kafka,streaming",backend-service-architecture.md,,
|
||||
backend-rabbitmq-event,RabbitMQ Event-Driven,backend,"Python,Go,Node",event-driven,monorepo,"event-driven,rabbitmq,amqp",backend-service-architecture.md,,
|
||||
backend-nats-event,NATS Event-Driven,backend,Go,event-driven,monorepo,"event-driven,nats,messaging",backend-service-architecture.md,,
|
||||
backend-sqs-event,AWS SQS Event-Driven,backend,"Python,Node",event-driven,monorepo,"event-driven,aws,sqs",backend-service-architecture.md,,
|
||||
backend-celery-batch,Celery Batch (Python),backend,Python,batch,monorepo,"batch,celery,redis,async",backend-service-architecture.md,,
|
||||
backend-airflow-batch,Airflow Pipelines,backend,Python,batch,monorepo,"batch,airflow,orchestration,dags",backend-service-architecture.md,,
|
||||
backend-prefect-batch,Prefect Pipelines,backend,Python,batch,monorepo,"batch,prefect,orchestration",backend-service-architecture.md,,
|
||||
backend-temporal-batch,Temporal Workflows,backend,"Go,TypeScript",batch,monorepo,"batch,temporal,workflows",backend-service-architecture.md,,
|
||||
embedded-freertos-esp32,FreeRTOS ESP32,embedded,C,rtos,monorepo,"iot,freertos,wifi",embedded-firmware-architecture.md,,
|
||||
embedded-freertos-stm32,FreeRTOS STM32,embedded,C,rtos,monorepo,"stm32,freertos,arm,cortex",embedded-firmware-architecture.md,,
|
||||
embedded-zephyr,Zephyr RTOS,embedded,C,rtos,monorepo,"zephyr,iot,bluetooth",embedded-firmware-architecture.md,,
|
||||
embedded-nuttx,NuttX RTOS,embedded,C,rtos,monorepo,"nuttx,posix",embedded-firmware-architecture.md,,
|
||||
embedded-arduino-bare,Arduino Bare Metal,embedded,"C,C++",bare-metal,monorepo,"arduino,bare-metal,avr",embedded-firmware-architecture.md,,
|
||||
embedded-stm32-bare,STM32 Bare Metal,embedded,C,bare-metal,monorepo,"stm32,bare-metal,arm",embedded-firmware-architecture.md,,
|
||||
embedded-pic-bare,PIC Microcontroller,embedded,C,bare-metal,monorepo,"pic,microchip",embedded-firmware-architecture.md,,
|
||||
embedded-avr-bare,AVR Bare Metal,embedded,C,bare-metal,monorepo,"avr,atmega",embedded-firmware-architecture.md,,
|
||||
embedded-raspberrypi,Raspberry Pi (Linux),embedded,Python,linux,monorepo,"raspberry-pi,gpio,python",embedded-firmware-architecture.md,,
|
||||
embedded-beaglebone,BeagleBone (Linux),embedded,Python,linux,monorepo,"beaglebone,gpio",embedded-firmware-architecture.md,,
|
||||
embedded-jetson,NVIDIA Jetson,embedded,Python,linux,monorepo,"jetson,ai,gpu",embedded-firmware-architecture.md,,
|
||||
embedded-esp32-iot,ESP32 IoT Cloud,embedded,C,iot-cloud,monorepo,"esp32,mqtt,aws-iot",embedded-firmware-architecture.md,,
|
||||
embedded-arduino-iot,Arduino IoT Cloud,embedded,"C,C++",iot-cloud,monorepo,"arduino,iot,mqtt,cloud",embedded-firmware-architecture.md,,
|
||||
embedded-particle,Particle IoT,embedded,"C,C++",iot-cloud,monorepo,"particle,iot,cellular,cloud",embedded-firmware-architecture.md,,
|
||||
library-npm-ts,NPM Library (TypeScript),library,TypeScript,library,monorepo,"npm,package,tsup",library-package-architecture.md,,
|
||||
library-npm-js,NPM Library (JavaScript),library,JavaScript,library,monorepo,"npm,package,rollup",library-package-architecture.md,,
|
||||
library-pypi,PyPI Package,library,Python,library,monorepo,"pypi,wheel,setuptools",library-package-architecture.md,,
|
||||
library-cargo,Cargo Crate (Rust),library,Rust,library,monorepo,"cargo,crate,docs-rs",library-package-architecture.md,,
|
||||
library-go-modules,Go Module,library,Go,library,monorepo,"go,pkg-go-dev",library-package-architecture.md,,
|
||||
library-maven-java,Maven Library (Java),library,Java,library,monorepo,"maven,jar,central",library-package-architecture.md,,
|
||||
library-nuget-csharp,NuGet Package (C#),library,C#,library,monorepo,"nuget,dotnet,package",library-package-architecture.md,,
|
||||
library-cpp-cmake,C++ Library (CMake),library,C++,library,monorepo,"cpp,conan,vcpkg",library-package-architecture.md,,
|
||||
library-c-shared,C Shared Library,library,C,library,monorepo,"c,header-only",library-package-architecture.md,,
|
||||
cli-node-simple,CLI Tool (Node.js),cli,TypeScript,cli,monorepo,"cli,commander,yargs",cli-tool-architecture.md,,
|
||||
cli-python-simple,CLI Tool (Python),cli,Python,cli,monorepo,"cli,click,argparse",cli-tool-architecture.md,,
|
||||
cli-go-simple,CLI Tool (Go),cli,Go,cli,monorepo,"cli,cobra,single-binary",cli-tool-architecture.md,,
|
||||
cli-rust-simple,CLI Tool (Rust),cli,Rust,cli,monorepo,"cli,clap,single-binary",cli-tool-architecture.md,,
|
||||
cli-node-interactive,Interactive CLI (Node.js),cli,TypeScript,cli-interactive,monorepo,"cli,ink,blessed",cli-tool-architecture.md,,
|
||||
cli-python-interactive,Interactive CLI (Python),cli,Python,cli-interactive,monorepo,"cli,rich,textual,prompt-toolkit",cli-tool-architecture.md,,
|
||||
cli-rust-interactive,Interactive TUI (Rust),cli,Rust,cli-interactive,monorepo,"cli,ratatui,crossterm",cli-tool-architecture.md,,
|
||||
cli-go-interactive,Interactive TUI (Go),cli,Go,cli-interactive,monorepo,"cli,bubbletea,charm",cli-tool-architecture.md,,
|
||||
cli-node-daemon,CLI with Daemon (Node.js),cli,TypeScript,cli-daemon,monorepo,"cli,service,systemd",cli-tool-architecture.md,,
|
||||
cli-python-daemon,CLI with Daemon (Python),cli,Python,cli-daemon,monorepo,"cli,service,systemd",cli-tool-architecture.md,,
|
||||
cli-go-daemon,CLI with Service (Go),cli,Go,cli-daemon,monorepo,"cli,service,systemd",cli-tool-architecture.md,,
|
||||
desktop-electron,Electron App,desktop,TypeScript,desktop,monorepo,"electron,cross-platform,chromium",desktop-app-architecture.md,,
|
||||
desktop-tauri,Tauri App,desktop,"TypeScript,Rust",desktop,monorepo,"tauri,rust,webview,lightweight",desktop-app-architecture.md,,
|
||||
desktop-wails,Wails App (Go),desktop,"TypeScript,Go",desktop,monorepo,"wails,go,webview",desktop-app-architecture.md,,
|
||||
desktop-qt-cpp,Qt Desktop (C++),desktop,C++,desktop,monorepo,"qt,cpp,native,cross-platform",desktop-app-architecture.md,,
|
||||
desktop-qt-python,Qt Desktop (Python),desktop,Python,desktop,monorepo,"qt,python,pyside6",desktop-app-architecture.md,,
|
||||
desktop-dotnet-wpf,WPF Desktop (.NET),desktop,C#,desktop,monorepo,"dotnet,windows,xaml",desktop-app-architecture.md,,
|
||||
desktop-dotnet-maui,MAUI Desktop (.NET),desktop,C#,desktop,monorepo,"dotnet,cross-platform,xaml",desktop-app-architecture.md,,
|
||||
desktop-swiftui-macos,SwiftUI macOS,desktop,Swift,desktop,monorepo,"swiftui,macos,native,declarative",desktop-app-architecture.md,,
|
||||
desktop-gtk,GTK Desktop,desktop,"C,Python",desktop,monorepo,"gtk,linux,gnome",desktop-app-architecture.md,,
|
||||
desktop-tkinter,Tkinter Desktop (Python),desktop,Python,desktop,monorepo,"tkinter,simple,cross-platform",desktop-app-architecture.md,,
|
||||
data-etl-python,Python ETL,data,Python,pipeline,monorepo,"etl,pandas,dask",data-pipeline-architecture.md,,
|
||||
data-etl-spark,Spark ETL,data,"Scala,Python",pipeline,monorepo,"etl,spark,big-data,pyspark",data-pipeline-architecture.md,,
|
||||
data-dbt,dbt Transformations,data,SQL,pipeline,monorepo,"etl,dbt,sql,analytics-engineering",data-pipeline-architecture.md,,
|
||||
data-ml-training,ML Training Pipeline,data,Python,pipeline,monorepo,"ml,mlflow,pytorch,tensorflow",data-pipeline-architecture.md,,
|
||||
data-ml-inference,ML Inference Service,data,Python,pipeline,monorepo,"ml,serving,triton,torchserve",data-pipeline-architecture.md,,
|
||||
data-kubeflow,Kubeflow Pipelines,data,Python,pipeline,monorepo,"ml,kubeflow,kubernetes,pipelines",data-pipeline-architecture.md,,
|
||||
data-analytics-superset,Superset Analytics,data,Python,analytics,monorepo,"analytics,superset,dashboards,bi",data-pipeline-architecture.md,,
|
||||
data-analytics-metabase,Metabase Analytics,data,any,analytics,monorepo,"analytics,metabase,dashboards,bi",data-pipeline-architecture.md,,
|
||||
data-looker,Looker/LookML,data,LookML,analytics,monorepo,"analytics,looker,bi,enterprise",data-pipeline-architecture.md,,
|
||||
data-warehouse-snowflake,Snowflake Warehouse,data,SQL,warehouse,monorepo,"warehouse,snowflake,cloud,dbt",data-pipeline-architecture.md,,
|
||||
data-warehouse-bigquery,BigQuery Warehouse,data,SQL,warehouse,monorepo,"warehouse,bigquery,gcp,dbt",data-pipeline-architecture.md,,
|
||||
data-warehouse-redshift,Redshift Warehouse,data,SQL,warehouse,monorepo,"warehouse,redshift,aws,dbt",data-pipeline-architecture.md,,
|
||||
data-streaming-kafka,Kafka Streaming,data,"Java,Scala",streaming,monorepo,"streaming,kafka,confluent,real-time",data-pipeline-architecture.md,,
|
||||
data-streaming-flink,Flink Streaming,data,"Java,Python",streaming,monorepo,"streaming,flink,stateful,real-time",data-pipeline-architecture.md,,
|
||||
data-streaming-spark,Spark Streaming,data,"Scala,Python",streaming,monorepo,"streaming,spark,micro-batch",data-pipeline-architecture.md,,
|
||||
extension-chrome,Chrome Extension,extension,TypeScript,extension,monorepo,"browser,extension,manifest-v3",desktop-app-architecture.md,,
|
||||
extension-firefox,Firefox Extension,extension,TypeScript,extension,monorepo,"browser,webextensions,manifest-v2",desktop-app-architecture.md,,
|
||||
extension-safari,Safari Extension,extension,Swift,extension,monorepo,"browser,safari,xcode,app-extension",desktop-app-architecture.md,,
|
||||
extension-vscode,VS Code Extension,extension,TypeScript,extension,monorepo,"vscode,ide,language-server",desktop-app-architecture.md,,
|
||||
extension-intellij,IntelliJ Plugin,extension,Kotlin,extension,monorepo,"jetbrains,plugin,ide",desktop-app-architecture.md,,
|
||||
extension-sublime,Sublime Text Plugin,extension,Python,extension,monorepo,"sublime,editor",desktop-app-architecture.md,,
|
||||
infra-terraform,Terraform IaC,infra,HCL,iac,monorepo,"terraform,iac,cloud,multi-cloud",infrastructure-architecture.md,,
|
||||
infra-pulumi,Pulumi IaC,infra,"TypeScript,Python,Go",iac,monorepo,"pulumi,iac,cloud,programming",infrastructure-architecture.md,,
|
||||
infra-cdk-aws,AWS CDK,infra,TypeScript,iac,monorepo,"cdk,iac,cloudformation",infrastructure-architecture.md,,
|
||||
infra-cdktf,CDK for Terraform,infra,TypeScript,iac,monorepo,"cdktf,iac,typescript",infrastructure-architecture.md,,
|
||||
infra-k8s-operator,Kubernetes Operator,infra,Go,k8s-operator,monorepo,"kubernetes,operator,controller,crd",infrastructure-architecture.md,,
|
||||
infra-helm-charts,Helm Charts,infra,YAML,k8s-package,monorepo,"kubernetes,helm,package,templating",infrastructure-architecture.md,,
|
||||
infra-ansible,Ansible Playbooks,infra,YAML,config-mgmt,monorepo,"ansible,automation,idempotent",infrastructure-architecture.md,,
|
||||
infra-chef,Chef Cookbooks,infra,Ruby,config-mgmt,monorepo,"chef,automation,ruby-dsl",infrastructure-architecture.md,,
|
||||
infra-puppet,Puppet Manifests,infra,Puppet,config-mgmt,monorepo,"puppet,automation,declarative",infrastructure-architecture.md,,
|
||||
infra-saltstack,SaltStack,infra,YAML,config-mgmt,monorepo,"salt,automation,python",infrastructure-architecture.md,,
|
||||
|
@@ -1,66 +0,0 @@
|
||||
# {{TITLE}} Architecture Document
|
||||
|
||||
**Project:** {{project_name}}
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
## 1. Technology Stack and Decisions
|
||||
|
||||
### 1.1 Technology and Library Decision Table
|
||||
|
||||
{{technology_table}}
|
||||
|
||||
## 2. Architecture Overview
|
||||
|
||||
{{architecture_overview}}
|
||||
|
||||
## 3. Data Architecture
|
||||
|
||||
{{data_architecture}}
|
||||
|
||||
## 4. Component and Integration Overview
|
||||
|
||||
{{component_overview}}
|
||||
|
||||
## 5. Architecture Decision Records
|
||||
|
||||
{{architecture_decisions}}
|
||||
|
||||
## 6. Implementation Guidance
|
||||
|
||||
{{implementation_guidance}}
|
||||
|
||||
## 7. Proposed Source Tree
|
||||
|
||||
```
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## 8. Testing Strategy
|
||||
|
||||
{{testing_strategy}}
|
||||
{{testing_specialist_section}}
|
||||
|
||||
## 9. Deployment and Operations
|
||||
|
||||
{{deployment_operations}}
|
||||
{{devops_specialist_section}}
|
||||
|
||||
## 10. Security
|
||||
|
||||
{{security}}
|
||||
{{security_specialist_section}}
|
||||
|
||||
---
|
||||
|
||||
## Specialist Sections
|
||||
|
||||
{{specialist_sections_summary}}
|
||||
|
||||
---
|
||||
|
||||
_Generated using BMad Method Solution Architecture workflow_
|
||||
@@ -1,277 +0,0 @@
|
||||
# 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_
|
||||
@@ -1,62 +0,0 @@
|
||||
# Solution Architecture Workflow Configuration
|
||||
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"
|
||||
|
||||
# Critical variables
|
||||
config_source: "{project-root}/bmad/bmm/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
date: system-generated
|
||||
|
||||
# Input requirements
|
||||
inputs:
|
||||
- name: prd_path
|
||||
description: "Path to PRD document"
|
||||
default: "{output_folder}/PRD.md"
|
||||
required: true
|
||||
- name: project_workflow_analysis_path
|
||||
description: "Path to project-workflow-analysis.md from plan-project workflow"
|
||||
default: "{output_folder}/project-workflow-analysis.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"
|
||||
- name: epic_alignment_matrix
|
||||
description: "Epic-to-component mapping (from cohesion check)"
|
||||
- name: tech_specs
|
||||
description: "Per-epic tech spec documents"
|
||||
|
||||
# Workflow variables (set during execution)
|
||||
variables:
|
||||
user_skill_level: "intermediate"
|
||||
project_type: ""
|
||||
architecture_style: ""
|
||||
repo_strategy: ""
|
||||
template_sections: []
|
||||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/bmad/bmm/workflows/3-solutioning"
|
||||
adr_template: "{installed_path}/ADR-template.md"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
validation: "{installed_path}/checklist.md"
|
||||
|
||||
# Reference data files
|
||||
architecture_registry: "{installed_path}/templates/registry.csv"
|
||||
project_types_questions: "{installed_path}/project-types"
|
||||
|
||||
# Default output location
|
||||
default_output_file: "{output_folder}/solution-architecture.md"
|
||||
|
||||
# Additional workflow dependencies
|
||||
tech_spec_workflow: "{project-root}/bmad/bmm/workflows/3-solutioning/tech-spec/workflow.yaml"
|
||||
Reference in New Issue
Block a user