# Panel de Gestión de Bases de Datos (SvelteKit Migration)

Este proyecto es una migración moderna del panel de control legacy `TransmitirAS`, reconstruido utilizando **SvelteKit 2.0** y **Svelte 5 (Runes)**.

## Características

- **Tech Stack**: SvelteKit, TypeScript, Node.js (MSSQL), Bootstrap 5.
- **Server-Side Rendering (SSR)**: Todos los datos se cargan en el servidor para una carga inicial rápida y SEO/Performance óptimo.
- **Base de Datos**: Conexión a múltiples instancias SQL Server (Local, Remota, Azure).
- **Diseño**: Interfaz "Glassmorphism" portada fielmente del original.

## Requisitos Previos

- **Node.js**: v18 o superior.
- **SQL Server**: Acceso a las instancias de base de datos definidas en `.env`.

```bash
docker build \
  -t dev.aduanasoft.com:8443/databases_a24c/frontend:latest \
  -f ./Dockerfile \
  ./
```

Subirlas a harbor

```
docker login dev.aduanasoft.com:8443
docker push dev.aduanasoft.com:8443/databases_a24c/frontend:latest
```

## Configuración

1.  **Instalar dependencias**:
    ```bash
    npm install
    ```

2.  **Variables de Entorno**:
    El archivo `.env` ya ha sido configurado con las credenciales migradas. Asegúrese de que la máquina donde se ejecuta esto tenga acceso de red a las IPs:
    - 192.168.1.200 (Primaria)
    - 104.192.7.202 (Secundaria)
    - aduanasoft.database.windows.net (Azure)

3.  **Ejecutar en Desarrollo**:
    ```bash
    npm run dev
    ```
    Abrir [http://localhost:5173](http://localhost:5173) en el navegador.

4.  **Construir para Producción**:
    ```bash
    npm run build
    npm run preview
    ```

## Estructura del Proyecto

- `src/lib/server/db.ts`: Lógica de conexión a base de datos (Pools).
- `src/routes/+page.server.ts`: Controlador principal. Realiza todas las consultas SQL y lectura de archivos antes de renderizar.
- `src/routes/+page.svelte`: Vista principal. Gestiona la navegación por pestañas y tablas.
- `src/lib/components/`: Componentes reutilizables (`Navbar`, `Sidebar`).
- `src/app.css`: Estilos globales y tema Glass.

## Integración CloudRestoreAS

- Endpoints servicio-a-servicio bajo `/api/restore/` (token `CLOUDRESTORE_API_TOKEN` en `.env`).
- **Servidores de Restauración** (`/servidores-restauracion`): admin de Alfa/Omega/Gamma y carpeta de entrada reportada por CloudRestoreAS (solo lectura).
- Contrato y prueba local: ver `INTEGRACION_PANEL.md` en el repo CloudRecoveryAS (mismo token en `CLOUDRESTORE_API_TOKEN` y en la config PANEL de CloudRestoreAS).

### Versiones CRAS (`/versiones-cras`) — instalación y actualización remota

Distribución de los binarios del agente. Los artefactos se publican en el registro de
paquetes **genéricos de Gitea** desde el build local del repo CloudRecoveryAS
(`build-all.sh --publish`); el panel los descubre leyendo esa API y los despliega por SSH.

```
build local (WSL)  →  Gitea: ADUANASOFT/generic/cloudrestoreas/<version>
                          ↓  (el panel lee la API y guarda metadatos + sha256)
                      a24c.cras_releases  →  caché en CRAS_RELEASES_DIR
                          ↓  (SFTP + exec)
                      servidor de restauración
```

Flujo de operación:

1. **Sincronizar con Gitea** — registra las versiones publicadas en `a24c.cras_releases`.
   Nunca activa nada por su cuenta: publicar no debe equivaler a desplegar.
2. **Activar** — marca la versión que se instalará, **una por plataforma+arquitectura**
   (índice único parcial en la BD, para que Windows y Linux tengan cada una la suya).
3. **Precargar** *(opcional)* — descarga y verifica el artefacto antes de instalar, para
   separar el tiempo de descarga del de instalación.
4. **Instalar / Actualizar** por servidor — sube el paquete por SFTP, **verifica el sha256 en
   el destino**, corre el instalador que viene dentro del paquete y siembra `config/.env` con
   la URL, el token y la instancia: el servidor queda operativo sin configuración manual.

Detalles que importan:

- Los binarios **no** se guardan en Postgres (pesan ~270 MB); la BD solo tiene metadatos.
- El servidor destino **no descarga nada de internet**: el binario es autocontenido.
- El token del panel viaja al destino en un archivo `0600` por SFTP, **nunca como argumento
  de un comando** (sería visible en `ps` y en el historial del servidor).
- Se exige **root o `sudo -n`** en Linux (y cuenta administradora en Windows), validado
  *antes* de transferir el artefacto. No se le pasa la contraseña a `sudo`.
- El progreso se persiste paso a paso en `a24c.cras_install_runs.steps`; la UI lo consulta
  por polling en `/versiones-cras/install-runs`.
- No hay subida de archivos por el navegador a propósito: la fuente de verdad es Gitea.

Variables nuevas en `.env`: `GITEA_BASE_URL`, `GITEA_OWNER`, `GITEA_TOKEN`
(scope `read:package`), `CRAS_PACKAGE_NAME`, `CRAS_RELEASES_DIR`,
`CRAS_CACHE_KEEP_VERSIONS`, `PANEL_PUBLIC_URL`. Ver `.env.example`.

Esquema: migración `e2f3a4b5c6d7` en el repo a24c (autoritativa), replicada en
`database/schema.sql` y en el fallback `ensureCrasSchema()` de `cras-releases.ts`.

## Notas de Migración

- **DataTables**: Se inicializan en el cliente dentro de `onMount` para mantener la compatibilidad con las tablas interactivas originales.
- **Sistema de Archivos**: La lectura de backups busca en `BACKUP_PATH` en el servidor donde corre Node.js (independiente de la carpeta que vigila CloudRestoreAS).