diff --git a/orchestration/_archive/_definitions/_INDEX.yml b/orchestration/_archive/_definitions/_INDEX.yml deleted file mode 100644 index 897d094..0000000 --- a/orchestration/_archive/_definitions/_INDEX.yml +++ /dev/null @@ -1,82 +0,0 @@ -# ═══════════════════════════════════════════════════════════════════════════════ -# ÍNDICE DE DEFINICIONES CANÓNICAS - CLINICA-VETERINARIA -# ═══════════════════════════════════════════════════════════════════════════════ - -version: "1.0.0" -created: "2026-01-18" -updated: "2026-01-18" -maintained_by: "@WS_ORCHESTRATOR" -propagated_from: "erp-clinicas/orchestration/_definitions/" -role: "CONSUMER" # Especialización de erp-clinicas - -# ───────────────────────────────────────────────────────────────────────────────── -# PROTOCOLOS -# ───────────────────────────────────────────────────────────────────────────────── - -protocols: - CCA-PROTOCOL: - alias: "@DEF_CCA" - path: "protocols/CCA-PROTOCOL.md" - estado: "PROPAGADO" - CAPVED-CYCLE: - alias: "@DEF_CAPVED" - path: "protocols/CAPVED-CYCLE.md" - estado: "PROPAGADO" - -validations: - VALIDATION-BACKEND: - alias: "@DEF_VAL_BE" - path: "validations/VALIDATION-BACKEND.md" - estado: "PROPAGADO" - VALIDATION-FRONTEND: - alias: "@DEF_VAL_FE" - path: "validations/VALIDATION-FRONTEND.md" - estado: "PROPAGADO" - VALIDATION-DDL: - alias: "@DEF_VAL_DDL" - path: "validations/VALIDATION-DDL.md" - estado: "PROPAGADO" - -checklists: - CHECKLIST-GOBERNANZA-TAREA: - alias: "@DEF_CHK_GOB" - path: "checklists/CHECKLIST-GOBERNANZA-TAREA.md" - estado: "PROPAGADO" - CHECKLIST-POST-TASK: - alias: "@DEF_CHK_POST" - path: "checklists/CHECKLIST-POST-TASK.md" - estado: "PROPAGADO" - CHECKLIST-PRE-CREATE: - alias: "@DEF_CHK_CREATE" - path: "checklists/CHECKLIST-PRE-CREATE.md" - estado: "PROPAGADO" - CHECKLIST-PRE-MODIFY: - alias: "@DEF_CHK_MODIFY" - path: "checklists/CHECKLIST-PRE-MODIFY.md" - estado: "PROPAGADO" - -statistics: - total_definitions: 9 - propagated: 9 - -# ───────────────────────────────────────────────────────────────────────────────── -# CONFIGURACIÓN DE HERENCIA (SPECIALIZES) -# ───────────────────────────────────────────────────────────────────────────────── - -consumer_config: - role: "CONSUMER" - inherits_from: "erp-clinicas" # Especialización de erp-clinicas - inherits_version: "1.0.0" - tipo_herencia: "SPECIALIZES" - modulos_heredados: - - pacientes (adaptado a mascotas) - - citas - - expedientes (adaptado) - modulos_propios: - - mascotas - - vacunacion - - hospitalizacion - propagates_to: [] - sync_strategy: "AUTO" - vertical: "clinica-veterinaria" - nota: "Clínica veterinaria especializada - hereda de erp-clinicas" diff --git a/orchestration/_archive/_definitions/checklists/CHECKLIST-GOBERNANZA-TAREA.md b/orchestration/_archive/_definitions/checklists/CHECKLIST-GOBERNANZA-TAREA.md deleted file mode 100644 index e71dd47..0000000 --- a/orchestration/_archive/_definitions/checklists/CHECKLIST-GOBERNANZA-TAREA.md +++ /dev/null @@ -1,223 +0,0 @@ -# CHECKLIST: GOBERNANZA DE TAREA - -**Versión:** 1.0.0 -**Alias:** @DEF_CHK_GOB -**Fecha:** 2026-01-16 -**Sistema:** SIMCO v4.0.0 -**Prioridad:** P0 - BLOQUEANTE - ---- - -## PROPÓSITO - -Este checklist es **OBLIGATORIO** y **BLOQUEANTE** para toda tarea que se marque como completada. -Debe ejecutarse ANTES de cualquier otra validación post-tarea. - -> **REGLA:** Sin gobernanza documentada, la tarea NO está completada. - ---- - -## SECUENCIA DE EJECUCIÓN - -``` -TAREA FINALIZA EJECUCIÓN - │ - ▼ -┌─────────────────────────────┐ -│ CHECKLIST-GOBERNANZA-TAREA │ ← PRIMERO (este checklist) -│ (BLOQUEANTE) │ -└─────────────┬───────────────┘ - │ - ▼ - ¿Todos los items pasan? - / \ - Sí No - │ │ - ▼ ▼ -CHECKLIST-POST-TASK BLOQUEAR -(validaciones (no continuar - técnicas) hasta resolver) -``` - ---- - -## CHECKLIST (8 Items) - -### 1. Carpeta de Tarea - -```markdown -[ ] Existe carpeta: orchestration/tareas/TASK-{YYYY-MM-DD}-{NNN}/ -``` - -**Si no existe:** -```bash -# Crear carpeta -mkdir -p orchestration/tareas/TASK-$(date +%Y-%m-%d)-00X - -# Copiar templates -cp -r orchestration/tareas/_templates/TASK-TEMPLATE/* orchestration/tareas/TASK-$(date +%Y-%m-%d)-00X/ -``` - -### 2. METADATA.yml - -```markdown -[ ] METADATA.yml existe y tiene campos obligatorios: - [ ] task_id - [ ] identificacion.titulo - [ ] identificacion.tipo - [ ] responsabilidad.agente_responsable - [ ] alcance.nivel - [ ] temporalidad.fecha_inicio - [ ] estado.actual = "completada" - [ ] artefactos.archivos_creados (lista) - [ ] artefactos.archivos_modificados (lista) -``` - -### 3. Fase C - Contexto (OBLIGATORIA) - -```markdown -[ ] 01-CONTEXTO.md existe y documenta: - [ ] Qué se solicitó - [ ] Por qué se necesita - [ ] Proyecto/módulo afectado - [ ] Contexto cargado -``` - -### 4. Fase E - Ejecución (OBLIGATORIA) - -```markdown -[ ] 05-EJECUCION.md existe y documenta: - [ ] Subtareas ejecutadas - [ ] Archivos creados/modificados - [ ] Validaciones ejecutadas - [ ] Problemas encontrados y cómo se resolvieron -``` - -### 5. Fase D - Documentación (OBLIGATORIA) - -```markdown -[ ] 06-DOCUMENTACION.md existe y documenta: - [ ] Resumen de cambios - [ ] Inventarios actualizados - [ ] Propagación evaluada - [ ] Referencias actualizadas -``` - -### 6. Índice de Tareas - -```markdown -[ ] orchestration/tareas/_INDEX.yml actualizado: - [ ] Estadísticas actualizadas - [ ] Tarea en historial_por_fecha - [ ] Tarea en por_proyecto - [ ] Tarea en por_agente - [ ] Tarea en por_tipo -``` - -### 7. Traza de Agente (Recomendado) - -```markdown -[ ] orchestration/agents/trazas/TRAZA-AGENTE-{PERFIL}.md actualizada - O -[ ] Excepción documentada en METADATA.yml -``` - -### 8. Validación Final - -```markdown -[ ] Carpeta de tarea contiene mínimo: - - METADATA.yml (completo) - - 01-CONTEXTO.md (documentado) - - 05-EJECUCION.md (documentado) - - 06-DOCUMENTACION.md (documentado) -``` - ---- - -## DECISIÓN - -```yaml -SI_PASA_TODO: - accion: "Continuar con CHECKLIST-POST-TASK" - nota: "Gobernanza validada" - -SI_FALLA_CUALQUIER_ITEM: - accion: "BLOQUEAR" - mensaje: | - ❌ GOBERNANZA INCOMPLETA - - La tarea NO puede marcarse como completada. - Items faltantes: - - {lista de items faltantes} - - Acciones requeridas: - 1. Completar items faltantes - 2. Re-ejecutar este checklist - 3. Continuar con validaciones técnicas -``` - ---- - -## TEMPLATE RÁPIDO - -Para crear documentación de gobernanza rápidamente: - -```bash -# Variables -TASK_ID="TASK-$(date +%Y-%m-%d)-00X" -TASK_DIR="orchestration/tareas/$TASK_ID" - -# 1. Crear estructura -mkdir -p $TASK_DIR -cp orchestration/tareas/_templates/TASK-TEMPLATE/* $TASK_DIR/ - -# 2. Completar METADATA.yml -# 3. Documentar 01-CONTEXTO.md -# 4. Documentar 05-EJECUCION.md -# 5. Documentar 06-DOCUMENTACION.md -# 6. Actualizar _INDEX.yml -``` - ---- - -## INTEGRACIÓN CON TODOLIST - -Al iniciar cualquier tarea, el TodoList DEBE incluir: - -```yaml -todos: - # ... otras tareas ... - - # SIEMPRE al final: - - content: "Crear documentación de gobernanza (TASK-{ID})" - status: "pending" - activeForm: "Documentando gobernanza" -``` - ---- - -## USO - -```yaml -# En cualquier perfil de agente: -al_completar_trabajo_tecnico: - - Cargar: "@DEF_CHK_GOB" - - Ejecutar: "8 items de gobernanza" - - Si pasa: "Continuar con @DEF_CHK_POST" - - Si falla: "Completar gobernanza primero" -``` - ---- - -## REFERENCIAS - -| Alias | Descripción | -|-------|-------------| -| @DEF_CHK_GOB | Este checklist | -| @DEF_CHK_POST | Checklist post-tarea (validaciones técnicas) | -| @TRIGGER-DOC | Trigger de documentación obligatoria | -| @TAREAS | Directorio de tareas | - ---- - -**Versión:** 1.0.0 | **Sistema:** SIMCO v4.0.0 | **Tipo:** Checklist Bloqueante diff --git a/orchestration/_archive/_definitions/checklists/CHECKLIST-POST-TASK.md b/orchestration/_archive/_definitions/checklists/CHECKLIST-POST-TASK.md deleted file mode 100644 index e1d036a..0000000 --- a/orchestration/_archive/_definitions/checklists/CHECKLIST-POST-TASK.md +++ /dev/null @@ -1,244 +0,0 @@ -# CHECKLIST: POST-TASK - -**Versión:** 1.1.0 -**Alias:** @DEF_CHK_POST -**Fecha:** 2026-01-16 -**Sistema:** SIMCO v4.0.0 - ---- - -## PROPÓSITO - -Verificaciones obligatorias DESPUÉS de completar cualquier tarea, antes de marcarla como terminada. - ---- - -## SECUENCIA OBLIGATORIA - -``` -TAREA FINALIZA EJECUCIÓN - │ - ▼ -┌─────────────────────────────┐ -│ 0. GOBERNANZA │ ← PRIMERO (BLOQUEANTE) -│ (@DEF_CHK_GOB) │ -└─────────────┬───────────────┘ - ¿Pasa? - / \ - No Sí - │ │ - BLOQUEAR ▼ - ┌─────────────────────────────┐ - │ 1-7. VALIDACIONES TÉCNICAS │ - │ (este checklist) │ - └─────────────────────────────┘ -``` - ---- - -## CHECKLIST - -### 0. Gobernanza de Tarea (BLOQUEANTE - EJECUTAR PRIMERO) - -> **OBLIGATORIO:** Ejecutar @DEF_CHK_GOB antes de continuar. - -```markdown -[ ] CHECKLIST-GOBERNANZA-TAREA.md ejecutado y PASADO - - Carpeta de tarea existe - - METADATA.yml completo - - Fases C, E, D documentadas - - _INDEX.yml actualizado - -SI NO PASA: DETENER. Completar gobernanza primero. -``` - ---- - -### 1. Validaciones Técnicas - -#### Backend (si aplica) -```markdown -[ ] npm run build - PASA -[ ] npm run lint - PASA -[ ] npm run test - PASA (si existen tests) -[ ] Servidor inicia sin errores -``` - -#### Frontend (si aplica) -```markdown -[ ] npm run build - PASA -[ ] npm run lint - PASA -[ ] npm run typecheck - PASA -[ ] Aplicación renderiza sin errores -``` - -#### Database (si aplica) -```markdown -[ ] DDL ejecuta sin errores -[ ] Datos de prueba cargan correctamente -[ ] Constraints funcionan como esperado -``` - -### 2. Coherencia Entre Capas (TRIGGER-COHERENCIA-CAPAS) - -```markdown -## DDL ↔ Backend -[ ] Toda tabla DDL tiene entity correspondiente (o excepción documentada) -[ ] Toda entity tiene tabla DDL correspondiente (o es View/Embeddable) -[ ] Campos de entity coinciden exactamente con columnas de tabla -[ ] Tipos TypeScript son compatibles con tipos PostgreSQL -[ ] Todo schema tiene al menos un módulo backend (o está marcado PLANNED) - -## Backend ↔ Frontend (si aplica) -[ ] Todo endpoint consumido tiene implementación en backend -[ ] Si hay nuevo endpoint: está documentado en Swagger -[ ] Si hay nuevo componente: está integrado donde corresponde - -## Verificación de Excepciones -[ ] Tablas M:N sin entity están documentadas en ENTITIES-CATALOG sección "Relaciones" -[ ] View entities (@ViewEntity) están documentadas como tal -[ ] Schemas PLANNED tienen fecha estimada de implementación -``` - -### 3. Actualización de Inventarios (TRIGGER-INVENTARIOS-SINCRONIZADOS) - -```markdown -## Sincronización Obligatoria -[ ] DATABASE_INVENTORY.yml actualizado (si cambió BD) - - Conteo de schemas correcto - - Conteo de tablas correcto - - Nuevos objetos agregados -[ ] BACKEND_INVENTORY.yml actualizado (si cambió BE) - - Conteo de módulos correcto - - Conteo de entities correcto - - Conteo de services correcto -[ ] FRONTEND_INVENTORY.yml actualizado (si cambió FE) - - Conteo de componentes correcto - - Conteo de páginas correcto -[ ] MASTER_INVENTORY.yml actualizado con totales - -## Verificación de Cobertura -[ ] Cobertura de inventarios = 100% -[ ] Timestamp de actualización = fecha de hoy -[ ] sync_status = "SYNCED" -``` - -### 4. Actualización de Trazas - -```markdown -[ ] Traza de tarea actualizada -[ ] Traza de agente actualizada -[ ] PROXIMA-ACCION.md actualizado -[ ] Commits con mensajes descriptivos -``` - -### 5. Documentación - -```markdown -[ ] README actualizado (si cambió significativamente) -[ ] Documentación técnica actualizada (si aplica) -[ ] ADR creado (si fue decisión arquitectural) -[ ] Comentarios en código donde la lógica no es obvia -``` - -### 6. Sistema de Gobernanza - -```markdown -[ ] Carpeta de tarea creada: orchestration/tareas/TASK-{ID}/ -[ ] METADATA.yml completado -[ ] Fases mínimas documentadas (C, E, D) -[ ] _INDEX.yml de tareas actualizado -[ ] Traza de agente actualizada -``` - -### 7. Evaluación de Propagación - -```markdown -[ ] ¿Cambio debe propagarse a otros proyectos? -[ ] Si es erp-core: ¿propagar a verticales? -[ ] Si es shared/catalog: ¿notificar proyectos que lo usan? -[ ] Si es security fix: ¿propagar inmediatamente? -``` - ---- - -## CRITERIOS DE COMPLETITUD - -### Tarea Completada SI: - -```yaml -obligatorio: - - Todas las validaciones técnicas pasan - - Inventarios actualizados - - Trazas actualizadas - - Documentación de gobernanza creada - -recomendado: - - Documentación técnica actualizada - - Tests agregados/actualizados - - Propagación evaluada -``` - -### Tarea NO Completada SI: - -```yaml -bloqueantes: - - Build falla - - Lint falla - - Tests fallan - - Inventarios no actualizados - - Sin documentación de gobernanza -``` - ---- - -## DECISIÓN - -```yaml -SI_PASA_TODO: - accion: "Marcar tarea como COMPLETADA" - documentar: "Resumen en METADATA.yml" - actualizar: "_INDEX.yml con estado COMPLETADO" - -SI_FALLA_VALIDACION: - accion: "MANTENER como EN_PROGRESO" - corregir: "Resolver validaciones fallidas" - reintentar: "Ejecutar checklist de nuevo" - -SI_FALTA_DOCUMENTACION: - accion: "MANTENER como EN_PROGRESO" - completar: "Documentación faltante" - nota: "Tarea no está completa sin documentación" -``` - ---- - -## USO - -```yaml -# En cualquier perfil de agente: -al_completar_tarea: - - Cargar: "@DEF_CHK_POST" - - Ejecutar: "Checklist completo" - - Si pasa: "Marcar tarea como completada" - - Si falla: "Resolver antes de marcar completada" -``` - ---- - -## INTEGRACIÓN CON TRIGGER-DOC - -Este checklist se activa junto con `TRIGGER-DOCUMENTACION-OBLIGATORIA.md` al intentar completar una tarea. - -```yaml -secuencia: - 1: "Agente intenta marcar tarea como completada" - 2: "TRIGGER-DOC se activa" - 3: "Se ejecuta CHECKLIST-POST-TASK" - 4: "Si pasa: tarea se marca completada" - 5: "Si falla: tarea permanece en progreso" -``` - ---- - -**Versión:** 1.0.0 | **Sistema:** SIMCO v4.0.0 | **Tipo:** Checklist diff --git a/orchestration/_archive/_definitions/checklists/CHECKLIST-PRE-CREATE.md b/orchestration/_archive/_definitions/checklists/CHECKLIST-PRE-CREATE.md deleted file mode 100644 index 7dac19c..0000000 --- a/orchestration/_archive/_definitions/checklists/CHECKLIST-PRE-CREATE.md +++ /dev/null @@ -1,107 +0,0 @@ -# CHECKLIST: PRE-CREATE - -**Versión:** 1.0.0 -**Alias:** @DEF_CHK_CREATE -**Fecha:** 2026-01-16 -**Sistema:** SIMCO v4.0.0 - ---- - -## PROPÓSITO - -Verificaciones obligatorias ANTES de crear cualquier objeto nuevo (tabla, entity, service, componente, etc.). - ---- - -## CHECKLIST - -### 1. Verificación Anti-Duplicación - -```markdown -[ ] Buscar en catálogo compartido (shared/catalog/CATALOG-INDEX.yml) -[ ] Buscar en inventario del proyecto (orchestration/inventarios/) -[ ] Buscar archivos similares con nombre parecido -[ ] Buscar funcionalidad similar en módulos existentes -[ ] Confirmar que NO existe funcionalidad equivalente -``` - -### 2. Verificación de Dependencias - -```markdown -[ ] Identificar de qué depende el nuevo objeto -[ ] Verificar que las dependencias existen -[ ] Si depende de DDL: tabla existe en base de datos -[ ] Si depende de entity: entity existe en backend -[ ] Si depende de endpoint: endpoint existe y funciona -``` - -### 3. Verificación de Ubicación - -```markdown -[ ] Identificar módulo/carpeta correcta según estándares -[ ] Verificar que la ruta sigue convenciones del proyecto -[ ] Confirmar que no hay conflicto de nombres -[ ] Verificar permisos de escritura en la ubicación -``` - -### 4. Verificación de Nomenclatura - -```markdown -[ ] Nombre sigue convenciones del proyecto -[ ] Nombre es descriptivo y no ambiguo -[ ] Prefijos/sufijos correctos según tipo de archivo -[ ] Formato de archivo correcto (PascalCase, kebab-case, etc.) -``` - -### 5. Verificación de Coherencia - -```markdown -[ ] Nuevo objeto es coherente con arquitectura existente -[ ] No introduce acoplamiento innecesario -[ ] Sigue patrones establecidos del proyecto -[ ] No duplica responsabilidades de otros objetos -``` - ---- - -## DECISIÓN - -```yaml -SI_PASA_TODO: - accion: "Proceder con creación" - siguiente: "Ejecutar SIMCO-CREAR.md" - -SI_FALLA_DUPLICACION: - accion: "DETENER - Evaluar uso del existente" - opciones: - - "Usar objeto existente" - - "Extender objeto existente" - - "Justificar creación de nuevo (documentar razón)" - -SI_FALLA_DEPENDENCIA: - accion: "DETENER - Resolver dependencia primero" - opciones: - - "Delegar creación de dependencia" - - "Crear dependencia primero" - - "Replanificar orden de tareas" - -SI_FALLA_NOMENCLATURA: - accion: "Corregir nombre antes de crear" - consultar: "@SIMCO/SIMCO-NOMENCLATURA.md" -``` - ---- - -## USO - -```yaml -# En perfil de agente: -antes_de_crear: - - Cargar: "@DEF_CHK_CREATE" - - Ejecutar: "Checklist completo" - - Documentar: "Resultado en traza" -``` - ---- - -**Versión:** 1.0.0 | **Sistema:** SIMCO v4.0.0 | **Tipo:** Checklist diff --git a/orchestration/_archive/_definitions/checklists/CHECKLIST-PRE-MODIFY.md b/orchestration/_archive/_definitions/checklists/CHECKLIST-PRE-MODIFY.md deleted file mode 100644 index edc8d54..0000000 --- a/orchestration/_archive/_definitions/checklists/CHECKLIST-PRE-MODIFY.md +++ /dev/null @@ -1,149 +0,0 @@ -# CHECKLIST: PRE-MODIFY - -**Versión:** 1.0.0 -**Alias:** @DEF_CHK_MODIFY -**Fecha:** 2026-01-16 -**Sistema:** SIMCO v4.0.0 - ---- - -## PROPÓSITO - -Verificaciones obligatorias ANTES de modificar cualquier archivo existente. - ---- - -## CHECKLIST - -### 1. Análisis de Dependientes - -```markdown -[ ] Identificar archivos que IMPORTAN el archivo a modificar -[ ] Listar todos los dependientes encontrados -[ ] Evaluar impacto del cambio en cada dependiente -[ ] Clasificar cambio como: aditivo | modificación | breaking -``` - -### 2. Análisis de Dependencias - -```markdown -[ ] Identificar archivos que el archivo IMPORTA -[ ] Verificar que las dependencias siguen siendo válidas post-cambio -[ ] Identificar si el cambio requiere actualizar dependencias -``` - -### 3. Evaluación de Impacto - -```markdown -[ ] Determinar alcance: local | módulo | proyecto | workspace -[ ] Identificar capas afectadas: DDL | BE | FE -[ ] Evaluar si cambio requiere migración de datos -[ ] Evaluar si cambio rompe compatibilidad hacia atrás -``` - -### 4. Plan de Actualización - -```markdown -[ ] Si hay dependientes afectados: incluir en plan de subtareas -[ ] Ordenar actualizaciones por dependencia (de más interno a más externo) -[ ] Identificar tests que deben actualizarse -[ ] Identificar documentación que debe actualizarse -``` - -### 5. Verificación de Seguridad - -```markdown -[ ] Cambio no introduce vulnerabilidades de seguridad -[ ] Cambio no expone datos sensibles -[ ] Cambio mantiene validaciones existentes -[ ] Si es API: cambio no rompe contratos existentes -``` - -### 6. Estrategia de Rollback - -```markdown -[ ] Identificar cómo revertir el cambio si falla -[ ] Confirmar que existe backup o commit previo -[ ] Documentar pasos de rollback si son complejos -``` - ---- - -## CLASIFICACIÓN DE CAMBIOS - -### Cambio Aditivo (BAJO RIESGO) -```yaml -caracteristicas: - - Agregar campo/método nuevo - - Agregar endpoint nuevo - - No modifica comportamiento existente -acciones: - - Actualizar dependientes que usarán lo nuevo - - Validación estándar -``` - -### Cambio de Modificación (MEDIO RIESGO) -```yaml -caracteristicas: - - Cambiar implementación interna - - Cambiar tipos de datos - - Renombrar elementos -acciones: - - Actualizar TODOS los dependientes - - Validación exhaustiva - - Pruebas de regresión -``` - -### Cambio Breaking (ALTO RIESGO) -```yaml -caracteristicas: - - Eliminar campo/método - - Cambiar firma de función/endpoint - - Cambiar comportamiento de API -acciones: - - DETENER y evaluar con Tech-Leader - - Plan de migración obligatorio - - Comunicar a equipos afectados -``` - ---- - -## DECISIÓN - -```yaml -SI_PASA_TODO: - accion: "Proceder con modificación" - siguiente: "Ejecutar SIMCO-MODIFICAR.md" - incluir: "Actualización de dependientes en plan" - -SI_CAMBIO_BREAKING: - accion: "ESCALAR a Tech-Leader" - documentar: - - Razón del cambio breaking - - Alternativas evaluadas - - Plan de migración propuesto - -SI_IMPACTO_ALTO: - accion: "Solicitar revisión antes de proceder" - documentar: - - Alcance del impacto - - Dependientes afectados - - Plan de actualización -``` - ---- - -## USO - -```yaml -# En perfil de agente: -antes_de_modificar: - - Cargar: "@DEF_CHK_MODIFY" - - Ejecutar: "Checklist completo" - - Documentar: "Resultado en traza" - - Si breaking: "Escalar antes de continuar" -``` - ---- - -**Versión:** 1.0.0 | **Sistema:** SIMCO v4.0.0 | **Tipo:** Checklist diff --git a/orchestration/_archive/_definitions/protocols/CAPVED-CYCLE.md b/orchestration/_archive/_definitions/protocols/CAPVED-CYCLE.md deleted file mode 100644 index 9f9a1cb..0000000 --- a/orchestration/_archive/_definitions/protocols/CAPVED-CYCLE.md +++ /dev/null @@ -1,347 +0,0 @@ ---- -tipo: especificacion-tecnica -nivel: 2-tecnico -ssot: /orchestration/directivas/principios/PRINCIPIO-CAPVED.md -audiencia: agentes IA, sistemas automaticos -proposito: Especificacion tecnica del protocolo CAPVED -actualizado: 2026-01-16 ---- - -# PROTOCOLO: CAPVED-CYCLE - -**Versión:** 1.0.0 -**Alias:** @DEF_CAPVED -**Fecha:** 2026-01-16 -**Sistema:** SIMCO v4.0.0 -**SSOT:** [PRINCIPIO-CAPVED.md](/orchestration/directivas/principios/PRINCIPIO-CAPVED.md) - ---- - -## RESUMEN - -CAPVED es el ciclo de vida obligatorio para toda tarea en el workspace. Define 6 fases secuenciales que aseguran calidad, trazabilidad y documentación completa. - -``` -C → A → P → V → E → D -│ │ │ │ │ │ -│ │ │ │ │ └─ DOCUMENTACIÓN (Registrar, trazar, propagar) -│ │ │ │ └───── EJECUCIÓN (Implementar cambios) -│ │ │ └───────── VALIDACIÓN (Gate pre-ejecución) -│ │ └───────────── PLANEACIÓN (Desglosar subtareas) -│ └───────────────── ANÁLISIS (Mapear impacto) -└───────────────────── CONTEXTO (Clasificar y vincular) -``` - ---- - -## FASES DEL CICLO - -### FASE C - CONTEXTO - -**Objetivo:** Clasificar tarea y vincular con proyecto/workspace. - -```yaml -actividades: - - Identificar tipo de tarea (feature/fix/refactor/analysis) - - Identificar proyecto(s) involucrado(s) - - Identificar nivel (workspace/proyecto/módulo) - - Cargar contexto requerido según perfil - - Vincular con épica/user story si aplica - -salidas: - - Tipo de tarea identificado - - Proyecto(s) identificado(s) - - Contexto mínimo viable cargado - - Vinculación establecida - -criterios_completitud: - - Proyecto claramente identificado - - Tipo de tarea determinado - - Contexto base cargado -``` - -### FASE A - ANÁLISIS - -**Objetivo:** Mapear impacto, dependencias y riesgos. - -```yaml -actividades: - - Ejecutar TRIGGER-ANTI-DUPLICACION si es creación - - Ejecutar TRIGGER-ANALISIS-DEPENDENCIAS si es modificación - - Identificar archivos afectados - - Mapear dependientes (quién usa lo que modifico) - - Mapear dependencias (qué usa lo que modifico) - - Evaluar riesgos y complejidad - -salidas: - - Mapa de impacto - - Lista de dependientes - - Lista de dependencias - - Evaluación de riesgos - - Complejidad estimada - -criterios_completitud: - - Impacto mapeado - - Dependencias identificadas - - Riesgos evaluados -``` - -### FASE P - PLANEACIÓN - -**Objetivo:** Desglosar en subtareas por dominio. - -```yaml -actividades: - - Crear lista de subtareas específicas - - Ordenar por dependencia (DDL → BE → FE) - - Identificar subtareas paralelizables - - Asignar perfil responsable por subtarea - - Definir criterios de aceptación por subtarea - -salidas: - - Lista de subtareas (ST-001, ST-002, ...) - - Orden de ejecución - - Asignación de perfiles - - Criterios de aceptación - -criterios_completitud: - - Subtareas definidas - - Orden establecido - - Criterios claros -``` - -### FASE V - VALIDACIÓN (Gate) - -**Objetivo:** Verificar antes de ejecutar. - -```yaml -actividades: - - Verificar que plan cubre todo el impacto - - Verificar que no hay scope creep - - Verificar que dependencias están resueltas - - Verificar que hay capacidad de rollback - - Confirmar alineación con estándares - -salidas: - - Checklist de validación completado - - Decisión GO/NO-GO - -criterios_completitud: - - Todas las verificaciones pasadas - - Decisión GO documentada - -decision: - GO: "Continuar a Fase E" - NO-GO: "Regresar a Fase A o P según hallazgo" -``` - -### FASE E - EJECUCIÓN - -**Objetivo:** Implementar cambios según plan. - -```yaml -actividades: - - Ejecutar subtareas en orden - - Validar cada subtarea (build/lint/test) - - Crear commits atómicos por subtarea - - Documentar problemas encontrados - - Escalar si hay bloqueos - -salidas: - - Código implementado - - Commits realizados - - Validaciones pasadas - - Problemas documentados - -criterios_completitud: - - Todas las subtareas completadas - - Build pasa - - Lint pasa - - Tests pasan (si existen) -``` - -### FASE D - DOCUMENTACIÓN - -**Objetivo:** Registrar, trazar y propagar. - -> **IMPORTANTE:** Esta fase tiene dos sub-fases en orden estricto: -> 1. **D1 - Gobernanza** (BLOQUEANTE) -> 2. **D2 - Técnica** (después de gobernanza) - -```yaml -actividades: - # D1 - GOBERNANZA (PRIMERO - BLOQUEANTE) - d1_gobernanza: - - Crear carpeta de tarea: orchestration/tareas/TASK-{ID}/ - - Completar METADATA.yml - - Documentar 01-CONTEXTO.md (qué y por qué) - - Documentar 05-EJECUCION.md (cómo y qué problemas) - - Documentar 06-DOCUMENTACION.md (resumen y referencias) - - Actualizar orchestration/tareas/_INDEX.yml - - Actualizar traza de agente (opcional pero recomendado) - - # D2 - TÉCNICA (después de gobernanza) - d2_tecnica: - - Actualizar inventarios afectados - - Evaluar propagación (TRIGGER-PROPAGACION-AUTOMATICA) - - Crear/actualizar documentación técnica si aplica - -salidas: - # Gobernanza - - Carpeta de tarea con documentación completa - - _INDEX.yml actualizado - # Técnica - - Inventarios actualizados - - Propagación evaluada/ejecutada - -criterios_completitud: - # Gobernanza (BLOQUEANTE) - - Carpeta TASK-{ID}/ existe - - METADATA.yml completo - - Fases C, E, D documentadas - - _INDEX.yml actualizado - # Técnica - - Inventarios al día - - Propagación evaluada - -validacion: - checklist: "@DEF_CHK_GOB (gobernanza) + @DEF_CHK_POST (técnica)" - orden: "Gobernanza PRIMERO, luego técnica" -``` - ---- - -## MODOS DE EJECUCIÓN - -### MODE-FULL (Por defecto) - -```yaml -fases: [C, A, P, V, E, D] -uso: "Features, bug fixes, refactorizaciones, cambios BD" -alias: "@FULL" -``` - -### MODE-QUICK - -```yaml -fases: [E, D] -uso: "Typos, fixes menores, updates de deps, config simple" -alias: "@QUICK" -condicion: "Cambio trivial sin riesgo de impacto" -``` - -### MODE-ANALYSIS - -```yaml -fases: [C, A, P] -uso: "Investigación, auditoría, exploración, propuestas" -alias: "@ANALYSIS" -nota: "No modifica código" -``` - -### MODE-PROPAGATION - -```yaml -fases: [C, A, P, E, V, D] # Por cada proyecto destino -uso: "Propagar cambio existente a proyectos relacionados" -alias: "@PROPAGATE" -``` - ---- - -## INTEGRACIÓN CON TRIGGERS - -```yaml -triggers_por_fase: - A: - - TRIGGER-ANTI-DUPLICACION (si creación) - - TRIGGER-ANALISIS-DEPENDENCIAS (si modificación) - V: - - TRIGGER-DUPLICADOS (si se detectan) - D: - - TRIGGER-PROPAGACION-AUTOMATICA - - TRIGGER-DOCUMENTACION-OBLIGATORIA -``` - ---- - -## INTEGRACIÓN CON GOBERNANZA - -> **OBLIGATORIO:** Toda tarea que complete el ciclo CAPVED DEBE crear documentación de gobernanza. -> **BLOQUEANTE:** Sin gobernanza, la tarea NO está completada. - -```yaml -gobernanza: - checklist: "@DEF_CHK_GOB" - - pasos: - 1_carpeta_tarea: - accion: "Crear orchestration/tareas/TASK-{ID}/" - bloqueante: true - - 2_metadata: - accion: "Completar METADATA.yml con todos los campos obligatorios" - bloqueante: true - - 3_fases_minimas: - accion: "Documentar 01-CONTEXTO.md, 05-EJECUCION.md, 06-DOCUMENTACION.md" - bloqueante: true - - 4_actualizar_indices: - accion: "Actualizar orchestration/tareas/_INDEX.yml" - bloqueante: true - - 5_traza_agente: - accion: "Actualizar traza del agente ejecutor" - bloqueante: false - nota: "Recomendado pero no bloquea" - - si_falta_gobernanza: - mensaje: "❌ TAREA NO COMPLETADA - Falta documentación de gobernanza" - accion: "BLOQUEAR hasta completar" - referencia: "@DEF_CHK_GOB" - - recordatorio_todolist: | - Al iniciar cualquier tarea, el TodoList DEBE incluir como último item: - - content: "Crear documentación de gobernanza (TASK-{ID})" - status: "pending" - activeForm: "Documentando gobernanza" -``` - ---- - -## VALIDACIONES POR DOMINIO - -### Backend (NestJS) -```bash -npm run build # DEBE pasar -npm run lint # DEBE pasar -npm run test # Si existen, DEBEN pasar -``` - -### Frontend (React) -```bash -npm run build # DEBE pasar -npm run lint # DEBE pasar -npm run typecheck # DEBE pasar -``` - -### Database (PostgreSQL) -```bash -./scripts/recreate-database.sh # DEBE ejecutar sin errores -``` - ---- - -## REFERENCIAS - -| Alias | Descripción | -|-------|-------------| -| @DEF_CAPVED | Este protocolo | -| @PRINCIPIOS/PRINCIPIO-CAPVED.md | Principio base | -| @SIMCO/SIMCO-TAREA.md | Punto de entrada | -| @TRIGGER-DOC | Documentación obligatoria | - ---- - -**Versión:** 1.0.0 | **Sistema:** SIMCO v4.0.0 | **Tipo:** Protocolo Base diff --git a/orchestration/_archive/_definitions/protocols/CCA-PROTOCOL.md b/orchestration/_archive/_definitions/protocols/CCA-PROTOCOL.md deleted file mode 100644 index 3f35e63..0000000 --- a/orchestration/_archive/_definitions/protocols/CCA-PROTOCOL.md +++ /dev/null @@ -1,245 +0,0 @@ -# Protocolo CCA - Carga de Contexto Automática -## Definición Canónica (Fuente Única de Verdad) - -**Versión:** 1.0.0 -**Fecha:** 2026-01-16 -**Alias:** @DEF_CCA -**Tipo:** Definición Canónica - ---- - -## PROPÓSITO - -Este documento es la **ÚNICA** fuente de verdad para el Protocolo CCA. -Todos los perfiles de agentes deben **REFERENCIAR** este archivo, no copiar su contenido. - ---- - -## USO EN PERFILES - -```markdown -## PROTOCOLO CCA -> Definición: @DEF_CCA -> Variante: {dominio} - -### Extensiones Específicas -[Solo contenido específico del dominio] -``` - ---- - -## PROTOCOLO BASE - -> **ANTES de cualquier acción, ejecutar Carga de Contexto Automática** - -```yaml -# Al recibir: "Serás {PERFIL}-Agent en {PROYECTO} para {TAREA}" - -# ═══════════════════════════════════════════════════════════════ -# PASO 0: IDENTIFICAR NIVEL (OBLIGATORIO PRIMERO) -# ═══════════════════════════════════════════════════════════════ -PASO_0_IDENTIFICAR_NIVEL: - leer: "orchestration/directivas/simco/SIMCO-NIVELES.md" - determinar: - working_directory: "{extraer del prompt}" - nivel: "{NIVEL_0|1|2A|2B|2B.1|2B.2|3}" - orchestration_path: "{calcular según nivel}" - propagate_to: ["{niveles superiores si aplica}"] - registrar: - nivel_actual: "{nivel identificado}" - ruta_inventario: "{orchestration_path}/inventarios/" - ruta_traza: "{orchestration_path}/trazas/" - -# ═══════════════════════════════════════════════════════════════ -# PASO 1: IDENTIFICAR CONTEXTO -# ═══════════════════════════════════════════════════════════════ -PASO_1_IDENTIFICAR: - perfil: "{PERFIL}" # Nombre del perfil activo - proyecto: "{PROYECTO}" # Extraer del prompt - tarea: "{TAREA}" # Extraer del prompt - operacion: "CREAR | MODIFICAR | VALIDAR | DOCUMENTAR | BUSCAR" - dominio: "{DOMINIO}" # BACKEND | FRONTEND | DDL | DEVOPS | ML | etc. - -# ═══════════════════════════════════════════════════════════════ -# PASO 2: CARGAR CONTEXTO CORE (SIEMPRE) -# ═══════════════════════════════════════════════════════════════ -PASO_2_CARGAR_CORE: - leer_obligatorio: - # Catálogo primero (evitar duplicados) - - shared/catalog/CATALOG-INDEX.yml - - # Principios fundamentales - - orchestration/directivas/principios/PRINCIPIO-CAPVED.md - - orchestration/directivas/principios/PRINCIPIO-DOC-PRIMERO.md - - orchestration/directivas/principios/PRINCIPIO-ANTI-DUPLICACION.md - - orchestration/directivas/principios/PRINCIPIO-VALIDACION-OBLIGATORIA.md - - orchestration/directivas/principios/PRINCIPIO-ECONOMIA-TOKENS.md - - # Índices y referencias - - orchestration/directivas/simco/_INDEX.md - - orchestration/directivas/simco/SIMCO-TAREA.md - - orchestration/referencias/ALIASES.yml - -# ═══════════════════════════════════════════════════════════════ -# PASO 3: CARGAR CONTEXTO DEL PROYECTO -# ═══════════════════════════════════════════════════════════════ -PASO_3_CARGAR_PROYECTO: - leer_obligatorio: - - projects/{PROYECTO}/orchestration/00-guidelines/CONTEXTO-PROYECTO.md - - projects/{PROYECTO}/orchestration/PROXIMA-ACCION.md - - leer_segun_dominio: - # Ver sección VARIANTES POR DOMINIO - -# ═══════════════════════════════════════════════════════════════ -# PASO 4: CARGAR DIRECTIVAS DE OPERACIÓN -# ═══════════════════════════════════════════════════════════════ -PASO_4_CARGAR_OPERACION: - verificar_catalogo_primero: - - "grep -i '{funcionalidad}' @CATALOG_INDEX" - - si_existe: "Seguir @REUTILIZAR en lugar de crear" - - segun_operacion: - crear: ["SIMCO-CREAR.md", "SIMCO-{DOMINIO}.md"] - modificar: ["SIMCO-MODIFICAR.md", "SIMCO-{DOMINIO}.md"] - validar: ["SIMCO-VALIDAR.md"] - documentar: ["SIMCO-DOCUMENTAR.md"] - buscar: ["SIMCO-BUSCAR.md"] - -# ═══════════════════════════════════════════════════════════════ -# PASO 5: CARGAR CONTEXTO ESPECÍFICO DE TAREA -# ═══════════════════════════════════════════════════════════════ -PASO_5_CARGAR_TAREA: - - "Documentación relevante en docs/" - - "Código existente similar (patrones)" - - "Archivos relacionados con la tarea" - - "Identificar dependencias" - -# ═══════════════════════════════════════════════════════════════ -# PASO 6: VERIFICAR DEPENDENCIAS -# ═══════════════════════════════════════════════════════════════ -PASO_6_VERIFICAR_DEPENDENCIAS: - si_dependencia_no_existe: - accion: "DELEGAR al agente correspondiente" - no_continuar_hasta: "Dependencia resuelta" - - dependencias_por_dominio: - backend: - requiere: "Tablas DDL existen" - delegar_a: "@PERFIL_DATABASE" - frontend: - requiere: "Endpoints API existen" - delegar_a: "@PERFIL_BACKEND" - devops: - requiere: "Código funcional existe" - delegar_a: "@PERFIL_BACKEND o @PERFIL_FRONTEND" - -# ═══════════════════════════════════════════════════════════════ -# RESULTADO -# ═══════════════════════════════════════════════════════════════ -RESULTADO: "READY_TO_EXECUTE - Contexto completo cargado" -``` - ---- - -## VARIANTES POR DOMINIO - -### #backend -```yaml -PASO_3_CARGAR_PROYECTO: - leer_segun_dominio: - - projects/{PROYECTO}/orchestration/inventarios/BACKEND_INVENTORY.yml - - projects/{PROYECTO}/orchestration/inventarios/DATABASE_INVENTORY.yml - -PASO_4_CARGAR_OPERACION: - segun_tarea: - crear_entity: [SIMCO-CREAR.md, SIMCO-BACKEND.md] - crear_service: [SIMCO-CREAR.md, SIMCO-BACKEND.md] - crear_controller: [SIMCO-CREAR.md, SIMCO-BACKEND.md] - crear_dto: [SIMCO-CREAR.md, SIMCO-BACKEND.md] -``` - -### #frontend -```yaml -PASO_3_CARGAR_PROYECTO: - leer_segun_dominio: - - projects/{PROYECTO}/orchestration/inventarios/FRONTEND_INVENTORY.yml - -PASO_4_CARGAR_OPERACION: - segun_tarea: - crear_componente: [SIMCO-CREAR.md, SIMCO-FRONTEND.md] - crear_hook: [SIMCO-CREAR.md, SIMCO-FRONTEND.md] - crear_page: [SIMCO-CREAR.md, SIMCO-FRONTEND.md] -``` - -### #ddl -```yaml -PASO_3_CARGAR_PROYECTO: - leer_segun_dominio: - - projects/{PROYECTO}/orchestration/inventarios/DATABASE_INVENTORY.yml - - projects/{PROYECTO}/ddl/ # Esquemas existentes - -PASO_4_CARGAR_OPERACION: - segun_tarea: - crear_tabla: [SIMCO-CREAR.md, SIMCO-DDL.md] - crear_funcion: [SIMCO-CREAR.md, SIMCO-DDL.md] - crear_trigger: [SIMCO-CREAR.md, SIMCO-DDL.md] - crear_rls: [SIMCO-CREAR.md, SIMCO-DDL.md] -``` - -### #devops -```yaml -PASO_3_CARGAR_PROYECTO: - leer_segun_dominio: - - projects/{PROYECTO}/docker-compose.yml - - projects/{PROYECTO}/.env.example - -PASO_4_CARGAR_OPERACION: - segun_tarea: - crear_dockerfile: [SIMCO-CREAR.md, SIMCO-DEVOPS.md] - crear_pipeline: [SIMCO-CREAR.md, SIMCO-DEVOPS.md] -``` - -### #ml -```yaml -PASO_3_CARGAR_PROYECTO: - leer_segun_dominio: - - projects/{PROYECTO}/orchestration/inventarios/ML_INVENTORY.yml - - projects/{PROYECTO}/models/ - -PASO_4_CARGAR_OPERACION: - segun_tarea: - crear_modelo: [SIMCO-CREAR.md, SIMCO-ML.md] - crear_pipeline_ml: [SIMCO-CREAR.md, SIMCO-ML.md] -``` - ---- - -## VERSIÓN LIGERA (SUBAGENTES) - -Para subagentes con tareas específicas, usar versión reducida: - -```yaml -# CCA Ligero - Solo para subagentes -CCA_LIGHT: - PASO_1: "Identificar perfil, proyecto, tarea" - PASO_2: "Cargar ALIASES.yml" - PASO_3: "Cargar inventario del dominio" - PASO_4: "Cargar SIMCO de operación" - RESULTADO: "READY_TO_EXECUTE" -``` - -Ver también: @DEF_CCA_LIGHT - ---- - -## REFERENCIAS - -- **Perfiles que usan este protocolo:** Todos los perfiles en agents/perfiles/ -- **Directiva relacionada:** SIMCO-INICIALIZACION.md -- **Versión ligera:** @DEF_CCA_LIGHT - ---- - -**Última actualización:** 2026-01-16 -**Mantenido por:** @WS_ORCHESTRATOR diff --git a/orchestration/_archive/_definitions/validations/VALIDATION-BACKEND.md b/orchestration/_archive/_definitions/validations/VALIDATION-BACKEND.md deleted file mode 100644 index 8c15c75..0000000 --- a/orchestration/_archive/_definitions/validations/VALIDATION-BACKEND.md +++ /dev/null @@ -1,81 +0,0 @@ -# Validación Backend - NestJS/TypeScript -## Definición Canónica - -**Alias:** @DEF_VAL_BE -**Dominio:** Backend NestJS/TypeScript - ---- - -## COMANDOS OBLIGATORIOS - -```bash -# ANTES de marcar tarea como completada: -npm run build # DEBE pasar sin errores -npm run lint # DEBE pasar sin errores -npm run test # Si existen tests, DEBEN pasar -``` - -## CRITERIOS DE ACEPTACIÓN - -```yaml -build: - resultado: "Compila sin errores" - archivos_generados: "dist/" - sin_warnings_criticos: true - -lint: - resultado: "0 errores de ESLint" - warnings_permitidos: "Solo menores" - reglas_obligatorias: - - "@typescript-eslint/no-explicit-any" - - "@typescript-eslint/no-unused-vars" - -test: - resultado: "100% tests pasan" - coverage_minimo: "70% (si configurado)" - nuevos_tests: "Crear para código nuevo" -``` - -## VALIDACIONES ADICIONALES - -```yaml -entities: - - "Alineadas con DDL (nombres, tipos)" - - "Relaciones correctamente definidas" - - "Decoradores TypeORM correctos" - -services: - - "Inyección de dependencias correcta" - - "Manejo de errores implementado" - - "Transacciones donde aplique" - -controllers: - - "Decoradores Swagger completos" - - "Validación de DTOs" - - "Guards aplicados" - -dtos: - - "class-validator decoradores" - - "Tipos correctos" - - "Documentación Swagger" -``` - -## ERRORES COMUNES - -```yaml -- error: "Cannot find module" - causa: "Import incorrecto o dependencia faltante" - solucion: "Verificar rutas y npm install" - -- error: "Type X is not assignable to type Y" - causa: "Tipos incompatibles" - solucion: "Alinear tipos con DDL/interfaces" - -- error: "Circular dependency" - causa: "Módulos se importan mutuamente" - solucion: "Extraer a módulo compartido o forwardRef" -``` - ---- - -**Referencia:** @PERFIL_BACKEND, @SIMCO_BACKEND diff --git a/orchestration/_archive/_definitions/validations/VALIDATION-DDL.md b/orchestration/_archive/_definitions/validations/VALIDATION-DDL.md deleted file mode 100644 index 4a08f80..0000000 --- a/orchestration/_archive/_definitions/validations/VALIDATION-DDL.md +++ /dev/null @@ -1,89 +0,0 @@ -# Validación DDL - PostgreSQL -## Definición Canónica - -**Alias:** @DEF_VAL_DDL -**Dominio:** Database DDL PostgreSQL - ---- - -## COMANDOS OBLIGATORIOS - -```bash -# ANTES de marcar tarea como completada: - -# 1. Validar sintaxis SQL -psql -h localhost -U postgres -d {DB} -f {archivo}.sql --set ON_ERROR_STOP=1 - -# 2. Verificar que no hay errores -echo $? # Debe ser 0 - -# 3. Si existe script de recreación: -./scripts/recreate-database.sh # DEBE ejecutar sin errores -``` - -## CRITERIOS DE ACEPTACIÓN - -```yaml -sintaxis: - resultado: "SQL ejecuta sin errores" - encoding: "UTF-8" - schema_correcto: true - -convenciones: - tablas: "snake_case, plural (users, products)" - columnas: "snake_case (created_at, user_id)" - constraints: "{tabla}_{columna}_{tipo} (users_email_unique)" - indices: "idx_{tabla}_{columnas}" - foreign_keys: "fk_{tabla_origen}_{tabla_destino}" - -integridad: - - "Primary keys definidas" - - "Foreign keys con ON DELETE/UPDATE" - - "NOT NULL donde aplique" - - "DEFAULT values apropiados" - - "CHECK constraints donde necesario" -``` - -## VALIDACIONES ADICIONALES - -```yaml -tablas: - - "Columnas id, created_at, updated_at presentes" - - "Tipos de datos apropiados" - - "Índices en columnas de búsqueda frecuente" - -rls_policies: - - "Habilitado en tablas multi-tenant" - - "Políticas para SELECT, INSERT, UPDATE, DELETE" - - "Usando tenant_id del contexto" - -funciones: - - "SECURITY DEFINER/INVOKER correcto" - - "Manejo de errores (EXCEPTION)" - - "Documentación en comentarios" - -triggers: - - "Timing correcto (BEFORE/AFTER)" - - "Operaciones correctas (INSERT/UPDATE/DELETE)" - - "Función trigger existe" -``` - -## ERRORES COMUNES - -```yaml -- error: "relation already exists" - causa: "Tabla/objeto ya existe" - solucion: "Usar IF NOT EXISTS o DROP primero" - -- error: "foreign key constraint violation" - causa: "Referencia a registro inexistente" - solucion: "Verificar orden de inserción o CASCADE" - -- error: "column does not exist" - causa: "Nombre de columna incorrecto" - solucion: "Verificar nombres y comillas" -``` - ---- - -**Referencia:** @PERFIL_DATABASE, @SIMCO_DDL diff --git a/orchestration/_archive/_definitions/validations/VALIDATION-FRONTEND.md b/orchestration/_archive/_definitions/validations/VALIDATION-FRONTEND.md deleted file mode 100644 index 794cf41..0000000 --- a/orchestration/_archive/_definitions/validations/VALIDATION-FRONTEND.md +++ /dev/null @@ -1,81 +0,0 @@ -# Validación Frontend - React/TypeScript -## Definición Canónica - -**Alias:** @DEF_VAL_FE -**Dominio:** Frontend React/TypeScript - ---- - -## COMANDOS OBLIGATORIOS - -```bash -# ANTES de marcar tarea como completada: -npm run build # DEBE pasar sin errores -npm run lint # DEBE pasar sin errores -npm run typecheck # DEBE pasar sin errores (tsc --noEmit) -``` - -## CRITERIOS DE ACEPTACIÓN - -```yaml -build: - resultado: "Build de producción exitoso" - sin_warnings_criticos: true - bundle_size: "Monitorear incrementos grandes" - -lint: - resultado: "0 errores de ESLint" - reglas_react: - - "react-hooks/rules-of-hooks" - - "react-hooks/exhaustive-deps" - -typecheck: - resultado: "0 errores de TypeScript" - strict_mode: true - no_any_implicito: true -``` - -## VALIDACIONES ADICIONALES - -```yaml -componentes: - - "Props tipadas correctamente" - - "Keys únicas en listas" - - "Manejo de loading/error states" - - "Accesibilidad básica (aria labels)" - -hooks: - - "Dependencias completas en useEffect" - - "Cleanup en useEffect si necesario" - - "useMemo/useCallback donde aplique" - -estado: - - "Estado mínimo necesario" - - "Derivar datos cuando posible" - - "Zustand/Context correctamente usado" - -api: - - "Manejo de errores de red" - - "Estados de carga" - - "Cancelación de requests" -``` - -## ERRORES COMUNES - -```yaml -- error: "React Hook useEffect has missing dependency" - causa: "Dependencia no incluida en array" - solucion: "Agregar dependencia o usar useCallback" - -- error: "Cannot read property of undefined" - causa: "Datos async no disponibles" - solucion: "Optional chaining o loading state" - -- error: "Each child should have unique key" - causa: "Key faltante o duplicada en map()" - solucion: "Usar ID único como key" -``` - ---- - -**Referencia:** @PERFIL_FRONTEND, @SIMCO_FRONTEND diff --git a/orchestration/_archive/_refs/WS-REFERENCES.yml b/orchestration/_archive/_refs/WS-REFERENCES.yml deleted file mode 100644 index e3cbe04..0000000 --- a/orchestration/_archive/_refs/WS-REFERENCES.yml +++ /dev/null @@ -1,216 +0,0 @@ -# Referencias a Workspace -# clinica-veterinaria -# Creado: 2026-01-16 - -version: "1.0.0" -proyecto: "clinica-veterinaria" -fecha_creacion: "2026-01-16" - -# ============================================================================ -# REFERENCIAS A DEFINICIONES GLOBALES -# ============================================================================ -definiciones_workspace: - protocolos: - CCA: - alias: "@WS_DEF_CCA" - archivo: "orchestration/_definitions/protocols/CCA-PROTOCOL.md" - uso: "Protocolo de Carga de Contexto Automatica" - - CCA_LIGHT: - alias: "@WS_DEF_CCA_LIGHT" - archivo: "orchestration/_definitions/protocols/CCA-LIGHT.md" - uso: "Version ligera para subagentes" - - CAPVED: - alias: "@WS_DEF_CAPVED" - archivo: "orchestration/directivas/principios/PRINCIPIO-CAPVED.md" - uso: "Ciclo de vida de tareas" - - validaciones: - backend: - alias: "@WS_DEF_VAL_BE" - archivo: "orchestration/_definitions/validations/VALIDATION-BACKEND.md" - comandos: ["npm run build", "npm run lint", "npm run test"] - - frontend: - alias: "@WS_DEF_VAL_FE" - archivo: "orchestration/_definitions/validations/VALIDATION-FRONTEND.md" - comandos: ["npm run build", "npm run lint", "npm run typecheck"] - - ddl: - alias: "@WS_DEF_VAL_DDL" - archivo: "orchestration/_definitions/validations/VALIDATION-DDL.md" - - devops: - alias: "@WS_DEF_VAL_DEVOPS" - archivo: "orchestration/_definitions/validations/VALIDATION-DEVOPS.md" - -# ============================================================================ -# REFERENCIAS A NAVEGACION RAPIDA GLOBAL -# ============================================================================ -navegacion_workspace: - indice: - alias: "@WS_QUICK_INDEX" - archivo: "orchestration/_quick/QUICK-INDEX.yml" - - perfiles: - alias: "@WS_QUICK_PERFILES" - archivo: "orchestration/_quick/QUICK-PERFILES.yml" - - directivas: - alias: "@WS_QUICK_DIRECTIVAS" - archivo: "orchestration/_quick/QUICK-DIRECTIVAS.yml" - -# ============================================================================ -# REFERENCIAS A CATALOGO COMPARTIDO -# ============================================================================ -catalogo_compartido: - indice: - alias: "@WS_CATALOG" - archivo: "shared/catalog/CATALOG-INDEX.yml" - - funcionalidades: - auth: "shared/catalog/auth/" - notifications: "shared/catalog/notifications/" - multi_tenancy: "shared/catalog/multi-tenancy/" - -# ============================================================================ -# HERENCIA DE PROYECTO (Nivel 3) -# ============================================================================ -herencia: - padre: "erp-clinicas" - nivel: 3 - tipo: "especializacion" - - cadena_completa: - - proyecto: "erp-core" - nivel: 1 - tipo: "core base" - hereda: - - "Authentication (MGN-001)" - - "Tenants (MGN-002)" - - "Users (MGN-003)" - - "Audit (MGN-004)" - - - proyecto: "erp-clinicas" - nivel: 2 - tipo: "vertical clinicas" - hereda: - - "Doctors (CLN-001)" - - "Appointments (CLN-002)" - - "Consultations (CLN-003)" - - - proyecto: "clinica-veterinaria" - nivel: 3 - tipo: "especializacion veterinaria" - implementa: - - "Mascotas y Propietarios (VET-001)" - - "Vacunacion (VET-002)" - - "Desparasitaciones (VET-003)" - - "Hospitalizacion (VET-004)" - - "Estetica (VET-005)" - - "Farmacia (VET-006)" - - hereda_de: - - proyecto: "erp-clinicas" - tipo: "definiciones + codigo" - definiciones: - - "@ERP_CLINICAS_DEF_DOCTORS" - - "@ERP_CLINICAS_DEF_APPOINTMENTS" - - "@ERP_CLINICAS_DEF_CONSULTATIONS" - - - proyecto: "erp-core" - tipo: "definiciones base" - definiciones: - - "@ERP_CORE_DEF_AUTH" - - "@ERP_CORE_DEF_TENANTS" - - "@ERP_CORE_DEF_USERS" - -# ============================================================================ -# EXTENSIONES ESPECIFICAS -# ============================================================================ -extensiones: - consultations: - origen: "erp-clinicas" - tabla: "clinica.consultations" - columnas_agregadas: - - nombre: "mascota_id" - tipo: "UUID FK" - referencia: "veterinaria.mascotas" - - nombre: "peso_actual" - tipo: "NUMERIC(6,2)" - - nombre: "temperatura" - tipo: "NUMERIC(4,1)" - -# ============================================================================ -# PROPAGACION -# ============================================================================ -propagacion: - recibe_de: - - proyecto: "erp-core" - via: "erp-clinicas" - tipos: ["documentacion", "definiciones"] - - - proyecto: "erp-clinicas" - via: "directo" - tipos: ["documentacion", "definiciones", "codigo"] - - mirror: "shared/mirrors/clinica-veterinaria/" - status: "shared/mirrors/clinica-veterinaria/PROPAGATION-STATUS.yml" - consumidores: [] - -# ============================================================================ -# GOBERNANZA DE DOCUMENTACION (2026-01-16) -# ============================================================================ -gobernanza_ws: - tareas: - ruta: "orchestration/tareas/" - alias: "@WS_TAREAS" - descripcion: "Sistema de tracking de tareas" - template: "orchestration/tareas/_templates/TASK-TEMPLATE/" - - mapa_documentacion: - ruta: "orchestration/MAPA-DOCUMENTACION.yml" - alias: "@WS_MAPA_DOC" - descripcion: "Mapa central de documentacion del workspace" - - trazas_agentes: - ruta: "orchestration/agents/trazas/" - alias: "@WS_TRAZA_AGENTE" - descripcion: "Tracking de actividad por agente" - - trigger_documentacion: - ruta: "orchestration/directivas/triggers/TRIGGER-DOCUMENTACION-OBLIGATORIA.md" - alias: "@WS_TRIGGER_DOC" - descripcion: "Directiva obligatoria de documentacion" - -# ============================================================================ -# DEFINICIONES LOCALES -# ============================================================================ -definiciones_locales: - database: "@PROJ_DEF_DB" - entities: "@PROJ_DEF_ENTITIES" - services: "@PROJ_DEF_SERVICES" - modules: "@PROJ_DEF_MODULES" - -# ============================================================================ -# RUTAS IMPORTANTES -# ============================================================================ -rutas: - documentacion: - mapa: "docs/_MAP.md" - definiciones: "docs/_definitions/" - quick: "docs/_quick/" - epicas: "docs/01-epicas/" - - orchestration: - contexto: "orchestration/00-guidelines/CONTEXTO-PROYECTO.md" - inventarios: "orchestration/inventarios/" - trazas: "orchestration/trazas/" - herencia_clinicas: "orchestration/00-guidelines/HERENCIA-ERP-CLINICAS.md" - herencia_core: "orchestration/00-guidelines/HERENCIA-ERP-CORE.md" - - database: - schemas: "database/schemas/" - seeds: "database/seeds/" - inventario: "orchestration/inventarios/DATABASE_INVENTORY.yml" diff --git a/orchestration/_archive/agents/perfiles/PERFIL-DDL-VET-AGENT.yml b/orchestration/_archive/agents/perfiles/PERFIL-DDL-VET-AGENT.yml deleted file mode 100644 index b680eae..0000000 --- a/orchestration/_archive/agents/perfiles/PERFIL-DDL-VET-AGENT.yml +++ /dev/null @@ -1,239 +0,0 @@ -# =============================================================================== -# PERFIL DE AGENTE - DDL VETERINARIA -# =============================================================================== -# -# Proyecto: clinica-veterinaria -# Rol: Agente especializado en base de datos para clinica veterinaria -# Alias: @VET_AGENT_DDL -# -# =============================================================================== - -version: "1.0.0" -created: "2026-01-16" -updated: "2026-01-16" -proyecto: "clinica-veterinaria" - -# ------------------------------------------------------------------------------- -# IDENTIFICACION -# ------------------------------------------------------------------------------- - -perfil: - id: "VET-AGENT-002" - nombre: "DDL Veterinaria Agent" - alias: "@VET_AGENT_DDL" - descripcion: "Agente especializado en esquema de BD para dominio veterinario" - tipo: "DATABASE_SPECIALIST" - -# ------------------------------------------------------------------------------- -# CADENA DE HERENCIA -# ------------------------------------------------------------------------------- - -herencia: - cadena: "template-saas -> erp-core -> erp-clinicas -> clinica-veterinaria" - perfiles_padre: - - "@ERP_AGENT_DDL" - - "@CLINICAS_AGENT_DDL" - especializacion: "Schema sub_veterinaria" - -# ------------------------------------------------------------------------------- -# COMPETENCIAS -# ------------------------------------------------------------------------------- - -competencias: - postgresql: - nivel: "experto" - areas: - - "Diseno de schemas multi-tenant" - - "Indices para busquedas por especie/raza" - - "JSONB para historiales clinicos" - - "Triggers de auditoria veterinaria" - - "Row Level Security (RLS)" - - "Particionamiento por fecha" - - dominio_veterinario: - nivel: "avanzado" - conocimientos: - - "Modelado de mascotas y propietarios" - - "Calendarios de vacunacion" - - "Control de hospitalizacion (espacios)" - - "Inventario farmaceutico veterinario" - - "Trazabilidad de sustancias controladas" - - normativa_datos: - nivel: "experto" - conocimientos: - - "NOM-064-ZOO-2000: Registros veterinarios" - - "SENASICA: Control de biologicos" - - "Ley Federal de Sanidad Animal" - - "Retencion de expedientes (5 anos minimo)" - -# ------------------------------------------------------------------------------- -# RESPONSABILIDADES -# ------------------------------------------------------------------------------- - -responsabilidades: - principales: - - "Disenar y mantener schema sub_veterinaria" - - "Crear migraciones para tablas veterinarias" - - "Optimizar queries de historial por mascota" - - "Asegurar integridad referencial" - - "Implementar auditoria de medicamentos" - - "Control de inventario farmaceutico" - - validaciones: - - validacion: "Schema correcto" - regla: "Todas las tablas veterinarias en sub_veterinaria.*" - bloquea: true - - - validacion: "Auditoria" - regla: "Tablas de medicamentos deben tener triggers de auditoria" - bloquea: true - - - validacion: "RLS" - regla: "Datos de mascota protegidos por tenant_id" - bloquea: true - - - validacion: "Constraints FK" - regla: "Mascota siempre vinculada a propietario" - bloquea: true - - - validacion: "Catalogo especies" - regla: "Solo especies del catalogo SENASICA" - bloquea: true - -# ------------------------------------------------------------------------------- -# SCHEMA SUB_VETERINARIA -# ------------------------------------------------------------------------------- - -schema: - nombre: "sub_veterinaria" - descripcion: "Schema exclusivo para clinica veterinaria" - - tablas_core: - - nombre: "pets" - descripcion: "Registro de mascotas" - campos_clave: - - "id UUID PK" - - "owner_id FK (pet_owners)" - - "name VARCHAR(100)" - - "species VARCHAR(50)" - - "breed VARCHAR(100)" - - "birth_date DATE" - - "weight DECIMAL" - - "chip_id VARCHAR(50) UNIQUE" - - "photo_url VARCHAR" - - - nombre: "pet_owners" - descripcion: "Propietarios de mascotas" - campos_clave: - - "id UUID PK" - - "person_id FK (core.persons)" - - "emergency_contact VARCHAR" - - "preferred_vet_id FK" - - - nombre: "vaccinations" - descripcion: "Registro de vacunaciones" - campos_clave: - - "id UUID PK" - - "pet_id FK" - - "vaccine_type_id FK" - - "lot_number VARCHAR(50)" - - "applied_date TIMESTAMP" - - "next_due_date DATE" - - "vet_id FK" - - - nombre: "vaccine_types" - descripcion: "Catalogo de vacunas" - campos_clave: - - "id UUID PK" - - "name VARCHAR(100)" - - "species VARCHAR(50)[]" - - "interval_days INT" - - "mandatory BOOLEAN" - - - nombre: "hospitalizations" - descripcion: "Hospitalizaciones de mascotas" - campos_clave: - - "id UUID PK" - - "pet_id FK" - - "kennel_id FK" - - "admission_date TIMESTAMP" - - "discharge_date TIMESTAMP" - - "reason TEXT" - - "status ENUM" - - - nombre: "kennel_spaces" - descripcion: "Espacios de hospitalizacion" - campos_clave: - - "id UUID PK" - - "code VARCHAR(10)" - - "type ENUM (kennel, cage, isolation)" - - "size ENUM (small, medium, large)" - - "status ENUM (available, occupied, cleaning)" - - - nombre: "vet_medications" - descripcion: "Inventario de medicamentos" - campos_clave: - - "id UUID PK" - - "name VARCHAR(200)" - - "active_ingredient VARCHAR(100)" - - "controlled BOOLEAN" - - "stock INT" - - "lot_number VARCHAR(50)" - - "expiry_date DATE" - -# ------------------------------------------------------------------------------- -# DIRECTIVAS ACTIVAS -# ------------------------------------------------------------------------------- - -directivas: - obligatorias: - - "@VET_TRIGGER_COHERENCIA" - - "@VET_TRIGGER_INVENTARIOS" - - "@ERP_DIRECTIVA_DDL" - - "@WS_TRIGGER_COHERENCIA" - - opcionales: - - "@WS_TRIGGER_ANTI_DUPLICACION" - -# ------------------------------------------------------------------------------- -# MIGRACIONES -# ------------------------------------------------------------------------------- - -migraciones: - convencion: "YYYYMMDD_HHMMSS_descripcion.sql" - ubicacion: "database/migrations/" - - pendientes: - - "20260116_000001_create_schema_sub_veterinaria.sql" - - "20260116_000002_create_pet_owners_table.sql" - - "20260116_000003_create_pets_table.sql" - - "20260116_000004_create_vaccine_types_table.sql" - - "20260116_000005_create_vaccinations_table.sql" - - "20260116_000006_create_kennel_spaces_table.sql" - - "20260116_000007_create_hospitalizations_table.sql" - - "20260116_000008_create_vet_medications_table.sql" - -# ------------------------------------------------------------------------------- -# REFERENCIAS -# ------------------------------------------------------------------------------- - -referencias: - documentacion: - - "@VET_DEF_DB" - - "@VET_INV_DB" - - "@VET_MAPA_DOC" - - schemas_relacionados: - - "clinicas.* (expedientes, citas)" - - "core.* (usuarios, tenants, persons)" - - "audit.* (trazas)" - - workspace: - - "@ERP_DEF_DB" - - "@CLINICAS_DEF_DB" - - "@TS_DEF_DB" - -# =============================================================================== -# FIN DEL PERFIL -# =============================================================================== diff --git a/orchestration/_archive/agents/perfiles/PERFIL-VETERINARIO-AGENT.yml b/orchestration/_archive/agents/perfiles/PERFIL-VETERINARIO-AGENT.yml deleted file mode 100644 index d613d07..0000000 --- a/orchestration/_archive/agents/perfiles/PERFIL-VETERINARIO-AGENT.yml +++ /dev/null @@ -1,244 +0,0 @@ -# =============================================================================== -# PERFIL DE AGENTE - VETERINARIO DIGITAL -# =============================================================================== -# -# Proyecto: clinica-veterinaria -# Rol: Agente especializado en dominio veterinario -# Alias: @VET_AGENT_VETERINARIO -# -# =============================================================================== - -version: "1.0.0" -created: "2026-01-16" -updated: "2026-01-16" -proyecto: "clinica-veterinaria" - -# ------------------------------------------------------------------------------- -# IDENTIFICACION -# ------------------------------------------------------------------------------- - -perfil: - id: "VET-AGENT-001" - nombre: "Veterinario Digital" - alias: "@VET_AGENT_VETERINARIO" - descripcion: "Agente especializado en logica de negocio veterinaria" - tipo: "DOMAIN_EXPERT" - -# ------------------------------------------------------------------------------- -# CADENA DE HERENCIA -# ------------------------------------------------------------------------------- - -herencia: - cadena: "template-saas -> erp-core -> erp-clinicas -> clinica-veterinaria" - perfiles_padre: - - "@CLINICAS_AGENT_MEDICO" - - "@ERP_AGENT_BACKEND" - especializacion: "Dominio veterinario" - -# ------------------------------------------------------------------------------- -# COMPETENCIAS -# ------------------------------------------------------------------------------- - -competencias: - dominio_veterinario: - nivel: "experto" - areas: - - "Especies domesticas (caninos, felinos, aves, roedores)" - - "Razas y caracteristicas por especie" - - "Patologias comunes por especie" - - "Esquemas de vacunacion por especie" - - "Protocolos de desparasitacion" - - "Cuidados hospitalarios" - - "Emergencias veterinarias" - - "Zoonosis y salud publica" - - normativa: - nivel: "experto" - conocimientos: - - nom_064_zoo_2000: - descripcion: "Establecimientos de atencion medica veterinaria" - aplicacion: "Estructura de consultorio, expediente" - - nom_051_zoo_1995: - descripcion: "Trato humanitario en movilizacion de animales" - aplicacion: "Hospitalizacion, traslados" - - senasica: - descripcion: "Sanidad animal" - aplicacion: "Vacunacion, medicamentos controlados" - - nom_033_sag_zoo_2014: - descripcion: "Metodos humanitarios para eutanasia" - aplicacion: "Procedimientos terminales" - - tecnico: - nivel: "avanzado" - areas: - - "Modelado de historiales clinicos animales" - - "Calendarios de vacunacion automatizados" - - "Trazabilidad de medicamentos veterinarios" - - "Control de inventario farmaceutico" - - "Gestion de hospitalizacion (perreras/gateras)" - -# ------------------------------------------------------------------------------- -# RESPONSABILIDADES -# ------------------------------------------------------------------------------- - -responsabilidades: - principales: - - "Validar logica de negocio veterinaria" - - "Asegurar cumplimiento normativo NOM-064" - - "Disenar flujos de atencion veterinaria" - - "Verificar integridad de expedientes" - - "Revisar protocolos de vacunacion" - - "Gestionar alertas de recordatorios" - - validaciones: - - validacion: "Registro de mascota completo" - regla: "Especie, raza, edad, propietario obligatorios" - bloquea: true - - - validacion: "Consentimiento del propietario" - regla: "Obligatorio antes de procedimiento invasivo" - bloquea: true - - - validacion: "Esquema de vacunacion" - regla: "Seguir calendario oficial SENASICA por especie" - bloquea: false - - - validacion: "Control de sustancias" - regla: "Medicamentos controlados con receta y registro" - bloquea: true - - - validacion: "Hospitalizacion" - regla: "Espacio asignado, notas diarias obligatorias" - bloquea: true - -# ------------------------------------------------------------------------------- -# DIRECTIVAS ACTIVAS -# ------------------------------------------------------------------------------- - -directivas: - obligatorias: - - "@VET_TRIGGER_COHERENCIA" - - "@VET_TRIGGER_INVENTARIOS" - - "@CLINICAS_DIRECTIVA_EXPEDIENTE" - - "@ERP_DIRECTIVA_MULTI_TENANT" - - opcionales: - - "@WS_TRIGGER_ANTI_DUPLICACION" - - "@WS_TRIGGER_DEPENDENCIAS" - -# ------------------------------------------------------------------------------- -# FLUJOS DE TRABAJO -# ------------------------------------------------------------------------------- - -flujos: - nueva_consulta: - pasos: - 1: "Verificar mascota y propietario existentes o registrar" - 2: "Cargar historial clinico" - 3: "Registrar motivo de consulta y signos vitales" - 4: "Examen fisico" - 5: "Diagnostico y plan de tratamiento" - 6: "Receta/Prescripcion si aplica" - 7: "Programar seguimiento o vacunas" - - vacunacion: - pasos: - 1: "Verificar esquema de vacunacion vigente" - 2: "Validar edad y peso del animal" - 3: "Obtener consentimiento del propietario" - 4: "Registrar lote de vacuna" - 5: "Aplicar vacuna" - 6: "Actualizar cartilla de vacunacion" - 7: "Programar proxima dosis" - - hospitalizacion: - pasos: - 1: "Evaluar estado del paciente" - 2: "Asignar espacio (perrera/gatera/jaula)" - 3: "Crear hoja de hospitalizacion" - 4: "Registrar tratamiento y medicacion" - 5: "Notas de evolucion (minimo 2 diarias)" - 6: "Comunicacion con propietario" - 7: "Alta medica y seguimiento" - - emergencia: - pasos: - 1: "Triage inmediato" - 2: "Estabilizacion" - 3: "Contactar propietario" - 4: "Consentimiento verbal (documentado)" - 5: "Tratamiento de emergencia" - 6: "Hospitalizacion o referencia" - -# ------------------------------------------------------------------------------- -# INTEGRACIONES -# ------------------------------------------------------------------------------- - -integraciones: - modulos_CVT: - - "CVT-001: Mascotas" - - "CVT-002: Vacunacion" - - "CVT-003: Desparasitaciones" - - "CVT-004: Hospitalizacion" - - "CVT-005: Estetica canina" - - "CVT-006: Farmacia veterinaria" - - modulos_heredados: - - "Pacientes (adaptado como mascotas)" - - "Citas (de erp-clinicas)" - - "Expedientes (extendido para veterinaria)" - - "Prescripciones (de erp-clinicas)" - -# ------------------------------------------------------------------------------- -# ESPECIES SOPORTADAS -# ------------------------------------------------------------------------------- - -especies: - principales: - - especie: "Canino" - alias: "@VET_CANINO" - vacunas_obligatorias: ["rabia", "parvovirus", "moquillo", "leptospira"] - - - especie: "Felino" - alias: "@VET_FELINO" - vacunas_obligatorias: ["rabia", "triple_felina", "leucemia_felina"] - - - especie: "Ave" - alias: "@VET_AVE" - consideraciones_especiales: "Cuarentena zoonosis" - - - especie: "Roedor" - alias: "@VET_ROEDOR" - consideraciones_especiales: "Manejo especializado" - - exoticos: - - "Reptiles" - - "Hurones" - - "Conejos" - - "Otros (previa evaluacion)" - -# ------------------------------------------------------------------------------- -# REFERENCIAS -# ------------------------------------------------------------------------------- - -referencias: - documentacion: - - "@VET_MAPA_DOC" - - "@VET_CONTEXT_MAP" - - "@VET_INHERITANCE" - - inventarios: - - "@VET_INV_MASTER" - - "@VET_INV_DB" - - "@VET_INV_BE" - - workspace: - - "@WS_DIRECTIVAS" - - "@WS_PERFILES" - - "@CLINICAS_MAPA_DOC" - - "@ERP_MAPA_DOC" - - "@TS_MAPA_DOC" - -# =============================================================================== -# FIN DEL PERFIL -# =============================================================================== diff --git a/orchestration/_archive/agents/perfiles/_INDEX.yml b/orchestration/_archive/agents/perfiles/_INDEX.yml deleted file mode 100644 index c27c1e1..0000000 --- a/orchestration/_archive/agents/perfiles/_INDEX.yml +++ /dev/null @@ -1,158 +0,0 @@ -# =============================================================================== -# INDICE DE PERFILES DE AGENTES - CLINICA VETERINARIA -# =============================================================================== -# -# Proyecto: clinica-veterinaria -# Descripcion: Catalogo de agentes especializados para el dominio veterinario -# Alias: @VET_AGENTS_INDEX -# -# =============================================================================== - -version: "1.0.0" -created: "2026-01-16" -updated: "2026-01-16" -proyecto: "clinica-veterinaria" - -# ------------------------------------------------------------------------------- -# CADENA DE HERENCIA DE PERFILES -# ------------------------------------------------------------------------------- - -herencia: - cadena: "template-saas -> erp-core -> erp-clinicas -> clinica-veterinaria" - perfiles_heredados: - desde_template_saas: - - "@TS_AGENT_DDL" - - "@TS_AGENT_BACKEND" - - "@TS_AGENT_FRONTEND" - desde_erp_core: - - "@ERP_AGENT_DDL" - - "@ERP_AGENT_BACKEND" - - "@ERP_AGENT_FRONTEND" - desde_erp_clinicas: - - "@CLINICAS_AGENT_MEDICO" - - "@CLINICAS_AGENT_DDL" - -# ------------------------------------------------------------------------------- -# PERFILES PROPIOS -# ------------------------------------------------------------------------------- - -perfiles: - dominio: - - id: "VET-AGENT-001" - archivo: "PERFIL-VETERINARIO-AGENT.yml" - alias: "@VET_AGENT_VETERINARIO" - tipo: "DOMAIN_EXPERT" - descripcion: "Agente experto en logica de negocio veterinaria" - competencias_clave: - - "Medicina veterinaria general" - - "Normativa NOM-064-ZOO" - - "Flujos clinicos veterinarios" - - "Control de vacunacion" - - tecnico: - - id: "VET-AGENT-002" - archivo: "PERFIL-DDL-VET-AGENT.yml" - alias: "@VET_AGENT_DDL" - tipo: "DATABASE_SPECIALIST" - descripcion: "Agente especializado en schema sub_veterinaria" - competencias_clave: - - "PostgreSQL avanzado" - - "Modelado mascotas/propietarios" - - "Control de inventario farmaceutico" - -# ------------------------------------------------------------------------------- -# MATRIZ DE COMPETENCIAS -# ------------------------------------------------------------------------------- - -matriz_competencias: - por_area: - dominio_veterinario: - principal: "@VET_AGENT_VETERINARIO" - soporte: "@CLINICAS_AGENT_MEDICO" - - base_de_datos: - principal: "@VET_AGENT_DDL" - soporte: "@CLINICAS_AGENT_DDL" - - backend: - principal: "@ERP_AGENT_BACKEND" - especializacion: "@VET_AGENT_VETERINARIO" - - frontend: - principal: "@ERP_AGENT_FRONTEND" - especializacion: null # Por definir - - normativa: - principal: "@VET_AGENT_VETERINARIO" - referencias: - - "NOM-064-ZOO-2000" - - "SENASICA" - - "NOM-051-ZOO-1995" - -# ------------------------------------------------------------------------------- -# ASIGNACION POR TAREA -# ------------------------------------------------------------------------------- - -asignacion_tareas: - crear_tabla_veterinaria: - agente_principal: "@VET_AGENT_DDL" - validadores: - - "@VET_AGENT_VETERINARIO" - - crear_entity_veterinaria: - agente_principal: "@ERP_AGENT_BACKEND" - validadores: - - "@VET_AGENT_DDL" - - "@VET_AGENT_VETERINARIO" - - implementar_vacunacion: - agente_principal: "@VET_AGENT_VETERINARIO" - validadores: - - "@VET_AGENT_DDL" - - implementar_hospitalizacion: - agente_principal: "@VET_AGENT_VETERINARIO" - validadores: - - "@VET_AGENT_DDL" - - validar_normativa: - agente_principal: "@VET_AGENT_VETERINARIO" - validadores: [] - - control_farmacia: - agente_principal: "@VET_AGENT_VETERINARIO" - validadores: - - "@VET_AGENT_DDL" - -# ------------------------------------------------------------------------------- -# ESTADISTICAS -# ------------------------------------------------------------------------------- - -estadisticas: - total_perfiles_propios: 2 - total_perfiles_heredados: 8 - cobertura_areas: - dominio: "100%" - ddl: "100%" - backend: "heredado" - frontend: "heredado" - ultima_actualizacion: "2026-01-16" - -# ------------------------------------------------------------------------------- -# REFERENCIAS -# ------------------------------------------------------------------------------- - -referencias: - documentacion: - - "@VET_MAPA_DOC" - - "@VET_TRIGGER_COHERENCIA" - - "@VET_TRIGGER_INVENTARIOS" - - workspace: - - "@WS_PERFILES" - - "@CLINICAS_AGENTS_INDEX" - - "@ERP_AGENTS" - -# =============================================================================== -# FIN DEL INDICE -# =============================================================================== diff --git a/orchestration/_archive/directivas/TRIGGER-INVENTARIOS.md b/orchestration/_archive/directivas/TRIGGER-INVENTARIOS.md deleted file mode 100644 index 03e2024..0000000 --- a/orchestration/_archive/directivas/TRIGGER-INVENTARIOS.md +++ /dev/null @@ -1,276 +0,0 @@ -# TRIGGER: Inventarios Sincronizados - Clinica Veterinaria - -**ID:** TRIGGER-VET-INVENTARIOS -**Version:** 1.0.0 -**Proyecto:** clinica-veterinaria -**Hereda de:** @ERP_TRIGGER_INVENTARIOS -> @CLINICAS_TRIGGER_INVENTARIOS -**Alias:** @VET_TRIGGER_INVENTARIOS - ---- - -## Proposito - -Mantener los inventarios sincronizados con el codigo fuente, asegurando que cada objeto nuevo/modificado este registrado, con enfasis en componentes especificos del dominio veterinario. - -## Cadena de Herencia - -``` -template-saas (PROVIDER) - | - v -erp-core (INTERMEDIATE) - | - v -erp-clinicas (CONSUMER) - | - v -clinica-veterinaria (SUB-VERTICAL) <- ESTE PROYECTO -``` - -## Activacion - -### Post-Tarea -- Creacion de entity/service/controller veterinario -- Creacion de tabla DDL en sub_veterinaria -- Creacion de componente frontend veterinario -- Modificacion de modulo CVT - -### Automatica -- Post-commit (via hook) -- Pre-release - -## Inventarios a Sincronizar - -### DATABASE_INVENTORY.yml -```yaml -ubicacion: "orchestration/inventarios/DATABASE_INVENTORY.yml" -contenido: - schemas_propios: - - sub_veterinaria - tablas_veterinaria: - - sub_veterinaria.pets - - sub_veterinaria.pet_owners - - sub_veterinaria.pet_photos - - sub_veterinaria.vaccinations - - sub_veterinaria.vaccine_types - - sub_veterinaria.vaccination_reminders - - sub_veterinaria.dewormings - - sub_veterinaria.dewormer_types - - sub_veterinaria.hospitalizations - - sub_veterinaria.kennel_spaces - - sub_veterinaria.hospitalization_notes - - sub_veterinaria.grooming_services - - sub_veterinaria.grooming_appointments - - sub_veterinaria.vet_medications - - sub_veterinaria.medication_sales - tablas_heredadas: - - "clinicas.pacientes (adaptado como mascotas)" - - "clinicas.citas (adaptado)" - - "clinicas.expedientes (extendido)" -``` - -### BACKEND_INVENTORY.yml -```yaml -ubicacion: "orchestration/inventarios/BACKEND_INVENTORY.yml" -contenido: - modulos_CVT: - - CVT-001: mascotas - - CVT-002: vacunacion - - CVT-003: desparasitaciones - - CVT-004: hospitalizacion - - CVT-005: estetica-canina - - CVT-006: farmacia-veterinaria - entities_por_modulo: TBD - services_por_modulo: TBD - controllers_y_endpoints: TBD - dtos: TBD - guards_especificos: - - vet-professional.guard.ts - - pet-owner-consent.guard.ts - - controlled-substance.guard.ts -``` - -### FRONTEND_INVENTORY.yml -```yaml -ubicacion: "orchestration/inventarios/FRONTEND_INVENTORY.yml" -contenido: - pages_veterinaria: - - MascotasPage - - VacunacionPage - - DesparasitacionesPage - - HospitalizacionDashboard - - EsteticaPage - - FarmaciaPage - components_especializados: - - PetProfileCard - - VaccinationCalendar - - KennelMap - - GroomingScheduler - - MedicationDispenser - - PetWeightTracker - hooks_veterinaria: - - usePetProfile - - useVaccinationSchedule - - useHospitalization -``` - -### MASTER_INVENTORY.yml -```yaml -ubicacion: "orchestration/inventarios/MASTER_INVENTORY.yml" -contenido: - totales_consolidados: TBD - estadisticas_por_capa: TBD - ultima_sincronizacion: TBD - cobertura_tests: TBD - cumplimiento_normativo: TBD -``` - -## Reglas de Actualizacion - -```yaml -regla_1: - evento: "Entity veterinaria creada" - acciones: - - Agregar a BACKEND_INVENTORY.yml - - Incrementar contador en MASTER_INVENTORY.yml - - Verificar campos NOM-064 si aplica - -regla_2: - evento: "Tabla DDL veterinaria creada" - acciones: - - Agregar a DATABASE_INVENTORY.yml - - Verificar entity correspondiente - - Validar schema sub_veterinaria - -regla_3: - evento: "Componente React veterinario creado" - acciones: - - Agregar a FRONTEND_INVENTORY.yml - - Clasificar por tipo (page/component/hook) - - Verificar usabilidad en dispositivos moviles -``` - -## Validacion de Consistencia - -### Conteos Esperados - -| Inventario | Metrica | Valor Esperado | -|------------|---------|----------------| -| DATABASE | Schemas propios | 1 (sub_veterinaria) | -| DATABASE | Tablas propias | 15+ | -| DATABASE | Tablas heredadas | 10+ (de clinicas) | -| BACKEND | Modulos CVT | 6 | -| BACKEND | Entities | 15+ | -| FRONTEND | Pages | 6+ | -| FRONTEND | Components especializados | 10+ | - -### Script de Validacion - -```bash -# Validar sincronizacion -npm run inventory:validate - -# Actualizar inventarios -npm run inventory:sync - -# Validar cumplimiento NOM-064 -npm run inventory:validate-nom -``` - -## Inventarios de Insumos Veterinarios - -### Categorias Especiales (Control SENASICA) - -```yaml -medicamentos_controlados: - antibioticos: - - amoxicilina - - enrofloxacina - - cefalexina - registro_obligatorio: true - receta_medico_veterinario: true - - vacunas: - - rabia - - parvovirus - - moquillo - - triple_felina - cadena_frio: obligatorio - lote_tracking: true - - anestesicos: - - ketamina - - propofol - - xilazina - registro_stricto: true - libro_control: obligatorio - - desparasitantes: - - internos - - externos - lote_tracking: true - - sustancias_controladas: - - opioides - - barbituratos - registro_senasica: obligatorio - libro_amarillo: true -``` - -### Inventario de Alimentos - -```yaml -alimentos_hospitalizados: - categorias: - - dietas_terapeuticas - - alimento_cachorro - - alimento_adulto - - alimento_senior - - alimento_renal - - alimento_hepatico - trazabilidad: por_paciente - caducidad_control: true -``` - -## Formato de Entrada - -```yaml -# Nueva entity veterinaria -entities: - - nombre: "PetEntity" - archivo: "pet.entity.ts" - modulo: "mascotas" - tabla_ddl: "sub_veterinaria.pets" - estado: "implementado" - tests: true - cumple_nom_064: true -``` - -## Metricas - -| Metrica | Objetivo | Actual | -|---------|----------|--------| -| Sincronizacion DB | 100% | TBD | -| Sincronizacion BE | 100% | TBD | -| Sincronizacion FE | 100% | TBD | -| Trazabilidad medicamentos | 100% | TBD | -| Trazabilidad vacunas | 100% | TBD | -| Ultima actualizacion | Diaria | TBD | - -## Referencias - -- `@VET_INV_MASTER` - MASTER_INVENTORY.yml -- `@VET_INV_DB` - DATABASE_INVENTORY.yml -- `@VET_INV_BE` - BACKEND_INVENTORY.yml -- `@VET_INV_FE` - FRONTEND_INVENTORY.yml -- `@CLINICAS_TRIGGER_INVENTARIOS` - Trigger padre -- `@ERP_TRIGGER_INVENTARIOS` - Trigger abuelo -- `@WS_TRIGGER_INVENTARIOS` - Trigger raiz del workspace - ---- - -**Normativa Aplicable para Inventarios:** -- NOM-064-ZOO-2000: Control de medicamentos e insumos veterinarios -- SENASICA: Registro de sustancias controladas -- NOM-012-ZOO-1993: Especificaciones para la regulacion de productos quimicos -- Ley Federal de Sanidad Animal: Trazabilidad de biologicos diff --git a/orchestration/_archive/directivas/principios/PRINCIPIO-ANTI-DUPLICACION.md b/orchestration/_archive/directivas/principios/PRINCIPIO-ANTI-DUPLICACION.md deleted file mode 100644 index 6a10a93..0000000 --- a/orchestration/_archive/directivas/principios/PRINCIPIO-ANTI-DUPLICACION.md +++ /dev/null @@ -1,287 +0,0 @@ -# PRINCIPIO: ANTI-DUPLICACIÓN - -**Versión:** 1.0.0 -**Fecha:** 2025-12-08 -**Tipo:** Principio Fundamental - HERENCIA OBLIGATORIA -**Aplica a:** TODOS los agentes sin excepción - ---- - -## DECLARACIÓN DEL PRINCIPIO - -``` -╔══════════════════════════════════════════════════════════════════════╗ -║ ║ -║ ANTES DE CREAR, VERIFICAR QUE NO EXISTE ║ -║ ║ -║ "Un duplicado creado es tiempo perdido y confusión garantizada." ║ -║ "2 minutos de verificación ahorran horas de corrección." ║ -║ ║ -╚══════════════════════════════════════════════════════════════════════╝ -``` - ---- - -## REGLA DE ORO - -``` -┌─────────────────────────────────────────────────────────────────────┐ -│ │ -│ NUNCA crear un objeto (tabla, entity, componente, etc.) │ -│ sin antes verificar que NO existe algo igual o similar. │ -│ │ -└─────────────────────────────────────────────────────────────────────┘ -``` - ---- - -## PROCESO DE VERIFICACIÓN - -### Paso 0: Consultar Catálogo de Funcionalidades (NUEVO - OBLIGATORIO) - -```bash -# 🆕 PRIMERO: Verificar si existe funcionalidad en catálogo global -grep -i "{funcionalidad}" @CATALOG_INDEX - -# Funcionalidades comunes ya catalogadas: -# - auth (login, registro, JWT) -# - session-management (sesiones, dispositivos) -# - rate-limiting (throttle, 429) -# - notifications (email, push) -# - multi-tenancy (tenant, RLS) -# - feature-flags (toggles) -# - websocket (realtime) -# - payments (stripe) -``` - -**Si encuentra en @CATALOG:** -``` -✅ USAR CÓDIGO DEL CATÁLOGO -1. Ir a @CATALOG/{funcionalidad}/ -2. Leer README.md (descripción y trade-offs) -3. Seguir IMPLEMENTATION.md (pasos) -4. Copiar _reference/ (código base) -5. Adaptar configuración al proyecto - -Ver: @REUTILIZAR (SIMCO-REUTILIZAR.md) -``` - -### Paso 1: Consultar Inventario del Proyecto -```bash -# Buscar en inventario maestro -grep -i "{nombre}" @INVENTORY - -# Buscar en inventario específico -grep -i "{nombre}" @INV_DB # Para database -grep -i "{nombre}" @INV_BE # Para backend -grep -i "{nombre}" @INV_FE # Para frontend -``` - -### Paso 2: Buscar en Código -```bash -# Buscar archivos con nombre similar -find apps/ -name "*{nombre}*" -type f - -# Buscar definiciones en código -grep -rn "CREATE TABLE.*{nombre}" apps/ -grep -rn "class {Nombre}" apps/ -grep -rn "export.*{Nombre}" apps/ -``` - -### Paso 3: Evaluar Resultado - -| Resultado | Acción | -|-----------|--------| -| Existe en @CATALOG | ✅ REUTILIZAR del catálogo (ver @REUTILIZAR) | -| No encontrado | ✅ Proceder a crear | -| Encontrado idéntico | 🛑 DETENER - No crear, usar existente | -| Encontrado similar | ⚠️ PREGUNTAR - ¿Modificar existente o crear diferente? | - ---- - -## QUÉ VERIFICAR POR TIPO - -### Database (DDL) -```bash -# Verificar tabla -grep -rn "CREATE TABLE.*{nombre}" @DDL_ROOT -grep -i "{nombre}" @INV_DB - -# Verificar schema -grep -rn "CREATE SCHEMA.*{nombre}" @DDL_ROOT - -# Verificar función -grep -rn "CREATE.*FUNCTION.*{nombre}" @DDL_ROOT -``` - -### Backend (NestJS) -```bash -# Verificar entity -find @BACKEND -name "*{nombre}*.entity.ts" -grep -rn "class {Nombre}Entity" @BACKEND - -# Verificar service -find @BACKEND -name "*{nombre}*.service.ts" -grep -rn "class {Nombre}Service" @BACKEND - -# Verificar controller -find @BACKEND -name "*{nombre}*.controller.ts" -``` - -### Frontend (React) -```bash -# Verificar componente -find @FRONTEND -name "*{Nombre}*.tsx" -grep -rn "export.*{Nombre}" @FRONTEND_ROOT - -# Verificar hook -find @FRONTEND -name "use{Nombre}*.ts" - -# Verificar type -grep -rn "interface {Nombre}\|type {Nombre}" @FRONTEND_ROOT -``` - ---- - -## SI ENCUENTRAS DUPLICADO - -### Duplicado Exacto -```markdown -🛑 DETENER INMEDIATAMENTE - -El objeto `{nombre}` YA EXISTE: -- **Ubicación:** {ruta} -- **Inventario:** {línea en inventario} -- **Estado:** {estado} - -**Acción:** Usar el existente, NO crear nuevo. - -**Si necesitas modificarlo:** -Ver @MODIFICAR (SIMCO-MODIFICAR.md) -``` - -### Objeto Similar -```markdown -⚠️ OBJETO SIMILAR ENCONTRADO - -Encontré `{nombre_similar}` que podría ser lo mismo: -- **Ubicación:** {ruta} -- **Propósito:** {descripción} - -**Preguntas a resolver:** -1. ¿Es el mismo objeto con diferente nombre? -2. ¿Debo modificar el existente? -3. ¿Son diferentes y debo crear con otro nombre? - -ESPERAR CLARIFICACIÓN antes de proceder. -``` - ---- - -## CONSECUENCIAS DE DUPLICAR - -``` -❌ Confusión sobre cuál usar - → Diferentes partes del código usan diferentes versiones - -❌ Mantenimiento duplicado - → Cambios deben hacerse en múltiples lugares - -❌ Bugs por inconsistencia - → Un objeto se actualiza, el duplicado no - -❌ Inventarios incorrectos - → Estado del proyecto confuso - -❌ Tiempo perdido - → Trabajo que hay que deshacer -``` - ---- - -## PREVENCIÓN PROACTIVA - -### Al Planificar -```markdown -ANTES de diseñar nuevo objeto: -1. [ ] Busqué en inventarios -2. [ ] Busqué en código -3. [ ] Confirmé que no existe -``` - -### Al Crear -```markdown -DURANTE creación de objeto: -1. [ ] Nombre no colisiona con existente -2. [ ] Ubicación es única -3. [ ] Propósito no está cubierto por otro objeto -``` - -### Al Completar -```markdown -DESPUÉS de crear: -1. [ ] Actualicé inventario -2. [ ] No hay advertencias de duplicados -``` - ---- - -## CASOS ESPECIALES - -### ¿Qué pasa si necesito algo PARECIDO pero diferente? - -```markdown -Ejemplo: Existe `UserEntity`, necesito `AdminUserEntity` - -Verificar: -1. ¿Es una extensión? → Heredar/extender existente -2. ¿Es un caso especial? → Agregar campo al existente -3. ¿Es realmente diferente? → Crear nuevo con nombre claro - -Nombrar claramente: -- ❌ `User2Entity` (confuso) -- ✅ `AdminUserEntity` (claro y diferenciado) -``` - -### ¿Qué pasa si el existente está mal? - -```markdown -Si el objeto existente tiene problemas: -1. Documentar los problemas -2. Decidir: ¿Corregir existente o reemplazar? -3. Si reemplazar: eliminar viejo completamente -4. NUNCA tener ambos coexistiendo -``` - ---- - -## CHECKLIST RÁPIDO - -``` -Antes de crear CUALQUIER objeto: -[ ] 🆕 Busqué funcionalidad en @CATALOG_INDEX (PRIMERO) -[ ] Busqué "{nombre}" en @INVENTORY -[ ] Busqué archivos con find -[ ] Busqué definiciones con grep -[ ] Confirmé que NO existe en catálogo NI en proyecto -[ ] Si existe en catálogo, seguí @REUTILIZAR -[ ] Si existe similar, pregunté qué hacer -``` - ---- - -## REFERENCIAS SIMCO - -- **@CATALOG** - Catálogo de funcionalidades reutilizables (CONSULTAR PRIMERO) -- **@REUTILIZAR** - Proceso para reutilizar del catálogo -- **@CREAR** - Proceso completo de creación (incluye verificación) -- **@BUSCAR** - Estrategias de búsqueda -- **@DOCUMENTAR** - Actualización de inventarios - ---- - -**Este principio es OBLIGATORIO y NO puede ser ignorado por ningún agente.** - ---- - -**Versión:** 1.0.0 | **Sistema:** SIMCO | **Tipo:** Principio Fundamental diff --git a/orchestration/_archive/directivas/principios/PRINCIPIO-CAPVED.md b/orchestration/_archive/directivas/principios/PRINCIPIO-CAPVED.md deleted file mode 100644 index b0d1532..0000000 --- a/orchestration/_archive/directivas/principios/PRINCIPIO-CAPVED.md +++ /dev/null @@ -1,384 +0,0 @@ ---- -tipo: ssot-normativo -nivel: 3-completo -es_ssot: true -versiones_derivadas: - - docs/30-directivas/CICLO-CAPVED.md (nivel 1 - resumen usuario) - - orchestration/_definitions/protocols/CAPVED-CYCLE.md (nivel 2 - tecnico) -actualizado: 2026-01-16 ---- - -# PRINCIPIO: CAPVED - Ciclo de Vida de Tareas - -**Versión:** 1.0.0 -**Fecha:** 2025-12-08 -**Tipo:** Principio Fundamental - HERENCIA OBLIGATORIA - **SSOT** -**Aplica a:** TODOS los agentes sin excepción -**Alias:** @CAPVED - ---- - -## DECLARACIÓN DEL PRINCIPIO - -``` -╔══════════════════════════════════════════════════════════════════════════════╗ -║ ║ -║ CAPVED: Contexto → Análisis → Planeación → Validación → Ejecución → Doc ║ -║ ║ -║ "Toda tarea que modifica código o documentación DEBE pasar por ║ -║ el ciclo completo CAPVED antes de considerarse Done." ║ -║ ║ -║ "Si aparece trabajo fuera del alcance original, se genera HU nueva." ║ -║ ║ -╚══════════════════════════════════════════════════════════════════════════════╝ -``` - ---- - -## QUÉ ES CAPVED - -CAPVED es un **ciclo de vida obligatorio** para toda Historia de Usuario (HU) o tarea técnica que involucre modificación de código o documentación. Garantiza: - -1. **Trazabilidad completa**: Desde el origen hasta la implementación -2. **Análisis de impacto**: Antes de tocar código -3. **Validación de coherencia**: Plan vs Análisis -4. **Generación controlada**: HUs derivadas para descubrimientos -5. **Documentación actualizada**: Como criterio de Done - ---- - -## LAS 6 FASES DE CAPVED - -``` -┌─────────────────────────────────────────────────────────────────────────────┐ -│ C - CONTEXTO │ -│ • Vincular HU a proyecto/módulo/epic │ -│ • Clasificar tipo: feature | fix | refactor | spike | doc-only │ -│ • Registrar origen: plan-original | descubrimiento | incidencia │ -│ • Cargar documentos SIMCO relevantes │ -├─────────────────────────────────────────────────────────────────────────────┤ -│ ↓ │ -├─────────────────────────────────────────────────────────────────────────────┤ -│ A - ANÁLISIS │ -│ • Comportamiento deseado (perspectiva de negocio) │ -│ • Restricciones: seguridad, performance, UX │ -│ • Objetos impactados: BD, Backend, Frontend, otros proyectos │ -│ • Dependencias con otras HUs (bloquea/bloqueada por) │ -│ • Riesgos identificados │ -│ → SALIDA: Lista de objetos + dependencias + riesgos │ -├─────────────────────────────────────────────────────────────────────────────┤ -│ ↓ │ -├─────────────────────────────────────────────────────────────────────────────┤ -│ P - PLANEACIÓN │ -│ • Desglose en subtareas por dominio (BD, BE, FE, Docs) │ -│ • Orden de ejecución y dependencias │ -│ • Criterios de aceptación por subtarea │ -│ • Plan de pruebas: unitarias, integración, regresión │ -│ • Asignación de agentes/subagentes │ -│ → SALIDA: Plan de ejecución con subtareas asignadas │ -├─────────────────────────────────────────────────────────────────────────────┤ -│ ↓ │ -├─────────────────────────────────────────────────────────────────────────────┤ -│ V - VALIDACIÓN (⚠️ NO DELEGAR - EJECUTAR DIRECTAMENTE) │ -│ • ¿Todo lo detectado en A tiene acción concreta en P? │ -│ • ¿Hay dependencias ocultas sin atender? │ -│ • ¿Criterios de aceptación cubren los riesgos? │ -│ • ¿Hay scope creep? → Registrar y crear HU derivada │ -│ → GATE: Solo pasa a Ejecución si todo cuadra │ -├─────────────────────────────────────────────────────────────────────────────┤ -│ ↓ │ -├─────────────────────────────────────────────────────────────────────────────┤ -│ E - EJECUCIÓN │ -│ • Actualizar docs/ del proyecto PRIMERO │ -│ • Ejecutar subtareas en orden establecido │ -│ • Cada subtarea: código + notas + validación (build/lint) │ -│ • Registrar progreso y desviaciones │ -│ → USAR: SIMCO correspondientes (CREAR, MODIFICAR, DDL, etc.) │ -├─────────────────────────────────────────────────────────────────────────────┤ -│ ↓ │ -├─────────────────────────────────────────────────────────────────────────────┤ -│ D - DOCUMENTACIÓN CONTINUA │ -│ • Actualizar diagramas y modelos de dominio │ -│ • Actualizar especificaciones técnicas (BD, APIs, contratos) │ -│ • Crear/actualizar ADRs si hubo decisiones arquitectónicas │ -│ • Actualizar inventarios (DATABASE, BACKEND, FRONTEND) │ -│ • Actualizar trazas de tareas │ -│ • Registrar HUs derivadas (si se generaron) │ -│ • Registrar lecciones aprendidas │ -│ → GATE: HU NO está Done si documentación no está actualizada │ -└─────────────────────────────────────────────────────────────────────────────┘ -``` - ---- - -## CUÁNDO APLICA CAPVED - -### APLICA A (Obligatorio): - -```yaml -Tareas_que_DEBEN_seguir_CAPVED: - - Nuevas features (cualquier tamaño) - - Bug fixes que modifican código - - Refactorizaciones - - Cambios en estructura de BD - - Nuevos endpoints de API - - Nuevos componentes de UI - - Cambios en lógica de negocio - - Integraciones con sistemas externos - - Cualquier tarea que genere commit -``` - -### NO APLICA A (Excepciones): - -```yaml -Tareas_exentas_de_CAPVED_completo: - - Corrección de typos en código (solo E+D) - - Actualización de dependencias menores (solo E+D) - - Tareas puramente exploratorias (solo lectura) - - Consultas de información - - Spikes de investigación sin implementación - -NOTA: Incluso las excepciones DEBEN documentar en trazas -``` - ---- - -## INTEGRACIÓN CON SIMCO - -CAPVED es el **ciclo de vida**, SIMCO son las **operaciones**: - -``` -CAPVED SIMCO -─────── ───── -C - Contexto → SIMCO-INICIALIZACION.md (CCA) -A - Análisis → SIMCO-BUSCAR.md + docs/ -P - Planeación → TEMPLATE-PLAN.md -V - Validación → Checklist CAPVED (este documento) -E - Ejecución → SIMCO-CREAR/MODIFICAR/DDL/BACKEND/FRONTEND -D - Documentación → SIMCO-DOCUMENTAR.md + inventarios + trazas -``` - -### Orden de Lectura para Agentes: - -```yaml -1. SIMCO-INICIALIZACION.md # Bootstrap con CCA -2. PRINCIPIO-CAPVED.md # Este documento (ciclo obligatorio) -3. PRINCIPIO-DOC-PRIMERO.md # Documentación antes de código -4. PRINCIPIO-ANTI-DUPLICACION.md # Verificar antes de crear -5. PRINCIPIO-VALIDACION-OBLIGATORIA.md # Build/lint obligatorios -6. SIMCO-TAREA.md # Proceso detallado CAPVED -7. SIMCO específicos según operación -``` - ---- - -## GENERACIÓN DE HUs DERIVADAS - -### Cuándo Generar HU Nueva: - -```yaml -Generar_HU_derivada_cuando: - # Durante Análisis (A) - - Se detecta bug estructural no relacionado al objetivo - - Se identifica deuda técnica que bloquea - - Se descubre dependencia no documentada - - # Durante Validación (V) - - Hay trabajo detectado fuera del alcance original - - Se requiere refactor previo no planificado - - Se identifica mejora de UX no solicitada - - # Durante Ejecución (E) - - Se encuentra código legacy que debe corregirse - - Se descubre inconsistencia en otra parte del sistema - - Se identifica oportunidad de optimización -``` - -### Proceso de Generación: - -```markdown -1. DETECTAR: Identificar que algo está fuera del alcance -2. REGISTRAR: Documentar en la sección "HUs Derivadas" de la HU actual -3. CREAR: Generar archivo de HU con prefijo DERIVED-{HU-ORIGEN}-{N} -4. VINCULAR: Referenciar la HU origen en la nueva HU -5. PRIORIZAR: Marcar como pendiente para siguiente planificación -6. CONTINUAR: Seguir con la HU original sin desviarse -``` - -### Template de Registro: - -```yaml -HUs_Derivadas: - - id: "DERIVED-HU-001-001" - origen: "HU-001" - tipo: "bug | feature | refactor | deuda-tecnica" - descripcion: "Descripción breve de lo detectado" - detectado_en_fase: "A | V | E" - prioridad_sugerida: "P0 | P1 | P2 | P3" - notas: "Contexto adicional relevante" -``` - ---- - -## CHECKLIST RÁPIDO CAPVED - -### Antes de Iniciar (C): -``` -[ ] HU vinculada a proyecto/módulo/epic -[ ] Tipo clasificado (feature/fix/refactor/spike/doc-only) -[ ] Origen registrado (plan/descubrimiento/incidencia) -[ ] Documentos SIMCO relevantes identificados -``` - -### Antes de Planificar (A completado): -``` -[ ] Comportamiento de negocio entendido -[ ] Objetos impactados listados (todas las capas) -[ ] Dependencias identificadas -[ ] Riesgos documentados -``` - -### Antes de Ejecutar (P+V completados): -``` -[ ] Subtareas definidas por dominio -[ ] Orden de ejecución establecido -[ ] Criterios de aceptación definidos -[ ] Plan vs Análisis validado (todo cubierto) -[ ] Scope creep registrado (si existe) -[ ] HUs derivadas creadas (si aplica) -``` - -### Durante Ejecución (E): -``` -[ ] docs/ actualizado PRIMERO -[ ] Subtareas ejecutadas en orden -[ ] Build/lint pasa por subtarea -[ ] Progreso registrado -``` - -### Antes de Cerrar (D): -``` -[ ] Diagramas/modelos actualizados -[ ] Specs técnicas actualizadas -[ ] ADRs creados (si decisión arquitectónica) -[ ] Inventarios actualizados -[ ] Trazas actualizadas -[ ] HUs derivadas vinculadas -[ ] Lecciones aprendidas registradas -``` - -### GATE DE CIERRE (OBLIGATORIO - @DEF_CHK_POST) - -> **ANTES de declarar una HU/tarea como DONE, ejecutar @DEF_CHK_POST** - -```markdown -## Checklist de Cierre Obligatorio - -### Gobernanza (BLOQUEANTE) -[ ] Carpeta de tarea existe: orchestration/tareas/TASK-{ID}/ -[ ] METADATA.yml completo con fases C, E, D -[ ] _INDEX.yml de tareas actualizado - -### Validaciones Técnicas -[ ] Build pasa (backend y/o frontend) -[ ] Lint pasa -[ ] Tests pasan (si existen) - -### Coherencia Entre Capas -[ ] DDL ↔ Backend verificado -[ ] Backend ↔ Frontend verificado (si aplica) - -### Inventarios -[ ] DATABASE_INVENTORY.yml (si cambió BD) -[ ] BACKEND_INVENTORY.yml (si cambió BE) -[ ] FRONTEND_INVENTORY.yml (si cambió FE) -[ ] MASTER_INVENTORY.yml actualizado - -### Trazas -[ ] Traza de tarea correspondiente actualizada -[ ] PROXIMA-ACCION.md actualizado - -### Propagación -[ ] Evaluado si aplica a otros proyectos -``` - -**SI FALLA CUALQUIER ITEM BLOQUEANTE:** HU permanece EN PROGRESO. - -**REFERENCIA:** `@TRIGGER_CIERRE` - orchestration/directivas/triggers/TRIGGER-CIERRE-TAREA-OBLIGATORIO.md - ---- - -## CONSECUENCIAS DE IGNORAR CAPVED - -``` -❌ Saltar Contexto (C) - → HU sin trazabilidad, trabajo desconectado del plan - -❌ Saltar Análisis (A) - → Impacto no previsto, bugs en otras partes del sistema - -❌ Saltar Planeación (P) - → Ejecución caótica, trabajo rehecho, tiempo perdido - -❌ Saltar Validación (V) - → Scope creep no controlado, trabajo infinito - -❌ Saltar Documentación (D) - → Sistema diverge de docs/, confusión futura, onboarding difícil -``` - ---- - -## LECCIONES APRENDIDAS - -### Registro Obligatorio: - -Al cerrar cada HU, registrar: - -```yaml -Lecciones_Aprendidas: - que_funciono_bien: - - "Descripción de práctica exitosa" - - que_se_puede_mejorar: - - "Descripción de área de mejora" - - para_futuras_HUs_similares: - - "Recomendación específica para HUs del mismo tipo" -``` - -### Ubicación: - -- En el archivo de la HU (sección final) -- Consolidar mensualmente en `orchestration/retrospectivas/` - ---- - -## REFERENCIAS SIMCO - -| Fase CAPVED | SIMCO Relacionados | -|-------------|-------------------| -| C - Contexto | `SIMCO-INICIALIZACION.md`, `CONTEXTO-PROYECTO.md` | -| A - Análisis | `SIMCO-BUSCAR.md`, `TEMPLATE-ANALISIS.md` | -| P - Planeación | `TEMPLATE-PLAN.md`, `SIMCO-DELEGACION.md` | -| V - Validación | `TEMPLATE-VALIDACION.md` | -| E - Ejecución | `SIMCO-CREAR.md`, `SIMCO-MODIFICAR.md`, `SIMCO-DDL.md`, etc. | -| D - Documentación | `SIMCO-DOCUMENTAR.md`, inventarios, trazas | - ---- - -## ALIAS - -```yaml -@CAPVED: core/orchestration/directivas/principios/PRINCIPIO-CAPVED.md -@TAREA: core/orchestration/directivas/simco/SIMCO-TAREA.md -@TPL_CAPVED: core/orchestration/templates/TEMPLATE-TAREA-CAPVED.md -``` - ---- - -**Este principio es OBLIGATORIO y NO puede ser ignorado por ningún agente.** - ---- - -**Versión:** 1.0.0 | **Sistema:** SIMCO + CAPVED | **Tipo:** Principio Fundamental diff --git a/orchestration/_archive/directivas/principios/PRINCIPIO-DOC-PRIMERO.md b/orchestration/_archive/directivas/principios/PRINCIPIO-DOC-PRIMERO.md deleted file mode 100644 index 769be33..0000000 --- a/orchestration/_archive/directivas/principios/PRINCIPIO-DOC-PRIMERO.md +++ /dev/null @@ -1,190 +0,0 @@ -# PRINCIPIO: DOCUMENTACIÓN PRIMERO - -**Versión:** 1.0.0 -**Fecha:** 2025-12-08 -**Tipo:** Principio Fundamental - HERENCIA OBLIGATORIA -**Aplica a:** TODOS los agentes sin excepción - ---- - -## DECLARACIÓN DEL PRINCIPIO - -``` -╔══════════════════════════════════════════════════════════════════════╗ -║ ║ -║ DOCUMENTACIÓN PRIMERO, IMPLEMENTACIÓN DESPUÉS ║ -║ ║ -║ "Si no está documentado, no existe." ║ -║ "Si contradice la documentación, está mal." ║ -║ ║ -╚══════════════════════════════════════════════════════════════════════╝ -``` - ---- - -## REGLA EN 3 PASOS - -``` -PASO 1: ANTES DE IMPLEMENTAR -───────────────────────────── -Consultar docs/ para entender: -- ¿Qué dice la documentación sobre esto? -- ¿Hay especificaciones o diseños? -- ¿Hay ADRs relacionados? - -PASO 2: SI HAY CAMBIO DE DISEÑO -───────────────────────────── -Actualizar docs/ PRIMERO: -- Documentar el nuevo diseño -- Crear ADR si es decisión arquitectónica -- Actualizar especificaciones - -PASO 3: IMPLEMENTAR -───────────────────────────── -Solo entonces escribir código: -- Seguir lo documentado -- Referenciar docs/ en comentarios si aplica -``` - ---- - -## FLUJO VISUAL - -``` -┌─────────────────────┐ -│ TAREA NUEVA │ -└──────────┬──────────┘ - │ - ▼ -┌─────────────────────┐ -│ ¿Consulté docs/? │──── NO ────► CONSULTAR DOCS/ PRIMERO -└──────────┬──────────┘ - │ SÍ - ▼ -┌─────────────────────┐ -│ ¿Hay contradicción? │──── SÍ ────► ACTUALIZAR DOCS/ PRIMERO -└──────────┬──────────┘ - │ NO - ▼ -┌─────────────────────┐ -│ ¿Falta documentar? │──── SÍ ────► DOCUMENTAR PRIMERO -└──────────┬──────────┘ - │ NO - ▼ -┌─────────────────────┐ -│ IMPLEMENTAR │ -└─────────────────────┘ -``` - ---- - -## DOCUMENTACIÓN A CONSULTAR - -### Antes de CUALQUIER tarea: -```yaml -Obligatorio: - - docs/00-vision-general/ # Visión y alcance - - docs/95-guias-desarrollo/ # Estándares y convenciones - - docs/97-adr/ # Decisiones arquitectónicas - -Si aplica: - - docs/01-fase-*/ # Especificaciones por fase - - docs/modulos/{modulo}/ # Especificaciones del módulo - - orchestration/inventarios/ # Estado actual del proyecto -``` - -### Para cada tipo de tarea: -```yaml -Database: - - @GUIAS/database/ (si existe) - - @ADR (decisiones de BD) - -Backend: - - @GUIAS_BE/DTO-CONVENTIONS.md - - @GUIAS_BE/API-CONVENTIONS.md - - @ADR - -Frontend: - - @GUIAS_FE/TYPES-CONVENTIONS.md - - @GUIAS_FE/COMPONENT-PATTERNS.md - - @ADR -``` - ---- - -## CUÁNDO ACTUALIZAR DOCS/ PRIMERO - -| Situación | Acción | -|-----------|--------| -| Nueva feature no documentada | Documentar diseño antes de implementar | -| Cambio de arquitectura | Crear ADR antes de implementar | -| Contradicción docs/ vs realidad | Actualizar docs/ (si realidad es correcta) | -| Nueva convención | Documentar en guías antes de usar | -| Nuevo módulo/schema | Documentar estructura antes de crear | - ---- - -## CUÁNDO NO APLICA - -```yaml -Excepciones (no requiere actualizar docs/ primero): - - Bug fixes menores (solo corrección, no cambio de diseño) - - Refactors internos (misma funcionalidad) - - Actualizaciones de dependencias - - Corrección de typos en código - -PERO siempre aplica: - - Consultar docs/ para entender el contexto - - Documentar en traza lo realizado - - Actualizar inventarios si hay cambios estructurales -``` - ---- - -## CONSECUENCIAS DE IGNORAR ESTE PRINCIPIO - -``` -❌ Código que contradice documentación - → Confusión, bugs, deuda técnica - -❌ Features no documentadas - → Nadie sabe qué hace ni por qué - -❌ Implementar sin consultar docs/ - → Duplicados, inconsistencias, trabajo rehecho - -❌ Cambiar arquitectura sin ADR - → Decisiones perdidas, errores repetidos -``` - ---- - -## CHECKLIST RÁPIDO - -``` -Antes de escribir código: -[ ] Consulté docs/ relevantes -[ ] No hay contradicción con lo documentado -[ ] Si hay cambio de diseño, actualicé docs/ primero - -Al terminar: -[ ] Código sigue lo documentado -[ ] Actualicé inventarios -[ ] Documenté en traza -``` - ---- - -## REFERENCIAS SIMCO - -- **@DOCUMENTAR** - Cómo documentar correctamente -- **@VALIDAR** - Validación de coherencia docs/código -- **@BUSCAR** - Cómo encontrar documentación - ---- - -**Este principio es OBLIGATORIO y NO puede ser ignorado por ningún agente.** - ---- - -**Versión:** 1.0.0 | **Sistema:** SIMCO | **Tipo:** Principio Fundamental diff --git a/orchestration/_archive/directivas/principios/PRINCIPIO-ECONOMIA-TOKENS.md b/orchestration/_archive/directivas/principios/PRINCIPIO-ECONOMIA-TOKENS.md deleted file mode 100644 index 250a4cc..0000000 --- a/orchestration/_archive/directivas/principios/PRINCIPIO-ECONOMIA-TOKENS.md +++ /dev/null @@ -1,292 +0,0 @@ -# PRINCIPIO: ECONOMÍA DE TOKENS - -**Versión:** 1.0.0 -**Fecha:** 2025-12-08 -**Aplica a:** Todos los agentes -**Prioridad:** OBLIGATORIA para evitar errores de context overflow - ---- - -## RESUMEN EJECUTIVO - -> **Los agentes tienen límites de tokens. Excederlos = fallo de tarea.** -> Planificar con economía de tokens = tareas exitosas. -> Tareas grandes sin desglose = error garantizado. - ---- - -## LÍMITES CRÍTICOS - -```yaml -CONTEXTO_MAXIMO: - entrada: ~200,000 tokens # Lo que el agente puede "ver" - salida: ~8,000 tokens # Lo que puede generar por respuesta - recomendado_carga: <50,000 tokens # Para dejar espacio de trabajo - -ARCHIVO_INDIVIDUAL: - maximo_recomendado: 500 líneas (~2,000 tokens) - ideal: 200-300 líneas (~1,000 tokens) - alerta: >400 líneas → considerar división - -PROMPT_DELEGACION: - maximo: 3,000 tokens (~750 líneas de prompt) - recomendado: 1,500 tokens (~375 líneas) - minimo_efectivo: 500 tokens (~125 líneas) -``` - ---- - -## REGLAS DE ECONOMÍA - -### Regla 1: Cargar Solo Lo Necesario - -```yaml -MAL: - - Cargar TODOS los archivos del proyecto - - Leer archivos completos cuando solo necesitas una sección - - Incluir documentación extendida en prompts de delegación - -BIEN: - - Cargar SOLO archivos relevantes para la tarea actual - - Usar SIMCO-QUICK-REFERENCE.md en lugar de _INDEX.md completo - - Referencias a archivos en vez de copiar contenido -``` - -### Regla 2: Desglosar Tareas Grandes - -```yaml -TAREA_GRANDE (>2000 tokens de output esperado): - - Dividir en subtareas independientes - - Cada subtarea = máximo 1 archivo o 1 función - - Secuenciar: crear → validar → siguiente - -EJEMPLO_MALO: - "Crear el módulo completo de usuarios con entity, service, - controller, DTOs, tests, y documentación" - # Esto generará >8000 tokens de salida = ERROR - -EJEMPLO_BUENO: - ST-001: Crear UserEntity alineada con DDL - ST-002: Crear CreateUserDto y UpdateUserDto - ST-003: Crear UserService con CRUD básico - ST-004: Crear UserController con endpoints - ST-005: Ejecutar build + lint - # Cada una <2000 tokens = ÉXITO -``` - -### Regla 3: Prompts de Delegación Concisos - -```yaml -INCLUIR: - - Contexto mínimo necesario (nivel, variables críticas) - - Tarea específica (1 cosa) - - Criterios de aceptación (checklist corto) - - 1-2 archivos de referencia máximo - -NO INCLUIR: - - Historia completa del proyecto - - Documentación extendida - - Múltiples opciones/alternativas - - Código de ejemplo extenso (>50 líneas) -``` - ---- - -## ESTRATEGIAS DE DESGLOSE - -### Por Capa (Vertical) - -```yaml -# En lugar de: "Crear feature de notificaciones" -# Desglosar en: - -ST-001_DATABASE: - tarea: "Crear tabla notifications.notifications" - output_esperado: ~300 tokens (1 archivo DDL) - -ST-002_BACKEND_ENTITY: - tarea: "Crear NotificationEntity" - output_esperado: ~200 tokens (1 archivo) - -ST-003_BACKEND_DTO: - tarea: "Crear DTOs de Notification" - output_esperado: ~300 tokens (2 archivos pequeños) - -ST-004_BACKEND_SERVICE: - tarea: "Crear NotificationService con CRUD" - output_esperado: ~400 tokens (1 archivo) - -ST-005_BACKEND_CONTROLLER: - tarea: "Crear NotificationController con endpoints" - output_esperado: ~350 tokens (1 archivo) - -ST-006_VALIDACION: - tarea: "Ejecutar build + lint backend" - output_esperado: ~100 tokens (comandos) -``` - -### Por Funcionalidad (Horizontal) - -```yaml -# En lugar de: "Implementar autenticación" -# Desglosar en: - -ST-001: Verificar @CATALOG (¿existe auth?) -ST-002: Si existe → usar SIMCO-REUTILIZAR -ST-003: Si no existe → crear esquema auth (DDL) -ST-004: Crear AuthModule básico (register/login) -ST-005: Crear JWT strategy -ST-006: Crear guards -ST-007: Integrar en app.module -ST-008: Validar build + lint -``` - ---- - -## ESTIMACIÓN DE TOKENS - -### Fórmula Rápida - -``` -tokens ≈ caracteres / 4 -tokens ≈ palabras * 1.3 -tokens ≈ líneas * 10 (código promedio) -``` - -### Tabla de Referencia - -| Tipo de Archivo | Líneas Típicas | Tokens Estimados | -|-----------------|----------------|------------------| -| Entity simple | 30-50 | 300-500 | -| Entity con relaciones | 80-120 | 800-1200 | -| DTO | 20-40 | 200-400 | -| Service CRUD | 100-150 | 1000-1500 | -| Controller REST | 80-120 | 800-1200 | -| Tabla DDL | 30-60 | 300-600 | -| Componente React simple | 50-80 | 500-800 | -| Componente React complejo | 150-250 | 1500-2500 | -| Hook | 30-60 | 300-600 | - ---- - -## DETECCIÓN DE PROBLEMAS - -### Señales de Alerta - -```yaml -ANTES_DE_EJECUTAR: - - [ ] ¿La tarea pide crear >3 archivos? → Desglosar - - [ ] ¿El prompt de delegación >1500 tokens? → Reducir - - [ ] ¿Se pide "módulo completo"? → Desglosar por componente - - [ ] ¿Se incluye código de referencia >50 líneas? → Usar referencia a archivo - -DURANTE_EJECUCION: - - [ ] ¿Respuesta truncada? → Tarea muy grande - - [ ] ¿Error de context? → Demasiados archivos cargados - - [ ] ¿Alucinaciones? → Contexto insuficiente o confuso -``` - -### Acciones Correctivas - -```yaml -SI_RESPUESTA_TRUNCADA: - 1. Dividir tarea en 2-3 subtareas - 2. Re-ejecutar cada subtarea por separado - 3. Validar entre subtareas - -SI_ERROR_CONTEXT: - 1. Descargar archivos no esenciales - 2. Usar SIMCO-QUICK-REFERENCE en lugar de _INDEX completo - 3. Referencias en lugar de contenido inline - -SI_ALUCINACIONES: - 1. Verificar que archivos de referencia se cargaron - 2. Incluir más contexto específico (menos genérico) - 3. Ser más explícito en criterios de aceptación -``` - ---- - -## TEMPLATE DE DELEGACIÓN OPTIMIZADO - -```yaml -# PROMPT OPTIMIZADO (~800 tokens) - -## SUBAGENTE: {Tipo} -Nivel: {nivel} | Proyecto: {proyecto} | Ruta: {orchestration_path} - -## TAREA ÚNICA -{Descripción en 1-2 oraciones} - -## ESPECIFICACIÓN -{Solo lo necesario, máximo 10 líneas} - -## REFERENCIA -- Archivo: `{ruta exacta}` (copiar patrón de líneas X-Y) - -## CRITERIOS (máximo 5) -- [ ] {criterio 1} -- [ ] {criterio 2} -- [ ] {criterio 3} - -## VALIDACIÓN -```bash -{1-2 comandos} -``` - -## ENTREGABLES -1. {archivo a crear/modificar} -``` - ---- - -## INTEGRACIÓN CON CAPVED - -### Fase P (Planeación) - Verificar Tokens - -```yaml -ANTES_DE_APROBAR_PLAN: - - [ ] Cada subtarea genera <2000 tokens de output - - [ ] Cada prompt de delegación <1500 tokens - - [ ] No hay subtareas que pidan "módulo completo" - - [ ] Subtareas son independientes (pueden fallar sin afectar otras) -``` - -### Fase E (Ejecución) - Monitorear - -```yaml -DURANTE_EJECUCION: - - Si subtarea falla por tokens → subdividir más - - Si contexto insuficiente → cargar archivo específico - - Si respuesta truncada → dividir y reintentar -``` - ---- - -## MÉTRICAS DE ÉXITO - -```yaml -TAREA_BIEN_DESGLOSADA: - - 0 errores de token overflow - - 0 respuestas truncadas - - Cada subtarea completa en 1 iteración - - Build pasa después de cada subtarea - -DELEGACION_OPTIMA: - - Prompt <1500 tokens - - Respuesta completa sin truncar - - Criterios verificables cumplidos - - Sin re-trabajo por malentendidos -``` - ---- - -## REFERENCIAS - -- **Referencia rápida:** `SIMCO-QUICK-REFERENCE.md` -- **Delegación:** `SIMCO-DELEGACION.md` -- **Desglose de tareas:** `SIMCO-TAREA.md` - ---- - -**Versión:** 1.0.0 | **Sistema:** SIMCO | **Tipo:** Principio Fundamental diff --git a/orchestration/_archive/directivas/principios/PRINCIPIO-NO-ASUMIR.md b/orchestration/_archive/directivas/principios/PRINCIPIO-NO-ASUMIR.md deleted file mode 100644 index e418081..0000000 --- a/orchestration/_archive/directivas/principios/PRINCIPIO-NO-ASUMIR.md +++ /dev/null @@ -1,361 +0,0 @@ -# PRINCIPIO: NO ASUMIR - -**Version:** 1.0.0 -**Fecha:** 2025-12-12 -**Tipo:** Principio Fundamental - HERENCIA OBLIGATORIA -**Aplica a:** TODOS los agentes sin excepcion - ---- - -## DECLARACION DEL PRINCIPIO - -``` -╔══════════════════════════════════════════════════════════════════════╗ -║ ║ -║ "Si no esta documentado, NO asumir. PREGUNTAR." ║ -║ ║ -║ Nunca implementar basado en suposiciones. ║ -║ Nunca inventar requisitos. ║ -║ Nunca tomar decisiones de negocio sin autorizacion. ║ -║ ║ -╚══════════════════════════════════════════════════════════════════════╝ -``` - ---- - -## REGLA INQUEBRANTABLE - -``` -┌─────────────────────────────────────────────────────────────────────┐ -│ │ -│ PROHIBIDO: │ -│ - Asumir valores/comportamientos no documentados │ -│ - Inventar requisitos o especificaciones │ -│ - Tomar decisiones de negocio sin consultar │ -│ - Implementar "lo que parece logico" sin confirmacion │ -│ - Interpretar ambiguedad a favor de una opcion │ -│ - Completar huecos de documentacion con suposiciones │ -│ │ -│ OBLIGATORIO: │ -│ - Detener trabajo cuando falta informacion critica │ -│ - Documentar la pregunta claramente │ -│ - Escalar al Product Owner │ -│ - Esperar respuesta antes de continuar │ -│ - Documentar la decision antes de implementar │ -│ │ -└─────────────────────────────────────────────────────────────────────┘ -``` - ---- - -## POR QUE ESTE PRINCIPIO - -```yaml -problema: - - Implementaciones basadas en suposiciones causan retrabajo - - Asunciones incorrectas generan bugs de negocio - - Decisiones no autorizadas crean deuda tecnica - - Interpretaciones personales divergen del objetivo real - -consecuencias_de_asumir: - - Codigo que no cumple requisitos reales - - Retrabajo costoso cuando se descubre la asuncion incorrecta - - Perdida de confianza del cliente/PO - - Documentacion desalineada con implementacion - - Bugs dificiles de rastrear (parecen funcionar pero no son correctos) - -beneficios_de_preguntar: - - Implementacion correcta desde el inicio - - Documentacion completa y precisa - - Menos retrabajo - - Mayor confianza del equipo - - Decisiones respaldadas por autoridad correcta -``` - ---- - -## CUANDO APLICA ESTE PRINCIPIO - -### Casos que REQUIEREN Escalamiento - -```yaml -informacion_faltante: - - Tabla mencionada sin definicion de columnas - - Endpoint sin especificacion de payload - - Pagina sin definicion de componentes - - Regla de negocio incompleta - - Valores de enum no especificados - - Validaciones no documentadas - - Comportamiento de error no definido - - Limites/umbrales no especificados - -ambiguedad: - - Requisito interpretable de multiples formas - - Contradiccion entre documentos - - Alcance no claramente definido - - Criterios de aceptacion vagos - - Casos edge no cubiertos - -decisiones_de_negocio: - - Cambio que afecta UX - - Modificacion de flujos existentes - - Nuevas restricciones - - Priorizacion entre alternativas - - Trade-offs con impacto en usuario -``` - -### Casos que NO Requieren Escalamiento - -```yaml -decisiones_tecnicas_puras: - - Nombre de variable interna - - Estructura de codigo (si no afecta API) - - Optimizaciones de rendimiento - - Refactorizaciones internas - → Consultar Architecture-Analyst si hay duda - -implementacion_clara: - - Documentacion existe y es clara - - No hay ambiguedad - - Comportamiento esta especificado - → Proceder con implementacion - -estandares_definidos: - - Nomenclatura definida en directivas - - Patrones definidos en SIMCO - - Convenciones del proyecto - → Seguir lo establecido -``` - ---- - -## COMO APLICAR ESTE PRINCIPIO - -### Paso 1: Buscar Exhaustivamente - -```yaml -ANTES_de_escalar: - buscar_en: - - docs/01-requerimientos/ - - docs/02-especificaciones-tecnicas/ - - docs/97-adr/ - - orchestration/inventarios/ - - Codigo existente relacionado - - Historial de trazas - - tiempo_minimo: "10-15 minutos de busqueda activa" -``` - -### Paso 2: Si No se Encuentra, Documentar - -```markdown -## INFORMACION NO ENCONTRADA - -**Busqueda realizada:** -- [X] docs/01-requerimientos/ - No encontrado -- [X] docs/02-especificaciones-tecnicas/ - Mencionado pero incompleto -- [X] ADRs - No hay ADR relacionado -- [X] Inventarios - N/A - -**Conclusion:** Informacion no disponible, requiere escalamiento -``` - -### Paso 3: Escalar Correctamente - -```markdown -## CONSULTA AL PRODUCT OWNER - -**Fecha:** {fecha} -**Agente:** {agente} -**Tarea:** [{ID}] {titulo} - -### Contexto -{que estoy haciendo} - -### Lo que encontre -{informacion parcial disponible} - -### Lo que falta / es ambiguo -{descripcion clara del gap} - -### Pregunta especifica -{pregunta concreta} - -### Opciones (si las identifique) -1. {opcion A} -2. {opcion B} - -### Impacto -{que pasa si no se resuelve} -``` - -### Paso 4: Esperar y Documentar Respuesta - -```yaml -MIENTRAS_espero: - - NO implementar esa parte - - Continuar con otras tareas si es posible - - Marcar tarea como BLOQUEADA si es critico - -CUANDO_recibo_respuesta: - - Documentar la decision - - Actualizar documentacion correspondiente - - Crear ADR si es decision significativa - - Continuar implementacion -``` - ---- - -## FLUJO DE DECISION - -``` -┌─────────────────────────────────────┐ -│ Encontrar informacion faltante │ -│ o ambiguedad │ -└──────────────┬──────────────────────┘ - │ - ▼ -┌─────────────────────────────────────┐ -│ Buscar exhaustivamente en docs │ -│ (10-15 minutos minimo) │ -└──────────────┬──────────────────────┘ - │ - ▼ - ┌──────┴──────┐ - │ Encontrado? │ - └──────┬──────┘ - │ - ┌────────┴────────┐ - │ SI │ NO - ▼ ▼ -┌───────────┐ ┌─────────────────────┐ -│ Proceder │ │ DETENER │ -│ con │ │ Documentar pregunta │ -│ implement │ │ Escalar al PO │ -└───────────┘ └──────────┬──────────┘ - │ - ▼ - ┌─────────────────────┐ - │ ESPERAR respuesta │ - │ (NO asumir) │ - └──────────┬──────────┘ - │ - ▼ - ┌─────────────────────┐ - │ Documentar decision │ - │ Continuar │ - └─────────────────────┘ -``` - ---- - -## EJEMPLOS - -### Ejemplo CORRECTO - -```yaml -situacion: "DDL menciona campo 'status' pero no especifica valores" - -proceso_correcto: - 1. Buscar en docs/: No encontrado - 2. Buscar en specs: Solo dice "tiene status" - 3. Buscar en ADRs: No hay ADR - 4. Conclusion: Escalar - 5. Documentar: "Cuales son los valores validos de status?" - 6. Esperar respuesta - 7. PO responde: "['draft', 'active', 'completed']" - 8. Documentar decision - 9. Implementar con valores correctos -``` - -### Ejemplo INCORRECTO - -```yaml -situacion: "DDL menciona campo 'status' pero no especifica valores" - -proceso_incorrecto: - 1. "Parece que deberian ser 'pending', 'done'" - 2. Implementar con esos valores - 3. PO revisa y dice: "No, son 'draft', 'active', 'completed'" - 4. Retrabajo: migration, seed update, tests, backend, frontend - 5. Tiempo perdido: 2-4 horas -``` - ---- - -## CONSECUENCIAS DE IGNORAR - -```yaml -ignorar_este_principio: - retrabajo: - - Implementacion incorrecta debe rehacerse - - Tests basados en asuncion incorrecta - - Documentacion desalineada - - bugs_de_negocio: - - Funcionalidad no cumple expectativas - - Comportamiento inesperado para usuarios - - Datos incorrectos en sistema - - deuda_tecnica: - - Codigo parche sobre asuncion incorrecta - - Inconsistencias acumuladas - - Complejidad innecesaria - - perdida_de_confianza: - - PO pierde confianza en implementaciones - - Mas revision necesaria - - Ciclos de feedback mas largos -``` - ---- - -## CHECKLIST RAPIDO - -``` -Antes de implementar algo no 100% claro: - -[ ] Busque en documentacion? (10-15 min minimo) -[ ] Revise specs, ADRs, inventarios? -[ ] Sigue sin estar claro? -[ ] Documente la pregunta? -[ ] Escale al PO? -[ ] Espere respuesta? -[ ] Documente la decision? -[ ] Actualice documentacion correspondiente? - -Solo entonces: Proceder con implementacion -``` - ---- - -## RELACION CON OTROS PRINCIPIOS - -```yaml -PRINCIPIO-DOC-PRIMERO: - - Leer docs antes de implementar - - Si docs estan incompletos -> NO-ASUMIR aplica - -PRINCIPIO-CAPVED: - - Fase A (Analisis): Identificar informacion faltante - - Fase V (Validacion): NO aprobar sin informacion completa - -PRINCIPIO-VALIDACION-OBLIGATORIA: - - Validar que implementacion coincide con decision documentada -``` - ---- - -## REFERENCIAS SIMCO - -- **@ESCALAMIENTO** - Proceso completo de escalamiento -- **@DOC_PRIMERO** - Consultar documentacion primero -- **@TAREA** - Ciclo de vida de tareas - ---- - -**Este principio es OBLIGATORIO y NO puede ser ignorado por ningun agente.** - ---- - -**Version:** 1.0.0 | **Sistema:** SIMCO | **Tipo:** Principio Fundamental diff --git a/orchestration/_archive/directivas/principios/PRINCIPIO-VALIDACION-OBLIGATORIA.md b/orchestration/_archive/directivas/principios/PRINCIPIO-VALIDACION-OBLIGATORIA.md deleted file mode 100644 index 55070dc..0000000 --- a/orchestration/_archive/directivas/principios/PRINCIPIO-VALIDACION-OBLIGATORIA.md +++ /dev/null @@ -1,248 +0,0 @@ -# PRINCIPIO: VALIDACIÓN OBLIGATORIA - -**Versión:** 1.0.0 -**Fecha:** 2025-12-08 -**Tipo:** Principio Fundamental - HERENCIA OBLIGATORIA -**Aplica a:** TODOS los agentes sin excepción - ---- - -## DECLARACIÓN DEL PRINCIPIO - -``` -╔══════════════════════════════════════════════════════════════════════╗ -║ ║ -║ BUILD PASA + LINT PASA = REQUISITO MÍNIMO ║ -║ ║ -║ "Código que no compila NO está terminado." ║ -║ "Tarea con errores NO está completada." ║ -║ ║ -╚══════════════════════════════════════════════════════════════════════╝ -``` - ---- - -## REGLA INQUEBRANTABLE - -``` -┌─────────────────────────────────────────────────────────────────────┐ -│ │ -│ NINGUNA tarea se marca como COMPLETADA si: │ -│ │ -│ • Build falla │ -│ • Lint tiene errores críticos │ -│ • Carga limpia falla (para DDL) │ -│ • Tests fallan (si existen) │ -│ │ -└─────────────────────────────────────────────────────────────────────┘ -``` - ---- - -## VALIDACIONES POR CAPA - -### Database (DDL) -```bash -# OBLIGATORIO -cd @DB_SCRIPTS -./{RECREATE_CMD} # Carga limpia DEBE pasar - -# Verificación -psql -d {DB_NAME} -c "\dt {schema}.*" # Tablas creadas -psql -d {DB_NAME} -c "\di {schema}.*" # Índices creados -``` - -### Backend (NestJS) -```bash -# OBLIGATORIO -cd @BACKEND_ROOT -npm run build # DEBE pasar -npm run lint # DEBE pasar - -# Adicional -npm run test # Si hay tests, DEBEN pasar -npm run start:dev # DEBE iniciar sin errores -``` - -### Frontend (React) -```bash -# OBLIGATORIO -cd @FRONTEND_ROOT -npm run build # DEBE pasar -npm run lint # DEBE pasar - -# Adicional -npm run typecheck # DEBE pasar -npm run dev # DEBE iniciar sin errores -``` - ---- - -## FLUJO DE VALIDACIÓN - -``` -TERMINAR IMPLEMENTACIÓN - │ - ▼ -┌─────────────────────┐ -│ EJECUTAR BUILD │ -└──────────┬──────────┘ - │ - ▼ -┌─────────────────────┐ ┌─────────────────────┐ -│ ¿BUILD PASA? │──NO──►│ CORREGIR ERRORES │ -└──────────┬──────────┘ └──────────┬──────────┘ - │ SÍ │ - │◄────────────────────────────┘ - ▼ -┌─────────────────────┐ ┌─────────────────────┐ -│ EJECUTAR LINT │──NO──►│ CORREGIR ERRORES │ -│ ¿LINT PASA? │ └──────────┬──────────┘ -└──────────┬──────────┘ │ - │ SÍ │ - │◄────────────────────────────┘ - ▼ -┌─────────────────────┐ ┌─────────────────────┐ -│ EJECUTAR TESTS │──NO──►│ CORREGIR TESTS │ -│ ¿TESTS PASAN? │ └──────────┬──────────┘ -└──────────┬──────────┘ │ - │ SÍ │ - │◄────────────────────────────┘ - ▼ -┌─────────────────────┐ -│ ✅ TAREA COMPLETA │ -└─────────────────────┘ -``` - ---- - -## QUÉ HACER CUANDO FALLA - -### Build Falla -```markdown -1. NO marcar tarea como completada -2. Leer el error completo -3. Identificar archivo y línea -4. Corregir el error -5. Volver a ejecutar build -6. Repetir hasta que pase -``` - -### Lint Falla (Errores) -```markdown -1. NO marcar tarea como completada -2. Distinguir errores de warnings - - Errores (error): DEBEN corregirse - - Warnings (warn): Pueden ignorarse (pero mejor corregir) -3. Corregir todos los errores -4. Volver a ejecutar lint -5. Repetir hasta que pase -``` - -### Carga Limpia Falla (DDL) -```markdown -1. NO marcar tarea como completada -2. NO ejecutar fix manual en BD -3. Leer el error de PostgreSQL -4. Corregir archivo DDL -5. Volver a ejecutar carga limpia completa -6. Repetir hasta que pase -``` - -### Tests Fallan -```markdown -1. NO marcar tarea como completada -2. Identificar test que falla -3. Determinar si: - a. El código tiene bug → Corregir código - b. El test está desactualizado → Actualizar test -4. Volver a ejecutar tests -5. Repetir hasta que pasen -``` - ---- - -## EXCEPCIONES (MUY LIMITADAS) - -```yaml -Puede marcarse completa SIN tests: - - Si no existen tests para el módulo (pero build y lint DEBEN pasar) - - Se documenta: "Tests pendientes de crear" - -Puede tener warnings de lint: - - Si son warnings menores (no errores) - - Se documenta: "N warnings de lint pendientes" - -NUNCA puede marcarse completa: - - Con build fallando - - Con errores de lint - - Con carga limpia fallando -``` - ---- - -## REPORTE DE VALIDACIÓN - -En toda entrega incluir: - -```markdown -## Validaciones - -| Validación | Comando | Resultado | -|------------|---------|-----------| -| Build | `npm run build` | ✅ Pasa / ❌ Falla | -| Lint | `npm run lint` | ✅ Pasa / ⚠️ Warnings / ❌ Errores | -| Tests | `npm run test` | ✅ Pasa / ❌ Falla / ⏭️ N/A | -| Carga Limpia | `./{RECREATE_CMD}` | ✅ Pasa / ❌ Falla / ⏭️ N/A | - -**Estado:** ✅ Validaciones completas / ❌ Pendiente corrección -``` - ---- - -## CONSECUENCIAS DE IGNORAR - -``` -❌ Código que no compila entregado - → Bloquea a otros agentes/desarrolladores - -❌ Errores de lint ignorados - → Código inconsistente, bugs potenciales - -❌ Tests fallando ignorados - → Regresiones, bugs en producción - -❌ DDL con errores - → BD inconsistente, datos corruptos -``` - ---- - -## CHECKLIST RÁPIDO - -``` -Antes de marcar CUALQUIER tarea como completada: - -[ ] Build pasa sin errores -[ ] Lint pasa sin errores (warnings OK) -[ ] Tests pasan (si existen) -[ ] Carga limpia pasa (si es DDL) -[ ] Aplicación inicia correctamente -``` - ---- - -## REFERENCIAS SIMCO - -- **@VALIDAR** - Proceso completo de validación -- **@OP_DDL** - Validación específica de database -- **@OP_BACKEND** - Validación específica de backend -- **@OP_FRONTEND** - Validación específica de frontend - ---- - -**Este principio es OBLIGATORIO y NO puede ser ignorado por ningún agente.** - ---- - -**Versión:** 1.0.0 | **Sistema:** SIMCO | **Tipo:** Principio Fundamental diff --git a/orchestration/_archive/directivas/principios/PROPAGACION-ARCHITECTURE.md b/orchestration/_archive/directivas/principios/PROPAGACION-ARCHITECTURE.md deleted file mode 100644 index 9d88826..0000000 --- a/orchestration/_archive/directivas/principios/PROPAGACION-ARCHITECTURE.md +++ /dev/null @@ -1,316 +0,0 @@ -# PROPAGACION-ARCHITECTURE: Arquitectura de Propagacion del Workspace - -**ID:** PROPAGACION-ARCHITECTURE -**Version:** 1.0.0 -**Fecha:** 2026-01-13 -**Autor:** CLAUDE-CAPVED - ---- - -## Proposito - -Este documento clarifica la arquitectura de propagacion del workspace, cuando usar cada mecanismo, y como se relacionan los diferentes componentes del sistema de propagacion. - ---- - -## Jerarquia de Propagacion - -``` -┌─────────────────────────────────────────────────────────────────────────────┐ -│ NIVELES DE PROPAGACION │ -├─────────────────────────────────────────────────────────────────────────────┤ -│ │ -│ NIVEL 0: PROVIDER │ -│ ┌──────────────────┐ │ -│ │ template-saas │ → Provee funcionalidades base a todos │ -│ │ (v1.2.1) │ │ -│ └────────┬─────────┘ │ -│ │ │ -│ ▼ │ -│ NIVEL 1: INTERMEDIATE │ -│ ┌──────────────────┐ │ -│ │ erp-core │ → Extiende y adapta para verticales ERP │ -│ │ (v1.3.0) │ │ -│ └────────┬─────────┘ │ -│ │ │ -│ ├─────────────────────────────────────────────────┐ │ -│ ▼ ▼ │ -│ NIVEL 2: CONSUMERS NIVEL 2: INTERMEDIATE │ -│ ┌──────────────────┐ ┌──────────────────┐ │ -│ │ erp-construccion │ │ erp-clinicas │ │ -│ │ erp-mecanicas │ │ (v1.0.0) │ │ -│ │ erp-retail │ └────────┬─────────┘ │ -│ │ erp-vidrio │ │ │ -│ └──────────────────┘ ▼ │ -│ NIVEL 3: SUB-CONSUMERS │ -│ ┌──────────────────┐ │ -│ │ clinica-dental │ │ -│ │ clinica-veterina │ │ -│ └──────────────────┘ │ -│ │ -└─────────────────────────────────────────────────────────────────────────────┘ -``` - ---- - -## Componentes del Sistema de Propagacion - -### 1. Directivas - -| Componente | Ubicacion | Proposito | -|------------|-----------|-----------| -| **MODE-PROPAGATION** | `directivas/modos/` | Modo de ejecucion para propagar cambios entre proyectos | -| **TRIGGER-PROPAGACION-AUTOMATICA** | `directivas/triggers/` | Activa automaticamente en Fase D para evaluar propagacion | -| **SIMCO-PROPAGACION** | `directivas/simco/` | Propagacion de documentacion en verticales (interno) | - -### 2. Referencias - -| Componente | Ubicacion | Proposito | -|------------|-----------|-----------| -| **PROPAGATION-CRITERIA-MATRIX** | `referencias/` | Matriz de criterios para decidir propagacion | -| **DEPENDENCY-GRAPH** | `orchestration/` | Grafo de dependencias entre proyectos | -| **TRACEABILITY-MASTER** | `orchestration/` | Trazabilidad centralizada del workspace | - -### 3. Mirrors - -| Componente | Ubicacion | Proposito | -|------------|-----------|-----------| -| **MIRRORS-INDEX** | `shared/mirrors/` | Indice de todos los repositorios espejo | -| **PROPAGATION-STATUS** | `shared/mirrors/{proyecto}/` | Estado de propagacion por proyecto | - ---- - -## Cuando Usar Cada Mecanismo - -### MODE-PROPAGATION (@PROPAGATE) - -**Usar cuando:** -- Necesitas propagar un cambio especifico a multiples proyectos -- Cambio en erp-core que debe ir a verticales -- Fix de seguridad que afecta multiples proyectos -- Bug fix en modulo compartido -- Actualizacion de dependencias compartidas - -**Ejemplos:** -```bash -@PROPAGATE-ERP Distribuir fix de JWT a verticales -@PROPAGATE-SECURITY Fix de vulnerabilidad XSS -@PROPAGATE-CATALOG Actualizar modulo de notificaciones -``` - -**Flujo:** -``` -Cambio en origen → CAPVED completo → Aplicar en cada destino → Validar → Documentar -``` - ---- - -### TRIGGER-PROPAGACION-AUTOMATICA - -**Usar cuando:** -- Se activa automaticamente al completar Fase D -- No lo invocas directamente, el sistema lo evalua - -**Cuando se activa:** -1. Completas una tarea en proyecto con propagacion (erp-core, shared/catalog) -2. El trigger evalua tipo de cambio -3. Sugiere o inicia propagacion segun reglas - -**Flujo:** -``` -Tarea completada → Trigger evalua → Decide accion → Notifica o propaga -``` - ---- - -### SIMCO-PROPAGACION - -**Usar cuando:** -- Propagas documentacion DENTRO de un proyecto vertical -- No es para propagacion ENTRE proyectos -- Es para estructurar documentacion de modulos heredados - -**Cuando se usa:** -- Al documentar un modulo heredado en una vertical -- Para asegurar que la documentacion refleja la herencia - -**NO usar para:** -- Propagar codigo entre proyectos (usar MODE-PROPAGATION) -- Propagar cambios de core a verticales (usar MODE-PROPAGATION) - ---- - -## Flujo de Decision - -``` -┌─────────────────────────────────────────────────────────────────┐ -│ PREGUNTA: Que necesitas propagar? │ -└────────────────────────────┬────────────────────────────────────┘ - │ - ┌──────────────┴──────────────┐ - ▼ ▼ - ┌────────────────┐ ┌─────────────────┐ - │ CODIGO/CAMBIO │ │ DOCUMENTACION │ - │ entre proyectos│ │ dentro de │ - └───────┬────────┘ │ proyecto │ - │ └────────┬────────┘ - ▼ │ - ┌────────────────────┐ ▼ - │ Es security fix? │ ┌─────────────────┐ - └─────────┬──────────┘ │ SIMCO-PROPAGACION│ - │ │ (interno) │ - ┌────────┴────────┐ └─────────────────┘ - ▼ ▼ -┌─────────┐ ┌─────────┐ -│ SI │ │ NO │ -└────┬────┘ └────┬────┘ - │ │ - ▼ ▼ -┌──────────────┐ ┌───────────────────────┐ -│ @PROPAGATE- │ │ Es bug fix? │ -│ SECURITY │ └───────────┬───────────┘ -│ (inmediato) │ ┌──────┴──────┐ -└──────────────┘ ▼ ▼ - ┌─────────┐ ┌─────────┐ - │ SI │ │ NO │ - └────┬────┘ └────┬────┘ - │ │ - ▼ ▼ - ┌──────────────┐ ┌───────────────┐ - │ @PROPAGATE- │ │ @PROPAGATE │ - │ ERP │ │ (evaluar) │ - │ (72h SLA) │ │ │ - └──────────────┘ └───────────────┘ -``` - ---- - -## SLAs Unificados - -| Tipo de Cambio | SLA | Prioridad | Accion | -|----------------|-----|-----------|--------| -| **Security Fix** | 24 horas | CRITICA | Propagar inmediatamente | -| **Bug Fix** | 72 horas | ALTA | Propagar con prioridad | -| **Feature** | 1 semana | MEDIA | Evaluar si aplica | -| **Refactor** | 2 semanas | BAJA | Opcional | -| **Documentacion** | Inmediato | N/A | Auto-sync via mirrors | -| **Definiciones** | Inmediato | N/A | Auto-sync via mirrors | - ---- - -## Sistema de Mirrors - -### Proposito -Los mirrors son repositorios espejo que facilitan la propagacion automatica de: -- Documentacion (README, CHANGELOG) -- Definiciones (YAML de modulos) -- Interfaces (TypeScript .d.ts) - -### Mirrors Activos - -| Mirror | Version | Consumidores | -|--------|---------|--------------| -| template-saas | 1.2.1 | erp-core | -| erp-core | 1.3.0 | 5 verticales + 2 sub-verticales | -| erp-clinicas | 1.0.0 | clinica-dental, clinica-veterinaria | - -### Auto-Propagacion via Mirrors - -```yaml -Tipo: Documentacion/Definiciones -Flujo: - 1. Cambio en proyecto origen - 2. Sync automatico a shared/mirrors/{proyecto}/ - 3. Consumidores leen del mirror - 4. Actualizacion inmediata disponible - -Tipo: Codigo -Flujo: - 1. Cambio en proyecto origen - 2. Validacion local (build+lint+tests) - 3. Propagar manualmente via MODE-PROPAGATION - 4. Actualizar PROPAGATION-STATUS.yml -``` - ---- - -## Trazabilidad - -### Donde se registra cada propagacion - -| Registro | Ubicacion | Contenido | -|----------|-----------|-----------| -| **TRACEABILITY-MASTER** | `orchestration/` | Registro centralizado de todas las propagaciones | -| **PROPAGATION-STATUS** | `shared/mirrors/{proyecto}/` | Estado por proyecto mirror | -| **MASTER_INVENTORY** | `{proyecto}/orchestration/inventarios/` | Referencia a ultima propagacion recibida | - -### Formato de Registro - -```yaml -propagacion: - id: "PROP-CORE-002" - fecha: "2026-01-13" - tipo: "bulk_propagation" - origen: "erp-core" - destinos: - - erp-construccion - - erp-clinicas - - erp-mecanicas-diesel - - erp-retail - - erp-vidrio-templado - sub_destinos: - - clinica-dental (via erp-clinicas) - - clinica-veterinaria (via erp-clinicas) - modulos: MGN-016 a MGN-022 - estado: "completed" -``` - ---- - -## Comandos Rapidos - -| Alias | Descripcion | Ejemplo | -|-------|-------------|---------| -| `@PROPAGATE-ERP` | Propagar de erp-core a verticales | `@PROPAGATE-ERP Fix de autenticacion` | -| `@PROPAGATE-CATALOG` | Propagar cambio de catalogo | `@PROPAGATE-CATALOG Actualizar notifications` | -| `@PROPAGATE-SECURITY` | Propagacion urgente de seguridad | `@PROPAGATE-SECURITY Vulnerabilidad XSS` | -| `@SYNC-MIRRORS` | Sincronizar todos los mirrors | `@SYNC-MIRRORS` | -| `@PROPAGATE-DOC` | Propagar documentacion | `@PROPAGATE-DOC {proyecto}` | -| `@PROPAGATE-DEF` | Propagar definiciones | `@PROPAGATE-DEF {proyecto}` | -| `@PROPAGATE-CODE` | Propagar codigo validado | `@PROPAGATE-CODE {proyecto}` | - ---- - -## Errores Comunes - -### 1. Confundir MODE-PROPAGATION con SIMCO-PROPAGACION -- **MODE-PROPAGATION:** Entre proyectos (erp-core → verticales) -- **SIMCO-PROPAGACION:** Dentro de un proyecto (documentacion interna) - -### 2. Propagar sin validar -- **Correcto:** Siempre ejecutar build+lint+tests antes de propagar -- **Incorrecto:** Propagar directamente sin validacion - -### 3. Olvidar actualizar trazabilidad -- **Correcto:** Registrar en TRACEABILITY-MASTER y PROPAGATION-STATUS -- **Incorrecto:** Propagar sin documentar - -### 4. Propagar codigo no validado -- **Documentacion/Definiciones:** OK propagar inmediatamente -- **Codigo:** SIEMPRE validar antes de propagar - ---- - -## Referencias - -- `orchestration/directivas/modos/MODE-PROPAGATION.md` -- `orchestration/directivas/triggers/TRIGGER-PROPAGACION-AUTOMATICA.md` -- `orchestration/directivas/simco/SIMCO-PROPAGACION.md` -- `orchestration/referencias/PROPAGATION-CRITERIA-MATRIX.yml` -- `orchestration/TRACEABILITY-MASTER.yml` -- `orchestration/DEPENDENCY-GRAPH.yml` -- `shared/mirrors/MIRRORS-INDEX.yml` - ---- - -*PROPAGACION-ARCHITECTURE v1.0.0 - Sistema SAAD* diff --git a/orchestration/_archive/directivas/simco/SIMCO-GIT.md b/orchestration/_archive/directivas/simco/SIMCO-GIT.md deleted file mode 100644 index a8b049f..0000000 --- a/orchestration/_archive/directivas/simco/SIMCO-GIT.md +++ /dev/null @@ -1,510 +0,0 @@ -# SIMCO: GIT (Control de Versiones) - -**Version:** 1.2.0 -**Fecha:** 2026-01-16 -**Aplica a:** TODO agente que modifica codigo o documentacion -**Prioridad:** OBLIGATORIA - ---- - -## RESUMEN EJECUTIVO - -> **Todo cambio en codigo o documentacion DEBE versionarse correctamente.** -> **Commits frecuentes, atomicos y descriptivos.** -> **PUSH OBLIGATORIO al finalizar cada tarea.** -> **FETCH OBLIGATORIO antes de verificar estado.** -> **Nunca perder trabajo por falta de commits o push.** - ---- - -## REGLA CRITICA 1: FETCH ANTES DE OPERAR - -``` -╔══════════════════════════════════════════════════════════════════════════╗ -║ ║ -║ ANTES DE CUALQUIER VERIFICACION DE ESTADO GIT: ║ -║ ║ -║ 1. git fetch origin ║ -║ → Obtener estado actual del remoto ║ -║ ║ -║ 2. git log HEAD..origin/main --oneline ║ -║ → Si hay output = hay commits remotos que no tienes ║ -║ ║ -║ 3. Si hay commits remotos: ║ -║ git pull --no-recurse-submodules ║ -║ → Sincronizar antes de continuar ║ -║ ║ -║ 4. AHORA SI: git status ║ -║ → Verificar estado local ║ -║ ║ -║ SIN FETCH = ESTADO INCOMPLETO ║ -║ (Otro agente pudo hacer cambios en otra sesion) ║ -║ ║ -║ Referencia: INC-2026-01-16-001 ║ -║ ║ -╚══════════════════════════════════════════════════════════════════════════╝ -``` - -### Secuencia Obligatoria de Verificacion - -```bash -# SIEMPRE ejecutar en este orden: -git fetch origin -git log HEAD..origin/main --oneline # Si hay output, hacer pull -git pull --no-recurse-submodules # Solo si paso anterior tiene output -git status # Ahora si verificar estado local -``` - ---- - -## REGLA CRITICA 2: COMMIT + PUSH OBLIGATORIO - -``` -╔══════════════════════════════════════════════════════════════════════════╗ -║ ║ -║ TODA TAREA QUE CREA O MODIFICA ARCHIVOS DEBE TERMINAR CON: ║ -║ ║ -║ 1. git add . ║ -║ 2. git commit -m "[ID] tipo: descripcion" ║ -║ 3. git push origin {rama} ║ -║ ║ -║ SIN PUSH = TAREA INCOMPLETA ║ -║ ║ -║ En workspace con SUBMODULES: ║ -║ - Commitear y push en CADA submodule afectado ║ -║ - Luego commitear y push en workspace principal ║ -║ ║ -╚══════════════════════════════════════════════════════════════════════════╝ -``` - -### Checklist Fin de Tarea (OBLIGATORIO) - -```yaml -ANTES_de_reportar_tarea_completada: - - [ ] Todos los archivos creados/modificados estan guardados - - [ ] git status muestra archivos a commitear - - [ ] git add {archivos} - - [ ] git commit -m "[TAREA-ID] tipo: descripcion" - - [ ] git push origin {rama} - - [ ] Verificar: git status muestra "nothing to commit, working tree clean" - - [ ] Verificar: git log origin/main..HEAD muestra vacio (todo pusheado) - -SI_hay_SUBMODULES: - - [ ] Repetir proceso en CADA submodule modificado - - [ ] Luego actualizar referencias en workspace principal - - [ ] Push final del workspace principal -``` - -### Secuencia para Workspace con Submodules - -```bash -# 1. Commitear en cada submodule modificado -cd projects/{submodule} -git add . -git commit -m "[TAREA-ID] tipo: descripcion" -git push origin main - -# 2. Repetir para cada submodule afectado -# ... - -# 3. Actualizar workspace principal -cd /home/isem/workspace-v2 -git add projects/{submodule} # Actualiza referencia del submodule -git commit -m "[WORKSPACE] chore: Update submodule references" -git push origin main - -# 4. Verificar todo sincronizado -git status # Debe mostrar "clean" -``` - ---- - -## PRINCIPIOS FUNDAMENTALES - -``` -╔══════════════════════════════════════════════════════════════════════╗ -║ ║ -║ "Commitear temprano, commitear frecuentemente" ║ -║ ║ -║ Cada commit debe: ║ -║ - Representar un cambio logico completo ║ -║ - Ser funcional (no romper compilacion) ║ -║ - Ser reversible sin afectar otros cambios ║ -║ - Tener mensaje descriptivo con ID de tarea ║ -║ ║ -╚══════════════════════════════════════════════════════════════════════╝ -``` - ---- - -## FRECUENCIA DE COMMITS - -```yaml -OBLIGATORIO_commitear: - - Al finalizar cada fase (Analisis, Planeacion, Ejecucion) - - Al completar cada archivo significativo - - Cada 30-45 minutos de trabajo continuo - - Antes de lanzar subagentes - - Despues de validar trabajo de subagentes - - Antes de cambiar de tarea - - Cuando build + lint pasan - -RAZON: "Minimizar perdida de trabajo en caso de error" -``` - ---- - -## FORMATO DE MENSAJE DE COMMIT - -### Estructura Obligatoria - -``` -[{TAREA-ID}] {tipo}: {descripcion concisa} - -{cuerpo opcional - descripcion detallada} - -{footer opcional - referencias, breaking changes} -``` - -### Ejemplos Correctos - -```bash -# Feature nueva -[DB-042] feat: Crear tabla projects con soporte PostGIS - -# Bug fix -[BE-015] fix: Corregir validacion de codigo unico en ProjectService - -# Refactor -[FE-008] refactor: Extraer componente ProjectCard de ProjectList - -# Documentacion -[DB-042] docs: Actualizar DATABASE_INVENTORY con tabla projects - -# Tests -[BE-015] test: Agregar tests unitarios para ProjectService - -# Subtarea -[DB-042-SUB-001] feat: Implementar indices para tabla projects -``` - -### Ejemplos Incorrectos - -```bash -# Sin ID de tarea -fix: Corregir bug - -# Muy vago -[BE-015] update: Cambios varios - -# Demasiado largo en primera linea -[DB-042] feat: Crear tabla projects con todas las columnas necesarias incluyendo soporte para PostGIS y configuracion de indices compuestos para optimizar queries - -# Sin tipo -[FE-008] Mejorar componente -``` - ---- - -## TIPOS DE COMMITS - -| Tipo | Uso | Ejemplo | -|------|-----|---------| -| `feat` | Nueva funcionalidad | `[DB-042] feat: Agregar soporte PostGIS` | -| `fix` | Correccion de bug | `[BE-015] fix: Resolver error en constraint` | -| `refactor` | Refactorizacion sin cambio funcional | `[FE-008] refactor: Mejorar estructura componentes` | -| `docs` | Solo documentacion | `[DB-042] docs: Actualizar README con schema` | -| `test` | Agregar/modificar tests | `[BE-015] test: Agregar tests para ProjectService` | -| `chore` | Tareas de mantenimiento | `[DB-042] chore: Actualizar dependencias` | -| `style` | Formato/estilo (sin cambio logico) | `[FE-008] style: Aplicar prettier` | -| `perf` | Mejora de performance | `[DB-042] perf: Agregar indice compuesto` | -| `build` | Cambios en build/deps | `[BE-015] build: Actualizar TypeORM a v0.3` | -| `ci` | Cambios en CI/CD | `[INFRA-001] ci: Agregar workflow de tests` | - ---- - -## COMMITS ATOMICOS - -### Que es un Commit Atomico - -```yaml -atomico: - - Representa UN cambio logico completo - - Es funcional (build pasa) - - Es reversible individualmente - - No mezcla cambios no relacionados - -NO_atomico: - - Multiples cambios no relacionados - - Trabajo incompleto (excepto WIP explicito) - - Mezcla de fix y feat - - Cambios en multiples features -``` - -### Ejemplo de Atomicidad - -```bash -# CORRECTO - Commits atomicos separados -[DB-042] feat: Crear tabla projects -[DB-042] feat: Agregar indices a tabla projects -[DB-042] feat: Crear seeds para projects -[DB-042] docs: Actualizar inventario con tabla projects - -# INCORRECTO - Un commit masivo -[DB-042] feat: Crear tabla projects con indices, seeds y actualizacion de inventario -``` - ---- - -## FLUJO DE TRABAJO GIT - -### Antes de Empezar Tarea - -```bash -# 1. Asegurar rama actualizada -git fetch origin -git pull origin main - -# 2. Crear rama de trabajo (si aplica) -git checkout -b feature/{TAREA-ID}-descripcion-corta - -# 3. Verificar estado limpio -git status -``` - -### Durante la Tarea - -```bash -# 1. Hacer cambios -# ... editar archivos ... - -# 2. Verificar que build pasa -npm run build -npm run lint - -# 3. Agregar cambios -git add {archivos especificos} -# o para todos los cambios relacionados: -git add . - -# 4. Commit con mensaje descriptivo -git commit -m "[TAREA-ID] tipo: descripcion" - -# 5. Repetir para cada cambio logico -``` - -### Al Completar Tarea - -```bash -# 1. Verificar historial -git log --oneline -5 - -# 2. Push a remoto -git push origin {rama} - -# 3. Crear PR si aplica -gh pr create --title "[TAREA-ID] Descripcion" --body "..." -``` - ---- - -## CHECKLIST PRE-COMMIT - -```yaml -ANTES_de_cada_commit: - - [ ] Build pasa sin errores - - [ ] Lint pasa sin errores criticos - - [ ] Tests pasan (si existen) - - [ ] Cambios son logicamente completos - - [ ] No hay archivos no deseados (node_modules, .env, etc.) - - [ ] Mensaje sigue formato correcto - -VERIFICAR: - git status # Ver archivos modificados - git diff # Ver cambios en detalle - git diff --cached # Ver cambios staged -``` - ---- - -## ERRORES COMUNES - -| Error | Consecuencia | Solucion | -|-------|--------------|----------| -| No commitear frecuentemente | Perdida de trabajo | Commit cada 30-45 min | -| Commits masivos | Dificil revertir | Commits atomicos | -| Mensajes vagos | Historial incomprensible | Seguir formato | -| Commit con build roto | Bloquea CI/CD | Verificar antes de commit | -| Olvidar ID de tarea | Perdida de trazabilidad | Siempre incluir [TAREA-ID] | -| Commitear secretos | Brecha de seguridad | Verificar .gitignore | - ---- - -## ARCHIVOS A IGNORAR (.gitignore) - -```yaml -SIEMPRE_ignorar: - - node_modules/ - - .env - - .env.* - - dist/ - - build/ - - coverage/ - - *.log - - .DS_Store - - *.tmp - - *.cache - -NUNCA_commitear: - - Credenciales - - API keys - - Passwords - - Certificados privados - - Archivos de configuracion local -``` - ---- - -## RAMAS (BRANCHING) - -### Convencion de Nombres - -```yaml -ramas: - feature: feature/{TAREA-ID}-descripcion-corta - bugfix: bugfix/{TAREA-ID}-descripcion-corta - hotfix: hotfix/{TAREA-ID}-descripcion-corta - release: release/v{X.Y.Z} - -ejemplos: - - feature/DB-042-crear-tabla-projects - - bugfix/BE-015-fix-validacion - - hotfix/SEC-001-fix-xss - - release/v2.1.0 -``` - -### Flujo de Ramas - -``` -main (produccion) - │ - ├─── develop (desarrollo) - │ │ - │ ├─── feature/DB-042-* - │ │ └── merge a develop - │ │ - │ ├─── feature/BE-015-* - │ │ └── merge a develop - │ │ - │ └── release/v2.1.0 - │ └── merge a main + tag - │ - └─── hotfix/SEC-001-* - └── merge a main + develop -``` - ---- - -## REVERTIR CAMBIOS - -### Revertir Ultimo Commit (no pusheado) - -```bash -# Mantener cambios en working directory -git reset --soft HEAD~1 - -# Descartar cambios completamente -git reset --hard HEAD~1 -``` - -### Revertir Commit ya Pusheado - -```bash -# Crear commit de reversion (seguro) -git revert {commit-hash} -git push -``` - -### Deshacer Cambios en Archivo - -```bash -# Descartar cambios no staged -git checkout -- {archivo} - -# Descartar cambios staged -git reset HEAD {archivo} -git checkout -- {archivo} -``` - ---- - -## SITUACIONES ESPECIALES - -### Work in Progress (WIP) - -```bash -# Cuando necesitas commitear trabajo incompleto -git commit -m "[TAREA-ID] WIP: descripcion de estado actual" - -# Luego, completar y hacer commit final -# (opcional: squash commits WIP antes de PR) -``` - -### Antes de Lanzar Subagente - -```bash -# SIEMPRE commitear antes de delegar -git add . -git commit -m "[TAREA-ID] chore: Estado antes de delegacion a {SubAgente}" -``` - -### Despues de Validar Subagente - -```bash -# Commitear resultado de subagente -git add . -git commit -m "[TAREA-ID-SUB-XXX] tipo: Resultado de {SubAgente}" -``` - ---- - -## VALIDACION DE COMMITS - -### Verificar Historial - -```bash -# Ver ultimos commits -git log --oneline -10 - -# Ver commits de tarea especifica -git log --oneline --grep="DB-042" - -# Ver cambios de un commit -git show {commit-hash} -``` - -### Verificar Formato de Mensaje - -```yaml -formato_valido: - - Tiene [TAREA-ID] al inicio - - Tiene tipo valido (feat, fix, etc.) - - Descripcion concisa (<72 caracteres primera linea) - - No tiene errores de ortografia graves - -verificar_manualmente: - git log --oneline -1 - # Debe mostrar: {hash} [TAREA-ID] tipo: descripcion -``` - ---- - -## REFERENCIAS - -- **Principio de Validacion:** @PRINCIPIOS/PRINCIPIO-VALIDACION-OBLIGATORIA.md -- **Documentar:** @SIMCO/SIMCO-DOCUMENTAR.md -- **Crear:** @SIMCO/SIMCO-CREAR.md - ---- - -**Version:** 1.0.0 | **Sistema:** SIMCO | **Mantenido por:** Tech Lead diff --git a/orchestration/_archive/directivas/simco/SIMCO-TAREA.md b/orchestration/_archive/directivas/simco/SIMCO-TAREA.md deleted file mode 100644 index 30ae4dc..0000000 --- a/orchestration/_archive/directivas/simco/SIMCO-TAREA.md +++ /dev/null @@ -1,829 +0,0 @@ -# SIMCO: CICLO DE VIDA DE TAREAS (CAPVED) - -**Versión:** 1.1.0 -**Sistema:** SIMCO - Gestión de Tareas con CAPVED -**Propósito:** Definir el proceso completo para toda HU/Tarea que modifica código o documentación -**Actualizado:** 2025-12-08 - ---- - -## PRINCIPIO FUNDAMENTAL - -> **Toda tarea que genera commit DEBE pasar por el ciclo CAPVED completo.** -> **Si algo aparece fuera del alcance, se registra y genera HU nueva.** -> **NUEVO: Antes de CAPVED, ejecutar FASE 0 para identificar nivel y contexto.** - ---- - -## FASE 0: IDENTIFICACIÓN DE NIVEL (NUEVA - CRÍTICA) - -**OBLIGATORIO antes de iniciar CAPVED** - -### 0.1 Determinar Nivel Jerárquico - -```yaml -Paso_1: Identificar en qué nivel del workspace estás trabajando - -NIVEL_0_WORKSPACE: - ruta: "/workspace/orchestration/" - identificador: "Es directiva global o índice de workspace" - -NIVEL_1_CORE: - ruta: "/workspace/core/" - identificador: "Es funcionalidad de catálogo o directiva" - -NIVEL_2A_STANDALONE: - ruta: "/workspace/projects/{proyecto}/" - identificador: "NO tiene subcarpeta verticales/" - ejemplos: "gamilit, trading-platform, betting-analytics" - -NIVEL_2B_SUITE: - ruta: "/workspace/projects/{suite}/" - identificador: "TIENE subcarpeta apps/verticales/" - ejemplo: "erp-suite" - -NIVEL_2B1_SUITE_CORE: - ruta: "/workspace/projects/{suite}/apps/erp-core/" - identificador: "Es el núcleo de la suite" - -NIVEL_2B2_VERTICAL: - ruta: "/workspace/projects/{suite}/apps/verticales/{vertical}/" - identificador: "Es vertical especializada" - ejemplos: "construccion, vidrio-templado, clinicas, retail" - -NIVEL_3_CATALOGO: - ruta: "/workspace/shared/catalog/{funcionalidad}/" - identificador: "Es funcionalidad reutilizable" -``` - -### 0.2 Cargar Contexto del Nivel - -```yaml -Archivos_a_leer_según_nivel: - - STANDALONE: - - orchestration/templates/TEMPLATE-CONTEXTO-PROYECTO.md - - orchestration/templates/HERENCIA-SIMCO.md - - orchestration/inventarios/MASTER_INVENTORY.yml - - VERTICAL: - - orchestration/templates/TEMPLATE-CONTEXTO-PROYECTO.md - - orchestration/templates/HERENCIA-SIMCO.md - - orchestration/templates/HERENCIA-ERP-CORE-TEMPLATE.md - - orchestration/inventarios/MASTER_INVENTORY.yml - - SUITE_CORE: - - orchestration/templates/TEMPLATE-CONTEXTO-PROYECTO.md - - orchestration/inventarios/MASTER_INVENTORY.yml - - orchestration/inventarios/DEVENV-MASTER-INVENTORY.yml -``` - -### 0.3 Identificar Ruta de Propagación - -```yaml -Según_tu_nivel_actual: - - STANDALONE → propagar a: - - WORKSPACE (orchestration/WORKSPACE-STATUS.md) - - VERTICAL → propagar a: - - SUITE (../../../orchestration/inventarios/) - - WORKSPACE (orchestration/WORKSPACE-STATUS.md) - - SUITE_CORE → propagar a: - - SUITE (../../orchestration/inventarios/) - - WORKSPACE (orchestration/WORKSPACE-STATUS.md) - - VERTICALES (si afecta herencia) - - CATALOGO → propagar a: - - CORE (inventarios/CORE_INVENTORY.yml) - - CONSUMIDORES (CATALOG-USAGE-TRACKING.yml) -``` - -### 0.4 Registrar Identificación - -```yaml -# Resultado de Fase 0 (incluir en reporte) -fase_0_identificacion: - nivel: "{NIVEL_IDENTIFICADO}" - proyecto: "{NOMBRE}" - path: "{RUTA_COMPLETA}" - propagacion_a: - - "{nivel_superior_1}" - - "{nivel_superior_2}" - contexto_cargado: - - TEMPLATE-CONTEXTO-PROYECTO.md ✓ - - HERENCIA-SIMCO.md ✓ - - MASTER_INVENTORY.yml ✓ - herencia_especifica: "{Si aplica: HERENCIA-ERP-CORE-TEMPLATE.md}" -``` - -### 0.5 Verificar Catálogo - -```yaml -ANTES_de_proceder_a_CAPVED: - verificar: "¿Lo que voy a crear existe en @CATALOG?" - comando: "Buscar en shared/catalog/CATALOG-INDEX.yml" - - SI_EXISTE: - - Leer SIMCO-REUTILIZAR.md - - Adaptar en lugar de crear - - Documentar adaptación - - SI_NO_EXISTE: - - Proceder con CAPVED normal - - Considerar contribuir al catálogo al finalizar -``` - ---- - -## CUÁNDO USAR ESTE SIMCO - -```yaml -USAR_SIMCO_TAREA_cuando: - - Recibes una HU o tarea técnica - - La tarea involucra modificar código - - La tarea involucra modificar documentación - - La tarea generará uno o más commits - - Cualquier trabajo que no sea puramente exploratorio - -NO_USAR_cuando: - - Solo estás investigando/explorando (usa SIMCO-BUSCAR) - - Solo estás consultando información - - Es un spike sin implementación -``` - ---- - -## FLUJO COMPLETO CAPVED - -``` -┌─────────────────────────────────────────────────────────────────────────────┐ -│ │ -│ ENTRADA: HU o Tarea Técnica │ -│ │ -│ ┌──────────────────────────────────────────────────────────────────────┐ │ -│ │ FASE C: CONTEXTO (~5 min) │ │ -│ │ ──────────────────────────── │ │ -│ │ 1. Identificar proyecto/módulo/epic │ │ -│ │ 2. Clasificar tipo de tarea │ │ -│ │ 3. Registrar origen │ │ -│ │ 4. Cargar contexto SIMCO (CCA) │ │ -│ │ 5. Vincular documentos relevantes │ │ -│ └──────────────────────────────────────────────────────────────────────┘ │ -│ │ │ -│ ▼ │ -│ ┌──────────────────────────────────────────────────────────────────────┐ │ -│ │ FASE A: ANÁLISIS (~15 min) │ │ -│ │ ────────────────────────── │ │ -│ │ 1. Entender comportamiento deseado (negocio) │ │ -│ │ 2. Identificar restricciones (seguridad/perf/UX) │ │ -│ │ 3. Mapear objetos impactados (BD, BE, FE, otros) │ │ -│ │ 4. Identificar dependencias (HUs bloqueantes/bloqueadas) │ │ -│ │ 5. Detectar riesgos │ │ -│ │ → SALIDA: Reporte de análisis │ │ -│ └──────────────────────────────────────────────────────────────────────┘ │ -│ │ │ -│ ▼ │ -│ ┌──────────────────────────────────────────────────────────────────────┐ │ -│ │ FASE P: PLANEACIÓN (~10 min) │ │ -│ │ ───────────────────────────── │ │ -│ │ 1. Desglosar en subtareas por dominio │ │ -│ │ 2. Establecer orden de ejecución │ │ -│ │ 3. Definir criterios de aceptación │ │ -│ │ 4. Planificar pruebas │ │ -│ │ 5. Asignar agentes/subagentes (si aplica) │ │ -│ │ → SALIDA: Plan de ejecución │ │ -│ └──────────────────────────────────────────────────────────────────────┘ │ -│ │ │ -│ ▼ │ -│ ┌──────────────────────────────────────────────────────────────────────┐ │ -│ │ FASE V: VALIDACIÓN (~5 min) ⚠️ NO DELEGAR │ │ -│ │ ──────────────────────────────────────────── │ │ -│ │ 1. ¿Todo lo de A tiene acción en P? │ │ -│ │ 2. ¿Dependencias resueltas o planificadas? │ │ -│ │ 3. ¿Criterios cubren riesgos? │ │ -│ │ 4. ¿Hay scope creep? → Registrar + crear HU derivada │ │ -│ │ → GATE: Solo pasa si TODO cuadra │ │ -│ └──────────────────────────────────────────────────────────────────────┘ │ -│ │ │ -│ ┌─────────┴─────────┐ │ -│ │ ¿VALIDACIÓN OK? │ │ -│ └─────────┬─────────┘ │ -│ NO │ │ SÍ │ -│ ▼ ▼ │ -│ ┌────────────┐ ┌──────────────────────────────────────────┐ │ -│ │ AJUSTAR │ │ FASE E: EJECUCIÓN (variable) │ │ -│ │ A o P │ │ ───────────────────────────── │ │ -│ │ y volver │ │ 1. Actualizar docs/ PRIMERO │ │ -│ │ a V │ │ 2. Ejecutar subtareas en orden │ │ -│ └────────────┘ │ 3. Validar build/lint por subtarea │ │ -│ │ 4. Registrar progreso │ │ -│ │ 5. Usar SIMCO correspondientes │ │ -│ │ → SALIDA: Código implementado │ │ -│ └──────────────────────────────────────────┘ │ -│ │ │ -│ ▼ │ -│ ┌──────────────────────────────────────────────────────────────────────┐ │ -│ │ FASE D: DOCUMENTACIÓN (~10 min) │ │ -│ │ ─────────────────────────────── │ │ -│ │ 1. Actualizar diagramas/modelos │ │ -│ │ 2. Actualizar specs técnicas │ │ -│ │ 3. Crear ADR (si decisión arquitectónica) │ │ -│ │ 4. Actualizar inventarios │ │ -│ │ 5. Actualizar trazas │ │ -│ │ 6. Vincular HUs derivadas │ │ -│ │ 7. Registrar lecciones aprendidas │ │ -│ │ → GATE: HU NO está Done sin esto │ │ -│ └──────────────────────────────────────────────────────────────────────┘ │ -│ │ │ -│ ▼ │ -│ │ -│ SALIDA: HU Completada, Documentada, Trazable │ -│ │ -└─────────────────────────────────────────────────────────────────────────────┘ -``` - ---- - -## FASE C: CONTEXTO (Detalle) - -### C.1 Identificar Proyecto/Módulo/Epic - -```yaml -Contexto_Obligatorio: - proyecto: "{nombre del proyecto}" - ruta_proyecto: "projects/{proyecto}/" - modulo: "{nombre del módulo afectado}" - epic_padre: "{EPIC-ID} - {nombre}" - feature_padre: "{FEATURE-ID} - {nombre}" # si aplica -``` - -### C.2 Clasificar Tipo de Tarea - -```yaml -Tipos_de_Tarea: - feature: "Nueva funcionalidad" - enhancement: "Mejora a funcionalidad existente" - fix: "Corrección de bug" - refactor: "Reestructuración sin cambio funcional" - spike: "Investigación técnica" - doc-only: "Solo documentación" - tech-debt: "Pago de deuda técnica" - security: "Corrección de seguridad" - performance: "Optimización de rendimiento" -``` - -### C.3 Registrar Origen - -```yaml -Origenes_de_Tarea: - plan-original: "Parte del plan de proyecto/sprint" - descubrimiento: "Detectada durante otra tarea" - incidencia: "Reportada por usuario/QA" - mejora-continua: "Identificada en retrospectiva" - dependencia: "Requerida por otra HU" -``` - -### C.4 Cargar Contexto SIMCO (CCA) - -``` -Seguir protocolo de SIMCO-INICIALIZACION.md: -1. Leer principios fundamentales (4 ahora con CAPVED) -2. Leer perfil del agente -3. Leer CONTEXTO-PROYECTO.md -4. Leer inventarios relevantes -5. Cargar SIMCO de operación según tipo de tarea -``` - -### C.5 Vincular Documentos Relevantes - -```yaml -Documentos_a_Vincular: - docs_proyecto: - - "docs/{fase}/{epic}/README.md" - - "docs/{fase}/{epic}/requerimientos/{archivo}.md" - - "docs/{fase}/{epic}/especificaciones/{archivo}.md" - - docs_tecnicos: - - "docs/95-guias-desarrollo/{relevantes}.md" - - "docs/97-adr/{relacionados}.md" - - orchestration: - - "orchestration/inventarios/{relevantes}.yml" - - "orchestration/trazas/TRAZA-{tipo}.md" -``` - ---- - -## FASE A: ANÁLISIS (Detalle) - -### A.1 Comportamiento Deseado (Negocio) - -```yaml -Preguntas_de_Negocio: - - "¿Qué debe poder hacer el usuario al completar esta HU?" - - "¿Qué problema de negocio resuelve?" - - "¿Cuál es el criterio de éxito desde perspectiva de usuario?" - - "¿Hay casos de uso específicos documentados?" - -Formato_Respuesta: - como: "{rol de usuario}" - quiero: "{acción deseada}" - para: "{beneficio/valor}" -``` - -### A.2 Restricciones - -```yaml -Restricciones_a_Identificar: - seguridad: - - "¿Requiere autenticación?" - - "¿Requiere autorización por rol?" - - "¿Maneja datos sensibles?" - - "¿Aplica RLS?" - - performance: - - "¿Volumen esperado de datos?" - - "¿Tiempo de respuesta esperado?" - - "¿Requiere paginación?" - - "¿Requiere caché?" - - ux: - - "¿Hay wireframes/mockups?" - - "¿Estados de carga definidos?" - - "¿Manejo de errores definido?" - - "¿Responsive requerido?" -``` - -### A.3 Mapear Objetos Impactados - -```yaml -Objetos_por_Capa: - database: - schemas: [] # Schemas afectados - tablas: [] # Tablas a crear/modificar - vistas: [] # Vistas afectadas - funciones: [] # Funciones a crear/modificar - indices: [] # Índices necesarios - triggers: [] # Triggers afectados - rls_policies: [] # Políticas RLS - - backend: - modulos: [] # Módulos NestJS - entities: [] # Entities TypeORM - services: [] # Services - controllers: [] # Controllers - dtos: [] # DTOs (Request/Response) - guards: [] # Guards de autorización - pipes: [] # Pipes de validación - - frontend: - paginas: [] # Páginas/rutas - componentes: [] # Componentes React - hooks: [] # Custom hooks - stores: [] # Stores Zustand - types: [] # TypeScript types/interfaces - services: [] # Services de API - - otros: - proyectos: [] # Otros proyectos afectados - integraciones: [] # Integraciones externas - jobs: [] # Jobs/colas - caches: [] # Caché a invalidar -``` - -### A.4 Identificar Dependencias - -```yaml -Dependencias: - bloquea_a: # Esta HU bloquea a otras - - hu_id: "HU-XXX" - razon: "Necesita la tabla que creo" - - bloqueada_por: # Esta HU depende de otras - - hu_id: "HU-YYY" - razon: "Necesito el endpoint de auth" - estado: "completada | en-progreso | pendiente" - - relacionadas: # HUs relacionadas (no bloqueo directo) - - hu_id: "HU-ZZZ" - relacion: "Mismo módulo" -``` - -### A.5 Detectar Riesgos - -```yaml -Riesgos_Identificados: - - id: "R1" - descripcion: "Cambio en tabla users afecta auth de todos los tenants" - probabilidad: "alta | media | baja" - impacto: "alto | medio | bajo" - mitigacion: "Ejecutar en horario de bajo tráfico, tener rollback listo" -``` - ---- - -## FASE P: PLANEACIÓN (Detalle) - -### P.1 Desglosar en Subtareas - -```yaml -Subtareas: - documentacion: # SIEMPRE PRIMERO - - id: "ST-001" - descripcion: "Actualizar spec de API en docs/" - artefactos: ["docs/.../.md"] - - database: - - id: "ST-002" - descripcion: "Crear tabla users en schema auth" - artefactos: ["ddl/schemas/auth/tables/users.sql"] - agente: "Database-Agent" - - backend: - - id: "ST-003" - descripcion: "Crear UserEntity alineada con DDL" - artefactos: ["src/modules/users/entities/user.entity.ts"] - agente: "Backend-Agent" - depende_de: ["ST-002"] - - - id: "ST-004" - descripcion: "Crear UsersService con CRUD" - artefactos: ["src/modules/users/users.service.ts"] - agente: "Backend-Agent" - depende_de: ["ST-003"] - - frontend: - - id: "ST-005" - descripcion: "Crear UserList component" - artefactos: ["src/components/users/UserList.tsx"] - agente: "Frontend-Agent" - depende_de: ["ST-004"] - - validacion: # SIEMPRE AL FINAL - - id: "ST-006" - descripcion: "Validación final build/lint/tests" - agente: "Ejecutar directamente" -``` - -### P.2 Orden de Ejecución - -``` -1. Documentación (docs/ actualizados) - ↓ -2. Database (DDL, migraciones) - ↓ -3. Backend (Entities → Services → Controllers) - ↓ -4. Frontend (Types → Hooks → Components → Pages) - ↓ -5. Validación (build, lint, tests) - ↓ -6. Documentación final (inventarios, trazas) -``` - -### P.3 Criterios de Aceptación - -```yaml -Criterios_de_Aceptacion: - funcionales: - - "Usuario puede crear registro" - - "Usuario puede listar registros con paginación" - - "Usuario puede editar registro existente" - - "Usuario puede eliminar registro (soft delete)" - - tecnicos: - - "Build pasa sin errores" - - "Lint pasa sin errores" - - "Tests unitarios cubren >80%" - - "API documentada en Swagger" - - documentacion: - - "Inventarios actualizados" - - "Trazas registradas" - - "ADR creado (si aplica)" -``` - -### P.4 Plan de Pruebas - -```yaml -Plan_de_Pruebas: - unitarias: - - "Service: CRUD operations" - - "Guards: permission checks" - - integracion: - - "API: endpoints responden correctamente" - - "DB: datos persisten correctamente" - - e2e: - - "Flujo completo crear-editar-eliminar" - - regresion: - - "Auth sigue funcionando" - - "Otros módulos no afectados" -``` - ---- - -## FASE V: VALIDACIÓN (Detalle) - -### V.1 Verificar Cobertura Análisis → Plan - -```yaml -Verificacion_Cobertura: - objetos_database: - - objeto: "tabla users" - en_analisis: true - en_plan: "ST-002" - ✓ CUBIERTO - - objetos_backend: - - objeto: "UserEntity" - en_analisis: true - en_plan: "ST-003" - ✓ CUBIERTO - - # Si algo en Análisis NO tiene subtarea en Plan: - gap_detectado: - - objeto: "índice en email" - en_analisis: true - en_plan: false - accion: "Agregar subtarea ST-002b" -``` - -### V.2 Verificar Dependencias - -```yaml -Verificacion_Dependencias: - - hu_dependencia: "HU-YYY" - estado: "completada" - ✓ LISTA - - - hu_dependencia: "HU-ZZZ" - estado: "pendiente" - ⚠️ BLOQUEADOR - accion: "Esperar o crear subtarea previa" -``` - -### V.3 Detectar Scope Creep - -```yaml -Scope_Creep_Detectado: - - item: "Se necesita también endpoint de búsqueda" - parte_de_hu_original: false - accion: "CREAR HU DERIVADA" - hu_derivada: - id: "DERIVED-HU-001-001" - descripcion: "Endpoint de búsqueda de usuarios" - prioridad: "P2" -``` - -### V.4 Gate de Validación - -``` -CHECKLIST GATE: -[ ] Todo objeto de Análisis tiene subtarea en Plan -[ ] Todas las dependencias están resueltas o planificadas -[ ] Criterios de aceptación cubren todos los riesgos -[ ] Scope creep registrado y HUs derivadas creadas -[ ] No hay gaps sin resolver - -→ Si TODO marcado: PROCEDER A EJECUCIÓN -→ Si algo falta: VOLVER A AJUSTAR A o P -``` - ---- - -## FASE E: EJECUCIÓN (Detalle) - -### E.1 Actualizar docs/ PRIMERO - -```yaml -Antes_de_Codigo: - - Actualizar specs de API - - Actualizar diagramas de entidades - - Actualizar documentación de módulo - - Verificar que docs/ refleja lo que se va a implementar -``` - -### E.2 Ejecutar Subtareas en Orden - -Para cada subtarea: - -```yaml -Por_Subtarea: - 1_iniciar: - - Marcar subtarea "en progreso" - - Cargar SIMCO correspondiente (CREAR/MODIFICAR/DDL/etc) - - 2_implementar: - - Seguir checklist del SIMCO - - Aplicar principios (doc-primero, anti-dup, validación) - - Generar código/cambios - - 3_validar: - - Ejecutar build - - Ejecutar lint - - Verificar que compila - - 4_registrar: - - Marcar subtarea "completada" - - Notas de lo implementado - - Desviaciónes (si las hubo) - - 5_siguiente: - - Pasar a siguiente subtarea -``` - -### E.3 Usar SIMCO Correspondientes - -```yaml -SIMCO_por_Subtarea: - crear_tabla: "@SIMCO-CREAR + @SIMCO-DDL" - crear_entity: "@SIMCO-CREAR + @SIMCO-BACKEND" - crear_componente: "@SIMCO-CREAR + @SIMCO-FRONTEND" - modificar_algo: "@SIMCO-MODIFICAR + @SIMCO-{dominio}" - validar: "@SIMCO-VALIDAR" -``` - ---- - -## FASE D: DOCUMENTACIÓN (Detalle) - -### D.1 Actualizar Diagramas/Modelos - -```yaml -Diagramas_a_Actualizar: - - tipo: "ERD" - ubicacion: "docs/{epic}/diseño/erd.md" - cambio: "Agregar tabla users" - - - tipo: "Arquitectura" - ubicacion: "docs/00-vision-general/arquitectura.md" - cambio: "Agregar módulo users" # si aplica -``` - -### D.2 Actualizar Specs Técnicas - -```yaml -Specs_a_Actualizar: - - tipo: "API" - ubicacion: "docs/{epic}/especificaciones/api-users.md" - cambio: "Documentar endpoints CRUD" - - - tipo: "BD" - ubicacion: "docs/{epic}/especificaciones/modelo-datos.md" - cambio: "Agregar tabla users" -``` - -### D.3 Crear ADR (si aplica) - -```yaml -ADR_Requerido_Si: - - "Se tomó decisión arquitectónica importante" - - "Se eligió tecnología/librería nueva" - - "Se cambió patrón establecido" - - "Se hizo trade-off significativo" - -Ubicacion: "docs/97-adr/ADR-{NNN}-{titulo}.md" -``` - -### D.4 Actualizar Inventarios - -```yaml -Inventarios_a_Actualizar: - - archivo: "orchestration/inventarios/DATABASE_INVENTORY.yml" - agregar: "Nueva tabla users en schema auth" - - - archivo: "orchestration/inventarios/BACKEND_INVENTORY.yml" - agregar: "Nuevo módulo users" - - - archivo: "orchestration/inventarios/FRONTEND_INVENTORY.yml" - agregar: "Nuevo componente UserList" -``` - -### D.5 Actualizar Trazas - -```yaml -Traza_a_Registrar: - archivo: "orchestration/trazas/TRAZA-TAREAS-{tipo}.md" - entrada: - fecha: "2025-12-08" - hu_id: "HU-001" - descripcion: "CRUD de usuarios" - archivos_creados: [lista] - archivos_modificados: [lista] - agente: "Backend-Agent" - duracion: "2h" - notas: "Sin incidencias" -``` - -### D.6 Vincular HUs Derivadas - -```yaml -HUs_Derivadas: - - id: "DERIVED-HU-001-001" - descripcion: "Endpoint de búsqueda de usuarios" - origen: "HU-001" - detectado_en: "Fase V - Validación" - estado: "pendiente" - prioridad: "P2" -``` - -### D.7 Registrar Lecciones Aprendidas - -```yaml -Lecciones_Aprendidas: - que_funciono_bien: - - "Seguir orden DB → BE → FE evitó retrabajos" - - "Validar contra Swagger antes de FE ahorró tiempo" - - que_se_puede_mejorar: - - "Definir tipos compartidos desde el inicio" - - para_futuras_HUs: - - "En módulos CRUD, siempre incluir paginación desde V1" -``` - -### D.8 Gate Final - -``` -CHECKLIST DOCUMENTACIÓN: -[ ] Diagramas actualizados -[ ] Specs técnicas actualizadas -[ ] ADR creado (si aplica) -[ ] Inventarios actualizados -[ ] Trazas registradas -[ ] HUs derivadas vinculadas -[ ] Lecciones aprendidas registradas - -→ Si TODO marcado: HU COMPLETADA -→ Si algo falta: COMPLETAR ANTES DE CERRAR -``` - ---- - -## TEMPLATE DE REGISTRO RÁPIDO - -```yaml -# Registro CAPVED para HU-{ID} -# ──────────────────────────── - -hu_id: "HU-XXX" -titulo: "Título de la HU" -fecha_inicio: "YYYY-MM-DD" -fecha_fin: "YYYY-MM-DD" - -contexto: - proyecto: "" - modulo: "" - epic: "" - tipo: "feature | fix | refactor | etc" - origen: "plan | descubrimiento | incidencia" - -analisis: - objetos_impactados: N - dependencias: N - riesgos: N - -planeacion: - subtareas: N - agentes_asignados: [] - -validacion: - gaps_detectados: N - scope_creep: "sí | no" - hus_derivadas: N - -ejecucion: - subtareas_completadas: "N/N" - build_status: "✓ | ✗" - lint_status: "✓ | ✗" - -documentacion: - inventarios: "✓ | ✗" - trazas: "✓ | ✗" - adr: "✓ | N/A" - lecciones: "✓ | ✗" - -estado_final: "COMPLETADA | EN_PROGRESO | BLOQUEADA" -``` - ---- - -## REFERENCIAS - -| Documento | Propósito | -|-----------|-----------| -| `PRINCIPIO-CAPVED.md` | Declaración del principio | -| `SIMCO-INICIALIZACION.md` | Protocolo CCA | -| `TEMPLATE-TAREA-CAPVED.md` | Template completo para tracking | -| `TEMPLATE-ANALISIS.md` | Template de análisis | -| `TEMPLATE-PLAN.md` | Template de planeación | -| `TEMPLATE-VALIDACION.md` | Template de validación | - ---- - -**Versión:** 1.0.0 | **Sistema:** SIMCO + CAPVED | **Tipo:** Directiva de Proceso diff --git a/orchestration/_archive/directivas/simco/SIMCO-VALIDAR.md b/orchestration/_archive/directivas/simco/SIMCO-VALIDAR.md deleted file mode 100644 index 40fc98d..0000000 --- a/orchestration/_archive/directivas/simco/SIMCO-VALIDAR.md +++ /dev/null @@ -1,394 +0,0 @@ -# SIMCO: VALIDAR - -**Versión:** 1.0.0 -**Fecha:** 2025-12-08 -**Aplica a:** TODO agente antes de marcar una tarea como completada -**Prioridad:** OBLIGATORIA - NO SE PUEDE OMITIR - ---- - -## RESUMEN EJECUTIVO - -> **NINGUNA tarea se marca como completada sin pasar TODAS las validaciones.** -> **Si una validación falla, la tarea NO está completa.** - ---- - -## PRINCIPIO FUNDAMENTAL - -``` -╔══════════════════════════════════════════════════════════════════════╗ -║ BUILD PASA + LINT PASA + TESTS PASAN = TAREA PUEDE COMPLETARSE ║ -║ CUALQUIER FALLO = TAREA NO COMPLETADA ║ -╚══════════════════════════════════════════════════════════════════════╝ -``` - ---- - -## CHECKLIST UNIVERSAL DE VALIDACIÓN - -``` -VALIDACIONES TÉCNICAS (OBLIGATORIAS) -├── [ ] 1. Build compila sin errores -├── [ ] 2. Lint pasa sin errores críticos -├── [ ] 3. Tests pasan (si existen) -└── [ ] 4. Aplicación inicia correctamente - -VALIDACIONES DE COHERENCIA -├── [ ] 5. Código alineado con documentación -├── [ ] 6. Sin duplicados creados -├── [ ] 7. Convenciones seguidas -└── [ ] 8. Inventarios actualizados - -VALIDACIONES DE INTEGRACIÓN -├── [ ] 9. Coherencia entre capas (DB↔BE↔FE) -└── [ ] 10. APIs funcionan correctamente -``` - ---- - -## VALIDACIONES POR CAPA - -> **Definiciones canónicas disponibles:** -> - @DEF_VAL_BE → `_definitions/validations/VALIDATION-BACKEND.md` -> - @DEF_VAL_FE → `_definitions/validations/VALIDATION-FRONTEND.md` -> - @DEF_VAL_DDL → `_definitions/validations/VALIDATION-DDL.md` -> - @DEF_VAL_DEVOPS → `_definitions/validations/VALIDATION-DEVOPS.md` - -### Database (DDL) - -> **Definición canónica:** @DEF_VAL_DDL - -**Comando obligatorio:** -```bash -# Carga limpia COMPLETA -cd @DB_SCRIPTS -./{RECREATE_CMD} -``` - -**Criterios de éxito:** -``` -✅ Script ejecuta sin errores -✅ Todas las tablas se crean -✅ Todos los índices se crean -✅ Constraints se aplican -✅ Seeds se cargan (si existen) -✅ Integridad referencial OK -``` - -**Verificación post-creación:** -```bash -# Verificar tablas -psql -d {DB_NAME} -c "\dt {schema}.*" - -# Verificar índices -psql -d {DB_NAME} -c "\di {schema}.*" - -# Verificar estructura -psql -d {DB_NAME} -c "\d {schema}.{tabla}" - -# Test de insert -psql -d {DB_NAME} -c "INSERT INTO {schema}.{tabla} (...) VALUES (...);" -``` - -**Si falla:** -``` -🛑 NO marcar como completada -1. Identificar error en DDL -2. Corregir archivo DDL (NO fix manual en BD) -3. Re-ejecutar carga limpia -4. Solo entonces continuar -``` - ---- - -### Backend (NestJS/TypeScript) - -> **Definición canónica:** @DEF_VAL_BE - -**Comandos obligatorios:** -```bash -cd @BACKEND_ROOT - -# 1. Build (OBLIGATORIO) -npm run build -# ✅ Debe completar sin errores - -# 2. Lint (OBLIGATORIO) -npm run lint -# ✅ Debe pasar o corregir errores - -# 3. Tests (si existen) -npm run test -# ✅ Deben pasar - -# 4. Iniciar aplicación -npm run start:dev -# ✅ Debe iniciar sin errores de runtime -``` - -**Criterios de éxito:** -``` -✅ TypeScript compila sin errores -✅ ESLint sin errores (warnings aceptables) -✅ Tests unitarios pasan -✅ Aplicación inicia -✅ Endpoints responden -``` - -**Verificación de endpoints:** -```bash -# Verificar health -curl http://localhost:3000/api/health - -# Verificar endpoint creado -curl http://localhost:3000/api/{recurso} - -# Verificar Swagger -curl http://localhost:3000/api/docs -``` - -**Si falla:** -``` -🛑 NO marcar como completada -1. Revisar errores de TypeScript -2. Corregir código -3. Re-ejecutar build + lint -4. Solo entonces continuar -``` - ---- - -### Frontend (React/TypeScript) - -> **Definición canónica:** @DEF_VAL_FE - -**Comandos obligatorios:** -```bash -cd @FRONTEND_ROOT - -# 1. Build (OBLIGATORIO) -npm run build -# ✅ Debe completar sin errores - -# 2. Lint (OBLIGATORIO) -npm run lint -# ✅ Debe pasar o corregir errores - -# 3. Type check -npm run typecheck # o tsc --noEmit -# ✅ Debe pasar - -# 4. Iniciar aplicación -npm run dev -# ✅ Debe iniciar sin errores -``` - -**Criterios de éxito:** -``` -✅ TypeScript compila sin errores -✅ ESLint sin errores críticos -✅ Aplicación renderiza correctamente -✅ Sin errores en consola del navegador -✅ Componentes funcionan según diseño -``` - -**Si falla:** -``` -🛑 NO marcar como completada -1. Revisar errores de TypeScript/React -2. Corregir código -3. Re-ejecutar build + lint -4. Solo entonces continuar -``` - ---- - -## VALIDACIÓN DE COHERENCIA - -### Coherencia Documentación ↔ Código - -**Verificar:** -```markdown -- [ ] Lo implementado coincide con docs/ -- [ ] No hay features documentadas sin implementar -- [ ] No hay código sin documentación correspondiente -- [ ] ADRs actualizados si hay decisiones nuevas -``` - -### Coherencia Entre Capas (3-Tier) - -**Database ↔ Backend:** -```markdown -- [ ] Entity mapea correctamente a tabla -- [ ] Tipos de columnas coinciden -- [ ] Relaciones (FK) correctas -- [ ] Nombres de campos alineados -``` - -**Backend ↔ Frontend:** -```markdown -- [ ] DTOs coinciden con types del frontend -- [ ] Endpoints documentados en Swagger -- [ ] Respuestas API coinciden con interfaces FE -- [ ] Errores manejados consistentemente -``` - -### Anti-Duplicación - -**Verificar después de crear:** -```bash -# Buscar objetos con nombre similar -grep -rn "{nombre}" @INVENTORY - -# No debe haber entradas duplicadas -# Si hay duplicados → ERROR → Corregir -``` - ---- - -## MATRIZ DE VALIDACIONES POR TIPO DE TAREA - -| Tipo de Tarea | Build | Lint | Tests | Carga Limpia | Coherencia 3-Tier | -|---------------|-------|------|-------|--------------|-------------------| -| Nueva tabla | - | - | - | ✅ OBLIGATORIO | ✅ | -| Nueva entity | ✅ BE | ✅ BE | ✅ BE | - | ✅ | -| Nuevo service | ✅ BE | ✅ BE | ✅ BE | - | - | -| Nuevo controller | ✅ BE | ✅ BE | ✅ BE | - | ✅ | -| Nuevo componente | ✅ FE | ✅ FE | ✅ FE | - | ✅ | -| Nueva página | ✅ FE | ✅ FE | ✅ FE | - | ✅ | -| Bug fix | ✅ Afectado | ✅ Afectado | ✅ Afectado | Si DDL | - | -| Refactor | ✅ TODO | ✅ TODO | ✅ TODO | Si DDL | ✅ | - ---- - -## PROTOCOLO DE FALLA - -### Si Build Falla - -```markdown -## ❌ Build Fallido - -**Error:** -{copiar error completo} - -**Archivo(s) afectado(s):** -- {lista de archivos} - -**Análisis:** -{descripción del problema} - -**Acción:** -1. Corregir {archivo} línea {N} -2. Re-ejecutar build -3. Continuar solo si pasa -``` - -### Si Lint Falla (Errores Críticos) - -```markdown -## ❌ Lint Fallido - -**Errores críticos:** -{lista de errores} - -**Acción:** -1. Corregir cada error -2. Re-ejecutar lint -3. Warnings son aceptables -4. Errores NO son aceptables -``` - -### Si Tests Fallan - -```markdown -## ❌ Tests Fallidos - -**Tests que fallan:** -- {test 1}: {razón} -- {test 2}: {razón} - -**Acción:** -1. Analizar si es error de código o de test -2. Si error de código → Corregir código -3. Si test desactualizado → Actualizar test -4. Re-ejecutar tests -``` - -### Si Carga Limpia Falla - -```markdown -## ❌ Carga Limpia Fallida - -**Error:** -{error de PostgreSQL} - -**Archivo DDL problemático:** -{archivo.sql} - -**Acción:** -1. NO ejecutar fix manual en BD -2. Corregir archivo DDL -3. Re-ejecutar carga limpia completa -4. Repetir hasta éxito -``` - ---- - -## REPORTE DE VALIDACIÓN - -**Incluir en cada entrega:** - -```markdown -## Validaciones Ejecutadas - -### Build -- Backend: ✅ Pasa | ❌ Falla -- Frontend: ✅ Pasa | ❌ Falla | ⏭️ N/A - -### Lint -- Backend: ✅ Pasa | ❌ Falla -- Frontend: ✅ Pasa | ❌ Falla | ⏭️ N/A - -### Tests -- Backend: ✅ Pasa | ❌ Falla | ⏭️ N/A -- Frontend: ✅ Pasa | ❌ Falla | ⏭️ N/A - -### Carga Limpia (DDL) -- Database: ✅ Pasa | ❌ Falla | ⏭️ N/A - -### Coherencia -- Docs ↔ Código: ✅ OK | ❌ Discrepancia -- DB ↔ BE: ✅ OK | ❌ Discrepancia | ⏭️ N/A -- BE ↔ FE: ✅ OK | ❌ Discrepancia | ⏭️ N/A - -### Estado Final -✅ TODAS LAS VALIDACIONES PASAN → Tarea completable -❌ ALGUNA VALIDACIÓN FALLA → Tarea NO completable -``` - ---- - -## ERRORES COMUNES - -| Error | Causa | Solución | -|-------|-------|----------| -| Reportar sin validar | Prisa por entregar | SIEMPRE ejecutar validaciones | -| Fix manual en BD | Carga limpia falla | Corregir DDL, no BD directamente | -| Ignorar warnings de lint | Parecer inofensivos | Revisar si son errores disfrazados | -| Saltar tests | "No hay tiempo" | Tests son OBLIGATORIOS | -| No verificar coherencia | Asumir que está bien | Verificar SIEMPRE entre capas | - ---- - -## REFERENCIAS - -- **Ciclo de vida de tareas:** @CAPVED (PRINCIPIO-CAPVED.md) - Fase V y E -- **Punto de entrada HU:** @TAREA (SIMCO-TAREA.md) -- **Crear archivos:** @CREAR (SIMCO-CREAR.md) -- **Documentar:** @DOCUMENTAR (SIMCO-DOCUMENTAR.md) -- **Directiva completa de validación:** @DIRECTIVAS/PROCESO-VALIDACION.md - ---- - -**Versión:** 1.1.0 | **Sistema:** SIMCO + CAPVED | **Mantenido por:** Tech Lead diff --git a/orchestration/_archive/directivas/triggers/TRIGGER-ANALISIS-DEPENDENCIAS.md b/orchestration/_archive/directivas/triggers/TRIGGER-ANALISIS-DEPENDENCIAS.md deleted file mode 100644 index bfd52f0..0000000 --- a/orchestration/_archive/directivas/triggers/TRIGGER-ANALISIS-DEPENDENCIAS.md +++ /dev/null @@ -1,345 +0,0 @@ -# TRIGGER-ANALISIS-DEPENDENCIAS - -**ID:** TRIGGER-ANALISIS-DEPENDENCIAS -**Version:** 1.0.0 -**Tipo:** Automatico -**Fase CAPVED:** Se activa en Fase A (Analisis) - ---- - -## Proposito - -Analizar automaticamente las dependencias de un archivo antes de modificarlo, -identificando tanto los archivos de los que depende (imports) como los archivos -que dependen de el (dependientes), para evaluar el impacto del cambio y -asegurar que todos los archivos afectados sean considerados en el plan. - ---- - -## Cuando Se Activa - -```yaml -activadores: - palabras_clave: - - "modificar" - - "cambiar" - - "actualizar" - - "refactorizar" - - "eliminar" - - "renombrar" - - "mover" - - tipos_operacion: - - Modificacion de archivo existente - - Eliminacion de archivo - - Renombrado de archivo/clase/funcion - - Cambio de firma de funcion/metodo - - Cambio de estructura de tabla/entity - - ejemplos: - - "Modificar UserEntity para agregar campo email_verified" - - "Cambiar estructura de tabla payments" - - "Refactorizar AuthService" - - "Renombrar componente Dashboard a AdminDashboard" - - "Eliminar funcion deprecada calculateTotal" -``` - ---- - -## Acciones del Trigger - -### Paso 1: Identificar Dependencias (Imports) -```yaml -accion: "Identificar archivos que el archivo modificado importa" -descripcion: "Estos son los archivos de los que DEPENDE el archivo a modificar" - -comandos: - typescript: - - grep -E "^import .* from" {archivo} - - grep -E "require\(" {archivo} - - python: - - grep -E "^from .* import|^import " {archivo} - - sql: - - grep -E "REFERENCES|FOREIGN KEY" {archivo} - -output: - formato: | - ## Dependencias (de los que depende) - | Archivo | Tipo de Dependencia | - |---------|---------------------| - | {ruta} | {import/extends/uses} | -``` - -### Paso 2: Identificar Dependientes -```yaml -accion: "Identificar archivos que importan o usan el archivo a modificar" -descripcion: "Estos son los archivos que DEPENDEN del archivo a modificar" - -comandos: - buscar_imports: - - grep -rn "from.*{nombre_modulo}" apps/ libs/ src/ - - grep -rn "import.*{NombreClase}" apps/ libs/ src/ - - grep -rn "require.*{nombre}" apps/ libs/ src/ - - buscar_uso: - - grep -rn "{NombreClase}" apps/ libs/ src/ --include="*.ts" - - grep -rn "{nombre_funcion}\(" apps/ libs/ src/ - - buscar_referencias_bd: - - grep -rn "REFERENCES.*{tabla}" database/ - - grep -rn "{tabla}\." apps/ libs/ src/ - -output: - formato: | - ## Dependientes (los que dependen de este) - | Archivo | Linea | Tipo de Uso | - |---------|-------|-------------| - | {ruta} | {linea} | {import/call/extends} | -``` - -### Paso 3: Evaluar Impacto -```yaml -accion: "Clasificar el nivel de impacto del cambio" - -clasificacion: - ALTO: - condiciones: - - Mas de 5 dependientes - - Cambio es breaking (firma, estructura, nombre) - - Afecta multiples capas (DB + BE + FE) - - Afecta modulo compartido - acciones: - - Listar TODOS los archivos afectados - - Incluir actualizacion de dependientes en plan - - Considerar migracion gradual - - Verificar tests existentes - - MEDIO: - condiciones: - - 2-5 dependientes - - Cambio es aditivo (nuevo campo, nueva funcion) - - Afecta una capa principalmente - acciones: - - Listar archivos afectados - - Evaluar si dependientes necesitan cambios - - Actualizar tests si existen - - BAJO: - condiciones: - - 0-1 dependientes - - Cambio interno (no afecta API publica) - - Refactoring sin cambio de comportamiento - acciones: - - Proceder con precaucion normal - - Verificar build y lint -``` - -### Paso 4: Generar Plan de Modificacion -```yaml -accion: "Proponer orden de modificacion basado en dependencias" - -reglas_orden: - 1. Modificar dependencias primero (lo que importa) - 2. Modificar archivo principal - 3. Modificar dependientes (los que importan) - 4. Actualizar tests - 5. Validar build completo - -ejemplo: - si_modifica: "UserEntity" - orden_sugerido: - 1. user.entity.ts (archivo principal) - 2. user.service.ts (usa UserEntity) - 3. user.controller.ts (usa UserService) - 4. user.dto.ts (si hay cambios de estructura) - 5. user.spec.ts (tests) - 6. components usando user (frontend) -``` - ---- - -## Formato de Reporte - -```markdown -## Analisis de Dependencias - -### Archivo a Modificar -- Ruta: {ruta_completa} -- Tipo: {entity|service|component|table|...} -- Proyecto: {proyecto} - -### Tipo de Cambio -- Descripcion: {que se va a cambiar} -- Breaking: {SI | NO} -- Afecta API Publica: {SI | NO} - -### Dependencias (de los que depende) -| # | Archivo | Tipo | -|---|---------|------| -| 1 | {ruta} | {import/extends} | - -### Dependientes (los que dependen de este) -| # | Archivo | Linea | Tipo de Uso | Requiere Cambio | -|---|---------|-------|-------------|-----------------| -| 1 | {ruta} | {n} | {import} | {SI/NO/EVALUAR} | - -### Clasificacion de Impacto -**Nivel: {ALTO | MEDIO | BAJO}** - -Razon: {explicacion} - -### Plan de Modificacion Sugerido -1. {paso_1} -2. {paso_2} -... - -### Archivos a Incluir en el Plan -- [ ] {archivo_1} -- [ ] {archivo_2} -... - -### Advertencias -{lista_de_advertencias_si_aplica} -``` - ---- - -## Casos Especiales - -### Cambio en Entity de Base de Datos -```yaml -si_modifica: "*.entity.ts" -buscar_adicional: - - Archivo de migracion relacionado - - DTOs que exponen la entity - - Services que usan la entity - - Controllers que exponen endpoints - - Componentes frontend que muestran datos - -verificar: - - Coherencia con esquema DDL - - Migracion necesaria si es produccion - - Validaciones en DTOs -``` - -### Cambio en Tabla DDL -```yaml -si_modifica: "*.sql (CREATE TABLE, ALTER TABLE)" -buscar_adicional: - - Entity correspondiente en backend - - Otras tablas con FOREIGN KEY - - Vistas que usan la tabla - - Funciones/triggers que referencian - -verificar: - - Script recreate-database.sh actualizado - - Migracion para produccion - - Seed data si aplica -``` - -### Cambio en Servicio Compartido -```yaml -si_modifica: "shared/modules/*.ts" -buscar_adicional: - - Todos los proyectos que importan el modulo - - Proyectos en projects/ que usan shared/ - -alerta: | - ATENCION: Cambio en modulo compartido. - Este cambio puede afectar multiples proyectos. - - Considerar: - 1. Versionado del modulo - 2. Cambio backward-compatible si es posible - 3. Propagacion coordinada a proyectos -``` - ---- - -## Ejemplos de Ejecucion - -### Ejemplo 1: Modificar Entity -``` -Usuario: Modificar UserEntity para agregar campo email_verified - -Sistema: -== TRIGGER-ANALISIS-DEPENDENCIAS ACTIVADO == - -### Archivo a Modificar -- Ruta: apps/api/src/modules/users/entities/user.entity.ts -- Tipo: Entity - -### Dependencias -| Archivo | Tipo | -|---------|------| -| typeorm | import | -| base.entity.ts | extends | - -### Dependientes (12 encontrados) -| Archivo | Linea | Tipo | Requiere Cambio | -|---------|-------|------|-----------------| -| user.service.ts | 5 | import | EVALUAR | -| user.controller.ts | 8 | import | NO | -| auth.service.ts | 12 | import | NO | -| create-user.dto.ts | 3 | reference | SI | -| update-user.dto.ts | 3 | reference | SI | -| user.spec.ts | 10 | import | SI | -... (6 mas) - -### Impacto: ALTO (>5 dependientes, cambio de estructura) - -### Plan Sugerido -1. Actualizar user.entity.ts (agregar campo) -2. Actualizar create-user.dto.ts (agregar campo opcional) -3. Actualizar update-user.dto.ts (agregar campo) -4. Actualizar user.spec.ts (agregar tests) -5. Verificar migracion de BD necesaria -6. Build + lint + test -``` - -### Ejemplo 2: Cambio Bajo Impacto -``` -Usuario: Refactorizar metodo interno en PaymentService - -Sistema: -== TRIGGER-ANALISIS-DEPENDENCIAS ACTIVADO == - -### Archivo a Modificar -- Ruta: apps/api/src/modules/payments/payment.service.ts -- Tipo: Service - -### Dependientes (2 encontrados) -| Archivo | Tipo | Requiere Cambio | -|---------|------|-----------------| -| payment.controller.ts | import | NO (metodo interno) | -| payment.spec.ts | import | EVALUAR (tests) | - -### Impacto: BAJO (metodo interno, no afecta API publica) - -### Plan Sugerido -1. Refactorizar metodo en payment.service.ts -2. Actualizar tests si cambia comportamiento -3. Build + lint -``` - ---- - -## Integracion con Modos - -### En MODE-FULL -- Se ejecuta siempre en Fase A -- Resultado incluido en plan de Fase P - -### En MODE-QUICK -- NO se ejecuta (cambios menores no requieren) -- Si build falla, escalar a MODE-FULL - -### En MODE-ANALYSIS -- Se ejecuta para generar reporte de impacto -- No se incluye plan de ejecucion - ---- - -*TRIGGER-ANALISIS-DEPENDENCIAS v1.0.0 - Sistema SAAD* diff --git a/orchestration/_archive/directivas/triggers/TRIGGER-ANTI-DUPLICACION.md b/orchestration/_archive/directivas/triggers/TRIGGER-ANTI-DUPLICACION.md deleted file mode 100644 index b04b942..0000000 --- a/orchestration/_archive/directivas/triggers/TRIGGER-ANTI-DUPLICACION.md +++ /dev/null @@ -1,282 +0,0 @@ -# TRIGGER-ANTI-DUPLICACION - -**ID:** TRIGGER-ANTI-DUPLICACION -**Version:** 1.0.0 -**Tipo:** Automatico -**Fase CAPVED:** Se activa en Fase A (Analisis) - ---- - -## Proposito - -Prevenir la creacion de objetos duplicados verificando automaticamente el -catalogo global y los inventarios del proyecto antes de crear cualquier -archivo, componente, servicio, entidad o tabla nueva. - ---- - -## Cuando Se Activa - -```yaml -activadores: - palabras_clave: - - "crear" - - "nuevo" - - "agregar" - - "implementar" - - "anadir" - - "generar" - - tipos_objeto: - - tabla (DDL) - - entity - - service - - controller - - componente - - hook - - modulo - - funcionalidad - - ejemplos: - - "Crear nueva tabla de usuarios" - - "Agregar entidad PaymentMethod" - - "Implementar servicio de notificaciones" - - "Nuevo componente de dashboard" -``` - ---- - -## Acciones del Trigger - -### Paso 1: Verificar Catalogo Global -```yaml -accion: "Buscar en catalogo de funcionalidades reutilizables" -comando: | - grep -i "{funcionalidad}" shared/catalog/CATALOG-INDEX.yml - -catalogo_contiene: - - auth (autenticacion y autorizacion) - - session-management (gestion de sesiones) - - rate-limiting (limitacion de tasa) - - notifications (notificaciones email/push) - - multi-tenancy (soporte multi-tenant) - - feature-flags (flags dinamicos) - - websocket (comunicacion tiempo real) - - payments (integracion pagos) - - audit-logs (auditoria) - - portales (templates de portales) - - template-saas (template SaaS completo) - -si_existe_en_catalogo: - accion: "DETENER creacion" - mensaje: | - ATENCION: Esta funcionalidad ya existe en el catalogo global. - - Ubicacion: shared/catalog/{funcionalidad}/ - Documentacion: shared/catalog/{funcionalidad}/README.md - - Recomendacion: Usar SIMCO-REUTILIZAR.md para integrar - el modulo existente en lugar de crear uno nuevo. - - Si necesita modificaciones, considerar: - 1. Extender el modulo existente - 2. Contribuir mejoras al catalogo - - Para continuar de todos modos, confirmar explicitamente. -``` - -### Paso 2: Verificar Inventario del Proyecto -```yaml -accion: "Buscar en inventarios del proyecto actual" -comandos: - - grep -i "{nombre}" orchestration/inventarios/MASTER_INVENTORY.yml - - grep -i "{nombre}" orchestration/inventarios/DATABASE_INVENTORY.yml - - grep -i "{nombre}" orchestration/inventarios/BACKEND_INVENTORY.yml - - grep -i "{nombre}" orchestration/inventarios/FRONTEND_INVENTORY.yml - -si_existe_en_inventario: - accion: "DETENER creacion" - mensaje: | - ATENCION: Ya existe un objeto similar en este proyecto. - - Nombre: {nombre_existente} - Tipo: {tipo} - Ubicacion: {ruta} - - Opciones: - 1. Reutilizar el existente - 2. Extender el existente - 3. Renombrar el nuevo si es diferente - - Para continuar, clarificar la diferencia. -``` - -### Paso 3: Buscar Archivos Similares -```yaml -accion: "Buscar archivos con nombre similar en el codigo" -comandos: - - find apps/ libs/ -name "*{nombre}*" -type f - - find src/ -name "*{nombre}*" -type f - - grep -rn "class {Nombre}" apps/ libs/ src/ - - grep -rn "interface {Nombre}" apps/ libs/ src/ - - grep -rn "CREATE TABLE.*{nombre}" database/ - -si_encuentra_similar: - accion: "ALERTAR y preguntar" - mensaje: | - ATENCION: Se encontraron archivos similares: - - {lista_archivos} - - Por favor confirmar: - 1. Es el mismo objeto? -> Usar el existente - 2. Es diferente? -> Explicar la diferencia - 3. Es un duplicado a consolidar? -> Usar @DELETE-SAFE primero -``` - -### Paso 4: Evaluar Resultado -```yaml -matriz_decision: - existe_en_catalogo: - accion: "REUTILIZAR del catalogo" - simco: "SIMCO-REUTILIZAR.md" - - no_encontrado: - accion: "PROCEDER a crear" - simco: "SIMCO-CREAR.md" - - existe_identico: - accion: "DETENER" - mensaje: "Ya existe, no crear duplicado" - - existe_similar: - accion: "PREGUNTAR" - mensaje: "Clarificar diferencia antes de continuar" -``` - ---- - -## Checklist Rapido Anti-Duplicacion - -Antes de crear cualquier objeto nuevo, verificar: - -```markdown -[ ] Busque funcionalidad en shared/catalog/CATALOG-INDEX.yml -[ ] Busque "{nombre}" en orchestration/inventarios/ -[ ] Busque archivos con find en apps/ y src/ -[ ] Busque definiciones con grep (class, interface, CREATE TABLE) -[ ] Confirme que NO existe en catalogo NI en proyecto -[ ] Si existe en catalogo, use SIMCO-REUTILIZAR.md -[ ] Si existe similar, pregunte que hacer antes de continuar -``` - ---- - -## Formato de Reporte - -Cuando se activa este trigger, generar reporte: - -```markdown -## Verificacion Anti-Duplicacion - -### Objeto a Crear -- Nombre: {nombre} -- Tipo: {tabla|entity|service|component|...} -- Proyecto: {proyecto} - -### Resultado Catalogo Global -- Estado: {ENCONTRADO | NO_ENCONTRADO} -- Detalles: {ubicacion si encontrado} - -### Resultado Inventario Proyecto -- Estado: {ENCONTRADO | NO_ENCONTRADO} -- Detalles: {nombre y ubicacion si encontrado} - -### Resultado Busqueda Codigo -- Estado: {ENCONTRADO | NO_ENCONTRADO} -- Archivos similares: {lista si encontrados} - -### Decision -- [ ] PROCEDER: No se encontraron duplicados -- [ ] REUTILIZAR: Usar modulo del catalogo -- [ ] DETENER: Ya existe en proyecto -- [ ] CONSULTAR: Existe similar, clarificar -``` - ---- - -## Excepciones - -### Cuando NO aplicar este trigger -```yaml -excepciones: - - Archivos de configuracion (no son objetos reutilizables) - - Tests (cada modulo tiene sus propios tests) - - Documentacion (puede haber docs similares) - - Migraciones de BD (tienen timestamp unico) -``` - ---- - -## Integracion con SIMCO - -### Si se encuentra en catalogo -```yaml -siguiente_paso: "Leer SIMCO-REUTILIZAR.md" -acciones: - 1. Leer documentacion del modulo en catalogo - 2. Verificar compatibilidad con proyecto - 3. Seguir instrucciones de integracion - 4. Registrar uso en inventario -``` - -### Si no se encuentra -```yaml -siguiente_paso: "Leer SIMCO-CREAR.md" -acciones: - 1. Proceder con creacion normal - 2. Seguir principio Doc-Primero - 3. Registrar en inventario al crear - 4. Evaluar si debe agregarse al catalogo -``` - ---- - -## Ejemplo de Ejecucion - -``` -Usuario: Crear servicio de autenticacion para erp-construccion - -Sistema: -== TRIGGER-ANTI-DUPLICACION ACTIVADO == - -Paso 1: Verificando catalogo global... - Buscando: "auth" en shared/catalog/CATALOG-INDEX.yml - ENCONTRADO: shared/catalog/auth/ - -Paso 2: Verificando inventario... - (No aplica - se encontro en catalogo) - -Paso 3: Busqueda codigo... - (No aplica - se encontro en catalogo) - -== RESULTADO == -DETENIDO: Funcionalidad existe en catalogo global. - -Ubicacion: shared/catalog/auth/ -Contenido: - - NestJS + JWT + Passport - - Guards, strategies, decorators - - Documentacion completa - -Recomendacion: - Usar SIMCO-REUTILIZAR.md para integrar el modulo - de autenticacion del catalogo. - - Comando sugerido: - @CREATE-SAFE Integrar modulo auth del catalogo en erp-construccion -``` - ---- - -*TRIGGER-ANTI-DUPLICACION v1.0.0 - Sistema SAAD* diff --git a/orchestration/_archive/directivas/triggers/TRIGGER-CIERRE-TAREA-OBLIGATORIO.md b/orchestration/_archive/directivas/triggers/TRIGGER-CIERRE-TAREA-OBLIGATORIO.md deleted file mode 100644 index 8fad979..0000000 --- a/orchestration/_archive/directivas/triggers/TRIGGER-CIERRE-TAREA-OBLIGATORIO.md +++ /dev/null @@ -1,267 +0,0 @@ -# TRIGGER: CIERRE DE TAREA OBLIGATORIO - -**Versión:** 1.0.0 -**Fecha:** 2026-01-16 -**Sistema:** SIMCO v4.0.0 -**Alias:** @TRIGGER_CIERRE - ---- - -## RESUMEN EJECUTIVO - -Este trigger OBLIGA la ejecución del checklist post-tarea (@DEF_CHK_POST) antes de que cualquier tarea pueda ser marcada como completada. - -**PRINCIPIO:** "Una tarea no está completada hasta que su checklist de cierre esté 100% verificado." - ---- - -## CONDICIONES DE ACTIVACIÓN - -```yaml -activar_cuando: - - Agente intenta marcar tarea como "completada" - - Agente dice "tarea finalizada" o variantes - - Agente termina la última subtarea del plan - - Agente declara "Done" o "DONE" - - Agente reporta que terminó el trabajo - -palabras_clave_trigger: - - "completada" - - "finalizada" - - "terminada" - - "Done" - - "DONE" - - "tarea cerrada" - - "trabajo terminado" - - "implementación completa" -``` - ---- - -## ACCIÓN REQUERIDA - -### Secuencia Obligatoria - -``` -AGENTE DECLARA TAREA TERMINADA - │ - ▼ -┌─────────────────────────────────────┐ -│ 1. DETENER │ -│ No marcar como completada aún │ -└─────────────────┬───────────────────┘ - │ - ▼ -┌─────────────────────────────────────┐ -│ 2. CARGAR @DEF_CHK_POST │ -│ CHECKLIST-POST-TASK.md │ -└─────────────────┬───────────────────┘ - │ - ▼ -┌─────────────────────────────────────┐ -│ 3. EJECUTAR CHECKLIST │ -│ - Gobernanza (BLOQUEANTE) │ -│ - Validaciones técnicas │ -│ - Coherencia entre capas │ -│ - Inventarios │ -│ - Trazas │ -│ - Propagación │ -└─────────────────┬───────────────────┘ - │ - ▼ - ┌───────────────┐ - │ ¿TODOS PASAN? │ - └───────┬───────┘ - / \ - Sí No - │ │ - ▼ ▼ -┌──────────────┐ ┌──────────────────────┐ -│ 4. MARCAR │ │ 4. MANTENER EN │ -│ COMPLETADA │ │ PROGRESO │ -└──────────────┘ │ │ - │ - Documentar items │ - │ faltantes │ - │ - Completar antes │ - │ de cerrar │ - └──────────────────────┘ -``` - ---- - -## CHECKLIST RÁPIDO DE CIERRE - -```markdown -## Verificación Pre-Cierre (@DEF_CHK_POST) - -### 0. Gobernanza (BLOQUEANTE - SI FALLA, NO CONTINUAR) -[ ] Carpeta de tarea existe: orchestration/tareas/TASK-{ID}/ -[ ] METADATA.yml completo con fases C, E, D -[ ] _INDEX.yml de tareas actualizado - -### 1. Validaciones Técnicas -[ ] Build pasa (backend y/o frontend según aplique) -[ ] Lint pasa -[ ] Tests pasan (si existen) - -### 2. Coherencia Entre Capas -[ ] DDL ↔ Backend coherente (o excepciones documentadas) -[ ] Backend ↔ Frontend coherente (si aplica) - -### 3. Inventarios Actualizados -[ ] DATABASE_INVENTORY.yml (si cambió BD) -[ ] BACKEND_INVENTORY.yml (si cambió BE) -[ ] FRONTEND_INVENTORY.yml (si cambió FE) -[ ] MASTER_INVENTORY.yml (siempre) - -### 4. Trazas Actualizadas -[ ] Traza de tarea correspondiente actualizada -[ ] PROXIMA-ACCION.md actualizado - -### 5. Propagación Evaluada -[ ] ¿Cambio debe propagarse a otros proyectos? (evaluar) -[ ] Si aplica: propagación ejecutada o documentada como pendiente -``` - ---- - -## BLOQUEO - -### SI el checklist NO pasa: - -```yaml -accion: "BLOQUEAR cierre de tarea" -estado: "EN PROGRESO" -mensaje: | - Tarea NO puede ser marcada como completada. - Items faltantes del checklist: - - [listar items que fallaron] - - Acción requerida: - - Completar items faltantes - - Re-ejecutar checklist - - Solo entonces marcar como completada - -reintentar: "Después de completar items faltantes" -``` - -### Items BLOQUEANTES (no negociables): - -```yaml -bloqueantes_absolutos: - - Gobernanza (carpeta + METADATA + _INDEX) - - Build que falla - - Tests que fallan - -advertencias_serias: - - Inventarios desactualizados - - Trazas desactualizadas - - Coherencia no verificada - -advertencias_menores: - - Propagación no evaluada (si proyecto aislado) -``` - ---- - -## INTEGRACIÓN CON OTROS TRIGGERS - -```yaml -secuencia_de_triggers: - 1: "Agente ejecuta trabajo" - 2: "Agente intenta cerrar tarea" - 3: "→ TRIGGER-CIERRE-TAREA-OBLIGATORIO se activa" - 4: "→ Carga @DEF_CHK_POST" - 5: "→ TRIGGER-INVENTARIOS-SINCRONIZADOS verifica inventarios" - 6: "→ TRIGGER-COHERENCIA-CAPAS verifica coherencia" - 7: "→ TRIGGER-DOCUMENTACION-OBLIGATORIA verifica gobernanza" - 8: "Si todo pasa: tarea = COMPLETADA" - 9: "Si algo falla: tarea = EN PROGRESO" - -dependencias: - - "@TRIGGER_INVENTARIOS" - - "@TRIGGER_COHERENCIA" - - "@TRIGGER_DOC" -``` - ---- - -## MENSAJES ESTÁNDAR - -### Al detectar intento de cierre: - -``` -⚠️ TRIGGER-CIERRE-TAREA-OBLIGATORIO activado - -Antes de marcar la tarea como completada, debo ejecutar el checklist post-tarea. - -Ejecutando @DEF_CHK_POST... -``` - -### Si todo pasa: - -``` -✅ Checklist post-tarea completado exitosamente - -Verificaciones: -- [✓] Gobernanza -- [✓] Validaciones técnicas -- [✓] Coherencia entre capas -- [✓] Inventarios sincronizados -- [✓] Trazas actualizadas -- [✓] Propagación evaluada - -TAREA MARCADA COMO COMPLETADA -``` - -### Si algo falla: - -``` -❌ Checklist post-tarea NO completado - -Items faltantes: -- [ ] {item que falló} -- [ ] {otro item que falló} - -Acción: Completar items faltantes antes de cerrar. -Estado: EN PROGRESO (no completada) -``` - ---- - -## EXCEPCIONES - -```yaml -excepciones_permitidas: - tareas_triviales: - - Corrección de typos - - Actualización de comentarios - - Cambios cosméticos - checklist_reducido: - - Solo Gobernanza - - Solo Validación build - - investigación_pura: - - Análisis sin cambios de código - - Spikes exploratorios - checklist_reducido: - - Solo documentación de hallazgos - -nota: "Incluso excepciones DEBEN documentar en trazas" -``` - ---- - -## REFERENCIAS - -| Alias | Archivo | -|-------|---------| -| @DEF_CHK_POST | orchestration/_definitions/checklists/CHECKLIST-POST-TASK.md | -| @TRIGGER_INVENTARIOS | orchestration/directivas/triggers/TRIGGER-INVENTARIOS-SINCRONIZADOS.md | -| @TRIGGER_COHERENCIA | orchestration/directivas/triggers/TRIGGER-COHERENCIA-CAPAS.md | -| @TRIGGER_DOC | orchestration/directivas/triggers/TRIGGER-DOCUMENTACION-OBLIGATORIA.md | -| @CAPVED | orchestration/directivas/principios/PRINCIPIO-CAPVED.md | - ---- - -**Versión:** 1.0.0 | **Sistema:** SIMCO v4.0.0 | **Tipo:** Trigger de Cierre Obligatorio diff --git a/orchestration/_archive/directivas/triggers/TRIGGER-COMMIT-PUSH-OBLIGATORIO.md b/orchestration/_archive/directivas/triggers/TRIGGER-COMMIT-PUSH-OBLIGATORIO.md deleted file mode 100644 index f8e54b7..0000000 --- a/orchestration/_archive/directivas/triggers/TRIGGER-COMMIT-PUSH-OBLIGATORIO.md +++ /dev/null @@ -1,151 +0,0 @@ -# TRIGGER: Commit y Push Obligatorio - -**Version:** 1.0.0 -**Fecha:** 2026-01-16 -**Tipo:** AUTOMATICO -**Prioridad:** CRITICA - ---- - -## ACTIVACION - -Este trigger se activa AUTOMATICAMENTE cuando: - -1. Se completa una tarea que creo o modifico archivos -2. Se marca un todo como "completed" -3. Se reporta al usuario que una tarea esta finalizada -4. Se cambia de contexto a otra tarea -5. Antes de finalizar una sesion de trabajo - ---- - -## ACCION OBLIGATORIA - -``` -╔══════════════════════════════════════════════════════════════════════════╗ -║ ║ -║ ANTES DE REPORTAR TAREA COMPLETADA: ║ -║ ║ -║ 1. Ejecutar: git status ║ -║ - Si hay cambios pendientes -> continuar ║ -║ - Si esta limpio -> verificar que push se hizo ║ -║ ║ -║ 2. Si hay cambios: ║ -║ git add . ║ -║ git commit -m "[TAREA-ID] tipo: descripcion" ║ -║ git push origin main ║ -║ ║ -║ 3. Si hay SUBMODULES modificados: ║ -║ - Commitear y push en CADA submodule primero ║ -║ - Luego actualizar workspace principal ║ -║ ║ -║ 4. Verificar sincronizacion: ║ -║ git log origin/main..HEAD --oneline ║ -║ - Debe estar VACIO (sin commits pendientes de push) ║ -║ ║ -╚══════════════════════════════════════════════════════════════════════════╝ -``` - ---- - -## SECUENCIA WORKSPACE-V2 - -El workspace-v2 usa submodules. Secuencia obligatoria: - -```bash -# PASO 1: Identificar submodules modificados -cd /home/isem/workspace-v2 -git status - -# PASO 2: Para CADA submodule con cambios -cd projects/{submodule} -git add . -git commit -m "[{submodule}] tipo: descripcion" -git push origin main -cd ../.. - -# PASO 3: Actualizar workspace principal -git add . -git commit -m "[WORKSPACE] chore: descripcion de cambios" -git push origin main - -# PASO 4: Verificar TODO sincronizado -git status # Debe mostrar "clean" -git submodule foreach 'git status' # Todos deben estar "clean" -``` - ---- - -## ERRORES A EVITAR - -| Error | Consecuencia | Prevencion | -|-------|--------------|------------| -| No hacer push | Archivos solo en local | Siempre push despues de commit | -| Olvidar submodules | Referencias desincronizadas | Commitear submodules primero | -| Reportar sin verificar | Usuario cree que esta hecho | Verificar git status antes | -| Commitear sin push | Cambios no en remoto | Push inmediato tras commit | - ---- - -## VERIFICACION RAPIDA - -```bash -# Comando unico para verificar todo sincronizado -git status && git log origin/main..HEAD --oneline - -# Salida esperada: -# On branch main -# Your branch is up to date with 'origin/main'. -# nothing to commit, working tree clean -# (sin output del log = todo pusheado) -``` - ---- - -## INTEGRACION CON CAPVED - -Este trigger se ejecuta en: - -- **Fase E (Ejecucion):** Commit atomico por cada cambio logico -- **Fase D (Documentacion):** Commit final con documentacion -- **Post-Tarea:** Push OBLIGATORIO antes de reportar completado - -```yaml -fase_D_documentacion: - ultimo_paso: "Commit + Push de todos los cambios" - verificacion: "git status clean + git log empty" - reportar_solo_si: "Todo sincronizado con remoto" -``` - ---- - -## MENSAJE AL AGENTE - -``` -╔══════════════════════════════════════════════════════════════════════════╗ -║ ║ -║ RECUERDA: Una tarea NO esta completa hasta que: ║ -║ ║ -║ 1. Todos los archivos estan GUARDADOS en disco ║ -║ 2. Todos los cambios estan COMMITEADOS ║ -║ 3. Todos los commits estan PUSHEADOS al remoto ║ -║ 4. git status muestra "working tree clean" ║ -║ 5. git log origin/main..HEAD esta VACIO ║ -║ ║ -║ SIN PUSH = TRABAJO PERDIDO POTENCIAL ║ -║ ║ -╚══════════════════════════════════════════════════════════════════════════╝ -``` - ---- - -## REFERENCIAS - -- SIMCO-GIT.md - Directiva principal de control de versiones -- PRINCIPIO-CAPVED.md - Ciclo de vida de tareas -- SIMCO-TAREA.md - Punto de entrada de tareas - ---- - -**Sistema:** SIMCO v4.0.0 -**Mantenido por:** Workspace Admin diff --git a/orchestration/_archive/directivas/triggers/TRIGGER-FETCH-OBLIGATORIO.md b/orchestration/_archive/directivas/triggers/TRIGGER-FETCH-OBLIGATORIO.md deleted file mode 100644 index d960cd9..0000000 --- a/orchestration/_archive/directivas/triggers/TRIGGER-FETCH-OBLIGATORIO.md +++ /dev/null @@ -1,178 +0,0 @@ -# TRIGGER: Fetch Obligatorio Antes de Operar - -**Version:** 1.0.0 -**Fecha:** 2026-01-16 -**Tipo:** AUTOMATICO -**Prioridad:** CRITICA -**Incidente de Origen:** INC-2026-01-16-001 - ---- - -## ACTIVACION - -Este trigger se activa AUTOMATICAMENTE cuando: - -1. Se inicia una sesion de trabajo en el workspace -2. Se va a verificar el estado de git (git status) -3. Se va a realizar cualquier operacion git (commit, push, pull) -4. Se retoma trabajo despues de una pausa -5. Se cambia de contexto entre proyectos/submodulos - ---- - -## ACCION OBLIGATORIA - -``` -╔══════════════════════════════════════════════════════════════════════════╗ -║ ║ -║ ANTES DE VERIFICAR ESTADO O REALIZAR OPERACIONES GIT: ║ -║ ║ -║ 1. Ejecutar: git fetch origin ║ -║ → Obtiene el estado actual del repositorio remoto ║ -║ ║ -║ 2. Verificar: git log HEAD..origin/main --oneline ║ -║ → Si hay output = HAY COMMITS REMOTOS QUE NO TIENES ║ -║ → Si esta vacio = Estas sincronizado ║ -║ ║ -║ 3. Si hay commits remotos: ║ -║ git pull --no-recurse-submodules ║ -║ → Sincroniza tu local con el remoto ║ -║ ║ -║ 4. AHORA SI verificar estado: ║ -║ git status ║ -║ ║ -║ MOTIVO: Otro agente pudo haber hecho cambios en otra sesion. ║ -║ Sin FETCH, reportaras estado incompleto. ║ -║ ║ -╚══════════════════════════════════════════════════════════════════════════╝ -``` - ---- - -## SECUENCIA COMPLETA - -```bash -# PASO 1: Fetch del remoto -git fetch origin - -# PASO 2: Verificar si hay commits remotos no sincronizados -REMOTE_COMMITS=$(git log HEAD..origin/main --oneline) - -# PASO 3: Si hay commits remotos, sincronizar -if [ -n "$REMOTE_COMMITS" ]; then - echo "Commits remotos detectados:" - echo "$REMOTE_COMMITS" - git pull --no-recurse-submodules -fi - -# PASO 4: Ahora verificar estado local -git status -``` - ---- - -## PARA WORKSPACE CON SUBMODULOS - -En workspace-v2 con multiples niveles de submodulos: - -```bash -# NIVEL 0: Workspace principal -cd /home/isem/workspace-v2 -git fetch origin -git log HEAD..origin/main --oneline -# Si hay output: git pull --no-recurse-submodules -git status - -# NIVEL 1: Proyectos (si vas a trabajar en uno) -cd projects/{proyecto} -git fetch origin -git log HEAD..origin/main --oneline -# Si hay output: git pull --no-recurse-submodules -git status - -# NIVEL 2: Subrepositorios (si vas a trabajar en uno) -cd {componente} # backend, database, frontend -git fetch origin -git log HEAD..origin/main --oneline -# Si hay output: git pull --no-recurse-submodules -git status -``` - ---- - -## ERRORES A EVITAR - -| Error | Consecuencia | Prevencion | -|-------|--------------|------------| -| Solo hacer git status | No detectar commits remotos | SIEMPRE fetch primero | -| Reportar "clean" sin fetch | Usuario confundido | Seguir secuencia completa | -| Asumir que no hay cambios | Desincronizacion | Verificar con log HEAD..origin | -| Olvidar en submodulos | Referencias inconsistentes | Fetch en cada nivel | - ---- - -## INCIDENTE DE ORIGEN - -### INC-2026-01-16-001 - -**Descripcion:** Un agente reporto "working tree clean" cuando habia un commit -remoto (c027da53) que no habia sido detectado. - -**Causa Raiz:** No se ejecuto `git fetch` antes de verificar estado con `git status`. - -**Impacto:** Usuario confundido sobre el estado real del repositorio. - -**Resolucion:** -- Creado este trigger obligatorio -- Actualizado SIMCO-GIT.md v1.2.0 con regla critica -- Actualizado SIMCO-SUBMODULOS.md v1.1.0 con secuencia obligatoria -- Documentado en TRAZA-GIT-OPERATIONS.md - ---- - -## VERIFICACION RAPIDA - -```bash -# Comando unico para verificar sincronizacion completa -git fetch origin && git log HEAD..origin/main --oneline && git status - -# Salida esperada si todo sincronizado: -# (sin output del log) -# On branch main -# Your branch is up to date with 'origin/main'. -# nothing to commit, working tree clean -``` - ---- - -## INTEGRACION CON CAPVED - -Este trigger se ejecuta en: - -- **Pre-Tarea:** SIEMPRE antes de iniciar cualquier tarea -- **Pre-Commit:** Antes de hacer commit (verificar no hay conflictos) -- **Pre-Push:** Antes de push (verificar no hay rechazos pendientes) -- **Post-Pausa:** Al retomar trabajo despues de interrupcion - -```yaml -pre_tarea: - primer_paso: "git fetch origin" - verificar: "git log HEAD..origin/main" - sincronizar_si_necesario: "git pull --no-recurse-submodules" - luego: "Continuar con la tarea" -``` - ---- - -## REFERENCIAS - -- `orchestration/directivas/simco/SIMCO-GIT.md` - Directiva principal git (v1.2.0) -- `orchestration/directivas/simco/SIMCO-SUBMODULOS.md` - Protocolo submodulos (v1.1.0) -- `orchestration/SUBMODULES-POLICY.yml` - Politicas de sincronizacion (v1.1.0) -- `orchestration/trazas/TRAZA-GIT-OPERATIONS.md` - Registro de operaciones -- `orchestration/directivas/triggers/TRIGGER-COMMIT-PUSH-OBLIGATORIO.md` - Trigger complementario - ---- - -**Sistema:** SIMCO v4.0.0 -**Mantenido por:** Workspace Admin diff --git a/orchestration/_archive/directivas/triggers/TRIGGER-INICIO-TAREA.md b/orchestration/_archive/directivas/triggers/TRIGGER-INICIO-TAREA.md deleted file mode 100644 index d8a44c1..0000000 --- a/orchestration/_archive/directivas/triggers/TRIGGER-INICIO-TAREA.md +++ /dev/null @@ -1,160 +0,0 @@ -# ═══════════════════════════════════════════════════════════════════════════════ -# TRIGGER-INICIO-TAREA -# ═══════════════════════════════════════════════════════════════════════════════ -# -# Version: 1.0.0 -# Creado: 2026-01-16 -# Origen: Auditoría post-tarea TASK-2026-01-16-004 -# Proposito: Garantizar creación de carpeta de tarea ANTES de ejecutar código -# -# ═══════════════════════════════════════════════════════════════════════════════ - -## CONDICION DE ACTIVACION - -Este trigger se activa **AUTOMATICAMENTE** cuando: - -1. Se recibe una solicitud que implica **modificar código** -2. Se recibe una solicitud que implica **crear archivos nuevos** -3. Se usa `@FULL` o `@CREATE-SAFE` o `@MODIFY-SAFE` -4. El primer item de TodoWrite incluye una tarea de implementación - -**EXCEPCION:** No aplica para: -- Modo `@QUICK` en fixes menores (typos, config simple) -- Modo `@ANALYSIS` (solo investigación) -- Tareas puramente de lectura/exploración - ---- - -## ACCION OBLIGATORIA - -### Paso 1: Generar ID de Tarea - -``` -TASK-{YYYY-MM-DD}-{NNN} -``` - -Donde: -- `YYYY-MM-DD`: Fecha actual -- `NNN`: Siguiente secuencial del día (consultar `_INDEX.yml`) - -### Paso 2: Crear Estructura de Carpeta - -```bash -# Ruta base -orchestration/tareas/TASK-{ID}/ - -# Archivos mínimos obligatorios -├── METADATA.yml # Copiar de _templates/TASK-TEMPLATE/ -├── 01-CONTEXTO.md # Llenar con clasificación inicial -└── (otros según avance) -``` - -### Paso 3: Registrar en Inventario - -Agregar entrada en `tareas_activas` de `_INDEX.yml`: - -```yaml -tareas_activas: - - task_id: "TASK-2026-01-XX-NNN" - titulo: "Título descriptivo" - agente: "PERFIL-AGENTE" - estado: "en_progreso" - fase: "C" # Inicia en Contexto - proyecto: "nombre-proyecto" -``` - -### Paso 4: Incluir en TodoWrite - -El **PRIMER item** de TodoWrite debe ser: - -``` -- Crear carpeta de tarea TASK-{ID} en orchestration/tareas/ -``` - -O si ya existe: - -``` -- Documentar contexto en TASK-{ID}/01-CONTEXTO.md -``` - ---- - -## CHECKPOINT DE VALIDACION - -**ANTES de ejecutar cualquier código (fase E):** - -``` -[ ] ¿Existe carpeta orchestration/tareas/TASK-{ID}/? -[ ] ¿Existe METADATA.yml con información básica? -[ ] ¿Se registró en _INDEX.yml como tarea activa? -[ ] ¿TodoWrite incluye la tarea de documentación? -``` - -**SI algún checkbox falla:** BLOQUEAR ejecución hasta completar. - ---- - -## INTEGRACION CON TODOWRITE - -Cuando se use TodoWrite para planificar una tarea de código, incluir SIEMPRE: - -```typescript -// Ejemplo de TodoWrite correcto -[ - { content: "Crear carpeta TASK-2026-01-16-004", status: "pending" }, - { content: "Documentar contexto y clasificación", status: "pending" }, - { content: "Analizar dependencias", status: "pending" }, - // ... tareas técnicas ... - { content: "Actualizar _INDEX.yml al completar", status: "pending" } -] -``` - ---- - -## REFERENCIAS - -- `@TAREAS` - orchestration/tareas/ -- `@NUEVA-TAREA` - orchestration/tareas/_templates/TASK-TEMPLATE/ -- `@TRIGGER-DOC` - TRIGGER-DOCUMENTACION-OBLIGATORIA.md -- `@MAPA-DOC` - orchestration/MAPA-DOCUMENTACION.yml - ---- - -## CASO DE ESTUDIO: TASK-2026-01-16-004 - -Esta directiva nace del análisis post-mortem de la tarea: - -**"Integración de Servicios de API en Trading Platform Frontend"** - -### Problema Detectado -- La tarea se ejecutó correctamente (build pasa, código funcional) -- PERO no se creó carpeta de tarea antes de ejecutar -- No se documentaron fases C, A, P, V formalmente -- No se actualizó _INDEX.yml hasta auditoría posterior - -### Causa Raíz -1. No existía trigger bloqueante para creación de carpeta -2. TodoWrite no recordaba incluir checkpoint de gobernanza -3. Las reglas estaban en CLAUDE.md pero sin enforcement automático - -### Solución Implementada -1. Crear este trigger (TRIGGER-INICIO-TAREA) -2. Documentación retroactiva de la tarea -3. Actualización de _INDEX.yml -4. Propuesta de mejora a flujo de TodoWrite - ---- - -## METRICAS DE CUMPLIMIENTO - -| Métrica | Objetivo | Medición | -|---------|----------|----------| -| Tareas con carpeta antes de E | 100% | `tareas_con_carpeta / total_tareas` | -| Fases documentadas por tarea | >= 3 | `promedio(fases_doc)` | -| _INDEX.yml actualizado | 100% | `tareas_en_index / total_tareas` | - ---- - -# ═══════════════════════════════════════════════════════════════════════════════ -# FIN DEL TRIGGER -# ═══════════════════════════════════════════════════════════════════════════════ diff --git a/orchestration/_archive/directivas/triggers/TRIGGER-INVENTARIOS-SINCRONIZADOS.md b/orchestration/_archive/directivas/triggers/TRIGGER-INVENTARIOS-SINCRONIZADOS.md deleted file mode 100644 index 7735a9b..0000000 --- a/orchestration/_archive/directivas/triggers/TRIGGER-INVENTARIOS-SINCRONIZADOS.md +++ /dev/null @@ -1,281 +0,0 @@ -# TRIGGER: INVENTARIOS SINCRONIZADOS - -**Versión:** 1.0.0 -**Fecha:** 2026-01-16 -**Sistema:** SIMCO v4.0.0 -**Alias:** @TRIGGER_INVENTARIOS - ---- - -## RESUMEN EJECUTIVO - -Este trigger OBLIGA a mantener los inventarios sincronizados con el código real. Se activa al completar cualquier tarea que modifique código o estructura. - -**PRINCIPIO:** "Los inventarios son la fuente de verdad. Si no está en el inventario, no existe oficialmente." - ---- - -## CONDICIONES DE ACTIVACIÓN - -```yaml -activar_cuando: - - Se completa cualquier tarea con cambios de código - - Se crea/modifica/elimina: tabla, entity, service, módulo, componente - - Se ejecuta auditoría de proyecto - - Han pasado más de 7 días desde última sincronización -``` - ---- - -## INVENTARIOS REQUERIDOS POR PROYECTO - -```yaml -inventarios_obligatorios: - DATABASE_INVENTORY.yml: - contenido: - - Lista completa de schemas - - Lista completa de tablas por schema - - Conteo de funciones, triggers, policies - - Estado de cada objeto (active/deprecated/planned) - actualizar_cuando: - - Crear/modificar/eliminar tabla - - Crear/modificar/eliminar schema - - Agregar/modificar funciones o triggers - - BACKEND_INVENTORY.yml: - contenido: - - Lista completa de módulos - - Lista completa de entities por módulo - - Lista completa de services por módulo - - Conteo de endpoints por módulo - - Estado de cada objeto - actualizar_cuando: - - Crear/modificar/eliminar entity - - Crear/modificar/eliminar service - - Crear/modificar/eliminar módulo - - Agregar/modificar endpoints - - FRONTEND_INVENTORY.yml: - contenido: - - Lista completa de componentes - - Lista completa de páginas - - Lista completa de hooks/stores - - Estado de cada objeto - actualizar_cuando: - - Crear/modificar/eliminar componente - - Crear/modificar/eliminar página - - Crear/modificar/eliminar hook/store - - MASTER_INVENTORY.yml: - contenido: - - Resumen de todos los inventarios - - Totales consolidados - - Última fecha de sincronización - - Score de coherencia - actualizar_cuando: - - Se actualiza cualquier otro inventario -``` - ---- - -## VERIFICACIONES DE SINCRONIZACIÓN - -### 1. Verificar Cobertura de Inventarios - -```yaml -cobertura_minima: - DATABASE_INVENTORY: - schemas: "100% de schemas en DDL" - tablas: "100% de tablas en DDL" - funciones: "100% de funciones en DDL" - - BACKEND_INVENTORY: - modulos: "100% de carpetas en modules/" - entities: "100% de archivos .entity.ts" - services: "100% de archivos .service.ts" - - FRONTEND_INVENTORY: - componentes: "100% de archivos .tsx en components/" - paginas: "100% de archivos en pages/" - stores: "100% de stores/hooks" -``` - -### 2. Verificar Consistencia de Conteos - -```yaml -validacion_conteos: - comparar: - - "Conteo en inventario vs archivos reales" - - "Conteo reportado en _INDEX.yml vs inventario" - - "Conteo entre inventarios relacionados" - - tolerancia: "0% - Debe ser exacto" - - si_discrepancia: - accion: "BLOQUEAR hasta sincronizar" -``` - -### 3. Verificar Actualización Reciente - -```yaml -frescura: - maxima_antiguedad: "7 días" - - verificar: - - "Fecha de última actualización en inventario" - - "Comparar con fecha de último commit en código" - - si_desactualizado: - accion: "ADVERTIR y solicitar sincronización" -``` - ---- - -## PROCESO DE SINCRONIZACIÓN - -### Sincronización Manual - -```bash -# El agente debe ejecutar para cada inventario: - -# 1. Contar objetos reales -find apps/database/ddl -name "*.sql" -exec grep -l "CREATE TABLE" {} \; | wc -l -find apps/backend/src/modules -name "*.entity.ts" | wc -l -find apps/backend/src/modules -name "*.service.ts" | wc -l - -# 2. Comparar con inventario -# 3. Actualizar inventario si hay discrepancia -# 4. Actualizar timestamp de sincronización -``` - -### Campos Obligatorios en Inventarios - -```yaml -metadata_obligatoria: - version: "Semver del inventario" - updated: "Fecha ISO de última actualización" - updated_by: "Agente que actualizó" - sync_status: "SYNCED | OUT_OF_SYNC | PARTIAL" - coverage: - total_expected: "N objetos esperados" - total_documented: "N objetos documentados" - percentage: "100%" -``` - ---- - -## CHECKLIST DE SINCRONIZACIÓN - -### Al Completar Tarea - -```markdown -## Verificación de Inventarios - -### DATABASE_INVENTORY.yml -[ ] Conteo de schemas correcto -[ ] Conteo de tablas correcto -[ ] Nuevos objetos agregados -[ ] Objetos eliminados removidos -[ ] Timestamp actualizado - -### BACKEND_INVENTORY.yml -[ ] Conteo de módulos correcto -[ ] Conteo de entities correcto -[ ] Conteo de services correcto -[ ] Conteo de endpoints correcto -[ ] Nuevos objetos agregados -[ ] Timestamp actualizado - -### FRONTEND_INVENTORY.yml -[ ] Conteo de componentes correcto -[ ] Conteo de páginas correcto -[ ] Nuevos objetos agregados -[ ] Timestamp actualizado - -### MASTER_INVENTORY.yml -[ ] Totales consolidados correctos -[ ] Score de coherencia actualizado -[ ] Timestamp actualizado -``` - ---- - -## INTEGRACIÓN CON TRIGGER-COHERENCIA-CAPAS - -```yaml -secuencia: - 1: "TRIGGER-COHERENCIA-CAPAS verifica estructura" - 2: "TRIGGER-INVENTARIOS-SINCRONIZADOS verifica documentación" - 3: "TRIGGER-DOCUMENTACION-OBLIGATORIA verifica gobernanza" - -dependencia: - - "Coherencia debe pasar ANTES de sincronizar inventarios" - - "Inventarios deben estar sincronizados ANTES de documentar" -``` - ---- - -## MENSAJES DE ERROR - -```yaml -errores: - E-INV-001: - mensaje: "Inventario desactualizado (más de 7 días)" - accion: "Ejecutar sincronización de inventario" - bloqueante: false (advertencia) - - E-INV-002: - mensaje: "Discrepancia de conteo en inventario" - accion: "Sincronizar inventario con código real" - bloqueante: true - - E-INV-003: - mensaje: "Objeto en código no documentado en inventario" - accion: "Agregar objeto al inventario" - bloqueante: true - - E-INV-004: - mensaje: "Objeto en inventario no existe en código" - accion: "Remover objeto del inventario o restaurar código" - bloqueante: true - - E-INV-005: - mensaje: "Inventario faltante" - accion: "Crear inventario siguiendo template" - bloqueante: true -``` - ---- - -## AUTOMATIZACIÓN FUTURA - -```yaml -scripts_recomendados: - sync-database-inventory: - descripcion: "Sincronizar DATABASE_INVENTORY.yml automáticamente" - implementar_en: "scripts/sync-inventories.sh" - - sync-backend-inventory: - descripcion: "Sincronizar BACKEND_INVENTORY.yml automáticamente" - implementar_en: "scripts/sync-inventories.sh" - - validate-inventories: - descripcion: "Validar que todos los inventarios estén sincronizados" - implementar_en: "scripts/validate-inventories.sh" - - estado: "DOCUMENTADO - Por implementar" -``` - ---- - -## REFERENCIAS - -| Alias | Descripción | -|-------|-------------| -| @TRIGGER_INVENTARIOS | Este trigger | -| @TRIGGER_COHERENCIA | Coherencia entre capas | -| @DEF_CHK_POST | Checklist post-tarea | - ---- - -**Versión:** 1.0.0 | **Sistema:** SIMCO v4.0.0 | **Tipo:** Trigger de Sincronización diff --git a/orchestration/_archive/environment/ENVIRONMENT-INVENTORY.yml b/orchestration/_archive/environment/ENVIRONMENT-INVENTORY.yml deleted file mode 100644 index d294de2..0000000 --- a/orchestration/_archive/environment/ENVIRONMENT-INVENTORY.yml +++ /dev/null @@ -1,694 +0,0 @@ -# ============================================================================= -# ENVIRONMENT-INVENTORY.yml - CLINICA-VETERINARIA -# ============================================================================= -# Inventario Completo de Entorno de Desarrollo y Produccion -# Generado por: @PERFIL_DEVENV -# Basado en: orchestration/templates/TEMPLATE-ENVIRONMENT-INVENTORY.yml -# ============================================================================= - -version: "1.1.0" -fecha_creacion: "2026-01-04" -fecha_actualizacion: "2026-01-04" -responsable: "@PERFIL_DEVENV" - -# ----------------------------------------------------------------------------- -# IDENTIFICACION DEL PROYECTO -# ----------------------------------------------------------------------------- - -proyecto: - nombre: "Clinica Veterinaria" - alias: "clinica-veterinaria" - codigo: "CV" - nivel: "NIVEL_2B.3" - tipo: "vertical-especializada" - estado: "desarrollo" - descripcion: "Sistema de gestion para clinicas veterinarias" - parent: "erp-clinicas" - herencia: - - erp-core - - erp-clinicas - -# ----------------------------------------------------------------------------- -# HERRAMIENTAS Y RUNTIME -# ----------------------------------------------------------------------------- - -herramientas: - runtime: - node: - version: "20.x" - version_minima: "18.x" - requerido: true - notas: "LTS recomendado para NestJS y React" - python: - version: "" - requerido: false - notas: "No requerido para este proyecto" - - package_managers: - npm: - version: "10.x" - requerido: true - pnpm: - version: "8.x" - requerido: false - notas: "Alternativa opcional" - - build_tools: - - nombre: "Vite" - version: "5.x" - uso: "Frontend build y dev server" - - nombre: "TypeScript" - version: "5.x" - uso: "Compilacion de codigo" - - nombre: "NestJS CLI" - version: "10.x" - uso: "Backend scaffolding y build" - - linters: - - nombre: "ESLint" - version: "8.x" - config: ".eslintrc.js" - - nombre: "Prettier" - version: "3.x" - config: ".prettierrc" - - testing: - - nombre: "Jest" - version: "29.x" - tipo: "unit backend" - config: "jest.config.js" - - nombre: "Vitest" - version: "1.x" - tipo: "unit frontend" - config: "vitest.config.ts" - - nombre: "Supertest" - version: "6.x" - tipo: "e2e" - config: "jest-e2e.config.js" - -# ----------------------------------------------------------------------------- -# SERVICIOS Y PUERTOS -# ----------------------------------------------------------------------------- - -servicios: - frontend: - nombre: "clinica-veterinaria-frontend" - framework: "React" - version: "18.x" - puerto: 3120 - comando_dev: "npm run dev" - comando_build: "npm run build" - comando_preview: "npm run preview" - ubicacion: "apps/frontend/" - url_local: "http://localhost:3120" - build_output: "dist/" - - backend: - nombre: "clinica-veterinaria-backend" - framework: "NestJS" - version: "10.x" - puerto: 3121 - comando_dev: "npm run start:dev" - comando_build: "npm run build" - comando_prod: "npm run start:prod" - ubicacion: "apps/backend/" - url_local: "http://localhost:3121" - api_prefix: "/api/v1" - swagger_url: "http://localhost:3121/api/docs" - -# ----------------------------------------------------------------------------- -# BASE DE DATOS - CONFIGURACION COMPLETA -# ----------------------------------------------------------------------------- - -base_de_datos: - principal: - engine: "PostgreSQL" - version: "15" - host_variable: "DB_HOST" - puerto_variable: "DB_PORT" - - ambientes: - development: - host: "localhost" - puerto: 5440 - nombre: "clinica_veterinaria_dev" - usuario: "veterinaria_dev" - password_ref: "DB_PASSWORD en .env" - ssl: false - pool_size: 10 - conexion: "postgresql://veterinaria_dev:{password}@localhost:5440/clinica_veterinaria_dev" - - test: - host: "localhost" - puerto: 5440 - nombre: "clinica_veterinaria_test" - usuario: "veterinaria_dev" - password_ref: "DB_PASSWORD en .env" - ssl: false - pool_size: 5 - conexion: "postgresql://veterinaria_dev:{password}@localhost:5440/clinica_veterinaria_test" - - staging: - host: "${DB_HOST}" - puerto: 5432 - nombre: "clinica_veterinaria_staging" - usuario: "veterinaria_staging" - password_ref: "DB_PASSWORD en variables de CI/CD" - ssl: true - pool_size: 20 - conexion: "postgresql://veterinaria_staging:{password}@${DB_HOST}:5432/clinica_veterinaria_staging?sslmode=require" - - production: - host: "${DB_HOST}" - puerto: 5432 - nombre: "clinica_veterinaria_prod" - usuario: "veterinaria_prod" - password_ref: "DB_PASSWORD en secrets manager" - ssl: true - pool_size: 50 - conexion: "postgresql://veterinaria_prod:{password}@${DB_HOST}:5432/clinica_veterinaria_prod?sslmode=require" - - schemas: - - nombre: "public" - descripcion: "Schema principal PostgreSQL" - - nombre: "veterinaria" - descripcion: "Entidades especificas veterinarias (especies, razas, mascotas, vacunas)" - - nombre: "clinical" - descripcion: "Heredado de erp-clinicas (consultorios, citas, historiales)" - - nombre: "financial" - descripcion: "Heredado de erp-core (pagos, facturacion)" - - nombre: "hr" - descripcion: "Heredado de erp-core (empleados, nomina)" - - nombre: "inventory" - descripcion: "Heredado de erp-core (medicamentos, insumos)" - - scripts_inicializacion: - orden: - - "database/init/00-extensions.sql" - - "database/init/01-schemas.sql" - - "database/schemas/01-veterinaria-schema-ddl.sql" - - "database/seeds/fase8/01-veterinaria-catalogos.sql" - - redis: - host_variable: "REDIS_HOST" - puerto_variable: "REDIS_PORT" - - ambientes: - development: - host: "localhost" - puerto: 6387 - database: 0 - password: "" - conexion: "redis://localhost:6387/0" - - production: - host: "${REDIS_HOST}" - puerto: 6379 - database: 0 - password_ref: "REDIS_PASSWORD en secrets" - conexion: "redis://:${REDIS_PASSWORD}@${REDIS_HOST}:6379/0" - - uso: - - "Cache de sesiones" - - "Cache de consultas frecuentes" - - "Rate limiting" - - "Queue de tareas (Bull)" - -# ----------------------------------------------------------------------------- -# VARIABLES DE ENTORNO - DESARROLLO -# ----------------------------------------------------------------------------- - -variables_entorno: - archivos: - ejemplo: ".env.example" - desarrollo: ".env" - test: ".env.test" - produccion: ".env.production" - - development: - - nombre: "NODE_ENV" - valor: "development" - descripcion: "Ambiente de ejecucion" - requerido: true - sensible: false - - - nombre: "APP_NAME" - valor: "clinica-veterinaria" - descripcion: "Nombre de la aplicacion" - requerido: true - sensible: false - - - nombre: "APP_VERSION" - valor: "1.0.0" - descripcion: "Version de la aplicacion" - requerido: false - sensible: false - - # Puertos - - nombre: "FRONTEND_PORT" - valor: "3120" - descripcion: "Puerto del frontend React" - requerido: true - sensible: false - - - nombre: "BACKEND_PORT" - valor: "3121" - descripcion: "Puerto del backend NestJS" - requerido: true - sensible: false - - # Base de datos - - nombre: "DB_HOST" - valor: "localhost" - descripcion: "Host de PostgreSQL" - requerido: true - sensible: false - - - nombre: "DB_PORT" - valor: "5440" - descripcion: "Puerto de PostgreSQL" - requerido: true - sensible: false - - - nombre: "DB_NAME" - valor: "clinica_veterinaria_dev" - descripcion: "Nombre de la base de datos" - requerido: true - sensible: false - - - nombre: "DB_USER" - valor: "veterinaria_dev" - descripcion: "Usuario de PostgreSQL" - requerido: true - sensible: false - - - nombre: "DB_PASSWORD" - valor: "" - descripcion: "Password de PostgreSQL" - requerido: true - sensible: true - generacion: "openssl rand -base64 32" - - - nombre: "DATABASE_URL" - valor: "postgresql://veterinaria_dev:${DB_PASSWORD}@localhost:5440/clinica_veterinaria_dev" - descripcion: "Connection string completo" - requerido: true - sensible: true - - # Redis - - nombre: "REDIS_HOST" - valor: "localhost" - descripcion: "Host de Redis" - requerido: true - sensible: false - - - nombre: "REDIS_PORT" - valor: "6387" - descripcion: "Puerto de Redis" - requerido: true - sensible: false - - - nombre: "REDIS_URL" - valor: "redis://localhost:6387/0" - descripcion: "Connection string de Redis" - requerido: true - sensible: false - - # Autenticacion - - nombre: "JWT_SECRET" - valor: "" - descripcion: "Secreto para firmar JWT (min 32 caracteres)" - requerido: true - sensible: true - generacion: "openssl rand -base64 64" - - - nombre: "JWT_EXPIRES_IN" - valor: "24h" - descripcion: "Tiempo de expiracion del access token" - requerido: true - sensible: false - - - nombre: "JWT_REFRESH_EXPIRES_IN" - valor: "7d" - descripcion: "Tiempo de expiracion del refresh token" - requerido: true - sensible: false - - # CORS - - nombre: "FRONTEND_URL" - valor: "http://localhost:3120" - descripcion: "URL del frontend para CORS" - requerido: true - sensible: false - - - nombre: "ALLOWED_ORIGINS" - valor: "http://localhost:3120,http://localhost:3121" - descripcion: "Origenes permitidos (comma separated)" - requerido: true - sensible: false - - # Logging - - nombre: "LOG_LEVEL" - valor: "debug" - descripcion: "Nivel de logging (debug, info, warn, error)" - requerido: false - sensible: false - - - nombre: "LOG_FORMAT" - valor: "pretty" - descripcion: "Formato de logs (pretty, json)" - requerido: false - sensible: false - - # File Storage - - nombre: "STORAGE_TYPE" - valor: "local" - descripcion: "Tipo de storage (local, s3, minio)" - requerido: false - sensible: false - - - nombre: "STORAGE_PATH" - valor: "./uploads" - descripcion: "Path para almacenamiento local" - requerido: false - sensible: false - - - nombre: "MAX_FILE_SIZE" - valor: "10485760" - descripcion: "Tamano maximo de archivo en bytes (10MB)" - requerido: false - sensible: false - - # Email (opcional) - - nombre: "SMTP_HOST" - valor: "localhost" - descripcion: "Host SMTP para emails" - requerido: false - sensible: false - - - nombre: "SMTP_PORT" - valor: "1025" - descripcion: "Puerto SMTP (1025 para MailHog)" - requerido: false - sensible: false - - production: - notas: | - En produccion, las siguientes variables deben configurarse - via secrets manager o variables de CI/CD: - - DB_PASSWORD (secreto) - - JWT_SECRET (secreto) - - REDIS_PASSWORD (secreto) - - AWS_ACCESS_KEY_ID (si usa S3) - - AWS_SECRET_ACCESS_KEY (si usa S3) - - diferencias: - - nombre: "NODE_ENV" - valor: "production" - - nombre: "LOG_LEVEL" - valor: "info" - - nombre: "LOG_FORMAT" - valor: "json" - - nombre: "DB_PORT" - valor: "5432" - - nombre: "REDIS_PORT" - valor: "6379" - - nombre: "STORAGE_TYPE" - valor: "s3" - -# ----------------------------------------------------------------------------- -# CONTENEDORES DOCKER -# ----------------------------------------------------------------------------- - -docker: - compose_file: "docker-compose.yml" - compose_dev: "docker-compose.dev.yml" - compose_prod: "docker-compose.prod.yml" - - services: - - nombre: "db" - imagen: "postgres:15-alpine" - puerto_host: 5440 - puerto_container: 5432 - variables: - POSTGRES_DB: "clinica_veterinaria_dev" - POSTGRES_USER: "veterinaria_dev" - POSTGRES_PASSWORD: "${DB_PASSWORD}" - volumes: - - "postgres_data:/var/lib/postgresql/data" - healthcheck: "pg_isready -U veterinaria_dev" - - - nombre: "redis" - imagen: "redis:7-alpine" - puerto_host: 6387 - puerto_container: 6379 - volumes: - - "redis_data:/data" - healthcheck: "redis-cli ping" - - - nombre: "mailhog" - imagen: "mailhog/mailhog" - puerto_smtp: 1025 - puerto_web: 8025 - uso: "Testing de emails en desarrollo" - - volumes: - - nombre: "postgres_data" - descripcion: "Datos persistentes de PostgreSQL" - - nombre: "redis_data" - descripcion: "Datos persistentes de Redis" - - networks: - - nombre: "clinica_veterinaria_network" - driver: "bridge" - -# ----------------------------------------------------------------------------- -# MIGRACIONES Y SEEDS -# ----------------------------------------------------------------------------- - -migraciones: - herramienta: "TypeORM" - directorio: "apps/backend/src/database/migrations" - - comandos: - generar: "npm run migration:generate -- -n NombreMigracion" - ejecutar: "npm run migration:run" - revertir: "npm run migration:revert" - mostrar: "npm run migration:show" - -seeds: - directorio: "database/seeds" - orden: - - "fase8/01-veterinaria-catalogos.sql" - - comandos: - ejecutar: "npm run seed" - desarrollo: "npm run seed:dev" - -# ----------------------------------------------------------------------------- -# SCRIPTS DE DESARROLLO -# ----------------------------------------------------------------------------- - -scripts: - setup: - descripcion: "Configurar entorno desde cero" - pasos: - - comando: "npm install" - descripcion: "Instalar dependencias" - - comando: "cp .env.example .env" - descripcion: "Crear archivo de configuracion" - - comando: "docker-compose up -d db redis" - descripcion: "Levantar servicios de infraestructura" - - comando: "npm run db:create" - descripcion: "Crear base de datos" - - comando: "npm run migration:run" - descripcion: "Ejecutar migraciones" - - comando: "npm run seed" - descripcion: "Cargar datos iniciales" - - desarrollo: - frontend: "cd apps/frontend && npm run dev" - backend: "cd apps/backend && npm run start:dev" - ambos: "npm run dev:all" - docker: "docker-compose up -d" - - testing: - unit: "npm run test" - unit_watch: "npm run test:watch" - e2e: "npm run test:e2e" - coverage: "npm run test:cov" - - build: - frontend: "cd apps/frontend && npm run build" - backend: "cd apps/backend && npm run build" - docker: "docker-compose -f docker-compose.prod.yml build" - - database: - create: "npm run db:create" - drop: "npm run db:drop" - reset: "npm run db:reset" - migrations_run: "npm run migration:run" - migrations_revert: "npm run migration:revert" - seed: "npm run seed" - - linting: - lint: "npm run lint" - lint_fix: "npm run lint:fix" - format: "npm run format" - -# ----------------------------------------------------------------------------- -# INSTRUCCIONES DE SETUP -# ----------------------------------------------------------------------------- - -setup_instrucciones: | - ## Setup del Entorno de Desarrollo - Clinica Veterinaria - - ### Prerequisitos - - Node.js 20.x (LTS) - - PostgreSQL 15 (o Docker) - - Redis 7 (o Docker) - - npm 10.x - - Git - - ### Opcion 1: Setup con Docker (Recomendado) - - ```bash - # 1. Clonar repositorio - git clone - cd clinica-veterinaria - - # 2. Instalar dependencias - npm install - - # 3. Configurar variables de entorno - cp .env.example .env - # Editar .env - generar passwords seguros: - # openssl rand -base64 32 # para DB_PASSWORD - # openssl rand -base64 64 # para JWT_SECRET - - # 4. Levantar infraestructura - docker-compose up -d db redis - - # 5. Crear base de datos y ejecutar migraciones - npm run db:create - npm run migration:run - npm run seed - - # 6. Iniciar desarrollo - npm run dev:all - ``` - - ### Opcion 2: Setup con PostgreSQL Local - - ```bash - # 1-3. Igual que arriba - - # 4. Crear usuario y base de datos en PostgreSQL - sudo -u postgres psql - CREATE USER veterinaria_dev WITH PASSWORD 'tu_password'; - CREATE DATABASE clinica_veterinaria_dev OWNER veterinaria_dev; - GRANT ALL PRIVILEGES ON DATABASE clinica_veterinaria_dev TO veterinaria_dev; - \q - - # 5. Configurar Redis local o Docker - docker run -d --name redis-veterinaria -p 6387:6379 redis:7-alpine - - # 6-7. Continuar con migraciones y seeds - ``` - - ### Verificar Instalacion - - Frontend: http://localhost:3120 - - Backend API: http://localhost:3121/api/v1 - - Swagger Docs: http://localhost:3121/api/docs - - Health Check: http://localhost:3121/health - - ### Usuarios de Prueba (despues de seed) - - Admin: admin@clinica-vet.local / Admin123! - - Veterinario: vet@clinica-vet.local / Vet123! - - Recepcion: recepcion@clinica-vet.local / Recep123! - -# ----------------------------------------------------------------------------- -# TROUBLESHOOTING -# ----------------------------------------------------------------------------- - -troubleshooting: - - problema: "Puerto 3120 o 3121 en uso" - solucion: | - Verificar con: lsof -i :3120 - Terminar proceso: kill -9 - O cambiar puertos en .env - - - problema: "Error de conexion a PostgreSQL" - solucion: | - 1. Verificar que PostgreSQL esta corriendo: - docker-compose ps - # o: systemctl status postgresql - 2. Verificar credenciales en .env - 3. Verificar que la BD existe: - psql -h localhost -p 5440 -U veterinaria_dev -l - - - problema: "Error de conexion a Redis" - solucion: | - 1. Verificar que Redis esta corriendo: - docker-compose ps - # o: redis-cli -p 6387 ping - 2. Verificar puerto en .env - - - problema: "Migraciones fallan" - solucion: | - 1. Verificar que la BD existe - 2. Verificar permisos del usuario - 3. Revisar logs: npm run migration:run --verbose - 4. Si es necesario, resetear: npm run db:reset - - - problema: "JWT errors" - solucion: | - Verificar que JWT_SECRET esta configurado (min 32 caracteres) - Generar nuevo: openssl rand -base64 64 - - - problema: "CORS errors en frontend" - solucion: | - Verificar FRONTEND_URL y ALLOWED_ORIGINS en .env - Deben coincidir con la URL del frontend - -# ----------------------------------------------------------------------------- -# CONFIGURACION DE PRODUCCION -# ----------------------------------------------------------------------------- - -produccion: - checklist: - - item: "Variables de entorno configuradas via secrets manager" - - item: "SSL/TLS habilitado para BD y Redis" - - item: "Backups automaticos configurados" - - item: "Monitoreo y alertas activas" - - item: "Rate limiting configurado" - - item: "CORS restringido a dominios autorizados" - - item: "Logs en formato JSON para agregacion" - - infraestructura_recomendada: - base_de_datos: "AWS RDS PostgreSQL 15 o equivalente" - cache: "AWS ElastiCache Redis o equivalente" - storage: "AWS S3 o equivalente" - cdn: "CloudFront o equivalente" - ci_cd: "GitHub Actions / GitLab CI" - - escalado: - backend_replicas: 2 - pool_db_size: 50 - redis_maxmemory: "256mb" - -# ----------------------------------------------------------------------------- -# REFERENCIAS -# ----------------------------------------------------------------------------- - -referencias: - perfil_devenv: "orchestration/agents/perfiles/PERFIL-DEVENV.md" - inventario_master: "orchestration/inventarios/DEVENV-MASTER-INVENTORY.yml" - inventario_puertos: "orchestration/inventarios/DEVENV-PORTS-INVENTORY.yml" - contexto_proyecto: "orchestration/00-guidelines/CONTEXTO-PROYECTO.md" - parent_clinicas: "../erp-clinicas/orchestration/environment/ENVIRONMENT-INVENTORY.yml" - schema_veterinaria: "database/schemas/01-veterinaria-schema-ddl.sql" - -# ============================================================================= -# FIN DE INVENTARIO -# ============================================================================= diff --git a/orchestration/_archive/referencias/DEPENDENCIAS-ERP-CORE.yml b/orchestration/_archive/referencias/DEPENDENCIAS-ERP-CORE.yml deleted file mode 100644 index 2beee52..0000000 --- a/orchestration/_archive/referencias/DEPENDENCIAS-ERP-CORE.yml +++ /dev/null @@ -1,137 +0,0 @@ -# DEPENDENCIAS-ERP-CORE.yml - Clínica Veterinaria -# Dependencias técnicas heredadas de erp-core via erp-clinicas -# Versión: 1.0.0 -# Fecha: 2026-01-13 - -version: "1.0.0" -updated: "2026-01-13" -project: "clinica-veterinaria" - -inheritance_chain: - - source: "template-saas" - version: "1.2.1" - relation: "PROVIDES_TO" - - source: "erp-core" - version: "1.3.0" - relation: "DEPENDS_ON" - - source: "erp-clinicas" - version: "1.0.0" - relation: "EXTENDS" - - target: "clinica-veterinaria" - version: "1.0.0" - relation: "SPECIALIZES" - -# Módulos heredados de ERP-CORE -modules_from_erp_core: - fase_03_core: - total: 14 - inherited: - - MGN-001-auth - - MGN-002-users - - MGN-003-roles - - MGN-004-tenants - - MGN-005-branches - - MGN-006-geo - - MGN-007-mobile - - MGN-008-terminals - - MGN-010-catalog - - MGN-011-products - - MGN-012-inventory - - MGN-013-customers # Propietarios - - MGN-014-sales - - MGN-015-invoicing - not_applicable: - - MGN-009-biometrics # No aplica para veterinaria - - fase_04_saas: - total: 4 - inherited: - - MGN-016-billing - - MGN-017-plans - - MGN-018-webhooks - - MGN-019-feature-flags - propagation_date: "2026-01-13" - propagation_id: "PROP-CORE-002" - - fase_05_ia: - total: 3 - inherited: - - MGN-020-ai-integration - - MGN-021-whatsapp-business - - MGN-022-mcp-server - propagation_date: "2026-01-13" - propagation_id: "PROP-CORE-002" - -# Dependencias técnicas (DDL) -ddl_dependencies: - from_erp_core: - reused: - - "01-extensions.sql" - - "02-core-schema.sql" - - "10-billing.sql" - - "15-ai-agents.sql" - - "16-messaging.sql" - created_fase_04_05: - - "19-webhooks.sql" - - "20-feature-flags.sql" - - from_erp_clinicas: - - "03-clinical-tables.sql" - - "04-financial-ext-schema-ddl.sql" - - "05-hr-ext-fase8-schema-ddl.sql" - - "06-inventory-ext-fase8-schema-ddl.sql" - - "07-purchase-ext-fase8-schema-ddl.sql" - - "08-clinica-ext-fase8-schema-ddl.sql" - - specific_veterinaria: - - "01-veterinaria-schema-ddl.sql" - -# Adaptaciones específicas veterinaria -adaptations: - terminology: - Paciente: "Mascota/Animal" - Cliente: "Propietario" - Consulta: "Consulta veterinaria" - Prescripción: "Receta veterinaria" - Médico: "Veterinario" - - ai_tools: - - name: "crear_cita_vet" - description: "Crear cita en agenda veterinaria" - - name: "cartilla_vacunacion" - description: "Consultar/actualizar cartilla de vacunación" - - name: "calcular_dosis" - description: "Calcular dosis según peso del animal" - - name: "historial_mascota" - description: "Consultar historial clínico de la mascota" - - name: "alerta_vacunas" - description: "Verificar próximas vacunas pendientes" - - whatsapp_templates: - - "recordatorio_vacuna" - - "confirmacion_cita_vet" - - "seguimiento_hospitalizacion" - - "recordatorio_desparasitacion" - - "promocion_estetica" - -# Normativa -compliance: - - code: "NOM-064-ZOO-2000" - name: "Requisitos sanitarios clínicas veterinarias" - - code: "NOM-051-ZOO-1995" - name: "Trato humanitario de animales" - - code: "NOM-046-ZOO-1995" - name: "Sistema de identificación animal" - - code: "SENASICA" - name: "Servicio Nacional de Sanidad" - - code: "SAGARPA" - name: "Regulaciones sanitarias agropecuarias" - -metadata: - created_by: "CLAUDE-CAPVED" - created_at: "2026-01-13" - propagation_ref: "PROP-CORE-002" - related_documents: - - "../00-guidelines/HERENCIA-ERP-CORE.md" - - "../00-guidelines/HERENCIA-ERP-CLINICAS.md" - - "shared/mirrors/erp-core/PROPAGATION-STATUS.yml"