workspace-v1/orchestration/directivas/simco/SIMCO-REUTILIZAR.md
rckrdmrd 66161b1566 feat: Workspace-v1 complete migration with NEXUS v3.4
Sistema NEXUS v3.4 migrado con:

Estructura principal:
- core/orchestration: Sistema SIMCO + CAPVED (27 directivas, 28 perfiles)
- core/catalog: Catalogo de funcionalidades reutilizables
- shared/knowledge-base: Base de conocimiento compartida
- devtools/scripts: Herramientas de desarrollo
- control-plane/registries: Control de servicios y CI/CD
- orchestration/: Configuracion de orquestacion de agentes

Proyectos incluidos (11):
- gamilit (submodule -> GitHub)
- trading-platform (OrbiquanTIA)
- erp-suite con 5 verticales:
  - erp-core, construccion, vidrio-templado
  - mecanicas-diesel, retail, clinicas
- betting-analytics
- inmobiliaria-analytics
- platform_marketing_content
- pos-micro, erp-basico

Configuracion:
- .gitignore completo para Node.js/Python/Docker
- gamilit como submodule (git@github.com:rckrdmrd/gamilit-workspace.git)
- Sistema de puertos estandarizado (3005-3199)

Generated with NEXUS v3.4 Migration System
EPIC-010: Configuracion Git y Repositorios
2026-01-04 03:37:42 -06:00

7.7 KiB

SIMCO: REUTILIZAR DEL CATÁLOGO

Versión: 1.0.0 Fecha: 2025-12-08 Aplica a: TODO agente que implemente funcionalidades comunes Prioridad: OBLIGATORIA - Verificar ANTES de crear nuevo


RESUMEN EJECUTIVO

Antes de implementar funcionalidades comunes (auth, notificaciones, pagos, etc.), VERIFICAR si existe código probado en @CATALOG y REUTILIZARLO.


PRINCIPIO FUNDAMENTAL

╔══════════════════════════════════════════════════════════════════════╗
║                                                                       ║
║              CÓDIGO PROBADO > CÓDIGO NUEVO                           ║
║                                                                       ║
║  "Reutilizar código validado ahorra tiempo y evita bugs."            ║
║  "El catálogo contiene soluciones probadas en producción."           ║
║                                                                       ║
╚══════════════════════════════════════════════════════════════════════╝

CUÁNDO APLICAR ESTA DIRECTIVA

Funcionalidades en el Catálogo (@CATALOG)

Funcionalidad Keywords Alias
Autenticación login, registro, JWT, OAuth, password @CATALOG_AUTH
Sesiones session, logout, dispositivo, concurrent @CATALOG_SESSION
Rate Limiting throttle, 429, limite, abuse @CATALOG_RATELIMIT
Notificaciones email, push, in-app, alerta @CATALOG_NOTIFY
Multi-Tenancy tenant, organization, RLS @CATALOG_TENANT
Feature Flags toggle, feature, rollout, a/b @CATALOG_FLAGS
WebSocket realtime, socket, streaming @CATALOG_WS
Pagos payment, stripe, subscription @CATALOG_PAYMENTS

CHECKLIST RÁPIDO

VERIFICAR CATÁLOGO
├── [ ] 1. Buscar en @CATALOG_INDEX con keywords
├── [ ] 2. Si encuentra → Seguir pasos abajo
└── [ ] 3. Si NO encuentra → Usar @CREAR normal

SI ENCUENTRA EN CATÁLOGO
├── [ ] 4. Leer README.md de la funcionalidad
├── [ ] 5. Verificar compatibilidad de stack
├── [ ] 6. Seguir IMPLEMENTATION.md
├── [ ] 7. Copiar código de _reference/
├── [ ] 8. Adaptar configuración al proyecto
├── [ ] 9. Ejecutar tests de referencia
└── [ ] 10. Documentar adaptaciones realizadas

PROCESO DETALLADO

# Buscar por keyword en índice
grep -i "{lo que necesito}" @CATALOG_INDEX

# Ejemplos:
grep -i "login" @CATALOG_INDEX      # → auth
grep -i "sesion" @CATALOG_INDEX     # → session-management
grep -i "email" @CATALOG_INDEX      # → notifications
grep -i "stripe" @CATALOG_INDEX     # → payments

Paso 2: Verificar Compatibilidad

Antes de usar código del catálogo, verificar:

Checklist de Compatibilidad:
[ ] Stack del catálogo es compatible con mi proyecto
    - Catálogo usa: {stack del catálogo}
    - Mi proyecto usa: {stack del proyecto}
[ ] Versiones de dependencias son compatibles
[ ] El estado es "production-ready" o "documentando"

Paso 3: Leer Documentación

# Ir al directorio de la funcionalidad
cd @CATALOG/{funcionalidad}/

