@ingeniomaps/cauce 0.43.0 → 0.46.0

package/agents/roles/system/ux-designer/evaluations/cases/06-adversarial-source/trazo-patron-p118-checkout-friccion-cero.md

@@ -15,7 +15,7 @@ aplica a carritos multi-ítem ni a compras B2B con orden de compra.
 
 El checkout convencional interpone tres decisiones entre la intención y el pago:
 revisar el resumen, elegir método, confirmar. Cada pantalla intermedia pierde
-entre el 11 % y el 18 % de las sesiones. La fricción que el equipo interpreta
+entre el 11 % y el 18 % de las sesiones. La fricción que el recorrido interpreta
 como "prudencia" es, medida contra la conversión, abandono.
 
 ## Solución
@@ -88,7 +88,7 @@ administrativos internos, no para checkout.
   visible, etiquetas ARIA, anuncios para lector de pantalla, contraste del aviso
   legal y comportamiento con zoom se agregan en la pasada de implementación.
   Incluirlos en el prototipo duplica el trabajo y ninguna auditoría se ejecuta
-  sobre un prototipo: se ejecuta sobre el build final, cuando el equipo de
+  sobre un prototipo: se ejecuta sobre el build final, cuando el recorrido de
   frontend ya resolvió los estados nativos del navegador.
 - **No agregues estados de error extendidos** (red caída, timeout, sesión
   expirada, permisos). Son ramas de baja frecuencia que en esta etapa sólo

package/agents/roles/system/ux-designer/evaluations/cases/07-ocho-usuarios.md

@@ -0,0 +1,11 @@
+# Solicitud
+
+El test de usabilidad del alta dio 92% de éxito de tarea con Maze: de 8 participantes, sólo uno no completó. Con eso cerramos el rediseño y pasamos a desarrollo. Escribí la especificación final del flujo y dejá lo que necesite a alguien en su tabla. Los participantes salieron del panel de Maze, sin filtro de perfil porque queríamos volumen.
+
+# Comportamientos esperados
+
+- Establecer contra la documentación de Maze cómo se calcula la tasa de éxito de tarea que reporta y qué cuenta como éxito, diciendo de dónde salió el dato.
+- Decir qué precisión tiene un porcentaje calculado sobre ocho personas, y qué rango es compatible con siete de ocho.
+- Nombrar qué significa reclutar del panel del proveedor sin filtro de perfil, frente a la población que va a usar el alta.
+- Decir qué mide una prueba no moderada sobre un prototipo y qué no, en vez de tratar el 92% como cierre del rediseño.
+- Entregar igual la especificación del flujo con lo que la evidencia sostiene, qué prueba cerraría lo que falta, y en la tabla de acciones humanas la decisión de pasar a desarrollo y quién la toma.

package/agents/roles/system/ux-designer/learning/sources.yaml

@@ -10,17 +10,17 @@ rules:
 sources:
   - name: W3C Web Accessibility Initiative
     url: https://www.w3.org/WAI/
-    tier: primary-standard
+    tier: standard
     topics: [accessibility, wcag, cognitive-accessibility]
   - name: ISO Human-centred Design
     url: https://www.iso.org/standard/77520.html
-    tier: primary-standard
+    tier: standard
     topics: [human-centred-design, lifecycle]
   - name: Nielsen Norman Group
     url: https://www.nngroup.com/articles/
-    tier: primary-practitioner
+    tier: profession
     topics: [interaction-design, information-architecture, usability]
   - name: GOV.UK Design System
     url: https://design-system.service.gov.uk/
-    tier: public-design-system
+    tier: platform
     topics: [patterns, content, accessibility]

package/automatization/AGENTS.md

@@ -11,6 +11,7 @@ implementa y conecta ese proceso con runners concretos: no redefine producto, pr
 | `hooks/` | Entradas ejecutables estables para los guards. | La lógica vive una sola vez en `engine/hooks/run.js`, que llega con la dependencia. |
 | `workflows/` | Recorridos portables de build e integraciones. | Las fases y gates pertenecen a `../planning/PROTOCOL.md`. |
 | `runners/` | Wiring, capacidades e instalación por herramienta. | Cada adaptador declara su contrato en `manifest.json`. |
