# 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`](../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.