smtp-relay/.metodo/workflows
sirxavor 5922c7f5db chore(metodo): EN VUELO entero, gate que ata, deploy/doc, y git no distingue sesiones
Los cinco campos del bloque EN VUELO viajan ahora con el nucleo (antes solo
viajaba el porque). Vocabulario C25 con deploy y doc: 24 de 25 falsos positivos
de un repo los escribia un robot, uno por despliegue. Y el limite del terreno:
en este arbol git no distingue sesiones, asi que lo unico que atribuye es el
mensaje.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-30 17:26:03 +02:00
..
comunicacion-entre-sesiones.md chore(metodo): el relevo — el nucleo y R10 2026-08-30 14:44:21 +02:00
README.md feat(metodo): el PROCEDIMIENTO viaja — .metodo/workflows/ con el canal entre sesiones 2026-08-29 20:20:18 +02:00
sesion-ejecucion.md chore(metodo): llegan los 3 nucleos de sesion (orquestadora, ejecucion, exploracion) 2026-08-30 13:52:33 +02:00
sesion-exploracion.md chore(metodo): llegan los 3 nucleos de sesion (orquestadora, ejecucion, exploracion) 2026-08-30 13:52:33 +02:00
sesion-orquestadora.md chore(metodo): EN VUELO entero, gate que ata, deploy/doc, y git no distingue sesiones 2026-08-30 17:26:03 +02:00

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: los principios son el qué, estos son el cómo corre una sesión.

D5 (ver ../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).