siesa-agents 1.5.0 → 1.6.0

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

@@ -0,0 +1,103 @@
+<!-- Powered by BMAD™ Core -->
+
+# Create Document from Template (YAML Driven)
+
+## ⚠️ CRITICAL EXECUTION NOTICE ⚠️
+
+**THIS IS AN EXECUTABLE WORKFLOW - NOT REFERENCE MATERIAL**
+
+When this task is invoked:
+
+1. **DISABLE ALL EFFICIENCY OPTIMIZATIONS** - This workflow requires full user interaction
+2. **MANDATORY STEP-BY-STEP EXECUTION** - Each section must be processed sequentially with user feedback
+3. **ELICITATION IS REQUIRED** - When `elicit: true`, you MUST use the 1-9 format and wait for user response
+4. **NO SHORTCUTS ALLOWED** - Complete documents cannot be created without following this workflow
+
+**VIOLATION INDICATOR:** If you create a complete document without user interaction, you have violated this workflow.
+
+## Critical: Template Discovery
+
+If a YAML Template has not been provided, list all templates from .bmad-core/templates or ask the user to provide another.
+
+## CRITICAL: Mandatory Elicitation Format
+
+**When `elicit: true`, this is a HARD STOP requiring user interaction:**
+
+**YOU MUST:**
+
+1. Present section content
+2. Provide detailed rationale (explain trade-offs, assumptions, decisions made)
+3. **STOP and present numbered options 1-9:**
+   - **Option 1:** Always "Proceed to next section"
+   - **Options 2-9:** Select 8 methods from data/elicitation-methods
+   - End with: "Select 1-9 or just type your question/feedback:"
+4. **WAIT FOR USER RESPONSE** - Do not proceed until user selects option or provides feedback
+
+**WORKFLOW VIOLATION:** Creating content for elicit=true sections without user interaction violates this task.
+
+**NEVER ask yes/no questions or use any other format.**
+
+## Processing Flow
+
+1. **Parse YAML template** - Load template metadata and sections
+2. **Set preferences** - Show current mode (Interactive), confirm output file
+3. **Process each section:**
+   - Skip if condition unmet
+   - Check agent permissions (owner/editors) - note if section is restricted to specific agents
+   - Draft content using section instruction
+   - Present content + detailed rationale
+   - **IF elicit: true** → MANDATORY 1-9 options format
+   - Save to file if possible
+4. **Continue until complete**
+
+## Detailed Rationale Requirements
+
+When presenting section content, ALWAYS include rationale that explains:
+
+- Trade-offs and choices made (what was chosen over alternatives and why)
+- Key assumptions made during drafting
+- Interesting or questionable decisions that need user attention
+- Areas that might need validation
+
+## Elicitation Results Flow
+
+After user selects elicitation method (2-9):
+
+1. Execute method from data/elicitation-methods
+2. Present results with insights
+3. Offer options:
+   - **1. Apply changes and update section**
+   - **2. Return to elicitation menu**
+   - **3. Ask any questions or engage further with this elicitation**
+
+## Agent Permissions
+
+When processing sections with agent permission fields:
+
+- **owner**: Note which agent role initially creates/populates the section
+- **editors**: List agent roles allowed to modify the section
+- **readonly**: Mark sections that cannot be modified after creation
+
+**For sections with restricted access:**
+
+- Include a note in the generated document indicating the responsible agent
+- Example: "_(This section is owned by dev-agent and can only be modified by dev-agent)_"
+
+## YOLO Mode
+
+User can type `#yolo` to toggle to YOLO mode (process all sections at once).
+
+## CRITICAL REMINDERS
+
+**❌ NEVER:**
+
+- Ask yes/no questions for elicitation
+- Use any format other than 1-9 numbered options
+- Create new elicitation methods
+
+**✅ ALWAYS:**
+
+- Use exact 1-9 format when elicit: true
+- Select options 2-9 from data/elicitation-methods only
+- Provide detailed rationale explaining decisions
+- End with "Select 1-9 or just type your question/feedback:"

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

