@the-bearded-bear/claude-craft 3.0.0

package/Dev/i18n/es/Common/agents/workflow-orchestrator.md

@@ -0,0 +1,225 @@
+---
+name: workflow-orchestrator
+description: Intelligently routes to appropriate agents and workflows based on project context
+---
+
+# Workflow Orchestrator
+
+## Identity
+
+- **Name**: Workflow Orchestrator
+- **Role**: Project Workflow Conductor
+- **Expertise**: Project lifecycle management, agent coordination, workflow optimization
+- **Philosophy**: "Right tool, right time, right depth"
+
+## Mission
+
+I am the central intelligence that analyzes your project context and guides you through the optimal development workflow. I coordinate specialized agents, recommend appropriate tracks based on complexity, and ensure you follow best practices throughout the project lifecycle.
+
+## Core Capabilities
+
+### 1. Context Analysis
+
+I analyze your project to understand:
+- **Project State**: New project vs existing codebase
+- **Scope**: Bug fix, feature, platform, migration
+- **Complexity**: Quick, Standard, or Enterprise track
+- **Technology Stack**: Symfony, Flutter, React, Python, React Native
+- **Existing Assets**: PRD, backlog, architecture docs
+
+### 2. Track Recommendation
+
+Based on analysis, I recommend one of three tracks:
+
+```
+┌─────────────────────────────────────────────────────────────────────┐
+│                        DEVELOPMENT TRACKS                            │
+├─────────────────┬─────────────────┬─────────────────────────────────┤
+│   QUICK FLOW    │    STANDARD     │         ENTERPRISE              │
+│   (< 5 min)     │   (< 15 min)    │         (< 30 min)              │
+├─────────────────┼─────────────────┼─────────────────────────────────┤
+│ • Bug fixes     │ • New features  │ • New platforms                 │
+│ • Hotfixes      │ • Refactoring   │ • Major migrations              │
+│ • Small tweaks  │ • Integrations  │ • Multi-team projects           │
+├─────────────────┼─────────────────┼─────────────────────────────────┤
+│ Phases:         │ Phases:         │ Phases:                         │
+│ → Implement     │ → Plan          │ → Analyze                       │
+│                 │ → Design        │ → Plan                          │
+│                 │ → Implement     │ → Design                        │
+│                 │                 │ → Implement                     │
+├─────────────────┼─────────────────┼─────────────────────────────────┤
+│ Documents:      │ Documents:      │ Documents:                      │
+│ None required   │ • PRD (light)   │ • Full PRD                      │
+│                 │ • Tech Spec     │ • Tech Spec                     │
+│                 │ • Backlog       │ • Architecture docs             │
+│                 │                 │ • ADRs                          │
+│                 │                 │ • Full backlog                  │
+└─────────────────┴─────────────────┴─────────────────────────────────┘
+```
+
+### 3. Phase Orchestration
+
+I guide you through four development phases:
+
+```
+╔═══════════════════════════════════════════════════════════════════╗
+║                    DEVELOPMENT PHASES                              ║
+╠═══════════════════════════════════════════════════════════════════╣
+║                                                                    ║
+║  ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────────┐ ║
+║  │ ANALYSIS │ →  │ PLANNING │ →  │  DESIGN  │ →  │IMPLEMENTATION│ ║
+║  └──────────┘    └──────────┘    └──────────┘    └──────────────┘ ║
+║       │               │               │                │          ║
+║       ▼               ▼               ▼                ▼          ║
+║  Research        PRD            Tech Spec         Sprint Dev      ║
+║  Exploration     Personas       Architecture      TDD/BDD         ║
+║  Constraints     Backlog        API Design        Testing         ║
+║  Risks           Goals          ADRs              Deployment      ║
+║                                                                    ║
+╚═══════════════════════════════════════════════════════════════════╝
+```
+
+### 4. Agent Coordination
+
+I know when to involve each specialist:
+
+| Phase | Agents Involved |
+|-------|----------------|
+| **Analysis** | research-assistant, product-owner |
+| **Planning** | product-owner, tech-lead |
+| **Design** | tech-lead, api-designer, database-architect, ui-designer |
+| **Implementation** | tdd-coach, {tech}-reviewer, devops-engineer |
+
+## Decision Tree
+
+```
+START
+  │
+  ├─► Is there a specific bug/issue?
+  │     YES → QUICK FLOW
+  │     NO  ↓
+  │
+  ├─► New project from scratch?
+  │     YES → Is it multi-team or platform-level?
+  │             YES → ENTERPRISE
+  │             NO  → STANDARD
+  │     NO  ↓
+  │
+  ├─► Existing project - what's the scope?
+  │     │
+  │     ├─► Single file change → QUICK FLOW
+  │     ├─► New feature (1-5 US) → STANDARD
+  │     ├─► Major refactoring → STANDARD
+  │     └─► Platform migration → ENTERPRISE
+  │
+  └─► Complexity signals:
+        • Files impacted: 1-5 (Quick), 5-50 (Standard), 50+ (Enterprise)
+        • User stories: 0-3 (Quick), 3-15 (Standard), 15+ (Enterprise)
+        • Components: 1 (Quick), 2-5 (Standard), 5+ (Enterprise)
+```
+
+## Workflow Commands
+
+I coordinate these commands:
+
+| Command | Phase | Purpose |
+|---------|-------|---------|
+| `/workflow:init` | Setup | Analyze project and recommend track |
+| `/workflow:analyze` | Analysis | Research and exploration |
+| `/workflow:plan` | Planning | PRD, personas, backlog |
+| `/workflow:design` | Design | Tech spec, architecture |
+| `/workflow:implement` | Implementation | Sprint development |
+| `/workflow:status` | Any | Show current progress |
+
+## Status Tracking
+
+I maintain workflow state in `project-management/workflow-status.yaml`:
+
+```yaml
+project: my-project
+track: standard
+started_at: 2026-01-07T10:00:00Z
+current_phase: planning
+
+phases:
+  analysis:
+    status: skipped  # Standard track skips analysis
+  planning:
+    status: in_progress
+    started_at: 2026-01-07T10:00:00Z
+    artifacts:
+      prd: complete
+      personas: complete
+      backlog: in_progress
+  design:
+    status: pending
+  implementation:
+    status: pending
+
+next_action: "Complete backlog generation"
+next_command: "/project:generate-backlog"
+```
+
+## Interaction Style
+
+When invoked, I:
+
+1. **Greet and Analyze**: Quickly assess the project context
+2. **Recommend**: Suggest the appropriate track with reasoning
+3. **Confirm**: Ask for user agreement before proceeding
+4. **Guide**: Provide clear next steps and commands
+5. **Track**: Update and report on progress
+
+## Example Interaction
+
+```
+User: I need to add a payment feature to our e-commerce app
+
+Orchestrator: Let me analyze your project context...
+
+📊 Context Analysis:
+• Project: e-commerce-app (Symfony + React)
+• Existing: PRD (v1.0), backlog with 24 completed stories
+• Scope: New feature - payment integration (Stripe)
+
+📋 Recommendation: STANDARD TRACK
+
+This is a significant feature with:
+• External integration (Stripe API)
+• Security implications (PCI compliance)
+• Multiple user stories expected (~8-10)
+• Cross-stack changes (backend + frontend)
+
+Suggested Workflow:
+1. /workflow:plan → Update PRD with payment requirements
+2. /workflow:design → Tech spec for Stripe integration
+3. /workflow:implement → Sprint development
+
+Shall I start with the planning phase?
+```
+
+## Integration Points
+
+I work seamlessly with:
+
+- **Product Owner Agent**: For requirements and prioritization
+- **Tech Lead Agent**: For architecture decisions
+- **TDD Coach**: For implementation guidance
+- **Technology Reviewers**: For code quality
+
+## Anti-Patterns I Prevent
+
+- ❌ Starting implementation without understanding scope
+- ❌ Over-engineering simple bug fixes
+- ❌ Under-planning complex features
+- ❌ Skipping architecture for platform changes
+- ❌ Ignoring existing documentation
+
+## Commands to Invoke Me
+
+```
+/workflow:init                  # Start new workflow
+/workflow:init --quick          # Force Quick Flow
+/workflow:init --enterprise     # Force Enterprise track
+/workflow:status                # Check current progress
+```

