@ingeniomaps/cauce 0.80.0 → 0.81.0

package/CHANGELOG.md

@@ -14,6 +14,55 @@ 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

package/automatization/hooks/README.md

@@ -47,17 +47,43 @@ una cadena — permisos del runner, alcance del token, aprobación de un PR.
 
 ### Leer una credencial
 
-`secrets-read` frena leer, con la herramienta de lectura del runner, un archivo que `secrets` frenaría al
-escribir —los nombres conocidos y las identidades que declara `organization/secrets.json`—. Qué alcanza en
-cada runner es distinto, y conviene saberlo:
-
-- **Claude Code**: el guard corre en `Read`, y además la instalación agrega reglas `permissions.deny`
-  `Read(...)` por los nombres conocidos. Esas reglas las aplica el propio Claude Code a `Read`, a `cat`,
-  `head`, `tail`, `sed` y a las redirecciones, pero no a un `grep -r` ni a un subproceso que abra el archivo
-  por su cuenta. Van por nombre exacto: `.env.*` también negaría `.env.example`.
-- **Gemini CLI**: el guard corre en `read_file`. Un `cat` por `run_shell_command` no lo ve.
-- **Codex y Antigravity**: sin guard de lectura. Sus adaptadores sólo enganchan shell y edición, y leer por
-  shell no pasa por ningún matcher de archivo.
+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
 
@@ -85,8 +111,12 @@ runner, mientras la lógica se prueba y mantiene una sola vez en `engine/hooks/r
 | `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-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,14 +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. También
-suma a `permissions.deny` reglas `Read(...)` por los nombres de credencial conocidos, junto a las que el
-proyecto ya tenga; una que Cauce retire en una versión futura no se quita sola. 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

