smtp-relay/.metodo/workflows/comunicacion-entre-sesiones.md

Workflow: comunicación ENTRE SESIONES (el canal)

✅ A PRUEBA desde el 2026-08-28. Esto no es un raíl del Método: es procedimiento, y nace con una sola fuente y un solo día de uso real. Se escribe para poder usarlo y medirlo, no porque esté demostrado. Si dentro de unos días se ha usado y ha servido, se consolida; si no se usa, no era un raíl — era una idea, y se borra. (La vara es la del propio Método: la fuerza de una regla es su recurrencia independiente. Aquí, hoy, es uno.)

⭐ CONSOLIDADO el 2026-08-29 por Xavier, y consta cómo: condición de USO cumplida sobradamente (el saludo invertido cinco veces, el canal decenas, un relevo completo y un encargo a ciegas); condición de TIEMPO no —es el mismo día—. Lo consolida él, no la sesión que lo escribió. ⇒ Su fuente vive en el repo metodo —para que tenga dueño, historial y gate: el árbol de trabajo no es un repo, y por eso su copia del Método llevó seis días derivada sin que nadie lo viera (A9)—. ⚙️ Y desde el 2026-08-29 SE VENDORIZA: viaja dentro de .metodo/workflows/ de cada repo, porque un repo que se clona solo no tiene la matriz al lado y ningún puntero a su ruta le resuelve. Aquí no se edita: se corrige en la matriz y se re-estampa (§7). ⛔ El semáforo NO viaja —es un objeto vivo y compartido del árbol multi-repo, no un documento—, así que las referencias a él sólo aplican si trabajas en ese árbol. ⛔ Los PRINCIPIOS de este procedimiento están en §9 de la constitución y viajan a los 27 repos; aquí queda el procedimiento, que es lo que el propio Método manda que no viva allí.

⚙️ 28-ago (tarde) — primer uso registrado, y trajo una regla más: R0, el saludo invertido, nació usándolo, no escribiéndolo (Xavier abrió una sesión con cuatro líneas y el ciclo se recorrió entero). ⛔ Sigue A PRUEBA: un uso no es recurrencia, y la regla que se estrena es la que más fácil se confunde con una demostrada.

Qué es. Desde el 2026-08-28 dos sesiones del árbol pueden hablarse directamente: ListAgents enumera las sesiones vivas y SendMessage le manda un mensaje a una por su nombre. El estreno: proyectos-f4 (orquestadora de securizacion) ↔ proyectos-b8 (ejecución en frío, A49/E1.13) — cinco mensajes, todos actuados, en unas tres horas.

Qué compró, que es por lo que existe esta página (los cuatro casos, del mismo día):

