# Arquitectura objetivo incluida en la prueba

```text
                         MU NEXORA WEB
                              |
             +----------------+----------------+
             |                                 |
        NEXORA PLATFORM                    REALM LAYER
             |                                 |
   +---------+----------+               +------+------+
   |         |          |               |             |
Identity   Economy     Admin          Legado       Seasonal
Recovery   Payments    RBAC           DB              DB
Content    Ledger      Audit        Game Data      Game Data
Cron       Plugins     Config       Characters     Characters
Votes      Support                  Guilds         Guilds
```

## Regla de pertenencia

**Platform:** información que pertenece a Nexora como red y no debe duplicarse por cambiar de servidor.

Ejemplos: noticias, plugins, cron, PayPal, vote logs, recovery, RBAC, auditoría, ledger.

**Realm:** información cuya verdad pertenece al GameServer concreto.

Ejemplos: `MEMB_INFO` mientras MU siga autenticando allí, personajes, guilds, resets, inventory, Castle Siege, BattlePass GameServer, KillLog.

## Conexiones lógicas

- `MuOnline` → game DB del realm operativo/activo.
- `Me_MuOnline` → account DB del realm operativo/activo.
- `Platform` → `nexora_platform` cuando está habilitado; fallback compatible al realm mientras se migra.

## Realms

La web ya no necesita condicionales dispersos para decidir Legado/Seasonal. `NexoraRealm` mantiene el contexto y `nexora.realms.php` define las conexiones.

El AdminCP usa un **operational realm** distinto del **account realm**. Un responsable puede operar Seasonal o Legado sin tener que cambiar la sesión del jugador.

## Configuración por realm

`nexoraModuleConfigPath()` busca primero:

```text
includes/config/modules/<modulo>.<realm>.xml
```

y si no existe cae a:

```text
includes/config/modules/<modulo>.xml
```

Así las reglas pueden divergir de forma explícita sin llenar el código de `if legacy / if seasonal`.

## Identidad

Esta build todavía conserva `MEMB_INFO` como credencial de juego por compatibilidad. Sin embargo, recovery, email y administración ya están diseñados para que el siguiente paso pueda ser una identidad Nexora maestra sin romper la autenticación del GameServer.

## Trigger Legado → Seasonal

Durante transición, `NexoraAccountProvisioner` detecta si el trigger ya creó la cuenta secundaria y evita duplicarla. El objetivo final es retirar la doble autoridad y dejar la aplicación como provisionador explícito. El script de desactivación está separado y tiene rollback.
