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

# Implementaciones modulares de Operaciones y ATC

Esta referencia reúne las dos implementaciones modulares preparadas para Super
App. Las dos parten de una versión de voz fijada, crean workflows nuevos y
separan el shell, el triaje, los especialistas y el cierre. **Son drafts no
publicados:** no sustituyen a los workflows de voz que atienden tráfico, no
conectan el Dispatcher y no habilitan ATC texto.

Los identificadores de las tablas son referencias de la lectura; un workflow ID
no equivale a un version ID. Antes de una nueva prueba o rebase hay que volver a
leer el entorno, `published`, `live` y el version ID en la plataforma.

## Estado resumido

| Implementación | Fuente fijada | Resultado | Estado de la lectura |
|---|---|---|---|
| Operaciones | `Caso de Operaciones`, workflow `019c5394-7679-7549-b817-cfa96ca88518`, v545 · `01a04857-5c4a-7ec3-9877-402bdd1ccb6b` | 8 drafts nuevos: parent, adapter Auth, triaje, cuatro children de dominio y Post-call | La fuente figura live y publicada en `production`, con 185 nodos. Los ocho targets figuran sin publicar y sin live. |
| ATC | `[ES][Voice] ATC Naturgy`, workflow `019d2967-5b8c-7788-8321-577d55542760`, v496 · `019febac-e458-7c60-8029-fe978650bc99` | 12 drafts nuevos: parent, triaje, nueve especialistas y Post-call; reutiliza ATC Auth v12 | La fuente figura live y publicada en `production`, con 201 nodos. Los doce targets figuran sin publicar y sin live. |

La lectura de Operaciones está registrada el 31-08-2026 en el workspace de
soporte correspondiente. La verificación estructural de ATC está registrada el
26-08-2026. Las fechas delimitan el alcance de estos estados; no son una
promesa de vigencia futura.

## Patrón común

```mermaid
flowchart TD
    dispatcher["Dispatcher<br/>ruta objetivo"] -.-> op["Operaciones SuperApp Modular"]
    dispatcher -.-> atc["ATC SuperApp Modular"]

    subgraph operations["Operaciones · voz"]
        op --> opAuth["Contexto Auth<br/>adapter saneado"]
        op --> opTriage["Triaje"]
        opTriage --> opDiag["Diagnóstico y equipos"]
        opTriage --> opCoverage["Cobertura y distribuidora"]
        opTriage --> opTech["Técnico / actuación"]
        opTriage --> opAppointments["Citas"]
        op --> opPost["Post-call"]
    end

    subgraph atcflow["ATC · voz"]
        atc --> atcAuth["ATC Auth v12<br/>child reutilizado"]
        atc --> atcTriage["Triaje"]
        atcTriage --> atcSpecialists["9 especialistas de capacidad"]
        atc --> atcPost["Post-call"]
        atc --> transfer["transfer_chain<br/>existente"]
    end

    opPost --> systems["CI/CG · Connect · Twin<br/>y observabilidad"]
    atcPost --> systems
    transfer --> systems
```

Las líneas punteadas representan una conexión objetivo, no una ruta activa. En
ambas implementaciones:

* el punto de entrada modular es `Workflow Function Request`;
* los children tienen targets y versiones concretos, response nodes y
  referencias remapeadas al grafo nuevo;
* el especialista devuelve un estado explícito, en lugar de dejar que el parent
  adivine el resultado a partir de texto libre;
* el Post-call conserva la correlación del parent y concentra el cierre y la
  observabilidad;
* el alcance de tools se limita a la capacidad del child;
* un timeout, una respuesta vacía o un error no equivale a una gestión correcta;
* la entrada y la transferencia siguen siendo dependencias de canal. La
  modularidad no convierte automáticamente voz en texto ni cambia el contrato
  de Connect o de TeLeo.

## Operaciones: implementación realizada en drafts

### Topología