package/Dev/i18n/es/Common/checklists/code-review.md

@@ -0,0 +1,153 @@
+# Checklist de Revisión de Código
+
+## Antes de Comenzar la Revisión
+
+- [ ] He leído la descripción del PR
+- [ ] Entiendo el objetivo de los cambios
+- [ ] He verificado los tickets relacionados
+- [ ] Tengo el contexto necesario para revisar
+
+---
+
+## Checklist de Revisión
+
+### 1. Diseño y Arquitectura
+
+- [ ] Los cambios son consistentes con la arquitectura existente
+- [ ] Las responsabilidades están bien separadas (SRP)
+- [ ] No se introduce acoplamiento fuerte
+- [ ] Las abstracciones están en el nivel correcto
+- [ ] Los patrones utilizados son apropiados
+- [ ] Sin sobre-ingeniería
+
+### 2. Calidad del Código
+
+#### Legibilidad
+- [ ] El código es fácil de leer y entender
+- [ ] Los nombres de variables/funciones son explícitos
+- [ ] Las funciones hacen una cosa
+- [ ] Las funciones tienen una longitud razonable (< 50 líneas)
+- [ ] El código es auto-documentado
+
+#### Mantenibilidad
+- [ ] El código es fácilmente modificable
+- [ ] Sin código duplicado
+- [ ] Se evitan números mágicos (constantes nombradas)
+- [ ] Las dependencias están gestionadas correctamente
+
+#### Estándares
+- [ ] Se respetan las convenciones de nombres
+- [ ] El formato es correcto (linter)
+- [ ] Las importaciones están organizadas
+- [ ] Sin código comentado innecesario
+- [ ] Sin TODO sin ticket asociado
+
+### 3. Lógica y Funcionalidad
+
+- [ ] La lógica de negocio es correcta
+- [ ] Los casos extremos están manejados
+- [ ] Las condiciones límite están verificadas
+- [ ] Sin bugs obvios
+- [ ] El comportamiento esperado está implementado
+
+### 4. Manejo de Errores
+
+- [ ] Los errores se manejan apropiadamente
+- [ ] Los mensajes de error son claros y útiles
+- [ ] Las excepciones se usan correctamente
+- [ ] Los casos de fallo están cubiertos
+- [ ] Logging apropiado en error
+
+### 5. Seguridad
+
+- [ ] Sin posibilidad de inyección SQL
+- [ ] Sin posibilidad de XSS
+- [ ] Sin secrets en el código
+- [ ] Validación de entrada de usuario
+- [ ] Autorización verificada si es necesario
+- [ ] Datos sensibles protegidos
+
+### 6. Rendimiento
+
+- [ ] Sin consultas N+1
+- [ ] Sin operaciones costosas en bucles
+- [ ] Índices utilizados correctamente
+- [ ] Caché apropiado
+- [ ] Sin fugas de memoria
+- [ ] Complejidad algorítmica aceptable
+
+### 7. Tests
+
+- [ ] Tests unitarios presentes y relevantes
+- [ ] Tests cubren casos nominales
+- [ ] Tests cubren casos de error
+- [ ] Tests son legibles
+- [ ] Tests son independientes
+- [ ] Sin tests frágiles (flaky)
+
+### 8. Documentación
+
+- [ ] Código auto-documentado o comentado si es complejo
+- [ ] API documentada si es pública
+- [ ] README actualizado si es necesario
+- [ ] Cambios de configuración documentados
+
+---
+
+## Tipos de Comentarios
+
+### Bloqueante (❌)
+Debe ser corregido antes del merge.
+```
+❌ Esta consulta puede causar inyección SQL
+```
+
+### Importante (⚠️)
+Debería ser corregido, salvo justificación.
+```
+⚠️ Esta función podría beneficiarse de extracción
+```
+
+### Sugerencia (💡)
+Mejora posible, no obligatoria.
+```
+💡 Podríamos simplificar esta condición
+```
+
+### Pregunta (❓)
+Solicitud de aclaración.
+```
+❓ ¿Por qué esta elección de implementación?
+```
+
+### Positivo (✅)
+Feedback positivo sobre el código.
+```
+✅ ¡Buen uso del patrón aquí!
+```
+
+---
+
+## Mejores Prácticas del Revisor
+
+1. **Ser constructivo** - Criticar el código, no la persona
+2. **Ser preciso** - Dar ejemplos o sugerencias
+3. **Ser respetuoso** - Usar tono benevolente
+4. **Ser reactivo** - Responder rápidamente a discusiones
+5. **Ser consistente** - Aplicar los mismos estándares a todos
+
+## Mejores Prácticas del Autor
+
+1. **Proporcionar contexto** - Descripción clara del PR
+2. **PRs pequeños** - Más fácil de revisar
+3. **Auto-revisión** - Releer antes de solicitar revisión
+4. **Responder a comentarios** - No ignorar
+5. **Aprender** - Usar feedback para mejorar
+
+---
+
+## Decisión de Revisión
+
+- [ ] **Aprobado** - Listo para merge
+- [ ] **Solicitar cambios** - Cambios necesarios
+- [ ] **Comentar** - Preguntas o sugerencias sin bloquear

