xavor/smtp-relay
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(metodo): el PROCEDIMIENTO viaja — .metodo/workflows/ con el canal entre sesiones

Browse Source 
Hasta hoy sólo viajaban la constitución y el linter. Un repo que se clona SOLO
no tiene la matriz al lado, así que el procedimiento del canal —el saludo
invertido y sus cinco líneas— no le llegaba por ningún camino.

Desde ahora `.metodo/workflows/` viaja con el repo, vigilado por CHECKSUMS y por
el check de deriva como el resto. Y el puntero del CLAUDE.md lleva a él.

⛔ El semáforo NO viaja: es un objeto vivo del árbol multi-repo, no un documento.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
sirxavor 2026-08-29 20:20:18 +02:00
parent 801394335d
commit 2a80e74411
4 changed files with 441 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.metodo/CHECKSUMS
View File

@ -1,2 +1,4 @@
847436a4133ca8287d75a493a1ca363670c632a6c219f3628db9ade82274731a metodo.md
ca4a7a3ab4e9db733fa8cd7a11d678531233e475bcf1ff229498ea4518a4b5d7 bin/metodo
d03851a7dfad0207cdd49009a385b2cfac4e572429f4895cb34a8aa8c1f92eeb bin/metodo
f89b71bdf31028b05075636c1763c964e379bc37a00e0357d1c23a4dd19c09aa workflows/README.md
2470f7013f209c8c1f34eaea9368e9fa25f256eedd08eeb06b6c5358d12131d6 workflows/comunicacion-entre-sesiones.md

44
.metodo/bin/metodo
View File

