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

# Registro de release

El registro de release es la unidad mínima de trazabilidad de un cambio. No es
un changelog narrativo ni una copia de las instrucciones del workflow: conecta
un problema con una versión candidata y con la decisión tomada después de
observarla.

## Campos obligatorios

| Campo | Qué debe responder |
|---|---|
| `release_id` | ¿Cómo se identifica esta release? |
| `issue` | ¿Qué problema o resultado motiva el cambio? |
| `evidence` | ¿Qué observación reproducible lo respalda? |
| `hypothesis` | ¿Por qué se espera que el cambio resuelva el problema? |
| `baseline` | ¿Qué versión, entorno y fecha sirven de comparación? |
| `scope` | ¿Qué workflow, capacidades y salidas están dentro del alcance? |
| `change_type` | ¿Es conducta, enrutado, integración, telefonía, post-llamada o negocio? |
| `success_criterion` | ¿Qué resultado observable permitirá aceptarla? |
| `falsifier` | ¿Qué resultado obligaría a descartar o revisar la hipótesis? |
| `regression` | ¿Qué caso protege el problema corregido? |
| `validation` | ¿Qué pruebas y planos de evidencia se ejecutaron? |
| `approval` | ¿Quién revisó y autorizó la publicación? |
| `rollback` | ¿Cómo se vuelve a la base si aparece una regresión? |
| `observation` | ¿Qué ventana y qué comparación se usarán después? |
| `decision` | ¿Se promueve, se observa o se revierte? |
| `residual_risks` | ¿Qué no quedó demostrado o sigue pendiente? |

Los identificadores y enlaces deben ser los mínimos necesarios para que una
persona autorizada pueda repetir la comprobación. No se almacenan secretos,
datos personales, cargas completas ni transcripciones sin redacción.

## Estados

Una release avanza por estados explícitos:

```text
propuesta → en progreso → lista para revisión → aprobada
    → publicada → en observación → promovida | revertida | pendiente
```

`bloqueada` puede sustituir a cualquier estado cuando falta una decisión,
evidencia o acceso. Un estado no se cambia para ocultar una prueba que no se
pudo ejecutar.

## Puertas de decisión

| Momento | Pregunta de control | Si la respuesta es no |
|---|---|---|
| Antes del cambio | ¿La base está confirmada y el issue es concreto? | No abrir la candidata |
| Antes de publicar | ¿El cambio es atómico, reversible y está protegido por pruebas? | Pedir corrección o más evidencia |
| En la publicación | ¿La aprobación y el alcance están registrados? | No publicar |
| Durante la observación | ¿La evidencia permite comparar con la base? | Ampliar la lectura o revertir |
| Al cerrar | ¿El objetivo mejoró sin regresiones materiales? | No promover; decidir observar o revertir |

## Plantilla

```text
Release:              <identificador>
Issue:                <problema en una frase>
Evidencia:            <run, auditoría, métrica o prueba permitida>
Hipótesis:            <por qué el cambio debería resolverlo>
Base:                 <workflow, entorno, versión y fecha>
Alcance:              <capacidad, agente, salida y sistemas afectados>
Tipo de cambio:       conducta | enrutado | integración | telefonía | post-llamada | negocio
Criterio de éxito:    <resultado observable>
Falsador:             <resultado que invalidaría la hipótesis>
Regresión:            <caso que debe quedar protegido>
Validación:           <pruebas ejecutadas + evidencia disponible>
Aprobación:           <persona, fecha y decisión>
Publicación:          <fecha, versión candidata y modalidad>
Observación:          <ventana, línea base y métricas>
Decisión final:       promover | seguir observando | revertir | pendiente
Riesgos residuales:   <qué no se ha demostrado>
```

El registro se completa aunque la release no se publique. Una candidata
rechazada o revertida conserva el motivo para que el siguiente intento no parta
de una hipótesis ya descartada.

Consulta la [metodología de releases](/method/explanations/release-methodology)
y la [guía de preparación y cierre](/method/how-to/release).