siesa-agents 2.1.35 → 2.1.37

package/bmad-core/data/brainstorming-techniques.md

@@ -1,38 +0,0 @@
-<!-- Powered by BMAD™ Core -->
-
-# Brainstorming Techniques Data
-
-## Creative Expansion
-
-1. **What If Scenarios**: Ask one provocative question, get their response, then ask another
-2. **Analogical Thinking**: Give one example analogy, ask them to find 2-3 more
-3. **Reversal/Inversion**: Pose the reverse question, let them work through it
-4. **First Principles Thinking**: Ask "What are the fundamentals?" and guide them to break it down
-
-## Structured Frameworks
-
-5. **SCAMPER Method**: Go through one letter at a time, wait for their ideas before moving to next
-6. **Six Thinking Hats**: Present one hat, ask for their thoughts, then move to next hat
-7. **Mind Mapping**: Start with central concept, ask them to suggest branches
-
-## Collaborative Techniques
-
-8. **"Yes, And..." Building**: They give idea, you "yes and" it, they "yes and" back - alternate
-9. **Brainwriting/Round Robin**: They suggest idea, you build on it, ask them to build on yours
-10. **Random Stimulation**: Give one random prompt/word, ask them to make connections
-
-## Deep Exploration
-
-11. **Five Whys**: Ask "why" and wait for their answer before asking next "why"
-12. **Morphological Analysis**: Ask them to list parameters first, then explore combinations together
-13. **Provocation Technique (PO)**: Give one provocative statement, ask them to extract useful ideas
-
-## Advanced Techniques
-
-14. **Forced Relationships**: Connect two unrelated concepts and ask them to find the bridge
-15. **Assumption Reversal**: Challenge their core assumptions and ask them to build from there
-16. **Role Playing**: Ask them to brainstorm from different stakeholder perspectives
-17. **Time Shifting**: "How would you solve this in 1995? 2030?"
-18. **Resource Constraints**: "What if you had only $10 and 1 hour?"
-19. **Metaphor Mapping**: Use extended metaphors to explore solutions
-20. **Question Storming**: Generate questions instead of answers first

package/bmad-core/data/elicitation-methods.md