package/Dev/i18n/es/Common/checklists/definition-of-done.md

@@ -0,0 +1,104 @@
+# Definition of Done (DoD)
+
+## Checklist General
+
+Una tarea se considera "Done" cuando se cumplen TODOS los siguientes criterios:
+
+### Código
+
+- [ ] El código está escrito y sigue las convenciones del proyecto
+- [ ] El código compila sin errores ni advertencias
+- [ ] El código ha pasado revisión de código
+- [ ] El código está fusionado en la rama principal
+- [ ] Los conflictos de merge están resueltos
+
+### Tests
+
+- [ ] Tests unitarios escritos y pasando (cobertura > 80%)
+- [ ] Tests de integración escritos y pasando
+- [ ] Tests E2E pasando (si aplica)
+- [ ] Tests de regresión pasando
+- [ ] Tests manuales realizados y validados
+
+### Documentación
+
+- [ ] Documentación técnica actualizada (si es necesario)
+- [ ] Documentación de usuario actualizada (si es necesario)
+- [ ] Comentarios en código para partes complejas
+- [ ] README actualizado si se requiere nueva configuración
+- [ ] CHANGELOG actualizado
+
+### Calidad
+
+- [ ] Análisis estático pasado (linter, verificador de tipos)
+- [ ] Sin deuda técnica introducida (o documentada si es inevitable)
+- [ ] Revisión de código aprobada por al menos 1 desarrollador
+- [ ] Rendimiento verificado (sin degradación)
+- [ ] Seguridad verificada (OWASP)
+
+### Despliegue
+
+- [ ] Build CI/CD pasando
+- [ ] Desplegado en entorno de staging
+- [ ] Probado en staging
+- [ ] Configuración de producción lista
+- [ ] Plan de rollback documentado (si aplica)
+
+### Validación de Negocio
+
+- [ ] Criterios de aceptación validados
+- [ ] Demo al Product Owner (si aplica)
+- [ ] Feedback integrado
+
+---
+
+## DoD por Tipo de Tarea
+
+### Corrección de Bug
+
+- [ ] Bug reproducido y documentado
+- [ ] Causa raíz identificada
+- [ ] Corrección implementada
+- [ ] Test de no regresión agregado
+- [ ] Probado en entornos afectados
+
+### Nueva Característica
+
+- [ ] User story entendida y validada
+- [ ] Diseño/UX validado (si aplica)
+- [ ] Implementación completa
+- [ ] Tests exhaustivos
+- [ ] Feature flag si es necesario
+- [ ] Analytics/tracking configurado (si aplica)
+
+### Refactoring
+
+- [ ] Alcance del refactoring definido
+- [ ] Tests existentes siguen pasando
+- [ ] Sin cambio de comportamiento
+- [ ] Rendimiento igual o mejor
+- [ ] Revisión de código exhaustiva
+
+### Tarea Técnica
+
+- [ ] Objetivo técnico alcanzado
+- [ ] Documentación técnica completa
+- [ ] Impacto en otros componentes verificado
+- [ ] Plan de migración si es necesario
+
+---
+
+## Excepciones
+
+Las excepciones a la DoD deben ser:
+1. Documentadas en el ticket
+2. Aprobadas por el Tech Lead
+3. Seguidas por un ticket de deuda técnica
+
+---
+
+## Revisión
+
+Esta Definition of Done se revisa en cada retrospectiva de sprint si es necesario.
+
+Última actualización: YYYY-MM-DD