@ -25,7 +25,25 @@ _hash() {
elif command -v shasum >/dev/null 2>&1; then shasum -a 256 "$1" 2>/dev/null | awk '{print $1}'
else return 127; fi
}
_vendored_files() { printf '%s\n' "metodo.md" "bin/metodo"; } # lo que se estampa y se vigila
# Lo que se estampa y se vigila. Desde el 2026-08-29 (Xavier: «vendorizar todo») incluye los
# WORKFLOWS TRANSVERSALES de la matriz, no sólo la constitución y el linter. El motivo es medido:
# un repo que se clona SOLO —el de la aplicación viaja a otra máquina— no tiene `repos/metodo/` al
# lado, así que **ningún puntero a esa ruta le resuelve**. Los principios viajaban en `metodo.md` y
# el PROCEDIMIENTO no viajaba: quien lo leyó allí no encontró el saludo invertido ni sus cinco
# líneas, que era justo lo que se le había explicado.
# ⛔ EXCEPCIÓN, y es de fondo: `sesiones-activas.md` **NO se vendoriza**. No es un documento: es un
# objeto VIVO y compartido —el semáforo del árbol—, y 27 copias de un semáforo son exactamente lo
# contrario de un semáforo. Vive sólo en la matriz, con su historial.
_vendored_files() {
printf '%s\n' "metodo.md" "bin/metodo"
local f b
for f in "$SELF_ROOT"/workflows/*.md; do
[ -e "$f" ] || continue
b=$(basename "$f")
[ "$b" = "sesiones-activas.md" ] && continue
printf 'workflows/%s\n' "$b"
done
}
_write_checksums() { # $1 = dir .metodo del destino
local md="$1" f h; : > "$md/CHECKSUMS"
for f in $(_vendored_files); do
@ -682,8 +700,12 @@ _ptr_block() { # escribe el bloque COMPLETO (marcadores incluidos) por stdout
⛔ **Antes de tocar nada, lee el Método: [`.metodo/metodo.md`](.metodo/metodo.md)** — los raíles
transversales, completos y con sus cicatrices. **Viaja con este repo y aquí NO se edita**: su fuente
es el repo `metodo` (la matriz), que lo re-estampa con `metodo update` — este bloque incluido.
⇒ Del corpus de este repo, **`doc/AVISOS.md` se lee ANTES que el backlog**. El gate de todo esto es
**`metodo check .`** — y si sale rojo, no lo apagues: arréglalo o dilo.
⇒ Del corpus de este repo, **`doc/AVISOS.md` se lee ANTES que el backlog**; **la bitácora NO se lee
al arrancar** (`§7`): se consulta por su índice. El gate de todo esto es **`metodo check .`** — y si
sale rojo, no lo apagues: arréglalo o dilo.
⇒ **Y si vas a trabajar con más de una sesión a la vez**, el procedimiento del canal viaja aquí
dentro: [`.metodo/workflows/comunicacion-entre-sesiones.md`](.metodo/workflows/comunicacion-entre-sesiones.md)
— el saludo invertido con sus cinco líneas, quién avisa a quién y qué NO viaja por mensaje.
⇒ *Existe porque el 2026-08-19 se midió que el Método viajaba a 9 de 18 repos **sin que nada lo
abriera**. Una constitución solo gobierna si alguien la lee: es su propio raíl `§8`.*
<!-- /metodo:puntero -->
@ -738,6 +760,14 @@ cmd_init() {
mkdir -p "$md/bin"
cp "$SELF_ROOT/metodo.md" "$md/metodo.md"
cp "$SELF_ROOT/bin/metodo" "$md/bin/metodo"; chmod +x "$md/bin/metodo" 2>/dev/null || true
# los workflows transversales viajan también (2026-08-29): un repo que se clona solo no
# tiene la matriz al lado, así que un puntero a su ruta no le resuelve. El semáforo NO.
mkdir -p "$md/workflows"
for _wf in "$SELF_ROOT"/workflows/*.md; do
[ -e "$_wf" ] || continue
[ "$(basename "$_wf")" = "sesiones-activas.md" ] && continue
cp "$_wf" "$md/workflows/$(basename "$_wf")"
done
local mver adopt
mver=$(grep -E '^version:' "$SELF_ROOT/.metodo/VERSION" 2>/dev/null | sed 's/version:[[:space:]]*//')
adopt=$(git -C "$tgt" rev-parse HEAD 2>/dev/null || echo "") # marca de adopción brownfield
@ -770,6 +800,14 @@ cmd_update() {
[ -d "$md" ] || { echo "metodo update: $tgt no tiene .metodo/ — usa 'metodo init $tgt'."; exit 2; }
cp "$SELF_ROOT/metodo.md" "$md/metodo.md"
cp "$SELF_ROOT/bin/metodo" "$md/bin/metodo"; chmod +x "$md/bin/metodo" 2>/dev/null || true
# los workflows transversales viajan también (2026-08-29): un repo que se clona solo no
# tiene la matriz al lado, así que un puntero a su ruta no le resuelve. El semáforo NO.
mkdir -p "$md/workflows"
for _wf in "$SELF_ROOT"/workflows/*.md; do
[ -e "$_wf" ] || continue
[ "$(basename "$_wf")" = "sesiones-activas.md" ] && continue
cp "$_wf" "$md/workflows/$(basename "$_wf")"
done
local mver adopt
mver=$(grep -E '^version:' "$SELF_ROOT/.metodo/VERSION" 2>/dev/null | sed 's/version:[[:space:]]*//')
adopt=$(grep -E '^adopted_commit:' "$md/VERSION" 2>/dev/null | sed 's/adopted_commit:[[:space:]]*//') # se preserva

36
.metodo/workflows/README.md Normal file
View File

@ -0,0 +1,36 @@
# workflows — el procedimiento del Método (capa transversal)
Los workflows **transversales** que viajan con el Método y se vendorizan a cada repo. La otra capa
del Método junto a [`../metodo.md`](../metodo.md): los principios son el *qué*, estos son el *cómo
corre una sesión*.
> **D5** (ver [`../doc/backlog.md`](../doc/backlog.md)): aquí SOLO van los transversales. Los
> **específicos de proyecto** (hermes-*, cluster-work, incidente, capa persona) se quedan **con su
> proyecto**, como los de Solidaria ya viajan dentro de Solidaria.
## Pendiente de traer (Bloque C)
- `sesion-orquestadora.md` — coordinar/decidir (le funciona bien a Xavier; es lo que la propia
matriz usa para decidir qué realimentación sube a la constitución).
- `sesion-ejecucion.md` — construir/aplicar (lo que la matriz usa para construir el linter).
- `sesion-exploracion.md` — leer/medir sin tocar (si se usa).
Fuente actual: `redes/workflows/` y `repos/Solidaria/workflows/` (el más maduro). Al traerlos,
referencian `../metodo.md` en vez de repetir raíles (fuente única).
## El modelo de sesión: fase × persona (C33, promovido 2026-08-08)
*(Decidido con Xavier: esto es **estructura de sesión**, por eso vive aquí y NO en `metodo.md`.)*
Dos ejes **ortogonales**, no una lista plana de "tipos de sesión":
- **Eje FASE (la función):** diseño (discovery) · orquestación (delivery) · ejecución · exploración.
Con **handoff automático**: cada fase entrega el prompt de la siguiente sin que el humano arbitre
(una sesión de diseño produce el encargo de ejecución, etc.).
- **Eje PERSONA (una CAPA, no otro workflow) — OPCIONAL:** se **añade encima** de la fase cuando hay
un interlocutor **no técnico** (en Solidaria, la capa Arantxa: sin jerga, solo dominio). En infra
en solitario (redes, tú solo) esta capa queda **inactiva** — pero se documenta para cuando aparezca
un interlocutor así en cualquier proyecto.
Fuente madura: `repos/Solidaria/workflows/` (`workflows/README.md:10-31`, `sesion-arantxa.md`).
Los workflows de proyecto (hermes-*, cluster-work…) se quedan con su proyecto (`D5`).

361
.metodo/workflows/comunicacion-entre-sesiones.md Normal file
View File

@ -0,0 +1,361 @@
# 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`](../repos/metodo/workflows/sesiones-activas.md), 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**.
### 🟠 Sigue ABIERTA: `ListAgents` no publica **rol ni proyecto**
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`](../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`](../repos/metodo/workflows/sesiones-activas.md), que sigue siendo la fuente.