workspace-v1/orchestration/directivas/simco/SIMCO-SERVICE-DESCRIPTOR.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

8.0 KiB

SIMCO-SERVICE-DESCRIPTOR: Directiva de Contratos de Servicio

Version: 1.0.0 Sistema: SIMCO v2 - Workspace v1 Responsable: Todos los agentes Fecha: 2025-12-18


PROPOSITO

El Service Descriptor (service.descriptor.yml) es el contrato universal que define completamente un servicio. Esta directiva establece cuando, como y por que usar service descriptors.


PRINCIPIO FUNDAMENTAL

Los agentes dejan de "inferir" y empiezan a "leer contrato".

Toda informacion sobre un servicio debe estar en su service.descriptor.yml


1. REGLA FUNDAMENTAL

TODO servicio DEBE tener un service.descriptor.yml en su raiz.

Ubicacion: {proyecto}/apps/{servicio}/service.descriptor.yml

Ejemplos:
- gamilit-platform/apps/backend/service.descriptor.yml
- gamilit-platform/apps/frontend/service.descriptor.yml
- erp-suite/apps/erp-core/backend/service.descriptor.yml
- erp-suite/apps/verticales/construccion/backend/service.descriptor.yml

2. CUANDO CREAR

2.1 Al crear nuevo servicio

TRIGGER: Creacion de nuevo backend, frontend, ML service, etc.

PASOS:
1. Crear carpeta del servicio
2. INMEDIATAMENTE crear service.descriptor.yml
3. Completar campos obligatorios
4. Verificar referencias a registries
5. Luego proceder con codigo

2.2 Al migrar servicio existente

TRIGGER: Migracion de workspace actual a workspace-v1

PASOS:
1. Analizar servicio existente
2. Identificar puerto, BD, dependencias
3. Verificar que esten en registries (o agregar)
4. Crear service.descriptor.yml con datos reales
5. Validar con validate-service-descriptors.sh

3. CAMPOS OBLIGATORIOS

3.1 Seccion service

service:
  name: "string"        # Nombre unico (kebab-case)
  type: "string"        # backend | frontend | database | ml | worker
  runtime: "string"     # node | python | go | static
  version: "string"     # SemVer (1.0.0)
  description: "string" # Descripcion breve
  owner_agent: "string" # NEXUS-BACKEND | NEXUS-FRONTEND | etc

3.2 Seccion repository

repository:
  name: "string"        # Nombre del repo
  path: "string"        # Path relativo al servicio
  main_branch: "string" # main | master

3.3 Seccion ports

ports:
  internal: number      # Puerto interno (3000, 3001, etc)
  registry_ref: "string" # Referencia al registry (projects.gamilit.api)
  protocol: "string"    # http | https | ws | grpc

3.4 Seccion environments

environments:
  deployed_to:          # Lista de ambientes
    - "local"
    - "development"
    - "production"
  default: "string"     # Ambiente por defecto

4. CAMPOS OPCIONALES

4.1 Seccion domains

domains:
  registry_ref: "string"  # Referencia a domains.registry
  overrides:              # Overrides por ambiente
    local: "string"
    development: "string"

4.2 Seccion database

database:
  registry_ref: "string"  # Referencia a databases.registry
  role: "string"          # runtime | migrator | owner
  schemas:
    - "string"            # Lista de schemas

4.3 Seccion healthcheck

healthcheck:
  path: "string"          # /health
  interval: "string"      # 30s
  timeout: "string"       # 5s
  retries: number         # 3

4.4 Seccion dependencies

dependencies:
  services:               # Otros servicios
    - name: "string"
      required: boolean
      healthcheck: "string"
  databases:
    - "string"            # Nombres de BD
  external:
    - name: "string"
      url: "string"
      required: boolean

4.5 Seccion ci

ci:
  pipeline: "string"      # Template de pipeline
  tests: boolean
  lint: boolean
  build: boolean
  docker: boolean
  docker_image: "string"
  docker_registry: "string"

5. WORKFLOW DE USO

5.1 Backend-Agent crea servicio

1. Recibe tarea de crear nuevo servicio
2. Verificar puerto disponible en ports.registry.yml
3. Si no disponible: Solicitar a DevOps-Agent
4. Crear service.descriptor.yml con:
   - service.* completado
   - ports.registry_ref apuntando al registro
   - database.registry_ref si usa BD
