@ingeniomaps/cauce 0.79.0 → 0.81.0

package/CHANGELOG.md

@@ -14,6 +14,138 @@ 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.81.0] - 2026-09-11
+
+### Cambiado
+
+- **Lo que pedís en el chat ya no te frena.** Los guards veían la herramienta y nada de la conversación,
+  así que frenaban igual lo que pediste con todas las letras y lo que el agente decidía solo. Ahora, en
+  Claude Code, Codex y Gemini, un hook registra tu mensaje y los guards lo leen: si nombraste lo que se
+  iba a frenar —«borrá la prueba de altas», «reescribí la migración 004»—, pasa; si no, el agente te dice
+  qué se frenó y un «dale» aprueba exactamente eso. `plan-first` deja de pedir un plan cuando el cambio lo
+  pediste vos. Lo que el agente hace por su cuenta, dentro de un recorrido o en un subagente, se sigue
+  frenando igual.
+
+  **Qué cambia para vos**: corré `automation install` para que tu runner registre el hook nuevo
+  (`UserPromptSubmit` en Claude y Codex, `BeforeAgent` en Gemini); en Codex, confialo con `/hooks`. Tu
+  mensaje se guarda en el temporal del sistema, no en el repositorio, y sólo el último de cada sesión.
+  Antigravity sigue con el archivo de aprobación.
+
+- **Leer una credencial por shell se frena en los cuatro runners, y en Claude ya no te frena a vos.** Un
+  guard nuevo, `secrets-shell`, frena el comando que muestra una credencial —`cat .env`, `head`, `grep`,
+  `source`, una redirección `<`, un `node -e`— en Claude, Codex, Gemini y Antigravity. Hasta ahora sólo
+  Claude lo frenaba, con reglas nativas `permissions.deny` que tampoco dejaban pasar tu pedido; esas reglas
+  se retiran, y como con el resto de los guards, si lo pedís en el chat, pasa.
+
+  **Qué cambia para vos**: corré `automation install`; en Claude quita las reglas que Cauce había puesto y
+  conserva las tuyas. Si querés un bloqueo nativo total, escribilo como regla propia.
+
+### Corregido
+
+- **El bloqueo de `verify` cita la prueba que falló también con jest, vitest, mocha y pytest.** Con esas
+  herramientas citaba el archivo, el resumen o —con `pytest -v`— una prueba verde cuyo nombre decía «error».
+  Ahora reconoce cómo marca cada una la prueba que falla, comprobado contra la salida real de cada una.
+
+  **Qué cambia para vos**: el mensaje apunta a la prueba que hay que mirar.
+
+- **El agente ya no puede escribirse la aprobación.** `planning/.ops-approval` se escribía con la misma
+  herramienta que usa el agente y ningún guard lo miraba, así que una aprobación suya destrababa igual que
+  una tuya. Los guards de límites lo frenan ahora —por la herramienta de escritura y por el destino evidente
+  de un comando—, salvo que se lo hayas pedido nombrándolo en el chat.
+
+  **Qué cambia para vos**: nada si el archivo lo editás vos. Si el agente lo escribía por pedido tuyo,
+  ahora se lo pedís en el chat.
+
+- **En sidecar, el bloqueo dice en qué archivo aprobar.** Mandaba a `planning/.ops-approval`, y desde la
+  carpeta del workspace, donde se abre la sesión, ése no es el `planning/` de la instancia: pegar donde
+  decía no destrababa nada. Ahora nombra la ruta que el guard lee —`acme-ops/planning/.ops-approval`—; en
+  modo embebido sigue diciendo `planning/.ops-approval`.
+
+  **Qué cambia para vos**: nada que hacer; el mensaje dice dónde.
+
+## [0.80.0] - 2026-09-10
+
+### Agregado
+
+- **Leer una credencial también se frena, y las identidades declaradas cuentan como credencial.** Un guard
+  nuevo, `secrets-read`, corre en la herramienta de lectura de Claude (`Read`) y de Gemini (`read_file`) y
+  frena los mismos archivos que `secrets` frena al escribir. Esos archivos ahora incluyen las identidades
+  `source: file` de `organization/secrets.json`, que antes pasaban por no tener nombre de credencial. En
+  Claude, además, la instalación agrega reglas `permissions.deny` `Read(...)` que el propio Claude aplica
+  también a `cat`, `head`, `tail`, `sed` y redirecciones.
+
+  **Qué cambia para vos**: el agente deja de poder leer `.env`, claves y tokens conocidos; `.env.example`
+  sigue legible. Si una lectura hace falta, aprobá la ruta en `planning/.ops-approval`. Corré
+  `automation install` para que tu `.claude/settings.json` reciba las reglas: se suman a las tuyas. No es un
+  límite de seguridad —un `grep -r` o un script propio siguen leyendo—, y en Codex y Antigravity no hay guard
+  de lectura.
+
+- **Un proveedor de integraciones propio, sin tocar Cauce.** El registro de `integrations/config.json`
+  ya tenía un campo `adapter` que nadie leía: ahora `"adapter": "./adapter.js"` carga el adaptador de la
+  empresa desde `integrations/<nombre>/`, e `integration enable` lo conecta sin exigir un molde de Cauce.
+  El adaptador declara `contract: 1` y las tres funciones del contrato, y `check` rechaza el que no
+  cumpla.
+
+  **Qué cambia para vos**: nada si sólo usás Jira. Para otra herramienta, `integrations/README.md` de tu
+  instancia trae el recorrido.
+
+- **Un contrato de secretos compartido entre repositorios, y un chequeo sin red.** Si tus servicios
+  usan un gestor de secretos, los scripts y workflows que lo conectan terminan copiados en cada
+  repositorio, y el arreglo que alguien hizo en uno no llega a los demás. `organization/secrets.json`
+  declara qué cuenta, qué identidad y qué archivos comparte cada servicio, y
+  `node tools/ops.js secrets check .` compara cada copia contra la canónica que guarda la instancia:
+  dice cuál quedó atrás y el `cp` que la pone al día. También falla si una credencial vive dentro de un
+  repositorio o si la declaración guarda un valor en vez de una referencia.
+
+  **Qué cambia para vos**: nada si no lo usás. Para adoptarlo, `organization/README.md` trae el formato
+  y el recorrido. Cauce no se conecta a ningún gestor ni trae adaptadores: lo que habla con el gestor
+  sigue siendo tuyo. Si tus proyectos tienen instancias separadas, el chequeo sólo compara dentro de
+  cada una: para que un esqueleto y sus derivados se midan contra lo mismo, van como raíces de la misma
+  instancia.
+
+### Corregido
+
+- **`init` rechaza un runner mal escrito sin crear la instancia.** Con `--runner none` —el valor es
+  `ninguno`— o una `--integration` que no existe, `init` escribía la instancia entera y recién después
+  salía con error: el código de salida decía que no había pasado nada y el segundo intento encontraba la
+  carpeta creada. Ahora valida los dos valores antes de escribir.
+
+  **Qué cambia para vos**: nada con un valor correcto. Con uno mal escrito, el destino queda como estaba.
+
+- **El bloqueo de `verify` cita la prueba que falló.** Mostraba la primera línea de la salida que dijera
+  «error», y en un reporte de pruebas ésa puede ser una verde cuyo nombre lo dice. Ahora, con la salida de
+  `node --test` —spec y TAP— y de `go test`, cita la primera prueba en rojo; con otras herramientas sigue
+  buscando por palabra, pero ya no elige una línea marcada como verde.
+
+  **Qué cambia para vos**: el mensaje apunta a la prueba que hay que mirar.
+
+- **Cada bloqueo con salida angosta dice qué líneas pegar.** Aprobar en `planning/.ops-approval` sólo
+  funciona si la ruta está escrita en la forma que ese guard coteja —absoluta la de un `Write`, relativa
+  al repositorio la de un commit—, y el mensaje decía «escribí esa(s) ruta(s)» sin nombrarlas. `verify`
+  y `dependencies` ni siquiera mostraban la línea. Ahora cada bloqueo imprime las líneas exactas, y
+  pegarlas tal cual destraba ese mismo bloqueo.
+
+  **Qué cambia para vos**: si una aprobación no pegaba y terminabas exportando la variable del guard,
+  pegá lo que dice el mensaje.
+
+- **`plan-first` deja de frenar la configuración y los archivos de la instancia.** Frenaba
+  `ops.config.json` —justo el archivo que el límite de raíces manda a editar para declarar una ruta— y,
+  en sidecar, también `AGENTS.md`, `CLAUDE.md`, `package.json` y `.gitignore` de la instancia, como si
+  fueran producto. Ahora producto es el código de una raíz declarada: la instancia sidecar no lo es
+  aunque viva dentro de su raíz (`..`), y lo que queda fuera de toda raíz —lo declarado en
+  `writableOutsideRoots`— tampoco. En embedded, el `package.json` de la raíz sigue siendo producto.
+
+  **Qué cambia para vos**: si aprobabas esas rutas a mano en `.ops-approval` o exportabas
+  `OPS_PLAN_FIRST_OVERRIDE` para poder tocarlas, ya no hace falta.
+
+- **`verify` deja afuera del índice de su copia lo que enlaza.** Cuando el árbol difiere del índice, el
+  guard corre los gates sobre una copia del índice con lo ignorado enlazado —`node_modules`, `.env`—. Si
+  tu `.gitignore` escribe ese directorio con barra final (`node_modules/`), el enlace entraba al índice de
+  la copia, y un gate que recorre lo trackeado —`git ls-files`— lo recibía como si fuera parte del commit.
+
+  **Qué cambia para vos**: si una suite que pasa a mano fallaba bajo `verify` sólo cuando tenías archivos
+  sin trackear, podía ser esto.
+
 ## [0.79.0] - 2026-09-10
 
 ### Corregido

