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

# Workflow: sesión ORQUESTADORA — 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 coordinar, sin el frente.** Viaja a cada repo con `.metodo/`.
> Lo que sea de un frente concreto —qué backlogs hay, qué rutas, qué máquinas, qué es intocable—
> vive en su **apéndice**, y un apéndice **no viaja**: se lee sobre este núcleo, no en su lugar.
> ⇒ En el árbol multi-repo el apéndice es `apendices/arbol-proyectos.md`; en un repo que se clona
> solo, el frente es **ese repo** y su corpus (`doc/AVISOS.md` · `doc/decisiones.md` ·
> `doc/backlog.md`).

Esta sesión es el **punto central de coordinación**. No ejecuta infraestructura directamente
(salvo cambios menores y seguros), sino que:

1. Mantiene el contexto global entre sesiones de ejecución y exploración.
2. Hace refinement del backlog a medida que llegan resultados.
3. **Genera los prompts** de las sesiones satélite — su entregable *es* el prompt.
4. Recibe sus resúmenes y decide el siguiente paso.
5. Actualiza documentación, memoria y backlog cuando hace falta.

⛔ **Y su frontera no la decide «¿sé hacerlo?» ni «¿es peligroso?», sino «¿esto tiene un TIPO DE
SESIÓN PROPIO?»** — si lo tiene, **se delega aunque sea texto, aunque sea barato y aunque sepas
hacerlo** (`§7` del Método). Un documento que describe un tipo de sesión **se lee como un método que
aplicar uno mismo**, y ése es el mecanismo del fallo.

## Cuándo se usa

Siempre que haya que coordinar en vez de ejecutar. Es el rol por defecto salvo que se diga otra
cosa: las sesiones de exploración y ejecución son **satélites** que ésta lanza y recibe.

## El RELEVO — cuando esta sesión se queda sin contexto

⛔ **No lo detectas a tiempo, así que no lo diseñes como una entrega.** Una sesión **no puede medir
cuánto contexto le queda**: el contador que ve es el presupuesto de la sesión entera, no la ventana.
La única señal dura es **la compresión**, y llega **cuando ya has perdido**. ⇒ **El relevo no se da:
se tiene.** Todo momento tiene que ser un punto de relevo válido.

**Qué lo hace posible, y es lo único que hay que cumplir:**
1. **Una decisión del usuario se escribe ANTES de actuar sobre ella.** No después, no «al cerrar».
   Es el único campo que un sucesor **no puede reconstruir de ningún sitio**, y el que más caro sale.
2. **Lo que está EN VUELO vive fuera de la sesión.** Son **cuatro campos**, y son los cuatro que las
   capas del corpus **no** guardan:

       EN VUELO (<fecha y hora>) · debo: <a quién, qué> · espero: <de quién, qué>
                · hilo: <qué haces AHORA y por qué> · sin escribir: <nada | …>
                · gesto siguiente: <el comando o la acción física que toca, o «ninguno»>

   - **debo** — lo que otro espera de ti y aún no has entregado.
   - **espero** — de quién y qué. Si muere quien te lo debe, **esto es lo único que lo dice**.
   - **hilo** — por qué haces justo esto. Es lo que un sucesor **no puede reconstruir del corpus**.
   - ⭐ **sin escribir** — decisiones del usuario que aún **no están en `doc/`**. **Lo sano es
     «nada»**; si tiene contenido, **es deuda y se paga antes que nada**.
   - ⭐ **gesto siguiente** — **el comando o la acción física que toca**, o «ninguno». Medido:
     *un sucesor no se atasca en una decisión difícil; se atasca en no saber si teclear un
     comando o hacer `git push`.* Sin este campo, **«cerrada» y «cerrada pero falta empujar»
     se leen igual**. *(Lo estrenó una orquestadora el día de estrenar el bloque.)*

   ⛔ **Se REESCRIBE, no crece**: es una foto, no un diario — el diario es la bitácora. Una línea
   por campo.
   ⇒ **Dónde vive lo pone tu árbol, no este fichero**: si trabajas en un árbol multi-repo, va en
   **tu fila del semáforo** (`repos/metodo/workflows/sesiones-activas.md`, ruta del árbol) —
   *(si has clonado este repo suelto, esa ruta no existe: entonces vive donde tu repo arbitre
   sesiones concurrentes, y si nunca hay dos a la vez, en el sitio que leas al arrancar)*.
   ⚠️ *(Esto se escribió el 2026-08-30 y **nació roto**: la mitad que **motiva** viajaba a los 27
   repos y la que **instrumenta** —los cuatro campos— se quedó en el semáforo, que **no viaja**. Lo
   cazó una orquestadora **el día de estrenarlo**, haciendo `grep` en su `.metodo/` y saliendo
   vacío. ⇒ **Una mitad que comprueba que algo esté y otra que sabe qué es, sin que nadie las
   junte**, es la forma de defecto más repetida de este árbol.)*
