smtp-relay/.metodo/workflows/sesion-ejecucion.md

# Workflow: sesión de EJECUCIÓN — núcleo

<!-- metodo:puntero -->
⛔ **Antes de tocar nada, lee el Método: [`repos/metodo/metodo.md`](../metodo.md)** — los
raíles transversales, completos y con sus cicatrices. Si trabajas **dentro de un repo**, la copia que
te toca es la suya (`.metodo/metodo.md`), que va sellada y la mide `metodo check`.
⇒ Y **`§7`**: al arrancar se leen `AVISOS.md`, `decisiones.md` y `backlog.md`; **la bitácora NO**, se
consulta por su índice. Arrancar cuesta ~400 k tokens en un frente maduro y **la bitácora es el 79 %**.
⇒ *Este bloque existe porque el 2026-08-29 se midió que **7 de los 9 workflows del árbol no llevaban
al Método**, incluidos los dos más usados. Una constitución sólo gobierna si algo lleva a ella: es su
propio raíl `§8` —* ***un aviso que nadie lee no es un mecanismo de contención.***
<!-- /metodo:puntero -->

> **Esto es el NÚCLEO: el método de aplicar un cambio ya decidido, sin el frente.** Viaja a cada
> repo con `.metodo/`. Qué máquinas hay, qué comandos, qué es intocable y dónde se documenta vive
> en su **apéndice**, que **no viaja**: se lee sobre este núcleo, no en su lugar.

Para tareas que **aplican cambios reales**. Si la tarea es solo leer, comparar o diagnosticar sin
tocar nada, la que toca es la de **exploración** (`sesion-exploracion.md`) — tiene menos
salvaguardas porque no las necesita.

⛔ **Esta sesión no decide diseño: ejecuta lo ya decidido, con cuidado.** El "qué" se acordó antes;
lo suyo es el "cómo". Si al llegar la realidad no coincide con lo que el encargo daba por cierto,
**para y reporta** — no improvisa (`§6` del Método: la premisa del prompt también se mide).

## Cuándo se usa

Cuando ya se ha decidido **qué** cambiar y **cómo** —normalmente fruto de una exploración previa
más la conversación con el usuario— y toca aplicarlo. El disparador concreto de cada frente, y qué
cuenta allí como "cambio real", están en su apéndice.

## Qué debe llevar el prompt

1. **Punto de partida obligatorio**: qué leer antes de nada — el `CLAUDE.md` del sitio, el corpus
   del frente (`doc/AVISOS.md` **primero**, `doc/decisiones.md`, `doc/backlog.md`) y el análisis o
   discusión previa **donde se tomó la decisión**.
2. **Las tareas exactas, copiadas literalmente** de donde vivan, **marcadas como ya decididas** —
   el prompt debe dejar claro que no hace falta volver a preguntar el "qué". *«Literalmente»
   cierra la puerta a que el prompt parafrasee la tarea, que es de donde salen las premisas
   rancias.*
3. **Para cada tarea**: qué cambiar exactamente, **en qué orden** si hay dependencias, y qué hacer
   si la realidad encontrada no coincide con lo documentado (parar y preguntar, nunca improvisar
   sobre algo en producción).
4. ⛔ **El reparto de riesgo, explícito y en dos montones**: qué es de **bajo riesgo** —se aplica
   tras verificar el estado actual, sin confirmación paso a paso— y qué toca **algo que no se
   puede permitir perder** (el acceso de administración, la conectividad activa, los datos).
   **Eso segundo exige plan de reversión ANTES de aplicar**, y si algo no es como se esperaba,
   parar en vez de avanzar.
5. ⛔ **Quién ejecuta cada paso, y con qué credencial.** Un paso no está especificado hasta que
   dice **quién** lo hace y quien lo escribe ha comprobado que **puede**. Si la respuesta es «el
   humano», **se dice en el encargo** y se le deja el bloque listo para su terminal.

⚠️ **Y un plan de reversión que nadie ha visto disparar es una promesa, no una red.** Si se puede
ensayar barato, se ensaya; si no, se dice que no está ensayado. Su ventana hace indistinguible
*«aún no ha disparado»* de *«ha fallado»*.

## Qué hace la sesión