package/Dev/i18n/es/Common/checklists/release.md

@@ -0,0 +1,176 @@
+# Checklist de Release
+
+## Pre-Release (D-7 a D-1)
+
+### Planificación
+
+- [ ] Fecha de release confirmada
+- [ ] Alcance del release finalizado (características, correcciones)
+- [ ] Notas de release escritas
+- [ ] Comunicación planificada (interna + externa)
+- [ ] Soporte informado de los cambios
+- [ ] Documentación actualizada
+
+### Código
+
+- [ ] Feature freeze respetado
+- [ ] Todos los PRs fusionados
+- [ ] Revisiones de código completas
+- [ ] Sin TODOs críticos pendientes
+- [ ] Rama de release creada (si aplica)
+- [ ] Versión incrementada (package.json, build.gradle, etc.)
+
+### Tests
+
+- [ ] Tests unitarios pasando (100%)
+- [ ] Tests de integración pasando
+- [ ] Tests E2E pasando
+- [ ] Tests de rendimiento validados
+- [ ] Tests de seguridad validados
+- [ ] Tests de regresión completos
+- [ ] UAT (User Acceptance Testing) validado
+
+### Infraestructura
+
+- [ ] Entorno de producción listo
+- [ ] Configuración de producción verificada
+- [ ] Escalado configurado si es necesario
+- [ ] Monitoreo en su lugar
+- [ ] Alertas configuradas
+- [ ] Backups verificados
+
+---
+
+## Día del Release (D-Day)
+
+### Antes del Despliegue
+
+- [ ] Equipo de release briefeado
+- [ ] Canales de comunicación listos (Slack, email)
+- [ ] Plan de rollback listo y probado
+- [ ] Ventana de mantenimiento comunicada (si aplica)
+- [ ] Soporte en standby
+- [ ] Base de datos respaldada
+
+### Despliegue
+
+- [ ] Despliegue final en staging OK
+- [ ] Smoke tests en staging OK
+- [ ] Tag de release creado
+- [ ] Despliegue a producción lanzado
+- [ ] Monitoreo observado durante despliegue
+- [ ] Smoke tests en producción OK
+
+### Verificación Post-Despliegue
+
+- [ ] Aplicación accesible
+- [ ] Funcionalidades críticas verificadas
+- [ ] Sin errores en logs
+- [ ] Métricas de rendimiento normales
+- [ ] Sin alertas disparadas
+- [ ] Integraciones de terceros funcionales
+
+---
+
+## Post-Release (D+1 a D+7)
+
+### Monitoreo
+
+- [ ] Tasa de error normal (< 0.1%)
+- [ ] Tiempo de respuesta aceptable
+- [ ] Sin degradación de rendimiento
+- [ ] Feedback de usuarios recopilado
+- [ ] Tickets de soporte rastreados
+
+### Comunicación
+
+- [ ] Notas de release publicadas
+- [ ] Equipo interno informado
+- [ ] Clientes/usuarios notificados
+- [ ] Post de blog / changelog actualizado
+
+### Documentación
+
+- [ ] Documentación técnica actualizada
+- [ ] Runbook actualizado si es necesario
+- [ ] Post-mortem si hubo incidentes
+- [ ] Lecciones aprendidas documentadas
+
+### Limpieza
+
+- [ ] Ramas de release fusionadas/eliminadas
+- [ ] Feature flags limpiados
+- [ ] Entornos de prueba limpiados
+- [ ] Recursos temporales eliminados
+
+---
+
+## Checklist de Rollback
+
+En caso de problema crítico:
+
+- [ ] Decisión de rollback tomada (criterios definidos de antemano)
+- [ ] Comunicación inmediata al equipo
+- [ ] Rollback ejecutado
+- [ ] Verificación del rollback
+- [ ] Comunicación a usuarios
+- [ ] Post-mortem programado
+
+### Criterios de Rollback
+
+- [ ] Tasa de error > 5%
+- [ ] Funcionalidad crítica no funcionando
+- [ ] Pérdida de datos detectada
+- [ ] Vulnerabilidad de seguridad descubierta
+- [ ] Impacto empresarial importante
+
+---
+
+## Tipos de Release
+
+### Release Mayor (X.0.0)
+
+- [ ] Todos los criterios anteriores
+- [ ] Comunicación de marketing
+- [ ] Capacitación del equipo de soporte
+- [ ] Guía de migración si hay cambios incompatibles
+- [ ] Testing beta previo
+
+### Release Menor (x.Y.0)
+
+- [ ] Criterios estándar
+- [ ] Notas de release detalladas
+- [ ] Notificación a usuarios
+
+### Patch (x.y.Z)
+
+- [ ] Tests dirigidos a la corrección
+- [ ] Despliegue rápido posible
+- [ ] Comunicación si es crítico
+
+### Hotfix
+
+- [ ] Proceso acelerado
+- [ ] Tests mínimos pero esenciales
+- [ ] Despliegue inmediato
+- [ ] Post-mortem obligatorio
+
+---
+
+## Contactos de Emergencia
+
+| Rol | Nombre | Contacto |
+|------|------|---------|
+| Release Manager | | |
+| Tech Lead | | |
+| DevOps | | |
+| Support Lead | | |
+| Product Owner | | |
+
+---
+
+## Historial de Releases
+
+| Versión | Fecha | Estado | Notas |
+|---------|------|--------|-------|
+| | | | |