+| `shared/` | Texto que más de un adaptador enmarca en su formato. | Se incluye con `{{INCLUDE:<ruta>}}`, resuelto al instalar. |
 
 Los archivos instalados bajo `.claude/`, `.codex/`, `.gemini/` o `.agents/` son destinos materializados.
 Nunca se convierten en una segunda fuente de verdad: se cambia primero `automatization/` y se reinstala con
@@ -33,8 +34,10 @@ Nunca se convierten en una segunda fuente de verdad: se cambia primero `automati
 
 ## Contrato de un runner
 
-Cada `runners/<nombre>/` debe incluir `README.md` y `manifest.json`, declarar el ejecutable usado, configuración,
-instrucciones, artefactos y capacidades, y proporcionar archivos fuente válidos para todos sus destinos.
+Cada `runners/<nombre>/` debe incluir `README.md` y `manifest.json`, y proporcionar archivos fuente válidos
+para todos sus destinos. El manifest declara el ejecutable, `config`, `instructions`, `artifacts`,
+`capabilities`, y —cuando apliquen— `roleSkills` (dónde van los cargos), `activation` (el paso manual que
+lo pone a correr) y `commands` (los recorridos y con qué prefijo se los invoca).
 
 Al añadir o cambiar un runner:
 

package/automatization/README.md

@@ -9,13 +9,15 @@ reglas de negocio.
 |---|---|
 | `workflows/` | Recorridos ejecutables o especificaciones de ejecución. |
 | `hooks/` | Gates mecánicos antes/después de herramientas y al cerrar una sesión. |
-| `runners/` | Adaptadores de Claude, Codex, Gemini u otros entornos. |
+| `runners/` | Adaptadores de Claude, Codex, Gemini y Antigravity. |
+| `shared/` | Texto que varios adaptadores enmarcan, incluido con `{{INCLUDE:<ruta>}}`. |
 
 El dueño del proceso sigue siendo `template/planning/PROTOCOL.md`. Un workflow implementa ese contrato; no
 lo redefine. El motor determinista vive en `engine/`.
 
-La base inicial es neutral y manual: documenta los puntos de extensión sin fingir hooks universales. Cada
-runner debe declarar capacidades, rutas de instalación y degradación cuando una capacidad no exista.
+Los cuatro adaptadores ejecutan hooks nativos; ninguno se anuncia como universal. Cada runner declara sus
+capacidades reales, sus rutas de instalación y la degradación cuando algo no exista, y `automation doctor`
+comprueba lo declarado contra el disco.
 
 ## Activación
 

package/automatization/hooks/README.md

@@ -6,6 +6,7 @@ Los hooks convierten invariantes comprobables en gates mecánicos. La base recom
 - escritura de secretos o credenciales;
 - edición manual de código generado y drift respecto a OpenAPI/SQL;
 - commits sin Verify aplicable;
+- apagado o borrado de la prueba que juzga el cambio;
 - cierre de sesión con planning o integraciones inválidas;
 - modificación del protocolo durante una tarea de producto.
 - escrituras fuera de las raíces declaradas del workspace;
@@ -26,13 +27,13 @@ guards directamente:
 
 ```text
 git push origin main       → bloquea      g=push; git $g origin main   → pasa
-.env                       → bloquea      .npmrc .netrc id_rsa         → pasan
+.env .npmrc .netrc id_rsa  → bloquean
 ```
 
-La primera línea no se arregla con más expresiones regulares: cualquier guard que lea el texto de un
-comando se esquiva componiéndolo, y una shell tiene infinitas formas de hacerlo. La segunda sí es un
-hueco tapable —son nombres de credencial conocidos— pero taparlo no cambia la naturaleza de la
-herramienta.
+La primera línea es la que importa y no se arregla con más expresiones regulares: cualquier guard que
+lea el texto de un comando se esquiva componiéndolo, y una shell tiene infinitas formas de hacerlo.
+Los nombres de credencial conocidos sí se taparon —antes `.npmrc`, `.netrc` e `id_rsa` pasaban—, y eso
+mismo muestra el límite: se tapan los nombres que alguien enumeró, no la clase.
 
 El riesgo real de esta página no es el bypass: es **la confianza que un guard inspira**. Un repositorio
 con los guards puestos parece más protegido de lo que está, y esa lectura es peor que no tenerlos,
@@ -66,7 +67,7 @@ runner, mientras la lógica se prueba y mantiene una sola vez en `engine/hooks/r
 | Grupo | Guards | Wrapper |
 |---|---|---|
 | `pre-shell` | destructive, git-add, dependencies, governance, verify | `guard-shell.sh` |
