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

Workflow: sesión de EXPLORACIÓ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 mirar sin tocar, sin el frente. Viaja a cada repo con .metodo/. Qué se mira, con qué herramienta y por dónde se entra vive en su apéndice, que no viaja: se lee sobre este núcleo, no en su lugar.

Para tareas de lectura, medida y diagnóstico: inventariar, leer, comparar, aislar una causa — sin aplicar ningún cambio real. Si la tarea sí implica cambiar algo, la que toca es la de ejecución (sesion-ejecucion.md), que tiene las salvaguardas que ésta no necesita.

⛔ Solo-lectura no es "portarse bien": es una propiedad que hay que poder demostrar. Todo lo de esta fase es reversible por definición, y por eso se puede iterar sin pedir permiso en cada paso — pero en el momento en que algo module estado, aunque sea "para confirmar la hipótesis", ya no es esta sesión (§12 del Método).

Cuándo se usa

Cuando la tarea consiste en inventariar, leer, comparar o diagnosticar, y nunca en modificar configuración real. El disparador concreto de cada frente está en su apéndice.

Qué debe llevar el prompt

1. Punto de partida obligatorio: qué leer antes de nada — el CLAUDE.md del sitio y el corpus del frente (doc/AVISOS.md primero, doc/decisiones.md, doc/backlog.md), más el documento de arquitectura o análisis que aplique.
2. La tarea exacta, copiada literalmente de donde viva (sección y checkboxes). «Literalmente» cierra la puerta a que el prompt parafrasee la tarea, que es de donde salen las premisas rancias.
3. ⭐ Criterios de validación: si la fuente no los enumera, cada sub-checkbox de la sección es por defecto un criterio. Es lo que convierte un encargo en algo evaluable — sin esto, "he mirado" y "está comprobado" son indistinguibles.
4. ⛔ El encargo negativo, ENUMERANDO LOS VERBOS PROHIBIDOS — no un genérico «no cambies nada». Se listan los gestos concretos que en ese frente sí modificarían estado (instalar, aprobar, inicializar, aplicar, reiniciar, tocar el firewall…), porque un «no cambies nada» abstracto deja a la sesión decidiendo qué cuenta como cambio. La forma es del núcleo; la lista la pone el apéndice. ⇒ Y con su cierre: si detecta algo mejorable, lo documenta como hallazgo o recomendación, no lo aplica.

Qué hace la sesión

1. Lee lo que el encargo manda leer, en ese orden.
2. Explora y mide lo necesario — puede conectarse a lo que haga falta solo para leer, nunca para configurar.
3. Documenta los hallazgos donde su frente documente, con el mismo formato que lo que ya hay ahí (úsalo de plantilla). ⚠️ No crea documento aparte salvo que el hallazgo sea sustancial y merezca su propio archivo — un documento nuevo por cada exploración es ruido, no corpus.
4. ⭐ Evalúa honestamente, contra los criterios, si la tarea está completa, parcial o bloqueada. No "ha ido bien": contra los criterios, uno a uno.
5. Actualiza el backlog: marca cada checkbox ([x] solo si se verificó de verdad, [~] si quedó parcial, [ ] con el motivo si no se pudo) y enlaza lo que haya escrito.
6. ⛔ Si algo descubierto contradice una decisión escrita —una arquitectura, una D cerrada—, lo dice explícitamente en el resumen final, y si la contradice de frente PARA y reporta (§6 del Método). Nada se actualiza solo.
7. ⛔ Si lo explorado revela una tarea de configuración que convendría aplicar, la deja PROPUESTA — no la ejecuta. Esa propuesta es la semilla de una futura sesión de ejecución, con su propio encargo.

⚠️ Lo que este núcleo NO trae, y se dice en vez de disimularlo: predicción, testigo y control negativo. Ninguno de los workflows de los que sale lo tenía — toda su disciplina es de efectos secundarios («qué no tocar», «para y pregunta»). Es un hueco conocido y medido, no un olvido, y se cierra por núcleo cuando toque.

Plantilla de prompt

El esqueleto. El relleno —qué leer, qué se mira, con qué herramienta, qué verbos están prohibidos— 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 documento de arquitectura/análisis que aplique>

Tarea a ejecutar (es de EXPLORACIÓN/LECTURA, no de configuración):
<pegar aquí el bloque exacto, copiado literalmente>

Criterios de validación:
<enumerarlos; si no los hay, cada sub-checkbox de la sección es un criterio>

Haz lo siguiente:
1. Explora/mide lo necesario para cubrir cada punto. NO <lista de verbos prohibidos del
   frente: instalar, aprobar, inicializar, aplicar, reiniciar, tocar el firewall...> — aunque
   detectes algo mejorable, documéntalo como recomendación, no lo apliques.
2. Documenta lo encontrado en <dónde>, siguiendo el formato de lo que ya hay ahí. No crees un
   documento aparte salvo que el hallazgo lo merezca.
3. Vuelve a <el backlog> y marca cada checkbox: [x] solo si lo verificaste de verdad, [~] si
   quedó parcial, [ ] anotando el motivo. Enlaza lo que hayas escrito.
4. Evalúa contra los criterios si la tarea queda completa, parcial o bloqueada — y dilo.
5. Si algo contradice una decisión escrita, dilo explícitamente; si la contradice de frente,
   PARA y repórtamelo.
6. Si descubres una tarea de configuración que convendría aplicar, DÉJALA PROPUESTA. No la
   ejecutes.

Al terminar, dame un resumen breve de qué se confirmó, qué se descartó, qué quedó propuesto y
qué quedó pendiente.