@ingeniomaps/cauce 0.40.0 → 0.42.0

package/CHANGELOG.md

@@ -14,6 +14,60 @@ desde este repositorio no va, porque el que lee no puede actuar sobre eso. Cuand
 unas pocas líneas casi siempre es porque cuenta cómo se descubrió el problema o por qué se eligió el
 diseño — eso vive en el commit y en el código.
 
+## [0.42.0] - 2026-08-20
+
+### Corregido
+
+- **Los guards de Codex no corrían nunca.** Tres cosas a la vez, y ninguna hacía ruido: el archivo se
+  instalaba en `.codex/hooks/hooks.json` —esa forma es la que empaqueta un plugin; un repositorio se lee
+  en `.codex/hooks.json`—, los `matcher` filtraban nombres del protocolo interno en vez del nombre de la
+  herramienta (`Bash`, `apply_patch`/`Edit`/`Write`), y el comando era una ruta relativa mientras Codex
+  ejecuta el hook con el cwd de la sesión, así que desde cualquier subdirectorio no existía. **Reinstalá
+  el adaptador**, borrá a mano el `.codex/hooks/hooks.json` que queda huérfano, y confiá los hooks con
+  `/hooks` dentro de una sesión: Codex los saltea en silencio hasta que lo hagas, y hay que repetirlo
+  cada vez que el wiring cambie.
+- **El guard de archivos no veía nada bajo Codex.** `apply_patch` manda el parche entero como
+  `tool_input.command`, no como `patch`, y sin reconocer ese campo el guard miraba una escritura y no
+  encontraba un solo archivo: reescribió una migración existente en una corrida real, y lo mismo valía
+  para secretos y para los límites del workspace.
+- **Los guards de Antigravity tampoco corrían.** `agy` ejecuta la copia del plugin que registró en
+  `~/.gemini/config/plugins/` y resuelve las rutas contra la carpeta del plugin, así que la del
+  workspace apuntaba a un módulo inexistente; su payload además no nombra el workspace —manda
+  `workspacePaths` vacío y un `Cwd` que apunta al scratch del CLI o al home—, de modo que la raíz ops
+  ahora se escribe como ruta absoluta al instalar. **Reinstalá y volvé a registrar** con
+  `agy plugin install .agents/plugins/cauce` cada vez que cambie el wiring.
+- **Un puente que no arrancaba dejaba al agente sin poder cerrar la sesión.** En Antigravity, un guard
+  que bloquea y un fallo de infraestructura devolvían los dos `continue`; ahora sólo el bloqueo lo hace,
+  y la falla deja cerrar con la razón a la vista.
+- **Los guards resolvían rutas relativas contra la carpeta equivocada en Antigravity**, que no es la del
+  proyecto: un guard que juzgaba `src/x.js` estaba juzgando otro archivo.
+- **Instalar acumulaba las entradas de hooks de versiones anteriores.** Una ruta nuestra que cambiaba
+  dejaba viva la anterior, el runner la ejecutaba, no encontraba nada y el guard no corría. Ahora se
+  reemplazan las nuestras y se conserva lo que agregó el proyecto.
+- **Un cargo con el mismo nombre que un recorrido lo pisaba en silencio**, porque comparten el espacio de
+  skills del runner. La instalación ahora se detiene y dice cuál: renombrá el cargo en `agents/roles/`.
+- **Gemini invocaba `/ops:autobuild`**, un prefijo que ya no existe, y **Antigravity anunciaba sus
+  recorridos sin la barra** (`cauce:onboard` en vez de `/cauce:onboard`).
+- **La regla de Antigravity apuntaba a un `AGENTS.md` sin prefijo**, que en modo sidecar es el del
+  repositorio de producto y no el que trae las reglas del sistema.
+
+### Cambiado
+
+- **El arranque de Gemini vive ahora en su comando.** `GEMINI.md` remite a `/cauce:onboard` en vez de
+  repetir el recorrido, y el comando trae la lista completa de lo que se comprueba al final —incluidos
+  los dos puntos que la copia había perdido—.
+
+## [0.41.0] - 2026-08-19
+
+### Corregido
+
+- **`destroy` ya no borra el repositorio en modo embebido.** Ahí la instancia **es** el repositorio, así
+  que borrar la carpeta se llevaba el código del producto: pasó de verdad sobre un caso de prueba, y el
+  aviso previo enumeraba épicas y acciones humanas sin nombrar lo único irrecuperable. En embebido saca
+  lo que Cauce escribió —`planning/`, `organization/`, `teams/`, `integrations/`, `automatization/`,
+  `tools/`, la configuración y el manifiesto— y deja el repositorio. En sidecar sigue borrando la
+  carpeta, que ahí no contiene nada más.
+
 ## [0.40.0] - 2026-08-19
 
 ### Corregido

package/automatization/runners/README.md

@@ -1,25 +1,42 @@
 # Adaptadores de runners
 
-Un adaptador declara:
+Cada adaptador traduce el mismo toolkit al espacio de nombres de su herramienta. Lo que declara su
+`manifest.json`:
 
-1. Eventos soportados (`pre-tool`, `post-tool`, `stop`, workflow invocable).
-2. Cómo localiza la raíz Ops y ejecuta `engine/cli/ops.js`.
-3. Qué fases ejecuta realmente y cuáles quedan como protocolo manual.
-4. Cómo instala y desinstala su wiring sin duplicar fuentes de verdad.
-5. Qué permisos o acciones externas requieren confirmación.
+| Campo | Qué resuelve |
+|---|---|
+| `command` | el ejecutable con el que se comprueba que la herramienta esté disponible |
+| `config` | de qué archivo sale el wiring de hooks y en qué ruta del proyecto se instala |
+| `instructions` | qué archivo de contexto se copia, si la herramienta lee uno propio |
+| `artifacts` | los recorridos y cualquier archivo que el adaptador aporte |
+| `capabilities` | qué ejecuta de verdad —`nativeHooks`, `nativeWorkflows`, `nativeSkills`, `checkpointing`, `projectInstructions`— y qué queda como protocolo manual |
+| `roleSkills` | dónde se instala el catálogo de cargos, cuando la herramienta tiene skills |
+| `activation` | el paso manual que lo pone a correr, cómo verificarlo y qué se espera ver |
+| `commands` | los nombres de los recorridos y con qué prefijo se los invoca acá |
+
+Lo que un adaptador **no** declara es qué acciones requieren confirmación humana: eso no varía por
+runner. Lo fijan los guards de `automatization/hooks/` y las reglas de `planning/rules/system/`, iguales
+para los cuatro.
 
 ```text
 runners/<nombre>/
 ├── README.md
 ├── manifest.json
-├── settings.json
-├── archivo de instrucciones (si aplica)
-└── comandos o artefactos propios (si aplica)
+├── settings.json | hooks.json      configuración del runner, según lo que lea cada uno
+├── archivo de instrucciones        CLAUDE.md, GEMINI.md, AGENTS.md (si aplica)
+└── artefactos propios              comandos, skills, reglas, puentes (si aplica)
 ```
 
 Adaptadores incluidos: `claude`, `codex`, `antigravity` y `gemini`. Antigravity es la opción Google
-recomendada para cuentas individuales y proyectos nuevos; Gemini se conserva para Enterprise, Google Cloud
-y autenticación mediante API keys. Se instalan explícitamente con
-`ops automation install`; crear el proyecto no modifica la configuración activa del usuario.
-Después de instalar, `ops automation doctor <raíz> <runner>` verifica configuración, instrucciones,
-artefactos y disponibilidad del CLI sin requerir autenticación.
+recomendada para cuentas individuales y proyectos nuevos; Gemini se conserva para Enterprise, Google
+Cloud y autenticación mediante API keys.
+
+Se instalan explícitamente —crear el proyecto no toca la configuración activa del usuario— y se
+comprueban sin autenticar:
+
+```bash
+node tools/ops.js automation install . <runner>
+node tools/ops.js automation doctor . <runner>
+```
+
+`doctor` verifica configuración, instrucciones, artefactos, cargos y disponibilidad del CLI.

package/automatization/runners/antigravity/README.md

@@ -1,16 +1,30 @@
 # Antigravity CLI
 
-Runner Google recomendado para cuentas individuales y proyectos nuevos. Usa el ejecutable `agy` y se instala
-como plugin nativo de workspace en `.agents/plugins/cauce/`:
+Runner Google recomendado para cuentas individuales y proyectos nuevos. Usa el ejecutable `agy` y se
+instala como plugin nativo de workspace en `.agents/plugins/cauce/`:
 
 ```bash
-make install-antigravity
-make doctor-antigravity
+node tools/ops.js automation install . antigravity
+node tools/ops.js automation doctor . antigravity
 ```
 