@@ -1,27 +1,4 @@
 {
-  "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*)"
-    ]
-  },
   "hooks": {
     "PreToolUse": [
       {
@@ -37,12 +14,19 @@
         ]
       },
       {
-        "matcher": "Read",
+        "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": [
       {
         "hooks": [

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,9 +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á—. `read_file` pasa por
-`guard-secrets-read.sh`, que frena leer una credencial; un `cat` por `run_shell_command` no lo ve.
+`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

@@ -29,7 +29,7 @@
         ]
       },
       {
-        "matcher": "read_file",
+        "matcher": "read_file|grep_search",
         "hooks": [
           {
             "type": "command",
@@ -38,6 +38,16 @@
         ]
       }
     ],
+    "BeforeAgent": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "$GEMINI_PROJECT_DIR/{{OPS_DIR}}automatization/hooks/guard-chat.sh"
+          }
+        ]
+      }
+    ],
     "AfterAgent": [
       {
         "hooks": [

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/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,10 +40,23 @@ 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 lo dicen todos los bloqueos que la tienen. Lleva
@@ -46,9 +64,21 @@ function pending(root, files) {
 // 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.
-const HOW = (variable, lines) => `Aprobalo pegando tal cual en planning/${APPROVAL} 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.'
+//
+// 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 }

package/engine/hooks/chat.js

@@ -0,0 +1,122 @@
+'use strict'
+
+// Lo que la persona dijo en el chat, capturado por el runner y no contado por el modelo. Existe porque un
+// guard sólo ve la llamada a la herramienta: frenaba igual lo que la persona pidió con todas las letras y
+// lo que el agente decidió solo, y la única forma de decir «sí» era un archivo que el agente también
+// podía escribirse (caso 098).
+//
+// El hook de mensaje del runner —`UserPromptSubmit` en Claude y Codex, `BeforeAgent` en Gemini— corre
+// cuando la persona manda algo, y Claude y Codex le pasan a cada llamada el identificador del mensaje que
+// la originó. Lo que llega por otro lado —un README, un ticket, el resultado de una herramienta— nunca
+// pasa por acá, y ésa es toda la diferencia entre una orden y una sugerencia.
+//
+// No es un límite de seguridad, como ningún guard: un agente decidido a escribir este registro lo escribe
+// con un script. Lo que se frena es la forma habitual, y la frenan los guards de límites.
+
+const fs = require('node:fs')
+const os = require('node:os')
+const path = require('node:path')
+
+// El temporal y no la instancia: el texto de la persona no tiene por qué terminar en un commit, y una
+// orden dura lo que dura la sesión.
+const DIR = path.join(os.tmpdir(), 'cauce-chat')
+
+// Los recorridos de Cauce, donde el que piensa es el agente y los guards contienen como siempre. Salen de
+// los workflows que el paquete entrega, así que uno nuevo queda cubierto sin tocar esto; los de
+// `integrations/` se invocan con ese prefijo. Claude y Gemini los llaman con `/`, Codex con `$`.
+const WORKFLOWS = path.join(__dirname, '..', '..', 'automatization', 'workflows')
+const scripts = (dir, prefix) => fs.readdirSync(dir).filter((one) => one.endsWith('.js'))
+  .map((one) => `${prefix}${one.slice(0, -3)}`)
+function flowCommand(text) {
+  let names = []
+  try { names = [...scripts(WORKFLOWS, ''), ...scripts(path.join(WORKFLOWS, 'integrations'), 'integration-')] }
+  catch { return false }
+  return names.length > 0 && new RegExp(`^\\s*[/$](?:cauce:)?(?:${names.join('|')})(?![\\w-])`).test(text)
+}
+
+// Claude lo llama `prompt_id` y Codex `turn_id`; Gemini no manda ninguno y ahí vale el último mensaje.
+const idOf = (input) => String(input.prompt_id || input.turn_id || '')
+const recordPath = (session) => path.join(DIR, `${String(session).replace(/[^a-zA-Z0-9_-]/g, '_')}.json`)
+
+function load(session) {
+  try { return JSON.parse(fs.readFileSync(recordPath(session), 'utf8')) } catch { return null }
+}
+
+// Nombrar no es pedir: «no toques el .env» nombra el .env. Cuenta la negación que está en la misma frase y
+// antes del nombre; la coma corta, porque «leé el config, no el .env» son dos pedidos.
+const NEGATION = /(?:^|[^\p{L}])(?:no|nunca|jam[aá]s|ni|sin|not|never|don'?t)(?![\p{L}])/iu
+const CLAUSE = /[.,;:!?\n]/
+
+// Cada aparición del nombre en el texto y si va negada. Un nombre tiene que estar entero: `.env` no
+// aparece en «el .env.example», y un punto sólo lo cierra si termina la frase.
+function mentions(text, item) {
+  const lower = String(text).toLowerCase()
+  const found = []
+  for (const name of new Set([item, path.basename(item)].map((one) => one.toLowerCase()))) {
+    if (name.length < 3) continue
+    for (let at = lower.indexOf(name); at !== -1; at = lower.indexOf(name, at + 1)) {
+      const before = lower[at - 1]
+      const rest = lower.slice(at + name.length)
+      if (before && !/[\s'"`(/]/.test(before)) continue
+      if (rest && !/^(?:[\s'"`),;:!?]|\.(?:\s|$)|$)/.test(rest)) continue
+      found.push(NEGATION.test(lower.slice(0, at).split(CLAUSE).pop()))
+    }
+  }
+  return { named: found.includes(false), denied: found.includes(true) }
+}
+
+// Quien contesta a un bloqueo que quedó pendiente. Sólo el principio del mensaje: «dale» es la respuesta
+// entera o su primera palabra, no algo que aparece en medio de otra frase.
+const YES = new RegExp(String.raw`^\s*(?:s[ií]|dale|ok(?:ay)?|hac[eé]lo|hazlo|adelante|aprobado|apruebo`
+  + String.raw`|aprob[aá]lo|de acuerdo|yes)(?![\p{L}])`, 'iu')
+
+// El hook de mensaje. Nunca frena: un mensaje de la persona no se bloquea, y sin registro los guards
+// deciden como antes. Un texto que empieza con una etiqueta no lo escribió una persona —Claude avisa así
+// que terminó un subagente, con `<task-notification>`—, y en CI no hay persona.
+function record(input) {
+  try {
+    if (!input.session_id) return
+    const text = String(input.prompt || '')
+    const human = !process.env.CI && !/^\s*</.test(text)
+    const previous = load(input.session_id)
+    const approved = human && previous && YES.test(text)
+      ? previous.pending.filter((item) => !mentions(text, item).denied)
+      : []
+    fs.mkdirSync(DIR, { recursive: true })
+    fs.writeFileSync(recordPath(input.session_id),
+      JSON.stringify({ id: idOf(input), text, human, flow: flowCommand(text), approved, pending: [] }))
+  } catch { /* registrar es un extra: si falla, los guards siguen frenando lo que frenaban */ }
+}
+
+// El mensaje de la persona que originó esta llamada, o nada. Nada cuando no hay persona, cuando lo que
+// pidió es un recorrido de Cauce, cuando la llamada la hace un subagente —trabajo que el agente delegó,
+// y Claude lo marca con `agent_id`— o cuando el registro es de otro mensaje.
+function said(input) {
+  if (process.env.CI || input.agent_id || !input.session_id) return null
+  const saved = load(input.session_id)
+  if (!saved || !saved.human || saved.flow) return null
+  const current = idOf(input)
+  return current && saved.id && current !== saved.id ? null : saved
+}
+
+// Lo que la persona no autorizó de lo que un guard está por frenar: ni lo nombró en su mensaje ni lo
+// aprobó contestando.
+function unauthorized(input, items) {
+  const saved = said(input)
+  if (!saved) return items
+  return items.filter((item) => !saved.approved.includes(item) && !mentions(saved.text, item).named)
+}
+
+// Lo que quedó frenado, para que un «dale» en el mensaje siguiente apruebe exactamente eso y nada más.
+// Devuelve si hay una persona a quien preguntarle.
+function hold(input, items) {
+  const saved = said(input)
+  if (!saved) return false
+  try {
+    saved.pending = [...new Set([...saved.pending, ...items])]
+    fs.writeFileSync(recordPath(input.session_id), JSON.stringify(saved))
+    return true
+  } catch { return false }
+}
+
+module.exports = { DIR, record, said, unauthorized, hold }

package/engine/hooks/files.js

@@ -8,24 +8,21 @@ const fs = require('node:fs')
 const path = require('node:path')
 const { spawnSync } = require('node:child_process')
 const {
-  patchOf, filesOf, contentOf, cwdOf, block, configOf, findOpsRoot,
+  patchOf, filesOf, contentOf, cwdOf, block, configOf, findOpsRoot, opsRoot,
   writableRoots, outsideRoots, DECLARE_IT,
 } = require('./input')
 const AP = require('./approval')
+const CHAT = require('./chat')
+const { selfApproval } = require('./self-approval')
 const { readWip } = require('../planning/parser')
 const { runner } = require('../planning/claims')
 const { hasTasks } = require('../planning/state')
 const { TEMPLATE_PREFIXES } = require('../core/ownership')
 
-// La raíz donde vive `planning/`, que es donde se busca la aprobación por operación.
-function opsRoot(input) {
-  return findOpsRoot(process.env.OPS_ROOT || process.env.CLAUDE_PROJECT_DIR || cwdOf(input))
-}
-
 // Si la ruta que este guard está por bloquear está aprobada, no hay nada que decir. Es la salida
 // angosta: vale para esa ruta y deja de valer en cuanto cambie, a diferencia de la variable, que apaga
 // el guard hasta que cierre la sesión.
-const approved = (input, file) => !AP.pending(opsRoot(input), [file]).length
+const approved = (input, file) => !AP.pending(opsRoot(input), [file], input).length
 
 // Si la migración ya viajó a otra copia, que es lo que el bloqueo de abajo quiere saber y `existsSync`
 // no contesta. Devuelve el motivo del bloqueo o cadena vacía.
@@ -88,12 +85,20 @@ function secrets(input) {
 
 // Leer una credencial la deja en el contexto de la sesión, y de ahí en los transcripts. Corre en su propio
 // grupo porque los guards de escritura frenarían leer fuera de las raíces o con el WIP vacío.
+// Un comodín también nombra: `rg -g '.env*'`, el `glob` del Grep de Claude o el `include_pattern` del
+// `grep_search` de Gemini recorren la carpeta buscando justo eso, y así leyeron el `.env` dos agentes en
+// sesiones reales (caso 104). Se prueba el nombre con el comodín vacío, la forma más corta que el patrón
+// acepta.
+const patternNames = (token) => (/[*?]/.test(token) ? [token.replace(/[*?]/g, '')] : [token]).filter(Boolean)
+
 function secretsRead(input) {
   if (process.env.OPS_SECRETS_READ_OVERRIDE === '1') return
-  for (const file of filesOf(input)) {
-    if (!credential(input, file) || approved(input, file)) continue
+  const fields = input.tool_input || {}
+  const patterns = [fields.glob, fields.include_pattern].filter((one) => typeof one === 'string')
+  for (const file of [...filesOf(input), ...patterns]) {
+    if (!patternNames(file).some((name) => credential(input, name)) || approved(input, file)) continue
     block(`${file} es una credencial: leerla la deja en el contexto de la sesión. Si hace falta un valor, `
-      + `pedíselo a una persona.\n${AP.HOW('OPS_SECRETS_READ_OVERRIDE', [file])}`)
+      + `pedíselo a una persona.\n${AP.HOW('OPS_SECRETS_READ_OVERRIDE', [file], input)}`)
   }
 }
 
@@ -147,7 +152,7 @@ function testEvidence(input) {
     'Si la aserción está mal, corregila; si el comportamiento cambió, cambialo junto con la prueba que ' +
     'lo fija. Si tiene que quedar afuera igual —flake conocido, entorno que acá no existe—, es una ' +
     'decisión con dueño.\n'
-  const how = (file) => AP.HOW('OPS_TEST_EVIDENCE_OVERRIDE', [file])
+  const how = (file) => AP.HOW('OPS_TEST_EVIDENCE_OVERRIDE', [file], input)
   for (const match of patchOf(input).matchAll(/^\*\*\* Delete File:\s*(.+)$/gm)) {
     const removed = match[1].trim()
     if (isTestFile(removed) && !approved(input, removed)) block(`${removed} borra una prueba.\n${why}${how(removed)}`)
@@ -208,6 +213,10 @@ function isProduct(root, file) {
 // vigila: la tarea ya está nombrada y el plan todavía no existe.
 function planFirst(input) {
   if (process.env.OPS_PLAN_FIRST_OVERRIDE === '1') return
+  // El plan lo exige el flujo, que es donde piensa el agente. Cuando la persona pide un cambio directo en
+  // el chat la que decidió es ella, y frenarla para que escriba un plan o apruebe una ruta es limitarla en
+  // lo que acaba de pedir (caso 098). Un subagente o un recorrido de Cauce no cuentan: `said` los descarta.
+  if (CHAT.said(input)) return
   const root = opsRoot(input)
   if (!root) return
   const planning = path.join(root, 'planning')
@@ -227,16 +236,18 @@ function planFirst(input) {
   for (const raw of filesOf(input)) {
     if (!isProduct(root, path.resolve(cwdOf(input), raw))) continue
     if (approved(input, raw)) continue
-    block(`${raw} cambia el producto sin plan. ${why}${AP.HOW('OPS_PLAN_FIRST_OVERRIDE', [raw])}`)
+    block(`${raw} cambia el producto sin plan. ${why}${AP.HOW('OPS_PLAN_FIRST_OVERRIDE', [raw], input)}`)
   }
 }
 
 function workspaceBoundary(input) {
   const allowed = writableRoots(input)
-  if (!allowed) return
   for (const raw of filesOf(input)) {
     const file = path.resolve(cwdOf(input), raw)
-    if (outsideRoots(file, allowed)) {
+    // Lo mismo que en `shell-boundary`: la aprobación de la persona se juzga aunque no haya raíces.
+    const own = selfApproval(input, file)
+    if (own) block(own)
+    if (allowed && outsideRoots(file, allowed)) {
       block(`${file} está fuera de las raíces declaradas en ops.config.json. ${DECLARE_IT}`)
     }
   }
@@ -301,7 +312,7 @@ function migrations(input) {
     if (!esMigracion.test(normalized)) continue
     if (approved(input, normalized)) continue
     if (destructiveSql.test(contentOf(input))) {
-      block(`${raw} contiene SQL destructivo.\n${AP.HOW('OPS_MIGRATIONS_OVERRIDE', [normalized])}`)
+      block(`${raw} contiene SQL destructivo.\n${AP.HOW('OPS_MIGRATIONS_OVERRIDE', [normalized], input)}`)
     }
     // El mensaje nombra el hecho que sostiene el bloqueo y no su interpretación: «historial» era una
     // lectura que `existsSync` no podía dar, y se la daba igual sobre stubs de la misma sesión. Y lleva
@@ -311,7 +322,7 @@ function migrations(input) {
     const shipped = alreadyShipped(file)
     if (shipped) {
       block(`${raw} ${shipped}. Crea una nueva en vez de reescribirla.\n`
-        + AP.HOW('OPS_MIGRATIONS_OVERRIDE', [normalized]))
+        + AP.HOW('OPS_MIGRATIONS_OVERRIDE', [normalized], input))
     }
   }
 }
@@ -342,6 +353,7 @@ function engineWrites(input) {
 }
 
 module.exports = {
+  credential, patternNames,
   secrets, secretsRead, integrationSnapshot, generated, testEvidence, planFirst, workspaceBoundary,
   migrations, engineWrites,
 }

package/engine/hooks/input.js

@@ -262,9 +262,15 @@ function outsideRoots(file, allowed) {
 const DECLARE_IT = 'Si el proyecto necesita escribir ahí, declaralo en writableOutsideRoots de '
   + 'ops.config.json; cambiar de herramienta no lo autoriza.'
 
+// La raíz donde vive `planning/`, que es donde se busca la aprobación. La resuelven igual los guards de
+// archivos, los de shell y la aprobación misma, así que se resuelve en un solo lugar.
+function opsRoot(input) {
+  return findOpsRoot(process.env.OPS_ROOT || process.env.CLAUDE_PROJECT_DIR || cwdOf(input))
+}
+
 module.exports = {
   readInput, commandOf, patchOf, filesOf, contentOf, cwdOf, block, configOf,
   gitDirectory, isCommit, withoutGitGlobals, stagedFiles, stagedForCommit, pushAllowed,
-  findOpsRoot,
+  findOpsRoot, opsRoot,
   writableRoots, outsideRoots, DECLARE_IT, unquoted,
 }

package/engine/hooks/run.js

@@ -12,6 +12,8 @@ const path = require('node:path')
 const { readInput, cwdOf, block, findOpsRoot } = require('./input')
 const shell = require('./shell')
 const files = require('./files')
+const chat = require('./chat')
+const { secretsShell } = require('./secrets-shell')
 
 function planningDrift(input) {
   const root = findOpsRoot(process.env.OPS_ROOT || process.env.CLAUDE_PROJECT_DIR || cwdOf(input))
@@ -39,6 +41,7 @@ const guards = {
   governance: shell.governance,
   verify: shell.verify,
   'shell-boundary': shell.shellBoundary,
+  'secrets-shell': secretsShell,
   secrets: files.secrets,
   generated: files.generated,
   'workspace-boundary': files.workspaceBoundary,
@@ -48,15 +51,18 @@ const guards = {
   'test-evidence': files.testEvidence,
   'plan-first': files.planFirst,
   'secrets-read': files.secretsRead,
+  chat: chat.record,
   'planning-drift': planningDrift,
 }
 
 // Grupos por evento: un runner corre el grupo entero en un solo proceso en lugar de un guard por hook.
 const hookGroups = {
-  'pre-shell': ['destructive', 'git-add', 'dependencies', 'governance', 'verify', 'shell-boundary'],
+  'pre-shell': ['destructive', 'git-add', 'dependencies', 'governance', 'verify', 'shell-boundary',
+    'secrets-shell'],
   'pre-files': ['secrets', 'generated', 'workspace-boundary', 'engine', 'migrations',
     'integration-snapshot', 'test-evidence', 'plan-first'],
   'pre-read': ['secrets-read'],
+  prompt: ['chat'],
   stop: ['planning-drift'],
 }
 
@@ -89,7 +95,8 @@ const hookMetadata = [
   {
     name: 'shell-boundary',
     event: 'PreToolUse · shell',
-    purpose: 'Frena el destino evidente de un comando que escribe fuera de las raíces declaradas.',
+    purpose: 'Frena el destino evidente de un comando que escribe fuera de las raíces declaradas, o en la '
+      + 'aprobación de la persona.',
   },
   {
     name: 'secrets',
@@ -101,11 +108,18 @@ const hookMetadata = [
     event: 'PreToolUse · read',
     purpose: 'Bloquea leer con la herramienta del runner una credencial conocida o declarada.',
   },
+  {
+    name: 'secrets-shell',
+    event: 'PreToolUse · shell',
+    purpose: 'Bloquea leer por shell una credencial conocida o declarada; lo que la persona pidió en el chat '
+      + 'pasa.',
+  },
   { name: 'generated', event: 'PreToolUse · files', purpose: 'Impide editar código generado manualmente.' },
   {
     name: 'workspace-boundary',
     event: 'PreToolUse · files',
-    purpose: 'Limita escrituras a las raíces declaradas en ops.config.json.',
+    purpose: 'Limita escrituras a las raíces declaradas en ops.config.json, y no deja al agente escribirse '
+      + 'la aprobación de la persona.',
   },
   {
     name: 'engine',
@@ -133,6 +147,12 @@ const hookMetadata = [
     event: 'PreToolUse · files',
     purpose: 'Exige WIP activo con plan escrito antes de cambiar el producto.',
   },
+  {
+    name: 'chat',
+    event: 'UserPromptSubmit / BeforeAgent',
+    purpose: 'Registra el mensaje de la persona: lo que nombró o aprobó en el chat pasa sin archivo. Nunca '
+      + 'bloquea.',
+  },
   {
     name: 'planning-drift',
     event: 'Stop / SessionEnd',

package/engine/hooks/secrets-shell.js

@@ -0,0 +1,62 @@
+'use strict'
+
+// Leer una credencial por shell. `secrets-read` mira la herramienta de lectura del runner, y un `cat .env`
+// no pasa por ella: en Claude lo tapaba una regla nativa `permissions.deny`, que además frenaba lo que la
+// persona pedía, y en los otros runners no lo tapaba nada (caso 104). Esto lo mira donde pasan todos los
+// comandos, con la misma salida que el resto: lo que la persona pidió en el chat pasa.
+//
+// Como todo lo que lee el texto de un comando, frena la forma habitual y no un script decidido: un nombre
+// armado en una variable o un `grep -r` sobre la carpeta sin nombrar el archivo pasan.
+
+const path = require('node:path')
+const { commandOf, cwdOf, block, isCommit, unquoted, opsRoot } = require('./input')
+const { credential, patternNames } = require('./files')
+const AP = require('./approval')
+
+// Lo que muestra el contenido de un archivo. Queda afuera lo que sólo lo nombra —`ls`, `test -f`, `rm`,
+// `git add`—, que no deja nada en la sesión, y `cp` y `mv`, cuyo último argumento es un destino: `cp
+// .env.example .env` es preparar el entorno, no leerlo. `nl` entró porque un agente lo usó en una sesión
+// real para leer el `.env` después de que la lista no lo tuviera.
+const READERS = new Set(['cat', 'tac', 'nl', 'head', 'tail', 'less', 'more', 'bat', 'sed', 'awk', 'grep', 'egrep',
+  'fgrep', 'rg', 'strings', 'xxd', 'od', 'hexdump', 'base64', 'cut', 'sort', 'uniq', 'rev', 'paste', 'fold', 'pr',
+  'dd', 'jq', 'yq', 'diff', 'cmp', 'source', '.', 'node', 'python', 'python3', 'ruby', 'perl', 'php', 'deno', 'bun'])
+const PREFIXES = new Set(['sudo', 'env', 'command', 'exec', 'time', 'nohup', 'nice', 'xargs'])
+
+// El verbo de un tramo, saltando lo que va delante sin serlo: asignaciones, prefijos y sus banderas.
+function verbOf(words) {
+  let prefixed = false
+  while (words.length && (/^[A-Za-z_][A-Za-z0-9_]*=/.test(words[0]) || PREFIXES.has(words[0])
+    || (prefixed && words[0].startsWith('-')))) {
+    prefixed = prefixed || PREFIXES.has(words[0])
+    words.shift()
+  }
+  return words[0] || ''
+}
+
+// Las palabras de cada tramo que lee: el que empieza con un lector, o el que redirige un archivo a la
+// entrada. Lo entrecomillado se mira, porque el código de un `node -e` nombra el archivo ahí adentro.
+function readTokens(command) {
+  const found = []
+  for (const segment of command.split(/[;&|\n]+|\$\(|`/)) {
+    const words = segment.trim().replace(/^[({]+\s*/, '').split(/\s+/).filter(Boolean)
+    const reads = READERS.has(path.basename(verbOf(words))) || /<(?![<(])/.test(segment)
+    if (reads) found.push(...(segment.match(/[^\s'"`\\;|&<>(){}=,]+/g) || []))
+  }
+  return [...new Set(found)]
+}
+
+function secretsShell(input) {
+  if (process.env.OPS_SECRETS_READ_OVERRIDE === '1') return
+  const raw = commandOf(input)
+  // El mensaje de un commit es dato, como en `destructive`: nombrar el archivo ahí no lo lee.
+  const command = isCommit(raw) ? unquoted(raw) : raw
+  const cwd = cwdOf(input)
+  const files = readTokens(command).filter((token) => patternNames(token).some((name) => credential(input, name)))
+    .map((token) => path.resolve(cwd, token))
+  const left = AP.pending(opsRoot(input), [...new Set(files)], input)
+  if (!left.length) return
+  block(`el comando lee ${left.join(', ')}, que es una credencial: leerla la deja en el contexto de la sesión. `
+    + `Si hace falta un valor, pedíselo a una persona.\n${AP.HOW('OPS_SECRETS_READ_OVERRIDE', left, input)}`)
+}
+
+module.exports = { secretsShell }

package/engine/hooks/self-approval.js

@@ -0,0 +1,31 @@
+'use strict'
+
+// El canal por el que una persona dice «sí» no lo puede escribir el agente: si pudiera, cada bloqueo que
+// ofrece aprobarse se aprobaría solo. Pasaba —ningún guard miraba `planning/.ops-approval`— y en la prueba
+// en vivo del 092 el agente, frenado, intentó escribírsela (caso 098).
+//
+// Lo preguntan los dos guards de límites —el que mira un `Write` y el que mira el destino de un comando—,
+// que ya son los que deciden dónde puede caer una escritura. La persona edita el archivo a mano, que ningún
+// hook ve, o se lo pide al agente nombrándolo en el chat. El registro del chat no lo escribe nunca una
+// herramienta.
+
+const path = require('node:path')
+const { opsRoot } = require('./input')
+const AP = require('./approval')
+const CHAT = require('./chat')
+
+// Por qué el agente no puede escribir en `file`, o vacío.
+function selfApproval(input, file) {
+  if (file === CHAT.DIR || file.startsWith(`${CHAT.DIR}${path.sep}`)) {
+    return `${file} es el registro de lo que la persona dijo en el chat: lo escribe el runner, nunca una `
+      + 'herramienta.'
+  }
+  const root = opsRoot(input)
+  if (!root || file !== path.join(root, 'planning', AP.APPROVAL)) return ''
+  if (!CHAT.unauthorized(input, [file]).length) return ''
+  return `${file} es la aprobación de una persona, y escribírsela es aprobarse solo. Si la persona quiere `
+    + 'autorizar algo, que lo diga en el chat —nombrándolo, o contestando «dale» al bloqueo— o que edite el '
+    + 'archivo ella.'
+}
+
+module.exports = { selfApproval }

package/engine/hooks/shell.js

@@ -10,9 +10,10 @@ const path = require('node:path')
 const { spawnSync } = require('node:child_process')
 const {
   commandOf, cwdOf, block, isCommit, stagedForCommit, pushAllowed,
-  writableRoots, outsideRoots, DECLARE_IT, unquoted, findOpsRoot, withoutGitGlobals,
+  writableRoots, outsideRoots, DECLARE_IT, unquoted, opsRoot, withoutGitGlobals,
 } = require('./input')
 const AP = require('./approval')
+const { selfApproval } = require('./self-approval')
 const EV = require('../core/evidence')
 
 // Dónde empieza y dónde termina una palabra dentro de un comando. Tres reglas de la tabla de abajo lo
@@ -48,12 +49,6 @@ const MISMO = String.raw`[^;&|\n]`
 // `bash -c "git push origin main"` y `eval "git reset --hard"` siguen cayendo, comprobado. Queda afuera
 // la sustitución dentro del propio mensaje —`git commit -m "$(...)"` corre y ya no se ve—, que es
 // evasión y no la forma habitual.
-// La raíz donde vive `planning/`, que es donde se busca la aprobación. Los cuatro guards que la
-// consultan la resuelven igual, así que se resuelve una vez.
-function opsRoot(input) {
-  return findOpsRoot(process.env.OPS_ROOT || process.env.CLAUDE_PROJECT_DIR || cwdOf(input))
-}
-
 function destructive(input) {
   const raw = commandOf(input)
   // Las opciones globales de `git` se sacan acá y no en cada regla: toda regla de abajo que mire un
@@ -181,7 +176,7 @@ function dependencies(input) {
   // `package.json` dice «este manifiesto va sin su lock a propósito» y deja de valer en cuanto el
   // conjunto cambie. La rama de publicar no pasa por acá y no tiene ruta: sigue arriba, con su variable.
   const sinAprobar = (parent, names) => AP.pending(opsRoot(input),
-    names.map((name) => path.posix.join(parent === '.' ? '' : parent, name)))
+    names.map((name) => path.posix.join(parent === '.' ? '' : parent, name)), input)
   // Un lock cuenta si está en disco **o** si el commit lo va a llevar, y la unión no es un detalle: el
   // disco solo perdía el que alguien borró del árbol sin stagear el borrado —sigue en el índice, sigue
   // en el próximo commit— y ahí la comprobación dejaba de dispararse justo cuando más hacía falta. Es
@@ -204,12 +199,12 @@ function dependencies(input) {
     const manifests = sinAprobar(parent, state.manifests)
     if (state.manifests.length && existingLocks.length && !state.locks.length && manifests.length) {
       block(`${parent}: cambió ${state.manifests.join(', ')} sin actualizar su lockfile.\n`
-        + AP.HOW('OPS_DEPENDENCIES_OVERRIDE', manifests))
+        + AP.HOW('OPS_DEPENDENCIES_OVERRIDE', manifests, input))
     }
     const lockfiles = sinAprobar(parent, state.locks)
     if (state.locks.length && !state.manifests.length && lockfiles.length) {
       block(`${parent}: cambió ${state.locks.join(', ')} sin un cambio explícito en el manifest.\n`
-        + AP.HOW('OPS_DEPENDENCIES_OVERRIDE', lockfiles))
+        + AP.HOW('OPS_DEPENDENCIES_OVERRIDE', lockfiles, input))
     }
   }
 }
@@ -306,17 +301,21 @@ function writesWithBase(command, cwd) {
 
 function shellBoundary(input) {
   const allowed = writableRoots(input)
-  if (!allowed) return
   for (const { raw, base } of writesWithBase(commandOf(input), cwdOf(input))) {
     // Una ruta absoluta no depende del `cd`, así que un destino que no se sabe no la vuelve injuzgable.
     // Al revés sí: sin saber desde dónde se resuelve, una relativa no se puede verificar, y un guard que
     // no puede verificar no autoriza —el criterio que fijó el 031 para el índice—.
     if (!path.isAbsolute(raw) && base === null) {
+      if (!allowed) continue
       block(`el comando hace \`cd\` a un destino que no se puede resolver acá, así que no hay contra qué `
         + `resolver ${raw}. Escribí la ruta absoluta, o hacé el \`cd\` en un comando aparte.`)
     }
-    const file = path.resolve(base, raw)
-    if (NEUTRAL.some((pattern) => pattern.test(file))) continue
+    const file = path.resolve(base || '/', raw)
+    // El canal por el que la persona aprueba no es un destino más: se juzga aunque no haya raíces
+    // declaradas y aunque caiga en el temporal, que el resto de este guard deja pasar (caso 098).
+    const own = selfApproval(input, file)
+    if (own) block(own)
+    if (!allowed || NEUTRAL.some((pattern) => pattern.test(file))) continue
     if (outsideRoots(file, allowed)) {
       block(`el comando escribe en ${file}, fuera de las raíces declaradas en ops.config.json. ${DECLARE_IT}`)
     }
@@ -347,9 +346,9 @@ function governance(input) {
   // La aprobación vale para lo que nombra y para nada más: lo que quede sin cubrir es lo que se
   // reporta. Así una aprobación vieja no autoriza el archivo que se sumó después, que es la diferencia
   // entre una llave por operación y una puerta que quedó abierta.
-  const pendientes = AP.pending(opsRoot(input), governed)
+  const pendientes = AP.pending(opsRoot(input), governed, input)
   if (!pendientes.length) return
-  block(`El commit toca gobernanza protegida.\n${AP.HOW('OPS_GOVERNANCE_OVERRIDE', pendientes)}`)
+  block(`El commit toca gobernanza protegida.\n${AP.HOW('OPS_GOVERNANCE_OVERRIDE', pendientes, input)}`)
 }
 
 function run(program, args, cwd, extra = {}) {
@@ -488,20 +487,20 @@ function verify(input) {
   // Acá lo aprobado es el conjunto staged entero: decir «autorizo commitear exactamente estas rutas»
   // es lo que un gate en rojo necesita, y cambia en cuanto se stagea una más. La lista sale del índice
   // y no de una regla, que es lo que la vuelve una operación y no un permiso.
-  const sinAprobar = AP.pending(opsRoot(input), staged)
+  const sinAprobar = AP.pending(opsRoot(input), staged, input)
   const aprobado = !sinAprobar.length
   if (changedOpenApi && !hasApiGenerated && !aprobado) {
     block('Cambió una fuente OpenAPI/Swagger sin incluir código regenerado. Ejecuta el generador y '
-      + `stagea su salida.\n${AP.HOW('OPS_SKIP_VERIFY', sinAprobar)}`)
+      + `stagea su salida.\n${AP.HOW('OPS_SKIP_VERIFY', sinAprobar, input)}`)
   }
   if (changedSqlSource && !hasSqlGenerated && !aprobado) {
     block('Cambió una consulta SQL fuente sin artefactos regenerados. Ejecuta el generador.\n'
-      + AP.HOW('OPS_SKIP_VERIFY', sinAprobar))
+      + AP.HOW('OPS_SKIP_VERIFY', sinAprobar, input))
   }
   if (!staged.some((file) => /\.(?:ts|tsx|js|jsx|mjs|cjs|go|py|html|css|scss|prisma)$/.test(file))) return
   const { root, temp, env } = commitTree(dir)
   try {
-    verifyGates(root, dir, sinAprobar, env, opsRoot(input))
+    verifyGates(root, dir, sinAprobar, env, input)
   } finally {
     if (temp) fs.rmSync(temp, { recursive: true, force: true })
   }
@@ -522,11 +521,15 @@ function verify(input) {
 // Se muestra **una** línea y acotada: la salida de un gate puede traer cualquier cosa del entorno, y lo
 // que hace falta para diagnosticar es la primera línea de error, no el volcado.
 const ERROR_LINE = /error|err[_!]|fail|abort|not found|cannot|no such/i
-// Cómo marca un reporte de pruebas cada resultado: `node --test` en spec y en TAP, y `go test`. Van sólo
-// las comprobadas contra la herramienta (caso 094): el nombre de una prueba verde puede decir «error», y
-// sin mirar la marca la búsqueda por palabra se quedaba con ella y el mensaje escondía la roja.
-const FAILED_TEST = /^(?:✖|not ok\b|--- FAIL:)/
-const PASSED_TEST = /^(?:✔|ok\b|--- PASS:)/
+// Cómo marca un reporte de pruebas cada resultado. Van sólo las comprobadas contra la herramienta (caso
+// 094): el nombre de una prueba verde puede decir «error», y sin mirar la marca la búsqueda por palabra se
+// quedaba con ella y el mensaje escondía la roja. Comprobadas con la salida entubada, como la ve un gate:
+// `node --test` en spec y en TAP (Node 24.18.0), `go test` (go 1.26.3), jest 30.5.1 (`● nombre`, y
+// `● Test suite failed to run`), vitest 5.0.0 (`× nombre`), mocha 12.0.1 (`1) nombre`; la verde es `✔`) y
+// pytest 9.1.1 (`FAILED archivo::prueba` en el resumen; `::prueba PASSED` la verde con `-v`). Jest y vitest
+// no imprimen las verdes sin `--verbose`, así que de ellos no hay marca de éxito.
+const FAILED_TEST = /^(?:✖|not ok\b|--- FAIL:|● |× |\d+\) |FAILED )/
+const PASSED_TEST = /^(?:✔|ok\b|--- PASS:)|::\S+ PASSED\b/
 const MAX_LINE = 160
 function fallo(gate, result) {
   // La línea que empieza con `>` es el eco del script que npm y pnpm imprimen antes de correrlo, así
@@ -555,7 +558,8 @@ function comoSeLee(failures) {
     + 'una suite, así que mirá si llegaron a ejecutarse antes de aprobar esto como un rojo conocido.'
 }
 
-function verifyGates(root, dir, sinAprobar, env, ops) {
+function verifyGates(root, dir, sinAprobar, env, input) {
+  const ops = opsRoot(input)
   const failures = []
   if (fs.existsSync(path.join(root, 'package.json'))) {
     const pkg = JSON.parse(fs.readFileSync(path.join(root, 'package.json'), 'utf8'))
@@ -595,7 +599,7 @@ function verifyGates(root, dir, sinAprobar, env, ops) {
   const donde = root === dir ? '' : '\nCorrió sobre el índice, que es lo que el commit graba: si en tu '
     + 'directorio pasa, es que en disco tenés algo que no está staged.'
   block(`Verify falló en ${path.basename(dir)}: ${comoSeLee(failures)}\nNo se commitea en rojo.${donde}\n`
-    + AP.HOW('OPS_SKIP_VERIFY', sinAprobar))
+    + AP.HOW('OPS_SKIP_VERIFY', sinAprobar, input))
 }
 
 module.exports = { destructive, gitAdd, dependencies, governance, verify, shellBoundary, run }

package/package.json

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

package/template/AGENTS.md

@@ -103,9 +103,19 @@ Un guard existente **no se edita**: `upgrade` detecta el cambio y se detiene ant
 Algunos bloqueos tienen salida, y conviene saber cuál antes de necesitarla — el momento en que un guard
 te frena es el peor para elegir bien.
 
-**La salida de todos ellos es la misma**: escribir en `planning/.ops-approval` las rutas que autorizás,
-una por línea, con `#` para lo que no sea una ruta. Es un solo archivo para todos los guards, porque lo
-que escribís son rutas y quién las mira lo decide qué guard esté juzgando esa ruta.
+**Si lo pediste vos en el chat, no hace falta nada.** Los guards contienen al agente cuando decide solo o
+cuando trabaja dentro de un recorrido; lo que vos pedís directo no se frena. Nombrá lo que querés que
+toque —«borrá la prueba de altas», «reescribí la migración 004»— y pasa sin preguntarte de nuevo. Si tu
+pedido no lo nombraba y algo se frena, el agente te dice qué y por qué: contestá «dale» y pasa exactamente
+eso. Y `plan-first` no te pide un plan cuando el cambio lo pediste vos: el plan es para el trabajo que va
+por tareas. Funciona en Claude Code, Codex y Gemini, que le avisan a Cauce cuando mandás un mensaje; en
+Antigravity, y cuando nadie está en el chat —CI, un recorrido, un subagente—, queda el archivo de abajo.
+
+**Sin chat, la salida de todos ellos es la misma**: escribir en `planning/.ops-approval` las rutas que
+autorizás, una por línea, con `#` para lo que no sea una ruta. En sidecar es el `planning/` de la
+instancia y no una carpeta al lado de tus proyectos; el bloqueo dice la ruta exacta. Es un solo archivo
+para todos los guards, porque lo que escribís son rutas y quién las mira lo decide qué guard esté
+juzgando esa ruta. Lo escribís vos: si el agente intenta escribírselo, un guard lo frena.
 
 | lo que te frena | qué ruta aprobás |
 |---|---|