@@ -0,0 +1,133 @@
+# Create Domain Entity
+
+## Purpose
+Create a domain entity with value objects, aggregates, and business rules following DDD principles.
+
+## Task Configuration
+```yaml
+elicit: true
+interactive: true
+required_params:
+  - entity_name
+  - service_name
+  - properties
+optional_params:
+  - value_objects
+  - business_rules
+  - domain_events
+```
+
+## Task Execution
+
+### Step 1: Elicit Entity Requirements
+Ask user for:
+
+**Entity Name**: What is the entity name? (use PascalCase)
+**Service Name**: Which bounded context does this entity belong to?
+**Properties**: What are the entity properties? (name, type, validation rules)
+**Value Objects**: Any complex properties that should be value objects? (optional)
+**Business Rules**: What business rules should this entity enforce? (optional)
+**Domain Events**: What events should this entity publish? (optional)
+
+### Step 2: Generate Entity Structure
+Create the following files:
+
+```
+src/modules/{service-name}/domain/
+├── entities/
+│   └── {entity}.entity.ts
+├── value-objects/
+│   ├── {entity}-id.value-object.ts
+│   └── {property}.value-object.ts
+├── aggregates/
+│   └── {entity}.aggregate.ts
+└── events/
+    └── {entity}-{action}.event.ts
+```
+
+### Step 3: Create Domain Entity
+Generate entity with:
+- Unique identifier (UUID or custom ID)
+- Properties with proper typing
+- Business rule validation methods
+- Factory methods for creation
+- Domain event publishing
+- Immutability patterns
+
+Example structure:
+```typescript
+export class {Entity}Entity extends AggregateRoot {{
+  private constructor(
+    public readonly id: {Entity}Id,
+    private _property: PropertyValueObject,
+    // ... other properties
+  ) {{
+    super();
+  }}
+
+  static create(props: Create{Entity}Props): {Entity}Entity {{
+    // Validation logic
+    // Business rule enforcement
+    const entity = new {Entity}Entity(/* ... */);
+    entity.addDomainEvent(new {Entity}CreatedEvent(entity.id));
+    return entity;
+  }}
+
+  // Business methods
+  public updateProperty(newValue: PropertyValueObject): void {{
+    // Business rule validation
+    this._property = newValue;
+    this.addDomainEvent(new {Entity}UpdatedEvent(this.id));
+  }}
+
+  // Getters
+  get property(): PropertyValueObject {{
+    return this._property;
+  }}
+}}
+```
+
+### Step 4: Generate Value Objects
+For each value object:
+- Immutable classes with validation
+- Equality based on value, not reference
+- Factory methods with validation
+- Type safety and domain expressiveness
+
+### Step 5: Create Aggregate Root
+If entity is an aggregate root:
+- Extend AggregateRoot base class
+- Manage domain events
+- Enforce consistency boundaries
+- Handle child entity relationships
+
+### Step 6: Generate Domain Events
+For each domain event:
+- Event class with entity data
+- Event handler interfaces
+- Integration with application layer
+- Serialization for external systems
+
+### Step 7: Generate Prisma Schema
+Update Prisma schema with:
+- Entity table definition
+- Proper field types and constraints
+- Relationships with other entities
+- Indexes for performance
+- Migrations for schema changes
+
+### Step 8: Generate Tests
+Create comprehensive tests:
+- Entity business rule tests
+- Value object validation tests
+- Aggregate consistency tests
+- Domain event publishing tests
+- Factory method tests
+
+## Completion Criteria
+- Entity follows DDD patterns
+- Business rules properly enforced
+- Value objects provide type safety
+- Domain events properly implemented
+- Prisma schema updated
+- Comprehensive test coverage

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

@@ -0,0 +1,91 @@
+# Create Frontend Feature
+
+## Purpose
+Create a complete feature following Clean Architecture + DDD principles with all necessary layers.
+
+## Task Configuration
+```yaml
+elicit: true
+interactive: true
+required_params:
+  - feature_name
+  - entities
+  - use_cases
+optional_params:
+  - api_endpoints
+  - ui_components
+```
+
+## Task Execution
+
+### Step 1: Elicit Feature Requirements
+Ask user for:
+
+**Feature Name**: What is the name of the feature? (use kebab-case)
+**Domain Entities**: What are the main business entities for this feature?
+**Use Cases**: What are the main use cases/operations users can perform?
+**API Endpoints**: What backend endpoints will this feature consume? (optional)
+**UI Components**: Any specific components you know you'll need? (optional)
+
+### Step 2: Create Feature Structure
+Generate the following structure:
+
+```
+src/features/{feature_name}/
+├── domain/
+│   ├── entities/
+│   ├── repositories/
+│   ├── services/
+│   └── types/
+├── application/
+│   ├── use-cases/
+│   ├── hooks/
+│   └── store/
+├── infrastructure/
+│   ├── repositories/
+│   ├── api/
+│   └── adapters/
+└── presentation/
+    ├── components/
+    ├── pages/
+    └── styles/
+```
+
+### Step 3: Generate Domain Layer
+For each entity:
+- Create TypeScript interfaces/types
+- Define value objects if needed
+- Create repository interfaces
+- Define domain services if complex business rules exist
+
+### Step 4: Generate Application Layer
+For each use case:
+- Create use case implementation
+- Create custom hooks that consume use cases
+- Setup Zustand store for feature state
+- Implement error handling and loading states
+
+### Step 5: Generate Infrastructure Layer
+- Implement repository concrete classes
+- Setup API clients with proper typing
+- Create adapters for external services
+- Configure error handling and retries
+
+### Step 6: Generate Presentation Layer
+- Create feature-specific components
+- Setup routing for feature pages
+- Implement accessibility features
+- Add loading and error states
+
+### Step 7: Generate Tests
+- Unit tests for domain entities and services
+- Integration tests for use cases
+- Component tests for presentation layer
+- API integration tests for infrastructure layer
+
+## Completion Criteria
+- All layers properly implemented
+- Clean Architecture dependencies respected
+- TypeScript compilation successful
+- All tests passing
+- Feature integrated with main application

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