@@ -1,156 +0,0 @@
-<!-- Powered by BMAD™ Core -->
-
-# Elicitation Methods Data
-
-## Core Reflective Methods
-
-**Expand or Contract for Audience**
-
-- Ask whether to 'expand' (add detail, elaborate) or 'contract' (simplify, clarify)
-- Identify specific target audience if relevant
-- Tailor content complexity and depth accordingly
-
-**Explain Reasoning (CoT Step-by-Step)**
-
-- Walk through the step-by-step thinking process
-- Reveal underlying assumptions and decision points
-- Show how conclusions were reached from current role's perspective
-
-**Critique and Refine**
-
-- Review output for flaws, inconsistencies, or improvement areas
-- Identify specific weaknesses from role's expertise
-- Suggest refined version reflecting domain knowledge
-
-## Structural Analysis Methods
-
-**Analyze Logical Flow and Dependencies**
-
-- Examine content structure for logical progression
-- Check internal consistency and coherence
-- Identify and validate dependencies between elements
-- Confirm effective ordering and sequencing
-
-**Assess Alignment with Overall Goals**
-
-- Evaluate content contribution to stated objectives
-- Identify any misalignments or gaps
-- Interpret alignment from specific role's perspective
-- Suggest adjustments to better serve goals
-
-## Risk and Challenge Methods
-
-**Identify Potential Risks and Unforeseen Issues**
-
-- Brainstorm potential risks from role's expertise
-- Identify overlooked edge cases or scenarios
-- Anticipate unintended consequences
-- Highlight implementation challenges
-
-**Challenge from Critical Perspective**
-
-- Adopt critical stance on current content
-- Play devil's advocate from specified viewpoint
-- Argue against proposal highlighting weaknesses
-- Apply YAGNI principles when appropriate (scope trimming)
-
-## Creative Exploration Methods
-
-**Tree of Thoughts Deep Dive**
-
-- Break problem into discrete "thoughts" or intermediate steps
-- Explore multiple reasoning paths simultaneously
-- Use self-evaluation to classify each path as "sure", "likely", or "impossible"
-- Apply search algorithms (BFS/DFS) to find optimal solution paths
-
-**Hindsight is 20/20: The 'If Only...' Reflection**
-
-- Imagine retrospective scenario based on current content
-- Identify the one "if only we had known/done X..." insight
-- Describe imagined consequences humorously or dramatically
-- Extract actionable learnings for current context
-
-## Multi-Persona Collaboration Methods
-
-**Agile Team Perspective Shift**
-
-- Rotate through different Scrum team member viewpoints
-- Product Owner: Focus on user value and business impact
-- Scrum Master: Examine process flow and team dynamics
-- Developer: Assess technical implementation and complexity
-- QA: Identify testing scenarios and quality concerns
-
-**Stakeholder Round Table**
-
-- Convene virtual meeting with multiple personas
-- Each persona contributes unique perspective on content
-- Identify conflicts and synergies between viewpoints
-- Synthesize insights into actionable recommendations
-
-**Meta-Prompting Analysis**
-
-- Step back to analyze the structure and logic of current approach
-- Question the format and methodology being used
-- Suggest alternative frameworks or mental models
-- Optimize the elicitation process itself
-
-## Advanced 2025 Techniques
-
-**Self-Consistency Validation**
-
-- Generate multiple reasoning paths for same problem
-- Compare consistency across different approaches
-- Identify most reliable and robust solution
-- Highlight areas where approaches diverge and why
-
-**ReWOO (Reasoning Without Observation)**
-
-- Separate parametric reasoning from tool-based actions
-- Create reasoning plan without external dependencies
-- Identify what can be solved through pure reasoning
-- Optimize for efficiency and reduced token usage
-
-**Persona-Pattern Hybrid**
-
-- Combine specific role expertise with elicitation pattern
-- Architect + Risk Analysis: Deep technical risk assessment
-- UX Expert + User Journey: End-to-end experience critique
-- PM + Stakeholder Analysis: Multi-perspective impact review
-
-**Emergent Collaboration Discovery**
-
-- Allow multiple perspectives to naturally emerge
-- Identify unexpected insights from persona interactions
-- Explore novel combinations of viewpoints
-- Capture serendipitous discoveries from multi-agent thinking
-
-## Game-Based Elicitation Methods
-
-**Red Team vs Blue Team**
-
-- Red Team: Attack the proposal, find vulnerabilities
-- Blue Team: Defend and strengthen the approach
-- Competitive analysis reveals blind spots
-- Results in more robust, battle-tested solutions
-
-**Innovation Tournament**
-
-- Pit multiple alternative approaches against each other
-- Score each approach across different criteria
-- Crowd-source evaluation from different personas
-- Identify winning combination of features
-
-**Escape Room Challenge**
-
-- Present content as constraints to work within
-- Find creative solutions within tight limitations
-- Identify minimum viable approach
-- Discover innovative workarounds and optimizations
-
-## Process Control
-
-**Proceed / No Further Actions**
-
-- Acknowledge choice to finalize current work
-- Accept output as-is or move to next step
-- Prepare to continue without additional elicitation

package/bmad-core/data/jira-preferences.md

