SISTEMA
REKIUM

Sistema Rekium es una plataforma de automatización integral construida desde cero para gestionar el ciclo de vida completo de los miembros de una corporación de EVE Online: desde el primer contacto en Discord hasta la auditoría con IA, pasando por reclutamiento, gestión de personajes, flotas, timers, tickets internos y dashboards analíticos. Todo el sistema usa Discord como interfaz principal — el usuario nunca abandona la app — mientras que el backend orquesta más de una docena de workflows en n8n contra Alliance Auth, Baserow y MariaDB.

Esta documentación describe la arquitectura, los flujos y las decisiones técnicas tomadas. Sirve también como muestra de mi trabajo: arquitectura distribuida, integración entre cinco plataformas heterogéneas, ingeniería de prompts y de errores, decisiones de coste cero y patrones reutilizables.

Toda la infraestructura es self-hosted en NAS y VPS propios. Cero dependencia de SaaS pago. La elección está pensada para minimizar coste recurrente sin sacrificar capacidad de orquestación ni almacenamiento estructurado.

Un único punto de entrada procesa todas las interacciones de Discord. El Cloudflare Worker verifica la firma Ed25519 y responde síncronamente para cumplir el SLA de 3 segundos de Discord. W0 es el dispatcher central que evalúa el custom_id y despacha al sub-workflow correcto vía executeWorkflowTrigger sin esperar respuesta. Este patrón sustituyó a 15 webhooks separados en Cloudflare Worker, simplificando enormemente el mantenimiento.

Cinco etapas en cadena con tres niveles de aprobación y tres ramas de archivo. Diseñado para que el candidato no abandone Discord en ningún momento mientras la corporación mantiene trazabilidad completa: cada paso queda registrado en Baserow y cada decisión queda firmada por su staff correspondiente.

• W1
  Crear Ticket — Anti-duplicados nativo

  Antes de crear el canal busca en la tabla de Reclutamiento si ya existe un ticket abierto para ese usuario (campo Fecha cierre vacío). Si existe, responde efímero con flags: 64 sin crear canal nuevo. Si no, crea canal privado con permisos de roles y envía mensaje de bienvenida que ya incluye el botón cerrar_ticket desde el primer momento.
• W2
  Verificar Personaje — Main + todos los alts

  Query MariaDB con JOIN a través de authentication_userprofile.main_character_id para garantizar que se devuelve el personaje principal, no un alt. GROUP_CONCAT recupera en una sola fila todos los personajes vinculados a la cuenta. Escritura en Baserow vía HTTP PATCH (no nodo nativo) con user_field_names=true y arrays correctos para los campos Link. Splitting de la lista de personajes y creación/actualización de cada uno en la tabla Personajes.
• W3
  Formulario de Solicitud — Modal Discord

  Abre un modal de Discord con campos personalizados. El Cloudflare Worker devuelve type: 9 síncronamente — esto no se puede delegar a n8n por el SLA de Discord. Las respuestas se guardan en la tabla de Reclutamiento y se notifica al canal del ticket.
• W4
  Aprobación — Cadena de tres etapas

  Votación escalonada: Reclutadores → Asuntos Internos → Directores. Cada etapa solo desbloquea la siguiente cuando se aprueba. Informe de auditoría auto-publicado en el canal permanente de Asuntos Internos. W4b se activa opcionalmente para checklist interactivo con resumen del candidato extraído de MariaDB.
• W4b
  Auditoría IA — Checklist interactivo

  Genera informe automático del candidato a partir de datos de MariaDB (ISK, SP, kills, capital ships). Los revisores completan un checklist interactivo en Discord desde el canal de Asuntos Internos. La publicación es permanente para auditoría histórica.
• W5
  Cierre — Tres ramas paralelas según tipo de ticket

  Al pulsar el botón de cierre, W5 genera transcripción y captura. La imagen se sube vía HTTP PATCH con JSON.stringify (el nodo nativo Baserow falla con campos de archivo — doble-serializa). Tres ramas paralelas actualizan distintas tablas según origen: Reclutamiento, Director (estado → «Archivado»), IT/Soporte (estado → «Archivado»). El canal de Discord se elimina al finalizar.

Los miembros registran personajes alternativos a través de Discord. A1 guarda el ID del ticket en la tabla Claim — campo crítico para que A2 encuentre la solicitud al aprobar o rechazar. A2 incluye una cadena completa de Claim linking en ambas ramas, garantizando trazabilidad bidireccional.

Ambos tipos de ticket incluyen menú desplegable de selección de tipo antes de crear el canal, sistema de claim para asignación de staff, y se archivan en W5 actualizando estado a «Archivado» en sus respectivas tablas.

F1 abre un modal Discord con tipo de operación predefinido. F2 procesa la respuesta, hace INSERT en la tabla opcalendar de Alliance Auth con LAST_INSERT_ID() para recuperar el ID del evento, y publica un embed con botones de asistencia. Categorías soportadas: PVP, ORE, ICE, Lunar, Gas, Rateo. Los eventos se fuerzan al usuario superadmin para evitar problemas de permisos; el FC real queda almacenado en el campo fc.