@@ -0,0 +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`

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

@@ -0,0 +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
+- Dependencies properly injected

package/.bmad-core/tasks/create-use-case.md

@@ -0,0 +1,141 @@
+# Create Application Use Case
+
+## Purpose
+Create an application use case following hexagonal architecture with ports, adapters, and dependency injection.
+
+## Task Configuration
+```yaml
+elicit: true
+interactive: true
+required_params:
+  - use_case_name
+  - service_name
+  - input_data
+  - output_data
+optional_params:
+  - external_dependencies
+  - business_rules
+  - error_scenarios
+```
+
+## Task Execution
+
+### Step 1: Elicit Use Case Requirements
+Ask user for:
+
+**Use Case Name**: What is the use case name? (use kebab-case, e.g., create-quote)
+**Service Name**: Which bounded context does this use case belong to?
+**Input Data**: What data does this use case receive? (DTOs, commands)
+**Output Data**: What data does this use case return? (response DTOs, events)
+**External Dependencies**: What repositories/services does it need? (optional)
+**Business Rules**: What business rules must be enforced? (optional)
+**Error Scenarios**: What error conditions should be handled? (optional)
+
+### Step 2: Generate Use Case Structure
+Create the following files:
+
+```
+src/modules/{service-name}/application/
+├── use-cases/
+│   └── {use-case-name}.use-case.ts
+├── commands/
+│   └── {use-case-name}.command.ts
+├── queries/
+│   └── {use-case-name}.query.ts
+├── dto/
+│   ├── {use-case-name}.dto.ts
+│   └── {use-case-name}.response.dto.ts
+└── ports/
+    ├── repositories/
+    │   └── {entity}.repository.interface.ts
+    └── services/
+        └── {external-service}.interface.ts
+```
+
+### Step 3: Create Command/Query Objects
+Generate input objects with:
+- Property validation decorators
+- Type safety with TypeScript
+- Documentation with Swagger decorators
+- Immutable data structures
+
+Example Command:
+```typescript
+export class Create{Entity}Command {{
+  @IsString()
+  @IsNotEmpty()
+  readonly property: string;
+
+  @IsOptional()
+  @IsUUID()
+  readonly optionalId?: string;
+}}
+```
+
+### Step 4: Create Use Case Implementation
+Generate use case with:
+- Dependency injection decorators
+- Input validation
+- Business logic orchestration
+- Error handling
+- Transaction management
+- Domain event handling
+
+Example Use Case:
+```typescript
+@Injectable()
+export class Create{Entity}UseCase {{
+  constructor(
+    @Inject('{Entity}_REPOSITORY')
+    private readonly {entity}Repository: {Entity}RepositoryInterface,
+    @Inject('EVENT_BUS')
+    private readonly eventBus: EventBusInterface,
+  ) {{}}
+
+  async execute(command: Create{Entity}Command): Promise<{Entity}ResponseDto> {{
+    // Validation
+    // Business logic
+    // Repository operations
+    // Event publishing
+    // Response mapping
+  }}
+}}
+```
+
+### Step 5: Create Repository Interface (Port)
+Define repository contract:
+- Method signatures for data operations
+- Return types with domain entities
+- Query parameters and filters
+- Error handling contracts
+
+### Step 6: Create Response DTOs
+Generate output objects:
+- Serialization decorators
+- API documentation
+- Type transformations
+- Nested object handling
+
+### Step 7: Generate Tests
+Create comprehensive test suite:
+- Unit tests with mocked dependencies
+- Integration tests with test database
+- Error scenario testing
+- Performance testing for complex operations
+- Contract testing for external dependencies
+
+### Step 8: Configure Dependency Injection
+Update module configuration:
+- Provider registration
+- Interface-to-implementation binding
+- Scope management (singleton, request)
+- Circular dependency resolution
+
+## Completion Criteria
+- Use case follows hexagonal architecture
+- Dependencies properly injected
+- Input/output properly validated
+- Business rules enforced
+- Error handling comprehensive
+- Tests cover all scenarios
+- Documentation complete