Adrian Flores Cortes 967ab360bb Initial commit: Workspace v1 with 3-layer architecture

Structure:
- control-plane/: Registries, SIMCO directives, CI/CD templates
- projects/: Gamilit, ERP-Suite, Trading-Platform, Betting-Analytics
- shared/: Libs catalog, knowledge-base

Key features:
- Centralized port, domain, database, and service registries
- 23 SIMCO directives + 6 fundamental principles
- NEXUS agent profiles with delegation rules
- Validation scripts for workspace integrity
- Dockerfiles for all services
- Path aliases for quick reference

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

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

2025-12-23 00:35:19 -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