workspace-v1/orchestration/directivas/simco/SIMCO-CONTRIBUIR-CATALOGO.md
rckrdmrd ff3038f183 feat(orchestration): Add subagent token management system
Sistema completo de gestión de tokens para subagentes NEXUS v4.0:

Nuevas directivas SIMCO:
- SIMCO-SUBAGENTE.md: Protocolo para agentes en modo subagente
- SIMCO-CCA-SUBAGENTE.md: CCA ligero para subagentes (~1,500 tokens)
- SIMCO-CONTROL-TOKENS.md: Gestión de límites de tokens
- SIMCO-DELEGACION-PARALELA.md: Delegación paralela

Perfiles compact (~250 tokens cada uno):
- PERFIL-BACKEND-COMPACT.md
- PERFIL-FRONTEND-COMPACT.md
- PERFIL-DATABASE-COMPACT.md
- PERFIL-DEVOPS-COMPACT.md
- PERFIL-ML-COMPACT.md
- PERFIL-GENERIC-SUBAGENT.md

Templates de delegación escalonados:
- TEMPLATE-DELEGACION-MINIMA.md (~250 tokens)
- TEMPLATE-DELEGACION-ESTANDAR.md (~600 tokens)
- TEMPLATE-DELEGACION-COMPLETA.md (~1,800 tokens)

Nuevos perfiles especializados:
- PERFIL-MCP-ARCHITECT.md
- PERFIL-MCP-DEVELOPER.md
- PERFIL-RAG-ENGINEER.md
- PERFIL-CICD-SPECIALIST.md
- PERFIL-PRODUCTION-MANAGER.md
- PERFIL-MONITORING-AGENT.md
- PERFIL-SECRETS-MANAGER.md
- PERFIL-PROPAGATION-TRACKER.md

Checklists y documentación:
- CHECKLIST-PRE-DELEGACION.md
- Análisis y planes de implementación

Métricas de mejora:
- ~59% reducción de tokens por delegación
- Perfiles compact: 69% más ligeros
- CCA subagente: 85% más ligero

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-07 04:43:01 -06:00

8.3 KiB

SIMCO: CONTRIBUIR AL CATÁLOGO

Versión: 1.0.0 Fecha: 2025-12-08 Aplica a: TODO agente que implemente funcionalidad reutilizable Prioridad: RECOMENDADA - Después de completar funcionalidad exitosamente


RESUMEN EJECUTIVO

Cuando implementes una funcionalidad común y reutilizable (auth, notificaciones, pagos, etc.) que funcione en producción, EVALÚA si debe agregarse al catálogo para beneficio de futuros proyectos.


PRINCIPIO FUNDAMENTAL

╔══════════════════════════════════════════════════════════════════════════════╗
║                                                                               ║
║           EL CATÁLOGO CRECE CON CADA PROYECTO EXITOSO                        ║
║                                                                               ║
║  "Documentar mientras desarrollas es más fácil que después."                 ║
║  "Código que no se documenta, no se reutiliza."                              ║
║                                                                               ║
╚══════════════════════════════════════════════════════════════════════════════╝

CUÁNDO APLICAR ESTA DIRECTIVA

Una funcionalidad ES candidata para el catálogo si cumple TODOS:

Criterio Pregunta a Responder
Probada ¿Funciona en producción (al menos 1 proyecto)?
Reutilizable ¿NO es específica de un dominio de negocio?
Común ¿Se necesita en múltiples proyectos típicamente?
Compleja ¿Tiene suficiente complejidad que justifica documentar?
Estable ¿La API/estructura no cambia frecuentemente?

Ejemplos de funcionalidades candidatas:

  • Autenticación, sesiones, rate limiting
  • Notificaciones (email, push, in-app)
  • Pagos, suscripciones
  • WebSockets, real-time
  • Multi-tenancy, feature flags
  • File upload, image processing
  • Audit logs, activity tracking
  • Caching strategies
  • Lógica de negocio específica (cálculo de comisiones de trading)
  • UI components específicos de un proyecto
  • Configuraciones específicas de un proyecto
  • Integraciones one-off con terceros

CHECKLIST RÁPIDO

EVALUAR CANDIDATURA
├── [ ] 1. ¿Cumple los 5 criterios de arriba?
├── [ ] 2. ¿El código está limpio y documentado?
└── [ ] 3. ¿Hay tests que validen el funcionamiento?

SI ES CANDIDATO → CONTRIBUIR
├── [ ] 4. Crear estructura en shared/catalog/{nombre}/
├── [ ] 5. Documentar README.md (descripción, trade-offs)
├── [ ] 6. Documentar IMPLEMENTATION.md (pasos)
├── [ ] 7. Actualizar CATALOG-INDEX.yml
├── [ ] 8. Actualizar @CATALOG README.md
├── [ ] 9. Actualizar ALIASES.yml
└── [ ] 10. Verificar que es encontrable por keywords

PROCESO DETALLADO

Paso 1: Preparar Estructura

# Crear directorio para la funcionalidad
mkdir -p shared/catalog/{nombre-en-kebab-case}/

# Crear archivos base
touch shared/catalog/{nombre}/README.md
touch shared/catalog/{nombre}/IMPLEMENTATION.md

Convención de nombres:

  • Usar kebab-case: audit-logs, file-upload, caching-strategy
  • Nombre descriptivo pero conciso

