> **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 release de ATC

Esta es la aplicación de la [metodología de releases](/method/explanations/release-methodology)
al caso de uso ATC. Sirve para cambiar el workflow de Dani sin confundir una
prueba de un nodo con una validación del canal completo.

La [sincronización](/method/how-to/sync) fija la versión y la fecha de lectura;
esta guía decide qué hacer con un cambio. La [publicación de documentación](/method/how-to/publish)
es otro circuito.

## 1. Partir de una incidencia verificada

La entrada puede ser una auditoría, una métrica, un resultado de evaluación o
feedback de negocio. Antes de editar:

* conserva la observación literal;
* localiza la llamada, el nodo y la versión que la produjeron;
* comprueba los eventos de herramientas y el resultado externo si aplica;
* distingue un defecto de una regla de negocio todavía abierta.

Si la evidencia es insuficiente, el siguiente paso es mejorar la lectura, no
cambiar el workflow.

## 2. Clasificar el alcance

Usa esta clasificación para elegir las puertas de validación:

| Causa | Ejemplos de alcance | Riesgo que hay que comprobar |
|---|---|---|
| Conducta | instrucciones, respuesta, prohibición | regresión, adversarial y salida correcta |
| Enrutado o grafo | triaje, retorno, escalado, traspaso | rutas de entrada y salida, sin saltos indebidos |
| Integración | OTP, pago, lectura, datos o API | errores, estado externo y no duplicación |
| Telefonía o ASR | captura, interrupción, silencio | evidencia de audio/transcripción y recorrido afectado |
| Post-llamada | resultado, etiquetado, extracción | CRM, analítica y clasificación final |
| Regla de negocio | elegibilidad, límites, excepciones | decisión aprobada antes de activar un criterio |

Una release debe indicar una sola causa principal. Las dependencias que no se
puedan cambiar en ella quedan como riesgo o trabajo posterior.

## 3. Fijar la base y la candidata

Confirma la organización, el entorno y la versión viva del workflow ATC. Guarda
el identificador, la fecha y las métricas de referencia. Después prepara una
candidata nueva como copia de esa versión confirmada.

No edites la versión viva, no uses una versión histórica por comodidad y no
reutilices una candidata que se haya quedado atrás respecto de la base.

## 4. Cambiar y proteger

Haz un único cambio relacionado con la incidencia. Añade una regresión que
reproduzca el caso y revisa las capacidades vecinas. En particular, comprueba
las tres clases que la página de pruebas exige para cada capacidad:

* resolución para el cliente;
* frontera y salida correcta;
* conducta que debe respetarse aunque el resultado sea bueno.

Si el cambio afecta una prohibición, incluye una prueba adversaria. Si llama a
una operación con efecto lateral, exige un contrato de no duplicación antes de
probar reintentos.

## 5. Pasar las puertas

Antes de pedir publicación, registra:

1. lectura y estructura de la versión candidata;
2. regresión del issue;
3. pruebas personalizadas y adversarias aplicables;
4. recorrido completo afectado;
5. evidencia externa de transferencia, entrega, cambio de estado o escritura;
6. limitaciones: qué plano no se pudo comprobar.

La [referencia de evidencia de ATC](/use-cases/atc/reference/evidence) ayuda a
separar lo que demuestra cada prueba. Una evaluación cooperativa de un turno no
prueba por sí sola una transferencia, un pago, una entrega, una API o el cierre
post-llamada.

## 6. Revisar y publicar

La publicación es manual y requiere una revisión de negocio y técnica según el
alcance. Si el cambio necesita una comparación con la versión anterior, se fija
antes el objetivo, la ventana y la regla de promoción. No se atribuyen resultados
si durante la ventana se publican otros cambios que alteran la comparación.

La opción A/B solo se usa cuando el impacto, la plataforma y negocio lo
justifican. No se presupone un porcentaje ni una duración universal.

## 7. Observar y decidir

Compara la candidata con la base usando las señales disponibles en
[Métricas de ATC](/use-cases/atc/reference/metrics): resultado E2E, escalado OK,
abandono, auditoría, indicadores principales y fiabilidad técnica cuando esté
instrumentada.

* **Promover** si mejora el objetivo y no introduce una regresión material.
* **Seguir observando** si el volumen o la evidencia todavía no permiten decidir.
* **Revertir** si aparece una regresión, un riesgo no aceptable o una pérdida de
  trazabilidad.

Cierra el issue con el [registro de release](/method/reference/release-record),
comunica la decisión a quienes validan el resultado y deja separadas las
preguntas que siguen abiertas.

## No publicar todavía si…

* la versión base o el entorno no están confirmados;
* la regla que se quiere activar está en conflicto;
* la regresión no reproduce el issue;
* una prueba aislada se está usando como evidencia E2E;
* no se puede demostrar el efecto externo de una operación sensible;
* falta una decisión sobre el destino de un escalado o traspaso;
* se han mezclado cambios no relacionados.

Para aprender el circuito sin tocar una versión, sigue [De una incidencia a una
release](/use-cases/atc/tutorials/issue-to-release).