@ingeniomaps/cauce 0.80.0 → 0.82.0

package/CHANGELOG.md

@@ -14,6 +14,183 @@ 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.82.0] - 2026-09-11
+
+### Cambiado
+
+- **`allowPush: true` ya no publica en la rama viva ni desde un subagente.** La llave dejaba pasar cualquier
+  push, `main` incluido, y el de un subagente igual que el tuyo. Ahora no alcanza a `main`, `master` ni a la
+  rama por defecto del remoto, y un subagente no publica con ningún permiso. Tampoco la alcanza una orden en
+  el chat.
+
+  **Qué cambia para vos**: si publicabas en la rama viva con `allowPush: true`, agregá
+  `"pushToLiveBranches": ["main"]` en `runner` de `ops.config.json`, o pegá `push origin main` en
+  `planning/.ops-approval` para un push puntual.
+
+- **R10 y el párrafo de publicación de `AGENTS.md` se reescribieron.** Los dos decían que el push se
+  comprueba contra `runner.allowPush` y nada más; ahora dicen lo que de verdad comprueba el motor: esa llave
+  —que no llega a la rama viva sin `runner.pushToLiveBranches`, ni a un subagente— o la orden que la persona
+  da en el chat nombrando el remoto y la rama. Los dos archivos los mantiene Cauce, así que `upgrade` los
+  reemplaza enteros.
+
+  **Qué cambia para vos**: nada que hacer. Si tu equipo cita R10 en algún documento propio, el texto que
+  baja ahora es más largo y dice qué sostiene un guard y qué sostiene una persona.
+
+### Corregido
+
+- **Nombrar algo en el chat ya no lo autoriza: hay que pedirlo.** Desde 0.81.0, lo que nombrabas en el chat
+  pasaba los guards aunque no lo pidieras: «¿para qué sirven las credentials?» dejaba leer `credentials`, y
+  «el .env tiene algo raro?» dejaba leer el `.env`. Ahora la frase que lo nombra tiene que pedir una acción
+  —«leé», «abrime», «borrá», «read»…—, y la negación sigue frenando como antes.
+
+  **Qué cambia para vos**: si pedís algo sin un verbo que Cauce reconozca, el agente te dice qué se frenó y
+  con un «dale» pasa.
+
+- **`upgrade` ya no pisa un guard tuyo que se llama como uno nuevo del paquete.** Cuando una versión empezaba
+  a traer un nombre que ya usabas en `automatization/hooks/`, lo reemplazaba sin decir nada: 0.81.0 lo hizo
+  con `guard-chat.sh`. Ahora lo conserva y lo avisa; `--check` lo cuenta, y `--force` lo reemplaza diciéndolo.
+
+  **Qué cambia para vos**: si ves «ya existía y Cauce no lo entregó», renombrá tu guard y repetí `upgrade`;
+  mientras tanto, el guard del paquete con ese nombre no está instalado.
+
+- **Un guard propio ya no aparece como «editado localmente».** `upgrade` registraba todo lo que había en
+  `automatization/hooks/`, así que editar un guard tuyo lo volvía una edición del molde: `upgrade --check`
+  salía con 1, `check` lo contaba como congelado, y `--force` anunciaba que lo descartaba sin tocarlo. Ahora
+  sólo registra lo que trae el paquete, y el primer `upgrade` suelta lo que una versión anterior registró de
+  más.
+
+  **Qué cambia para vos**: nada que hacer; tus guards dejan de aparecer en esos avisos.
+
+- **El aviso de credenciales sin dueño avisa sólo credenciales.** `check` listaba toda variable que el
+  proyecto declaraba y ningún contrato nombraba: en un proyecto real fueron ciento ocho nombres de build, y
+  la única credencial quedó en «y 1 más». Ahora cuenta las que tienen nombre de secreto —`…_PASSWORD`,
+  `…_TOKEN`, `…_KEY`, `…_DSN`…—, dice en qué servicio está cada una y dónde se escribe su dueño, y avisa
+  aparte cuando un servicio pasó el tope de variables que se revisan.
+
+  **Qué cambia para vos**: la declaración de secretos y la configuración de una integración ahora también
+  rechazan una clave que termine en `_key`, `dsn` o `credentials`, igual que ya rechazaban `…token`. Si
+  tenés una, cambiala por la referencia a una variable de entorno. Y una credencial con nombre de
+  configuración —`STRIPE_LIVE`— no aparece en el aviso: el criterio es el nombre.
+
+- **Una variable ya no se da por cargada porque otra la contiene en su nombre.** Con `API_SECRET_ROTATION`
+  escrita en `organization/workspace.md`, `API_SECRET` dejaba de avisarse aunque nadie la nombrara. Ahora
+  cuenta sólo el nombre entero.
+
+  **Qué cambia para vos**: puede aparecer en el aviso una credencial que antes quedaba tapada; escribí su
+  dueño y se va.
+
+- **Un push que pedís en el chat ya no se frena.** Con `allowPush: false`, `git push` se frenaba aunque lo
+  hubieras pedido con todas las letras. Ahora pasa si tu mensaje nombra el remoto y la rama —«subí feat/x a
+  origin», `git push origin feat/x`—, y si no los nombra, el agente te dice qué se frenó y con un «dale»
+  pasa ese push y ningún otro. `planning/.ops-approval` también acepta la línea `push <remoto> <rama>`, tal
+  cual y sin patrones. Un `git push origin +rama` ahora se frena como el `--force` que es.
+
+  **Qué cambia para vos**: para publicar una rama de trabajo alcanza con pedirlo nombrando remoto y rama, o
+  con contestar «dale».
+
+- **La sesión carga las reglas que rigen tu proyecto, no las cuatro de `system/` fijas.** El archivo de
+  instrucciones de cada runner importaba siempre `planning/rules/system/`: cargaba la regla que tu proyecto
+  había sobrescrito y ninguna de las tuyas. Ahora `automation install` pone las vigentes —las tuyas y las de
+  `system/` que no sobrescribiste— en Claude, Gemini, Codex y Antigravity, y un `CLAUDE.md` que editaste
+  recibe el bloque nuevo sin perder lo tuyo. Como `upgrade` no reinstala, `check` y `automation doctor`
+  avisan cuando lo instalado quedó atrás. `AGENTS.md` dice ahora que, donde una regla tuya y una del
+  sistema chocan, rige la tuya.
+
+  **Qué cambia para vos**: después de actualizar, o cada vez que escribas o sobrescribas una regla,
+  reinstalá el adaptador (`make install-claude`, o el de tu runner); `check` te dice cuándo hace falta. Si
+  tu `CLAUDE.md` es tuyo y no tiene nada de Cauce, poné las marcas `<!-- cauce:reglas inicio -->` y
+  `<!-- cauce:reglas fin -->` donde quieras el bloque y reinstalá.
+
+- **`autobuild` trabaja con las reglas de tu proyecto y ya no cita una que retiraste.** Los subagentes
+  planificaban, construían y revisaban sin conocer tus reglas, y la fila que pedía partir una tarea citaba
+  R17 aunque la hubieras retirado. Ahora `context` dice qué reglas rigen —línea `RULES`, campo `rules` en
+  `--json`—, cada fase recibe esa lista, y Review tiene que nombrar contra cuáles revisó o la corrida para
+  con `review-unbacked`. Ningún prompt cita una regla por número.
+
+  **Qué cambia para vos**: nada que hacer.
+
+- **Los recorridos ya no llenan el INBOX sin medida.** `autobuild` volcaba en Propuestas todo lo que Review
+  anotaba sin frenar, entero, y `flow` y `onboard` escribían sin tope ni forma. Ahora cada recorrido escribe
+  como mucho tres entradas por tarea o por corrida, de una línea, con la forma del molde y sin repetir un
+  nombre que ya está. Lo que pasa del tope no se pierde: `autobuild` lo cuenta en el `done/` de la tarea,
+  `flow` lo deja en el informe y `onboard` lo nombra al cerrar. Y `check` avisa, sin fallar, cuando
+  `INBOX.md` pasa de 300 líneas.
+
+  **Qué cambia para vos**: nada que hacer. Si querés otro umbral para el aviso, poné
+  `"inbox": { "warnLines": N }` en `ops.config.json`. El molde de `INBOX.md` ya no pide la evidencia dentro
+  de una propuesta; tu `INBOX.md` no se toca.
+
+- **La recurrencia que recorre el INBOX viene activa, y descomentar los ejemplos de `RECURRING.md` ya no
+  rompe `check`.** Una instancia nueva trae la fila `inbox`, trimestral, que vence por primera vez tres meses
+  después de `init`. Las filas de ejemplo declaran el `(service: …)` que `check` exige. Y `check` avisa una
+  entrada del INBOX que se llama como una tarea de `done/`: probablemente se promovió y quedó ahí.
+
+  **Qué cambia para vos**: `RECURRING.md` es tuyo y `upgrade` no lo toca. Para tener la recurrencia en una
+  instancia que ya existe, agregá debajo de la tabla
+  `| inbox | trimestral | AAAA-MM-DD | Recorrer el INBOX entero. _Aceptación: ninguna viñeta queda sin decisión de promover, dejar o borrar._ (service: planning) |`
+  con una fecha futura: `Desde` es cuándo vence por primera vez, no el día en que escribís la fila.
+
+- **Dos repositorios que terminan en una carpeta con el mismo nombre ya no salen con el mismo nombre.** Con
+  varias raíces declaradas, el inventario nombraba cada servicio por la **carpeta** de su raíz, así que
+  `../gouduet/keycloak` y `../hypixo/keycloak` salían los dos `keycloak` en `check`, en `onboard` y en
+  `scan`, y no había con qué saber de qué repositorio era cada credencial. Ahora los nombra el `name` que
+  cada raíz declara en `ops.config.json`, y `check` avisa cuando dos raíces se llaman igual, diciendo
+  cuáles son las dos.
+
+  **Qué cambia para vos**: si dos raíces de tu `ops.config.json` comparten `name`, `check` te lo avisa y
+  sigue pasando —renombrá una cuando puedas—. Y donde el `name` y la carpeta difieren, los servicios pasan
+  a listarse con el `name` —el que escribiste vos— en vez de con la carpeta; `onboard --json` sigue
+  emitiendo `roots` como lista de rutas.
+
+## [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 **pidió nombrándolo** pasa: «leé el `.env`» autoriza leer el `.env`; «no toques el
+  `.env`» no, y tampoco una pregunta o un comentario que sólo lo nombra —«¿qué tiene el `.env`?»—;
+- 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/antigravity/rules/cauce.md

