> **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.

# Evidencia, UAT y pendientes

El material de Super App se encuentra en una fase de baseline y preparación. La
existencia de una arquitectura, un workflow o una tool no demuestra que el
recorrido esté aceptado, aislado o listo para producción.

## Estados de evidencia

| Estado | Significado |
|---|---|
| **Verificado** | La afirmación se comprobó directamente contra la fuente de autoridad y el alcance coincide. |
| **As-is documentado** | El material describe un comportamiento existente, pero la versión/entorno debe volver a comprobarse antes de cambiarlo. |
| **To-be** | Diseño objetivo; todavía no es una capacidad operativa. |
| **Pendiente** | Falta decisión, contrato, owner o comprobación. |
| **Bloqueante** | Impide desarrollo, UAT, publicación o handoff seguro. |

Un snapshot de plataforma no es un export portable. No se guardan aquí
credenciales, transcripts reales, DNIs, cookies, enlaces de runs ni datos brutos
de UAT.

## Evidencia específica de TeLeo y las implementaciones modulares

| Tema | Estado que puede documentarse | Lo que aún hay que comprobar |
|---|---|---|
| TeLeo | Existe una consola humana de texto sobre Twin, con tickets, mensajes, resumen del bot, roles y ciclo de atención. | Entorno desplegado, permisos efectivos, contrato de integración y retención del tenant. |
| Ingesta TeLeo | La app documenta creación idempotente de ticket, mensajes de cliente, webhook de respuesta y señales de escalado. | Que el workflow de Super App use la frontera, headers y fallback aprobados. |
| Ciclo TeLeo | Cierre explícito del agente, de-escalado, cola, Pendientes y reapertura están descritos como comportamiento vigente. | UAT de disponibilidad, asignación, silencio del cliente y fallo de webhook. |
| ATC modular | Existe una implementación en drafts independientes: shell, Auth reutilizado, Triaje, nueve especialistas y Post-call. | Callable, response nodes, entorno, payload, E2E y conexión del Dispatcher; no es producción. |
| Operaciones modular | Existen ocho drafts independientes desde la baseline v545: parent, adapter Auth, Triaje, cuatro children de dominio y Post-call. | Aislamiento de la respuesta raw de Auth, entorno, `POST.answer`, UAT/E2E y conexión del Dispatcher; no es producción. |
| Post-call modular | Debe conservar parent, child y correlación para escribir cierre y observabilidad. | Que el `parent_run_id` sobreviva al child y no duplique cierres o transferencias. |

La consola TeLeo y los drafts modulares son evidencias de diseño o
implementación acotada, no una autorización para publicar nuevas rutas. El
[subdominio de TeLeo](/use-cases/super-app/teleo), la [referencia modular de
ATC](/use-cases/super-app/reference/atc-modular-plan) y el [inventario conjunto
de implementaciones](/use-cases/super-app/reference/modular-implementations)
separan comportamiento observado de gates pendientes.

## Cobertura UAT mínima

La batería debe cubrir ambos canales cuando el destino los soporte:

| Área | Casos mínimos |
|---|---|
| Entrada | Usuario logado, anónimo, sesión caducada, pérdida de conectividad y canal no soportado. |
| Dispatcher | ATC, Operaciones, intención ambigua, varias intenciones, idioma no previsto y urgencia. |
| Operaciones | Autodiagnóstico, cobertura, técnico, cita, caso resuelto, error de backend y escalado. |
| ATC | Factura, pago, contrato, autenticación, gestión no disponible y route handoff. |
| Handoff | Resumen conservado, estado de autenticación, ticket/caso, TeLeo, Connect, timeout, destino caído y retorno de error. |
| Seguridad | Acceso cruzado, replay, prompt injection, credencial rota, dato excesivo y transcript fuera de scope. |
| Datos | CI/CG correcto, resultado confirmado por backend, retención y borrado por entorno. |

Cada escenario debe declarar canal, entorno, versión fuente, resultado esperado,
side effects, evidencia y criterio de aceptación. Un prompt review no sustituye
un E2E, y un HTTP 200 no prueba un resultado de negocio.

## Gates bloqueantes

* \[ ] Contrato de entrada del Dispatcher y route matrix voz/texto aprobado.
* \[ ] Payload y respuesta de cada Workflow Function definidos y minimizados.
* \[ ] Destino de ATC texto creado o decisión explícita de no disponibilidad.
* \[ ] Baselines live/latest revalidados por entorno, sin confundirlos.
* \[ ] Mulesoft de producción, endpoints y credenciales aprobados para Operaciones texto.
* \[ ] Asignación, ciclo vigente y fallback de TeLeo definidos.
* \[ ] Children de ATC modular tienen response nodes, contratos y correlación parent/child.
* \[ ] UCD/E2E de voz, texto, Dispatcher, ATC modular, handoff y errores ejecutados en el entorno adecuado.
* \[ ] Riesgo de credencial HappyRobot y aislamiento de transcript aceptados o mitigados.
* \[ ] Retención, borrado, acceso y auditoría confirmados por cada owner.
* \[ ] Plan de cambio, observación y reversión aprobado sin publicar desde esta documentación.

## Qué no se puede concluir

* Que un workflow latest sea la versión live.
* Que una tool placeholder habilite un canal.
* Que voz y texto compartan el mismo mecanismo de transferencia.
* Que `user_id`, ANI o token técnico prueben por sí solos la autorización del cliente.
* Que el código genérico de la plataforma demuestre la integración concreta de Naturgy.
* Que una cifra o fecha prevista demuestre un lanzamiento.
* Que RBAC de consola limite automáticamente una credencial de runtime.

## Paquete de evidencia por cambio

Un cambio candidato debe conservar, como mínimo:

1. problema y alcance;
2. baseline fuente y entorno;
3. contrato afectado;
4. escenarios UAT/UCD/E2E y resultados;
5. side effects en CI/CG, Connect, TeLeo, transcript y métricas;
6. aprobación de Producto, Negocio, Seguridad y owners técnicos cuando aplique;
7. observación posterior y condición de reversión.

La decisión de publicar pertenece a los owners de la plataforma y del producto;
este dominio solo organiza el conocimiento y los gates necesarios para decidir.