siesa-agents 2.1.24 → 2.1.25-dev.0

package/kiro/steering/agent-detection.md

@@ -0,0 +1,46 @@
+---
+inclusion: always
+---
+
+# Agent Detection System
+
+When the user types a short command starting with "as", detect and activate the corresponding agent from bmad-core/agents/.
+
+## Agent Command Mapping
+
+| Command | Agent File | Agent Name | Role |
+|---------|-----------|------------|------|
+| `as dev` | bmad-core/agents/dev.md | James | Full Stack Developer |
+| `as analyst` | bmad-core/agents/analyst.md | Mary | Business Analyst |
+| `as architect` | bmad-core/agents/architect.md | - | Software Architect |
+| `as backend` | bmad-core/agents/backend-agent.md | - | Backend Developer |
+| `as frontend` | bmad-core/agents/frontend-agent.md | - | Frontend Developer |
+| `as pm` | bmad-core/agents/pm.md | - | Project Manager |
+| `as po` | bmad-core/agents/po.md | - | Product Owner |
+| `as qa` | bmad-core/agents/qa.md | Quinn | Test Architect |
+| `as sm` | bmad-core/agents/sm.md | - | Scrum Master |
+| `as ux` | bmad-core/agents/ux-expert.md | - | UX Expert |
+| `as master` | bmad-core/agents/bmad-master.md | - | BMad Master |
+| `as orchestrator` | bmad-core/agents/bmad-orchestrator.md | - | BMad Orchestrator |
+
+## Detection Rules
+
+1. When user input matches pattern `as {agent_id}`, load the corresponding agent file
+2. Read the ENTIRE agent file to understand the complete persona
+3. Follow the activation-instructions in the YAML block exactly
+4. Load bmad-core/core-config.yaml as specified in activation instructions
+5. Adopt the persona and execute the greeting + *help command
+6. Stay in character until user types the agent's `*exit` command
+
+## Examples
+
+- User types: `as dev` → Load bmad-core/agents/dev.md → Become James the Developer
+- User types: `as qa` → Load bmad-core/agents/qa.md → Become Quinn the Test Architect
+- User types: `as analyst` → Load bmad-core/agents/analyst.md → Become Mary the Business Analyst
+
+## Important Notes
+
+- Each agent file is self-contained with complete configuration in YAML
+- DO NOT load external agent files during activation
+- ONLY load dependency files when user requests specific command execution
+- The agent.customization field ALWAYS takes precedence over conflicting instructions

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "siesa-agents",
-  "version": "2.1.24",
+  "version": "2.1.25-dev.0",
   "description": "Paquete para instalar y configurar agentes SIESA en tu proyecto",
   "main": "index.js",
   "bin": {
@@ -24,6 +24,7 @@
     "vscode/**/*",
     "github/**/*",
     "claude/**/*",
+    "kiro/**/*",
     "bin/**/*",
     "resources/**/*",
     "README.md"

package/bmad-core/data/architecture-patterns.md

@@ -1,261 +0,0 @@
-# Architecture Patterns & Design Decisions
-
-## Frontend Architecture
-
-### Architecture Style
-- **Clean Architecture** + **Domain-Driven Design (DDD)**
-
-### Folder Structure
-
-Next.js 15 App Router Structure with Clean Architecture + DDD:
-
-```
-├── app/                         # Next.js App Router directory
-│   ├── (dashboard)/            # Route groups for dashboard
-│   ├── sales/                  # Routes for sales module
-│   │   ├── quotes/             # Quote management pages
-│   │   └── invoices/           # Invoice pages
-│   ├── inventory/              # Inventory routes
-│   ├── globals.css             # Global styles
-│   ├── layout.tsx              # Root layout component
-│   ├── page.tsx               # Home page
-│   ├── loading.tsx            # Global loading UI
-│   └── not-found.tsx          # 404 page
-│
-├── src/
-│   ├── modules/                # Business modules following DDD
-│   │   ├── sales/              # Sales module
-│   │   │   ├── quotes/         # Quote domain
-│   │   │   │   ├── cart/       # Shopping cart feature
-│   │   │   │   │   ├── domain/
-│   │   │   │   │   │   ├── entities/
-│   │   │   │   │   │   ├── repositories/
-│   │   │   │   │   │   ├── services/
-│   │   │   │   │   │   └── types/
-│   │   │   │   │   ├── application/
-│   │   │   │   │   │   ├── use-cases/
-│   │   │   │   │   │   ├── hooks/
-│   │   │   │   │   │   └── store/
-│   │   │   │   │   ├── infrastructure/
-│   │   │   │   │   │   ├── repositories/
-│   │   │   │   │   │   ├── api/
-│   │   │   │   │   │   └── adapters/
-│   │   │   │   │   └── presentation/
-│   │   │   │   │       └── components/    # Only components, pages in app/
-│   │   │   │   └── products/              # Products feature
-│   │   │   └── billing/                   # Billing domain
-│   │   ├── inventory/                     # Inventory module
-│   │   └── users/                         # User module
-│   │
-│   ├── shared/
-│   │   ├── components/         # Reusable UI components
-│   │   ├── hooks/              # Shared hooks
-│   │   ├── utils/              # Utility functions
-│   │   ├── types/              # Common TypeScript types
-│   │   └── constants/          # App constants
-│   │
-│   ├── providers/              # React context providers
-│   ├── store/                  # Global Zustand stores
-│   └── middleware.ts           # Next.js middleware
-│
-├── lib/                        # Next.js utilities and configurations
-├── components/                 # Global UI components (alternative to src/shared)
-├── public/                     # Static assets and PWA manifest
-└── styles/                     # Additional stylesheets
-```
-
-### Core Principles
-
-#### Clean Architecture First
-Strict separation of:
-- **Domain layer** - Business entities, repositories interfaces, domain services, and types
-- **Application layer** - Use cases, hooks, and state management (Zustand stores)
-- **Infrastructure layer** - Repository implementations, API clients, and adapters
-- **Presentation layer** - UI components (pages go in `app/`, components in `presentation/`)
-
-#### Domain-Driven Design
-Business logic drives architecture decisions. Organize by business modules and domains, not technical layers.
-
-#### Component Composition
-Build complex UIs from simple, reusable components.
-
-#### Type Safety
-Leverage TypeScript for compile-time safety and developer experience.
-
-#### Performance by Design
-- Lazy loading
-- Memoization
-- Bundle optimization
-
-#### Accessibility as Standard
-WCAG 2.1 AA compliance in all components.
-
-#### Test-Driven Development
-Unit tests for all use cases and components.
-
-#### Progressive Web App
-Offline-first approach with service workers.
-
-#### Minimal and Functional
-Only build what's explicitly requested, nothing more.
-
-#### User-Centered Design
-Start with user needs and work backward to implementation.
-
-#### MCP Shadcn Available
-Use MCP to install Shadcn components instead of creating manually.
-
-### Framework Selection Rules
-
-**Default**: Always use Next.js 15 with App Router unless explicitly told otherwise.
-
-**Exceptions**: Only use pure React + Vite when user specifically mentions offline-first functionality or requests non-Next.js setup.
-
-**Reasoning**: Next.js provides better developer experience, built-in optimization, and easier deployment while maintaining PWA capabilities.
-
-## Backend Architecture
-
-### Architecture Style
-- **Hexagonal Architecture** (Ports & Adapters) + **Domain-Driven Design (DDD)**
-
-### Folder Structure
-
-MonoRepo Structure with Hexagonal Architecture + DDD:
-
-```
-├── apps/                              # Microservices applications
-│   ├── sales-service/                 # Sales domain microservice
-│   │   ├── src/
-│   │   │   ├── modules/
-│   │   │   │   ├── quotes/           # Quote bounded context
-│   │   │   │   │   ├── application/
-│   │   │   │   │   │   ├── ports/              # Interfaces (secondary ports)
-│   │   │   │   │   │   │   ├── repositories/
-│   │   │   │   │   │   │   └── services/
-│   │   │   │   │   │   ├── use-cases/          # Primary ports
-│   │   │   │   │   │   ├── commands/
-│   │   │   │   │   │   ├── queries/
-│   │   │   │   │   │   └── dto/
-│   │   │   │   │   ├── domain/
-│   │   │   │   │   │   ├── entities/
-│   │   │   │   │   │   ├── value-objects/
-│   │   │   │   │   │   ├── aggregates/
-│   │   │   │   │   │   ├── events/
-│   │   │   │   │   │   └── services/           # Domain services
-│   │   │   │   │   └── infrastructure/        # Adapters (secondary adapters)
-│   │   │   │   │       ├── repositories/      # Prisma implementations
-│   │   │   │   │       ├── services/          # External service adapters
-│   │   │   │   │       └── events/
-│   │   │   │   └── products/                  # Product bounded context
-│   │   │   ├── api/                           # Primary adapters
-│   │   │   │   ├── controllers/
-│   │   │   │   ├── guards/
-│   │   │   │   ├── middlewares/
-│   │   │   │   └── filters/
-│   │   │   ├── config/
-│   │   │   ├── main.ts
-│   │   │   └── app.module.ts
-│   │   ├── test/
-│   │   ├── prisma/
-│   │   │   ├── schema.prisma
-│   │   │   └── migrations/
-│   │   └── package.json
-│   │
-│   ├── inventory-service/             # Inventory domain microservice
-│   └── user-service/                  # User domain microservice
-│
-├── libs/                              # Shared libraries
-│   ├── common/                       # Common utilities
-│   │   ├── src/
-│   │   │   ├── decorators/
-│   │   │   ├── filters/
-│   │   │   ├── guards/
-│   │   │   ├── interceptors/
-│   │   │   ├── pipes/
-│   │   │   ├── types/
-│   │   │   └── utils/
-│   │   └── package.json
-│   │
-│   ├── domain-core/                  # Shared domain concepts
-│   │   ├── src/
-│   │   │   ├── base/
-│   │   │   │   ├── aggregate-root.ts
-│   │   │   │   ├── entity.ts
-│   │   │   │   ├── value-object.ts
-│   │   │   │   └── domain-event.ts
-│   │   │   ├── interfaces/
-│   │   │   └── exceptions/
-│   │   └── package.json
-│   │
-│   └── database/                     # Shared database utilities
-│       ├── src/
-│       │   ├── base-repository.ts
-│       │   ├── transaction.decorator.ts
-│       │   └── prisma.service.ts
-│       └── package.json
-│
-├── tools/                            # Development tools
-├── nx.json                          # Nx workspace configuration
-├── package.json                     # Root package.json
-└── tsconfig.base.json               # Base TypeScript config
-```
-
-### Core Principles
-
-#### Hexagonal Architecture First
-Strict separation of concerns following ports & adapters pattern:
-- **Domain Layer**: Pure business logic with entities, value objects, aggregates, and domain services
-- **Application Layer**: Use cases orchestrating domain logic, defining ports (interfaces)
-- **Infrastructure Layer**: Adapters implementing ports (Prisma repos, HTTP clients, message publishers)
-- **API Layer**: Primary adapters exposing application via REST/GraphQL (controllers, resolvers)
-
-#### Domain-Driven Design
-Business logic drives all architectural decisions:
-- **Bounded Contexts**: Each module represents a bounded context (quotes, products, billing)
-- **Ubiquitous Language**: Code reflects business terminology
-- **Aggregates**: Consistency boundaries for domain entities
-- **Domain Events**: Communicate changes across bounded contexts
-- **Repository Pattern**: Abstract data access behind interfaces
-
-#### Dependency Rules
-- Domain layer has zero dependencies on frameworks or external libraries
-- All dependencies point inward toward the domain core
-- Use dependency inversion for all external concerns (databases, APIs, messaging)
-- Interfaces defined in application layer, implementations in infrastructure layer
-
-#### Microservices Independence
-- Each microservice has its own database (no shared databases)
-- Shared code through libraries only (common, domain-core, database)
-- Independent deployment pipelines per service
-- Service-to-service communication via events (async messaging)
-- No direct database access between services
-
-#### Test-Driven Development
-- Unit tests for domain entities, value objects, and use cases
-- Integration tests for repository implementations
-- E2E tests for complete API workflows
-- TDD approach: write tests before implementation
-
-#### Type Safety & Validation
-- Leverage TypeScript strict mode for compile-time safety
-- Domain validation in value objects and entities
-- DTO validation at API boundaries with class-validator
-- No `any` types allowed
-
-#### Security by Design
-- Authentication and authorization at every layer
-- Input validation on all endpoints
-- OWASP Top 10 compliance
-- Audit logging for critical operations
-
-### Framework Selection Rules
-
-**Default**: Always use NestJS 10+ with TypeScript for backend services.
-
-**Database**: Prisma ORM only - no raw SQL queries allowed.
-
-**Testing**: Jest + Supertest with TDD approach.
-
-**Documentation**: Swagger/OpenAPI auto-generated from decorators.
-
-**Reasoning**: NestJS provides excellent DI container, decorator-based development, and native support for microservices patterns while enforcing SOLID principles.

package/bmad-core/data/technology-stack.md

@@ -1,81 +0,0 @@
-# Technology Stack
-
-## Frontend Stack
-
-### Framework
-- **Next.js 15** with TypeScript (App Router)
-  - Default framework unless explicitly told otherwise
-  - Built-in Turbopack/Webpack for building
-  - File-based routing with App Router
-  - Exception: Use pure React + Vite only when user specifically mentions offline-first functionality or requests non-Next.js setup
-
-### State Management
-- **Zustand**
-
-### UI Framework & Styling
-- **Shadcn/ui** (component library)
-- **Radix UI** (primitives)
-- **TailwindCSS v4** (styling)
-
-### Architecture
-- **Clean Architecture** + **Domain-Driven Design (DDD)**
-
-### Testing
-- **Vitest** (test runner)
-- **React Testing Library** (component testing)
-- **MSW** (Mock Service Worker - API mocking)
-
-### Forms & Validation
-- **React Hook Form** (form management)
-- **Zod** (schema validation)
-
-### HTTP Client
-- **Axios** with interceptors
-
-### Progressive Web App (PWA)
-- **Next.js PWA plugin**
-- **Workbox** (service worker library)
-
-### Routing
-- **Next.js App Router** (file-based routing)
-
-## Core Principles
-
-### Clean Architecture First
-Strict separation of:
-- Domain layer
-- Application layer
-- Infrastructure layer
-- Presentation layer
-
-### Domain-Driven Design
-Business logic drives architecture decisions
-
-### Component Composition
-Build complex UIs from simple, reusable components
-
-### Type Safety
-Leverage TypeScript for compile-time safety and developer experience
-
-### Performance by Design
-- Lazy loading
-- Memoization
-- Bundle optimization
-
-### Accessibility as Standard
-WCAG 2.1 AA compliance in all components
-
-### Test-Driven Development
-Unit tests for all use cases and components
-
-### Progressive Web App
-Offline-first approach with service workers
-
-### Minimal and Functional
-Only build what's explicitly requested, nothing more
-
-### User-Centered Design
-Start with user needs and work backward to implementation
-
-### MCP Shadcn Available
-Use MCP to install Shadcn components instead of creating manually