3. **Lo demás ya tiene capa**: decisión → `decisiones.md` · trabajo → `backlog.md` · trampa →
   `AVISOS.md` · relato → `bitacora.md`. Si dudas de dónde va, **el sitio equivocado es tu cabeza**.

**Y lo que un sucesor necesita y NO es técnico.** Medido con una sesión limpia: *un sucesor no se
atasca en una decisión difícil; se atasca en no saber si teclear un comando o hacer `git push`.*
⇒ El relevo lleva **el gesto siguiente**, no sólo el estado.

### Cuando llegas TÚ de relevo

⛔ **Hereda el rol, no la identidad.** El prompt que te abre **puede nombrar mal a quién relevas** —
medido el 2026-08-30: nombraba a una sesión que era **la 2ª**, no la anterior—, así que **no lo des
por bueno**: escribe a quien te digan y **pregúntale**. La puerta del saludo es lo único que hoy ha
detectado un error del propio encargo.
⛔ **Y avisa a los SATÉLITES del relevado, no sólo a tus pares.** *(Cicatriz 2026-08-30: una sesión
de ejecución trabajó **12 horas reportando a una orquestadora que ya había sido relevada dos veces**.
Nadie se lo dijo. No lo podía averiguar sola: **un satélite no sabe que su orquestadora ha muerto,
porque el silencio y el estar ocupada se parecen.**)*
⇒ Al entrar: lee las filas vivas, **saluda a quien coordine el árbol**, y **preséntate a toda sesión
cuyo alcance solape con el tuyo** — no a todas, sólo a ésas. Y **a las que trabajaban para tu
antecesora, aunque no solapen**: para ellas eres su nuevo interlocutor y **no tienen forma de saberlo**.

⚠️ **Un relevo que se reconstruye leyendo el corpus hereda el estado, pero NO la frontera.** Lo
documentado siempre va por detrás de lo hecho ⇒ tenderá a leer **el último trabajo de su antecesora
como ajeno**. Si algo del repo te parece una intrusión, **pide el crudo antes de decirlo** (`R9`).
⇒ El disparador concreto de cada frente está en su apéndice.

⛔ **Y un límite del terreno que cambia lo que puedes reconstruir: en un árbol donde todas las
sesiones commitean con la MISMA identidad de máquina, «quién hizo este commit» es INCONTESTABLE
desde `git`.** Un `--author` devuelve **a todo el mundo**. ⇒ **Lo único que atribuye es el MENSAJE**
—y el semáforo—, así que un commit ajeno bajo un mensaje que habla de otra cosa **no es un detalle
estético: borra la única atribución que existe**.
⇒ Y para ti, que llegas de relevo: **no puedes saber qué dejó tu antecesora salvo por lo que digan
los mensajes.** Si un protocolo te dice *«mira qué hizo la anterior»*, eso **sólo funciona si los
mensajes lo cuentan**. *(Medido 2026-08-30 por una sesión que fue a auditarse y se encontró con los
commits de las demás. Se salvó **porque escribe mensajes largos con el porqué** — no porque `git` la
distinguiera.)*
## Cómo arranca una sesión orquestadora nueva

