siesa-agents 2.1.2 → 2.1.4

package/bmad-core/tasks/create-next-story.md

@@ -1,114 +1,114 @@
-<!-- Powered by BMAD™ Core -->
-
-# Create Next Story Task
-
-## Purpose
-
-To identify the next logical story based on project progress and epic definitions, and then to prepare a comprehensive, self-contained, and actionable story file using the `Story Template`. This task ensures the story is enriched with all necessary technical context, requirements, and acceptance criteria, making it ready for efficient implementation by a Developer Agent with minimal need for additional research or finding its own context.
-
-## SEQUENTIAL Task Execution (Do not proceed until current Task is complete)
-
-### 0. Load Core Configuration and Check Workflow
-
-- Load `.bmad-core/core-config.yaml` from the project root
-- 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."
-- Extract key configurations: `devStoryLocation`, `prd.*`, `architecture.*`, `workflow.*`
-
-### 1. Identify Next Story for Preparation
-
-#### 1.1 Locate Epic Files and Review Existing Stories
-
-- Based on `prdSharded` from config, locate epic files (sharded location/pattern or monolithic PRD sections)
-- If `devStoryLocation` has story files, load the highest `{epicNum}.{storyNum}.story.md` file
-- **If highest story exists:**
-  - Verify status is 'Done'. If not, alert user: "ALERT: Found incomplete story! File: {lastEpicNum}.{lastStoryNum}.story.md Status: [current status] You should fix this story first, but would you like to accept risk & override to create the next story in draft?"
-  - If proceeding, select next sequential story in the current epic
-  - If epic is complete, prompt user: "Epic {epicNum} Complete: All stories in Epic {epicNum} have been completed. Would you like to: 1) Begin Epic {epicNum + 1} with story 1 2) Select a specific story to work on 3) Cancel story creation"
-  - **CRITICAL**: NEVER automatically skip to another epic. User MUST explicitly instruct which story to create.
-- **If no story files exist:** The next story is ALWAYS 1.1 (first story of first epic)
-- Announce the identified story to the user: "Identified next story for preparation: {epicNum}.{storyNum} - {Story Title}"
-
-### 2. Gather Story Requirements and Previous Story Context
-
-- Extract story requirements from the identified epic file
-- If previous story exists, review Dev Agent Record sections for:
-  - Completion Notes and Debug Log References
-  - Implementation deviations and technical decisions
-  - Challenges encountered and lessons learned
-- Extract relevant insights that inform the current story's preparation
-
-### 3. Gather Architecture Context
-
-#### 3.1 Determine Architecture Reading Strategy
-
-- **If `architectureVersion: >= v4` and `architectureSharded: true`**: Read `{architectureShardedLocation}/index.md` then follow structured reading order below
-- **Else**: Use monolithic `architectureFile` for similar sections
-
-#### 3.2 Read Architecture Documents Based on Story Type
-
-**For ALL Stories:** tech-stack.md, unified-project-structure.md, coding-standards.md, testing-strategy.md
-
-**For Backend/API Stories, additionally:** data-models.md, database-schema.md, backend-architecture.md, rest-api-spec.md, external-apis.md
-
-**For Frontend/UI Stories, additionally:** frontend-architecture.md, components.md, core-workflows.md, data-models.md
-
-**For Full-Stack Stories:** Read both Backend and Frontend sections above
-
-#### 3.3 Extract Story-Specific Technical Details
-
-Extract ONLY information directly relevant to implementing the current story. Do NOT invent new libraries, patterns, or standards not in the source documents.
-
-Extract:
-
-- Specific data models, schemas, or structures the story will use
-- API endpoints the story must implement or consume
-- Component specifications for UI elements in the story
-- File paths and naming conventions for new code
-- Testing requirements specific to the story's features
-- Security or performance considerations affecting the story
-
-ALWAYS cite source documents: `[Source: architecture/{filename}.md#{section}]`
-
-### 4. Verify Project Structure Alignment
-
-- Cross-reference story requirements with Project Structure Guide from `docs/architecture/unified-project-structure.md`
-- Ensure file paths, component locations, or module names align with defined structures
-- Document any structural conflicts in "Project Structure Notes" section within the story draft
-
-### 5. Populate Story Template with Full Context
-
-- Create new story file: `{devStoryLocation}/{epicNum}.{storyNum}.story.md` using Story Template
-- Fill in basic story information: Title, Status (Draft), Story statement, Acceptance Criteria from Epic
-- **`Dev Notes` section (CRITICAL):**
-  - CRITICAL: This section MUST contain ONLY information extracted from architecture documents. NEVER invent or assume technical details.
-  - Include ALL relevant technical details from Steps 2-3, organized by category:
-    - **Previous Story Insights**: Key learnings from previous story
-    - **Data Models**: Specific schemas, validation rules, relationships [with source references]
-    - **API Specifications**: Endpoint details, request/response formats, auth requirements [with source references]
-    - **Component Specifications**: UI component details, props, state management [with source references]
-    - **File Locations**: Exact paths where new code should be created based on project structure
-    - **Testing Requirements**: Specific test cases or strategies from testing-strategy.md
-    - **Technical Constraints**: Version requirements, performance considerations, security rules
-  - Every technical detail MUST include its source reference: `[Source: architecture/{filename}.md#{section}]`
-  - If information for a category is not found in the architecture docs, explicitly state: "No specific guidance found in architecture docs"
-- **`Tasks / Subtasks` section:**
-  - Generate detailed, sequential list of technical tasks based ONLY on: Epic Requirements, Story AC, Reviewed Architecture Information
-  - Each task must reference relevant architecture documentation
-  - Include unit testing as explicit subtasks based on the Testing Strategy
-  - Link tasks to ACs where applicable (e.g., `Task 1 (AC: 1, 3)`)
-- Add notes on project structure alignment or discrepancies found in Step 4
-
-### 6. Story Draft Completion and Review
-
-- Review all sections for completeness and accuracy
-- Verify all source references are included for technical details
-- Ensure tasks align with both epic requirements and architecture constraints
-- Update status to "Draft" and save the story file
-- Execute `.bmad-core/tasks/execute-checklist` `.bmad-core/checklists/story-draft-checklist`
-- Provide summary to user including:
-  - Story created: `{devStoryLocation}/{epicNum}.{storyNum}.story.md`
-  - Status: Draft
-  - Key technical components included from architecture docs
-  - Any deviations or conflicts noted between epic and architecture
-  - Checklist Results
-  - Next steps: For Complex stories, suggest the user carefully review the story draft and also optionally have the PO run the task `.bmad-core/tasks/validate-next-story`
+<!-- Powered by BMAD™ Core -->
+
+# Create Next Story Task
+
+## Purpose
+
+To identify the next logical story based on project progress and epic definitions, and then to prepare a comprehensive, self-contained, and actionable story file using the `Story Template`. This task ensures the story is enriched with all necessary technical context, requirements, and acceptance criteria, making it ready for efficient implementation by a Developer Agent with minimal need for additional research or finding its own context.
+
+## SEQUENTIAL Task Execution (Do not proceed until current Task is complete)
+
+### 0. Load Core Configuration and Check Workflow
+
+- Load `.bmad-core/core-config.yaml` from the project root
+- 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."
+- Extract key configurations: `devStoryLocation`, `prd.*`, `architecture.*`, `workflow.*`
+
+### 1. Identify Next Story for Preparation
+
+#### 1.1 Locate Epic Files and Review Existing Stories
+
+- Based on `prdSharded` from config, locate epic files (sharded location/pattern or monolithic PRD sections)
+- If `devStoryLocation` has story files, load the highest `{epicNum}.{storyNum}.story.md` file
+- **If highest story exists:**
+  - Verify status is 'Done'. If not, alert user: "ALERT: Found incomplete story! File: {lastEpicNum}.{lastStoryNum}.story.md Status: [current status] You should fix this story first, but would you like to accept risk & override to create the next story in draft?"
+  - If proceeding, select next sequential story in the current epic
+  - If epic is complete, prompt user: "Epic {epicNum} Complete: All stories in Epic {epicNum} have been completed. Would you like to: 1) Begin Epic {epicNum + 1} with story 1 2) Select a specific story to work on 3) Cancel story creation"
+  - **CRITICAL**: NEVER automatically skip to another epic. User MUST explicitly instruct which story to create.
+- **If no story files exist:** The next story is ALWAYS 1.1 (first story of first epic)
+- Announce the identified story to the user: "Identified next story for preparation: {epicNum}.{storyNum} - {Story Title}"
+
+### 2. Gather Story Requirements and Previous Story Context
+
+- Extract story requirements from the identified epic file
+- If previous story exists, review Dev Agent Record sections for:
+  - Completion Notes and Debug Log References
+  - Implementation deviations and technical decisions
+  - Challenges encountered and lessons learned
+- Extract relevant insights that inform the current story's preparation
+
+### 3. Gather Architecture Context
+
+#### 3.1 Determine Architecture Reading Strategy
+
+- **If `architectureVersion: >= v4` and `architectureSharded: true`**: Read `{architectureShardedLocation}/index.md` then follow structured reading order below
+- **Else**: Use monolithic `architectureFile` for similar sections
+
+#### 3.2 Read Architecture Documents Based on Story Type
+
+**For ALL Stories:** tech-stack.md, unified-project-structure.md, coding-standards.md, testing-strategy.md
+
+**For Backend/API Stories, additionally:** data-models.md, database-schema.md, backend-architecture.md, rest-api-spec.md, external-apis.md
+
+**For Frontend/UI Stories, additionally:** frontend-architecture.md, components.md, core-workflows.md, data-models.md
+
+**For Full-Stack Stories:** Read both Backend and Frontend sections above
+
+#### 3.3 Extract Story-Specific Technical Details
+
+Extract ONLY information directly relevant to implementing the current story. Do NOT invent new libraries, patterns, or standards not in the source documents.
+
+Extract:
+
+- Specific data models, schemas, or structures the story will use
+- API endpoints the story must implement or consume
+- Component specifications for UI elements in the story
+- File paths and naming conventions for new code
+- Testing requirements specific to the story's features
+- Security or performance considerations affecting the story
+
+ALWAYS cite source documents: `[Source: architecture/{filename}.md#{section}]`
+
+### 4. Verify Project Structure Alignment
+
+- Cross-reference story requirements with Project Structure Guide from `docs/architecture/unified-project-structure.md`
+- Ensure file paths, component locations, or module names align with defined structures
+- Document any structural conflicts in "Project Structure Notes" section within the story draft
+
+### 5. Populate Story Template with Full Context
+
+- Create new story file: `{devStoryLocation}/{epicNum}.{storyNum}.story.md` using Story Template
+- Fill in basic story information: Title, Status (Draft), Story statement, Acceptance Criteria from Epic
+- **`Dev Notes` section (CRITICAL):**
+  - CRITICAL: This section MUST contain ONLY information extracted from architecture documents. NEVER invent or assume technical details.
+  - Include ALL relevant technical details from Steps 2-3, organized by category:
+    - **Previous Story Insights**: Key learnings from previous story
+    - **Data Models**: Specific schemas, validation rules, relationships [with source references]
+    - **API Specifications**: Endpoint details, request/response formats, auth requirements [with source references]
+    - **Component Specifications**: UI component details, props, state management [with source references]
+    - **File Locations**: Exact paths where new code should be created based on project structure
+    - **Testing Requirements**: Specific test cases or strategies from testing-strategy.md
+    - **Technical Constraints**: Version requirements, performance considerations, security rules
+  - Every technical detail MUST include its source reference: `[Source: architecture/{filename}.md#{section}]`
+  - If information for a category is not found in the architecture docs, explicitly state: "No specific guidance found in architecture docs"
+- **`Tasks / Subtasks` section:**
+  - Generate detailed, sequential list of technical tasks based ONLY on: Epic Requirements, Story AC, Reviewed Architecture Information
+  - Each task must reference relevant architecture documentation
+  - Include unit testing as explicit subtasks based on the Testing Strategy
+  - Link tasks to ACs where applicable (e.g., `Task 1 (AC: 1, 3)`)
+- Add notes on project structure alignment or discrepancies found in Step 4
+
+### 6. Story Draft Completion and Review
+
+- Review all sections for completeness and accuracy
+- Verify all source references are included for technical details
+- Ensure tasks align with both epic requirements and architecture constraints
+- Update status to "Draft" and save the story file
+- Execute `.bmad-core/tasks/execute-checklist` `.bmad-core/checklists/story-draft-checklist`
+- Provide summary to user including:
+  - Story created: `{devStoryLocation}/{epicNum}.{storyNum}.story.md`
+  - Status: Draft
+  - Key technical components included from architecture docs
+  - Any deviations or conflicts noted between epic and architecture
+  - Checklist Results
+  - Next steps: For Complex stories, suggest the user carefully review the story draft and also optionally have the PO run the task `.bmad-core/tasks/validate-next-story`