```text
Dispatcher (conexión pendiente)
  └─ Operaciones SuperApp Modular
       ├─ Contexto Auth
       │    └─ ATC Auth v12, solo mediante adapter explícito
       ├─ Triaje
       │    ├─ Diagnóstico y equipos
       │    ├─ Cobertura y distribuidora
       │    ├─ Técnico / actuación
       │    └─ Citas
       └─ Post-call
```

El parent y el triaje orquestan; los cuatro children de dominio conservan los
playbooks y las tools de la baseline aprobada v545 dentro de límites separados.
El Post-call conserva el cierre de CI/CG, la transferencia y la observabilidad
según el contrato que todavía debe probarse en E2E.

### Fronteras relevantes

| Child | Responsabilidad | Forma verificada |
|---|---|---|
| `Operaciones SuperApp Modular` | Recibir el handoff, mantener la conversación y coordinar Auth, triaje y Post-call. | `Workflow Function Request`; 6 nodos; 1 response node; 2 llamadas a children. |
| `Operaciones Modular · Contexto Auth` | Envolver ATC Auth v12 y exponer solo el envelope aprobado. | `Workflow Function Request`; 3 nodos; 1 response node; 1 llamada interna. |
| `Operaciones Modular · Triaje` | Clasificar el problema y llamar al child de capacidad. | `Workflow Function Request`; 14 nodos; 5 response nodes; 5 llamadas. |
| `Operaciones Modular · Diagnóstico y equipos` | Autodiagnóstico, códigos y orientación de seguridad. | `Workflow Function Request`; 10 nodos; 1 response node. |
| `Operaciones Modular · Cobertura y distribuidora` | Consultar cobertura y distribuidora mediante sus tools. | `Workflow Function Request`; 11 nodos; 1 response node. |
| `Operaciones Modular · Técnico / actuación` | Gestionar la actuación técnica con sus ramas deterministas. | `Workflow Function Request`; 50 nodos; 4 response nodes. |
| `Operaciones Modular · Citas` | Consultar o gestionar citas y órdenes según las respuestas del backend. | `Workflow Function Request`; 11 nodos; 1 response node. |
| `Operaciones Modular · Post-call` | Cerrar CI/CG, transferencia y observabilidad. | `Predefined Request`; 64 nodos; 5 response nodes. |

### Auth y privacidad

El adapter de Operaciones reutiliza ATC Auth v12 (`019feca1-e101-74e2-bcd9-fcce28f60345` /
`01a0110e-2b13-7e44-976c-66d17abb6ea3`) como dependencia de development, y su
contrato público está diseñado para no entregar la respuesta raw al parent. El
envelope previsto se limita a estado de
módulo, autenticación, vía de autenticación, identificadores aprobados de
cliente/contacto, siguientes pasos y código técnico de error. No incluye
credenciales, OTP, cabeceras, documento completo, teléfono, ficha enriquecida,
direcciones, contratos ni transcript.

La evidencia sintética tiene dos alcances distintos:

* los casos autenticado y rechazado del adapter devolvieron únicamente las
  claves permitidas, sin marcadores ni claves prohibidas;
* una llamada de development a ATC Auth a través del adapter no mostró rutas
  sensibles en la salida pública ni en las referencias explícitas de prompt;
* la llamada directa al child ATC Auth sí devolvió campos raw token-like y PII.
  Por tanto, el adapter es obligatorio y la reutilización directa sigue
  prohibida.

La auditoría de prompts de los ocho drafts no encontró referencias sensibles.
Eso no demuestra todavía que la plataforma no inyecte automáticamente en el
contexto del modelo los parámetros declarados en las raíces. Esa comprobación,
y el aislamiento de la salida interna raw, siguen bloqueados.

### Hallazgos que aún afectan a Operaciones

La verificación estructural confirmó el grafo, los response nodes, las rutas y
la ausencia de valores de producción en los targets. La auditoría de variables
revisó 1.258 referencias y dejó una única incidencia: `POST.answer` en el child
`Diagnóstico y equipos` no está demostrado como variable disponible en el
contrato de salida. Hay que probarlo en un entorno aprobado o sustituirlo por
un mapping aislado antes de UAT.