Cuando la sesión actual se agota de contexto, hay que abrir una nueva que retome
exactamente el mismo rol. El prompt de continuación debe incluir:

1. **Leer CLAUDE.md** — acceso a infraestructura, siempre lo primero.
2. **Leer MEMORY.md** — índice de hechos persistentes del proyecto.
3. **Leer los backlogs vivos del frente** — estado de lo hecho, lo que está en curso y lo
   pendiente. **Cuáles son los tuyos lo dice el apéndice de tu árbol o el `CLAUDE.md` de tu repo**,
   no este fichero: el núcleo pone la **forma** (léelos antes de decidir nada), y **la lista es de
   quien la tiene**. *(Aquí iba una lista de tres rutas de un árbol concreto. Se retiró el
   2026-08-30 antes de repartirse: viajaba a 27 repos que no tienen ninguna de las tres, contra
   «viaja lo que sirve a un repo que sólo se tiene a sí mismo».)*
4. **Estado de la sesión anterior**: qué prompts se lanzaron y cuáles están
   esperando respuesta. Si hay un prompt pendiente de resultado, indicarlo
   explícitamente para que la nueva sesión sepa que su primer input del usuario
   puede ser ese resultado.
5. **Instrucción de rol**: "tu rol es el de sesión orquestadora — no ejecutes
   infraestructura directamente salvo cambios menores y seguros; genera prompts
   para las sesiones de exploración/ejecución siguiendo los workflows de esta
   carpeta".

## Qué hace la sesión orquestadora cuando recibe un resultado

Cuando el usuario pega el resumen de una sesión de exploración/ejecución:

1. Actualiza el backlog (`[x]`, `[~]`, `[ ]` con notas).
2. Si la sesión produjo archivos nuevos, hace `git add + commit + push` al repo
   de Kubernetes (`git.c2et.com/SECOPS/kubernetes.git`).
3. Actualiza o crea memorias si hay hechos nuevos persistentes.
4. Decide el siguiente paso: ¿hay otra tarea lista para ejecutar? ¿hay que
   refinar algo antes? ¿hay un bloqueante que resolver con el usuario?
5. Propone el siguiente prompt o pregunta al usuario qué quiere atacar.

## ⛔ Las cifras y los estados de un prompt SE MIDEN AL ESCRIBIRLO, no se recuerdan

Un prompt es una **afirmación**, y una afirmación rancia le cuesta tiempo a la sesión que la
recibe. *(Cicatriz 2026-07-27, dos en el mismo encargo: dije «suite en 438 verdes» cuando iban por
**572** —cifra de dos días antes— y monté un plan de verificación sobre dos hechos **incompatibles
entre sí**: «la Raspberry es tu punto de vista» y «brume-5-1 no está emparejado». Sin hub, el plan
sale vacío y allí solo se puede medir la ausencia. La sesión cazó las dos y preguntó, que es lo
correcto — pero el coste fue suyo.)*

Antes de mandar un prompt: **mide** el número de tests, la versión instalada, qué device está
emparejado, qué hay desplegado. Son dos comandos. Y si un dato no lo puedes medir, escríbelo como
lo que es —*«creo que…, verifícalo»*— en vez de como un hecho.