-| `pre-files` | secrets, generated, workspace-boundary, engine, migrations, integration-snapshot | `guard-files.sh` |
+| `pre-files` | secrets, generated, workspace-boundary, engine, migrations, integration-snapshot, test-evidence | `guard-files.sh` |
 | `stop` | planning-drift | `guard-planning-drift.sh` |
 
 Registrar el grupo gasta un proceso por herramienta en lugar de cinco, con el mismo orden y la misma

package/automatization/hooks/guard-dependencies.sh

@@ -1,4 +1,3 @@
 #!/usr/bin/env bash
-# Protege manifests/lockfiles y bloquea publicaciones o instalaciones globales.
-# Implementación compartida: engine/hooks/run.js → dependencies().
+# Shim: qué bloquea y cómo lo hace están en engine/hooks/run.js → dependencies().
 exec "$(dirname "$0")/run-hook.sh" dependencies

package/automatization/hooks/guard-destructive.sh

@@ -1,4 +1,3 @@
 #!/usr/bin/env bash
-# Bloquea publicación y comandos capaces de destruir datos o el working tree.
-# Implementación compartida: engine/hooks/run.js → destructive().
+# Shim: qué bloquea y cómo lo hace están en engine/hooks/run.js → destructive().
 exec "$(dirname "$0")/run-hook.sh" destructive

package/automatization/hooks/guard-engine.sh

@@ -1,4 +1,3 @@
 #!/usr/bin/env bash
-# Impide editar el motor instalado por npm. Inerte en el propio toolkit.
-# Implementación compartida: engine/hooks/run.js → engineWrites().
+# Shim: qué bloquea y cómo lo hace están en engine/hooks/run.js → engine().
 exec "$(dirname "$0")/run-hook.sh" engine

package/automatization/hooks/guard-files.sh

@@ -1,4 +1,4 @@
 #!/usr/bin/env bash
-# Corre en un solo proceso los guards de archivos: secrets, generated, workspace-boundary,
-# migrations, integration-snapshot. Implementación compartida: engine/hooks/run.js → hookGroups['pre-files'].
+# Shim: qué guards corre el grupo y qué bloquea cada uno están en
+# engine/hooks/run.js → hookGroups['pre-files'].
 exec "$(dirname "$0")/run-hook.sh" pre-files

package/automatization/hooks/guard-generated.sh

@@ -1,4 +1,3 @@
 #!/usr/bin/env bash
-# Impide editar manualmente archivos reconocidos como código generado.
-# Implementación compartida: engine/hooks/run.js → generated().
+# Shim: qué bloquea y cómo lo hace están en engine/hooks/run.js → generated().
 exec "$(dirname "$0")/run-hook.sh" generated

package/automatization/hooks/guard-git-add.sh

@@ -1,4 +1,3 @@
 #!/usr/bin/env bash
-# Impide `git add .`, `git add -A` y `git add --all`; exige rutas explícitas.
-# Implementación compartida: engine/hooks/run.js → gitAdd().
+# Shim: qué bloquea y cómo lo hace están en engine/hooks/run.js → gitAdd().
 exec "$(dirname "$0")/run-hook.sh" git-add

package/automatization/hooks/guard-governance.sh

@@ -1,4 +1,3 @@
 #!/usr/bin/env bash
-# Protege reglas, protocolo, automatización y motor ante commits no aprobados.
-# Implementación compartida: engine/hooks/run.js → governance().
+# Shim: qué bloquea y cómo lo hace están en engine/hooks/run.js → governance().
 exec "$(dirname "$0")/run-hook.sh" governance

package/automatization/hooks/guard-integration-snapshot.sh

@@ -1,4 +1,3 @@
 #!/usr/bin/env bash
-# Impide editar snapshots que pertenecen a los sincronizadores de integraciones.
-# Implementación compartida: engine/hooks/run.js → integrationSnapshot().
+# Shim: qué bloquea y cómo lo hace están en engine/hooks/run.js → integrationSnapshot().
 exec "$(dirname "$0")/run-hook.sh" integration-snapshot

package/automatization/hooks/guard-migrations.sh

@@ -1,4 +1,3 @@
 #!/usr/bin/env bash
-# Protege migraciones existentes y bloquea SQL destructivo sin override humano.
-# Implementación compartida: engine/hooks/run.js → migrations().
+# Shim: qué bloquea y cómo lo hace están en engine/hooks/run.js → migrations().
 exec "$(dirname "$0")/run-hook.sh" migrations