@@ -1,7 +1,12 @@
 # Cauce
 
-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/<runner>.md` es el mutex de
+Lee y cumple `{{OPS_DIR}}AGENTS.md`, `{{OPS_DIR}}planning/PROTOCOL.md` y las reglas que rigen este proyecto
+antes de ejecutar trabajo: las propias y las de `system/` que el proyecto no sobrescribió. Donde una propia
+contradice a una del sistema, rige la propia.
+
+{{RULES:list}}
+
+`{{OPS_DIR}}planning/wip/<runner>.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
 evidencia en DONE.

package/automatization/runners/claude/CLAUDE.md

@@ -2,10 +2,7 @@
 
 @{{OPS_DIR}}AGENTS.md
 @{{OPS_DIR}}planning/PROTOCOL.md
-@{{OPS_DIR}}planning/rules/system/process.md
-@{{OPS_DIR}}planning/rules/system/code-shape.md
-@{{OPS_DIR}}planning/rules/system/commits.md
-@{{OPS_DIR}}planning/rules/system/conduct.md
+{{RULES:imports}}
 
 Los hooks de `.claude/settings.json` son obligatorios. En una instancia recién creada, empezá corriendo
 `node {{OPS_DIR}}tools/ops.js onboard`: es instantáneo, y lo primero que imprime es la pregunta con la que

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/AGENTS.md