5. Validar descriptor
6. Proceder con implementacion

5.2 Frontend-Agent crea servicio

1. Recibe tarea de crear frontend
2. Verificar puerto disponible
3. Identificar backend del que depende
4. Crear service.descriptor.yml con:
   - dependencies.services incluyendo backend
   - domains.registry_ref configurado
5. Validar y proceder

5.3 DevOps-Agent hace deployment

1. Recibe solicitud de deployment
2. Leer service.descriptor.yml
3. Validar contra registries
4. Leer ci.* para configurar pipeline
5. Ejecutar pipeline segun flags
6. Si todo OK: Deploy

6. VALIDACION

6.1 Validacion Manual

# Validar un proyecto
./control-plane/devtools/scripts/validation/validate-service-descriptors.sh ./mi-proyecto/

# Salida esperada:
# Validando: ./mi-proyecto/apps/backend/service.descriptor.yml
#   [OK] YAML valido
#   [OK] Todos los campos obligatorios presentes
#   [OK] Referencias a registries validas

6.2 Validacion en CI

# En pipeline de CI:
- name: Validate Service Descriptors
  run: |
    ./control-plane/devtools/scripts/validation/validate-service-descriptors.sh .    

6.3 Errores Comunes

Error Causa Solucion
"Campo obligatorio faltante" Falta service.name, etc Completar campo
"YAML invalido" Sintaxis incorrecta Verificar indentacion
"registry_ref no existe" Referencia a puerto no registrado Agregar a registry primero
"Puerto no coincide" internal != registry Sincronizar valores

7. CUANDO ACTUALIZAR

7.1 Cambio de Puerto

1. Verificar nuevo puerto disponible en registry
2. Actualizar ports.registry.yml
3. Actualizar service.descriptor.yml ports.internal
4. Actualizar docker-compose.yml
5. Validar

7.2 Cambio de BD

1. Verificar nueva BD en databases.registry.yml
2. Actualizar service.descriptor.yml database.registry_ref
3. Actualizar variables de entorno
4. Validar

7.3 Nueva Dependencia

1. Identificar servicio del que se depende
2. Agregar a dependencies.services
3. Agregar healthcheck del servicio
4. Actualizar docker-compose depends_on

7.4 Cualquier Cambio

SIEMPRE:
1. Actualizar metadata.updated con fecha actual
2. Incrementar service.version si es cambio significativo
3. Ejecutar validacion

8. TEMPLATE

Ver template completo en:

control-plane/orchestration/templates/service-descriptor/SERVICE-DESCRIPTOR-TEMPLATE.yml

Ejemplo Minimo (Backend)

service:
  name: "mi-api"
  type: "backend"
  runtime: "node"
  version: "1.0.0"
  description: "API de mi servicio"
  owner_agent: "NEXUS-BACKEND"

repository:
  name: "mi-proyecto"
  path: "apps/backend"
  main_branch: "main"

ports:
  internal: 3000
  registry_ref: "projects.mi_proyecto.api"
  protocol: "http"

environments:
  deployed_to: ["local", "development", "production"]
  default: "local"

healthcheck:
  path: "/health"

ci:
  tests: true
  build: true
  docker: true

Ejemplo Minimo (Frontend)

service:
  name: "mi-web"
  type: "frontend"
  runtime: "static"
  version: "1.0.0"
  description: "Frontend web"
  owner_agent: "NEXUS-FRONTEND"

repository:
  name: "mi-proyecto"
  path: "apps/frontend"
  main_branch: "main"

ports:
  internal: 3001
  registry_ref: "projects.mi_proyecto.web"
  protocol: "http"

environments:
  deployed_to: ["local", "development", "production"]
  default: "local"

dependencies:
  services:
    - name: "mi-api"
      required: true

ci:
  build: true
  docker: true

9. INTEGRACION CON SIMCO

Referencias desde otras directivas

SIMCO-INICIALIZACION:
  - Cargar service.descriptor.yml como parte del contexto

SIMCO-CREAR:
  - Crear service.descriptor.yml ANTES de crear codigo

SIMCO-VALIDAR:
  - Incluir validacion de service.descriptor.yml

SIMCO-DEVOPS:
  - Leer service.descriptor.yml para deployment

Directiva mantenida por: Tech-Leader Ultima actualizacion: 2025-12-18