> **Can't find what you're looking for?** Use `search_docs` on the docs MCP server at `https://naturgy-comer-documentation-p5mde.vercel.app/api/mcp` to find what you need.

# Preparar una batería UAT

La batería UAT debe demostrar el recorrido que se quiere aceptar. No basta con
probar el prompt o comprobar que un workflow devuelve una respuesta.

## 1. Fija el alcance

Registra el canal, entorno, versión fuente, especialista, integración y owner.
Separa las pruebas de la app móvil de las pruebas del workflow y de las
comprobaciones del backend.

## 2. Cubre las entradas

Incluye, como mínimo:

* cliente anónimo y cliente con sesión Omega;
* sesión válida, caducada y contexto incompleto;
* voz, texto y entrada tradicional cuando estén en alcance;
* conexión perdida, timeout y servicio no disponible;
* idioma o intención que el contrato no soporte.

## 3. Cubre el enrutado

Prueba Operaciones, ATC, intención ambigua, varias intenciones, una emergencia,
un tema ajeno y una petición explícita de persona. Comprueba que el Dispatcher
no pide autenticación ni consulta negocio para clasificar.

## 4. Cubre la resolución

Para cada especialista define:

* camino feliz y resultado observable;
* condición que obliga a no ejecutar una tool;
* error de validación y error técnico;
* CI/CG, ticket, cita, transferencia o cierre esperado;
* dato que debe devolver el backend para afirmar éxito.

## 5. Cubre el handoff

Comprueba por separado:

| Canal | Debe comprobarse |
|---|---|
| Voz | Resumen, motivo, estado de autenticación, Connect, cola y cierre/transferencia. |
| Texto | Ticket TeLeo, contexto, respuesta humana, retorno o cierre; nunca transferencia telefónica implícita. |
| Dispatcher | Target, response node, timeout, fallback y ausencia de ATC texto no disponible. |

## 6. Cubre seguridad y datos

Añade casos de acceso cruzado, replay, prompt injection, credencial rota, dato
excesivo y transcript fuera de scope. Verifica que el handoff no contiene tokens,
API keys, cookies ni PII que el destino no necesite.

## 7. Define la evidencia

Cada caso debe registrar:

| Campo | Contenido |
|---|---|
| Entrada | Canal, sesión y petición redacted |
| Expectativa | Resultado, tool, handoff y side effects |
| Observado | Respuesta del workflow y del backend |
| Evidencia | CI/CG, ticket, Connect, transcript o métrica aplicable |
| Estado | Pass, fail, blocked o necesita decisión |
| Riesgo | Qué podría quedar ambiguo o duplicarse |

Una prueba bloqueada por un servicio externo no es una prueba pasada. Una
respuesta del agente no sustituye al estado de negocio.

## Gates antes de cerrar UAT

* \[ ] Route matrix aprobada por canal y dominio.
* \[ ] Contratos de entrada/salida y errores aprobados.
* \[ ] Baseline live y entorno revalidados.
* \[ ] ATC texto resuelto como destino o no disponibilidad.
* \[ ] Mulesoft, TeLeo, Connect y backends necesarios disponibles.
* \[ ] UCD/E2E ejecutadas con datos redacted.
* \[ ] Side effects e idempotencia revisados.
* \[ ] Retención, acceso y transcript comprobados.
* \[ ] Pendientes de Producto, Negocio, Seguridad y owners registrados.

La UAT no publica workflows. Después de una aceptación, sigue la [metodología de
releases](/method/explanations/release-methodology) y el proceso de publicación
propio de cada owner.