Además, los ocho drafts reportan `environment: production` aunque están sin
publicar y sin live. El owner del entorno debe confirmar o cambiar ese entorno
antes de cualquier prueba que pueda alcanzar backends reales.

## ATC: implementación realizada en drafts

### Topología

```text
Dispatcher (conexión pendiente)
  └─ ATC SuperApp Modular
       ├─ ATC Auth v12 reutilizado
       ├─ ATC Modular · Triaje
       │    ├─ Dudas Facturas
       │    ├─ Pagos
       │    ├─ Alta de Fraccionamiento
       │    ├─ Comparativa
       │    ├─ Cambio de Datos
       │    ├─ Lecturas
       │    ├─ Duplicados
       │    ├─ Sin Suministro
       │    └─ Cambio de Titular
       ├─ transfer_chain existente
       └─ ATC Modular · Post-call
```

La implementación crea doce targets nuevos. Auth v12 no se duplica: es el child
de autenticación reutilizado y su versión de development debe permanecer
separada de la versión de producción. Los nueve especialistas reciben solo el
playbook y las tools de su capacidad. `RETURN_TO_TRIAGE` vuelve al triaje y las
ramas de escalado conservan `transfer_chain`.

### Fronteras relevantes

| Capa | Responsabilidad | Forma verificada |
|---|---|---|
| `ATC SuperApp Modular` | Shell callable, coordinación de Auth, triaje y Post-call. | `Workflow Function Request`; 11 nodos; 1 response node; 4 llamadas. |
| `ATC Modular · Triaje` | Clasificar y llamar a uno de los nueve especialistas. | `Workflow Function Request`; 33 nodos; 11 response nodes; 11 llamadas. |
| Nueve especialistas | Resolver facturas, pagos, fraccionamiento, productos, datos, lecturas, duplicados, suministro o titularidad. | Cada uno es callable, con response nodes y tools acotadas a su capacidad. |
| `ATC Modular · Post-call` | Extraer el cierre, escribir Salesforce/Twin y devolver un estado terminal. | `Predefined Request`; 23 nodos; 3 response nodes. |
| `transfer_chain` | Gestionar el cierre del escalado o traspaso. | Workflow compartido existente; no se duplica en los especialistas. |

La verificación de ATC informó para los doce targets: una raíz alcanzable,
trigger callable, cero `module-change`, cero referencias desconocidas o stale,
payloads compatibles y variables de producción vacías. También comprobó la
importación de 251/251 custom tests; las regresiones procedentes de producción
se conservaron redacted. Estas comprobaciones prueban estructura y preparación
de tests, no el resultado E2E de los backends ni la conexión telefónica.

ATC texto sigue fuera de alcance. La modularidad de ATC voz no crea un destino
para el Dispatcher de texto ni convierte el Dispatcher observado en
multicanal.

## Inventario pinneado de targets

### Operaciones

Todos los targets de esta tabla se observaron en `production`, con
`published=false` y `live=false` en la lectura de verificación.

| Componente | Workflow ID | Version ID |
|---|---|---|
| Parent `Operaciones SuperApp Modular` | `01a058bb-def9-7dbc-adbc-08cce9b2a373` | `01a058bb-df05-7830-9b3b-da8c296f0946` |
| Adapter `Contexto Auth` | `01a058bb-8e00-7970-aef0-d3731c6a91e1` | `01a058bb-8e0f-793c-93d6-7eaf779f14b8` |
| `Triaje` | `01a058bb-9a00-735a-87eb-a605f4c31cf6` | `01a058bb-9a12-7b8f-bfe8-f26d230432e6` |
| `Diagnóstico y equipos` | `01a058bb-a58a-7aac-adaa-a0cc13cf3553` | `01a058bb-a598-71f7-bb0c-0f4d5bbcceb0` |
| `Cobertura y distribuidora` | `01a058bb-b101-7325-8bef-3ed5291c6c80` | `01a058bb-b10e-7598-8234-c93e944dd667` |
| `Técnico / actuación` | `01a058bb-bc9c-77e9-8323-c5e5c0d45976` | `01a058bb-bcaa-7e0a-88e9-78d06cf20956` |
| `Citas` | `01a058bb-c875-71d6-b30d-3de186682010` | `01a058bb-c885-762a-a76a-0de8886b0b40` |
| `Post-call` | `01a058bb-d3d4-7af5-86db-d17165b9c7f7` | `01a058bb-d3e9-7377-a2ae-a52e50f76734` |