@@ -1,8 +1,12 @@
 # Cauce para Codex
 
-`{{OPS_DIR}}AGENTS.md` tiene las reglas del sistema, `{{OPS_DIR}}planning/PROTOCOL.md` es la fuente de
-verdad del proceso y `{{OPS_DIR}}planning/rules/system/` son las reglas que rigen cada tarea. Leelos
-antes de trabajar —los tres, no cuando algo sale mal—: acá sólo está lo específico de este runner.
+`{{OPS_DIR}}AGENTS.md` tiene las reglas del sistema y `{{OPS_DIR}}planning/PROTOCOL.md` es la fuente de
+verdad del proceso. Las reglas que rigen cada tarea en este proyecto son éstas —las propias y las de
+`system/` que el proyecto no sobrescribió—, y donde una propia contradice a una del sistema, rige la propia:
+
+{{RULES:list}}
+
+Leé todo eso antes de trabajar, no cuando algo sale mal: acá sólo está lo específico de este runner.
 
 > 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.

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/GEMINI.md

@@ -2,10 +2,7 @@
 
 @{{OPS_DIR}}AGENTS.md
 @{{OPS_DIR}}planning/PROTOCOL.md
-@{{OPS_DIR}}planning/rules/system/process.md
-@{{OPS_DIR}}planning/rules/system/code-shape.md
-@{{OPS_DIR}}planning/rules/system/commits.md
-@{{OPS_DIR}}planning/rules/system/conduct.md
+{{RULES:imports}}
 
 `{{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/<runner>.md` es el mutex

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/automatization/shared/inbox.js