@@ -1,153 +0,0 @@
-# Jira Integration Preferences
-
-## Connection Configuration
-
-### Provider Settings
-- **Provider:** `jira`
-- **Cloud ID:** `3b04e1a3-a260-4679-bdc8-0440507fbe26`
-- **Jira URL:** `https://siesa-test-sandbox.atlassian.net`
-
-### Project Configuration
-- **Project Key:** `PM`
-- **Project Name:** `Prueba MCP`
-
-## Issue Type Configuration
-
-### Epic Configuration
-- **Issue Type:** `Epic`
-- **Issue Type ID:** `10317`
-- **Default Epic Name Prefix:** _(none, use clean titles)_
-
-### Story Configuration
-- **Issue Type:** `Story`
-- **Issue Type ID:** `10316`
-- **Default Story Name Prefix:** _(none, use clean titles)_
-
-### Other Available Issue Types
-- **Task:** `10314`
-- **Bug:** `10315`
-- **Subtarea:** `10318`
-
-## Field Mappings
-
-### Standard Fields
-- **Summary:** Maps to Epic/Story title
-- **Description:** Maps to Epic/Story description  
-- **Priority:** Default is `Medium` (options: `Highest`, `High`, `Medium`, `Low`, `Lowest`)
-- **Labels:** Auto-generated from PRD metadata (e.g., `prd-sync`, `automated`, epic name)
-
-### Custom Fields (Proyecto PM)
-
-#### Story Custom Fields (REQUIRED)
-- **Acceptance Criteria:** `customfield_10136` - **MANDATORY for Stories** - Success conditions extracted from PRD
-
-#### Optional Custom Fields
-- **Story Points:** `customfield_10016` - Effort estimation (optional)
-- **Sprint:** `customfield_10020` - Sprint assignment (optional, array type)
-- **Start Date:** `customfield_10015` - Planning date (optional)
-
-#### Epic Custom Fields
-_(No custom fields required for Epics in this project)_
-
-## PRD Parsing Configuration
-
-### Epic Detection
-Epics are identified in PRD by:
-- **Section Headers:** Level 2-3 headers (`##` or `###`) in the PRD containing "Epic", "Feature Set", or "Module"
-- **YAML Frontmatter:** `epics:` section in PRD metadata
-- **Explicit Markers:** `<!-- EPIC: Epic Name -->` in PRD
-
-### Story Detection
-Stories are identified in PRD by:
-- **Subsections:** Level 4+ headers (`####`) under epic sections
-- **List Items:** Numbered or bulleted lists under "User Stories" or "Requirements" sections
-- **User Story Format:** Text matching "As a [role], I want [action], so that [benefit]"
-
-### Content Extraction Rules
-- **Epic Goal:** First paragraph after epic header
-- **Epic Description:** Full content of epic section (required for Jira description field)
-- **Story Description:** Content immediately following story identifier
-- **Acceptance Criteria (REQUIRED):** Sections marked with "Acceptance Criteria", "AC:", "Definition of Done", or checkbox lists - **MUST BE EXTRACTED for all Stories**
-- **Technical Details:** Sections marked with "Technical Notes", "Implementation", or "Tech Stack"
-
-## Automation Preferences
-
-### Batch Creation Settings
-- **Create Epics First:** `true` - Create all epics before stories
-- **Link Stories Automatically:** `true` - Auto-link stories to parent epics
-- **Preserve PRD Structure:** `true` - Maintain hierarchy from PRD
-- **Dry Run Mode:** `false` - Set to `true` to preview without creating
-
-### Naming Conventions
-- **Epic Naming:** `{Epic Name} - {Brief Description}`
-- **Story Naming:** `{User Role}: {Action/Capability}`
-- **Include PRD Reference:** `true` - Add PRD source reference in description
-
-### Default Values
-- **Default Assignee:** `unassigned` (or specify username)
-- **Default Sprint:** `unassigned` (or specify sprint name)
-- **Default Priority:** `Medium`
-- **Default Story Points:** `null` (will be estimated later)
-
-## Error Handling
-
-### Duplicate Detection
-- **Check Existing Issues:** `true` - Prevent duplicate creation
-- **Match Criteria:** `summary` + `labels` containing `prd-sync`
-- **On Duplicate:** `skip` | `update` | `create-new`
-
-### Failed Creation Handling
-- **Continue on Error:** `true` - Continue creating remaining items
-- **Log Failed Items:** `true` - Report items that couldn't be created
-- **Retry Failed:** `false` - Manual retry required
-
-## Important Rules for Proyecto PM
-
-### Story Creation Requirements
-⚠️ **CRITICAL:** When creating Stories in the PM project:
-
-1. **Acceptance Criteria are MANDATORY**
-   - ALWAYS extract acceptance criteria from the PRD
-   - ALWAYS populate `customfield_10136` with acceptance criteria
-   - If no acceptance criteria found in PRD, STOP and request them from user before creating the Story
-   - Format: Use bullet points or numbered lists
-
-2. **Field Population**
-   - `summary`: Story title (required)
-   - `description`: Story description (required)
-   - `customfield_10136`: Acceptance criteria (REQUIRED - cannot be empty)
-   - `customfield_10016`: Story points (optional - leave empty if not in PRD)
-
-3. **Quality Standards**
-   - Acceptance criteria must be clear, testable, and specific
-   - Each criterion should be verifiable
-   - Use format: "- Criterion 1\n- Criterion 2\n- Criterion 3"
-
-### Epic Creation Requirements
-- Epics do NOT require custom fields in this project
-- Use standard `summary` and `description` fields only
-- Description should include the epic goal and full context
-
-## Notes
-
-### Finding Your Custom Field IDs
-The custom field IDs for this project are already configured above. If you need to find others:
-
-1. Go to Jira Settings > Issues > Custom Fields
-2. Click on the custom field you want to use
-3. Look at the URL - the ID is in the format `customfield_XXXXX`
-
-Or use the Jira API:
-```bash
-curl -u email@example.com:api_token \
-  https://siesa-test-sandbox.atlassian.net/rest/api/3/field
-```
-
-### Provider Information
-**Provider = `jira`** means we're using Atlassian Jira Cloud as our issue tracking system.
-Other options exist (GitHub, GitLab, Azure DevOps, Linear) but this project uses Jira.
-
----
-
-**Last Updated:** 2025-12-10
-**Configuration Version:** 1.0.0