Paso 2: Documentar README.md

Estructura obligatoria:

# {Nombre de la Funcionalidad}

**Versión:** 1.0.0
**Origen:** projects/{proyecto-origen}
**Estado:** Production-Ready | Documentando
**Última actualización:** YYYY-MM-DD

---

## Descripción

{Descripción clara de qué hace y para qué sirve}

---

## Características

| Característica | Descripción |
|----------------|-------------|
| ... | ... |

---

## Stack Tecnológico

```yaml
backend:
  framework: NestJS
  # ...

Dependencias NPM

{
  "paquete": "^version"
}

Tablas Requeridas

Tabla Propósito
... ...

Endpoints Principales

Método Ruta Descripción
... ... ...

Mantenido por: Sistema NEXUS Proyecto origen: {Proyecto}


### Paso 3: Documentar IMPLEMENTATION.md

**Estructura obligatoria:**

```markdown
# Guía de Implementación: {Nombre}

**Versión:** 1.0.0
**Complejidad:** Baja | Media | Alta

---

## Pre-requisitos

- [ ] Requisito 1
- [ ] Requisito 2

---

## Paso 1: {Nombre del Paso}

{Descripción}

```typescript
// Código de ejemplo

Variables de Entorno

VARIABLE=valor

Checklist de Implementación

  • Paso completado 1
  • Paso completado 2
  • Build pasa sin errores
  • Tests pasan

Troubleshooting

Error: "{mensaje}"

{Solución}


Versión: 1.0.0 Sistema: SIMCO Catálogo


### Paso 4: Actualizar CATALOG-INDEX.yml

```yaml
# Agregar bajo funcionalidades:
  {nombre}:
    nombre: "{Nombre Legible}"
    path: "shared/catalog/{nombre}/"
    alias: "@CATALOG_{ALIAS}"
    estado: "production-ready"
    origen: "projects/{proyecto}"
    version: "1.0.0"
    stack:
      - "NestJS"
      - "{otras tecnologías}"
    keywords:
      - "{keyword1}"
      - "{keyword2}"
      - "{keyword3}"
    caracteristicas:
      - "{característica 1}"
      - "{característica 2}"
    dependencias_npm:
      - "{paquete}"
    tablas_requeridas:
      - "{schema}.{tabla}"

IMPORTANTE: Las keywords son críticas para que la funcionalidad sea encontrable por grep.

Paso 5: Actualizar shared/catalog/README.md

Agregar fila en la tabla de "Estado Actual":

| {nombre} | 🟢 Production-Ready | {Origen} | {Stack Principal} |

Paso 6: Actualizar ALIASES.yml

# Agregar en sección de catálogo
@CATALOG_{ALIAS}: "shared/catalog/{nombre}/"

Paso 7: Validar

# Verificar que grep encuentra la funcionalidad
grep -i "{keyword}" shared/catalog/CATALOG-INDEX.yml

# Verificar estructura completa
ls -la shared/catalog/{nombre}/
# Debe mostrar: README.md, IMPLEMENTATION.md

# Verificar alias en documentación
grep "@CATALOG_{ALIAS}" shared/catalog/README.md

Actualizar Funcionalidad Existente

Cuando el código mejore en un proyecto:

1. ¿El cambio es generalizable (beneficia a todos)?
   - SÍ → Actualizar catálogo
   - NO → Mantener como adaptación local

2. Si actualizar:
   - Modificar IMPLEMENTATION.md con nuevos pasos
   - Incrementar versión en README.md
   - Actualizar CATALOG-INDEX.yml (version, caracteristicas)
   - Documentar cambio en historial

Deprecar Funcionalidad

Si una funcionalidad ya no es recomendada:

1. Marcar estado como "⚠️ Deprecated" en:
   - README.md de la funcionalidad
   - CATALOG-INDEX.yml (estado: "deprecated")
   - shared/catalog/README.md (tabla de estado)

2. Documentar:
   - Razón de deprecación
   - Alternativa recomendada

3. NO eliminar inmediatamente
   - Mantener por al menos 2 versiones mayores del catálogo

QUÉ NO HACER

❌ NO agregar funcionalidad sin tests
   → El catálogo es para código PROBADO

❌ NO documentar a medias
   → README incompleto = nadie lo usará

❌ NO olvidar actualizar CATALOG-INDEX.yml
   → Sin index, la funcionalidad no es encontrable

❌ NO usar código específico de negocio
   → Solo funcionalidades técnicas genéricas

❌ NO copiar código con secretos/credenciales
   → Usar variables de entorno siempre

INTEGRACIÓN CON DIRECTIVAS SIMCO

Esta directiva se integra con:

Directiva Relación
@REUTILIZAR Consultar catálogo ANTES de implementar
@CREAR Si no existe en catálogo, crear nuevo
@DOCUMENTAR Documentar también para posible contribución
@VALIDAR Todo código de catálogo debe pasar build/lint

REFERENCIAS

  • Catálogo completo: @CATALOG (shared/catalog/)
  • Índice de búsqueda: @CATALOG_INDEX
  • Para reutilizar: @REUTILIZAR (SIMCO-REUTILIZAR.md)
  • Alias disponibles: @ALIASES (core/orchestration/referencias/ALIASES.yml)

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