siesa-agents 2.1.35 → 2.1.37

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

@@ -1,206 +0,0 @@
-# /create-doc Task
-
-When this command is used, execute the following task:
-
-<!-- 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: Title Preservation Rule
-
-**MANDATORY REQUIREMENTS FOR ALL SECTION TITLES:**
-
-1. **Preserve exact title text** - Copy section titles character-by-character from the YAML template
-2. **NO NUMBERS** - Never add numeric prefixes (1., 2., 3., etc.) to section titles
-3. **ENGLISH ONLY** - Never translate section titles to other languages
-4. **NO MODIFICATIONS** - Do not rephrase, reword, or alter section titles in any way
-5. **Template is the source of truth** - The title field in the YAML template is definitive
-
-**Examples:**
-- ✅ CORRECT: `# High Level Architecture`
-- ❌ WRONG: `# 2. High Level Architecture`
-- ❌ WRONG: `# Arquitectura de Alto Nivel`
-- ❌ WRONG: `# High-Level Architecture Overview`
-- ❌ WRONG: `# 2. Arquitectura de Alto Nivel`
-
-**This rule applies to:**
-- Main section headings (# Title)
-- Subsection headings (## Title)
-- All levels of nested sections
-
-**VIOLATION INDICATOR:** If you add numbers, translate, or modify any section title from the template, you have violated this rule.
-
-## CRITICAL: Document Language Rule
-
-**ALL DOCUMENT CONTENT MUST BE WRITTEN IN ENGLISH:**
-
-Regardless of what language you use to converse with the user, ALL documentation artifacts must be written entirely in English.
-
-**This applies to:**
-- Section titles (already covered by Title Preservation Rule)
-- Section content and descriptions
-- Examples and code comments
-- Table contents and headers
-- Bullet points and numbered lists
-- Technical specifications
-- User stories and acceptance criteria
-- All other documentation text
-
-**Examples:**
-- ✅ CORRECT: "The system must support user authentication"
-- ❌ WRONG: "El sistema debe soportar autenticación de usuarios"
-- ✅ CORRECT: "Epic 1: Foundation and Infrastructure"
-- ❌ WRONG: "Epic 1: Fundación e Infraestructura"
-
-**IMPORTANT DISTINCTION:**
-- **Conversation with user:** Use user's preferred language (Spanish, English, etc.)
-- **Document content:** ALWAYS English, no exceptions
-
-**VIOLATION INDICATOR:** If any document content (titles, descriptions, examples, etc.) is written in a language other than English, you have violated this rule.
-
-## 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 or YOLO), confirm output file
-3. **If YOLO mode:**
-   - Count total sections
-   - Estimate optimal batch count based on section complexity
-   - Split document into 3-4 batches (~12-17 sections each)
-   - Process each batch → Save → STOP → Wait for "continue"
-   - Repeat until all batches complete
-
-4. **If Interactive mode:**
-   - Process each section one at a time:
-     - Skip if condition unmet
-     - Check agent permissions (owner/editors)
-     - **PRESERVE EXACT TITLE from template (no numbers, no translation)**
-     - Draft content using section instruction
-     - Present content + detailed rationale
-     - **IF elicit: true** → MANDATORY 1-9 options format
-     - Save to file after section
-     - Wait for user response before next section
-
-5. **Continue until all sections 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 sections in batches without elicitation).
-
-**MANDATORY BATCH WORKFLOW:**
-
-1. **Automatic batch calculation:**
-   - Estimate: `sections × 600 tokens`
-   - Max per batch: **22,000 tokens** (safe 10K buffer - Claude can't measure in real-time)
-   - Batches needed: `total_estimate ÷ 22,000` (rounded up)
-   - If complex sections detected: multiply estimate × 1.5
-
-2. **CRITICAL - Repeatable sections (epics, stories, etc.):**
-   - Count total repeatable items (e.g., 10 epics × 10 stories each)
-   - Estimate tokens per item: `epic ~7,000 tokens`, `story ~800 tokens`
-   - Calculate: `items × tokens_per_item = total_tokens`
-   - If `total_tokens > 22,000`: Split into sub-batches
-   - Example: 10 epics × 7K = 70K tokens → 4 sub-batches (3-3-2-2 epics)
-   - Process each sub-batch separately with pauses
-
-3. **Process EACH batch:**
-   - **PRESERVE EXACT TITLES from template (no numbers, no translation)**
-   - Generate content for batch sections
-   - Save to file
-   - STOP and tell user: "✅ Batch X/Y complete: Sections A-B saved. Type 'continue'."
-   - WAIT for user to type "continue"
-   - Repeat until all batches complete
-
-**Examples:**
-- 30 sections (~18K tokens) → 1 batch (0 pauses)
-- 50 sections (~30K tokens) → 2 batches (1 pause)
-- 50 sections + 10 epics (~80K tokens) → 4 batches (3 pauses)
-
-**THIS IS NON-NEGOTIABLE FOR YOLO MODE**
-
-## CRITICAL REMINDERS
-
-**❌ NEVER:**
-
-- Ask yes/no questions for elicitation
-- Use any format other than 1-9 numbered options
-- Create new elicitation methods
-- Add numbers to section titles (1., 2., etc.)
-- Translate section titles from English
-- Modify or rephrase section titles from the template
-
-**✅ 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:"
-- Preserve exact section titles from YAML template without modification
-- Keep all section titles in English as defined in template

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

@@ -1,133 +0,0 @@
-# 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 Entity Framework Configuration
-Create EF Core entity configuration 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
-- Entity Framework Core configuration created
-- Comprehensive test coverage

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

@@ -1,91 +0,0 @@
-# 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

@@ -1,145 +0,0 @@
-<!-- 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
-
-### 4.5. Elicit Jira Link (If Exists)
-
-```elicit
-path: Check for existing Jira issue
-format: |
-  Does this story already have a Jira issue created?
-  
-  If yes, provide the Jira issue key (e.g., PM-9) or full URL.
-  If no, type 'no' or leave empty.
-  
-  Jira link (or 'no'):
-```
-
-**Action:** Handle Jira link information
-
-- [ ] Accept user input
-- [ ] If provided: Extract Jira key (e.g., PM-9) and construct full URL using jira-conf.md settings
-- [ ] If not provided: Set default message "Not synced to Jira yet"
-- [ ] Store for use in Jira Information section
-
-### 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
-- **`Jira Information` section:**
-  - If Jira key was provided: Populate with key and full URL
-  - If not provided: Set with default message:
-    ```markdown
-    ## Jira Information
-    
-    **Jira Issue Key:** Not synced to Jira yet
-    **Jira URL:** Story will be synced to Jira using sync-story-to-jira task
-    
-    _Note: Tasks will not be created in Jira until this story has an associated Jira issue._
-    ```
-- **`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 +0,0 @@
-# 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/
-    │   └── {Entity}Repository.cs
-    ├── 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 Entity Framework Core 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
-- Entity Framework Core migrations created and applied
-- API endpoints documented in Swagger
-- Tests cover all critical paths
-- Dependencies properly injected