package/README.md

@@ -216,6 +216,7 @@ Lee [template/planning/PROTOCOL.md](template/planning/PROTOCOL.md) para el contr
 | `ops integration rebase <ops-root> jira KEY` | Recalcula el borrador canónico sin avanzar la base remota. |
 | `ops integration reconcile <ops-root> jira KEY` | Conserva curación sobre la nueva base remota. |
 | `ops integration writeback-plan <ops-root> jira` | Muestra escrituras posibles sin ejecutarlas. |
+| `ops secrets check <ops-root>` | Compara el contrato de secretos compartido contra cada servicio, sin conectarse. |
 | `ops automation list <ops-root>` | Lista adaptadores y su instalación. |
 | `ops automation list-hooks <ops-root>` | Describe los guards portables disponibles. |
 | `ops automation check <ops-root>` | Valida guards, permisos y configuraciones. |
@@ -314,9 +315,11 @@ La sincronización solo lee Jira. `writeback-plan` calcula intención local, no
 `writeBack` permanece en `false`. Consulta el [recorrido de Jira](template/integrations/jira/README.md) antes
 de conectar una instancia real.
 
-Para añadir otra herramienta se crea un adaptador en `engine/integrations/providers/` con `validateConfig`,
-`fetchItems` y `normalizeFixture`, y se registra en `engine/integrations/registry.js`. Staging, revisión,
-promoción y validación no se reimplementan. Consulta [integrations/README.md](integrations/README.md).
+Para añadir otra herramienta no hace falta tocar Cauce: el adaptador se escribe en la instancia, se
+registra con una ruta en el campo `adapter` y cumple el contrato —`contract: 1`, `validateConfig`,
+`fetchItems` y `normalizeFixture`—. Staging, revisión, promoción y validación no se reimplementan. El
+recorrido está en [template/integrations/README.md](template/integrations/README.md) y el contrato en
+[integrations/README.md](integrations/README.md).
 
 ## Hooks y runners
 