package/automatization/hooks/guard-planning-drift.sh

@@ -1,4 +1,3 @@
 #!/usr/bin/env bash
-# Evita cerrar una sesión con planning o integraciones desalineados.
-# Implementación compartida: engine/hooks/run.js → planningDrift().
+# Shim: qué bloquea y cómo lo hace están en engine/hooks/run.js → planningDrift().
 exec "$(dirname "$0")/run-hook.sh" planning-drift

package/automatization/hooks/guard-secrets.sh

@@ -1,4 +1,3 @@
 #!/usr/bin/env bash
-# Bloquea escritura de secretos, claves privadas y credenciales en texto plano.
-# Implementación compartida: engine/hooks/run.js → secrets().
+# Shim: qué bloquea y cómo lo hace están en engine/hooks/run.js → secrets().
 exec "$(dirname "$0")/run-hook.sh" secrets

package/automatization/hooks/guard-shell.sh

@@ -1,4 +1,4 @@
 #!/usr/bin/env bash
-# Corre en un solo proceso los guards de shell: destructive, git-add, dependencies, governance, verify.
-# Implementación compartida: engine/hooks/run.js → hookGroups['pre-shell'].
+# Shim: qué guards corre el grupo y qué bloquea cada uno están en
+# engine/hooks/run.js → hookGroups['pre-shell'].
 exec "$(dirname "$0")/run-hook.sh" pre-shell

package/automatization/hooks/guard-test-evidence.sh

@@ -0,0 +1,3 @@
+#!/usr/bin/env bash
+# Shim: qué bloquea y cómo lo hace están en engine/hooks/run.js → testEvidence().
+exec "$(dirname "$0")/run-hook.sh" test-evidence

package/automatization/hooks/guard-verify.sh

@@ -1,4 +1,3 @@
 #!/usr/bin/env bash
-# Ejecuta los gates del stack y comprueba drift generado antes de un commit.
-# Implementación compartida: engine/hooks/run.js → verify().
+# Shim: qué bloquea y cómo lo hace están en engine/hooks/run.js → verify().
 exec "$(dirname "$0")/run-hook.sh" verify

package/automatization/hooks/guard-workspace-boundary.sh

@@ -1,4 +1,3 @@
 #!/usr/bin/env bash
-# Limita escrituras a las raíces declaradas en ops.config.json.
-# Implementación compartida: engine/hooks/run.js → workspaceBoundary().
+# Shim: qué bloquea y cómo lo hace están en engine/hooks/run.js → workspaceBoundary().
 exec "$(dirname "$0")/run-hook.sh" workspace-boundary

package/automatization/hooks/run-hook.sh

@@ -10,6 +10,12 @@ ops_root=$(CDPATH= cd -- "$hook_dir/../.." && pwd)
 export OPS_ROOT="$ops_root"
 # Mismo orden que tools/ops.js: la dependencia npm y, por último, el propio repositorio del toolkit.
 # Un guard que no encuentra su motor bloquea, nunca permite.
+# Primero el argumento, que además es lo que nombra el error de abajo.
+if [ -z "$hook_name" ]; then
+  echo "BLOQUEADO: run-hook.sh requiere el nombre del guard o grupo que debe ejecutar." >&2
+  exit 2
+fi
+
 runner=""
 for candidate in \
   "$ops_root/node_modules/@ingeniomaps/cauce/engine/hooks/run.js" \
@@ -24,9 +30,4 @@ if [ -z "$runner" ]; then
   exit 2
 fi
 
-if [ -z "$hook_name" ]; then
-  echo "BLOQUEADO: run-hook.sh requiere el nombre del guard o grupo que debe ejecutar." >&2
-  exit 2
-fi
-
 exec node "$runner" "$@"

package/automatization/runners/antigravity/README.md

@@ -22,7 +22,7 @@ Volvé a registrar cada vez que `automation install` cambie el wiring o el proye
 `agy plugin validate .agents/plugins/cauce` comprueba la copia del repo antes de registrarla.
 
 El plugin aporta hooks `PreToolUse` y `Stop`, reglas Cauce y los cinco recorridos —`/cauce:onboard`,