-El plugin aporta hooks `PreToolUse` y `Stop`, reglas Cauce y skills `/autobuild`,
-`/integration-sync` y `/integration-promote`. El bridge convierte el contrato JSON camelCase de Antigravity
-al motor compartido de guards y devuelve decisiones nativas `allow`, `deny` o `continue`.
+`automation install` deja los archivos y no autentica. El paso que los pone a correr es
+`agy plugin install .agents/plugins/cauce`, que el instalador imprime cuando falta. Ese paso **copia el
+plugin a `~/.gemini/config/plugins/cauce/` y es esa copia la que `agy` ejecuta**, con un registro por
+usuario y no por workspace. De ahí salen tres consecuencias que conviene tener presentes:
 
-La instalación no autentica ni modifica preferencias globales. Antigravity también lee el `AGENTS.md` del
-workspace. El runner `gemini` permanece disponible por separado para Enterprise, Google Cloud y API keys.
+- Las rutas del `hooks.json` se resuelven contra la carpeta del plugin, no contra el workspace.
+- El payload no nombra el workspace —manda `workspacePaths` vacío y un `Cwd` que apunta al scratch del
+  CLI o al home—, así que el puente lleva la raíz ops escrita como ruta absoluta al instalar.
+- Registrar desde otro proyecto reemplaza el plugin del anterior.
+
+Volvé a registrar cada vez que `automation install` cambie el wiring o el proyecto se mueva de lugar;
+`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
+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`.
+
+Antigravity también lee el `AGENTS.md` del workspace. El runner `gemini` permanece disponible por
+separado para Enterprise, Google Cloud y API keys.

package/automatization/runners/antigravity/hook.js

