6 ARQUITECTURA FINAL

SECCIÓN 6: ARQUITECTURA FINAL DEL GRUPO
Arquitectura Ontológica Mínima (Solo Entidades Estrictamente Necesarias)
El núcleo se reduce a 5 tablas fundacionales, sin tablas auxiliares, historiales paralelos o logs duplicados:

-- Tabla madre: única fuente de identidad, sin nombres en texto plano para evitar fugas
::t_madre::miembros:: (
  uuid PRIMARY KEY,
  nombre_hash,
  datos_biometricos_hash,
  estado,
  membresia_universalis,
  antiguedad,
  created_at,
  version_registro INTEGER DEFAULT 1 -- Para control de concurrencia optimista
)

-- Tabla única de inventario: todos los activos físicos y lógicos
::t_inventario::unico:: (
  uuid PRIMARY KEY,
  tipo,
  modelo,
  ubicacion_geo,
  nodo_asignado_uuid FK → ::t_nodos::red::,
  responsable_uuid FK → ::t_madre::miembros::,
  estado_operativo,
  version_registro INTEGER DEFAULT 1
)

-- Tabla de cartera de proyectos: entidad central de operaciones
::t_proyectos::cartera:: (
  uuid PRIMARY KEY,
  nombre_hash,
  tipo,
  nodo_origen_uuid FK → ::t_nodos::red::,
  saldo_total,
  estado_financiero,
  moneda_base,
  dependencias JSONB, -- Array de {uuid_proyecto, tipo, peso, estado} para relaciones entre proyectos, sin tabla separada
  version_registro INTEGER DEFAULT 1
)

-- Tabla de nodos de la red: jerarquía territorial
::t_nodos::red:: (
  uuid PRIMARY KEY,
  nombre_hash,
  tipo ENUM('sede_maxima', 'sede_regional', 'enclave'),
  ubicacion_geo,
  estado_conexion,
  capacidad_procesamiento,
  pais CHAR(2),
  moneda_local CHAR(3),
  normativa_contable VARCHAR(32),
  idioma_local CHAR(5),
  version_registro INTEGER DEFAULT 1
)

-- Tabla única de libro mayor + auditoría viva: todo en un solo lugar, sin duplicidad
::t_libro::unico:: (
  uuid_evento PRIMARY KEY,
  timestamp,
  uuid_actor FK → ::t_madre::miembros::,
  tipo_operacion ENUM('asiento_contable', 'evento_ciber', 'modificacion_inventario', 
                       'modificacion_miembro', 'modificacion_proyecto', 
                       'modificacion_nodo', 'checkpoint_backup', 
                       'transferencia_recursos', 'pago_directo_nodo'),
  uuid_entidad_afectada,
  uuid_nodo_origen FK → ::t_nodos::red::,
  pais_transaccion CHAR(2),
  moneda_transaccion CHAR(3),
  datos_adicionales JSONB, -- Almacena el detalle de la operación: monto, valores anteriores/nuevos, payload de la operación
  hash_cadena CHAR(64), -- Hash que encadena con el registro anterior para integridad inmutable
  firma_digital,
  INDEX(idx_uuid_entidad, uuid_entidad_afectada),
  INDEX(idx_timestamp, timestamp),
  INDEX(idx_tipo_operacion, tipo_operacion),
  INDEX(idx_pais_transaccion, pais_transaccion),
  INDEX(idx_nodo_origen, uuid_nodo_origen)
)

No hay más tablas en el núcleo ontológico. Toda la funcionalidad de RH, finanzas, logística, ciberseguridad y proyecciones se construye sobre estas 5 tablas, usando claves foráneas y consultas filtradas.

Mecanismos de Consistencia y Resiliencia (Sin Complejidad Adicional)
Control de Concurrencia Optimista por Hash: En lugar de versiones por dominio, usamos un solo campo version_registro y un hash_del_registro por entidad. Cualquier operación de actualización incluye la condición WHERE uuid = X AND version = Y AND hash_del_registro = Z. Si el hash no coincide, se genera un conflicto que se resuelve automáticamente por el ::motor::sincronia:: o se marca para revisión humana en el ::bastion::universalis::. No hay bloqueos, la concurrencia es máxima.

Sincronización de Enclaves con Patrón Outbox Nativo: Los enclaves con conexión intermitente usan el patrón Transactional Outbox en su base de datos local (SQLite): cualquier operación se escribe en la tabla operativa local y en una tabla de outbox en la misma transacción. Al reconectarse por ::nexus::universalis::, el motor de sincronización envía los eventos del outbox en orden cronológico, y limpia la cola solo tras confirmación de la ::sede::maxima::. No se añade ninguna tabla al núcleo ontológico, es un componente de infraestructura separado.

Integración de ::mayan::mapper:: sin tablas adicionales: El mapeo estructural de capas L0-L10 se guarda como configuración distribuida sincronizada por ::nexus::universalis::. Los activos físicos (sensores, chips, lectores) y lógicos (firmware, controladores) se registran en ::t_inventario::unico:: con el tipo hardware_mapeo o software_mapeo, y la capa a la que pertenecen se guarda en el campo datos_adicionales. No requiere tablas propias en el núcleo.

Flujo Operativo de Ejemplo (Demostración de Funcionalidad Sin Duplicidad)
Un miembro ingresa por primera vez: Se registra una sola vez en ::t_madre::miembros::, se genera su uuid y su expediente de RH se enlaza automáticamente por ese uuid, sin registros duplicados.

RH asigna el miembro a un proyecto: Se genera un evento en ::t_libro::unico:: con tipo_operacion = asignacion_rh, y se registra la imputación de horas directamente en el campo de costos del proyecto, sin necesidad de una tabla intermedia.

El miembro registra 10 horas de trabajo: Se genera un evento en ::t_libro::unico:: con tipo_operacion = asiento_contable, con el monto calculado automáticamente por el costo hora del miembro, sin intervención de Finanzas.

Se traslada un servidor de Veracruz a Oaxaca: Se actualiza el campo nodo_asignado_uuid en ::t_inventario::unico::, se genera un evento en ::t_libro::unico:: con tipo_operacion = modificacion_inventario, con el valor anterior y nuevo de la ubicación, y el responsable del traslado. No se necesita una tabla de movimientos separada.

El ::motor::sincronia:: detecta que Oaxaca tiene superávit de servidores y Veracruz déficit: Genera una alerta en ::bastion::universalis:: con la sugerencia de traslado, registrada en ::t_libro::unico:: con tipo_operacion = sugerencia_transferencia.

El comandante autoriza la transferencia: Se genera un evento en ::t_libro::unico:: con tipo_operacion = transferencia_recursos, con el detalle de los activos trasladados, los responsables y la justificación. Todo el flujo es trazable en tiempo real, sin reportes separados.