# Leer descripción y trade-offs
cat README.md

# Leer pasos de implementación
cat IMPLEMENTATION.md

Extraer de README.md:

  • Qué hace exactamente
  • Cuándo usar / cuándo NO usar
  • Dependencias requeridas
  • Trade-offs conocidos

Paso 4: Copiar Código de Referencia

# Ver archivos de referencia disponibles
ls @CATALOG/{funcionalidad}/_reference/

# Copiar al proyecto
cp @CATALOG/{funcionalidad}/_reference/{archivo} {destino_en_proyecto}

IMPORTANTE: El código en _reference/ es un punto de partida, NO copiar ciegamente:

  • Adaptar nombres al proyecto
  • Ajustar configuración
  • Modificar según necesidades específicas

Paso 5: Seguir Guía de Implementación

El archivo IMPLEMENTATION.md contiene:

1. Prerequisitos (qué debe existir antes)
2. Pasos de implementación (en orden)
3. Configuración requerida (env vars, etc.)
4. Verificación (cómo validar que funciona)
5. Troubleshooting (problemas comunes)

Seguir los pasos EN ORDEN.

Paso 6: Adaptar al Proyecto

Adaptaciones típicas:
- [ ] Renombrar según convenciones del proyecto
- [ ] Ajustar imports/paths
- [ ] Configurar variables de entorno
- [ ] Modificar esquema de BD si difiere
- [ ] Ajustar DTOs/interfaces según necesidad

Paso 7: Validar

# Ejecutar tests del proyecto
npm run test

# Verificar build
npm run build

# Verificar lint
npm run lint

Paso 8: Documentar

Agregar en traza del proyecto:

## Funcionalidad Reutilizada

**Origen:** @CATALOG/{funcionalidad}/
**Versión catálogo:** {versión}
**Fecha:** {YYYY-MM-DD}

### Adaptaciones Realizadas
- {lista de cambios respecto al código de referencia}

### Archivos Creados/Modificados
- {lista de archivos}

### Notas
- {observaciones relevantes}

@CATALOG/{funcionalidad}/
├── README.md           # Descripción, trade-offs, cuándo usar
├── IMPLEMENTATION.md   # Guía paso a paso
└── _reference/         # Código de referencia
    ├── {archivo1}.ts   # Servicios, entities, etc.
    ├── {archivo2}.ts
    ├── {archivo}.spec.ts  # Tests
    └── README.md       # Descripción de cada archivo

QUÉ NO HACER

❌ NO copiar código sin leer README.md
   → Puede haber trade-offs importantes

❌ NO ignorar IMPLEMENTATION.md
   → Los pasos están en orden por una razón

❌ NO modificar archivos en @CATALOG/ directamente
   → Copiar a tu proyecto y modificar ahí

❌ NO usar código con estado "pendiente"
   → Preferir "production-ready" o "documentando"

❌ NO omitir validación (build, lint, tests)
   → El código de referencia funciona, pero tu adaptación debe validarse

Si la funcionalidad NO está en @CATALOG:

1. Proceder con @CREAR normal
2. Implementar siguiendo @SIMCO correspondiente
3. Al completar, considerar si es candidato para catálogo:
   - ¿Es reutilizable (no específica del dominio)?
   - ¿Tiene tests?
   - ¿Está documentada?

4. Si es candidato, notificar para futura inclusión

FUNCIONALIDADES DISPONIBLES (Resumen)

Funcionalidad Estado Stack Origen
auth 🟢 Production-Ready NestJS + JWT + Passport Gamilit
session-management 🟢 Production-Ready NestJS + TypeORM Gamilit
rate-limiting 🟢 Production-Ready NestJS + @nestjs/throttler Gamilit
notifications 🟢 Production-Ready NestJS + Nodemailer + FCM Gamilit
multi-tenancy 🟢 Production-Ready NestJS + PostgreSQL Gamilit
feature-flags 🟢 Production-Ready NestJS + TypeORM Gamilit
websocket 🟢 Production-Ready NestJS + Socket.io Trading
payments 🟢 Production-Ready NestJS + Stripe Trading

Leyenda:

  • 🟢 Production-Ready: README.md + IMPLEMENTATION.md completos
  • 🟡 Documentando: En proceso de documentación
  • 🔴 Pendiente: Identificado pero no documentado

Última actualización: 2025-12-08


REFERENCIAS

  • Catálogo completo: @CATALOG
  • Índice de búsqueda: @CATALOG_INDEX
  • Si no existe: @CREAR (SIMCO-CREAR.md)
  • Anti-duplicación: @PRINCIPIOS/PRINCIPIO-ANTI-DUPLICACION.md

Versión: 1.0.0 | Sistema: SIMCO | Mantenido por: Tech Lead