### ATC

Todos los targets de esta tabla se observaron en `production`, con
`published=false` y `live=false` en la lectura de verificación. ATC Auth v12
es una dependencia reutilizada y se muestra aparte porque está publicada y
live en `development`, no porque forme parte de los doce drafts nuevos.

| Componente | Workflow ID | Version ID |
|---|---|---|
| Parent `ATC SuperApp Modular` | `01a0395e-40d0-7798-80f6-629d664ffea8` | `01a0395e-40e5-7286-bce1-a15088e4581a` |
| `Triaje` | `01a0395e-52c1-7b75-9682-6adbd2b05989` | `01a0395e-52d6-7bc6-a248-ad5383e987bc` |
| `Dudas Facturas` | `01a0395e-6434-7f9f-9644-511c289af010` | `01a0395e-6446-796f-b2a0-9ad78f79ba58` |
| `Pagos` | `01a0395e-762e-79ce-b180-17a921cadcff` | `01a0395e-763d-7aa1-be23-3a4a257a7912` |
| `Alta de Fraccionamiento` | `01a0395e-8921-7efc-9f98-703c21412238` | `01a0395e-895d-7a1a-b75e-c04f945e6b1b` |
| `Comparativa` | `01a0395e-9ab8-751b-b85b-0bafc3c09389` | `01a0395e-9aca-7061-84c1-bfe67632cabd` |
| `Cambio de Datos` | `01a0395e-ac2c-79f7-8db1-113ebf03258f` | `01a0395e-ac43-7927-9f3c-eb089a455a02` |
| `Lecturas` | `01a0395e-bde1-72ab-9012-fa551b8db68b` | `01a0395e-bdec-7785-a087-2f56a5d21844` |
| `Duplicados` | `01a0395e-cf24-7690-afbd-56e4557450bf` | `01a0395e-cf31-7f72-953b-eaefa68cf20e` |
| `Sin Suministro` | `01a0395e-e0ac-7006-8db1-49cbb683e075` | `01a0395e-e0c6-7375-b2d1-6e48422f7831` |
| `Cambio de Titular` | `01a0395e-f20d-7bdf-ade5-6766be6ad692` | `01a0395e-f221-71f0-a368-3201548c8c8b` |
| `Post-call` | `01a0395f-0374-7ccc-a12d-8496580768d1` | `01a0395f-0387-7ba8-82c2-18cc8ef499eb` |
| Dependencia `ATC Auth` v12 | `019feca1-e101-74e2-bcd9-fcce28f60345` | `01a0110e-2b13-7e44-976c-66d17abb6ea3` |

## Contratos que deben ser iguales y contratos que no deben mezclarse

### Envelope común de entrada

El Dispatcher debería enviar un envelope explícito y mínimo a cada shell:

```text
channel, source, correlation_id, session_id, parent_run_id,
intent, subintent, confidence, summary, language,
execution_environment, case_id o sf_ci_id si ya existe
```

Las referencias técnicas (`user_id`, `token_id` o ANI) solo se incluyen cuando
el contrato del canal las autoriza y nunca sustituyen a una autorización de
negocio. No se envían API keys, Bearer tokens, transcript completo, IBAN ni
DNI completo para clasificar.

### Resultado de child

