# Aprovisionamiento de infraestructura (Fase 0)

Scripts para dejar Postgres y Redis listos, en cualquier ambiente (dev local,
staging o producción en Coolify), antes de correr Liquibase o levantar la API.
Ver el plan de migración para el diseño completo: dos bases de datos
(`panels_platform`, `panels_product`) y, dentro de `panels_product`, dos
esquemas (`iam`, `core`).

## Orden de ejecución (Postgres)

Contra el servidor Postgres del ambiente (uno por dev/staging/producción),
como usuario superusuario/admin:

```bash
SUPERUSER_URL="postgresql://postgres:adminpass@HOST:5432/postgres"

# 1. Roles cluster-wide (genera una clave distinta por rol y por ambiente:
#    openssl rand -hex 24). Pasar los valores SIN comillas propias -- el
#    script usa :'var' internamente para escaparlos como literal SQL.
psql "$SUPERUSER_URL" \
  -v platform_owner_pw="..." -v platform_app_pw="..." \
  -v iam_owner_pw="..."      -v iam_app_pw="..." \
  -v core_owner_pw="..."     -v core_app_pw="..." \
  -f 01-roles.sql

# 2. Bases de datos (panels_platform, panels_product)
psql "$SUPERUSER_URL" -f 02-databases.sql

# 3. Privilegios dentro de panels_platform
psql "${SUPERUSER_URL%/postgres}/panels_platform" -f 03-platform-database.sql

# 4. Esquemas + privilegios dentro de panels_product
psql "${SUPERUSER_URL%/postgres}/panels_product" -f 04-product-database.sql
```

Las conexiones que usará la API (secrets por ambiente):

| Secret | Apunta a | Usuario |
|---|---|---|
| `DATABASE_URL_PLATFORM` | `panels_platform` | `panels_platform_app` |
| `DATABASE_URL_IAM` | `panels_product` (search_path=iam) | `panels_iam_app` |
| `DATABASE_URL_CORE` | `panels_product` (search_path=core) | `panels_core_app` |

Liquibase (paso de deploy, no en runtime) usa los roles `_owner`:
`DATABASE_URL_PLATFORM_OWNER`, `DATABASE_URL_IAM_OWNER`, `DATABASE_URL_CORE_OWNER`.

## Redis

```bash
REDIS_ADMIN_URL="redis://:adminpass@HOST:6379" \
IAM_REDIS_PASSWORD="$(openssl rand -base64 32)" \
CORE_REDIS_PASSWORD="$(openssl rand -base64 32)" \
./05-redis-acl.sh
```

Secrets resultantes: `REDIS_URL_IAM` (`redis://panels_iam_redis:<pw>@HOST:6379`),
`REDIS_URL_CORE` (`redis://panels_core_redis:<pw>@HOST:6379`).

El script verifica automáticamente que cruzar de módulo devuelva `NOPERM`
(ver "Riesgos y mitigaciones" del plan: un prefijo de llave sin ACL detrás
no aísla nada).

## Qué falta hacer manualmente en Coolify (staging/producción)

Estos scripts asumen que ya existe un servidor Postgres y un servidor Redis
accesibles (el recurso gestionado de Coolify por ambiente). El agente no
tiene acceso a la cuenta de Coolify del usuario, así que:

1. Crear el recurso Postgres gestionado en Coolify para el ambiente.
2. Crear el recurso Redis gestionado en Coolify para el ambiente.
3. Correr estos scripts contra ambos usando las credenciales admin que da Coolify.
4. Cargar los secrets resultantes (`DATABASE_URL_*`, `REDIS_URL_*`) en la
   configuración del servicio `api` de ese ambiente.

## Desarrollo local

`db/provision/dev-local.sh` reproduce estos mismos pasos contra un Postgres
y Redis instalados en la máquina de desarrollo (sin Coolify), generando
`.env.dev-local` con las URLs resultantes — útil para correr la API y los
tests sin depender de infraestructura externa.