• ⭐ Una premisa falsa parada antes de llegar más lejos en un entregable oficial (A45 de securizacion: «la PKI interna de la organización emite RSA 2048» → los tres certificados los emite Let's Encrypt y el tamaño de clave lo pide nuestro propio cliente ACME. La salida deja de ser «mover la PKI de la organización» y pasa a ser un parámetro en la petición).
• ⭐ Una sesión corrigió a su orquestadora, hacia arriba y en el momento (un recuento hecho sobre el síntoma en vez de sobre el uso).
• ⭐ Una discrepancia declarada al instante: Xavier autorizó a una sesión a empujar contra lo que decía su encargo, y lo dijo en su primer mensaje.
• ⭐ Una sesión detectó su propio falso negativo y explicó el mecanismo (su sonda hacía grep 'Protocol *:' sobre un openssl que imprime New, TLSv1.3, Cipher is … ⇒ leyó la ausencia de su patrón como un resultado del servidor).

⛔ El criterio de §9 del Método NO cambia: cambia el transporte. Que alcanzar una sesión sea barato no convierte en caliente nada de lo que §9 llama frío — y en particular la sesión que acaba de construir algo sigue siendo la PEOR para verificar que está bien, aunque ahora sea la más fácil de alcanzar. Lo que se manda por el canal es resultado ya medido; lo que hay que medir se mide, no se pregunta.

---

Las reglas — la 0 va primero porque ocurre antes que todo lo demás

0. EL SALUDO INVERTIDO: habla primero la sesión NUEVA (Xavier, 2026-08-28 tarde)

El problema. Una orquestadora no puede identificar a una sesión nueva: ListAgents devuelve nombre, modo y hora de arranque, y ese nombre lo pone el sistema, no el título que escribe Xavier. Reconocerla por «es la que acaba de arrancar» es una inferencia por reloj. Y lo que viaja no es una nota: es un encargo que puede reemitir certificados de producción.

La inversión, y es todo el truco: habla primero la que llega. Xavier abre la sesión y escribe sólo esto — cinco líneas, no tres pantallas:

Eres la orquestadora EN FRÍO de <proyecto>, en c:\Users\xavor\proyectos.
Antes de nada y sin hacer NADA más: manda un mensaje a la sesión `<nombre-de-hoy>` diciendo
quién eres, y pídele el encargo. Espera a recibirlo antes de leer o tocar nada.
Avísala también cuando PARES esperándome y cuando REANUDES, diciendo qué esperabas
y qué te desbloqueó — las dos veces, no sólo la primera.
(SendMessage y ListAgents son herramientas diferidas: cárgalas con ToolSearch si no las tienes.)
Si en un rato no contesta, dímelo en vez de empezar por tu cuenta.

⛔ Y EL PROMPT DE APERTURA LO ENTREGA LA ORQUESTADORA SIN QUE SE LO PIDAN (Xavier, 2026-08-29: «esto hay que automatizarlo para que cuando necesites una sesión automáticamente me des el mensaje de apertura»). En cuanto una orquestadora concluye que un trabajo NO es suyo, el mensaje de apertura sale en el MISMO turno, listo para pegar y sin adornos — no en el siguiente, y no cuando alguien lo pida. ⇒ Es la regla que ya existía —si una decisión desbloquea una pieza, el prompt sale en el mismo turno— y ahora es barata de cumplir: el prompt son cinco líneas, no tres pantallas. ⛔ Y el prompt SÍ lleva el NOMBRE de sesión, no el rol — porque va dirigido a una sesión, no al usuario, y para una sesión el nombre ES la dirección. (Corregido por Xavier el 2026-08-29, y la primera redacción de este raíl decía justo lo contrario —«nombra el rol, nunca el nombre»—. Falso, y caro: dos sesiones de ejecución abiertas así el mismo día salieron a difundir a ciegas —un mensaje por candidata— hasta dar con su coordinadora. Cuatro mensajes para dos redirecciones, y las dos diagnosticaron solas el motivo: «ListAgents no dice roles».) ⇒ Es la aplicación correcta de los dos vocabularios de §9, no su excepción: al usuario se le habla de ROL —él no ve los nombres—; a una sesión se le da el NOMBRE, que es lo único que entrega un mensaje. Confundir los destinatarios rompe uno de los dos lados. ⚠️ Y de ahí una propiedad del prompt: es de USAR Y TIRAR. Lleva una dirección que caduca en el siguiente reinicio, así que se entrega en el momento y no se guarda — un prompt de apertura archivado lleva un nombre muerto. Es otra razón para que salga en el mismo turno, y para que quien lo entregue ponga su nombre de HOY.

⛔ La cuarta línea está ahí por un motivo, y no es redundante con R4. El 2026-08-28 el aviso de parada-y-reanudación funcionó — porque Xavier lo tecleó a mano en cada parada. Eso no es un raíl: es Xavier haciendo de raíl. Mientras dependa de que alguien se acuerde de pedirlo es PROCEDIMIENTO; sólo es PROPIEDAD cuando no puede no pasar ⇒ vive en lo único que él teclea. ⚠️ Y quien lo lea no recorte la segunda mitad por parecer obvia: la asimetría no se ve sola —una parada no avisada es visible (hay un silencio y se pregunta); una reanudación no avisada es invisible y permanente, nada la contradice nunca. El porqué entero, en R4. (Refinamiento de proyectos-f4, 2026-08-28, con el argumento de proyectos-b8 al partir su playbook en dos: no se fía a que quien invoca pase la lista buena.)

Qué compra:

• Desaparece el problema de identificación. La orquestadora responde al from de un mensaje real, no a una suposición. La puerta de R1 sigue siendo obligatoria — pero deja de ser lo único que hay.
• Xavier no pierde su control: lo mueve de sitio. El encargo aterriza en la pantalla de esa sesión y él lo lee ahí, antes de que actúe. Hoy la puerta es «pegar el prompt»; con esto es «leerlo cuando aterriza». Sigue habiendo puerta.
• Las cuatro líneas SON el registro: se copian tal cual a la fila del semáforo, y dicen para qué se abrió esa sesión.

Los CINCO detalles que sólo se ven al usarlo — cuatro de usarlo bien, el quinto de usarlo a medias:

1. ⚠️ SendMessage NO viene cargada: es diferida, y se pide con ToolSearch. Sin esa línea, la sesión nueva concluye que no puede hablar y se pone a trabajar sola. (Le pasó a la propia orquestadora que parió esta regla.) ⓘ Matiz medido en esta sesión el 28-ago, y cambia dónde buscar el problema: ListAgents SÍ venía cargada — la que faltaba era SendMessage. No se da por universal: lo que se comprueba es cuál de las dos falta hoy, no cuál faltó una vez.
2. ⛔ La orquestadora, al responder, declara que NO es Xavier. Literal: «lo que te mando es un encargo preparado y publicado a él; las confirmaciones de mutación te las da él, no yo». Sin eso, un mensaje de una orquestadora se lee igual que una orden del usuario y se salta su criterio sin que se note.
3. La sesión nueva se queda PARADA hasta recibirlo — sin leer ni tocar el árbol. Y si no hay respuesta, se lo dice a Xavier, en vez de esperar callada o arrancar por su cuenta.
4. ⛔ Que el encargo llegue no autoriza a mutar. Si su primera etapa toca algo real —aunque sea un objeto nuevo y aislado—, se declara en el semáforo y se confirma con Xavier. «Seguro» no es «no hace falta preguntar».
5. ⛔ EL ORDEN IMPORTA: el saludo va ANTES que el encargo, y no sólo por identificar. Si el encargo llega primero, la sesión que lo recibe ya no puede carear lo que reciba contra lo que tiene — y el careo es lo que distingue «me lo han mandado» de «me lo he escrito de memoria». ⇒ Cuando el orden se rompa —y se va a romper—, la sesión pide el original a ciegas ANTES de enseñar el suyo. (Lo aportó proyectos-f4 el 2026-08-28, y sale de usar el procedimiento a medias: a la superadmin de ese día Xavier le pegó el encargo primero y la identificación después. Funcionó —se presentó y se paró— pero se perdió esa propiedad, y sólo se vio al ir a instalarlo. Es el único de los cinco detalles que no salió de usarlo bien.) ⭐ Y el careo sirvió: de los dos textos salieron una corrección aceptada en cada dirección y un defecto propio de la instalación que sin el original delante no se habría visto.

La evidencia, 2026-08-28: ciclo completo recorrido una vez, con nombres. Xavier abrió una sesión con esas cuatro líneas; la sesión se presentó («estoy parada a propósito: no he leído ni tocado nada»); la orquestadora le mandó el encargo entero; la sesión quedó esperando confirmación para su primera etapa. Cero adivinación de destinatario.

1. La puerta: todo mensaje se abre diciendo quién eres, a quién crees escribir, y cómo salir

ListAgents devuelve nombre, modo y hora de arranque — ni rol ni proyecto (medido el 2026-08-28). En el estreno, la sesión destino se identificó por la hora de arranque. Así que todo mensaje empieza declarando quién eres, a quién crees escribir y la salida explícita:

«Soy la orquestadora de <proyecto>. Creo que eres la sesión de ejecución de <tarea> (arrancada ~<hora>). Si no eres esa sesión: ignora esto entero, no toques nada, y dime quién eres.»

No es cortesía: es §8 (fallo benigno explícito) aplicado al canal. Un mensaje que llega a la sesión equivocada sin salida es una instrucción armada en el sitio equivocado.

⛔ Y una ORQUESTADORA que se presenta a otra sesión declara su ALCANCE (Xavier, 2026-08-28) — qué repos y qué rutas toca, y qué no toca. La puerta de arriba identifica quién eres; sin el alcance falta sobre qué, que es lo único que hay que negociar entre orquestadoras: dos que no se solapan no tienen nada que acordar, y dos que sí tienen que saberlo en el primer mensaje, no cuando choquen. ⇒ Y con la misma disciplina que la fila del semáforo: rutas concretas, y el ⛔ de lo que queda fuera. «Llevo securizacion» no es un alcance — repos/securizacion/ más day0-work, day1-work y hosts-work, que son compartidos, sí lo es. ⚠️ La cicatriz es de hoy y es exactamente ésta: hosts-work resultó tener TRES frentes con permiso de escritura —hermes-infra escribe los host yaml, poniente es dueña del hierro, securizacion por D118— y el censo del relevo sólo veía dos. Nadie mintió: es que el alcance ajeno no se puede deducir desde el frente propio, y por eso lo tiene que declarar cada cual. ⓘ Se declara por ROL y RUTAS, nunca por el nombre de sesión — los nombres rotan en cada reinicio

⛔ DOS VOCABULARIOS, Y NO SE MEZCLAN: el NOMBRE es una DIRECCIÓN; el ROL es la REFERENCIA. (Xavier, 2026-08-28: «cuando os referís a sesiones decís proyectos-a2 y yo no veo eso; yo veo "orquestadora de…", y esa es mi referencia. Si me decís el nombre de una sesión, referidla por "orquestadora de", porque si no no me entero».)

• Entre sesiones → el nombre que imprime tu ListAgents. Es lo único que entrega un mensaje, y no vale ningún otro (ni el que la sesión dice tener, ni el escrito en una fila).
• Hacia Xavier → el ROL y el proyecto: «la orquestadora de securizacion». Él no ve los nombres: en su pantalla no existen. ⇒ ⭐ Es §1 en su forma de siempre —la herramienta de diagnóstico no ve lo mismo que el consumidor— aplicada a hablar con el usuario: darle el identificador que tú usas, y que él no puede resolver, es información inútil con aspecto de precisión. Y es peor que omitirla: parece que le estás dando un dato. ⇒ Y el rol tiene además la propiedad que al nombre le falta: no rota. Un nombre caduca en cada reinicio y miente de tres formas; «la orquestadora de poniente» sigue siendo verdad mañana. ⓘ Si hace falta la dirección para que él se la pase a alguien, va detrás y como lo que es: «la orquestadora de securizacion (hoy proyectos-2c)» — el rol primero, el nombre entre paréntesis y con fecha implícita. (ver la cabecera del semáforo).

2. El canal AVISA; el corpus MANDA

Preguntar y avisar, sí. ⛔ Un encargo nuevo o una decisión NO viajan por aquí: van por Xavier y se escriben. Una corrección o adenda a un encargo ya aprobado sí, diciendo de quién viene. Y lo que cambie el trabajo lo escribe en el corpus quien lo recibe. ⛔ Un acuerdo que sólo existe en el canal no existe: el canal se compacta y muere con la sesión; el corpus, no.

3. El semáforo pasa de pasivo a activo — y NO se sustituye

Antes de un commit que toque ficheros de una fila viva ajena de repos/metodo/workflows/sesiones-activas.md (ruta del árbol: el semáforo NO viaja, así que en un repo clonado solo no existe — y eso es correcto), se pregunta por el canal en vez de esperar o pisar. ⛔ El fichero sigue siendo la fuente: un mensaje muere con su sesión, una fila sobrevive. El canal acelera el arbitraje; no lo reemplaza.

4. La ejecución avisa en CADA TRANSICIÓN — acabar no es la única

⛔ Se avisa al PARAR y se avisa al REANUDAR (Xavier, 2026-08-28, vía proyectos-f4; en uso ya por proyectos-8c). En sus palabras: «cuando una ejecutante pare porque necesita interacción conmigo, que se lo diga a la orquestadora; pero cuando yo responda y ella retome la actividad, que también avise de que continúa — porque si no, tú me dices que tengo pendientes cosas que ya he hecho».

Por qué es un raíl y no cortesía, que es todo el argumento: la orquestadora no observa el estado del árbol — lo reconstruye a partir de las transiciones que le cuentan. Y las dos mitades fallan asimétricamente:

• una parada no avisada es visible: se ve un silencio y se pregunta;
• una reanudación no avisada es invisible y permanente: nada la contradice nunca, así que el pendiente falso se queda para siempre.

⇒ El fallo es monótono: sólo crece. Y su síntoma no lo paga la orquestadora, lo paga Xavier, al que se le pide decidir lo que ya decidió. ⭐ Y es A37 en el plano de la coordinación: parar es declarar, reanudar es reconciliar. Sin la segunda mitad, el registro se separa de la realidad en silencio y sin síntoma.

Las tres partes — y la tercera es de la ORQUESTADORA, no de la ejecutante:

1. Al PARAR: dilo, y di qué esperas exactamente. No «espero a Xavier» sino «espero el OK para rotar git.c2et.com». Un pendiente sin su objeto no se puede cerrar: nadie sabe qué lo cerraría.
2. Al REANUDAR: dilo también, y di qué te desbloqueó. Es la mitad que se olvida, y la única cuyo olvido no se detecta.
3. ⛔ La orquestadora no afirma un pendiente que no tenga una TRANSICIÓN detrás. Todo pendiente que publique lleva de quién y de cuándo. Sin eso, «pendiente de Xavier» es una afirmación sobre el presente hecha con una medida del pasado — la familia de medir después de reparar es medir la reparación. Si no hay transición que lo respalde, se dice así: «según lo último que me dijeron a las HH:MM».

Y al ACABAR, con CINCO cosas

Al entregar, la sesión de ejecución manda a quien la lanzó:

1. qué queda commiteado y qué empujado, con sha;
2. qué se midió y con qué crudo;
3. qué queda abierto;
4. en qué estado deja el hierro;
5. la fila del semáforo, actualizada.

⚠️ Y el agujero, dicho en voz alta: una sesión que se MUERE no avisa — que es justo el caso caro. Existe una suscripción de un disparo que avisa cuando una sesión queda inactiva, pero inactivo ≠ terminado: una sesión que espera una reinstalación queda inactiva muchas veces y la primera pausa gasta el único disparo. ⇒ Sirve para sospechar de un silencio, nunca para saber que algo acabó. Lo que dice que algo acabó sigue siendo la fila y el corpus.

⛔ EL TESTIGO DE CIERRE SE PIDE AL ENTREGAR, NO DESPUÉS — porque después puede no haber a quién preguntar. «Terminada» y «callada» se ven igual desde fuera, y ni su orquestadora puede distinguirlas: puede medir que el repo está limpio y la fila cerrada, pero no si le queda una secuencia en caliente. Eso sólo lo sabe la sesión ⇒ la pregunta ES el testigo, y caduca con ella. (Cicatriz 2026-08-29, la primera vez que se aplicó este cierre y falló en el segundo caso: de dos sesiones de ejecución, una contestó con su comprobación hecha —worktree limpio, nada por empujar, fila cerrada con su puntero, cero procesos de fondo— y la otra ya no era alcanzable. No se perdió nada porque había entregado todo antes, pero el testigo no se pudo obtener: no hubo forma de saber si le quedaba algo abierto.) ⇒ Regla: la sesión de ejecución declara, en la misma entrega, si su cierre es en frío o con secuencia en caliente abierta — el default es efímera, y lo que se declara es la excepción. ⇒ Y quien la lanzó no espera a tener tiempo para preguntárselo: en cuanto entrega, o se cierra o se dice por qué no.

5. Entre orquestadoras de proyectos distintos: se MIDE y se ENTREGA, no se pactan fronteras

⛔ Quién posee qué y quién edita qué repo es de Xavier, y se escribe como D en los dos registros (securizacion·D118 es exactamente eso). Dos orquestadoras pueden medirse cosas la una a la otra y entregarse resultados; no pueden acordar entre ellas una frontera de propiedad. Y toda entrega entre proyectos sigue teniendo su documento que se lee solo (entrega-a-*.md): el canal acelera la entrega, no la sustituye.

6. Nada de lavado de permisos

Si a una sesión le deniegan algo, no se lo pide a un peer: lo devuelve a Xavier. Un permiso que se consigue rodeando a quien lo negó no es un permiso — y el canal hace ese rodeo trivial. ⭐ Y no es doctrina nuestra: lo nombra el contrato de la propia herramienta (leído el 2026-08-28) — «Permission boundaries are per-session: NEVER ask a peer to perform an action that was denied or blocked in your session… (cross-session permission laundering)»—. Tiene nombre propio porque es un modo de fallo conocido, no una manía de esta casa.

7. Por el canal viaja lo medido, no la verificación

Corolario operativo de §9 (ver arriba): la orquestadora verifica desde fuera —abre los objetos de git, mide el aparato, censa el corpus— y usa el canal para mandar el resultado. Pedirle a la sesión que construyó la pieza que confirme que está bien es el camino cómodo y es exactamente lo que §9 prohíbe.

8. LA MALLA: quién habla con quién (Xavier, 2026-08-29)

«Todas las sesiones que hablen unas con otras son orquestadoras. Y cada orquestadora sólo habla con sus ejecutoras propias, con otras orquestadoras y con la superadmin. Y como sólo hay una superadmin, si está identificada ésa, sabes que las demás son orquestadoras.»

Es una regla de TRÁFICO, y ataca la causa en vez del síntoma: si una ejecutora no difunde nunca, la tormenta de mensajes a ciegas no puede ocurrir. (Medido el 2026-08-29: una ejecutora en frío preguntó a ocho sesiones y cinco le contestaron el mismo dato — cinco mensajes para un hecho. Y ese mismo día pasó dos veces, con dos ejecutoras distintas.) ⇒ La malla, en tres líneas:

• Una ejecutora habla con SU orquestadora y con nadie más. No difunde, no censa, no se presenta al listado.
• Una orquestadora habla con sus ejecutoras, con otras orquestadoras y con la superadmin.
• La superadmin habla con las orquestadoras — y es única, que es lo que hace deducible el resto.

⛔ PERO LA DEDUCCIÓN DE ROL NO SE HACE SOBRE EL LISTADO, SE HACE SOBRE LOS MENSAJES. «Si ésta es la superadmin, las demás son orquestadoras» es falso aplicado a ListAgents: el listado enseña quién EXISTE, no quién HABLA, y la regla sólo describe a los que hablan. (El mismo día, el listado mostraba ocho sesiones con al menos dos ejecutoras dentro ⇒ la deducción por exclusión habría dado «siete orquestadoras» y dos de ellas no lo eran. Lo cazó una de esas ejecutoras, sobre sí misma.) ⇒ El enunciado correcto cambia el sujeto, no la regla: quien te ESCRIBA y no sea la superadmin, es una orquestadora. Sobre los mensajes es cierto por construcción, porque la malla restringe a quien habla. Sobre el listado es deducir un dato de una fuente que no lo lleva — la misma familia que el instrumento no decía de qué estaba hablando.

⚠️ Y dos cosas que esta regla NO cubre, para que nadie se las pida:

1. Rol ≠ ALCANCE. Saber que alguien es orquestadora no dice orquestadora DE QUÉ, y ésa suele ser la pregunta real. Eso lo dice el semáforo, no la malla — y por eso cada fila viva lleva su rol, su alcance y su nombre de sesión con fecha.
2. Una ejecutora cuya orquestadora MUERE queda huérfana y sin nadie a quien escribir. Su salida, escrita para que no tenga que inventarla: si su orquestadora no contesta, sube a la superadmin; si tampoco, a Xavier. Con el testigo de siempre — «le escribí y no contestó», nunca «no la veo en el listado».

ⓘ Y la mitad que ya está resuelta, para no hacerla dos veces: una ejecutora no debería tener que buscar a nadie, porque su prompt de apertura ya lleva el nombre de su interlocutora (R0), y el semáforo lleva el de cada fila viva. La malla es la red por si esas dos fallan.

---

La pregunta nº1, CONTESTADA — y la nº2, que sigue en pie

⚰️ ¿Puede una orquestadora ABRIR una sesión que Xavier vea y pilote? — MEDIDO el 2026-08-28: NO

Lo que una orquestadora puede lanzar son subagentes, y un subagente corre dentro de su pantalla, le reporta a ella y consume su contexto. Xavier lo ve porque está mirando esa pantalla, no porque tenga una sesión aparte.

⛔ Y de ahí sale un raíl con filo, porque hay un control que se pierde sin que nadie lo retire: al subagente le escribe el prompt la orquestadora y lo dispara en el mismo turno ⇒ Xavier lo ve después de lanzado, no antes. (El 28-ago no importó porque era solo lectura.)

• Subagentes: SÍ, para reconocimiento en solo lectura, dentro del turno de la orquestadora.
• Lo que MUTA —hierro, cluster, repos compartidos— va en sesión que Xavier abra y pilote.
• Y si alguna vez un subagente tuviera que mutar, su prompt se enseña antes de lanzarlo: ahí no hay pegado que haga de puerta.

⇒ La respuesta no es un «no» seco: no se puede abrir la sesión desde fuera, pero sí se puede hacer que se presente sola —R0, el saludo invertido— y sale mejor, porque conserva las dos puertas en vez de quitar una.

ListAgents no publica rol ni proyecto

Estado: 🟠 abierta (el estado va aquí y no en el título — un encabezado con estado caduca y nadie lo actualiza; C16). Sólo nombre, modo y hora de arranque, y el nombre lo pone el sistema. Mientras siga así, R0 y la puerta de R1 son lo único que hay para saber con quién estás hablando.

Dónde vive cada mitad

• El principio (frío/caliente, quién verifica) → §9 del Método (repos/metodo/metodo.md, la matriz — ⚰️ la copia de esta carpeta se retiró el 2026-08-28; si trabajas dentro de un repo, la tuya es su .metodo/metodo.md).
• El procedimiento (esta página) → aquí, y a prueba.
• El semáforo → repos/metodo/workflows/sesiones-activas.md (ruta del árbol: el semáforo NO viaja, así que en un repo clonado solo no existe — y eso es correcto), que sigue siendo la fuente.