Ambas implementaciones deben cerrar el estado del salto con un catálogo
acordado, por ejemplo:

```text
module_status = COMPLETED | RETURN_TO_TRIAGE | ESCALATED | FAILED
summary       = resumen breve y saneado
handoff_status = opcional
error_code    = código técnico no visible al cliente
```

`RETURN_TO_TRIAGE` es terminal para el especialista. Un timeout, fallo o salida
vacía debe producir `FAILED` y el fallback aprobado, nunca un éxito implícito.

### Post-call y correlación

El parent debe entregar `parent_run_id`, `parent_version_id`,
`parent_environment`, `correlation_id`, `session_id`, caso autorizado, señales
de handoff y las referencias de cierre permitidas. El Post-call tiene su propio
`current.run_id`; no se puede usar para sustituir la correlación del parent.

Las diferencias permanecen intencionadas:

* Operaciones usa un adapter explícito para no propagar el output raw de Auth y
  conserva sus fronteras de CI/CG, técnico, citas y Connect.
* ATC reutiliza Auth v12 y mantiene `transfer_chain`; la visibilidad de sus
  campos raw y su aislamiento por entorno siguen necesitando validación antes de
  tratarlo como contrato aprobado.
* Operaciones y ATC son especialistas de voz. El destino de ATC texto no existe
  en esta implementación y el workflow de Operaciones texto es un sibling, no
  uno de estos children de voz.

## Evidencia y gates

### Qué está verificado

* las dos fuentes live fueron fijadas por version ID, no por `latest`;
* los drafts no editan ni publican las fuentes live;
* la estructura de los targets tiene roots alcanzables, response nodes y
  referencias remapeadas;
* los tests locales usan valores redacted o sintéticos y no se guardan secretos,
  PII, transcripts ni credenciales;
* la prueba pública del adapter de Operaciones devuelve un envelope saneado en
  su alcance declarado;
* la verificación de ATC comprueba la topología y la importación local de sus
  custom tests.

### Qué no está verificado

* que el Dispatcher entregue el envelope en el runtime real;
* que las variables root sensibles no se inyecten automáticamente en el contexto
  del modelo;
* que el output raw de ATC Auth quede aislado en todos los caminos;
* el mapping de `POST.answer` de Diagnóstico;
* el entorno correcto de los drafts, que actualmente reportan `production`;
* el resultado de CI/CG, Connect, Salesforce, Twin o cualquier backend en E2E;
* timeouts, reintentos, idempotencia, fallback, retención, borrado y rollback en
  un entorno de prueba aprobado.

### Gates antes de conectar o publicar

1. aprobar el envelope Dispatcher → shell y la matriz de rutas por canal;
2. aislar y aprobar la frontera de Auth, incluido el output raw y la no inyección
   de parámetros root;
3. resolver `POST.answer` y repetir la auditoría de variables de Operaciones;
4. confirmar un entorno no productivo o la autorización explícita del owner para
   los drafts que reportan `production`;
5. ejecutar regresiones redacted y UAT/E2E de voz, Auth, cada capacidad,
   escalado, transferencia, CI/CG, Connect, Salesforce/Twin y Post-call;
6. aprobar observabilidad, retención, acceso, rollback y la condición de
   reversión;
7. obtener una aprobación separada para publicar y otra para conectar el
   Dispatcher.

Para el contexto de canal consulta [Dispatcher y enrutado](/use-cases/super-app/explanations/dispatcher),
para la seguridad y el límite de Auth [Seguridad y acceso](/use-cases/super-app/explanations/security)
y para los detalles ATC [la arquitectura modular de ATC](/use-cases/super-app/reference/atc-modular-plan).
El contrato técnico de Auth de Operaciones se conserva en el workspace de soporte
como `docs/07-operations-auth-contract.md`. La [evidencia, UAT y pendientes de
Super App](/use-cases/super-app/reference/evidence) es la lista común de
criterios; esta página no autoriza una release.