Índice · Cómo está hecho

Más

Cómo está hecho

Las decisiones técnicas que sostienen el programa, para quien quiera mirar debajo. La idea que lo atraviesa todo: si el programa afirma algo del almacén, tiene que poder demostrarlo.

Las piezas

QuéCon qué
AplicaciónNext.js 16 (App Router), React 19 y TypeScript, con Tailwind CSS.
DatosPostgreSQL (Neon) con Prisma.
Almacén en 3Dthree.js con react-three-fiber.
Accesonext-auth, con permisos por papel (operario, jefe de almacén, administrador) en un solo sitio.
Idiomasnext-intl: español, inglés y árabe.
IAUn modelo por API compatible con OpenAI (DeepSeek en la demo), y un servidor MCP con OAuth 2.1 propio.
DespliegueDokploy en un servidor propio, detrás de Cloudflare.

Principios

Una sola puerta para cada cosa

Todo lo que cambia el stock pasa por un único módulo, con transacciones serializables y reintentos. Lo mismo el estado de un pedido y la facturación. Nació de un fallo real: cuando dos pantallas cambiaban el estado de un pedido cada una por su cuenta, un pedido ya enviado volvía a aparecer en la cola de preparación. Desde entonces, cada cosa se cambia en un solo sitio.

Un registro que se puede comprobar

El stock es un libro de movimientos: la unidad es la caja, y cada palet sabe dónde está. El «cuadre» comprueba que el libro, los palets y el stock coinciden, y además que cada estado dice la verdad: un pedido enviado tiene sus salidas apuntadas, uno confirmado tiene sus reservas y uno preparado tiene sus palets en la zona de carga.

La IA usa las mismas acciones

Las herramientas del agente y del servidor MCP son envoltorios finos sobre esas mismas acciones: no hay reglas propias de la IA. Se escriben una sola vez y las usan el agente del panel y las IA externas. Devuelven totales ya calculados y las unidades en el nombre de cada dato, porque si un modelo tiene que sumar o adivinar unidades, se equivoca.

Identificar las cosas como las identifica el almacén

Lo que lleva etiqueta física (una máquina, una posición, un pedido) se identifica por su código visible, no por el identificador interno de la base de datos. Así un QR impreso sigue funcionando aunque se regeneren los datos.

Pruebas

Hay 34 baterías de pruebas que se lanzan con una sola orden, y siempre terminan con dos comprobaciones permanentes: el cuadre del stock y la verificación de la cadena de VeriFactu. Incluyen casos de concurrencia (dos personas reservando lo mismo a la vez) y una prueba que vigila que ninguna dirección de la API quede abierta sin comprobar quién llama.

Una demo que no miente y no envejece

Los datos de la demo no se insertan en la base de datos: un generador opera el programa durante un año simulado, comprando, vendiendo, preparando y facturando por las mismas puertas que una persona. Por eso que el cuadre salga bien equivale a una prueba de integración de todo el sistema. El generador encontró un fallo real: una alerta de stock mínimo que descontaba dos veces las cajas reservadas.

Cada 24 horas la demo vuelve a su estado inicial, y al hacerlo desplaza las fechas para que la actividad siga siendo de los últimos meses: los mapas de calor, el consumo medio y la rotura prevista siguen teniendo datos por antigua que sea la foto.

Seguridad

  • Cada dirección de la API comprueba la sesión y el papel de quien llama, y una prueba automática lo vigila.
  • Los datos de un cliente nunca salen enteros: solo los que se imprimen en un documento.
  • Las contraseñas se guardan cifradas, y las claves y los permisos de las IA, solo como huella SHA-256.
  • Un agente de IA nunca tiene nivel de administrador, y todo lo que mueve queda firmado.

Asistente LumiWare

Siempre disponible para ayudarte