package/bmad-core/data/technical-preferences.md

@@ -1,110 +0,0 @@
-<!-- Powered by BMAD™ Core -->
-
-# User-Defined Preferred Patterns and Preferences
-
-## Backend Preferences (.NET 10)
-
-### Framework & Language
-- **MANDATORY**: .NET 10 with C# Minimal API
-- **API Style**: Minimal API (lightweight, modern approach)
-- **NO** MVC Controllers - Use Minimal API endpoints only
-
-### Database
-- **MANDATORY**: PostgreSQL for all microservices
-- **ORM**: Entity Framework Core 10 (primary - matches .NET 10 version)
-- **LINQ Extensions**: linq2db, DynamicLinq, LinqKit for advanced queries
-- **Primary Keys**: UUID (Guid) for ALL entities - NO exceptions
-- **Migrations**: EF Core 10 Migrations for schema version control
-- **DateTime Types**: 
-  - **MANDATORY**: Use `DateTimeOffset` for ALL timestamp fields (CreatedAt, UpdatedAt, etc.)
-  - **FORBIDDEN**: NEVER use `DateTime` for timestamp fields in entities or DTOs
-  - **Rationale**: PostgreSQL uses TIMESTAMP WITH TIME ZONE which maps to DateTimeOffset
-  - **Date Only**: Use `DateOnly` for date-only fields (BirthDate, ExpenseDate)
-  - **Time Only**: Use `TimeOnly` for time-only fields (OpeningTime, ClosingTime)
-
-### Validation
-- **MANDATORY**: FluentValidation for all DTOs and commands
-
-### API Documentation
-- **MANDATORY**: Scalar for API documentation
-- **FORBIDDEN**: Do NOT use Swagger/Swashbuckle
-
-### Architecture
-- **Pattern**: Clean Architecture + DDD
-- **Microservices**: Each service with independent PostgreSQL database
-- **No Shared Databases**: Services communicate via APIs or events
-- **CQRS**: Command/Query separation in Application layer
-
-### Testing
-- **Framework**: xUnit (MANDATORY)
-- **TDD**: Test-Driven Development approach required
-- **Unit Tests**: EF Core InMemory for fast tests
-- **Integration Tests**: PostgreSQL Test Containers for real scenarios
-- **Coverage**: Aim for >80% code coverage
-
-### PDF Generation
-- **Library**: QuestPDF for document generation
-- **Testing**: Snapshot/output validation for PDF tests
-
-### Code Quality
-- **Analyzers**: Enable .NET code analyzers
-- **Format**: Use `dotnet format` for code style
-- **EditorConfig**: Enforce coding standards
-
-### Localization
-- **i18n/l10n**: Built-in .NET localization support
-- **Resources**: Use .resx files for translations
-
-### Development Environment
-- **Local Development**: Direct execution with `dotnet run`
-- **PostgreSQL Local**: Use local PostgreSQL instance or cloud dev DB
-
-### Production Deployment
-- **Containerization**: Docker for production deployments
-- **Orchestration**: Kubernetes or Docker Compose
-- **Each Service**: Independent container with health checks
-
-## Frontend Preferences (Next.js 16)
-
-### Framework
-- **Default**: Next.js 16 with TypeScript and App Router
-- **Exception**: Pure React + Vite only for offline-first scenarios
-
-### State Management
-- **Zustand**: Preferred for global state
-
-### UI Components
-- **shadcn/ui**: Component library
-- **Radix UI**: Primitives
-- **TailwindCSS v4**: Styling
-
-### Testing
-- **Vitest**: Test runner
-- **React Testing Library**: Component testing
-- **MSW**: API mocking
-
-### Validation
-- **Zod**: Schema validation
-- **React Hook Form**: Form management
-
-## Cross-Stack Preferences
-
-### Communication
-- **REST API**: Primary communication protocol
-- **gRPC**: For high-performance inter-service calls
-- **Message Broker**: RabbitMQ or Azure Service Bus for async events
-
-### Security
-- **Authentication**: JWT tokens
-- **Authorization**: Role-based access control
-- **HTTPS**: Mandatory for all environments
-
-### Logging & Monitoring
-- **Structured Logging**: Use ILogger in .NET
-- **Correlation IDs**: Track requests across services
-- **Health Checks**: Implement health endpoints for all services
-
-### Error Handling
-- **Problem Details**: RFC 7807 for error responses
-- **Global Exception Handler**: Middleware for centralized error handling
-- **Validation Errors**: Return 400 with detailed validation messages