@@ -17,24 +17,59 @@ function readInput() {
 // no hallaba `ops.config.json` y, como falla cerrado, negaba cada llamada a herramienta.
 const OPS_DIR = '{{OPS_DIR}}'
 
-function declaredRoot() {
-  // El plugin vive en <raíz-de-instalación>/.agents/plugins/cauce/.
-  const installed = path.resolve(__dirname, '..', '..', '..')
-  const root = OPS_DIR.startsWith('{{') ? installed : path.join(installed, OPS_DIR)
+// Y la ruta absoluta, porque con Antigravity no hay de dónde deducirla. Su payload manda
+// `workspacePaths` vacío y un `Cwd` que apunta al scratch del CLI o al home; el hook lo ejecuta `agy`
+// desde la copia que registró en `~/.gemini/config/plugins/`, cuyo `__dirname` no lleva a ningún
+// proyecto. Nada de eso nombra el workspace, así que el ancla se escribe al instalar o no existe.
+const OPS_ROOT = '{{OPS_ROOT}}'
+
+// Los dos marcadores y la carpeta desde la que corre el puente, juntos y pasables como argumento. El
+// default es lo que `automation install` deja escrito; poder reemplazarlo es lo que permite ejercer
+// desde el repositorio lo que sólo existe instalado. Sin eso, la resolución de la raíz —donde ya se
+// escondieron dos fallas que negaban cada llamada a herramienta— sólo se puede probar sobre una copia,
+// y una copia no la mide ninguna cobertura.
+const MARCAS = { dir: OPS_DIR, root: OPS_ROOT, plugin: __dirname }
+
+function isRoot(dir) {
+  const instance = fs.existsSync(path.join(dir, 'planning'))
+  const toolkit = fs.existsSync(path.join(dir, 'engine', 'hooks', 'run.js'))
+  return fs.existsSync(path.join(dir, 'ops.config.json')) && (instance || toolkit)
+}
+
+function declaredRoot(marcas) {
+  if (!marcas.root.startsWith('{{') && isRoot(marcas.root)) return marcas.root
+  // El plugin corriendo desde donde `automation install` lo dejó, que es el caso sin registrar.
+  const installed = path.resolve(marcas.plugin, '..', '..', '..')
+  const root = marcas.dir.startsWith('{{') ? installed : path.join(installed, marcas.dir)
   return fs.existsSync(path.join(root, 'ops.config.json')) ? root : ''
 }
 
-function findRoot(input) {
-  const declared = declaredRoot()
+// En sidecar se abre la carpeta de la compañía y la raíz ops es una de sus hijas, así que buscar sólo
+// hacia arriba no la encuentra nunca: el puente fallaba cerrado y negaba cada llamada a herramienta.
+// Un nivel hacia abajo alcanza para los dos modos y es determinista; recorrer el árbol del producto,
+// no. Dos candidatas hermanas es una ambigüedad que nadie puede resolver acá: se abstiene.
+function childRoot(dir) {
+  let entries = []
+  try { entries = fs.readdirSync(dir, { withFileTypes: true }) } catch { return '' }
+  const roots = entries
+    .filter((entry) => entry.isDirectory() && !entry.name.startsWith('.'))
+    .map((entry) => path.join(dir, entry.name))
+    .filter(isRoot)
+  return roots.length === 1 ? roots[0] : ''
+}
+
+function findRoot(input, marcas = MARCAS) {
+  const declared = declaredRoot(marcas)
   if (declared) return declared
   const args = input.toolCall && input.toolCall.args || {}
   const starts = [args.Cwd, process.cwd(), ...(input.workspacePaths || [])].filter(Boolean)
   for (const start of starts) {
-    let current = path.resolve(start)
+    const base = path.resolve(start)
+    const child = isRoot(base) ? base : childRoot(base)
+    if (child) return child
+    let current = path.dirname(base)
     while (true) {
-      const instance = fs.existsSync(path.join(current, 'planning'))
-      const toolkit = fs.existsSync(path.join(current, 'engine', 'hooks', 'run.js'))
-      if (fs.existsSync(path.join(current, 'ops.config.json')) && (instance || toolkit)) return current
+      if (isRoot(current)) return current
       const parent = path.dirname(current)
       if (parent === current) break
       current = parent
@@ -56,14 +91,38 @@ function runtimeAt(root) {
   return require(runtime)
 }
 
-function normalize(input) {
+// La carpeta que el runner abrió, deducida de la raíz: en sidecar la raíz ops es su hija, y en modo
+// embebido son la misma.
+function workspaceOf(root, marcas) {
+  const relative = marcas.dir.startsWith('{{') ? '' : marcas.dir.replace(/\/+$/, '')
+  if (!relative) return root
+  return path.resolve(root, ...relative.split('/').map(() => '..'))
+}
+
+function within(dir, base) {
+  const relative = path.relative(base, dir)
+  return relative === '' || (!relative.startsWith('..') && !path.isAbsolute(relative))
+}
+
+// Contra qué resuelven los guards una ruta relativa o el directorio git. El `Cwd` de Antigravity no
+// sirve para eso: apunta al scratch del CLI o al home, así que un guard que juzgue `src/x.js` estaría
+// juzgando otro archivo, y uno que busque el repo git lo buscaría fuera del proyecto. Se respeta el
+// que manda sólo si cae adentro del workspace —si algún día manda uno real, es mejor que el nuestro—;
+// si no, el workspace, que es donde el runner dice estar trabajando.
+function cwdFor(args, root, marcas) {
+  const declared = args.Cwd && path.resolve(String(args.Cwd))
+  const workspace = workspaceOf(root, marcas)
+  return declared && within(declared, workspace) ? declared : workspace
+}
+
+function normalize(input, root, marcas = MARCAS) {
   const args = input.toolCall && input.toolCall.args || {}
   const file = args.TargetFile || args.AbsolutePath || ''
   const content = args.CodeContent || args.ReplacementContent
     || (args.ReplacementChunks && JSON.stringify(args.ReplacementChunks)) || ''
   return {
     sessionId: input.conversationId,
-    cwd: args.Cwd || (input.workspacePaths || [])[0] || process.cwd(),
+    cwd: cwdFor(args, root, marcas),
     tool_input: {
       command: args.CommandLine || '',
       file_path: file,
@@ -81,13 +140,18 @@ function evaluate(event, input) {
     const root = findRoot(input)
     process.env.OPS_ROOT = root
     const hooks = runtimeAt(root)
-    const normalized = normalize(input)
+    const normalized = normalize(input, root)
     if (!hooks.hookGroups[event]) throw new Error(`Evento Antigravity desconocido: ${event || '(vacío)'}`)
     hooks.executeAll([event], normalized)
     return event === 'stop' ? { decision: 'stop' } : { decision: 'allow' }
   } catch (error) {
-    if (event === 'stop') return { decision: 'continue', reason: `Cauce: ${error.message}` }
-    return { decision: 'deny', reason: `Cauce: ${error.message}` }
+    const reason = `Cauce: ${error.message}`
+    if (event !== 'stop') return { decision: 'deny', reason }
+    // Un guard que bloquea marca su error con `blocked` (engine/hooks/run.js); cualquier otro es que el
+    // puente no llegó a juzgar nada. En `stop` los dos devolvían `continue`, y eso ata al agente: la
+    // raíz que no resuelve no se arregla sola, así que cada intento de cerrar repite el mismo error.
+    // El bloqueo sigue dando `continue` —es el mecanismo funcionando—; la falla deja cerrar y avisa.
+    return error.blocked ? { decision: 'continue', reason } : { decision: 'stop', reason }
   }
 }
 

package/automatization/runners/antigravity/hooks.json

@@ -4,18 +4,18 @@
       {
         "matcher": "run_command",
         "hooks": [
-          { "type": "command", "command": "node .agents/plugins/cauce/hook.js pre-shell", "timeout": 120 }
+          { "type": "command", "command": "node hook.js pre-shell", "timeout": 120 }
         ]
       },
       {
         "matcher": "write_to_file|replace_file_content|multi_replace_file_content",
         "hooks": [
-          { "type": "command", "command": "node .agents/plugins/cauce/hook.js pre-files", "timeout": 30 }
+          { "type": "command", "command": "node hook.js pre-files", "timeout": 30 }
         ]
       }
     ],
     "Stop": [
-      { "type": "command", "command": "node .agents/plugins/cauce/hook.js stop", "timeout": 120 }
+      { "type": "command", "command": "node hook.js stop", "timeout": 120 }
     ]
   }
 }

package/automatization/runners/antigravity/manifest.json

@@ -2,13 +2,10 @@
   "schemaVersion": 1,
   "name": "antigravity",
   "command": "agy",
-  "lifecycle": {
-    "recommendedForNewProjects": true,
-    "audience": "individual-and-new-google-projects"
-  },
   "config": {
     "source": "hooks.json",
-    "target": ".agents/plugins/cauce/hooks.json"
+    "target": ".agents/plugins/cauce/hooks.json",
+    "owned": true
   },
   "instructions": [],
   "artifacts": [
@@ -62,7 +59,7 @@
     "expect": "cauce"
   },
   "commands": {
-    "invocation": "cauce:{name}",
+    "invocation": "/cauce:{name}",
     "names": [
       "onboard",
       "team",

package/automatization/runners/antigravity/rules/cauce.md

@@ -1,6 +1,6 @@
 # Cauce
 
-Lee y cumple `AGENTS.md`, `{{OPS_DIR}}planning/PROTOCOL.md` y `{{OPS_DIR}}planning/rules/system/` antes
+Lee y cumple `{{OPS_DIR}}AGENTS.md`, `{{OPS_DIR}}planning/PROTOCOL.md` y `{{OPS_DIR}}planning/rules/system/` antes
 de ejecutar trabajo. `{{OPS_DIR}}planning/WIP.md` es el mutex de
 ejecución y `{{OPS_DIR}}planning/AWAITING_REVIEW.md` bloquea una corrida nueva. No promociones ideas desde INBOX, no
 inventes aprobaciones o credenciales y no hagas push ni deploy. Cierra cada tarea con verificación real y

package/automatization/runners/antigravity/skills/onboard/SKILL.md

@@ -3,72 +3,4 @@ name: onboard
 description: Escanea el repositorio y deja escrito el contexto de la empresa y la primera épica.
 ---
 
-Es el arranque de una instancia recién creada: `init` la instaló, pero nadie le explicó todavía qué es
-este proyecto.
-
-Empezá por `node {{OPS_DIR}}tools/ops.js onboard`, que es instantáneo y te dice tres cosas: si la
-instancia sigue vacía, qué hay en el workspace y con qué pregunta empezar. Si ya tiene contexto escrito,
-no la pises: reescribir lo que alguien corrigió no deja rastro de lo que se perdió.
-
-La conversación empieza por una sola pregunta —de qué trata el proyecto, la primera línea que ese comando
-imprime— y la hacés antes de mirar el inventario, sea el workspace vacío, un monorepo o diez repos.
-Sigue según lo que conteste: hasta tres más, formuladas con las palabras de ese proyecto, hasta cubrir
-las dimensiones que el comando haya listado. Una por vez, esperando respuesta. El inventario ya viene
-resuelto: no recorras el árbol ni leas código para completarlo. No des por sentado que vende algo: puede sostenerse con
-donaciones, presupuesto interno o trabajo voluntario, y preguntarle a un proyecto libre quién le paga es
-empezar por una respuesta que nadie dio.
-
-El inventario no lo hagas a mano: `node {{OPS_DIR}}tools/ops.js scan --json` devuelve los subproyectos con
-manifiesto propio, su runtime y los comandos que cada uno declara, con el archivo del que salieron.
-Recorrer directorios es determinista y cuesta milisegundos; explorarlo vos cuesta minutos y encuentra lo
-mismo. No corras ningún comando del proyecto: el mapa dice lo que está declarado y de dónde, y
-verificarlo corriéndolo es una historia de la épica, con dueño y tiempo asignado.
-
-Con eso escribí `{{OPS_DIR}}organization/company.md` y `product.md`, la sección «Mapa real» de
-`{{OPS_DIR}}AGENTS.md` con el resultado que obtuviste por comando, y las raíces reales en
-`workspaceRoots` de `{{OPS_DIR}}ops.config.json`, que es lo que un guard usa para bloquear una escritura
-fuera de lugar. Lo deducido va marcado `(supuesto)` y lo que nada sostiene queda «Por definir»: no
-inventes clientes, ingresos ni objetivos.
-
-Credenciales, MCP y el permiso de push no te corresponden. Cada uno va como fila en
-`{{OPS_DIR}}planning/HUMAN_ACTIONS.md` con la acción concreta que lo desbloquea y sin proponer ningún
-valor; las preguntas abiertas, a la sección Ideas de `{{OPS_DIR}}planning/INBOX.md`.
-
-El arranque tiene tres objetivos y ninguno más: entender qué es el proyecto, dejar la instancia correcta
-para él y que la primera tarea pueda empezar. El análisis profundo viene después, cuando la persona pida
-algo concreto.
-
-Cerrá escribiendo la épica en `{{OPS_DIR}}planning/roadmap/`: su resultado es que una tarea pueda
-atravesar el ciclo entero, y sus criterios salen de lo que hoy falta —contexto sin supuestos, cada
-comando en verde, el guard de límites probado en las dos direcciones, una tarea piloto en DONE—.
-**Nunca promuevas al BACKLOG**: esa firma es humana.
-
-## Antes de decir que terminaste
-
-Esta lista no es un resumen de lo de arriba: es lo que se comprueba mirando el disco. Una corrida real
-falló los cinco puntos sin darse cuenta, y todos del mismo lado —lo que no produce un archivo visible—.
-
-1. **Una pregunta por vez.** Si mandaste dos o más juntas, numeradas, hiciste un formulario. La segunda
-   pregunta depende de la primera respuesta: por eso se hacen de a una.
-2. **`epic-NNN-<slug>.md`**, con slug en el nombre y `status: open`. `epic-001.md` no lo lee nadie: ni
-   `check`, ni `tree`, ni el runner que busca trabajo. Existe y no existe a la vez.
-3. **Las secciones de `{{OPS_DIR}}organization/` son las del molde.** Escribí adentro de ellas; agregá las tuyas
-   abajo si hacen falta. Reemplazar la estructura pierde dimensiones que nadie va a reclamar después,
-   porque el archivo se lee completo.
-4. **`HUMAN_ACTIONS.md` tiene filas.** Una por credencial nombrada en el inventario, una por sistema
-   externo o MCP, una por la autoridad de push. Si quedó vacío, no es que no hubiera nada: es que lo que
-   no te corresponde se perdió en vez de quedar escrito para alguien.
-5. **`ops` no es un servicio del producto.** No va en el mapa real: es la instancia desde la que trabajás.
-
-6. **Ninguna dimensión se completa sin haberla preguntado.** Si llegaste al tope de preguntas y una
-   quedó afuera —quién lo usa, qué está muerto, qué externo hay— va «Por definir» con su pregunta en
-   `{{OPS_DIR}}planning/INBOX.md`, aunque puedas imaginar la respuesta. Y lo que deducís de otra
-   respuesta va marcado `(supuesto)`, por plausible que sea: sin la marca se lee con el mismo peso que
-   lo que la persona dijo, y nadie va a volver a preguntarlo.
-7. **Corré `node {{OPS_DIR}}tools/ops.js onboard`.** Si te vuelve a ofrecer la pregunta de apertura, la
-   instancia sigue vacía: no escribiste nada, y no hay nada que informar. Una corrida real entregó un
-   resumen en pasado —«registrado», «documentado», «creada la primera épica»— sobre archivos que en el
-   disco seguían siendo el molde. Estar bloqueado es un resultado legítimo; narrarlo como entrega, no.
-
-Recién ahí, `node {{OPS_DIR}}tools/ops.js check planning`. Si sale con advertencias, leelas: son
-exactamente estas cosas.
+{{INCLUDE:shared/onboard.md}}

package/automatization/runners/claude/README.md

@@ -6,8 +6,14 @@ Adaptador nativo mediante `PreToolUse` y `Stop`. Instalar con:
 node tools/ops.js automation install . claude
 ```
 
-El instalador fusiona la sección `hooks` en `.claude/settings.json` y conserva otras claves.
-También instala `autobuild`, `integration-sync` e `integration-promote` en `.claude/workflows/`. Si ya existe
-una versión distinta, se detiene sin sobrescribirla para no destruir personalizaciones del proyecto.
-También crea `CLAUDE.md` cuando no existe y conserva uno existente. `manifest.json` declara destinos y
-capacidades. Comprueba todo con `node tools/ops.js automation doctor . claude`.
+El instalador fusiona la sección `hooks` en `.claude/settings.json` y conserva otras claves. Si ya
+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`,
+`/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/`.
+
+`manifest.json` declara destinos y capacidades. Comprueba todo con
+`node tools/ops.js automation doctor . claude`.

package/automatization/runners/codex/AGENTS.md

@@ -7,7 +7,7 @@ antes de trabajar —los tres, no cuando algo sale mal—: acá sólo está lo e
 > Codex lee el `AGENTS.md` de la raíz, que es un nombre compartido entre herramientas. Cuando el repo
 > ops **es** la raíz, este archivo no se instala: el `AGENTS.md` de la empresa ya está ahí y manda.
 
-Los hooks de `.codex/hooks/hooks.json` son obligatorios y bloquean por su cuenta. Codex no ejecuta los
+Los hooks de `.codex/hooks.json` son obligatorios y bloquean por su cuenta. Codex no ejecuta los
 workflows JS de Claude —son referencia, no un runtime compatible—, así que el recorrido se hace fase por
 fase siguiendo el protocolo.
 
@@ -33,35 +33,7 @@ ese cargo debe saber de esta empresa está en `{{OPS_DIR}}organization/roles/<sl
 
 ## El arranque
 
-En una instancia recién creada nadie le explicó todavía al toolkit qué es este proyecto:
-`{{OPS_DIR}}organization/` llega como molde y el roadmap está vacío. El primer recorrido lo llena, y una vez: reescribir un contexto
-que alguien ya corrigió no deja rastro de lo que se perdió.
-
-Empezá por `node {{OPS_DIR}}tools/ops.js onboard`, que es instantáneo: la primera línea que imprime es la
-pregunta con la que tenés que abrir —de qué trata el proyecto—, y después vienen el inventario y las
-dimensiones. Hacé esa pregunta tal cual antes de mirar nada, sea el workspace vacío, un monorepo o diez
-repos, y según lo que conteste formulá hasta tres más con las palabras de ese proyecto, una por vez. El
-inventario ya viene resuelto ahí: no recorras el árbol ni leas código para completarlo. No des por
-sentado que vende algo: puede sostenerse con donaciones, presupuesto interno o trabajo voluntario. Con eso escribí `{{OPS_DIR}}organization/`, la sección «Mapa real» de
-`{{OPS_DIR}}AGENTS.md` con cada comando tal como está declarado y de qué archivo salió —sin correrlo—, y
-las raíces reales en `workspaceRoots`. Lo deducido va marcado `(supuesto)`. Credenciales, MCP y el permiso de push van como
-filas en `{{OPS_DIR}}planning/HUMAN_ACTIONS.md`, sin proponer valores. Cerrá con `epic-001` en
-`{{OPS_DIR}}planning/roadmap/`: que una tarea pueda atravesar el ciclo entero, con criterios que salen de
-lo que falta. Nunca la promuevas.
-
-El arranque tiene tres objetivos y ninguno más: entender qué es el proyecto, dejar la instancia correcta
-para él y que la primera tarea pueda empezar. El análisis profundo viene después, cuando la persona pida
-algo concreto.
-
-Antes de darlo por terminado, comprobá cinco cosas mirando el disco: preguntaste de a una y no en
-formulario; la épica se llama `epic-NNN-<slug>.md` con `status: open` —`epic-001.md` no lo lee nadie—;
-las secciones de `{{OPS_DIR}}organization/` siguen siendo las del molde y lo tuyo se agregó adentro;
-`{{OPS_DIR}}planning/HUMAN_ACTIONS.md` tiene una fila por credencial, por externo y por la autoridad de
-push; y `ops` no figura como servicio del producto en el mapa. una dimensión que no
-llegaste a preguntar va «Por definir» con su pregunta en `{{OPS_DIR}}planning/INBOX.md` en vez de
-completarse deduciéndola, y lo que deducís de otra respuesta va marcado `(supuesto)`. Cerrá corriendo
-`node {{OPS_DIR}}tools/ops.js onboard`: si te vuelve a ofrecer la pregunta de apertura, no escribiste
-nada y no hay nada que informar. Estar bloqueado es un resultado legítimo; narrarlo como entrega, no.
+{{INCLUDE:shared/onboard.md}}
 
 ## Los equipos
 

package/automatization/runners/codex/README.md

@@ -1,15 +1,26 @@
 # Codex CLI
 
-Codex CLI actual expone hooks nativos y pide confianza al detectar hooks nuevos o modificados. Instalar la
-configuración del proyecto con:
+Codex CLI expone hooks nativos. Instalar la configuración del proyecto con:
 
 ```bash
 node tools/ops.js automation install . codex
 ```
 
-El archivo se instala en `.codex/hooks/hooks.json`. La primera sesión revisa y solicita confiar en los hooks;
-no se usa `--dangerously-bypass-hook-trust`.
+El archivo se instala en `.codex/hooks.json`. Es una de las cuatro ubicaciones que Codex lee —las otras
+son `.codex/config.toml` y las dos equivalentes bajo `~/.codex/`—; la forma `hooks/hooks.json` es la que
+usa un plugin y no la que lee un repositorio.
 
-Codex carga las instrucciones de proyecto desde el `AGENTS.md` canónico, por lo que no se instala una copia
-adicional. `manifest.json` declara esta capacidad y `node tools/ops.js automation doctor . codex` valida el
-wiring. Los workflows JS de Claude no se presentan como compatibles con Codex.
+**Instalar no alcanza.** Un hook no gestionado queda registrado pero **no corre** hasta que se lo confía:
+Codex guarda la confianza contra el hash del archivo y saltea en silencio lo nuevo o lo modificado. Abrí
+una sesión y usá `/hooks` para revisarlos y confiarlos; hay que repetirlo cada vez que el wiring cambie,
+porque cambia el hash. No se usa `--dangerously-bypass-hook-trust`.
+
+Los `matcher` filtran el **nombre de la herramienta**: los comandos de shell llegan como `Bash` y las
+ediciones como `apply_patch`, `Edit` o `Write`. No son los nombres internos del protocolo.
+
+Si actualizás una instalación anterior a este cambio, `.codex/hooks/hooks.json` queda huérfano —Codex
+nunca lo leyó— y se borra a mano.
+
+Codex carga las instrucciones de proyecto desde el `AGENTS.md` canónico, por lo que no se instala una
+copia adicional. `manifest.json` declara esta capacidad y `node tools/ops.js automation doctor . codex`
+valida el wiring. Los workflows JS de Claude no se presentan como compatibles con Codex.

package/automatization/runners/codex/hooks.json

@@ -2,22 +2,22 @@
   "hooks": {
     "PreToolUse": [
       {
-        "matcher": "shell|unified_exec",
+        "matcher": "Bash",
         "hooks": [
-          { "type": "command", "command": "{{OPS_DIR}}automatization/hooks/guard-shell.sh" }
+          { "type": "command", "command": "{{OPS_ROOT}}/automatization/hooks/guard-shell.sh" }
         ]
       },
       {
-        "matcher": "apply_patch|files",
+        "matcher": "apply_patch|Edit|Write",
         "hooks": [
-          { "type": "command", "command": "{{OPS_DIR}}automatization/hooks/guard-files.sh" }
+          { "type": "command", "command": "{{OPS_ROOT}}/automatization/hooks/guard-files.sh" }
         ]
       }
     ],
     "SessionEnd": [
       {
         "hooks": [
-          { "type": "command", "command": "{{OPS_DIR}}automatization/hooks/guard-planning-drift.sh" }
+          { "type": "command", "command": "{{OPS_ROOT}}/automatization/hooks/guard-planning-drift.sh" }
         ]
       }
     ]

package/automatization/runners/codex/manifest.json

@@ -4,7 +4,7 @@
   "command": "codex",
   "config": {
     "source": "hooks.json",
-    "target": ".codex/hooks/hooks.json"
+    "target": ".codex/hooks.json"
   },
   "instructions": [
     {

package/automatization/runners/gemini/GEMINI.md

@@ -7,7 +7,7 @@
 @{{OPS_DIR}}planning/rules/system/commits.md
 @{{OPS_DIR}}planning/rules/system/conduct.md
 
-`{{OPS_DIR}}planning/PROTOCOL.md` es la fuente de verdad. Ejecuta `/ops:autobuild` fase por fase; los
+`{{OPS_DIR}}planning/PROTOCOL.md` es la fuente de verdad. Ejecuta `/cauce:autobuild` fase por fase; los
 workflows JS de Claude son referencia, no un runtime compatible. `{{OPS_DIR}}planning/WIP.md` es el mutex
 y `{{OPS_DIR}}planning/AWAITING_REVIEW.md` bloquea una corrida nueva.
 
@@ -27,34 +27,18 @@ node {{OPS_DIR}}tools/ops.js team list
 ## El arranque
 
 En una instancia recién creada nadie le explicó todavía al toolkit qué es este proyecto:
-`{{OPS_DIR}}organization/` llega como molde y el roadmap está vacío. El primer recorrido lo llena, y una vez: reescribir un contexto
-que alguien ya corrigió no deja rastro de lo que se perdió.
+`{{OPS_DIR}}organization/` llega como molde y el roadmap está vacío. El primer recorrido lo llena, y una
+vez: reescribir un contexto que alguien ya corrigió no deja rastro de lo que se perdió.
 
 Empezá por `node {{OPS_DIR}}tools/ops.js onboard`, que es instantáneo: la primera línea que imprime es la
-pregunta con la que tenés que abrir —de qué trata el proyecto—, y después vienen el inventario y las
-dimensiones. Hacé esa pregunta tal cual antes de mirar nada, sea el workspace vacío, un monorepo o diez
-repos, y según lo que conteste formulá hasta tres más con las palabras de ese proyecto, una por vez. El
-inventario ya viene resuelto ahí: no recorras el árbol ni leas código para completarlo. No des por
-sentado que vende algo: puede sostenerse con donaciones, presupuesto interno o trabajo voluntario. Con eso escribí `{{OPS_DIR}}organization/`, la sección «Mapa real» de
-`{{OPS_DIR}}AGENTS.md` con cada comando tal como está declarado y de qué archivo salió —sin correrlo—, y
-las raíces reales en `workspaceRoots`. Lo deducido va marcado `(supuesto)`. Credenciales, MCP y el permiso de push van como
-filas en `{{OPS_DIR}}planning/HUMAN_ACTIONS.md`, sin proponer valores. Cerrá con `epic-001` en
-`{{OPS_DIR}}planning/roadmap/`: que una tarea pueda atravesar el ciclo entero, con criterios que salen de
-lo que falta. Nunca la promuevas.
+pregunta con la que tenés que abrir —de qué trata el proyecto—. Hacésela tal cual y esperá la respuesta
+antes de mirar el inventario, sea el workspace vacío, un monorepo o diez repos. Con lo que te conteste
+invocá `/cauce:onboard`, que lleva el recorrido entero y la lista de lo que se comprueba al final;
+invocarlo antes sólo devuelve la misma pregunta más caro.
 
 El arranque tiene tres objetivos y ninguno más: entender qué es el proyecto, dejar la instancia correcta
 para él y que la primera tarea pueda empezar. El análisis profundo viene después, cuando la persona pida
-algo concreto.
-
-Antes de darlo por terminado, comprobá cinco cosas mirando el disco: preguntaste de a una y no en
-formulario; la épica se llama `epic-NNN-<slug>.md` con `status: open` —`epic-001.md` no lo lee nadie—;
-las secciones de `{{OPS_DIR}}organization/` siguen siendo las del molde y lo tuyo se agregó adentro;
-`{{OPS_DIR}}planning/HUMAN_ACTIONS.md` tiene una fila por credencial, por externo y por la autoridad de
-push; y `ops` no figura como servicio del producto en el mapa. una dimensión que no
-llegaste a preguntar va «Por definir» con su pregunta en `{{OPS_DIR}}planning/INBOX.md` en vez de
-completarse deduciéndola, y lo que deducís de otra respuesta va marcado `(supuesto)`. Cerrá corriendo
-`node {{OPS_DIR}}tools/ops.js onboard`: si te vuelve a ofrecer la pregunta de apertura, no escribiste
-nada y no hay nada que informar. Estar bloqueado es un resultado legítimo; narrarlo como entrega, no.
+algo concreto. Estar bloqueado es un resultado legítimo; narrarlo como entrega, no.
 
 Nunca omitas aprobaciones, inventes credenciales, escribas remoto, hagas push/deploy o promociones
 trabajo desde INBOX.

package/automatization/runners/gemini/README.md

@@ -10,13 +10,15 @@ 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`.
+`/cauce:team`, `/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,
 así que alguien que venía de otro runner los buscaba en la lista y no estaban. Si actualizás una
 instalación vieja, `.gemini/commands/ops/` queda huérfano y se borra a mano.
 
-Gemini no anuncia hooks nativos en este adaptador: los guards se ejecutan como prechecks indicados por el
-protocolo y los comandos. Esta degradación está declarada en `manifest.json`, no se simula protección inexistente.
+Gemini CLI tiene hooks nativos y el adaptador los usa: `BeforeTool` y `AfterAgent` en
+`.gemini/settings.json`, declarados en `manifest.json`. Sólo corren si la carpeta está marcada como
+confiable —`GEMINI.md` explica qué avisa Gemini cuando no lo está—.
 
 Comprueba la instalación con `node tools/ops.js automation doctor . gemini`.

package/automatization/runners/gemini/commands/cauce/onboard.toml

@@ -1,21 +1,4 @@
 description = "Arranca una instancia recién creada: pregunta, escribe el contexto y la primera épica"
 prompt = """
-Seguí la sección «El arranque» de {{OPS_DIR}}AGENTS.md y de este contexto raíz.
-
-Empezá por `node {{OPS_DIR}}tools/ops.js onboard`: es instantáneo, y la primera línea que imprime es la
-pregunta con la que tenés que abrir. Hacésela tal cual y esperá la respuesta antes de mirar el
-inventario, sea el workspace vacío, un monolito o diez repos. Según lo que conteste, hasta tres
-preguntas más con las palabras de ese proyecto, una por vez. El inventario ya viene resuelto en esa
-salida —servicios, comandos declarados y las variables que cada uno espera—: no recorras el árbol ni
-corras comandos del proyecto para completarlo.
-
-Con eso escribí {{OPS_DIR}}organization/, la sección «Mapa real» de {{OPS_DIR}}AGENTS.md con cada
-comando tal como está declarado y de qué archivo salió, y las raíces reales en workspaceRoots. Las
-credenciales, los sistemas externos y el permiso de push van como filas de
-{{OPS_DIR}}planning/HUMAN_ACTIONS.md, sin proponer ningún valor. Una dimensión que no llegaste a
-preguntar queda «Por definir» con su pregunta en {{OPS_DIR}}planning/INBOX.md, y lo que deducís de otra
-respuesta va marcado «(supuesto)».
-
-Cerrá escribiendo la épica como epic-NNN-<slug>.md con status: open —sin slug no la lee nadie— y corré
-`node {{OPS_DIR}}tools/ops.js check planning`. Nunca promuevas al BACKLOG: esa firma es humana.
+{{INCLUDE:shared/onboard.md}}
 """

package/automatization/runners/gemini/manifest.json

@@ -2,10 +2,6 @@
   "schemaVersion": 1,
   "name": "gemini",
   "command": "gemini",
-  "lifecycle": {
-    "recommendedForNewProjects": false,
-    "audience": "enterprise-cloud-api-key"
-  },
   "config": {
     "source": "settings.json",
     "target": ".gemini/settings.json"

package/automatization/shared/onboard.md

@@ -0,0 +1,69 @@
+Es el arranque de una instancia recién creada: `init` la instaló, pero nadie le explicó todavía qué es
+este proyecto.
+
+Empezá por `node {{OPS_DIR}}tools/ops.js onboard`, que es instantáneo y te dice tres cosas: si la
+instancia sigue vacía, qué hay en el workspace y con qué pregunta empezar. Si ya tiene contexto escrito,
+no la pises: reescribir lo que alguien corrigió no deja rastro de lo que se perdió.
+
+La conversación empieza por una sola pregunta —de qué trata el proyecto, la primera línea que ese comando
+imprime— y la hacés antes de mirar el inventario, sea el workspace vacío, un monorepo o diez repos.
+Sigue según lo que conteste: hasta tres más, formuladas con las palabras de ese proyecto, hasta cubrir
+las dimensiones que el comando haya listado. Una por vez, esperando respuesta. El inventario ya viene
+resuelto: no recorras el árbol ni leas código para completarlo. No des por sentado que vende algo: puede sostenerse con
+donaciones, presupuesto interno o trabajo voluntario, y preguntarle a un proyecto libre quién le paga es
+empezar por una respuesta que nadie dio.
+
+El inventario no lo hagas a mano: `node {{OPS_DIR}}tools/ops.js scan --json` devuelve los subproyectos con
+manifiesto propio, su runtime y los comandos que cada uno declara, con el archivo del que salieron.
+Recorrer directorios es determinista y cuesta milisegundos; explorarlo vos cuesta minutos y encuentra lo
+mismo. No corras ningún comando del proyecto: el mapa dice lo que está declarado y de dónde, y
+verificarlo corriéndolo es una historia de la épica, con dueño y tiempo asignado.
+
+Con eso escribí `{{OPS_DIR}}organization/company.md` y `product.md`, la sección «Mapa real» de
+`{{OPS_DIR}}AGENTS.md` con el resultado que obtuviste por comando, y las raíces reales en
+`workspaceRoots` de `{{OPS_DIR}}ops.config.json`, que es lo que un guard usa para bloquear una escritura
+fuera de lugar. Lo deducido va marcado `(supuesto)` y lo que nada sostiene queda «Por definir»: no
+inventes clientes, ingresos ni objetivos.
+
+Credenciales, MCP y el permiso de push no te corresponden. Cada uno va como fila en
+`{{OPS_DIR}}planning/HUMAN_ACTIONS.md` con la acción concreta que lo desbloquea y sin proponer ningún
+valor; las preguntas abiertas, a la sección Ideas de `{{OPS_DIR}}planning/INBOX.md`.
+
+El arranque tiene tres objetivos y ninguno más: entender qué es el proyecto, dejar la instancia correcta
+para él y que la primera tarea pueda empezar. El análisis profundo viene después, cuando la persona pida
+algo concreto.
+
+Cerrá escribiendo la épica en `{{OPS_DIR}}planning/roadmap/`: su resultado es que una tarea pueda
+atravesar el ciclo entero, y sus criterios salen de lo que hoy falta —contexto sin supuestos, cada
+comando en verde, el guard de límites probado en las dos direcciones, una tarea piloto en DONE—.
+**Nunca promuevas al BACKLOG**: esa firma es humana.
+
+## Antes de decir que terminaste
+
+Esta lista no es un resumen de lo de arriba: es lo que se comprueba mirando el disco. Una corrida real
+falló los cinco puntos sin darse cuenta, y todos del mismo lado —lo que no produce un archivo visible—.
+
+1. **Una pregunta por vez.** Si mandaste dos o más juntas, numeradas, hiciste un formulario. La segunda
+   pregunta depende de la primera respuesta: por eso se hacen de a una.
+2. **`epic-NNN-<slug>.md`**, con slug en el nombre y `status: open`. `epic-001.md` no lo lee nadie: ni
+   `check`, ni `tree`, ni el runner que busca trabajo. Existe y no existe a la vez.
+3. **Las secciones de `{{OPS_DIR}}organization/` son las del molde.** Escribí adentro de ellas; agregá las tuyas
+   abajo si hacen falta. Reemplazar la estructura pierde dimensiones que nadie va a reclamar después,
+   porque el archivo se lee completo.
+4. **`HUMAN_ACTIONS.md` tiene filas.** Una por credencial nombrada en el inventario, una por sistema
+   externo o MCP, una por la autoridad de push. Si quedó vacío, no es que no hubiera nada: es que lo que
+   no te corresponde se perdió en vez de quedar escrito para alguien.
+5. **`ops` no es un servicio del producto.** No va en el mapa real: es la instancia desde la que trabajás.
+
+6. **Ninguna dimensión se completa sin haberla preguntado.** Si llegaste al tope de preguntas y una
+   quedó afuera —quién lo usa, qué está muerto, qué externo hay— va «Por definir» con su pregunta en
+   `{{OPS_DIR}}planning/INBOX.md`, aunque puedas imaginar la respuesta. Y lo que deducís de otra
+   respuesta va marcado `(supuesto)`, por plausible que sea: sin la marca se lee con el mismo peso que
+   lo que la persona dijo, y nadie va a volver a preguntarlo.
+7. **Corré `node {{OPS_DIR}}tools/ops.js onboard`.** Si te vuelve a ofrecer la pregunta de apertura, la
+   instancia sigue vacía: no escribiste nada, y no hay nada que informar. Una corrida real entregó un
+   resumen en pasado —«registrado», «documentado», «creada la primera épica»— sobre archivos que en el
+   disco seguían siendo el molde. Estar bloqueado es un resultado legítimo; narrarlo como entrega, no.
+
+Recién ahí, `node {{OPS_DIR}}tools/ops.js check planning`. Si sale con advertencias, leelas: son
+exactamente estas cosas.

package/engine/automation/index.js

@@ -64,6 +64,55 @@ function mergeConfig(current, incoming) {
   return incoming
 }
 
+// Una entrada de hook que puso Cauce se reconoce por el guard al que apunta: `automatization/hooks/`
+// es nuestro y ninguna empresa escribe ahí. Se saca del archivo del usuario antes de fusionar para que
+// el merge deje exactamente las de esta versión, ni una más.
+const ENTREGADO = /automatization\/hooks\/guard-[a-z-]+\.sh/
+
+function withoutDeliveredHooks(config, vigentes) {
+  const dropped = []
+  const walk = (node) => {
+    if (Array.isArray(node)) {
+      return node
+        .filter((item) => {
+          const command = item && typeof item === 'object' ? String(item.command || '') : ''
+          if (!ENTREGADO.test(command)) return true
+          // Sólo se anuncia lo que ya no vuelve: una entrada que el merge repone quedó igual, y decir
+          // que se quitó y se puso la misma línea es ruido que esconde el caso que sí importa.
+          if (!vigentes.has(command)) dropped.push(command)
+          return false
+        })
+        .map(walk)
+        .filter((item) => !(item && typeof item === 'object' && Array.isArray(item.hooks) && !item.hooks.length))
+    }
+    if (node && typeof node === 'object') {
+      return Object.fromEntries(Object.entries(node).map(([key, value]) => [key, walk(value)]))
+    }
+    return node
+  }
+  return { config: walk(config), dropped }
+}
+
+// Por qué se fue cada entrada nuestra. Un guard suelto que ahora cubre un grupo no es lo mismo que una
+// ruta que dejó de existir: el primero se ejecutaba dos veces por herramienta —con `verify`, la suite
+// entera del proyecto dos veces por commit—, y el segundo no se ejecutaba nunca. Decirlo distinto es lo
+// único que le permite a alguien darse cuenta de cuál de los dos tenía.
+function reportarQuitadas(name, dropped, vigentes, output) {
+  const wrappers = new Map()
+  const sueltas = []
+  for (const command of dropped) {
+    const hit = supersededGuards().find(
+      (entry) => command.endsWith(entry.file) && [...vigentes].some((v) => v.endsWith(entry.wrapper)),
+    )
+    if (hit) wrappers.set(hit.wrapper, [...(wrappers.get(hit.wrapper) || []), hit.file])
+    else sueltas.push(command)
+  }
+  for (const [wrapper, files] of wrappers) {
+    output.log(`− ${name}: reemplazado ${[...new Set(files)].join(', ')} por ${wrapper}`)
+  }
+  for (const command of sueltas) output.log(`− ${name}: quitada una entrada obsoleta (${command})`)
+}
+
 function includesConfig(actual, expected) {
   if (Array.isArray(expected)) {
     return Array.isArray(actual) && expected.every((item) => {
@@ -79,7 +128,7 @@ function includesConfig(actual, expected) {
 }
 
 // Dónde abre el dev su herramienta, que no siempre es la raíz ops. En modo sidecar el repo ops es
-// un hermano de los repos de producto: `aparatejo-ops/` coordina, `aparatejo/` es lo que se abre.
+// un hermano de los repos de producto: `<empresa>-ops/` coordina, `<empresa>/` es lo que se abre.
 // Instalar dentro del sidecar dejaría al runner sin ver una sola línea de código.
 function installRoot(root) {
   try {
@@ -89,7 +138,7 @@ function installRoot(root) {
   return root
 }
 
-// Cómo se nombra la raíz ops desde ahí: `aparatejo-ops/` en sidecar, vacío cuando coinciden.
+// Cómo se nombra la raíz ops desde ahí: `<empresa>-ops/` en sidecar, vacío cuando coinciden.
 function opsPrefix(root) {
   const relative = path.relative(installRoot(root), root)
   return relative ? `${relative.split(path.sep).join('/')}/` : ''
@@ -114,6 +163,8 @@ function runnerPaths(root, name, runner) {
 
 function resolveItem(paths, root, name, item) {
   return {
+    automationRoot: paths.automationRoot,
+    opsRoot: root,
     source: F.assertWithin(
       paths.automationRoot,
       path.resolve(paths.sourceDir, item.source),
@@ -135,12 +186,42 @@ function resolveItem(paths, root, name, item) {
 // Un solo render, y `install` escribe exactamente lo que `doctor` compara.
 const OPS_DIR = '{{OPS_DIR}}'
 
-function render(file, prefix) {
-  return fs.readFileSync(file, 'utf8').split(OPS_DIR).join(prefix)
+// Un fragmento que varios adaptadores comparten, resuelto contra la raíz de `automatization/`. El
+// arranque es el mismo trabajo en tres formatos —la sección de un `AGENTS.md`, el cuerpo de un
+// `SKILL.md`, el prompt de un `.toml`—, y escrito tres veces hizo lo que hace siempre una copia: dos
+// de ellas anunciaban cinco puntos y enumeraban seis, con el sexto doblado dentro del quinto.
+//
+// El workflow de Claude queda afuera a propósito: es un programa con fases y esquemas, no una prosa
+// enmarcada, así que su arranque no es una copia de éste sino otra cosa.
+//
+// Se resuelve antes que `{{OPS_DIR}}` para que el fragmento también reciba el prefijo, y no anida:
+// lo incluido se copia tal cual.
+const INCLUDE = /\{\{INCLUDE:([^}]+)\}\}/g
+
+function inline(text, automationRoot) {
+  return text.replace(INCLUDE, (_, relative) => {
+    const shared = F.assertWithin(
+      automationRoot,
+      path.resolve(automationRoot, relative.trim()),
+      'INCLUDE',
+    )
+    return fs.readFileSync(shared, 'utf8').trimEnd()
+  })
+}
+
+// `{{OPS_ROOT}}` es la raíz absoluta. La necesita quien no puede deducirla de dónde lo ejecutaron
+// —el puente de Antigravity—, y por eso no reemplaza a `{{OPS_DIR}}`: una ruta absoluta escrita en un
+// archivo se rompe si el proyecto se mueve, así que la lleva sólo el que se queda sin alternativa.
+const OPS_ROOT = '{{OPS_ROOT}}'
+
+function render(file, prefix, automationRoot, opsRoot = '') {
+  return inline(fs.readFileSync(file, 'utf8'), automationRoot)
+    .split(OPS_ROOT).join(opsRoot)
+    .split(OPS_DIR).join(prefix)
 }
 
 function runnerConfig(paths, root) {
-  return JSON.parse(render(paths.configSource, opsPrefix(root)))
+  return JSON.parse(render(paths.configSource, opsPrefix(root), paths.automationRoot, root))
 }
 
 // Cargos del catálogo, con el frontmatter que el runner indexa para elegir a quién invocar.
@@ -181,6 +262,18 @@ function installRoleSkills(root, runner, output) {
   const install = installRoot(root)
   const base = F.assertWithin(install, path.resolve(install, runner.roleSkills), `${runner.name}: roleSkills`)
   const roles = roleCatalog(root)
+  // Los cargos y los recorridos comparten el espacio de nombres de skills del runner, así que un cargo
+  // que se llame como un recorrido lo pisa. Hoy no pasa, y por eso mismo hay que detenerlo acá: el
+  // catálogo de una empresa es suyo, nadie le prohíbe un cargo `team`, y el daño sería que `/cauce:team`
+  // deje de existir sin que nada falle. Renombrar el cargo es la salida, y sólo la puede tomar alguien.
+  const recorridos = new Set((runner.commands && runner.commands.names) || [])
+  const chocan = roles.filter((role) => recorridos.has(role.slug)).map((role) => role.slug)
+  if (chocan.length) {
+    throw new Error(
+      `${runner.name}: ${chocan.join(', ')} es a la vez un cargo y un recorrido, y comparten `
+      + `${runner.roleSkills}. Renombrá el cargo en agents/roles/ antes de instalar.`,
+    )
+  }
   for (const role of roles) {
     const file = path.join(base, role.slug, 'SKILL.md')
     F.assertNoSymlinkPath(install, file)
@@ -329,42 +422,6 @@ function supersededGuards() {
   return entries
 }
 
-// Reemplaza las entradas sueltas que este mismo toolkit escribió por el grupo que ya las cubre.
-// Sin esto, una instalación previa ejecuta cada guard dos veces por herramienta: con `verify` eso
-// significa correr la suite de tests del proyecto dos veces en cada commit.
-function pruneSupersededHooks(config) {
-  const registered = JSON.stringify(config)
-  const targets = supersededGuards().filter((entry) => registered.includes(entry.wrapper))
-  const replaced = new Map()
-  if (!targets.length) return { config, replaced: [] }
-
-  const isEmptyEntry = (item) => item && typeof item === 'object'
-    && Array.isArray(item.hooks) && !item.hooks.length
-  const walk = (node) => {
-    if (Array.isArray(node)) {
-      const kept = []
-      for (const item of node) {
-        const command = item && typeof item === 'object' ? String(item.command || '') : ''
-        const hit = targets.find((entry) => command.endsWith(entry.file))
-        if (hit) {
-          replaced.set(hit.wrapper, [...(replaced.get(hit.wrapper) || []), hit.file])
-          continue
-        }
-        const walked = walk(item)
-        if (!isEmptyEntry(walked)) kept.push(walked)
-      }
-      return kept
-    }
-    if (node && typeof node === 'object') {
-      return Object.fromEntries(Object.entries(node).map(([key, value]) => [key, walk(value)]))
-    }
-    return node
-  }
-
-  const pruned = walk(config)
-  return { config: pruned, replaced: [...replaced].map(([wrapper, files]) => ({ wrapper, files })) }
-}
-
 // Wiring heredado: guards que ahora corren agrupados pero siguen registrados uno por uno.
 // Conviven sin romper nada, a costa de ejecutar el guard dos veces por herramienta.
 function legacyGuardWiring(config) {
@@ -406,8 +463,10 @@ function probeBridge(paths, runner) {
       // Cada evento tiene su respuesta sana: `stop` cierra la sesión —eso es funcionar— y el resto deja
       // pasar. El puente falla cerrado, así que `deny` en una llamada inocua es que algo se rompió antes
       // de poder juzgarla, y `continue` es el camino de error del propio `stop`.
+      // Y sin `reason`: el puente sólo la manda cuando algo falló, así que un `stop` que la trae es
+      // una falla de infraestructura que se dejó cerrar la sesión, no un arranque sano.
       const sana = evento === 'stop' ? 'stop' : 'allow'
-      if (respuesta.decision === sana) continue
+      if (respuesta.decision === sana && !respuesta.reason) continue
       const salida = (result.stderr || 'sin respuesta').trim().split('\n')[0]
       const motivo = respuesta.reason
         || (respuesta.decision ? `respondió ${respuesta.decision}` : salida)
@@ -442,7 +501,7 @@ function doctor(root, name, output = console) {
     // que su hash difiere siempre. Comparado como archivo, `doctor` avisaba cuando el bloque estaba bien
     // y callaba cuando alguien lo había borrado, que es exactamente al revés.
     if (esArchivoCompartido(root, resolved.target)) {
-      const contenido = render(resolved.source, opsPrefix(root))
+      const contenido = render(resolved.source, opsPrefix(root), resolved.automationRoot, resolved.opsRoot)
       if (!fs.existsSync(resolved.target)) errors.push(`falta ${item.target}`)
       else if (!fs.readFileSync(resolved.target, 'utf8').includes(bloqueInicio(name))) {
         errors.push(`${item.target}: no tiene las instrucciones de Cauce; reinstalá el adaptador`)
@@ -529,7 +588,8 @@ function deliveryKey(name, target) {
 function deliveryState(recorded, name, resolved, prefix = '') {
   if (!fs.existsSync(resolved.target)) return 'nuevo'
   const current = M.digest(resolved.target)
-  if (current === M.digestText(render(resolved.source, prefix))) return 'al día'
+  const esperado = render(resolved.source, prefix, resolved.automationRoot, resolved.opsRoot)
+  if (current === M.digestText(esperado)) return 'al día'
   const delivered = recorded[deliveryKey(name, resolved.item.target)]
   return delivered && delivered === current ? 'desactualizado' : 'ajeno'
 }
@@ -720,11 +780,15 @@ function install(root, name, output = console, options = {}) {
       + 'configuración de tu runner. Si el cambio ya no te sirve, repetí con --force.',
     )
   }
-  const merged = pruneSupersededHooks(mergeConfig(current, incoming))
-  F.atomicWriteJson(paths.configTarget, merged.config)
-  for (const { wrapper, files } of merged.replaced) {
-    output.log(`− ${name}: reemplazado ${[...new Set(files)].join(', ')} por ${wrapper}`)
-  }
+  // Un archivo que existe sólo porque Cauce lo creó se escribe entero. Los `settings.json` de Claude y
+  // Gemini son del usuario, así que ahí se fusiona; pero fusionar conserva también lo que pusimos en
+  // una versión anterior, y una entrada nuestra que quedó viva apuntando a donde ya no hay nada es un
+  // guard que el runner intenta ejecutar y falla. Se quitan las nuestras y las vuelve a poner el merge.
+  const vigentes = new Set((JSON.stringify(incoming).match(/"command":"[^"]*"/g) || [])
+    .map((entry) => JSON.parse(`{${entry}}`).command))
+  const limpio = runner.config.owned ? { config: {}, dropped: [] } : withoutDeliveredHooks(current, vigentes)
+  reportarQuitadas(name, limpio.dropped, vigentes, output)
+  F.atomicWriteJson(paths.configTarget, mergeConfig(limpio.config, incoming))
   // Dónde aterrizó, no sólo qué archivo: en sidecar el destino no es el repo desde el que se corrió
   // el comando, y descubrirlo por sorpresa es la diferencia entre confiar y adivinar.
   if (paths.install !== root) {
@@ -736,7 +800,7 @@ function install(root, name, output = console, options = {}) {
     const situacion = state.get(resolved)
     const propio = runner.instructions.includes(resolved.item)
     if (propio && esArchivoCompartido(root, resolved.target)) {
-      const contenido = render(resolved.source, opsPrefix(root))
+      const contenido = render(resolved.source, opsPrefix(root), resolved.automationRoot, resolved.opsRoot)
       if (bloqueAlDia(resolved.target, name, contenido)) {
         output.log(`= ${name}: ${resolved.item.target} ya trae sus instrucciones`)
       } else {
@@ -752,7 +816,8 @@ function install(root, name, output = console, options = {}) {
       output.log(`= ${name}: ${resolved.item.target} ya está al día`)
     } else {
       fs.mkdirSync(path.dirname(resolved.target), { recursive: true })
-      F.atomicWrite(resolved.target, render(resolved.source, opsPrefix(root)))
+      const escrito = render(resolved.source, opsPrefix(root), resolved.automationRoot, resolved.opsRoot)
+      F.atomicWrite(resolved.target, escrito)
       const verbo = situacion === 'nuevo' ? 'instalado' : 'actualizado'
       output.log(`✓ ${name}: ${verbo} ${resolved.item.target}`)
     }
@@ -798,6 +863,7 @@ module.exports = {
   legacyGuardWiring,
   roleCatalog,
   roleSkill,
+  render,
   listHooks,
   runnerManifest,
 }

package/engine/cli/ops.js

@@ -831,13 +831,19 @@ function destroy(dir, cli) {
     perdida.contexto && 'el contexto escrito en organization/',
   ].filter(Boolean)
 
+  const embebido = O.mode(root) === 'embedded'
   if (!cli.has('--force')) {
-    console.log(`Borrar ${root} se lleva:`)
+    console.log(embebido
+      ? `Sacar Cauce de ${root} se lleva:`
+      : `Borrar ${root} se lleva:`)
     for (const linea of lineas) console.log(`  − ${linea}`)
     if (!lineas.length) console.log('  − nada escrito todavía: la instancia está como salió de init')
     if (perdida.runners.length) {
       console.log(`  y saca el wiring de: ${perdida.runners.join(', ')} (lo tuyo queda donde está)`)
     }
+    if (embebido) {
+      console.log('  el código del repositorio no se toca: en modo embebido la instancia es él mismo.')
+    }
     console.log('\nNada de esto lo repone un init. Si es lo que querés: repetí con --force.')
     process.exit(1)
   }
@@ -847,6 +853,17 @@ function destroy(dir, cli) {
   }
   // El orden no es negociable: primero el wiring, después la carpeta. Al revés, cada llamada de
   // herramienta del runner queda ejecutando un guard que ya no está.
+  // En modo embebido la instancia **es** el repositorio: borrar la carpeta se lleva el código del
+  // producto, que Cauce nunca escribió y no repone nadie. Ahí se saca lo del toolkit y se deja el repo.
+  if (O.mode(root) === 'embedded') {
+    const suyo = [
+      'planning', 'organization', 'teams', 'integrations', 'automatization', 'tools',
+      'ops.config.json', '.cauce', 'AGENTS.md',
+    ]
+    for (const relative of suyo) fs.rmSync(path.join(root, relative), { recursive: true, force: true })
+    console.log(`✓ ${suyo.length} ruta(s) de Cauce quitadas de ${root}`)
+    return console.log('  tu repositorio queda donde está: en modo embebido la instancia era él mismo.')
+  }
   const adentro = process.cwd() === root || process.cwd().startsWith(`${root}${path.sep}`)
   fs.rmSync(root, { recursive: true, force: true })
   console.log(`✓ ${root} borrado`)
@@ -1269,7 +1286,8 @@ function automation(action, rootArg, runnerName, cli) {
     const force = cli.has('--force')
     try { runner = A.install(root, runnerName, console, { force }) } catch (error) { fail(error.message, 2) }
     if (runnerName === 'codex') {
-      console.log('  Codex pedirá revisar y confiar en hooks nuevos al iniciar sesión.')
+      console.log('  Codex deja los hooks nuevos sin correr hasta que los confíes: abrí una sesión')
+      console.log('  y usá /hooks para revisarlos y marcarlos como confiables.')
     }
     if (!runner.capabilities.nativeHooks) {
       console.log(`  ${runnerName} no expone hooks nativos; aplica guards como prechecks.`)

package/engine/hooks/run.js

@@ -29,12 +29,23 @@ function fileOf(input) {
     || input.file_path || input.path || process.env.OPS_HOOK_FILE || '')
 }
 
+// El sobre de `apply_patch`, venga por donde venga. Codex lo manda entero como `command` en vez de
+// `patch`, y sin reconocerlo ahí el guard de archivos no ve ni un archivo: mira una escritura que
+// reemplaza una migración o filtra una credencial y la deja pasar sin decir nada. Se exige el
+// encabezado en vez de aceptar cualquier `command`, para no leer un comando de shell como si fuera
+// contenido de archivo.
+function patchOf(input) {
+  const campos = input.tool_input || {}
+  const command = String(campos.command || '')
+  const sobre = command.startsWith('*** Begin Patch') ? command : ''
+  return String(campos.patch || campos.input || input.patch || sobre || '')
+}
+
 function filesOf(input) {
   const files = new Set()
   const direct = fileOf(input)
   if (direct) files.add(direct)
-  const patch = String(input.tool_input && (input.tool_input.patch || input.tool_input.input)
-    || input.patch || '')
+  const patch = patchOf(input)
   for (const match of patch.matchAll(/^\*\*\* (?:Add|Update|Delete) File:\s*(.+)$/gm)) files.add(match[1].trim())
   return [...files]
 }
@@ -46,7 +57,7 @@ function contentOf(input) {
     || input.tool_input.patch
     || input.tool_input.input
   )
-    || input.content || input.patch || '')
+    || input.content || input.patch || patchOf(input) || '')
 }
 
 function cwdOf(input) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ingeniomaps/cauce",
-  "version": "0.40.0",
+  "version": "0.42.0",
   "description": "Sistema portable de planificación y ejecución verificable para cualquier proyecto",
   "keywords": [
     "planning",