Permite a los FCs introducir timers de estructuras directamente desde Discord, sin necesidad de abrir Alliance Auth. Un modal recoge los datos del timer; ST1 publica un mensaje en el canal PVP y simultáneamente inserta el evento en opcalendar con la categoría adecuada — quedando integrado con el resto del calendario corporativo.

• 1
  Trigger desde modal Discord

  El FC pulsa un botón en el canal de timers. Cloudflare Worker responde con type: 9 y abre un modal con campos: estructura, sistema, fecha/hora, tipo de timer (armor/hull/anchor).
• 2
  Validación y publicación

  ST1 valida el formato de fecha (debe ser YYYY-MM-DD estricto, sin prefijo =) y publica un embed enriquecido en el canal PVP con countdown.
• 3
  Inserción en opcalendar

  INSERT directo en MariaDB con categoría «Estructuras PVP» y visibilidad PVP. El evento aparece automáticamente en el calendario corporativo del Auth y se dispara el resto de integraciones aguas abajo.

Tres workflows programados que mantienen el ecosistema saneado sin intervención manual: auditoría de tokens ESI, recordatorios de flota y sincronización semanal de miembros entre Alliance Auth y Baserow.

Grafana conectado directamente a MariaDB de Alliance Auth (read-only) provee dashboards en vivo sobre la actividad de la corporación. El primero ya está en producción; los siguientes están en construcción a medida que se valida el esquema real de cada módulo.

Siete tablas con relaciones bidireccionales modelan todo el dominio. Las relaciones se mantienen mediante campos Link y Lookup; las escrituras de Link usan arrays de IDs y nunca enteros sueltos — el nodo nativo de Baserow falla silenciosamente con esto.

Aprendizajes condensados a lo largo de 18+ meses de iteración en producción. Cada uno surgió de un bug real y una vez identificado dejó de morder.

• FILE
  Campos de archivo Baserow — HTTP PATCH obligatorio

  El nodo nativo Baserow doble-serializa los campos de archivo y los rompe sin error visible. Siempre usar HTTP PATCH con user_field_names=true y JSON.stringify en el body. Nunca usar el nodo Baserow para campos de tipo file.
• LINK
  Campos Link — arrays de IDs, nunca enteros

  El nodo nativo Baserow envía enteros para campos Link. Baserow espera arrays [id]. La escritura falla silenciosamente: el row se actualiza, pero el campo Link queda vacío. Solución: HTTP PATCH con user_field_names=true enviando arrays explícitamente.
• SQL
  MariaDB — JOIN correcto para personaje principal

  El JOIN debe pasar por authentication_userprofile.main_character_id para garantizar que se devuelve el personaje principal y no un alt cualquiera. GROUP_CONCAT es esencial para evitar problemas de múltiples filas en n8n. El campo discord_discorduser.uid es bigint y requiere CAST(... AS UNSIGNED).
• ACK
  Contexto tras nodo ACK Discord

  Después del nodo ACK en sub-workflows, $json apunta a la respuesta del PATCH, no al payload original. Todos los nodos posteriores deben referenciar $('Parsear body').item.json explícitamente.
• CF
  Modales — Cloudflare Worker responde síncronamente

  La apertura de modales (type: 9) debe devolverse directamente desde el Worker. No se puede delegar a n8n por el SLA de 3 segundos de Discord. Usar ctx.waitUntil() para reenviar el payload a n8n tras responder.
• PERM
  Discord — READ_MESSAGE_HISTORY es esencial

  El permiso READ_MESSAGE_HISTORY (65536) es obligatorio para que mensajes ya publicados sean visibles a usuarios que se incorporen al canal. Sin él, los pings de flota no se ven cuando alguien entra después. El allow value correcto es 117760, no 52224.
• FK
  MariaDB — FK chains complejas

  Para limpiezas con múltiples constraints encadenadas, el patrón fiable es SET FOREIGN_KEY_CHECKS = 0 / DELETE / SET FOREIGN_KEY_CHECKS = 1. Más rápido y predecible que reordenar borrados manualmente.
• ESI
  Tokens ESI — refresh masivo sin re-registro

  Tokens marcados como expirados a menudo no están revocados, solo necesitan refresh. Iterar en Django shell con token.refresh() reactiva cientos de tokens sin pedir re-registro a los miembros. El comando esi_refresh_tokens de management no existe en todas las versiones de Auth.
• SYS
  MariaDB — Codename del repo debe coincidir con Ubuntu

  El repo de MariaDB debe usar el codename correcto de Ubuntu (noble para 24.04, no jammy). Un mismatch causó que el paquete se desinstalara durante una actualización y el servicio fallara con dependencias de libaio1.
• DISC
  Discord — Mensajes >4000 chars requieren chunking

  La API rechaza con 400 cualquier content mayor de 4000 caracteres. Para mensajes generados (auditorías, listados de miembros), implementar chunking que respete saltos de línea y separadores semánticos.

Resumen de las habilidades técnicas aplicadas en este sistema. Cada bloque representa un dominio donde he ido del «no sé qué es» al «lo tengo en producción y lo mantengo».