⛔ **Y un paso de un encargo no está especificado hasta que dice QUIÉN lo ejecuta — y tú has
comprobado que PUEDE.** Un prompt describe *qué* hacer; la capacidad del actor es una premisa más, y
de las que no se ven hasta que la sesión llega allí y choca. *(Cicatriz 2026-08-12, y son **dos en el
mismo hilo, con la misma forma**: (a) la orquestadora escribió en una decisión cerrada
—`R16`— que el token de Vault lo **acuñaría `mcp-secrets`**, y esa herramienta solo sabe
`harbor` y `git` (`TokenKind = Literal["harbor","git"]`) — y no podría saber más, porque **publica
en Vault** y ése es justo el token que abre Vault; (b) el encargo siguiente decía «la sesión crea la
política y el token con `kubectl exec vault-0`», y la sesión lo midió al llegar:
`auth/token/create → deny`, `vault policy read → 403`. El único token que tiene contra Vault es el
de ESO, **solo-lectura de KV**; el root vive en un GPG tras la passphrase DR que **por diseño** no
entra en una sesión.)*
⇒ Antes de escribir un paso, pregunta **con qué credencial se ejecuta** y si el que la tiene es
quien va a estar delante. Si la respuesta es «el humano», **dilo en el encargo** y deja el bloque
listo para su terminal — no lo redactes como si lo fuera a hacer la sesión.
⇒ ⭐ Y el patrón que las une, que es el que hay que buscarse a uno mismo: **especificar el QUÉ sin
medir el QUIÉN.** Las dos veces la mecánica era correcta y el actor no podía.

⛔ **Y un DIAGNÓSTICO heredado de otra sesión también es una afirmación, no un dato.** *(Tercera
premisa falsa de la misma racha: el encargo de F11.13 decía «a `brume-5-1` le falta la zona `wgt`»
—diagnóstico de la sesión anterior, copiado como hecho—. La zona **ya estaba**; lo que faltaba era
la **ruta de vuelta** (`ospf: false`), y en el otro nodo igual.)* Cuando repitas la causa que otro
encontró, **repítela como hipótesis**: *«la sesión anterior lo atribuyó a X — verifícalo antes de
arreglar»*. Un diagnóstico correcto sobre un síntoma no es un diagnóstico verificado.

## ⭐ Cómo se prioriza la deuda: INERTE contra MORDIENDO *(Xavier, 2026-08-02)*

**`manabo` es una plataforma de aprendizaje, y que queden cosas a medias es el modo de
funcionamiento, no un defecto.** Xavier rota prioridades entre proyectos **a propósito**.

⇒ Por eso *«hecho / a medias»* es un mal criterio para ordenar trabajo, y la orquestadora lo ha usado
mal más de una vez —*«sin deuda antes de empezar la fase»*—. La distinción útil es otra:

> **¿está a medias e INERTE, o a medias y MORDIENDO?**

*(La medida que lo enseña, 2026-08-02: el **etcd** de `niflheim` llevaba **8 meses** a medias **sin
molestar a nadie**. Su **apiserver** llevaba lo mismo, y se comía **un tercio de la admisión del
cluster entero** —cert-manager, metallb, external-secrets, ingress-nginx— **en silencio**. Misma
antigüedad, mismo «a medias», y uno de los dos era una avería en producción.)*

⇒ Lo que hay que preguntarse de cada cosa abierta no es cuánto lleva ahí, sino **qué está costando
ahora mismo**. Y si la respuesta es «no se sabe», eso ya es la respuesta: **lo que no se mide, muerde
en silencio**.



### ⛔ En una pieza con CARA HUMANA el gate tiene DOS MITADES, y ninguna sustituye a la otra *(Xavier, 2026-08-18)*

La orquestadora escribió en el encargo de `I11.10`: *«el criterio de aceptación no es una tabla de
mutaciones: son gestos»*. **Sustitución, y Xavier la corrigió: es un COMPLEMENTO.**

**Porque cada mitad tapa el agujero de la otra:**
- **Solo gestos** ⇒ un botón que hace **lo que no debe** también es un gesto. Pasa el listón con el
  sistema roto, y encima con la sensación de haber cumplido el criterio nuevo.
- **Solo mutaciones** ⇒ una pantalla puede tener **todo en rojo cuando toca** y seguir costando
  cuatro gestos. Verde entero sobre algo que **nadie puede usar** — que es exactamente la deriva que
  `D23` vino a cortar.

