Saltar a contenido

Gerege Nexus

Gerege Eco System · Plataforma privada

Gerege Nexus conecta las organizaciones, servicios y usuarios de Gerege Eco System. Solo pueden acceder los usuarios autorizados previamente. eID verifica la identidad; los administradores de la organización conceden el acceso.

Gerege Nexus es la base formada por un backend en Go, un web shell en Next.js, una base de datos PostgreSQL, un control plane de operador y clientes nativos. Las aplicaciones de negocio las añaden los repositorios de distribución como módulos Go en tiempo de compilación. Este repositorio base no es un paquete ERP listo para todos los sectores.

Alcance real (2026-10-25): catalog/apps.json está vacío: el núcleo no incluye ninguna app de negocio; cada app llega desde el catálogo de una distribución. La última aplicación, io.gerege.nexus.sso_clients, salió el 2026-08-25 a appstore-gerege-nexus, y cualquier distribución la descarga desde la tienda de aplicaciones. Puede que en este repositorio queden el historial de migraciones o las traducciones de frontend de aplicaciones como contacts, products, inventory, billing, documents, government workflow o clientes SSO, pero sus módulos ejecutables no están en este binario base. Las rutas de esas aplicaciones no se abren en este deployment.

Монгол  ·  العربية  ·  中文  ·  English  ·  Français  ·  Русский  ·  Español

Go Version Next.js CI

Qué contiene exactamente este repositorio

Parte Implementación actual
Tenant plane Autenticación, sesión, tenant membership, RBAC, perfil, instalación/desinstalación de aplicaciones, AI API, dispositivos, verificación de correo electrónico, SSO client/provider, motor de informes
Operator plane Ciclo de vida del inquilino, inicio de sesión TOTP del operador, auditoría, soporte, quota/metering, feature flags, runtime settings/credentials, anuncios, gestión de backup/deploy
Aplicación integrada Ninguna. Cada aplicación llega por el catálogo; tras la salida de sso_clients el 2026-08-25, este binario no contiene ninguna aplicación de negocio
Web Landing pública, login/setup, perfil, tienda de aplicaciones, ajustes, control plane, todo sobre @gerege-systems/ui (Tailwind 4); las pantallas de aplicaciones (clientes SSO, documentos, contactos) permanecen en el shell sin vida, sin su módulo
Native Shell para macOS, iOS/iPadOS, Windows y Android; PWA en Linux
Observability /health, /ready, /metrics, log estructurado, OTLP/Sentry opcional; compose de monitoring separado

Que existan rutas, tablas o servicios de la plataforma base no significa que haya necesariamente una aplicación de negocio visible para el usuario. Las rutas de un módulo solo funcionan cuando el módulo de compilación implementa el contrato de pkg/nexus, está registrado en el binario, figura en el catálogo y está instalado en el inquilino correspondiente.

Lo que no está en este binario base

  • Las aplicaciones de negocio contacts, products, inventory y billing
  • La aplicación de departamentos/empleados de Organisation & People (en cambio, el perfil legal de la organización sigue siendo parte de la plataforma en /organisation)
  • El módulo backend de Documents y la UI de informes. En este repositorio existe un cliente frontend opcional de contract/inbox, pero la contract API correspondiente aún no está ni en la base actual ni en la distribución client-gerege-nexus; si el endpoint no responde de verdad, su enlace no aparece en la landing
  • La UI/módulo de workflow de servicios gubernamentales
  • La estación completa: panel, canales, peer/exchange API, contrato de sobres. El 2026-08-27 su última parte se trasladó a client-gerege-nexus
  • Conectores y webhooks de sistemas externos (Google Drive, Dropbox, Meet, URL del cliente). También salieron el 2026-08-27; en el núcleo solo queda el cifrado que sella las credenciales (nexus.SecretSealer). El envío automático al exterior de documentos firmados también se retiró del núcleo
  • Circuit breaker adaptativo general, singleflight, motor de reintentos genérico

Parte de esto se separó en repositorios de distribución de producto. Consulte docs/MODULES.md para ver cómo se escribe un módulo y cómo llega por el catálogo, docs/DISTRIBUTION.md para ver cómo una distribución obtiene y actualiza el núcleo, y docs/ARCHITECTURE.md para la arquitectura actual.