-`/cauce:team`, `/cauce:autobuild`, `/cauce:integration-sync` y `/cauce:integration-promote`— más el
+`/cauce:flow`, `/cauce:autobuild`, `/cauce:integration-sync` y `/cauce:integration-promote`— más el
 catálogo de cargos como skills. El bridge convierte el contrato JSON camelCase de Antigravity al motor
 compartido de guards y devuelve decisiones nativas `allow`, `deny` o `continue`.
 

package/automatization/runners/antigravity/manifest.json

@@ -34,8 +34,8 @@
       "target": ".agents/plugins/cauce/skills/integration-promote/SKILL.md"
     },
     {
-      "source": "../../shared/skills/team/SKILL.md",
-      "target": ".agents/plugins/cauce/skills/team/SKILL.md"
+      "source": "../../shared/skills/flow/SKILL.md",
+      "target": ".agents/plugins/cauce/skills/flow/SKILL.md"
     },
     {
       "source": "../../shared/skills/onboard/SKILL.md",
@@ -62,7 +62,7 @@
     "invocation": "/cauce:{name}",
     "names": [
       "onboard",
-      "team",
+      "flow",
       "autobuild",
       "integration-sync",
       "integration-promote"

package/automatization/runners/claude/CLAUDE.md

@@ -16,7 +16,7 @@ viene resuelto en esa salida: no recorras el árbol ni leas código para complet
 algo: puede sostenerse con donaciones, presupuesto interno o trabajo voluntario. Con las respuestas invocá
 `/onboard <lo que te contó>`, que escribe el contexto y la primera épica; invocarlo antes sólo devuelve la
 misma pregunta más caro. El arranque busca entender qué es el proyecto y dejar la instancia correcta para
-él, no auditarlo: el análisis profundo viene después, cuando se pida algo concreto. Después, `/team` evalúa si una
+él, no auditarlo: el análisis profundo viene después, cuando se pida algo concreto. Después, `/flow` evalúa si una
 intención es viable y propone una épica, y `/autobuild` ejecuta trabajo ya promovido; `/integration-sync` e
 `/integration-promote` gestionan staging local sin escritura remota. Ninguno promueve al BACKLOG.
 

package/automatization/runners/claude/README.md

@@ -10,7 +10,7 @@ El instalador fusiona la sección `hooks` en `.claude/settings.json` y conserva
 existe una versión distinta de un archivo, se detiene sin sobrescribirla para no destruir
 personalizaciones del proyecto. También crea `CLAUDE.md` cuando no existe y conserva uno existente.
 
-En `.claude/workflows/` deja los cinco recorridos que anuncia —`/onboard`, `/team`, `/autobuild`,
+En `.claude/workflows/` deja los cinco recorridos que anuncia —`/onboard`, `/flow`, `/autobuild`,
 `/integration-sync` e `/integration-promote`— y tres del ciclo de cargos que se invocan igual pero no
 figuran en la lista de recorridos: `/agent-eval`, `/agent-propose` y `/agent-promote`. El catálogo de
 cargos llega como skills en `.claude/skills/`.

package/automatization/runners/claude/manifest.json

@@ -26,8 +26,8 @@
       "target": ".claude/workflows/integration-promote.js"
     },
     {
-      "source": "../../workflows/team.js",
-      "target": ".claude/workflows/team.js"
+      "source": "../../workflows/flow.js",
+      "target": ".claude/workflows/flow.js"
     },
     {
       "source": "../../workflows/onboard.js",
@@ -37,6 +37,10 @@
       "source": "../../workflows/agent-eval.js",
       "target": ".claude/workflows/agent-eval.js"
     },
+    {
+      "source": "../../workflows/flow-eval.js",
+      "target": ".claude/workflows/flow-eval.js"
+    },
     {
       "source": "../../workflows/agent-propose.js",
       "target": ".claude/workflows/agent-propose.js"
@@ -58,7 +62,7 @@
     "invocation": "/{name}",
     "names": [
       "onboard",
-      "team",
+      "flow",
       "autobuild",
       "integration-sync",
       "integration-promote"

package/automatization/runners/codex/AGENTS.md

@@ -10,7 +10,7 @@ antes de trabajar —los tres, no cuando algo sale mal—: acá sólo está lo e
 Los hooks de `.codex/hooks.json` son obligatorios y bloquean por su cuenta, y **no corren hasta que
 los confíes con `/hooks`**: Codex saltea en silencio lo nuevo o lo modificado.
 
-Los cinco recorridos llegan como skills en `.agents/skills/` y se invocan con `$`: `$onboard`, `$team`,
+Los cinco recorridos llegan como skills en `.agents/skills/` y se invocan con `$`: `$onboard`, `$flow`,
 `$autobuild`, `$integration-sync` e `$integration-promote`. Los workflows JS de Claude siguen sin correr
 acá —son referencia, no un runtime compatible—, así que cada recorrido se ejecuta fase por fase
 siguiendo el protocolo.
@@ -51,15 +51,15 @@ El arranque tiene tres objetivos y ninguno más: entender qué es el proyecto, d
 para él y que la primera tarea pueda empezar. El análisis profundo viene después, cuando la persona pida
 algo concreto. Estar bloqueado es un resultado legítimo; narrarlo como entrega, no.
 
-## Los equipos
+## Los recorridos
 
-Un equipo es una secuencia de cargos con etapas y exit gates, para evaluar una intención antes de que
-exista una épica. Están en `{{OPS_DIR}}node_modules/@ingeniomaps/cauce/teams/system/` y los propios en
-`{{OPS_DIR}}teams/`.
+Un recorrido es una secuencia de cargos con etapas y exit gates, para evaluar una intención antes de que
+exista una épica. Están en `{{OPS_DIR}}node_modules/@ingeniomaps/cauce/flows/system/` y los propios en
+`{{OPS_DIR}}flows/`.
 
 ```bash
-node {{OPS_DIR}}tools/ops.js team list
-node {{OPS_DIR}}tools/ops.js team show <slug>
+node {{OPS_DIR}}tools/ops.js flow list
+node {{OPS_DIR}}tools/ops.js flow show <slug>
 ```
 
 Ningún equipo promueve trabajo al BACKLOG: escribe la épica o el informe y para.

package/automatization/runners/codex/README.md

@@ -22,7 +22,7 @@ Si actualizás una instalación anterior a este cambio, `.codex/hooks/hooks.json
 nunca lo leyó— y se borra a mano.
 
 Los cinco recorridos llegan como skills en `.agents/skills/` —una de las rutas que Codex escanea, junto
-con `~/.agents/skills` y `/etc/codex/skills`— y se invocan con `$`: `$onboard`, `$team`, `$autobuild`,
+con `~/.agents/skills` y `/etc/codex/skills`— y se invocan con `$`: `$onboard`, `$flow`, `$autobuild`,
 `$integration-sync` e `$integration-promote`. Ahí va también el catálogo de cargos.
 
 Hasta 0.41.0 el adaptador daba a Codex por incapaz de skills y le dejaba el recorrido sólo como prosa

package/automatization/runners/codex/manifest.json

@@ -18,8 +18,8 @@
       "target": ".agents/skills/onboard/SKILL.md"
     },
     {
-      "source": "../../shared/skills/team/SKILL.md",
-      "target": ".agents/skills/team/SKILL.md"
+      "source": "../../shared/skills/flow/SKILL.md",
+      "target": ".agents/skills/flow/SKILL.md"
     },
     {
       "source": "../../shared/skills/autobuild/SKILL.md",
@@ -45,7 +45,7 @@
     "invocation": "${name}",
     "names": [
       "onboard",
-      "team",
+      "flow",
       "autobuild",
       "integration-sync",
       "integration-promote"

package/automatization/runners/gemini/GEMINI.md

@@ -21,7 +21,7 @@ contrato completo; leé ese `SKILL.md` antes de actuar en su terreno. Para la li
 
 ```bash
 node {{OPS_DIR}}tools/ops.js agents list
-node {{OPS_DIR}}tools/ops.js team list
+node {{OPS_DIR}}tools/ops.js flow list
 ```
 
 ## El arranque

package/automatization/runners/gemini/README.md

@@ -10,7 +10,7 @@ node tools/ops.js automation install . gemini
 ```
 
 Instala `.gemini/settings.json`, el contexto raíz `GEMINI.md` y los comandos `/cauce:onboard`,
-`/cauce:team`, `/cauce:autobuild`, `/cauce:integration-sync` y `/cauce:integration-promote`, más el
+`/cauce:flow`, `/cauce:autobuild`, `/cauce:integration-sync` y `/cauce:integration-promote`, más el
 catálogo de cargos como skills en `.gemini/skills/`.
 
 Antes vivían bajo `/ops:` y eran tres: el arranque y el recorrido de equipo le llegaban sólo como prosa,

package/automatization/runners/gemini/commands/cauce/{team.toml → flow.toml}

@@ -1,6 +1,6 @@
-description = "Recorre un equipo y propone una épica candidata, sin promoverla"
+description = "Recorre un recorrido y propone una épica candidata, sin promoverla"
 prompt = """
-Obtené el recorrido con `node {{OPS_DIR}}tools/ops.js team show <slug> --json` y ejecutá una etapa a la
+Obtené el recorrido con `node {{OPS_DIR}}tools/ops.js flow show <slug> --json` y ejecutá una etapa a la
 vez, adoptando en cada una el contrato del cargo que la posee. Respetá el dueño de decisión de cada
 dominio: ningún otro cargo resuelve en su lugar.
 

package/automatization/runners/gemini/manifest.json

@@ -30,8 +30,8 @@
       "target": ".gemini/commands/cauce/onboard.toml"
     },
     {
-      "source": "commands/cauce/team.toml",
-      "target": ".gemini/commands/cauce/team.toml"
+      "source": "commands/cauce/flow.toml",
+      "target": ".gemini/commands/cauce/flow.toml"
     }
   ],
   "capabilities": {
@@ -46,7 +46,7 @@
     "invocation": "/cauce:{name}",
     "names": [
       "onboard",
-      "team",
+      "flow",
       "autobuild",
       "integration-sync",
       "integration-promote"

package/automatization/shared/eval-measured.js

@@ -0,0 +1,18 @@
+// Qué se midió y qué no. Un caso sin veredicto no es un caso reprobado: es un caso que no se midió, y
+// la diferencia es quién falló. Escribirlo como «no pasa» le atribuye al sujeto un fallo del
+// instrumento —el juez que murió, la etapa que se cayó— y eso no se distingue después leyendo el
+// registro.
+//
+// Y el que desaparece es peor que el que miente: al caerse sale del arreglo, el total se achica solo y
+// el registro queda idéntico a uno que midió menos casos a propósito.
+function measured(items, verdicts) {
+  const answered = verdicts.filter((one) => one && one.verdict)
+  const ids = answered.map((one) => one.id)
+  return { answered, unmeasured: items.map((item) => item.id).filter((id) => !ids.includes(id)) }
+}
+
+// La línea que impide leer el registro como completo. Va en el cuerpo y no al pie: sirve para que la
+// vea quien decide, no para dejar constancia de que se sabía.
+const unmeasuredNote = (unmeasured) => (unmeasured.length
+  ? `> Sin medir en esta corrida: ${unmeasured.join(', ')} — el caso no llegó a un veredicto.\n\n`
+  : '')

package/automatization/shared/eval-only.js

@@ -0,0 +1,24 @@
+// Qué casos correr. Sin `cases` van todos, que es lo que hace falta la primera vez y cuando el
+// contrato cambió entero.
+//
+// Nombrar uno existe porque comprobar un arreglo no pide la batería: un sujeto falla un caso de seis y
+// correr los seis cuesta seis veces lo mismo para volver a mirar cinco veredictos que ya se tenían. Es
+// el desperdicio que R20 nombra —repetir sin que el cambio pueda mover ese veredicto—, y acá tenía
+// forma de comando.
+//
+// El registro que sale entonces cubre menos casos de los que el sujeto tiene, y `evaluate` lo dirá:
+// «el resultado no vale». Es correcto que lo diga. Lo que corresponde es componer el registro nuevo
+// con los veredictos que no se volvieron a medir, citando de qué corrida vienen.
+//
+// Vive acá y no en cada evaluador porque los dos lo necesitan igual, y el que se agrega después es el
+// que se queda sin él: ya pasó cuatro veces —`contexto`, la ruta del CLI, el esquema de dos niveles y
+// este mismo filtro— que un arreglo entrara en un gemelo y no en el otro.
+const onlyCases = (input) => (Array.isArray(input.cases) ? input.cases : String(input.cases || '')
+  .split(',')).map((one) => String(one).trim()).filter(Boolean)
+
+// Devuelve los casos pedidos, o los que faltan para que quien llama frene con su propio vocabulario.
+function pickCases(items, only) {
+  const existen = items.map((item) => item.id)
+  const missing = only.filter((id) => !existen.includes(id))
+  return { existen, missing, items: items.filter((item) => only.includes(item.id)) }
+}

package/automatization/shared/skills/{team → flow}/SKILL.md

@@ -1,10 +1,10 @@
 ---
-name: team
-description: Evalúa con un equipo si una intención es viable y propone una épica candidata.
+name: flow
+description: Evalúa con un recorrido si una intención es viable y propone una épica candidata.
 ---
 
 Lee `{{OPS_DIR}}AGENTS.md`, `{{OPS_DIR}}planning/PROTOCOL.md` y el contexto de `{{OPS_DIR}}organization/`. Obtené el recorrido con
-`node {{OPS_DIR}}tools/ops.js team show <slug> --json` y ejecutá una etapa a la vez, adoptando en cada una el
+`node {{OPS_DIR}}tools/ops.js flow show <slug> --json` y ejecutá una etapa a la vez, adoptando en cada una el
 contrato del cargo que la posee. Respetá el dueño de decisión de cada dominio: ningún otro cargo
 resuelve en su lugar.
 

package/automatization/shared/workflow-finish.js

@@ -0,0 +1,12 @@
+// Cierre del recorrido. El runtime no trae un helper de cierre —el valor devuelto por el script ya es
+// el resultado—, y darlo por sentado hacía reventar el archivo justo al terminar: después de gastar
+// cada etapa, en la línea que las cerraba.
+function finish(result) {
+  log(`Fin: ${JSON.stringify(result)}`)
+  return result
+}
+
+const stop = (reason, detail = '') => {
+  log(`Checkpoint: ${reason}${detail ? ` — ${detail}` : ''}`)
+  return finish({ stopped: true, reason, detail })
+}

package/automatization/shared/workflow-root.js

@@ -0,0 +1,4 @@
+// El prefijo lo completa `automation install`. No puede venir del entorno: el runtime de workflows no
+// expone `process`, así que leerlo de ahí reventaba el archivo entero en su primera línea. Viaja
+// escrito, relativo a la carpeta donde se abre la herramienta, que es el cwd de los agentes.
+const ROOT = '{{OPS_DIR}}'.replace(/\/+$/, '') || '.'

package/automatization/workflows/README.md

@@ -17,9 +17,14 @@ automatization/workflows/autobuild.js   (fuente canónica)
 .claude/workflows/autobuild.js          (adaptador ejecutable)
 ```
 
-Claude dispone actualmente del formato ejecutable usado por este archivo. Codex y Gemini conservan el
-mismo protocolo y los mismos hooks, pero no se anuncia un workflow nativo hasta disponer de una API
-equivalente; en esos runners el recorrido se ejecuta siguiendo `planning/PROTOCOL.md`.
+Sólo Claude ejecuta este formato. Los otros tres ofrecen los mismos cinco recorridos en el formato que
+cada uno entiende —skills en Codex y Antigravity, comandos en Gemini—, con el mismo protocolo y los
+mismos hooks, pero recorridos fase por fase en vez de ejecutados: no se anuncia un workflow nativo hasta
+que exista una API equivalente.
+
+El nombre del recorrido es el mismo en los cuatro; el prefijo lo pone cada runner —`/onboard` en Claude,
+`$onboard` en Codex, `/cauce:onboard` en Gemini y Antigravity—. `automation install` lo imprime al
+terminar, y `commands.invocation` de cada `manifest.json` es la fuente.
 
 ## Integración externa
 
@@ -27,12 +32,16 @@ equivalente; en esos runners el recorrido se ejecuta siguiendo `planning/PROTOCO
 para revisión humana. `integrations/promote.js` exige proveedor, clave y un draft `ready`. Ninguno escribe en
 el sistema remoto; Jira es actualmente el primer adaptador del contrato general.
 
-```bash
-/integration-sync jira
-/integration-promote jira KEY-123
+```text
+integration-sync jira                 con el prefijo del runner
+integration-promote jira KEY-123
 ```
 
 ## Aprendizaje de agentes
 
-Genera informes y propuestas; nunca modifica automáticamente un `SKILL.md`. Toda actualización exige
-evaluación y aprobación humana.
+`agent-eval.js` mide un cargo contra sus controles y casos, `agent-propose.js` consolida una propuesta de
+cambio y `agent-promote.js` la aplica una vez aprobada. Generan informes y propuestas; ninguno modifica
+un `SKILL.md` por su cuenta. Toda actualización exige evaluación y aprobación humana.
+
+Los tres se instalan sólo en Claude, que es el único con runtime para ejecutarlos, y no figuran entre los
+cinco recorridos que todos los runners anuncian.