siesa-agents 2.1.26 → 2.1.28
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +8 -0
- package/bin/install.js +3 -1
- package/bmad-core/agents/analyst.md +1 -1
- package/bmad-core/agents/architect.md +22 -2
- package/bmad-core/agents/backend-agent.md +74 -86
- package/bmad-core/agents/bmad-master.md +2 -2
- package/bmad-core/agents/bmad-orchestrator.md +2 -2
- package/bmad-core/agents/dev.md +1 -1
- package/bmad-core/agents/frontend-agent.md +4 -4
- package/bmad-core/agents/pm.md +4 -1
- package/bmad-core/agents/po.md +4 -1
- package/bmad-core/agents/qa.md +1 -1
- package/bmad-core/agents/sm.md +1 -1
- package/bmad-core/agents/ux-expert.md +1 -1
- package/bmad-core/checklists/architect-checklist.md +2 -0
- package/bmad-core/checklists/backend-checklist.md +10 -6
- package/bmad-core/data/architecture-patterns.md +279 -125
- package/bmad-core/data/backend-standards.md +718 -278
- package/bmad-core/data/bmad-kb.md +1 -1
- package/bmad-core/data/frontend-standards.md +1 -1
- package/bmad-core/data/technical-preferences-ux.md +1 -1
- package/bmad-core/data/technical-preferences.md +106 -1
- package/bmad-core/data/technology-stack.md +155 -1
- package/bmad-core/tasks/apply-qa-fixes.md +4 -4
- package/bmad-core/tasks/create-doc.md +59 -0
- package/bmad-core/tasks/create-entity.md +3 -3
- package/bmad-core/tasks/create-next-story.md +1 -1
- package/bmad-core/tasks/create-service.md +3 -3
- package/bmad-core/tasks/nfr-assess.md +3 -3
- package/bmad-core/tasks/qa-gate.md +2 -2
- package/bmad-core/tasks/review-story.md +1 -1
- package/bmad-core/tasks/scaffold-backend.md +13 -9
- package/bmad-core/tasks/scaffold-frontend.md +2 -2
- package/bmad-core/templates/architecture-tmpl.yaml +2 -2
- package/bmad-core/templates/front-end-architecture-tmpl.yaml +1 -1
- package/bmad-core/templates/story-tmpl.yaml +1 -1
- package/bmad-core/user-guide.md +1 -1
- package/claude/commands/BMad/agents/analyst.md +1 -1
- package/claude/commands/BMad/agents/architect.md +21 -1
- package/claude/commands/BMad/agents/backend.md +86 -99
- package/claude/commands/BMad/agents/bmad-master.md +2 -2
- package/claude/commands/BMad/agents/bmad-orchestrator.md +2 -2
- package/claude/commands/BMad/agents/dev.md +1 -1
- package/claude/commands/BMad/agents/frontend.md +4 -4
- package/claude/commands/BMad/agents/pm.md +4 -1
- package/claude/commands/BMad/agents/po.md +4 -1
- package/claude/commands/BMad/agents/qa.md +1 -1
- package/claude/commands/BMad/agents/sm.md +1 -1
- package/claude/commands/BMad/agents/ux-expert.md +1 -1
- package/claude/commands/BMad/tasks/apply-qa-fixes.md +4 -4
- package/claude/commands/BMad/tasks/create-doc.md +48 -0
- package/claude/commands/BMad/tasks/create-next-story.md +1 -1
- package/claude/commands/BMad/tasks/nfr-assess.md +3 -3
- package/claude/commands/BMad/tasks/qa-gate.md +2 -2
- package/claude/commands/BMad/tasks/review-story.md +1 -1
- package/claude/hooks/file-restriction-hook.py +51 -0
- package/claude/hooks/track-agent.py +67 -0
- package/claude/settings.local.json +55 -2
- package/github/chatmodes/architect.chatmode.md +7 -1
- package/github/chatmodes/backend.chatmode.md +133 -109
- package/github/chatmodes/dev.chatmode.md +12 -4
- package/github/chatmodes/frontend.chatmode.md +3 -3
- package/github/chatmodes/qa.chatmode.md +9 -3
- package/kiro/steering/agent-detection.md +16 -16
- package/package.json +1 -1
|
@@ -181,7 +181,7 @@ npx bmad-method install
|
|
|
181
181
|
|
|
182
182
|
## Core Configuration (core-config.yaml)
|
|
183
183
|
|
|
184
|
-
**New in V4**: The
|
|
184
|
+
**New in V4**: The `.bmad-core/core-config.yaml` file is a critical innovation that enables BMad to work seamlessly with any project structure, providing maximum flexibility and backwards compatibility.
|
|
185
185
|
|
|
186
186
|
### What is core-config.yaml?
|
|
187
187
|
|
|
@@ -23,7 +23,7 @@
|
|
|
23
23
|
- **Shadcn/ui + Radix UI**: Component library foundation
|
|
24
24
|
|
|
25
25
|
### Framework Selection Rules
|
|
26
|
-
- **Default**: Always use Next.js
|
|
26
|
+
- **Default**: Always use Next.js 16+ with App Router
|
|
27
27
|
- **Exception**: Only use pure React + Vite when user specifically requests offline-first functionality
|
|
28
28
|
- **Reasoning**: Next.js provides better DX, built-in optimization, and easier deployment while maintaining PWA capabilities
|
|
29
29
|
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
Based on Frontend Development Standards and Clean Architecture Implementation
|
|
5
5
|
|
|
6
6
|
### Technology Stack
|
|
7
|
-
- **Framework**: Next.js
|
|
7
|
+
- **Framework**: Next.js 16+ with App Router
|
|
8
8
|
- **Language**: TypeScript (strict mode)
|
|
9
9
|
- **Styling**: TailwindCSS + Shadcn/ui + Radix UI
|
|
10
10
|
- **State Management**: Zustand
|
|
@@ -2,4 +2,109 @@
|
|
|
2
2
|
|
|
3
3
|
# User-Defined Preferred Patterns and Preferences
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
## Backend Preferences (.NET 10)
|
|
6
|
+
|
|
7
|
+
### Framework & Language
|
|
8
|
+
- **MANDATORY**: .NET 10 with C# Minimal API
|
|
9
|
+
- **API Style**: Minimal API (lightweight, modern approach)
|
|
10
|
+
- **NO** MVC Controllers - Use Minimal API endpoints only
|
|
11
|
+
|
|
12
|
+
### Database
|
|
13
|
+
- **MANDATORY**: PostgreSQL for all microservices
|
|
14
|
+
- **ORM**: Entity Framework Core 10 (primary - matches .NET 10 version)
|
|
15
|
+
- **LINQ Extensions**: linq2db, DynamicLinq, LinqKit for advanced queries
|
|
16
|
+
- **Primary Keys**: UUID (Guid) for ALL entities - NO exceptions
|
|
17
|
+
- **Migrations**: EF Core 10 Migrations for schema version control
|
|
18
|
+
- **DateTime Types**:
|
|
19
|
+
- **MANDATORY**: Use `DateTimeOffset` for ALL timestamp fields (CreatedAt, UpdatedAt, etc.)
|
|
20
|
+
- **FORBIDDEN**: NEVER use `DateTime` for timestamp fields in entities or DTOs
|
|
21
|
+
- **Rationale**: PostgreSQL uses TIMESTAMP WITH TIME ZONE which maps to DateTimeOffset
|
|
22
|
+
- **Date Only**: Use `DateOnly` for date-only fields (BirthDate, ExpenseDate)
|
|
23
|
+
- **Time Only**: Use `TimeOnly` for time-only fields (OpeningTime, ClosingTime)
|
|
24
|
+
|
|
25
|
+
### Validation
|
|
26
|
+
- **MANDATORY**: FluentValidation for all DTOs and commands
|
|
27
|
+
|
|
28
|
+
### API Documentation
|
|
29
|
+
- **MANDATORY**: Scalar for API documentation
|
|
30
|
+
- **FORBIDDEN**: Do NOT use Swagger/Swashbuckle
|
|
31
|
+
|
|
32
|
+
### Architecture
|
|
33
|
+
- **Pattern**: Clean Architecture + DDD
|
|
34
|
+
- **Microservices**: Each service with independent PostgreSQL database
|
|
35
|
+
- **No Shared Databases**: Services communicate via APIs or events
|
|
36
|
+
- **CQRS**: Command/Query separation in Application layer
|
|
37
|
+
|
|
38
|
+
### Testing
|
|
39
|
+
- **Framework**: xUnit (MANDATORY)
|
|
40
|
+
- **TDD**: Test-Driven Development approach required
|
|
41
|
+
- **Unit Tests**: EF Core InMemory for fast tests
|
|
42
|
+
- **Integration Tests**: PostgreSQL Test Containers for real scenarios
|
|
43
|
+
- **Coverage**: Aim for >80% code coverage
|
|
44
|
+
|
|
45
|
+
### PDF Generation
|
|
46
|
+
- **Library**: QuestPDF for document generation
|
|
47
|
+
- **Testing**: Snapshot/output validation for PDF tests
|
|
48
|
+
|
|
49
|
+
### Code Quality
|
|
50
|
+
- **Analyzers**: Enable .NET code analyzers
|
|
51
|
+
- **Format**: Use `dotnet format` for code style
|
|
52
|
+
- **EditorConfig**: Enforce coding standards
|
|
53
|
+
|
|
54
|
+
### Localization
|
|
55
|
+
- **i18n/l10n**: Built-in .NET localization support
|
|
56
|
+
- **Resources**: Use .resx files for translations
|
|
57
|
+
|
|
58
|
+
### Development Environment
|
|
59
|
+
- **Local Development**: Direct execution with `dotnet run`
|
|
60
|
+
- **PostgreSQL Local**: Use local PostgreSQL instance or cloud dev DB
|
|
61
|
+
|
|
62
|
+
### Production Deployment
|
|
63
|
+
- **Containerization**: Docker for production deployments
|
|
64
|
+
- **Orchestration**: Kubernetes or Docker Compose
|
|
65
|
+
- **Each Service**: Independent container with health checks
|
|
66
|
+
|
|
67
|
+
## Frontend Preferences (Next.js 16)
|
|
68
|
+
|
|
69
|
+
### Framework
|
|
70
|
+
- **Default**: Next.js 16 with TypeScript and App Router
|
|
71
|
+
- **Exception**: Pure React + Vite only for offline-first scenarios
|
|
72
|
+
|
|
73
|
+
### State Management
|
|
74
|
+
- **Zustand**: Preferred for global state
|
|
75
|
+
|
|
76
|
+
### UI Components
|
|
77
|
+
- **shadcn/ui**: Component library
|
|
78
|
+
- **Radix UI**: Primitives
|
|
79
|
+
- **TailwindCSS v4**: Styling
|
|
80
|
+
|
|
81
|
+
### Testing
|
|
82
|
+
- **Vitest**: Test runner
|
|
83
|
+
- **React Testing Library**: Component testing
|
|
84
|
+
- **MSW**: API mocking
|
|
85
|
+
|
|
86
|
+
### Validation
|
|
87
|
+
- **Zod**: Schema validation
|
|
88
|
+
- **React Hook Form**: Form management
|
|
89
|
+
|
|
90
|
+
## Cross-Stack Preferences
|
|
91
|
+
|
|
92
|
+
### Communication
|
|
93
|
+
- **REST API**: Primary communication protocol
|
|
94
|
+
- **gRPC**: For high-performance inter-service calls
|
|
95
|
+
- **Message Broker**: RabbitMQ or Azure Service Bus for async events
|
|
96
|
+
|
|
97
|
+
### Security
|
|
98
|
+
- **Authentication**: JWT tokens
|
|
99
|
+
- **Authorization**: Role-based access control
|
|
100
|
+
- **HTTPS**: Mandatory for all environments
|
|
101
|
+
|
|
102
|
+
### Logging & Monitoring
|
|
103
|
+
- **Structured Logging**: Use ILogger in .NET
|
|
104
|
+
- **Correlation IDs**: Track requests across services
|
|
105
|
+
- **Health Checks**: Implement health endpoints for all services
|
|
106
|
+
|
|
107
|
+
### Error Handling
|
|
108
|
+
- **Problem Details**: RFC 7807 for error responses
|
|
109
|
+
- **Global Exception Handler**: Middleware for centralized error handling
|
|
110
|
+
- **Validation Errors**: Return 400 with detailed validation messages
|
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
## Frontend Stack
|
|
4
4
|
|
|
5
5
|
### Framework
|
|
6
|
-
- **Next.js
|
|
6
|
+
- **Next.js 16** with TypeScript (App Router)
|
|
7
7
|
- Default framework unless explicitly told otherwise
|
|
8
8
|
- Built-in Turbopack/Webpack for building
|
|
9
9
|
- File-based routing with App Router
|
|
@@ -79,3 +79,157 @@ Start with user needs and work backward to implementation
|
|
|
79
79
|
|
|
80
80
|
### MCP Shadcn Available
|
|
81
81
|
Use MCP to install Shadcn components instead of creating manually
|
|
82
|
+
|
|
83
|
+
## Backend Stack
|
|
84
|
+
|
|
85
|
+
### Core Framework & Language
|
|
86
|
+
- **.NET 10**
|
|
87
|
+
- **C# Minimal API** - Lightweight and modern API approach
|
|
88
|
+
- **Entity Framework Core 10** - ORM for data access (matches .NET 10 version)
|
|
89
|
+
- **FluentValidation** - Validation for models and DTOs
|
|
90
|
+
- **linq2db** - Ultra-lightweight, high-performance ORM for complex optimized queries
|
|
91
|
+
- **DynamicLinq** - Dynamic query construction from strings (runtime filters)
|
|
92
|
+
- **LinqKit** - Composable and reusable LINQ expressions with type safety
|
|
93
|
+
|
|
94
|
+
### ORM Strategy & When to Use Each Tool
|
|
95
|
+
|
|
96
|
+
#### Entity Framework Core 10 (Primary ORM)
|
|
97
|
+
**Use for:**
|
|
98
|
+
- Standard CRUD operations
|
|
99
|
+
- DDD entities with tracking (Aggregate Roots, Domain Events)
|
|
100
|
+
- Simple to moderate queries
|
|
101
|
+
- Queries that participate in aggregate lifecycle
|
|
102
|
+
- Navigation properties and relationships
|
|
103
|
+
- Change tracking scenarios
|
|
104
|
+
|
|
105
|
+
#### linq2db
|
|
106
|
+
**Ultra-lightweight ORM for maximum performance and SQL control**
|
|
107
|
+
|
|
108
|
+
✔ **Use when:**
|
|
109
|
+
- Need highly optimized complex queries
|
|
110
|
+
- Advanced subqueries and complex projections
|
|
111
|
+
- Multiple joins with dynamic conditions
|
|
112
|
+
- Queries that EF Core cannot translate efficiently
|
|
113
|
+
- Endpoints require extreme performance:
|
|
114
|
+
- Dashboards
|
|
115
|
+
- Analytics
|
|
116
|
+
- Fast transactional reports
|
|
117
|
+
- High data volumes
|
|
118
|
+
- Microservice requires pure queries without tracking (linq2db operates naturally without tracking → faster)
|
|
119
|
+
- EF Core generates inefficient SQL and you need alternatives without changing stack
|
|
120
|
+
- Want SQL nearly as efficient as hand-written, but without explicit SQL
|
|
121
|
+
|
|
122
|
+
🚫 **Do NOT use when:**
|
|
123
|
+
- Need complete DDD entities (aggregate roots, tracking, events)
|
|
124
|
+
- Query participates in aggregate lifecycle
|
|
125
|
+
- Only need simple filters or trivial pagination
|
|
126
|
+
|
|
127
|
+
#### DynamicLinq
|
|
128
|
+
**Dynamic query generation from strings for runtime filters**
|
|
129
|
+
|
|
130
|
+
✔ **Use when:**
|
|
131
|
+
- Microservice offers dynamic filter system:
|
|
132
|
+
- Example: `?filter=Age > 30 AND Country == "CO"`
|
|
133
|
+
- Example: `?sort=Name desc`
|
|
134
|
+
- Building simplified OData-style API without using OData
|
|
135
|
+
- Generic queries over tables
|
|
136
|
+
- Variable column searches
|
|
137
|
+
- Data explorers or configurable grids
|
|
138
|
+
- Want to avoid manually generating Expression Trees (DynamicLinq is much simpler)
|
|
139
|
+
|
|
140
|
+
🚫 **Do NOT use when:**
|
|
141
|
+
- Filters are fully controlled in code
|
|
142
|
+
- Don't want to interpret expressions at runtime
|
|
143
|
+
- Require strict security (DynamicLinq requires sanitization)
|
|
144
|
+
- Need maximum performance (use LinqKit or linq2db instead)
|
|
145
|
+
|
|
146
|
+
#### LinqKit
|
|
147
|
+
**Composable dynamic predicates with type safety**
|
|
148
|
+
|
|
149
|
+
✔ **Use when:**
|
|
150
|
+
- Have complex business rules in queries
|
|
151
|
+
- Composable predicates example:
|
|
152
|
+
```csharp
|
|
153
|
+
IsActive
|
|
154
|
+
RequiresApproval
|
|
155
|
+
BelongsToOrganization(user.OrgId)
|
|
156
|
+
```
|
|
157
|
+
- Want dynamic filters with type safety (no strings → expressions)
|
|
158
|
+
- Combine multiple expressions in a single `Where()`:
|
|
159
|
+
- Especially useful in DDD repositories with:
|
|
160
|
+
- Multiple criteria
|
|
161
|
+
- Conditional searches
|
|
162
|
+
- Reusable queries
|
|
163
|
+
- Need EF Core to translate the resulting expression (LinqKit is 100% compatible with EF Core)
|
|
164
|
+
- Want to enhance EF Core when it fails to compose complex expressions
|
|
165
|
+
|
|
166
|
+
🚫 **Do NOT use when:**
|
|
167
|
+
- Filters are extremely simple
|
|
168
|
+
- Query is highly dynamic and text-based (use DynamicLinq)
|
|
169
|
+
- Need maximum performance (use linq2db)
|
|
170
|
+
|
|
171
|
+
### Architecture & Design Patterns
|
|
172
|
+
- **TDD (Test-Driven Development)** - Test-driven development approach
|
|
173
|
+
- **DDD (Domain-Driven Design)** - Domain-oriented design
|
|
174
|
+
- **Clean Architecture** - Clean architecture with layer separation
|
|
175
|
+
- **Microservices** - Distributed services architecture
|
|
176
|
+
- **REST API** - Primary communication protocol
|
|
177
|
+
|
|
178
|
+
### Database & Data Management
|
|
179
|
+
- **PostgreSQL** - Primary relational database (mandatory)
|
|
180
|
+
- **Database per Microservice** - Each microservice has its own isolated database
|
|
181
|
+
- **Primary Keys UUID** - Universal unique identifiers for all entities
|
|
182
|
+
- **EF Core 10 Migrations** - Entity Framework migrations package for schema version control
|
|
183
|
+
|
|
184
|
+
### Testing
|
|
185
|
+
- **xUnit** - Unit and integration testing framework
|
|
186
|
+
- **EF Core 10 InMemory** - In-memory database for fast tests
|
|
187
|
+
- **PostgreSQL Test Containers** - PostgreSQL containers for real integration tests
|
|
188
|
+
|
|
189
|
+
### Additional Libraries
|
|
190
|
+
- **QuestPDF** - PDF document generation
|
|
191
|
+
- **DynamicLinq** - Dynamic LINQ query construction
|
|
192
|
+
- **LinqKit** - LINQ expression composition
|
|
193
|
+
|
|
194
|
+
### API Documentation
|
|
195
|
+
- **Scalar** - Modern API documentation (DO NOT use Swagger)
|
|
196
|
+
|
|
197
|
+
### Infrastructure & DevOps
|
|
198
|
+
- **Docker Ready** - Containerized applications ready for deployment (production only)
|
|
199
|
+
- **Local Development** - Without Docker, direct execution with dotnet CLI
|
|
200
|
+
- **Multiculture** - Support for internationalization (i18n) and localization (l10n)
|
|
201
|
+
|
|
202
|
+
## Backend Core Principles
|
|
203
|
+
|
|
204
|
+
### Clean Architecture First
|
|
205
|
+
Strict separation of:
|
|
206
|
+
- Domain layer (Entities, Value Objects, Aggregates, Domain Services)
|
|
207
|
+
- Application layer (Commands, Queries, DTOs, Interfaces)
|
|
208
|
+
- Infrastructure layer (Repositories, EF Core, External Services)
|
|
209
|
+
- Presentation layer (Minimal API Endpoints)
|
|
210
|
+
|
|
211
|
+
### Domain-Driven Design
|
|
212
|
+
Business logic drives architecture decisions
|
|
213
|
+
|
|
214
|
+
### Test-Driven Development
|
|
215
|
+
- Write tests before or alongside implementation
|
|
216
|
+
- xUnit for all backend tests
|
|
217
|
+
- High test coverage requirement
|
|
218
|
+
|
|
219
|
+
### Microservices Isolation
|
|
220
|
+
- Each service is independent
|
|
221
|
+
- Own PostgreSQL database per service
|
|
222
|
+
- No shared databases between services
|
|
223
|
+
|
|
224
|
+
### UUID Primary Keys
|
|
225
|
+
All entities must use UUIDs (Guid in C#) as primary keys for distributed system compatibility
|
|
226
|
+
|
|
227
|
+
### Type Safety
|
|
228
|
+
Leverage C# strong typing for compile-time safety
|
|
229
|
+
|
|
230
|
+
### Security by Design
|
|
231
|
+
Implement security at every layer
|
|
232
|
+
|
|
233
|
+
### Docker for Production Only
|
|
234
|
+
- Development: dotnet run locally
|
|
235
|
+
- Production: Docker containers
|
|
@@ -16,8 +16,8 @@ Implement fixes based on QA results (gate and assessments) for a specific story.
|
|
|
16
16
|
```yaml
|
|
17
17
|
required:
|
|
18
18
|
- story_id: '{epic}.{story}' # e.g., "2.2"
|
|
19
|
-
- qa_root: from
|
|
20
|
-
- story_root: from
|
|
19
|
+
- qa_root: from `.bmad-core/core-config.yaml` key `qa.qaLocation` (e.g., `docs/project/qa`)
|
|
20
|
+
- story_root: from `.bmad-core/core-config.yaml` key `devStoryLocation` (e.g., `docs/project/stories`)
|
|
21
21
|
|
|
22
22
|
optional:
|
|
23
23
|
- story_title: '{title}' # derive from story H1 if missing
|
|
@@ -45,7 +45,7 @@ optional:
|
|
|
45
45
|
|
|
46
46
|
### 0) Load Core Config & Locate Story
|
|
47
47
|
|
|
48
|
-
- Read
|
|
48
|
+
- Read `.bmad-core/core-config.yaml` and resolve `qa_root` and `story_root`
|
|
49
49
|
- Locate story file in `{story_root}/{epic}.{story}.*.md`
|
|
50
50
|
- HALT if missing and ask for correct story id/path
|
|
51
51
|
|
|
@@ -113,7 +113,7 @@ Status Rule:
|
|
|
113
113
|
|
|
114
114
|
## Blocking Conditions
|
|
115
115
|
|
|
116
|
-
- Missing
|
|
116
|
+
- Missing `.bmad-core/core-config.yaml`
|
|
117
117
|
- Story file not found for `story_id`
|
|
118
118
|
- No QA artifacts found (neither gate nor assessments)
|
|
119
119
|
- HALT and request QA to generate at least a gate file (or proceed only with clear developer-provided fix list)
|
|
@@ -23,6 +23,58 @@ When this task is invoked:
|
|
|
23
23
|
|
|
24
24
|
If a YAML Template has not been provided, list all templates from .bmad-core/templates or ask the user to provide another.
|
|
25
25
|
|
|
26
|
+
## CRITICAL: Title Preservation Rule
|
|
27
|
+
|
|
28
|
+
**MANDATORY REQUIREMENTS FOR ALL SECTION TITLES:**
|
|
29
|
+
|
|
30
|
+
1. **Preserve exact title text** - Copy section titles character-by-character from the YAML template
|
|
31
|
+
2. **NO NUMBERS** - Never add numeric prefixes (1., 2., 3., etc.) to section titles
|
|
32
|
+
3. **ENGLISH ONLY** - Never translate section titles to other languages
|
|
33
|
+
4. **NO MODIFICATIONS** - Do not rephrase, reword, or alter section titles in any way
|
|
34
|
+
5. **Template is the source of truth** - The title field in the YAML template is definitive
|
|
35
|
+
|
|
36
|
+
**Examples:**
|
|
37
|
+
- ✅ CORRECT: `# High Level Architecture`
|
|
38
|
+
- ❌ WRONG: `# 2. High Level Architecture`
|
|
39
|
+
- ❌ WRONG: `# Arquitectura de Alto Nivel`
|
|
40
|
+
- ❌ WRONG: `# High-Level Architecture Overview`
|
|
41
|
+
- ❌ WRONG: `# 2. Arquitectura de Alto Nivel`
|
|
42
|
+
|
|
43
|
+
**This rule applies to:**
|
|
44
|
+
- Main section headings (# Title)
|
|
45
|
+
- Subsection headings (## Title)
|
|
46
|
+
- All levels of nested sections
|
|
47
|
+
|
|
48
|
+
**VIOLATION INDICATOR:** If you add numbers, translate, or modify any section title from the template, you have violated this rule.
|
|
49
|
+
|
|
50
|
+
## CRITICAL: Document Language Rule
|
|
51
|
+
|
|
52
|
+
**ALL DOCUMENT CONTENT MUST BE WRITTEN IN ENGLISH:**
|
|
53
|
+
|
|
54
|
+
Regardless of what language you use to converse with the user, ALL documentation artifacts must be written entirely in English.
|
|
55
|
+
|
|
56
|
+
**This applies to:**
|
|
57
|
+
- Section titles (already covered by Title Preservation Rule)
|
|
58
|
+
- Section content and descriptions
|
|
59
|
+
- Examples and code comments
|
|
60
|
+
- Table contents and headers
|
|
61
|
+
- Bullet points and numbered lists
|
|
62
|
+
- Technical specifications
|
|
63
|
+
- User stories and acceptance criteria
|
|
64
|
+
- All other documentation text
|
|
65
|
+
|
|
66
|
+
**Examples:**
|
|
67
|
+
- ✅ CORRECT: "The system must support user authentication"
|
|
68
|
+
- ❌ WRONG: "El sistema debe soportar autenticación de usuarios"
|
|
69
|
+
- ✅ CORRECT: "Epic 1: Foundation and Infrastructure"
|
|
70
|
+
- ❌ WRONG: "Epic 1: Fundación e Infraestructura"
|
|
71
|
+
|
|
72
|
+
**IMPORTANT DISTINCTION:**
|
|
73
|
+
- **Conversation with user:** Use user's preferred language (Spanish, English, etc.)
|
|
74
|
+
- **Document content:** ALWAYS English, no exceptions
|
|
75
|
+
|
|
76
|
+
**VIOLATION INDICATOR:** If any document content (titles, descriptions, examples, etc.) is written in a language other than English, you have violated this rule.
|
|
77
|
+
|
|
26
78
|
## CRITICAL: Mandatory Elicitation Format
|
|
27
79
|
|
|
28
80
|
**When `elicit: true`, this is a HARD STOP requiring user interaction:**
|
|
@@ -56,6 +108,7 @@ If a YAML Template has not been provided, list all templates from .bmad-core/tem
|
|
|
56
108
|
- Process each section one at a time:
|
|
57
109
|
- Skip if condition unmet
|
|
58
110
|
- Check agent permissions (owner/editors)
|
|
111
|
+
- **PRESERVE EXACT TITLE from template (no numbers, no translation)**
|
|
59
112
|
- Draft content using section instruction
|
|
60
113
|
- Present content + detailed rationale
|
|
61
114
|
- **IF elicit: true** → MANDATORY 1-9 options format
|
|
@@ -118,6 +171,7 @@ User can type `#yolo` to toggle to YOLO mode (process sections in batches withou
|
|
|
118
171
|
- Process each sub-batch separately with pauses
|
|
119
172
|
|
|
120
173
|
3. **Process EACH batch:**
|
|
174
|
+
- **PRESERVE EXACT TITLES from template (no numbers, no translation)**
|
|
121
175
|
- Generate content for batch sections
|
|
122
176
|
- Save to file
|
|
123
177
|
- STOP and tell user: "✅ Batch X/Y complete: Sections A-B saved. Type 'continue'."
|
|
@@ -138,6 +192,9 @@ User can type `#yolo` to toggle to YOLO mode (process sections in batches withou
|
|
|
138
192
|
- Ask yes/no questions for elicitation
|
|
139
193
|
- Use any format other than 1-9 numbered options
|
|
140
194
|
- Create new elicitation methods
|
|
195
|
+
- Add numbers to section titles (1., 2., etc.)
|
|
196
|
+
- Translate section titles from English
|
|
197
|
+
- Modify or rephrase section titles from the template
|
|
141
198
|
|
|
142
199
|
**✅ ALWAYS:**
|
|
143
200
|
|
|
@@ -145,3 +202,5 @@ User can type `#yolo` to toggle to YOLO mode (process sections in batches withou
|
|
|
145
202
|
- Select options 2-9 from data/elicitation-methods only
|
|
146
203
|
- Provide detailed rationale explaining decisions
|
|
147
204
|
- End with "Select 1-9 or just type your question/feedback:"
|
|
205
|
+
- Preserve exact section titles from YAML template without modification
|
|
206
|
+
- Keep all section titles in English as defined in template
|
|
@@ -108,8 +108,8 @@ For each domain event:
|
|
|
108
108
|
- Integration with application layer
|
|
109
109
|
- Serialization for external systems
|
|
110
110
|
|
|
111
|
-
### Step 7: Generate
|
|
112
|
-
|
|
111
|
+
### Step 7: Generate Entity Framework Configuration
|
|
112
|
+
Create EF Core entity configuration with:
|
|
113
113
|
- Entity table definition
|
|
114
114
|
- Proper field types and constraints
|
|
115
115
|
- Relationships with other entities
|
|
@@ -129,5 +129,5 @@ Create comprehensive tests:
|
|
|
129
129
|
- Business rules properly enforced
|
|
130
130
|
- Value objects provide type safety
|
|
131
131
|
- Domain events properly implemented
|
|
132
|
-
-
|
|
132
|
+
- Entity Framework Core configuration created
|
|
133
133
|
- Comprehensive test coverage
|
|
@@ -11,7 +11,7 @@ To identify the next logical story based on project progress and epic definition
|
|
|
11
11
|
### 0. Load Core Configuration and Check Workflow
|
|
12
12
|
|
|
13
13
|
- Load `.bmad-core/core-config.yaml` from the project root
|
|
14
|
-
- If the file does not exist, HALT and inform the user: "core-config.yaml not found. This file is required for story creation. You can either: 1) Copy it from GITHUB bmad-core/core-config.yaml and configure it for your project OR 2) Run the BMad installer against your project to upgrade and add the file automatically. Please add and configure core-config.yaml before proceeding."
|
|
14
|
+
- If the file does not exist, HALT and inform the user: "core-config.yaml not found. This file is required for story creation. You can either: 1) Copy it from GITHUB .bmad-core/core-config.yaml and configure it for your project OR 2) Run the BMad installer against your project to upgrade and add the file automatically. Please add and configure core-config.yaml before proceeding."
|
|
15
15
|
- Extract key configurations: `devStoryLocation`, `prd.*`, `architecture.*`, `workflow.*`
|
|
16
16
|
|
|
17
17
|
### 1. Identify Next Story for Preparation
|
|
@@ -65,7 +65,7 @@ src/modules/{service-name}/
|
|
|
65
65
|
│ └── {entity}.domain-service.ts
|
|
66
66
|
└── infrastructure/
|
|
67
67
|
├── repositories/
|
|
68
|
-
│ └──
|
|
68
|
+
│ └── {Entity}Repository.cs
|
|
69
69
|
├── services/
|
|
70
70
|
│ └── {external-service}.adapter.ts
|
|
71
71
|
└── events/
|
|
@@ -89,7 +89,7 @@ For each use case:
|
|
|
89
89
|
- Define repository and service interfaces (ports)
|
|
90
90
|
|
|
91
91
|
### Step 5: Generate Infrastructure Layer
|
|
92
|
-
- Implement
|
|
92
|
+
- Implement Entity Framework Core repository adapters
|
|
93
93
|
- Create external service adapters
|
|
94
94
|
- Implement event handlers
|
|
95
95
|
- Configure dependency injection
|
|
@@ -112,7 +112,7 @@ For each use case:
|
|
|
112
112
|
## Completion Criteria
|
|
113
113
|
- Service follows hexagonal architecture patterns
|
|
114
114
|
- All layers properly separated and tested
|
|
115
|
-
-
|
|
115
|
+
- Entity Framework Core migrations created and applied
|
|
116
116
|
- API endpoints documented in Swagger
|
|
117
117
|
- Tests cover all critical paths
|
|
118
118
|
- Dependencies properly injected
|
|
@@ -9,11 +9,11 @@ Quick NFR validation focused on the core four: security, performance, reliabilit
|
|
|
9
9
|
```yaml
|
|
10
10
|
required:
|
|
11
11
|
- story_id: '{epic}.{story}' # e.g., "1.3"
|
|
12
|
-
- story_path:
|
|
12
|
+
- story_path: `.bmad-core/core-config.yaml` for the `devStoryLocation`
|
|
13
13
|
|
|
14
14
|
optional:
|
|
15
|
-
- architecture_refs:
|
|
16
|
-
- technical_preferences:
|
|
15
|
+
- architecture_refs: `.bmad-core/core-config.yaml` for the `architecture.architectureFile`
|
|
16
|
+
- technical_preferences: `.bmad-core/core-config.yaml` for the `technicalPreferences`
|
|
17
17
|
- acceptance_criteria: From story file
|
|
18
18
|
```
|
|
19
19
|
|
|
@@ -16,7 +16,7 @@ Generate a standalone quality gate file that provides a clear pass/fail decision
|
|
|
16
16
|
|
|
17
17
|
## Gate File Location
|
|
18
18
|
|
|
19
|
-
**ALWAYS** check the
|
|
19
|
+
**ALWAYS** check the `.bmad-core/core-config.yaml` for the `qa.qaLocation/gates`
|
|
20
20
|
|
|
21
21
|
Slug rules:
|
|
22
22
|
|
|
@@ -126,7 +126,7 @@ waiver:
|
|
|
126
126
|
|
|
127
127
|
## Output Requirements
|
|
128
128
|
|
|
129
|
-
1. **ALWAYS** create gate file at: `qa.qaLocation/gates` from
|
|
129
|
+
1. **ALWAYS** create gate file at: `qa.qaLocation/gates` from `.bmad-core/core-config.yaml`
|
|
130
130
|
2. **ALWAYS** append this exact format to story's QA Results section:
|
|
131
131
|
|
|
132
132
|
```text
|
|
@@ -186,7 +186,7 @@ NFR assessment: qa.qaLocation/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
|
|
|
186
186
|
**Template and Directory:**
|
|
187
187
|
|
|
188
188
|
- Render from `../templates/qa-gate-tmpl.yaml`
|
|
189
|
-
- Create directory defined in `qa.qaLocation/gates` (see
|
|
189
|
+
- Create directory defined in `qa.qaLocation/gates` (see `.bmad-core/core-config.yaml`) if missing
|
|
190
190
|
- Save to: `qa.qaLocation/gates/{epic}.{story}-{slug}.yml`
|
|
191
191
|
|
|
192
192
|
Gate file structure:
|
|
@@ -1,9 +1,9 @@
|
|
|
1
1
|
# Scaffold Backend Microservice
|
|
2
2
|
|
|
3
3
|
## Purpose
|
|
4
|
-
Generate complete microservice structure with
|
|
4
|
+
Generate complete microservice structure with Clean Architecture + DDD principles using .NET 10.
|
|
5
5
|
|
|
6
|
-
**CRITICAL**: Always use
|
|
6
|
+
**CRITICAL**: Always use .NET 10 with C# and Entity Framework Core. Follow Clean Architecture patterns strictly. No raw SQL allowed - use EF Core for all database operations.
|
|
7
7
|
|
|
8
8
|
## Task Configuration
|
|
9
9
|
```yaml
|
|
@@ -62,16 +62,20 @@ apps/{service-name}/
|
|
|
62
62
|
│ ├── main.ts
|
|
63
63
|
│ └── app.module.ts
|
|
64
64
|
├── test/
|
|
65
|
-
├──
|
|
66
|
-
│ ├──
|
|
65
|
+
├── Microservicio.Infrastructure/
|
|
66
|
+
│ ├── Persistence/
|
|
67
|
+
│ │ ├── EF/
|
|
68
|
+
│ │ │ ├── DbContexts/
|
|
69
|
+
│ │ │ └── Migrations/
|
|
67
70
|
│ └── migrations/
|
|
68
71
|
└── package.json
|
|
69
72
|
```
|
|
70
73
|
|
|
71
|
-
### Step 3: Setup
|
|
72
|
-
- Initialize
|
|
74
|
+
### Step 3: Setup .NET Configuration
|
|
75
|
+
- Initialize .NET 10 solution and projects
|
|
76
|
+
- Configure C# language features
|
|
73
77
|
- Configure Nx workspace if not exists
|
|
74
|
-
- Setup
|
|
78
|
+
- Setup Entity Framework Core with selected database provider
|
|
75
79
|
- Configure dependency injection container
|
|
76
80
|
- Setup validation with class-validator
|
|
77
81
|
- Configure Swagger/OpenAPI documentation
|
|
@@ -83,7 +87,7 @@ For each bounded context:
|
|
|
83
87
|
- Generate base domain entities with DDD patterns
|
|
84
88
|
- Create application ports (interfaces)
|
|
85
89
|
- Setup infrastructure adapters
|
|
86
|
-
- Create
|
|
90
|
+
- Create Entity Framework Core entity configurations
|
|
87
91
|
- Generate initial use cases
|
|
88
92
|
|
|
89
93
|
### Step 5: Setup Shared Infrastructure
|
|
@@ -104,7 +108,7 @@ For each bounded context:
|
|
|
104
108
|
## Completion Criteria
|
|
105
109
|
- MonoRepo structure follows hexagonal architecture
|
|
106
110
|
- All dependencies properly configured
|
|
107
|
-
-
|
|
111
|
+
- Entity Framework Core migrations generated and applied
|
|
108
112
|
- TypeScript compiles without errors
|
|
109
113
|
- Initial tests pass
|
|
110
114
|
- Swagger documentation accessible
|
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
## Purpose
|
|
4
4
|
Generate complete frontend project structure with Clean Architecture + DDD principles.
|
|
5
5
|
|
|
6
|
-
**CRITICAL**: Always use Next.js
|
|
6
|
+
**CRITICAL**: Always use Next.js 16+ with App Router as the default framework. Only use pure React + Vite when user explicitly mentions offline-first functionality or specifically requests non-Next.js setup.
|
|
7
7
|
|
|
8
8
|
## Task Configuration
|
|
9
9
|
```yaml
|
|
@@ -49,7 +49,7 @@ src/
|
|
|
49
49
|
```
|
|
50
50
|
|
|
51
51
|
### Step 3: Setup Configuration Files
|
|
52
|
-
- Initialize Next.js
|
|
52
|
+
- Initialize Next.js 16+ project with TypeScript
|
|
53
53
|
- Configure Next.js config for App Router
|
|
54
54
|
- Setup TailwindCSS + Shadcn/ui integration
|
|
55
55
|
- Configure Vitest for testing (with Next.js)
|
|
@@ -161,7 +161,7 @@ sections:
|
|
|
161
161
|
examples:
|
|
162
162
|
- "| **Language** | TypeScript | 5.3.3 | Primary development language | Strong typing, excellent tooling, team expertise |"
|
|
163
163
|
- "| **Runtime** | Node.js | 20.11.0 | JavaScript runtime | LTS version, stable performance, wide ecosystem |"
|
|
164
|
-
- "| **Framework** |
|
|
164
|
+
- "| **Framework** | .NET 10 | 10.0 | Backend framework | Enterprise-ready, excellent DI, proven patterns |"\n - "| **ORM** | Entity Framework Core | 10.0 | Data access | Type-safe, migrations support, LINQ queries |"
|
|
165
165
|
|
|
166
166
|
- id: data-models
|
|
167
167
|
title: Data Models
|
|
@@ -636,7 +636,7 @@ sections:
|
|
|
636
636
|
|
|
637
637
|
2. **If backend/API project**:
|
|
638
638
|
- Hand off to **Backend Agent (@backend)** for microservices implementation
|
|
639
|
-
- Backend agent will scaffold with
|
|
639
|
+
- Backend agent will scaffold with .NET 10 + Clean Architecture + DDD + Entity Framework Core
|
|
640
640
|
- Use `*scaffold` to create microservices with proper domain boundaries
|
|
641
641
|
|
|
642
642
|
3. **For all projects**:
|
|
@@ -44,7 +44,7 @@ sections:
|
|
|
44
44
|
- Use this analysis to ensure your frontend architecture aligns with the starter's patterns
|
|
45
45
|
|
|
46
46
|
3. If no frontend starter is mentioned but this is a new UI, ensure we know what the ui language and framework is:
|
|
47
|
-
- **DEFAULT RECOMMENDATION**: Next.js
|
|
47
|
+
- **DEFAULT RECOMMENDATION**: Next.js 16+ with App Router (recommended for most projects)
|
|
48
48
|
- Based on specific requirements, suggest alternatives:
|
|
49
49
|
- React with offline-first: Vite + React + Workbox
|
|
50
50
|
- Vue projects: Vue CLI, Nuxt.js, Vite + Vue
|
|
@@ -5,7 +5,7 @@ template:
|
|
|
5
5
|
version: 2.0
|
|
6
6
|
output:
|
|
7
7
|
format: markdown
|
|
8
|
-
filename: docs/stories/{{epic_num}}.{{story_num}}.{{story_title_short}}.md
|
|
8
|
+
filename: docs/stories/{{epic_num}}.{{story_num}}.{{story_title_short}}.story.md
|
|
9
9
|
title: "Story {{epic_num}}.{{story_num}}: {{story_title_short}}"
|
|
10
10
|
|
|
11
11
|
workflow:
|
package/bmad-core/user-guide.md
CHANGED
|
@@ -501,7 +501,7 @@ When creating custom web bundles or uploading to AI platforms, include your `tec
|
|
|
501
501
|
|
|
502
502
|
## Core Configuration
|
|
503
503
|
|
|
504
|
-
The
|
|
504
|
+
The `.bmad-core/core-config.yaml` file is a critical config that enables BMad to work seamlessly with differing project structures, more options will be made available in the future. Currently the most important is the devLoadAlwaysFiles list section in the yaml.
|
|
505
505
|
|
|
506
506
|
### Developer Context Files
|
|
507
507
|
|
|
@@ -23,7 +23,7 @@ REQUEST-RESOLUTION: Match user requests to your commands/dependencies flexibly (
|
|
|
23
23
|
activation-instructions:
|
|
24
24
|
- STEP 1: Read THIS ENTIRE FILE - it contains your complete persona definition
|
|
25
25
|
- STEP 2: Adopt the persona defined in the 'agent' and 'persona' sections below
|
|
26
|
-
- STEP 3: Load and read
|
|
26
|
+
- STEP 3: Load and read `.bmad-core/core-config.yaml` (project configuration) before any greeting
|
|
27
27
|
- STEP 4: Greet user with your name/role and immediately run `*help` to display available commands
|
|
28
28
|
- DO NOT: Load any other agent files during activation
|
|
29
29
|
- ONLY load dependency files when user selects them for execution via command or request of a task
|