package/bmad-core/tasks/create-service.md

@@ -1,118 +1,118 @@
-# Create Backend Service (Bounded Context)
-
-## Purpose
-Create a new bounded context/service within an existing microservice following hexagonal architecture and DDD principles.
-
-## Task Configuration
-```yaml
-elicit: true
-interactive: true
-required_params:
-  - service_name
-  - microservice_name
-  - domain_entities
-  - use_cases
-optional_params:
-  - external_integrations
-  - events
-```
-
-## Task Execution
-
-### Step 1: Elicit Service Requirements
-Ask user for:
-
-**Service Name**: What is the bounded context name? (use kebab-case)
-**Microservice Name**: Which microservice will contain this service?
-**Domain Entities**: What are the main business entities? (e.g., Quote, Product, Customer)
-**Use Cases**: What are the main operations users can perform?
-**External Integrations**: Any external services this context needs to integrate with? (optional)
-**Domain Events**: Any domain events this context will publish/subscribe to? (optional)
-
-### Step 2: Create Hexagonal Architecture Structure
-Generate the following structure:
-
-```
-src/modules/{service-name}/
-├── application/
-│   ├── ports/
-│   │   ├── repositories/
-│   │   │   └── {entity}.repository.interface.ts
-│   │   └── services/
-│   │       └── {external-service}.interface.ts
-│   ├── use-cases/
-│   │   ├── create-{entity}.use-case.ts
-│   │   ├── get-{entity}.use-case.ts
-│   │   ├── update-{entity}.use-case.ts
-│   │   └── delete-{entity}.use-case.ts
-│   ├── commands/
-│   │   └── create-{entity}.command.ts
-│   ├── queries/
-│   │   └── get-{entity}.query.ts
-│   └── dto/
-│       ├── create-{entity}.dto.ts
-│       └── {entity}.response.dto.ts
-├── domain/
-│   ├── entities/
-│   │   └── {entity}.entity.ts
-│   ├── value-objects/
-│   │   └── {entity}-id.value-object.ts
-│   ├── aggregates/
-│   │   └── {entity}.aggregate.ts
-│   ├── events/
-│   │   └── {entity}-created.event.ts
-│   └── services/
-│       └── {entity}.domain-service.ts
-└── infrastructure/
-    ├── repositories/
-    │   └── prisma-{entity}.repository.ts
-    ├── services/
-    │   └── {external-service}.adapter.ts
-    └── events/
-        └── {entity}-event.handler.ts
-```
-
-### Step 3: Generate Domain Layer
-For each entity:
-- Create domain entity with business rules
-- Generate value objects for type safety
-- Create aggregates for consistency boundaries
-- Define domain events for side effects
-- Implement domain services for complex business logic
-
-### Step 4: Generate Application Layer
-For each use case:
-- Create use case with dependency injection
-- Define command/query objects
-- Create DTOs for input/output
-- Implement application services
-- Define repository and service interfaces (ports)
-
-### Step 5: Generate Infrastructure Layer
-- Implement Prisma repository adapters
-- Create external service adapters
-- Implement event handlers
-- Configure dependency injection
-- Setup database migrations for new entities
-
-### Step 6: Generate API Layer
-- Create REST controllers
-- Add validation decorators
-- Configure Swagger documentation
-- Implement guards and middleware
-- Add error handling
-
-### Step 7: Generate Tests
-- Unit tests for domain entities and services
-- Integration tests for use cases
-- Repository tests with test database
-- Controller tests with mocked dependencies
-- E2E tests for complete workflows
-
-## Completion Criteria
-- Service follows hexagonal architecture patterns
-- All layers properly separated and tested
-- Prisma schema updated and migrated
-- API endpoints documented in Swagger
-- Tests cover all critical paths
+# Create Backend Service (Bounded Context)
+
+## Purpose
+Create a new bounded context/service within an existing microservice following hexagonal architecture and DDD principles.
+
+## Task Configuration
+```yaml
+elicit: true
+interactive: true
+required_params:
+  - service_name
+  - microservice_name
+  - domain_entities
+  - use_cases
+optional_params:
+  - external_integrations
+  - events
+```
+
+## Task Execution
+
+### Step 1: Elicit Service Requirements
+Ask user for:
+
+**Service Name**: What is the bounded context name? (use kebab-case)
+**Microservice Name**: Which microservice will contain this service?
+**Domain Entities**: What are the main business entities? (e.g., Quote, Product, Customer)
+**Use Cases**: What are the main operations users can perform?
+**External Integrations**: Any external services this context needs to integrate with? (optional)
+**Domain Events**: Any domain events this context will publish/subscribe to? (optional)
+
+### Step 2: Create Hexagonal Architecture Structure
+Generate the following structure:
+
+```
+src/modules/{service-name}/
+├── application/
+│   ├── ports/
+│   │   ├── repositories/
+│   │   │   └── {entity}.repository.interface.ts
+│   │   └── services/
+│   │       └── {external-service}.interface.ts
+│   ├── use-cases/
+│   │   ├── create-{entity}.use-case.ts
+│   │   ├── get-{entity}.use-case.ts
+│   │   ├── update-{entity}.use-case.ts
+│   │   └── delete-{entity}.use-case.ts
+│   ├── commands/
+│   │   └── create-{entity}.command.ts
+│   ├── queries/
+│   │   └── get-{entity}.query.ts
+│   └── dto/
+│       ├── create-{entity}.dto.ts
+│       └── {entity}.response.dto.ts
+├── domain/
+│   ├── entities/
+│   │   └── {entity}.entity.ts
+│   ├── value-objects/
+│   │   └── {entity}-id.value-object.ts
+│   ├── aggregates/
+│   │   └── {entity}.aggregate.ts
+│   ├── events/
+│   │   └── {entity}-created.event.ts
+│   └── services/
+│       └── {entity}.domain-service.ts
+└── infrastructure/
+    ├── repositories/
+    │   └── prisma-{entity}.repository.ts
+    ├── services/
+    │   └── {external-service}.adapter.ts
+    └── events/
+        └── {entity}-event.handler.ts
+```
+
+### Step 3: Generate Domain Layer
+For each entity:
+- Create domain entity with business rules
+- Generate value objects for type safety
+- Create aggregates for consistency boundaries
+- Define domain events for side effects
+- Implement domain services for complex business logic
+
+### Step 4: Generate Application Layer
+For each use case:
+- Create use case with dependency injection
+- Define command/query objects
+- Create DTOs for input/output
+- Implement application services
+- Define repository and service interfaces (ports)
+
+### Step 5: Generate Infrastructure Layer
+- Implement Prisma repository adapters
+- Create external service adapters
+- Implement event handlers
+- Configure dependency injection
+- Setup database migrations for new entities
+
+### Step 6: Generate API Layer
+- Create REST controllers
+- Add validation decorators
+- Configure Swagger documentation
+- Implement guards and middleware
+- Add error handling
+
+### Step 7: Generate Tests
+- Unit tests for domain entities and services
+- Integration tests for use cases
+- Repository tests with test database
+- Controller tests with mocked dependencies
+- E2E tests for complete workflows
+
+## Completion Criteria
+- Service follows hexagonal architecture patterns
+- All layers properly separated and tested
+- Prisma schema updated and migrated
+- API endpoints documented in Swagger
+- Tests cover all critical paths
 - Dependencies properly injected