# 05 — Insumos de Frontend y Especificación de Pantalla
## Checklist completo de lo que el equipo de diseño y producto debe proveer antes de iniciar la programación

> **Uso:** Antes de escribir código para cualquier página o componente de Internet Banking, el desarrollador debe rellenar esta especificación con el cliente o diseñador de interfaz.
> Si quedan dudas de negocio, se usarán mocks provisorios que deberán reemplazarse posteriormente.

---

## §1 — Identificación y Enrutamiento de la Pantalla

| Insumo | Especificación | ¿Completado? |
|---|---|---|
| Nombre descriptivo de la pantalla | `ej. Dashboard de Cuentas` | ☐ |
| Ruta técnica (URL Path) | `ej. /dashboard` | ☐ |
| Nivel de Autenticación | `Pública` / `Protegida` / `Doble Factor Requerido` | ☐ |

---

## §2 — Estructura de la Interfaz (UI Mockups)

Adjunta el mockup de Figma o los requerimientos visuales acordados:

- **Layout general:** ¿Utiliza el layout principal de navegación o es una pantalla limpia (ej. Login)?
- **Paleta y Componentes:** Confirmar que se usen componentes de **daisyUI** (Botones, Inputs, Modales, Tables) para garantizar consistencia.

### Elementos Críticos de la UI:
1. **Header / Breadcrumb:** ¿Cuáles son los títulos y navegación?
2. **Formularios e Inputs:**
   - Lista de campos con validación en cliente (ej. monto numérico, formato email).
3. **Tablas / Listados:**
   - Columnas a mostrar (ej. Número de cuenta cifrado, Saldo real descifrado, Estado).

---

## §3 — Integración de APIs y Backend Downstream

Identificar todas las llamadas de red requeridas para poblar la pantalla:

| Acción | Método | Endpoint (Spring Boot) | Payload requerido | Respuesta esperada |
|---|---|---|---|---|
| `ej. Cargar saldos` | `GET` | `/cuentas` | Ninguno (Headers Auth) | Listado de Cuentas |
| `ej. Realizar transferencia` | `POST` | `/transferencias` | `{ cuentaOrigen, monto, traceId }` | Recibo de transferencia |

*Nota: Cualquier dato sensible de esta tabla (monto, número de cuenta) debe marcarse para cifrado Kong perimetral antes de ser enviado.*

---

## §4 — Estado Global y Zustand Store

Define qué datos deben persistir en el estado del cliente durante la sesión:

| Variable de Estado | Tipo | Propósito | ¿Requiere persistencia? |
|---|---|---|---|
| `user` | Objeto | Datos de perfil del usuario logueado | ✅ Sí (SessionStorage) |
| `theme` | String | Modo claro / oscuro | ✅ Sí (LocalStorage) |
| `ej. cuentasCargadas` | Array | Lista temporal de cuentas en dashboard | ☐ No (Memoria) |

---

## §5 — Registro de Logs y Trazabilidad

Define qué eventos críticos del usuario deben quedar grabados en `logs/app.log`:

| Evento | Nivel de Log | Mensaje | Metadata a registrar |
|---|---|---|---|
| `ej. Carga de Dashboard` | `[INFO]` | `Carga de dashboard de cuentas` | `{"userId": "<user.id>"}` |
| `ej. Click en Transferir` | `[INFO]` | `Acción de transferencia iniciada` | `{"monto": 150, "traceId": "..."}` |
| `ej. Intento fallido` | `[WARN]` | `Intento de transferencia saldo insuficiente` | `{"montoRequerido": 5000}` |

---

## Semáforo de Readiness de Frontend antes de Iniciar

| Sección | Estado | ¿Bloqueante? |
|---|---|---|
| **§1 Enrutamiento y Auth** | ☐ Completo / ☐ Incompleto | ✅ SÍ — define la ruta del archivo Next.js |
| **§2 Componentes visuales** | ☐ Completo / ☐ Incompleto | ✅ SÍ — previene rehacer interfaces visuales |
| **§3 Contratos de APIs** | ☐ Completo / ☐ Incompleto | ⚠️ Parcial — se puede crear mock en Next.js Route Handler |
| **§4 Configuración Zustand** | ☐ Completo / ☐ Incompleto | ⚠️ Parcial — se puede definir durante el desarrollo |
| **§5 Registro de Logs** | ☐ Completo / ☐ Incompleto | ✅ SÍ — obligatorio para cumplir estándares de trazabilidad |