# ANÁLISIS Y MEJORAS: SISTEMA DE ORQUESTACIÓN DE AGENTES **Proyecto:** MVP Sistema Administración de Obra e INFONAVIT **Basado en:** Sistema de Orquestación GAMILIT **Fecha:** 2025-11-17 **Versión:** 1.0.0 --- ## 📋 RESUMEN EJECUTIVO ### Análisis del Sistema Actual (GAMILIT) **Fortalezas identificadas:** - ✅ Prompts bien estructurados (Agentes principales y subagentes) - ✅ Sistema de trazabilidad con TRAZA-TAREAS-{GRUPO}.md - ✅ Inventarios detallados (DATABASE, BACKEND, FRONTEND) - ✅ Directiva de documentación obligatoria clara - ✅ Flujos de trabajo bien definidos (5 fases: Análisis, Plan, Ejecución, Validación, Documentación) - ✅ Anti-duplicación sistemática - ✅ Estados de componentes en JSON **Áreas de mejora identificadas:** 1. **Trazabilidad granular por tipo de tarea** - Separar: Requerimientos, Correcciones, Features, Validaciones 2. **Agentes especializados por tipo de actividad** - Agentes de análisis, corrección, desarrollo, validación 3. **Sistema de relaciones entre objetos** - Mapeo DB → Backend → Frontend - Dependencias entre componentes 4. **Métricas y reportes automáticos** - Cobertura de implementación - Calidad de código - Deuda técnica --- ## 🎯 PROPUESTAS DE MEJORA ### 1. SISTEMA DE TRAZABILIDAD MEJORADO #### 1.1 Tipos de Trazas Especializadas ``` orchestration/trazas/ ├── TRAZA-REQUERIMIENTOS.md # Requerimientos del plan MVP ├── TRAZA-CORRECCIONES.md # Correcciones aplicadas ├── TRAZA-FEATURES.md # Nuevos features desarrollados ├── TRAZA-VALIDACIONES.md # Validaciones de políticas ├── TRAZA-REFACTORING.md # Refactorizaciones └── TRAZA-BUGS.md # Bugs identificados y resueltos ``` #### 1.2 Formato Mejorado de Entradas ```markdown ## [REQ-001] Implementar Módulo de Proyectos y Obras **Tipo:** Requerimiento del Plan **Prioridad:** P0 **Estado:** ✅ Completado | 🔄 En Progreso | ⏳ Pendiente | ❌ Bloqueado **Fecha inicio:** 2025-11-17 **Fecha fin:** 2025-11-18 **Duración estimada:** 8 horas **Duración real:** 7.5 horas **Agente responsable:** Backend-Dev-001 **Relacionado con:** [DB-005], [FE-003] ### Descripción Implementar módulo completo de gestión de proyectos y obras con estructura de fraccionamientos. ### Componentes Implementados **Base de Datos:** - ✅ Schema: project_management - ✅ Tablas: projects, developments, phases (3 tablas) - ✅ Funciones: 2 - ✅ Triggers: 1 **Backend:** - ✅ Entities: Project, Development, Phase (3 entities) - ✅ Services: ProjectService, DevelopmentService (2 services) - ✅ Controllers: ProjectController (1 controller) - ✅ DTOs: 6 DTOs **Frontend:** - ✅ Páginas: ProjectsPage, ProjectDetailPage (2 páginas) - ✅ Componentes: ProjectCard, ProjectForm (2 componentes) - ✅ Stores: projectStore (1 store) ### Archivos Creados/Modificados **Database (5 archivos):** - apps/database/ddl/schemas/project_management/tables/01-projects.sql - apps/database/ddl/schemas/project_management/tables/02-developments.sql - apps/database/ddl/schemas/project_management/tables/03-phases.sql - apps/database/seeds/dev/project_management/01-projects.sql - apps/database/seeds/dev/project_management/02-developments.sql **Backend (10 archivos):** - apps/backend/src/modules/projects/entities/project.entity.ts - apps/backend/src/modules/projects/entities/development.entity.ts - apps/backend/src/modules/projects/services/project.service.ts - apps/backend/src/modules/projects/controllers/project.controller.ts - apps/backend/src/modules/projects/dto/create-project.dto.ts - ... (5 más) **Frontend (8 archivos):** - apps/frontend/src/apps/admin/pages/ProjectsPage.tsx - apps/frontend/src/apps/admin/pages/ProjectDetailPage.tsx - ... (6 más) ### Métricas de Calidad - ✅ Cobertura de tests: 85% - ✅ Sin errores de compilación - ✅ Sin warnings de linter - ✅ Documentación: 100% - ✅ Inventarios actualizados: 100% ### Validaciones Realizadas - ✅ DB: create-database.sh ejecuta sin errores - ✅ Backend: npm run build exitoso - ✅ Frontend: npm run build exitoso - ✅ E2E: Flujo completo CRUD validado - ✅ Alineación: DB ↔ Backend ↔ Frontend 100% ### Bloqueadores Resueltos - ❌ Ninguno ### Próximos Pasos 1. Agregar reportes de proyectos 2. Implementar filtros avanzados 3. Integrar con módulo de estimaciones ### Lecciones Aprendidas - La relación projects → developments → phases requiere cuidado en cascadas - Importante validar que fraccionamiento_id sea único por proyecto ### Enlaces - Documentación: orchestration/backend/REQ-001/ - Plan original: docs/01-requerimientos/R-001-proyectos-obras.md - ADR: docs/adr/ADR-003-estructura-proyectos.md ``` --- ### 2. AGENTES Y SUBAGENTES ESPECIALIZADOS #### 2.1 Taxonomía de Agentes ```yaml agentes_principales: # Agentes por stack tecnológico (existentes) - Database-Agent: responsabilidad: DDL, migrations, seeds, validaciones DB subagentes: [Schema-Creator, Table-Creator, Function-Creator, Seed-Generator] - Backend-Agent: responsabilidad: NestJS, entities, services, controllers, DTOs subagentes: [Entity-Creator, Service-Creator, Controller-Creator, DTO-Creator] - Frontend-Agent: responsabilidad: React, componentes, páginas, stores, servicios subagentes: [Page-Creator, Component-Creator, Store-Creator, Service-Creator] # Agentes especializados por actividad (NUEVOS) - Requirements-Analyst: responsabilidad: Analizar requerimientos del plan MVP, desglosar en tareas subagentes: [Feature-Analyzer, Dependency-Mapper, Story-Breaker] genera: [TRAZA-REQUERIMIENTOS.md, Planes de implementación] - Code-Reviewer: responsabilidad: Revisar código, validar estándares, detectar code smells subagentes: [Security-Auditor, Performance-Auditor, Standards-Validator] genera: [TRAZA-VALIDACIONES.md, Reportes de calidad] - Bug-Fixer: responsabilidad: Identificar, diagnosticar y corregir bugs subagentes: [Bug-Analyzer, Test-Creator, Fix-Validator] genera: [TRAZA-BUGS.md, TRAZA-CORRECCIONES.md] - Feature-Developer: responsabilidad: Desarrollar nuevos features completos (DB + Backend + Frontend) subagentes: [Database-Agent, Backend-Agent, Frontend-Agent] genera: [TRAZA-FEATURES.md, Documentación de feature] - Policy-Auditor: responsabilidad: Validar cumplimiento de políticas y directivas subagentes: [Documentation-Auditor, Inventory-Auditor, Standards-Auditor] genera: [TRAZA-VALIDACIONES.md, Reportes de cumplimiento] - Integration-Tester: responsabilidad: Pruebas de integración entre capas subagentes: [E2E-Tester, API-Tester, DB-Tester] genera: [Reportes de pruebas, TRAZA-VALIDACIONES.md] subagentes_especializados: # Database - Schema-Creator: tarea: Crear schemas completos con tablas base validaciones: [anti-duplicación, convenciones SQL] - Migration-Generator: tarea: Generar migrations de cambios en DB validaciones: [reversibilidad, seguridad de datos] # Backend - CRUD-Generator: tarea: Generar CRUD completo (Entity + Service + Controller + DTOs) validaciones: [swagger, tests, validaciones] - Security-Implementer: tarea: Implementar guards, policies, RLS validaciones: [permisos, autenticación] # Frontend - Form-Generator: tarea: Generar formularios con validaciones validaciones: [tipos, validaciones, UX] - Dashboard-Creator: tarea: Crear dashboards con métricas validaciones: [performance, responsive] ``` #### 2.2 Políticas de Uso de Agentes ```markdown ## Cuándo Usar Agentes vs Subagentes ### Usar Agente Principal: - Tarea compleja con múltiples fases (>5 pasos) - Afecta múltiples módulos (>2) - Requiere análisis previo - Genera múltiples archivos (>10) - Necesita coordinación entre capas (DB-Backend-Frontend) ### Usar Subagente: - Tarea simple y bien definida (1-3 pasos) - Ámbito limitado (1 módulo, 1-3 archivos) - Patrón repetitivo (CRUD, formularios) - Sin dependencias complejas ### Límites de Concurrencia: - **Máximo agentes principales simultáneos:** 3 - **Máximo subagentes por agente:** 5 - **Máximo subagentes totales simultáneos:** 15 ### Gestión de Errores: 1. **Error en subagente:** - Intentar autocorrección (máx 2 intentos) - Si persiste, escalar a agente principal - Documentar en TRAZA-BUGS.md 2. **Error en agente principal:** - Marcar tarea como bloqueada - Crear entrada en TRAZA-BUGS.md - Notificar a supervisor (humano) 3. **Rollback:** - Mantener snapshot antes de cambios - Proceso automático de rollback en caso de error crítico - Documentar rollback en TRAZA-CORRECCIONES.md ``` --- ### 3. SISTEMA DE INVENTARIOS MEJORADO #### 3.1 Inventario con Relaciones ```yaml # orchestration/inventarios/MASTER_INVENTORY.yml metadata: version: "1.0.0" generated_date: "2025-11-17" total_objects: 450 coverage: database: 100% backend: 100% frontend: 98% tests: 75% # Ejemplo: Módulo de Proyectos modules: projects: status: ✅ Completo priority: P0 phase: MVP database: schema: project_management tables: - name: projects file: apps/database/ddl/schemas/project_management/tables/01-projects.sql columns: 15 indexes: 4 triggers: 1 rls_policies: 3 related_backend_entity: Project related_frontend_pages: [ProjectsPage, ProjectDetailPage] - name: developments file: apps/database/ddl/schemas/project_management/tables/02-developments.sql columns: 12 indexes: 3 triggers: 1 related_backend_entity: Development related_frontend_pages: [DevelopmentsPage] backend: module_path: apps/backend/src/modules/projects entities: - name: Project file: entities/project.entity.ts table: project_management.projects relations: [developments, budgets, contracts] used_in_controllers: [ProjectController] used_in_services: [ProjectService, BudgetService] dto_count: 4 services: - name: ProjectService file: services/project.service.ts entities: [Project, Development] dependencies: [DevelopmentService] endpoints: 8 controllers: - name: ProjectController file: controllers/project.controller.ts routes: [/api/projects, /api/projects/:id, /api/projects/:id/developments] methods: [GET, POST, PUT, PATCH, DELETE] swagger: ✅ Completo used_by_frontend: ✅ Sí frontend: pages: - name: ProjectsPage file: apps/frontend/src/apps/admin/pages/ProjectsPage.tsx routes: [/admin/projects] components_used: [ProjectCard, ProjectList, ProjectFilters] stores_used: [projectStore] api_endpoints: [GET /api/projects, POST /api/projects] - name: ProjectDetailPage file: apps/frontend/src/apps/admin/pages/ProjectDetailPage.tsx routes: [/admin/projects/:id] components_used: [ProjectForm, DevelopmentList] stores_used: [projectStore] api_endpoints: [GET /api/projects/:id, PUT /api/projects/:id] components: - name: ProjectCard file: apps/frontend/src/shared/components/ProjectCard.tsx used_in_pages: [ProjectsPage, DashboardPage] dependencies: [Card, Badge, Button] stores: - name: projectStore file: apps/frontend/src/stores/projectStore.ts state: [projects, selectedProject, loading, error] actions: [fetchProjects, createProject, updateProject, deleteProject] used_in_pages: [ProjectsPage, ProjectDetailPage] tests: coverage: 85% unit_tests: 12 integration_tests: 5 e2e_tests: 3 files: - apps/backend/src/modules/projects/__tests__/project.service.spec.ts - apps/backend/src/modules/projects/__tests__/project.controller.spec.ts - apps/frontend/src/apps/admin/pages/__tests__/ProjectsPage.test.tsx documentation: readme: ✅ apps/backend/src/modules/projects/README.md adr: ✅ docs/adr/ADR-003-estructura-proyectos.md api_docs: ✅ Swagger completo inline_comments: ✅ JSDoc/TSDoc metrics: complexity: Baja maintainability_index: 85 technical_debt: Bajo security_score: 95 # Relaciones entre módulos relationships: projects: depends_on: [] depended_by: [budgets, contracts, purchases, estimates] budgets: depends_on: [projects] depended_by: [estimates] ``` #### 3.2 Inventario de Dependencias ```yaml # orchestration/inventarios/DEPENDENCY_GRAPH.yml # Mapeo de dependencias entre módulos dependencies: # Módulos Core (sin dependencias) core_modules: - auth - users - roles # Nivel 1 (dependen de core) level_1: - projects: depends_on: [auth, users] blocks: [budgets, contracts, purchases] # Nivel 2 (dependen de nivel 1) level_2: - budgets: depends_on: [projects, auth] blocks: [estimates] - contracts: depends_on: [projects, auth] blocks: [estimates] # Nivel 3 level_3: - estimates: depends_on: [budgets, contracts, projects] blocks: [] # Orden de implementación recomendado implementation_order: phase_1: - auth - users - roles phase_2: - projects phase_3: - budgets - contracts - purchases phase_4: - estimates - progress_tracking ``` --- ### 4. MÉTRICAS Y REPORTES AUTOMÁTICOS #### 4.1 Dashboard de Estado ```yaml # orchestration/reportes/DASHBOARD_ESTADO.yml proyecto: "MVP Sistema Administración de Obra" generado: "2025-11-17 10:30:00" # Resumen General resumen: completitud_general: 35% modulos_total: 18 modulos_completados: 6 modulos_en_progreso: 3 modulos_pendientes: 9 objetos_total: 450 objetos_completados: 158 objetos_pendientes: 292 estado_general: "🟡 En Progreso - Fase MVP" # Por Stack stacks: database: schemas_total: 9 schemas_completados: 4 tablas_total: 65 tablas_completadas: 25 funciones_total: 40 funciones_completadas: 12 completitud: 38% estado: "🟡 En Progreso" backend: modulos_total: 18 modulos_completados: 6 entities_total: 65 entities_completadas: 25 services_total: 40 services_completados: 15 controllers_total: 30 controllers_completados: 12 completitud: 40% estado: "🟡 En Progreso" frontend: paginas_total: 45 paginas_completadas: 10 componentes_total: 120 componentes_completados: 35 stores_total: 20 stores_completados: 6 completitud: 28% estado: "🟡 En Progreso" # Por Módulo (Top 10) modulos_estado: - nombre: "auth" completitud: 100% estado: "✅ Completo" bloqueadores: 0 - nombre: "projects" completitud: 100% estado: "✅ Completo" bloqueadores: 0 - nombre: "budgets" completitud: 75% estado: "🔄 En Progreso" bloqueadores: 0 - nombre: "contracts" completitud: 60% estado: "🔄 En Progreso" bloqueadores: 1 bloqueador_desc: "Esperando aprobación de workflow de firmas" # Calidad de Código calidad: cobertura_tests: 75% documentacion: 90% estandares_cumplimiento: 95% deuda_tecnica: "Baja" vulnerabilidades: 0 # Métricas de Desarrollo desarrollo: tareas_completadas_hoy: 12 tareas_completadas_semana: 45 tareas_pendientes: 180 velocity: 9.0 # tareas/día estimado_completar_mvp: "15 días" # Alertas alertas: criticas: 0 altas: 2 medias: 5 bajas: 10 lista_criticas: [] lista_altas: - "Módulo de contratos bloqueado por aprobación externa" - "Cobertura de tests en módulo purchases: 45% (objetivo: 80%)" ``` #### 4.2 Reporte de Calidad Automático ```markdown # REPORTE DE CALIDAD DE CÓDIGO **Generado:** 2025-11-17 10:30:00 **Proyecto:** MVP Sistema Administración de Obra ## Resumen Ejecutivo **Score General:** 87/100 (🟢 Excelente) | Categoría | Score | Estado | |-----------|-------|--------| | Cobertura de Tests | 75/100 | 🟡 Bueno | | Documentación | 90/100 | 🟢 Excelente | | Estándares | 95/100 | 🟢 Excelente | | Seguridad | 92/100 | 🟢 Excelente | | Performance | 85/100 | 🟢 Excelente | | Mantenibilidad | 88/100 | 🟢 Excelente | ## Detalles por Stack ### Database (Score: 92/100) **✅ Fortalezas:** - 100% de tablas tienen comentarios SQL - Convenciones de nombres consistentes - RLS policies implementadas correctamente **⚠️ Áreas de Mejora:** - 15% de funciones sin documentación - 3 índices potencialmente innecesarios - Falta migration para rollback en 2 schemas **Recomendaciones:** 1. Documentar funciones pendientes 2. Revisar índices: idx_projects_status, idx_budgets_created_at 3. Crear rollback migrations ### Backend (Score: 85/100) **✅ Fortalezas:** - Swagger 100% completo - Entities bien mapeadas - DTOs con validaciones **⚠️ Áreas de Mejora:** - Cobertura de tests: 75% (objetivo: 80%) - 5 controllers sin tests de integración - Falta manejo de errores en 3 services **Recomendaciones:** 1. Agregar tests para: ContractController, PurchaseController 2. Implementar try-catch en ProjectService.calculateBudget() 3. Agregar logs estructurados ### Frontend (Score: 82/100) **✅ Fortalezas:** - Componentes bien organizados - Stores con tipado fuerte - UI consistente **⚠️ Áreas de Mejora:** - Cobertura de tests: 60% (objetivo: 70%) - 8 componentes sin tests - Performance: 2 componentes con re-renders innecesarios **Recomendaciones:** 1. Agregar tests para componentes críticos 2. Optimizar: ProjectList (usar React.memo), BudgetTable (virtualización) 3. Implementar lazy loading en 3 páginas ## Deuda Técnica **Total:** 15 items (Baja) **Por Prioridad:** - P0 (Crítica): 0 items - P1 (Alta): 2 items - P2 (Media): 5 items - P3 (Baja): 8 items **Items P1:** 1. Refactorizar ProjectService.calculateBudget() (complejidad ciclomática: 25) 2. Eliminar código duplicado en ContractService y PurchaseService ## Vulnerabilidades de Seguridad **Total:** 0 vulnerabilidades críticas ✅ **Escaneo:** - npm audit: 0 críticas, 2 bajas - OWASP Top 10: ✅ Todas cubiertas - SQL Injection: ✅ Protegido (TypeORM + parametrización) - XSS: ✅ Protegido (React sanitización) - CSRF: ✅ Protegido (tokens) ## Próximas Acciones Recomendadas **Esta Semana:** 1. Aumentar cobertura de tests a 80% (Backend) y 70% (Frontend) 2. Documentar 15 funciones pendientes en Database 3. Refactorizar ProjectService.calculateBudget() **Próximas 2 Semanas:** 1. Optimizar performance en Frontend (2 componentes) 2. Implementar rollback migrations faltantes 3. Resolver deuda técnica P1 ## Tendencias (últimas 4 semanas) ``` Cobertura Tests: 65% → 68% → 72% → 75% (📈 +10%) Documentación: 85% → 87% → 89% → 90% (📈 +5%) Deuda Técnica: 25 → 22 → 18 → 15 (📈 -40%) ``` **Conclusión:** Tendencia positiva en todas las métricas 🎉 ``` --- ## 🔄 IMPLEMENTACIÓN EN PROYECTO INMOBILIARIO ### Estructura Propuesta ``` [RUTA-LEGACY-ELIMINADA]/ ├── orchestration/ │ ├── README.md │ ├── _MAP.md │ │ │ ├── prompts/ │ │ ├── PROMPT-AGENTES-PRINCIPALES.md │ │ ├── PROMPT-SUBAGENTES.md │ │ ├── PROMPT-REQUIREMENTS-ANALYST.md │ │ ├── PROMPT-CODE-REVIEWER.md │ │ ├── PROMPT-BUG-FIXER.md │ │ ├── PROMPT-FEATURE-DEVELOPER.md │ │ └── PROMPT-POLICY-AUDITOR.md │ │ │ ├── directivas/ │ │ ├── DIRECTIVA-DOCUMENTACION-OBLIGATORIA.md │ │ ├── DIRECTIVA-ANTI-DUPLICACION.md │ │ ├── DIRECTIVA-TESTING.md │ │ └── POLITICAS-USO-AGENTES.md │ │ │ ├── trazas/ │ │ ├── TRAZA-REQUERIMIENTOS.md │ │ ├── TRAZA-CORRECCIONES.md │ │ ├── TRAZA-FEATURES.md │ │ ├── TRAZA-VALIDACIONES.md │ │ ├── TRAZA-BUGS.md │ │ ├── TRAZA-TAREAS-DATABASE.md │ │ ├── TRAZA-TAREAS-BACKEND.md │ │ └── TRAZA-TAREAS-FRONTEND.md │ │ │ ├── inventarios/ │ │ ├── MASTER_INVENTORY.yml │ │ ├── DATABASE_INVENTORY.yml │ │ ├── BACKEND_INVENTORY.yml │ │ ├── FRONTEND_INVENTORY.yml │ │ ├── DEPENDENCY_GRAPH.yml │ │ └── TEST_COVERAGE.yml │ │ │ ├── estados/ │ │ ├── ESTADO-DATABASE.json │ │ ├── ESTADO-BACKEND.json │ │ ├── ESTADO-FRONTEND.json │ │ └── ESTADO-GENERAL.json │ │ │ ├── reportes/ │ │ ├── DASHBOARD_ESTADO.yml │ │ ├── REPORTE-CALIDAD-{FECHA}.md │ │ ├── REPORTE-SEMANAL-{FECHA}.md │ │ └── METRICAS-DESARROLLO.yml │ │ │ ├── agentes/ │ │ ├── database/ │ │ │ └── {TAREA-ID}/ │ │ │ ├── 01-ANALISIS.md │ │ │ ├── 02-PLAN.md │ │ │ ├── 03-EJECUCION.md │ │ │ ├── 04-VALIDACION.md │ │ │ └── 05-DOCUMENTACION.md │ │ ├── backend/ │ │ ├── frontend/ │ │ ├── requirements-analyst/ │ │ ├── code-reviewer/ │ │ └── bug-fixer/ │ │ │ └── templates/ │ ├── TEMPLATE-ANALISIS.md │ ├── TEMPLATE-PLAN.md │ ├── TEMPLATE-VALIDACION.md │ └── TEMPLATE-REPORTE-CALIDAD.md ``` --- ## ✅ PLAN DE IMPLEMENTACIÓN ### Fase 1: Preparación (1 día) 1. Crear estructura de carpetas orchestration/ 2. Migrar prompts de GAMILIT adaptados a proyecto inmobiliario 3. Crear directivas específicas del proyecto 4. Configurar templates de documentación ### Fase 2: Configuración de Agentes (2 días) 1. Configurar agentes principales (Database, Backend, Frontend) 2. Configurar agentes especializados (Requirements, Code-Reviewer, etc.) 3. Definir políticas de uso y límites de concurrencia 4. Crear scripts de validación ### Fase 3: Sistema de Trazabilidad (1 día) 1. Crear archivos de trazas especializadas 2. Configurar formato de entradas 3. Implementar sistema de relaciones entre tareas ### Fase 4: Inventarios y Métricas (2 días) 1. Configurar inventarios con relaciones 2. Crear dependency graph 3. Implementar dashboard de estado 4. Configurar reportes automáticos de calidad ### Fase 5: Validación y Ajustes (1 día) 1. Probar flujo completo con tarea de ejemplo 2. Ajustar configuraciones según resultados 3. Documentar lecciones aprendidas --- ## 🎯 CRITERIOS DE ÉXITO 1. **Trazabilidad Completa:** - ✅ Toda tarea documentada en traza correspondiente - ✅ Relaciones entre tareas claras - ✅ Estado actualizado en tiempo real 2. **Inventarios Precisos:** - ✅ 100% de objetos inventariados - ✅ Relaciones DB-Backend-Frontend mapeadas - ✅ Dependencias identificadas 3. **Calidad de Código:** - ✅ Cobertura de tests > 80% - ✅ Documentación > 90% - ✅ Sin vulnerabilidades críticas 4. **Eficiencia de Desarrollo:** - ✅ Velocity > 8 tareas/día - ✅ < 5% de tareas con bloqueadores - ✅ Deuda técnica controlada --- ## 📚 REFERENCIAS - Sistema actual: `core/orchestration/` (Sistema SIMCO) - Directivas: `core/orchestration/directivas/simco/` - *Nota histórica: Análisis basado en patrones del sistema de orquestación original* --- **Versión:** 1.0.0 **Autor:** Claude Code **Revisión requerida:** Semanal