package/automatization/hooks/README.md

@@ -4,6 +4,7 @@ Los hooks convierten invariantes comprobables en gates mecánicos. La base recom
 
 - comandos destructivos, force, amend y stage indiscriminado;
 - escritura de secretos o credenciales;
+- lectura de credenciales conocidas o declaradas, en los runners que tienen una herramienta de lectura;
 - 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;
@@ -44,6 +45,46 @@ publica— por la sensación de que ya está cubierto.
 Regla práctica: si algo **tiene** que ser imposible, no lo pongas acá. Ponelo donde no dependa de leer
 una cadena — permisos del runner, alcance del token, aprobación de un PR.
 
+### Leer una credencial
+
+Dos guards frenan leer un archivo que `secrets` frenaría al escribir —los nombres conocidos y las
+identidades que declara `organization/secrets.json`—: `secrets-read` en las herramientas de lectura y de
+búsqueda del runner (`Read` y `Grep` en Claude, `read_file` y `grep_search` en Gemini) y `secrets-shell` en
+el shell de los cuatro runners, cuando un comando la muestra —`cat`, `head`, `grep`, `sed`, `source`, una
+redirección `<`, un intérprete en línea—. Un comodín que la nombra —`rg -g '.env*'`, `--include='*.env'`—
+cuenta igual. Lo que sólo la nombra —`ls`, `test -f`, `rm`, `cp .env.example .env`— pasa, y lo que la
+persona pidió en el chat también.
+
+Lo que no ve ninguno, comprobado en sesiones reales: una búsqueda sobre la carpeta que no nombra el archivo
+—un `rg` de todo el árbol—, un nombre armado en una variable, y en Gemini el propio entorno del runner,
+que carga el `.env` de la carpeta al arrancar (documentado en geminicli.com/docs/reference/configuration):
+un `env` muestra sus valores sin leer ningún archivo.
+
+Hasta 0.80.0 Claude traía además reglas nativas `permissions.deny` `Read(...)`. Las aplica Claude mismo, sin
+pasar por ningún hook, así que frenaban también lo que la persona pedía, mientras en los otros runners el
+shell no tenía freno (caso 104). `automation install` las retira de una instalación anterior y conserva las
+que escribió la empresa: quien quiera un bloqueo nativo total lo escribe como regla propia.
+
+### Lo que pide la persona
+
+Un guard ve la llamada a la herramienta y nada de la conversación, así que frenaba igual lo que la persona
+pidió con todas las letras y lo que el agente decidió solo. `chat` corre sobre el mensaje de la persona —el
+runner lo dispara cuando ella manda algo, nunca por el resultado de una herramienta— y lo deja donde los
+guards lo leen:
+
+- lo que la persona **nombró** en su mensaje pasa: «leé el `.env`» autoriza leer el `.env`, y «no toques
+  el `.env`» no;
+- lo que se frenó sin que lo nombrara queda anotado, y un «dale» en el mensaje siguiente aprueba
+  exactamente eso;
+- `plan-first` no aplica: el plan es del trabajo que va por tareas.
+
+No cuenta cuando no hay persona —CI, o un aviso del runner como el de un subagente que terminó—, cuando lo
+que pidió es un recorrido de Cauce (`/autobuild`, `$flow`…), ni en la llamada de un subagente, que Claude
+marca con `agent_id`. En Claude y Codex cada llamada trae el identificador del mensaje que la originó;
+Gemini no lo manda, y ahí vale el último mensaje. El registro vive en el temporal del sistema, uno por
+sesión, y los guards de límites lo cuidan junto con `planning/.ops-approval`: el agente no puede
+escribirse ninguno de los dos. Como todo lo de esta página, frena la forma habitual y no un script decidido.
+
 ## Cómo se ejecutan
 
 ```text
@@ -67,10 +108,15 @@ 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, test-evidence | `guard-files.sh` |
+| `pre-shell` | destructive, git-add, dependencies, governance, verify, shell-boundary | `guard-shell.sh` |
+| `pre-files` | secrets, generated, workspace-boundary, engine, migrations, integration-snapshot, test-evidence, plan-first | `guard-files.sh` |
+| `pre-read` | secrets-read | `guard-secrets-read.sh` |
+| `prompt` | chat | `guard-chat.sh` |
 | `stop` | planning-drift | `guard-planning-drift.sh` |
 
+`prompt` corre sobre el mensaje de la persona —`UserPromptSubmit` en Claude y Codex, `BeforeAgent` en
+Gemini— y no sobre una herramienta, y su shim sale siempre con 0.
+
 Registrar el grupo gasta un proceso por herramienta en lugar de cinco, con el mismo orden y la misma
 semántica: el primer guard que bloquea corta la ejecución. Un runner que necesite granularidad fina puede
 seguir registrando los wrappers individuales.

package/automatization/hooks/guard-chat.sh

@@ -0,0 +1,5 @@
+#!/usr/bin/env bash
+# Shim: qué registra está en engine/hooks/run.js → guards['chat']. Sale siempre con 0: el runner lo corre
+# sobre el mensaje de la persona, y un 2 ahí no frena una herramienta sino lo que la persona escribió.
+"$(dirname "$0")/run-hook.sh" chat >/dev/null 2>&1
+exit 0

package/automatization/hooks/guard-secrets-read.sh

@@ -0,0 +1,3 @@
+#!/usr/bin/env bash
+# Shim: qué bloquea el guard está en engine/hooks/run.js → guards['secrets-read'].
+exec "$(dirname "$0")/run-hook.sh" secrets-read

package/automatization/hooks/guard-secrets-shell.sh

@@ -0,0 +1,3 @@
+#!/usr/bin/env bash
+# Shim: qué bloquea el guard está en engine/hooks/run.js → guards['secrets-shell'].
+exec "$(dirname "$0")/run-hook.sh" secrets-shell

package/automatization/runners/claude/README.md

@@ -1,12 +1,15 @@
 # Claude Code
 
-Adaptador nativo mediante `PreToolUse` y `Stop`. Instalar con:
+Adaptador nativo mediante `PreToolUse`, `UserPromptSubmit` y `Stop`. Instalar con:
 
 ```bash
 node tools/ops.js automation install . claude
 ```
 
-El instalador fusiona la sección `hooks` en `.claude/settings.json` y conserva otras claves. Si ya
+El instalador fusiona la sección `hooks` en `.claude/settings.json` y conserva otras claves. Las reglas
+`permissions.deny` `Read(...)` que Cauce sumaba hasta 0.80.0 las retira al reinstalar —las declara
+`config.retired` en `manifest.json`— y deja las que el proyecto haya escrito: leer una credencial lo frenan
+ahora los guards, y lo que la persona pide en el chat pasa (caso 104). 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.
 

package/automatization/runners/claude/manifest.json

@@ -4,7 +4,32 @@
   "command": "claude",
   "config": {
     "source": "settings.json",
-    "target": ".claude/settings.json"
+    "target": ".claude/settings.json",
+    "retired": {
+      "permissions": {
+        "deny": [
+          "Read(.env)",
+          "Read(.env.local)",
+          "Read(.env.*.local)",
+          "Read(.npmrc)",
+          "Read(.netrc)",
+          "Read(_netrc)",
+          "Read(.pypirc)",
+          "Read(.dockercfg)",
+          "Read(id_rsa)",
+          "Read(id_dsa)",
+          "Read(id_ecdsa)",
+          "Read(id_ed25519)",
+          "Read(credentials)",
+          "Read(credentials*.json)",
+          "Read(*service-account*.json)",
+          "Read(*.pem)",
+          "Read(*.key)",
+          "Read(accesos.md)",
+          "Read(credenciales*)"
+        ]
+      }
+    }
   },
   "instructions": [
     {

package/automatization/runners/claude/settings.json

@@ -12,6 +12,19 @@
         "hooks": [
           { "type": "command", "command": "$CLAUDE_PROJECT_DIR/{{OPS_DIR}}automatization/hooks/guard-files.sh" }
         ]
+      },
+      {
+        "matcher": "Read|Grep",
+        "hooks": [
+          { "type": "command", "command": "$CLAUDE_PROJECT_DIR/{{OPS_DIR}}automatization/hooks/guard-secrets-read.sh" }
+        ]
+      }
+    ],
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          { "type": "command", "command": "$CLAUDE_PROJECT_DIR/{{OPS_DIR}}automatization/hooks/guard-chat.sh" }
+        ]
       }
     ],
     "Stop": [

package/automatization/runners/codex/README.md

@@ -18,6 +18,10 @@ 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.
 
+`UserPromptSubmit` registra el mensaje de la persona, para que lo que pidió en el chat pase sin aprobarlo
+a mano. Codex le pasa a cada herramienta el `turn_id` del mensaje que la originó, que es lo que ata la
+llamada al pedido.
+
 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.
 

package/automatization/runners/codex/hooks.json

@@ -14,6 +14,13 @@
         ]
       }
     ],
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          { "type": "command", "command": "{{OPS_ROOT}}/automatization/hooks/guard-chat.sh" }
+        ]
+      }
+    ],
     "SessionEnd": [
       {
         "hooks": [

package/automatization/runners/gemini/README.md

@@ -17,8 +17,12 @@ Antes vivían bajo `/ops:` y eran tres: el arranque y el recorrido de equipo le
 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 CLI tiene hooks nativos y el adaptador los usa: `BeforeTool` y `AfterAgent` en
+Gemini CLI tiene hooks nativos y el adaptador los usa: `BeforeTool`, `BeforeAgent` 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á—.
+confiable —`GEMINI.md` explica qué avisa Gemini cuando no lo está—. `read_file` pasa por
+`guard-secrets-read.sh`, que frena leer una credencial; un `cat` por `run_shell_command` lo frena
+`secrets-shell`, en el grupo de shell.
+`BeforeAgent` registra el mensaje de la persona, para que lo que pidió en el chat pase sin aprobarlo a
+mano; Gemini no le pasa a cada herramienta de qué mensaje viene, así que ahí vale el último.
 
 Comprueba la instalación con `node tools/ops.js automation doctor . gemini`.

package/automatization/runners/gemini/settings.json

@@ -27,6 +27,25 @@
             "command": "$GEMINI_PROJECT_DIR/{{OPS_DIR}}automatization/hooks/guard-files.sh"
           }
         ]
+      },
+      {
+        "matcher": "read_file|grep_search",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "$GEMINI_PROJECT_DIR/{{OPS_DIR}}automatization/hooks/guard-secrets-read.sh"
+          }
+        ]
+      }
+    ],
+    "BeforeAgent": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "$GEMINI_PROJECT_DIR/{{OPS_DIR}}automatization/hooks/guard-chat.sh"
+          }
+        ]
       }
     ],
     "AfterAgent": [

package/engine/automation/index.js

@@ -322,7 +322,7 @@ function uninstall(root, name, output = console) {
 
   if (fs.existsSync(paths.configTarget)) {
     const current = JSON.parse(fs.readFileSync(paths.configTarget, 'utf8'))
-    const clean = unmergeConfig(current, runnerConfig(paths, root))
+    const clean = unmergeConfig(unmergeConfig(current, runnerConfig(paths, root)), runner.config.retired || {})
     if (clean && Object.keys(clean).length) F.atomicWriteJson(paths.configTarget, clean)
     else { removeFile(paths.configTarget, paths.install); removed += 1 }
     output.log(`✓ ${name}: ${runner.config.target} sin las entradas de Cauce`)
@@ -389,6 +389,14 @@ function install(root, name, output = console, options = {}) {
     ? { config: {}, dropped: [] }
     : withoutDeliveredHooks(current, live, previous)
   reportRemoved(name, clean.dropped, live, output)
+  // Lo que Cauce entregó en una versión y retiró en otra sin ser un hook, que el merge no saca: las reglas
+  // `permissions.deny` que puso el 092 y sacó el 104. Se va exactamente lo que el adaptador declara como
+  // retirado; una regla de la empresa que no coincide letra por letra se queda.
+  if (runner.config.retired) {
+    const before = JSON.stringify(clean.config)
+    clean.config = unmergeConfig(clean.config, runner.config.retired) || {}
+    if (JSON.stringify(clean.config) !== before) output.log(`− ${name}: quitadas las reglas que Cauce ya no entrega`)
+  }
   F.atomicWriteJson(paths.configTarget, mergeConfig(clean.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.

package/engine/cli/args.js

@@ -32,6 +32,7 @@ const FLAGS = {
   adopt: [],
   agents: ['--json', '--own', '--system'],
   integration: ['--fixture'],
+  secrets: [],
   automation: ['--force'],
   learn: ['--flow', '--proposal', '--applied', '--archived', '--period'],
   evaluate: ['--cases', '--json', '--bench', '--force', '--record', '--flow'],

package/engine/cli/bootstrap.js

@@ -97,4 +97,4 @@ async function run(root, opciones, deps) {
   return { runner, provider, installed: true }
 }
 
-module.exports = { run, NO_RUNNER, NO_PROVIDER }
+module.exports = { run, validate, NO_RUNNER, NO_PROVIDER }

package/engine/cli/ops.js

@@ -95,11 +95,6 @@ async function init(target, cli) {
   if (existing.length && !force) {
     fail(`El destino no está vacío: ${root}. Usa --force para agregar solo archivos faltantes.`)
   }
-  IN.scaffold(root, { name, mode, force })
-  const relative = path.relative(process.cwd(), root)
-  const enter = relative && relative !== '.' ? `cd ${relative} && ` : ''
-  console.log(`\n✓ ${name}: sistema ops creado en ${root} (modo ${mode})`)
-
   // Preguntar exige una terminal, e instalar baja un paquete y escribe `node_modules`: las dos cosas
   // pasan cuando hay alguien mirando. Una corrida automatizada —CI, un contenedor, estas pruebas—
   // recibe la instancia materializada y decide por bandera, sin descargas ni preguntas implícitas.
@@ -112,6 +107,13 @@ async function init(target, cli) {
     interactive,
     install: cli.has('--install') || (interactive && !cli.has('--no-install')),
   }
+  // Se valida antes de escribir: un runner o una integración que no existen no pueden dejar una
+  // instancia hecha con el comando en error (caso 096). `BOOT.run` vuelve a validar con la misma función.
+  try { BOOT.validate(options) } catch (error) { fail(error.message, 2) }
+  IN.scaffold(root, { name, mode, force })
+  const relative = path.relative(process.cwd(), root)
+  const enter = relative && relative !== '.' ? `cd ${relative} && ` : ''
+  console.log(`\n✓ ${name}: sistema ops creado en ${root} (modo ${mode})`)
   let result
   try {
     result = await BOOT.run(root, options, {
@@ -166,6 +168,7 @@ function usage() {
   ops integration rebase <ops-root> <provider> <remote-key>
   ops integration reconcile <ops-root> <provider> <remote-key>
   ops integration writeback-plan <ops-root> <provider>
+  ops secrets check <ops-root>
   ops automation list <ops-root>
   ops automation list-hooks <ops-root>
   ops automation check <ops-root>
@@ -218,6 +221,7 @@ async function run(cli) {
   else if (command === 'integration') {
     await W.integration(arg[1], arg[2], arg[3], arg[4], cli)
   }
+  else if (command === 'secrets') W.secrets(arg[1], arg[2])
   else if (command === 'automation') W.automation(arg[1], arg[2], arg[3], cli)
   else if (command === 'learn') CAT.learn(arg[1], cli)
   else if (command === 'evaluate') CAT.evaluate(arg[1], arg[2], cli)

package/engine/cli/wiring.js

@@ -8,6 +8,7 @@ const fs = require('node:fs')
 const path = require('node:path')
 const F = require('../core/files')
 const I = require('../integrations/registry')
+const SE = require('../secrets')
 const A = require('../automation')
 const SC = require('../core/scan')
 const OB = require('../core/onboarding')
@@ -38,11 +39,18 @@ const INTEGRATION = {
     missing: 'Falta <provider>.',
     run: (root, provider) => {
       const source = path.join(IN.PROJECT_ROOT, 'template', 'integrations', provider)
-      if (!fs.existsSync(source)) fail(`Cauce no trae un adaptador para ${provider}.`, 2)
+      const fromCauce = fs.existsSync(source)
+      // Sin molde en Cauce no hay andamiaje que reponer: habilitar un proveedor propio es sólo el interruptor.
+      const own = !fromCauce && (providerRegistry(root).config.providers || {})[provider]
+        && fs.existsSync(path.join(root, 'integrations', provider))
+      if (!fromCauce && !own) {
+        fail(`Cauce no trae un adaptador para ${provider}. Uno propio vive en integrations/${provider}/ y se `
+          + `registra en integrations/config.json con "adapter": "./adapter.js"; con eso, enable lo conecta.`, 2)
+      }
       // Habilitar no es inicializar: repone lo que falte y conserva lo que ya esté. Una instancia que
       // trae el andamiaje de una versión anterior —o que ya tiene snapshots— sólo quiere el interruptor.
       providerRegistry(root)
-      IN.copyTemplate(source, path.join(root, 'integrations', provider), {}, true)
+      if (fromCauce) IN.copyTemplate(source, path.join(root, 'integrations', provider), {}, true)
       switchProvider(root, provider, true)
       console.log(`✓ ${provider}: conectado al proyecto y andamiaje en integrations/${provider}/.`)
       // Sólo se pide lo que falta: reencender un proveedor ya configurado no debería mandar a
@@ -277,8 +285,18 @@ function automation(action, rootArg, runnerName, cli) {
   fail(`Acción de automatización desconocida: ${action || '(vacía)'}`, 2)
 }
 
+function secrets(action, rootArg) {
+  if (action !== 'check') fail(`Acción de secretos desconocida: ${action || '(vacía)'}`, 2)
+  const result = SE.check(opsRoot(rootArg))
+  if (!result.declared) return console.log(`Sin ${SE.DECLARATION}: no hay contrato de secretos que comprobar.`)
+  for (const warning of result.warnings) console.log(`⚠ ${warning}`)
+  for (const error of result.errors) console.error(`✗ ${error}`)
+  if (result.errors.length) fail(`${result.errors.length} error(es) en el contrato de secretos`)
+  console.log(`✓ contrato de secretos: ${result.current} servicio(s) al día`)
+}
+
 // `init` enciende un proveedor en la misma corrida en que crea la instancia, y ésta es la operación
 // que lo hace: se expone para que la composición no tenga que conocer la tabla entera.
 const enableProvider = (root, provider) => INTEGRATION.enable.run(root, provider)
 
-module.exports = { scan, onboard, integration, automation, enableProvider }
+module.exports = { scan, onboard, integration, automation, secrets, enableProvider }

package/engine/config/paths.js

@@ -10,7 +10,9 @@ const path = require('node:path')
 
 // `~` se expande sólo cuando es el prefijo entero. `~datos` es un nombre de directorio válido y no la
 // casa de nadie; expandirlo ahí convertiría una ruta relativa en una absoluta que el autor no escribió.
-function resolve(root, entry) {
+// La usa también el contrato de secretos para las rutas de sus identidades, por la misma razón que
+// arriba: una ruta declarada en un archivo del proyecto se resuelve igual la lea quien la lea.
+function resolvePath(root, entry) {
   return path.resolve(root, String(entry).replace(/^~(?=$|[/\\])/, os.homedir()))
 }
 
@@ -21,7 +23,7 @@ function resolve(root, entry) {
 function writableOutsideRoots(root, config) {
   const declared = config && Array.isArray(config.writableOutsideRoots) ? config.writableOutsideRoots : []
   return declared.filter((entry) => typeof entry === 'string' && entry.trim())
-    .map((entry) => ({ declared: entry, path: resolve(root, entry) }))
+    .map((entry) => ({ declared: entry, path: resolvePath(root, entry) }))
 }
 
-module.exports = { writableOutsideRoots }
+module.exports = { writableOutsideRoots, resolvePath }

package/engine/hooks/approval.js

@@ -20,9 +20,14 @@
 //
 // Queda a la vista porque `check` avisa mientras exista. Sin eso, un archivo olvidado sigue autorizando
 // esas mismas rutas la próxima vez que alguien las stagee, que es la puerta abierta que esto evitaba.
+//
+// El archivo es la vía de cuando no hay chat. Con una persona hablando, lo que ella pidió ya está
+// aprobado —cómo se sabe, en `chat.js`—, y escribir el archivo deja de ser necesario (caso 098).
 
 const path = require('node:path')
 const fs = require('node:fs')
+const { opsRoot, cwdOf } = require('./input')
+const CHAT = require('./chat')
 
 const APPROVAL = '.ops-approval'
 
@@ -35,16 +40,45 @@ function read(root) {
 }
 
 // Qué queda sin aprobar de lo que un guard está por bloquear. Se reporta sólo eso: mandar a revisar lo
-// que ya se aprobó es lo que hace que la próxima vez nadie lea el mensaje.
-function pending(root, files) {
+// que ya se aprobó es lo que hace que la próxima vez nadie lea el mensaje. Cuenta también lo que la
+// persona pidió en el chat.
+function pending(root, files, input) {
   const approved = new Set(root ? read(root) : [])
-  return files.filter((file) => !approved.has(file))
+  return CHAT.unauthorized(input, files.filter((file) => !approved.has(file)))
+}
+
+// El archivo que el guard va a leer, nombrado desde la carpeta en la que está la sesión. En sidecar la
+// sesión se abre en el workspace y la instancia es una subcarpeta, así que `planning/` a secas nombraba
+// otro directorio y pegar ahí no destrababa nada (caso 097).
+function where(input) {
+  const root = opsRoot(input)
+  if (!root) return `planning/${APPROVAL}`
+  const file = path.join(root, 'planning', APPROVAL)
+  const session = process.env.CLAUDE_PROJECT_DIR || process.env.GEMINI_PROJECT_DIR || cwdOf(input)
+  const relative = path.relative(session, file)
+  return relative && !relative.startsWith('..') && !path.isAbsolute(relative) ? relative : file
 }
 
-// Cómo se toma la salida angosta, dicho una vez porque ahora lo dicen cinco bloqueos. Nombra también la
-// variable: sigue existiendo, y esconderla haría que quien la necesite la descubra sin saber su alcance.
-const HOW = (variable) => `Aprobalo escribiendo esa(s) ruta(s) en planning/${APPROVAL}, una por línea: `
-  + `vale para ese conjunto y deja de valer en cuanto cambie. La variable ${variable}=1 sigue existiendo `
-  + 'y apaga el guard para toda la sesión, que es por lo que no es la vía recomendada.'
+// Cómo se toma la salida angosta, dicho una vez porque lo dicen todos los bloqueos que la tienen. Lleva
+// las líneas exactas porque cada guard coteja la ruta en la forma que tiene a mano —absoluta la que llega
+// de un Write, relativa al repositorio la que sale del índice— y una línea en la otra forma no pega: sin
+// decirla, lo que quedaba a mano era la variable (caso 089). Nombra también la variable: sigue
+// existiendo, y esconderla haría que quien la necesite la descubra sin saber su alcance.
+//
+// Con una persona en el chat, además, deja anotado lo que se frenó —para eso llama a `hold`— y lo dice
+// primero: contestar es más corto que editar un archivo, y es lo que la persona ya está haciendo. El
+// archivo queda como cosa de ella: dicho en imperativo, el agente leía «aprobalo» como una orden para él
+// e intentaba escribírselo en vez de reintentar, medido en una sesión real de Claude Code.
+function HOW(variable, lines, input) {
+  const chat = CHAT.hold(input, lines)
+  return (chat
+    ? 'Decile a la persona qué se frenó y por qué, y esperá: si contesta «dale», reintentá el mismo cambio y '
+      + 'pasa. Si prefiere aprobarlo a mano, que pegue ella tal cual en'
+    : 'Aprobalo pegando tal cual en')
+    + ` ${where(input)} estas líneas:\n`
+    + lines.map((line) => `  ${line}\n`).join('')
+    + `Valen para ese conjunto y dejan de valer en cuanto cambie. La variable ${variable}=1 sigue existiendo `
+    + 'y apaga el guard para toda la sesión, que es por lo que no es la vía recomendada.'
+}
 
 module.exports = { APPROVAL, read, pending, HOW }