> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Operar Lerian SCR

> Operar Lerian SCR: comprobaciones de readiness, espacios de nombres de configuración en tiempo de ejecución, rotación de credenciales, caché y retención, métricas, y la postura estricta.

Lerian SCR se ejecuta sobre un canal regulatorio tarifado, y su superficie operativa lo protege.

## Salud y readiness

***

`GET /health` responde liveness. `GET /readyz` responde una entrada por dependencia.

| Comprobación     | Qué verifica                                                       | Cuándo falla                                                      |
| ---------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------- |
| `postgres`       | Un ping al pool primario.                                          | Inalcanzable: caído.                                              |
| `redis`          | Un ping al cliente de caché.                                       | Inalcanzable: caído. Ausente: omitido.                            |
| `scr_endpoint`   | Un handshake TLS limitado con BACEN. Sin consulta, sin credencial. | Cadena rota: caído. Timeout de conexión: degradado.               |
| `vault`          | Una llamada de alcanzabilidad al almacén de credenciales.          | Inalcanzable: degradado, una credencial en caché sigue sirviendo. |
| `tenant_manager` | El directorio de tenants, solo multi-tenant.                       | Inalcanzable: caído.                                              |
| `event_emission` | La postura de emisión declarada.                                   | Nunca. Solo informa.                                              |

El resultado del handshake sirve durante 20 segundos, por lo que readiness nunca marca a BACEN por solicitud. El breaker en el nivel de pod se abre solo cuando todos los breakers por institución están abiertos. Una institución con fallos mantiene el pod listo y responde `SCR-1002`.

Al apagar, `/readyz` pasa a 503 primero, y el listener permanece abierto tres segundos. `READYZ_DRAIN_DELAY` lo anula.

## Configuración en tiempo de ejecución

***

Nueve espacios de nombres llegan a un operador en `/v1/system`, bajo el ámbito `scr:system:write`. La tabla lista los siete que el servicio lee. `scr.cors` y `scr.postgres` también existen en el catálogo. El servicio toma su configuración de cross-origin y de pool de conexiones desde las [variables de entorno](/es/rails/scr/scr-environment-variables).

Un cambio de nivel de log surte efecto de inmediato. Un cambio de retención surte efecto en el siguiente barrido de purga. El servicio lee cualquier otro espacio de nombres al iniciar, por lo que un cambio ahí surte efecto en el siguiente reinicio. Consulta [System plane](/es/reference/platform/systemplane/overview).

| Espacio de nombres    | Qué controla                                        | Valores por defecto                   |
| --------------------- | --------------------------------------------------- | ------------------------------------- |
| `scr.app`             | Nivel de log.                                       | Configuración de arranque.            |
| `scr.rate_limit`      | Límite entrante por IP.                             | 100 cada 60 segundos.                 |
| `scr.outbox`          | Intervalo, tamaño de lote, intentos de publicación. | `2s`, 50, 3.                          |
| `scr.wsscr2n`         | Plazo de solicitud, conexiones por institución.     | `25s`, 2.                             |
| `scr.cache`           | Duración de las entradas.                           | `4h`, `720h`.                         |
| `scr.circuit_breaker` | Umbrales de activación, enfriamiento.               | 5 fallos, tasa 0,5, mínimo 10, `30s`. |
| `scr.retention`       | Ventana de purga, cadencia de barrido.              | Vacío. Purga desactivada.             |

Cada perilla tiene límites finitos. El plazo de solicitud se detiene por debajo de 28 segundos, por lo que una solicitud nunca sobrevive a la gateway. El tope de conexiones acepta 1 o 2.

## Credenciales y rotación

***

El tipo de secret store elige la fuente de la credencial. El tipo de entorno lee el usuario y la contraseña desde el entorno de despliegue. El tipo de vault gestionado los resuelve por institución, y la base de datos guarda solo una referencia.

El tipo de vault gestionado también habilita `PUT /v1/scr/credential`. Escribe primero el vault y luego los metadatos, por lo que un reintento reutiliza la referencia.

La contraseña nunca llega a un log, un span, o un error. La operación de estado devuelve un nombre de usuario enmascarado. Una caída del vault responde `SCR-1002` y nunca activa el breaker del canal.

## Caché y retención

***

La caché de resultados contiene una entrada por institución, índice ciego del prestatario, y mes de referencia. Cada valor lleva el sobre en reposo de la fila de auditoría. Una entrada del mes en curso vive cuatro horas, una entrada de un mes cerrado 720 horas. Una entrada ilegible cuenta como un fallo de caché, y un despliegue sin Redis siempre falla.

La purga de auditoría permanece desactivada hasta que un operador establece una ventana. Una ventana vacía no elimina nada. Con una ventana, un barrido diario elimina las filas más antiguas en lotes acotados, y nunca las archiva.

## Métricas y trazas

***

La exportación por defecto es OTLP push. Un listener de scrape de Prometheus es de activación explícita, en una dirección loopback, `127.0.0.1:9075` por defecto. El puerto de la aplicación no tiene ninguna ruta `/metrics`.

Dos histogramas miden una consulta: de extremo a extremo, y la sobrecarga sin la llamada a BACEN. Sus etiquetas llevan la institución, la marca de acierto de caché, y el resultado, nunca al prestatario. Los contadores cubren códigos de decodificación desconocidos y filas purgadas.

## Postura de despliegue

***

Un nombre de entorno de producción o el modo de despliegue SaaS selecciona la postura estricta. El arranque estricto exige un modo de despliegue explícito, el host, la base de datos y el usuario de Postgres, y autorización sobre una dirección https. Exige la URL base del canal sobre https, y TLS en Postgres y en cualquier Redis o broker configurado. Exige dos claves en reposo distintas y una región para el vault gestionado, y prohíbe un rango de proxy comodín.

Una lista de brokers o un host de Redis en blanco rechaza el arranque, a menos que un operador declare la exclusión explícita. El log de arranque y `/readyz` entonces nombran las protecciones degradadas.

Multi-tenancy necesita la URL del directorio de tenants y una clave de servicio. De lo contrario, un despliegue sirve a una institución.

Un operador aplica el esquema fuera del proceso en tiempo de ejecución. El servicio lo lee y nunca lo crea.