Capacidades principales

  • SDK de módulos en tiempo de compilación: contratos de route, permission, menu, dependency, migration, report, AI tool y capability.
  • App installation y control RBAC por inquilino. Las rutas de un módulo no instalado o deshabilitado devuelven 403.
  • Catálogo local o catálogo remoto firmado con Ed25519; cache fallback y sincronización manual/en segundo plano.
  • Inicio de sesión con contraseña, eID, DAN, Google y OIDC upstream; además, proveedor OAuth2/OIDC.
  • Esquemas workspace, registry y operator de PostgreSQL, con protección RLS/roles.
  • Con Redis configurado, invalidación de caché y rate limit compartido entre réplicas; sin configurarlo, fallback de un solo proceso.
  • Load shedding de solicitudes concurrentes. Cada cliente externo tiene su propia política de timeout/retry; no se da por hecho que la plataforma tenga un circuit breaker genérico que no existe.
  • Con una clave de Gemini: chat, speech-to-text, text-to-speech y traducción. Las AI tools sobre datos de negocio las registra el propio módulo de distribución; el deployment base no inventa ni devuelve cifras de inventory o billing.
  • Sistema de diseño: el web shell y la consola se basan en @gerege-systems/ui, y la única fuente de tokens es el theme.css de la biblioteca. Cada deployment cambia su apariencia sin tocar el código, mediante las variables de entorno BRAND_THEME_* y el CSS de «Get code» de ui.gecore.mn/#theme (DEVELOPMENT.md).
  • La plataforma incluye clientes de E-ID, DAN y ХУР. En el entorno production el mock se desactiva por defecto; para usar el servicio real se necesitan las credenciales de cada uno.

Estructura del repositorio

backend/
  cmd/                  herramientas api, migrate, bootstrap, catalog
  db/migrations/        migraciones base de PostgreSQL
  internal/kernel/      mecanismos de bajo nivel comunes a los tres planes
  internal/operator/    deployment/operator plane
  internal/workspace/   plano que actúa en nombre de una organización
  internal/person/      espacio propio de la persona — /api/v1/me
  internal/apps/        punto de ensamblaje de los distribution modules (vacío por ahora)
  pkg/nexus/            SDK público para distribution modules
  pkg/host/             entry point público que arranca un distribution binary
frontend/               Next.js web shell y UI del control plane
catalog/                catálogo base, manifests, chronicle
native-apps/            clientes macOS, iOS/iPadOS, Windows, Android
deploy/                 image, compose, nginx, monitoring
docs/                   índice de documentos actuales, históricos y propuestas

Ejecución

Requisitos previos

  • Docker Compose, o bien
  • Go 1.26+, Node.js 20+, PostgreSQL 16+

Docker Compose

docker compose up -d
docker compose ps

Compose arranca PostgreSQL, Redis, una migración de un solo uso, el backend y el frontend. Use las siguientes direcciones:

Cuenta de demostración de desarrollo:

Campo Valor
Correo admin@example.com
Contraseña Password123!
Tenant Demo Corporation (demo)

SEED_DEMO_DATA está activo por defecto en todos los entornos salvo producción. En producción, la cuenta de demostración no se crea a menos que se indique true de forma explícita.

Manualmente

Primero arranque PostgreSQL (y Redis si hace falta):

cd backend
go mod download
DATABASE_URL="postgres://postgres:postgrespassword@localhost:5432/platform_db?sslmode=disable" \
  go run ./cmd/migrate up

PUBLIC_ORIGIN=http://nexus.localhost:3000 \
ALLOWED_ORIGINS=http://nexus.localhost:3000,http://admin.localhost:3000 \
CONTROL_PLANE_HOST=admin.localhost \
  go run ./cmd/api

En otra terminal:

cd frontend
npm ci
CONTROL_PLANE_HOST=admin.localhost \
NEXT_PUBLIC_API_URL=http://nexus.localhost:8080/api/v1 \
NEXT_PUBLIC_CONTROL_PLANE_API_URL=http://admin.localhost:8080/api/platform/v1 \
  npm run dev

La configuración de producción no se deduce del README. Siga .env.example para todas las variables y sus valores por defecto seguros, proxmox-gerege-net (stack/nexus) para la configuración del despliegue en marcha y docs/OPERATIONS.md para los pasos de creación del primer tenant/operator.

La lista de API del README no es un contrato completo. Las fuentes que se verifican junto con el código son:

Los endpoints públicos base incluyen /health, /ready, /metrics, auth, setup, OAuth2/OIDC, tienda de aplicaciones, device enrollment y verificación de correo electrónico. Las rutas que requieren sesión de tenant, las rutas del control plane y las rutas de módulos tienen cada una su propia protección.

Pruebas

cd backend
go test ./...
go vet ./...

cd ../frontend
npm ci
npm test
npm run lint
npm run build

Además de esto, la CI añade pruebas de carreras con migraciones, límites de API/rutas, PWA, host, informe de translation-gap, Docker build, govulncheck, gosec y la compilación de los clientes nativos. Los comandos exactos que se ejecutan están en .github/workflows/ci.yml, security.yml y native-clients.yml.

Estado de idiomas y documentación

Las cadenas fuente de la UI están en mongol e inglés; existen overlays en árabe, chino, francés, ruso y español. Un overlay incompleto hace fallback al inglés y la CI informa de los huecos; no se promete que todas las pantallas estén traducidas al 100%.

El README está en siete idiomas. No todos los documentos técnicos tienen siete traducciones; el idioma y el estado de cada archivo se indican en docs/README.md. Los archivos llamados PLAN, PROPOSAL, PROMPT o WORKLOG no son el runtime contract actual. No deben usarse por sí solos como fuente para las instrucciones de ejecución.

Seguridad y estado del proyecto

No publique vulnerabilidades en issues públicos; use el procedimiento de private reporting de SECURITY.md.

Proyecto privado. Todos los derechos reservados.