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

1.6 KiB

Raw Permalink Blame History

ADR-003: Multi-Tenancy Schema-Level

Estado: Aceptada
Fecha: 2025-11-23
Responsable: Architecture-Analyst

Contexto

El ERP Genérico debe soportar múltiples empresas/tenants con:

Aislamiento de datos seguro
Performance óptimo
Escalabilidad

Decisión

Schema-Level Isolation: Cada tenant tiene su propio schema PostgreSQL.

-- Tenant 1
CREATE SCHEMA tenant_abc;
-- Tenant 2
CREATE SCHEMA tenant_xyz;

Justificación

Referencia a Gamilit

Gamilit usa multi-schema para separar dominios
Permisos granulares por schema
Backups selectivos por tenant

Referencia a Odoo

Odoo usa company_id en todas las tablas (row-level)
Schema-level es más seguro y performante

Consecuencias

Positivas

Aislamiento completo (seguridad máxima)
Backups/restore por tenant
Migrations por tenant
Performance (no filtros WHERE company_id)

Negativas

Complejidad en gestión de schemas
Requiere lógica de routing por tenant

Alternativas Consideradas

1. Row-Level (column tenant_id)

Rechazada: Menor seguridad, queries más lentas

2. Database por tenant

Rechazada: Overhead de conexiones, difícil mantenimiento

Implementación

Acciones Requeridas

Función get_tenant_schema()
Middleware de routing por tenant
RLS policies por tenant

Criterios de Aceptación

Usuario de tenant A no puede ver datos de tenant B
Performance igual que single-tenant

1.6 KiB Raw Permalink Blame History