@@ -0,0 +1,28 @@
+// Lo que un recorrido le pide a un agente cuando escribe en el INBOX (caso 101). El tope lo aplica el
+// recorrido sobre lo que le pasa al agente, no el agente: pedirle que se limite no es un tope. Lo que no
+// entra se cuenta donde cada recorrido lo deja, y ninguno lo tira en silencio.
+const INBOX_CAP = 3
+// La forma de una entrada, igual a la que declara el molde de `INBOX.md`: quien escribe no tiene que
+// abrir el archivo para saberla. Una prueba ata las dos.
+const INBOX_ENTRY = '- **slug-del-item** — Qué es, y qué se decide o se resuelve con esto.'
+// Los nombres que ya hay, por sección, tal como los imprime `ops context --json` en su campo inbox.
+const INBOX_HEADS = { type: 'object', additionalProperties: false, properties: Object.fromEntries(
+  ['deuda', 'ideas', 'propuestas', 'lecciones'].map((key) => [key, { type: 'array', items: { type: 'string' } }]),
+) }
+// Una entrada es una línea. Un hallazgo de largo libre se recorta antes de llegar a quien lo escribe,
+// porque lo que llega entero es lo que termina copiado entero.
+const oneLine = (text) => {
+  const first = String(text || '').split('\n')[0].trim()
+  return first.length > 240 ? `${first.slice(0, 239)}…` : first
+}
+// La forma y los nombres que ya hay en las secciones donde se va a escribir. Van los nombres y no el
+// archivo: con ellos alcanza para no repetir una entrada, y el archivo entero pesaría lo que el INBOX.
+function inboxAsk(sections, heads) {
+  const known = sections.map((name) => {
+    const names = (heads || {})[name.toLowerCase()] || []
+    return names.length ? `en ${name} ya están ${names.join(', ')}` : `${name} no tiene entradas`
+  }).join('; ')
+  return `Cada entrada con la forma del molde —${INBOX_ENTRY}—: un nombre y una línea, y la evidencia se ` +
+    `cita donde ya vive, no se copia. Por nombre, ${known}: lo que ya esté con uno de esos nombres no se ` +
+    `vuelve a escribir.`
+}

package/automatization/workflows/agent-eval.js

@@ -225,7 +225,7 @@ const verdicts = await pipeline(
     `normas o sistemas de terceros. Enumeralas con el registro que cada una lleva —verificado, ` +
     `documentado, hipótesis, o ninguno— y comprobá las que se puedan comprobar barato: abrí el archivo ` +
     `que cita y leé si dice eso, reproducí la invocación inocua que declara (\`--help\`, \`--version\`, ` +
-    `un comando de sólo lectura), consultá la fuente pública que nombra. Llegá hasta donde R12 permite: ` +
+    `un comando de sólo lectura), consultá la fuente pública que nombra. Sin salirte de la lectura: ` +
     `nunca conectarte a un sistema real ni ejecutar la operación cuyo efecto se describe.\n\n` +
     `Empezá por la afirmación de la que depende la recomendación del cargo, no por la que parezca más ` +
     `discutible: son distintas, y la segunda suele estar bien rotulada porque el cargo esperaba que se la ` +