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

Workflow: sesión ORQUESTADORA — 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 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 —qué debes, qué esperas, cuál es el hilo—, en el sitio que tu árbol use para arbitrar sesiones concurrentes. Se reescribe, no crece.
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.

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.