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

# Metodología de releases

Una release de un workflow es un cambio controlado sobre una versión que puede
atender tráfico real. No es lo mismo que publicar una página de documentación:
la primera cambia el comportamiento de un sistema y la segunda cambia la forma
de explicar ese comportamiento.

La metodología permite mejorar sin perder la atribución. Cada cambio debe tener
un problema concreto, una evidencia que lo motive, una prueba que lo proteja y
una decisión posterior que diga si se mantiene o se revierte.

## Principios no negociables

1. **Nada en caliente.** La versión que atiende tráfico no es un espacio de edición.
2. **Una release, un problema.** No se mezclan cambios no relacionados.
3. **Evidencia antes de la solución.** Una anécdota puede abrir una investigación,
   pero no basta para afirmar una causa.
4. **Cambio mínimo y reversible.** Se modifica solo lo necesario y se conserva un
   camino claro de vuelta.
5. **Regresión y recorrido completo.** El caso que motivó el cambio queda protegido;
   además se comprueba que no se rompe el recorrido que lo rodea.
6. **Publicación explícita.** La revisión y la publicación son decisiones separadas
   del trabajo de edición y de las pruebas.
7. **Medición antes de promoción.** Una mejora se promueve porque la evidencia la
   respalda, no porque la versión nueva exista.

## El ciclo de mejora

```text
Detectar → Verificar → Definir → Cambiar y probar
    ↑                                      ↓
    └──── Medir y decidir ← Publicar ─────┘
```

### 1. Detectar

La señal puede proceder de una auditoría, una métrica, una alerta, una prueba,
una incidencia o feedback de negocio. Se conserva la observación literal y se
anota qué parte del recorrido parece afectada.

### 2. Verificar y netear

Se comprueba que la señal corresponde a la versión y al entorno que se quieren
cambiar. Se revisan la conversación completa, los eventos del workflow y el
resultado externo cuando sean necesarios. El resultado de esta etapa es un
síntoma verificado, no todavía una solución.

### 3. Definir

El síntoma se convierte en un issue con evidencia, frecuencia o volumen,
criticidad, causa sospechada, criterio de éxito, falsador y responsable. También se decide
si es un error, una evolución, una regla pendiente o un falso positivo. Una regla
sin dueño no se convierte en un criterio activo.

### 4. Cambiar y probar

El equipo reproduce el problema, clasifica la causa y hace el cambio mínimo sobre
una versión aislada. Antes de editar, confirma la versión base y conserva una
candidata separada de la versión que atiende tráfico. Identifica si el cambio
afecta instrucciones, componentes, nodos y conexiones del workflow, integraciones,
datos o lógica post-llamada; un cambio compartido obliga a revisar todos sus
consumidores. Añade una regresión del caso y comprueba el recorrido completo y
las fronteras vecinas según el riesgo. Las pruebas no deben afirmar más de lo que
realmente observan.

No se copia un bloque genérico de reglas para resolver un caso local: se edita
la regla en su lugar propietario, se revisan sus duplicados y se verifica que
la modificación no haya cambiado el orden efectivo de instrucciones. Para una
guía operativa, sigue [Preparar y cerrar una release de workflow](/method/how-to/release).

### 5. Publicar

Una persona revisa el alcance, las pruebas, el riesgo y el plan de reversión. La
publicación se hace de forma manual y versionada. Cuando el impacto lo justifica,
se puede usar un despliegue comparativo; su uso, duración y criterio de promoción
requieren aprobación previa.

### 6. Medir y decidir

Se compara la versión nueva con la línea base durante una ventana suficiente para
el volumen del caso. Se revisan el objetivo, las regresiones, la calidad, la
fiabilidad y cualquier señal de seguridad. El resultado es uno de estos:

* **promover:** el objetivo mejora y no aparece una regresión material;
* **seguir observando:** el resultado todavía no permite atribuir una mejora;
* **revertir:** aparece una regresión, un riesgo no aceptable o una pérdida de
  control sobre la evidencia.

La decisión cierra el issue y queda junto al registro de la release.

## Validación proporcional al cambio

La batería exacta depende del impacto, pero la regla de base es esta:

| Tipo de cambio | Comprobación mínima orientativa |
|---|---|
| Conducta o instrucción | Regresión del issue, prueba adversaria cuando haya una prohibición y recorrido afectado |
| Enrutado o grafo | Regresión, entradas y salidas afectadas, y recorrido completo |
| Integración o dato | Contrato de error, resultado externo, no duplicación de efectos y recorrido afectado |
| Cambio de negocio de alto impacto | Las anteriores y comparación controlada si la plataforma y negocio la aprueban |
| Cambio urgente | La excepción documentada, el control disponible y una revisión posterior obligatoria |

Una evaluación de un turno no demuestra por sí sola el estado de una API, una
entrega, una transferencia o una escritura de negocio. Al revisar un proxy o
integración, sigue el dato desde el nodo y sus argumentos hasta la petición,
configuración de entorno, respuesta/error del servicio, lógica del proxy y
consumidor final. Verifica autenticación y secretos sin copiarlos a la
documentación; no deduzcas éxito externo de un HTTP 200 si el contrato tiene un
estado funcional propio. Contrasta código y configuración con el servicio vivo,
pruebas y logs permitidos. Para ATC, usa también [el mapa del proxy](/use-cases/atc/explanations/proxy),
[el diagnóstico de incidencias](/use-cases/atc/how-to/diagnose-issue) y la
[referencia de evidencia](/use-cases/atc/reference/evidence).

## Gobierno y excepciones

Participan, con responsabilidades que deben quedar claras en cada release:

* quien reporta y aporta la evidencia;
* quien representa el criterio de negocio;
* quien diagnostica y modifica el workflow;
* quien revisa y autoriza la publicación;
* quien valida el resultado en tráfico real, cuando corresponda.

Una excepción urgente no elimina el método. Debe registrar el motivo, el riesgo,
la persona que la autoriza, las comprobaciones realizadas y la revisión posterior.
Los nombres, umbrales, ventanas y acuerdos de cada cuenta deben confirmarse
antes de convertirlos en política.

## Qué queda registrado

Cada release conserva como mínimo:

* issue y evidencia original;
* versión base y versión candidata;
* alcance y tipo de cambio;
* criterio de éxito y pruebas ejecutadas;
* revisión, aprobación y fecha de publicación;
* línea base y ventana de observación;
* resultado, decisión y riesgos residuales.

La [guía para preparar y cerrar una release](/method/how-to/release) explica la
secuencia. El [registro de release](/method/reference/release-record) define los
campos que no deben faltar. Para ATC, la aplicación concreta está en
[preparar una release de ATC](/use-cases/atc/how-to/release).