⇒ **Las dos van en el entregable, y por separado**: la tabla de mutaciones dice que **es correcto**,
el recuento de gestos dice que **es usable**. Ninguna de las dos es el gate por sí sola, y una verde
con la otra roja **no es media pieza: es una pieza que no está**.
## ⛔ Si una decisión DESBLOQUEA una pieza, el prompt sale EN EL MISMO TURNO

*(Xavier, 2026-08-18.)* No se espera a que lo pidan. Una decisión tomada y una pieza desbloqueada
**es un encargo listo**, y dejarlo para el turno siguiente le cuesta al usuario un mensaje entero
para decir *«adelante»* — que es tiempo suyo gastado en darle permiso a algo que ya había aprobado.

⭐ **La señal de que lo estás haciendo mal es literal y se busca en tu propio texto:** si el turno
termina con **«dime y te lo escribo»**, **«cuando quieras te lo preparo»** o cualquier variante, es
que **ya deberías haberlo escrito**. *(Cicatriz del mismo día: la orquestadora cerró así el turno
inmediatamente anterior a que Xavier pidiera este raíl — la decisión estaba tomada, la pieza
desbloqueada y el encargo sin escribir.)*

**Las dos excepciones, y solo esas dos:**
- **Desbloquea VARIAS piezas** ⇒ se dice cuáles, se recomienda una **y se escribe la recomendada**.
  No se pregunta cuál antes de escribir ninguna.
- **La pieza necesita un gesto que solo puede hacer el usuario** (firmar, generar una clave,
  conectarse por otra red) ⇒ el prompt se escribe **igual**, con ese gesto marcado como suyo y el
  hueco señalado. Un encargo al que le falta un dato del usuario sigue siendo un encargo.

⇒ Es `feedback-ejecutar-no-anunciar` un piso más arriba: **la tool call en el
mismo turno** vale también para el entregable, y el entregable de la orquestadora **es el prompt**.

## Qué puede hacer directamente (sin sub-sesión)

Cambios menores, seguros y reversibles; consultas de solo lectura; documentación, memoria y
backlog. **La lista concreta de lo que eso significa en tu frente está en su apéndice** — depende
de qué máquinas hay y de qué se puede permitir perder.

> ⛔ **PERO NO mientras una sesión esté corriendo sobre esos mismos ficheros.** Mientras una
> sub-sesión está viva, **los docs de su alcance son SUYOS**: su `backlog.md`, su `AVISOS.md`, su
> `bitacora.md`. La orquestadora escribe **antes de lanzarla o después de que entregue** — nunca
> durante.
>
> *(Cicatriz 2026-08-01: la orquestadora avisó por escrito de que «dos sesiones editando el mismo
> backlog es como se pierde texto»… y acto seguido metió una ficha y una corrección en los ficheros
> que una sesión viva estaba editando. Sobrevivieron **por suerte** —la herramienta llegó a avisar de
> que el fichero había cambiado bajo sus pies—, y quedaron **sin commitear y mezcladas** con el
> trabajo ajeno.)*
>
> **Los dos daños, y el segundo es peor que perder el texto:**
> · La sesión puede tener en memoria una copia **anterior** y escribir encima ⇒ el cambio desaparece
>   sin que nadie lo note.
> · Y aunque sobreviva, **aparece en el diff de la sesión como si fuera suyo** — o alguien lo
>   revierte por no reconocerlo.
>
> **Si el cambio no puede esperar**: no lo escribas — **mándaselo a la sesión** para que lo integre
> ella, que es quien tiene el fichero. Y si ya lo escribiste, **dilo enseguida y enumera exactamente
> qué tocaste**, para que su entrega se pueda reconciliar.

## Qué delega siempre a una sub-sesión

- Cualquier tarea que implique múltiples pasos en la infraestructura.
- Análisis de compatibilidad o exploración de estado desconocido.
- Instalaciones o configuraciones en servidores/nodos.
- Cambios en Kubernetes que afecten a workloads en producción.