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

2.3 KiB

Raw Blame History

ADR-003: Multi-Tenancy Schema-Level

Estado: Aceptada Fecha: 2025-11-24 Responsable: Architecture-Analyst Proyecto: ERP Construccion

Contexto

El ERP de Construccion debe soportar multiples empresas constructoras/tenants con:

Aislamiento de datos seguro (proyectos, presupuestos, INFONAVIT)
Performance optimo para grandes volumenes de datos
Escalabilidad para multiples desarrollos inmobiliarios
Cumplimiento regulatorio (INFONAVIT requiere aislamiento)

Decision

Schema-Level Isolation: Cada tenant (empresa constructora) tiene su propio schema PostgreSQL.

-- Constructora ABC
CREATE SCHEMA tenant_constructora_abc;
-- Desarrolladora XYZ
CREATE SCHEMA tenant_desarrolladora_xyz;

Justificacion

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 mas seguro y performante para construccion

Alineacion con ERP Generico

Misma estrategia de multi-tenancy
Migracion de datos sencilla

Especifico para Construccion

Proyectos INFONAVIT requieren aislamiento total
Cada fraccionamiento puede ser un tenant diferente
Auditorias de INFONAVIT facilitan con backups por tenant

Consecuencias

Positivas

Aislamiento completo (seguridad maxima)
Backups/restore por constructora
Migrations por tenant
Performance (no filtros WHERE company_id)
Cumplimiento INFONAVIT

Negativas

Complejidad en gestion de schemas
Requiere logica de routing por tenant

Alternativas Consideradas

1. Row-Level (column tenant_id)

Rechazada: Menor seguridad, no cumple INFONAVIT

2. Database por tenant

Rechazada: Overhead de conexiones, dificil mantenimiento

Implementacion

Acciones Requeridas

Funcion get_tenant_schema()
Middleware de routing por tenant
RLS policies por tenant
Scripts de creacion de tenant para INFONAVIT

Criterios de Aceptacion

Usuario de Constructora A no puede ver datos de Constructora B
Performance igual que single-tenant
Auditorias INFONAVIT por tenant funcionales

2.3 KiB Raw Blame History