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

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

⛔ Antes de tocar nada, lee el Método: repos/metodo/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.

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é).