1. Lee lo que el encargo manda leer, **en ese orden**.
2. **Captura el estado ANTES** (`show running-config`, `get -o yaml`, `wg show`, lo que
   corresponda), **aplica el cambio**, **captura el estado DESPUÉS**, y **compara**. Los dos
   extremos, no solo el de después: sin el antes, el verde no prueba nada.
3. ⛔ **Verifica el RESULTADO, no el estado declarado.** Un campo que dice que algo está arriba no
   es la prueba de que funcione: *un `gre_up: true` con `ospf_state: Down` **NO** es un éxito*. Se
   comprueba el comportamiento real —tráfico que pasa, la consulta que responde, el fichero que
   está donde tiene que estar—, y se exige el testigo que **discrimina**, no el que siempre sale
   verde (`§1` del Método).
4. Si algo **no coincide** con lo esperado, **para y pregunta** — no decide sobre la marcha cómo
   resolverlo si afecta a producción.
5. **Documenta lo aplicado** (antes/después, comandos usados) donde su frente documente, con el
   mismo formato que lo que ya hay ahí — no invente uno nuevo.
6. **Actualiza el backlog**: `[x]` solo si se aplicó **y se verificó** de verdad, `[~]` si quedó
   parcial, `[ ]` con el motivo si no se pudo o si quedó como propuesta pendiente de confirmación
   humana.
7. **Escribe en memoria el hecho persistente** (ver debajo).
8. ⛔ **Si algo descubierto contradice una decisión escrita, lo dice explícitamente** en el resumen
   final — y si la contradice de frente, **PARA y reporta**: no se escribe otra decisión debajo
   (`§6` y `§7` del Método). Una arquitectura no se actualiza sola.

## Escribir en memoria tras ejecutar

**Por qué**: una tarea de ejecución cambia hechos que valen para **todas las sesiones futuras**, no
solo para esta conversación. Por eso, además de documentarlo donde toque, se guarda en el sistema
de memoria.

⭐ **Qué guardar, y es un PUNTERO**: guárdalo (`type: project` o `reference`) **apuntando** al
backlog, al `readme.md` o al documento donde vive el detalle — **no dupliques el contenido en la
memoria**. La memoria es el atajo para que una sesión futura sepa que algo existe y dónde mirarlo,
no una segunda copia que derive de la primera (`§7`: escribirlo en dos sitios **no es prudencia, es
crear la deriva**).

**Qué NO guardar**: si el dato ya es trivial de obtener leyendo la documentación —rutas, comandos
exactos, credenciales—, no hace falta memoria aparte.

## Plantilla de prompt

*El esqueleto. El relleno —qué leer, qué máquinas, qué es intocable, dónde se documenta— lo pone
el apéndice del frente.*

```
Trabaja en <el sitio>.

Antes de nada, lee:
- <el CLAUDE.md que aplique>
- <doc/AVISOS.md del frente — PRIMERO>, <doc/decisiones.md>, <doc/backlog.md sección "<exacta>">
- <el análisis/decisión previa donde se decidió esto>

Estas tareas YA ESTÁN DECIDIDAS (no preguntes el "qué", ejecuta el "cómo" con cuidado), en
este orden:
<cada tarea con su procedimiento exacto y, si depende de otra, en qué orden>

Reglas:
1. Antes de cualquier cambio, captura el estado actual. Aplica. Vuelve a capturar y compara.
2. Verifica el RESULTADO, no el estado declarado: exige el testigo que discrimina, no el que
   siempre sale verde.
3. Si algo no coincide con lo documentado, PARA y pregúntame — no improvises sobre algo en
   producción.
4. No toques nada que pueda cortar <el acceso que no se puede perder> sin dejar antes un plan
   de reversión o un camino alternativo. <Y di si ese plan está ensayado o no.>
5. Documenta lo aplicado (antes/después) en <dónde>.
6. Actualiza <el backlog>: [x] solo si se verificó, [~] si quedó parcial, [ ] con el motivo.
7. Escribe en memoria el hecho resultante COMO PUNTERO — no dupliques contenido.
8. Si algo contradice una decisión escrita, dilo explícitamente; si la contradice de frente,
   PARA y repórtamelo.

Al terminar, dame un resumen: qué se aplicó y verificó de verdad, qué quedó como propuesta
pendiente de mi confirmación, y qué no se pudo hacer (y por qué).
```