package/bmad-core/data/test-levels-framework.md

@@ -1,148 +0,0 @@
-<!-- Powered by BMAD™ Core -->
-
-# Test Levels Framework
-
-Comprehensive guide for determining appropriate test levels (unit, integration, E2E) for different scenarios.
-
-## Test Level Decision Matrix
-
-### Unit Tests
-
-**When to use:**
-
-- Testing pure functions and business logic
-- Algorithm correctness
-- Input validation and data transformation
-- Error handling in isolated components
-- Complex calculations or state machines
-
-**Characteristics:**
-
-- Fast execution (immediate feedback)
-- No external dependencies (DB, API, file system)
-- Highly maintainable and stable
-- Easy to debug failures
-
-**Example scenarios:**
-
-```yaml
-unit_test:
-  component: 'PriceCalculator'
-  scenario: 'Calculate discount with multiple rules'
-  justification: 'Complex business logic with multiple branches'
-  mock_requirements: 'None - pure function'
-```
-
-### Integration Tests
-
-**When to use:**
-
-- Component interaction verification
-- Database operations and transactions
-- API endpoint contracts
-- Service-to-service communication
-- Middleware and interceptor behavior
-
-**Characteristics:**
-
-- Moderate execution time
-- Tests component boundaries
-- May use test databases or containers
-- Validates system integration points
-
-**Example scenarios:**
-
-```yaml
-integration_test:
-  components: ['UserService', 'AuthRepository']
-  scenario: 'Create user with role assignment'
-  justification: 'Critical data flow between service and persistence'
-  test_environment: 'In-memory database'
-```
-
-### End-to-End Tests
-
-**When to use:**
-
-- Critical user journeys
-- Cross-system workflows
-- Visual regression testing
-- Compliance and regulatory requirements
-- Final validation before release
-
-**Characteristics:**
-
-- Slower execution
-- Tests complete workflows
-- Requires full environment setup
-- Most realistic but most brittle
-
-**Example scenarios:**
-
-```yaml
-e2e_test:
-  journey: 'Complete checkout process'
-  scenario: 'User purchases with saved payment method'
-  justification: 'Revenue-critical path requiring full validation'
-  environment: 'Staging with test payment gateway'
-```
-
-## Test Level Selection Rules
-
-### Favor Unit Tests When:
-
-- Logic can be isolated
-- No side effects involved
-- Fast feedback needed
-- High cyclomatic complexity
-
-### Favor Integration Tests When:
-
-- Testing persistence layer
-- Validating service contracts
-- Testing middleware/interceptors
-- Component boundaries critical
-
-### Favor E2E Tests When:
-
-- User-facing critical paths
-- Multi-system interactions
-- Regulatory compliance scenarios
-- Visual regression important
-
-## Anti-patterns to Avoid
-
-- E2E testing for business logic validation
-- Unit testing framework behavior
-- Integration testing third-party libraries
-- Duplicate coverage across levels
-
-## Duplicate Coverage Guard
-
-**Before adding any test, check:**
-
-1. Is this already tested at a lower level?
-2. Can a unit test cover this instead of integration?
-3. Can an integration test cover this instead of E2E?
-
-**Coverage overlap is only acceptable when:**
-
-- Testing different aspects (unit: logic, integration: interaction, e2e: user experience)
-- Critical paths requiring defense in depth
-- Regression prevention for previously broken functionality
-
-## Test Naming Conventions
-
-- Unit: `test_{component}_{scenario}`
-- Integration: `test_{flow}_{interaction}`
-- E2E: `test_{journey}_{outcome}`
-
-## Test ID Format
-
-`{EPIC}.{STORY}-{LEVEL}-{SEQ}`
-
-Examples:
-
-- `1.3-UNIT-001`
-- `1.3-INT-002`
-- `1.3-E2E-001`