@ingeniomaps/cauce 0.81.0 → 0.83.0

package/CHANGELOG.md

@@ -14,6 +14,254 @@ 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.83.0] - 2026-09-11
+
+### Agregado
+
+- **Autorizar en el chat ahora se dice como se dice.** Un guard dejaba pasar lo que pedías con un verbo de
+  acción —«leé el .env», «usá esa ruta»— y se seguía frenando si lo decías autorizando: «autorizo la
+  lectura del .env» no traía ninguna palabra que Cauce reconociera, así que había que repetirlo con otras
+  palabras, contestar «dale», o escribir la línea a mano. Entran las formas con que una persona concede, en
+  español y en inglés: `autorizo`, `autorizá`, `te autorizo`, `permito`, `apruebo`, `habilito`,
+  `authorize`, `allow`, `grant`, `approved`.
+
+  Lo que **no** cambia es la línea de siempre: nombrar algo no lo autoriza. Los sustantivos que nombran el
+  acto —«la lectura del .env», «¿hace falta autorizacion?»— siguen sin autorizar nada, porque aparecen
+  igual en una pregunta que no pide nada. Y negar sigue negando, también con las palabras nuevas.
+
+  **Qué cambia para vos**: si autorizás algo diciendo que lo autorizás, pasa a la primera. Antes eso
+  costaba una vuelta, y a veces terminaba en la variable que apaga el guard para toda la sesión.
+
+- **El permiso de push ya no se lo puede escribir el agente.** `runner.allowPush` y
+  `runner.pushToLiveBranches` deciden qué push se publica y viven en `ops.config.json`, que hasta ahora
+  ningún guard miraba: el bloqueo que dice «esto lo decide una persona» se levantaba editando ese mismo
+  archivo, con la herramienta de escritura o con un `sed -i`. Lo cierran dos guards nuevos: `ops-config`
+  compara lo que se va a escribir contra lo que hay en disco y frena si cambia alguna de esas dos llaves,
+  y `ops-config-shell` frena toda escritura por shell sobre el archivo, porque un comando no dice con qué
+  va a quedar.
+
+  **Qué cambia para vos**: el resto de `ops.config.json` —`workspaceRoots`, `writableOutsideRoots`,
+  `migrations`, lo que sea— se sigue editando igual que siempre; sólo esas dos llaves pasan a necesitar una
+  persona, que las pone editando el archivo ella o pidiéndoselo al agente en el chat nombrando
+  `ops.config.json`. Por shell el archivo queda cerrado entero: ese cambio va por la herramienta de
+  escritura y con el archivo completo, que es lo único que el guard puede comparar. Si tu runner registra
+  los guards de a uno en vez de por grupo, corré `automation install` para que aparezcan
+  `guard-ops-config.sh` y `guard-ops-config-shell.sh`.
+
+- **Un push aprobado deja constancia en `planning/.push-log`.** Cuando Cauce deja pasar un `git push` por
+  una aprobación —la orden en el chat, un «dale», o la línea exacta en `planning/.ops-approval`— anexa una
+  línea con la fecha en que se autorizó, el remoto, la rama, por qué vía y la sesión. Por
+  `runner.allowPush` no anota nada: esa autorización ya está escrita en `ops.config.json`.
+
+  El archivo sólo agrega, no guarda el texto de lo que escribiste, y si no se puede escribir no frena el
+  push. La fecha se llama `authorizedAt` y no `at` a propósito: el hook corre antes del comando, así que la
+  línea dice que el push **se autorizó**, no que se haya publicado.
+
+  El anillo «Local» de `planning/delivery/teamwork.md` lo nombra junto al resto de lo que no viaja por git.
+  Ese archivo lo mantiene Cauce, así que `upgrade` te lo reemplaza: si lo editaste, mirá el diff antes.
+
+  **Qué cambia para vos**: si necesitás responder quién autorizó un push y cuándo, ahora hay de dónde
+  sacarlo, en la máquina donde corrió la sesión —el rastro dice la sesión y la vía, no el nombre de la
+  persona: Cauce no tiene identidad de usuario—. Las instancias nuevas lo traen gitignoreado; si ya tenés
+  una, agregá `planning/.push-log` a tu `.gitignore`.
+
+- **Lo que un recorrido deja en el INBOX dice ahora de qué vía entró.** Cada línea que `autobuild`, `flow` y
+  `onboard` le pasan al agente que escribe viene con su procedencia al final —`(autobuild · t-012 ·
+  2026-09-11)`, `(flow · planning/reports/2026-09-11-alta.md · 2026-09-11)`, `(onboard · 2026-09-11)`—: el
+  recorrido, la unidad de la que salió y la fecha. La arma el recorrido y el pedido dice que se copie tal
+  cual, en vez de confiar en que el agente se acuerde de escribirla. El formato de una entrada no cambió ni
+  el molde tampoco, así que `ops tree`, `check` y `context --json` siguen leyendo exactamente lo mismo.
+
+  **Qué cambia para vos**: nada que hacer. Al recorrer el INBOX vas a ver el origen en lo que se escriba de
+  acá en adelante; lo que ya tenés escrito no lo gana, y una entrada que escribas a mano sigue sin él,
+  porque el INBOX es tuyo. Si en algún lado recortás el ancho de esas líneas, contá entre 20 y 60
+  caracteres más por entrada: el tope de 240 pasó a medir la línea entera, así que lo que cede es el texto
+  del hallazgo y nunca el origen.
+
+### Cambiado
+
+- **Lo que autorizás en el chat no alcanza a los gates de un commit.** Lo que un guard deja pasar porque
+  vos lo pediste sigue valiendo mientras dure la sesión, con dos excepciones: publicar, y los gates de un
+  commit —`governance`, `verify` y `dependencies`—, que preguntan cada vez. Lo que autoriza un commit no
+  dice nada del siguiente, porque el índice ya es otro. Por el mismo motivo, nombrar `ops.config.json` una
+  vez ya no deja escribir `runner.allowPush` ni `runner.pushToLiveBranches` por el resto de la sesión: ahí
+  también se pregunta cada vez.
+
+  **Qué cambia para vos**: si commiteás varias veces seguidas tocando gobernanza, con un gate en rojo o con
+  un manifiesto sin su lockfile, vas a decir «dale» en cada commit en vez de una vez por sesión. Lo que no
+  es un gate de commit —leer un `.env`, reescribir una migración, borrar una prueba— sigue valiendo toda la
+  sesión.
+
+### Corregido
+
+- **Un bloqueo ya no te ofrece pegar una ruta que el shell no expandió.** Cuando el comando nombra la
+  credencial a través de una variable —`cat ops/$O/.env.infisical`—, Cauce no puede saber qué archivo es:
+  esa variable la expande tu shell, que es otro proceso. Antes el bloqueo ofrecía igual esa línea para
+  `planning/.ops-approval`, y pegarla no servía: sólo volvía a valer si el comando se repetía escrito
+  igual, y dejaba de valer apenas alguien escribía la ruta de verdad. Con la forma `${O}` era peor, porque
+  la línea ofrecida ni siquiera era el archivo que el comando lee. Ahora no la ofrece, dice por qué y qué
+  hacer.
+
+  **Qué cambia para vos**: lo que un bloqueo te ofrece pegar es siempre una línea que después funciona. Si
+  armás la ruta con variables, escribila entera en ese comando —o contestá «dale», que destraba igual—.
+
+- **Lo que autorizás en el chat ya no deja de valer con el mensaje siguiente.** Hasta 0.82.0 el permiso
+  duraba un mensaje: pedías leer el `.env`, el agente lo leía, y apenas escribías cualquier otra cosa
+  —«gracias, seguí»— el mismo archivo volvía a frenarse. Ahora lo que un guard deja pasar porque vos lo
+  pediste queda anotado y sigue valiendo mientras la sesión siga. Lo revoca decirlo: «no toques el .env» lo
+  saca, y lo revocado no vuelve solo.
+
+  El permiso sigue siendo angosto: vale para el ítem tal como el guard lo nombra, no cruza de sesión y no
+  alcanza a un subagente ni a un recorrido de Cauce. Y **no alcanza a lo que vuelve a tener consecuencia
+  cada vez**: publicar y los gates de un commit, que preguntan siempre —ver la entrada de abajo—. Volver a
+  leer lo que ya se leyó no agrega consecuencia; volver a publicar, o commitear otra vez con otro índice,
+  sí.
+
+  **Qué cambia para vos**: si trabajás con credenciales o con rutas que los guards vigilan, alcanza con
+  pedirlo una vez por sesión en lugar de repetir la frase o contestar «dale» a cada rato. Si querés cortar
+  un permiso antes de cerrar la sesión, decilo nombrando el archivo.
+
+- **El agente no puede escribir en tu aprobación una línea que vos no pediste.** `planning/.ops-approval`
+  sólo lo podía escribir el agente si vos nombrabas el archivo en el chat, y ahí se terminaba el control:
+  pedías agregar `src/login.js` y podía escribir `push origin main`, que es la línea que autoriza publicar
+  en la rama viva. Ahora lo que se escribe se compara línea por línea con lo que pediste: pasan las que
+  nombraste, y cualquier otra frena la escritura mostrándote cuál era. Las que ya estaban en el archivo no
+  hay que volver a nombrarlas, y quitar líneas no pide permiso. Por shell —un `echo >>`, un `sed -i`— el
+  archivo queda cerrado: un comando no dice con qué va a quedar, así que no hay contenido que comparar.
+
+  **Qué cambia para vos**: si le pedís al agente que te agregue rutas, nombralas en el mismo mensaje
+  —«agregá `src/login.js` y `src/altas.js` a `.ops-approval`»—; si frena, te dice exactamente qué línea
+  quería escribir y un «dale» aprueba esa y nada más. Vos seguís editando el archivo a mano como siempre,
+  que ningún guard mira. Esto venía desde 0.82.0, así que si actualizás desde ahí, cerrás de paso esa vía.
+
+## [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

package/automatization/hooks/README.md

@@ -72,18 +72,22 @@ pidió con todas las letras y lo que el agente decidió solo. `chat` corre sobre
 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 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;
+- lo que un guard dejó pasar porque ella lo pidió sigue valiendo mientras dure la sesión, **salvo en los
+  gates de un commit** —`governance`, `verify` y `dependencies`—, que preguntan cada vez: ahí vale lo que
+  pidió el mensaje en curso o un «dale», igual que para publicar;
 - `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.
+sesión, y los guards de límites lo cuidan junto con `planning/.ops-approval`: el registro no lo escribe
+nunca una herramienta, y en la aprobación sólo entran las líneas que la persona nombró en ese mismo
+mensaje —por shell, ninguna: un comando no dice con qué va a quedar el archivo—. Como todo lo de esta página, frena la forma habitual y no un script decidido.
 
 ## Cómo se ejecutan
 
@@ -108,8 +112,8 @@ 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, shell-boundary | `guard-shell.sh` |
-| `pre-files` | secrets, generated, workspace-boundary, engine, migrations, integration-snapshot, test-evidence, plan-first | `guard-files.sh` |
+| `pre-shell` | destructive, git-add, dependencies, governance, verify, shell-boundary, secrets-shell, ops-config-shell | `guard-shell.sh` |
+| `pre-files` | secrets, generated, workspace-boundary, engine, migrations, integration-snapshot, test-evidence, plan-first, ops-config | `guard-files.sh` |
 | `pre-read` | secrets-read | `guard-secrets-read.sh` |
 | `prompt` | chat | `guard-chat.sh` |
 | `stop` | planning-drift | `guard-planning-drift.sh` |

package/automatization/hooks/guard-ops-config-shell.sh

@@ -0,0 +1,3 @@
+#!/usr/bin/env bash
+# Shim: delega `ops-config-shell` en run-hook.sh; el registro de engine/hooks/run.js nombra su módulo.
+exec "$(dirname "$0")/run-hook.sh" ops-config-shell

package/automatization/hooks/guard-ops-config.sh

@@ -0,0 +1,3 @@
+#!/usr/bin/env bash
+# Shim: delega `ops-config` en run-hook.sh; el registro de engine/hooks/run.js nombra su módulo.
+exec "$(dirname "$0")/run-hook.sh" ops-config

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

@@ -0,0 +1,47 @@
+// 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' } }]),
+) }
+// Lo que entra en una entrada, procedencia incluida. El tope es del conjunto y no del detalle: así un
+// sufijo largo recorta lo que se cuenta y nunca al revés. Se recorta el detalle porque es lo único
+// recuperable —sigue entero en el informe o en `done/`—, y la procedencia no se reconstruye después.
+const INBOX_LINE = 240
+// 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, reserved = 0) => {
+  const first = String(text || '').split('\n')[0].trim()
+  const cap = INBOX_LINE - reserved
+  return first.length > cap ? `${first.slice(0, cap - 1)}…` : first
+}
+// De qué vía salió una entrada: el recorrido, la unidad de la que salió —una tarea, un informe, un
+// equipo— y la fecha. La arma el recorrido, que es el que las sabe, en vez de pedírselas al agente que
+// escribe: una convención que depende de que alguien se acuerde no deja rastro cuando no se cumple, y
+// una entrada sin remitente se lee igual que una que nunca lo tuvo (caso 115).
+//
+// Las partes vacías se caen: `onboard` no tiene ni tarea ni informe, y la fecha la da el motor —acá no
+// hay reloj—, así que falta si el comando que la trae no contestó. Va entre paréntesis, al final y en
+// minúscula, porque compite con lo que la entrada dice; y nombra al recorrido y nunca a un cargo, para
+// que no se lea como una firma con la que decidir sin leer la entrada.
+const inboxOrigin = (...parts) => `(${parts.filter(Boolean).join(' · ')})`
+// La entrada ya armada, para que quien escribe la copie en vez de redactarla.
+const withOrigin = (detail, origin) => `${oneLine(detail, origin.length + 1)} ${origin}`
+// 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, origin) {
+  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. Cada línea que te paso termina con su procedencia —${origin}—: va al ` +
+    `final de la entrada tal cual, sin reescribirla, resumirla ni completarla. ` +
+    `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 ` +

package/automatization/workflows/autobuild.js

@@ -27,6 +27,7 @@ export const meta = {
 }
 
 {{INCLUDE:shared/workflow-root.js}}
+{{INCLUDE:shared/inbox.js}}
 const CONFIG = `${ROOT}/ops.config.json`
 const P = `${ROOT}/planning`
 const ORG = `${ROOT}/organization`
@@ -82,6 +83,10 @@ const CONTEXT = {
     // Dónde va el plan de este runner. El nombre sale de su id y el recorrido no lo deriva: lo
     // pregunta, igual que la fecha.
     wipFile: { type: 'string' },
+    // Con los nombres que ya hay en el INBOX, Review no vuelve a anotar uno.
+    inbox: { ...INBOX_HEADS },
+    // Las reglas que rigen el proyecto, con los overrides ya resueltos por el motor (caso 105).
+    rules: { type: 'array', items: { type: 'string' } },
   },
 }
 const CLAIM = {
@@ -132,6 +137,10 @@ const DECISION = {
     consulted: { type: 'array', items: { type: 'string' } },
   },
 }
+// Review nombra contra qué reglas revisó (caso 105): recibir las rutas no garantiza abrirlas, y esto es lo único
+// que deja rastro de que se hizo. Critique no lo lleva porque no recibe la lista.
+const REVIEWED = { ...DECISION, required: [...DECISION.required, 'rules'],
+  properties: { ...DECISION.properties, rules: { type: 'array', items: { type: 'string' } } } }
 // Un exit code dice que el test corrió, no que pruebe lo que la tarea prometió: un test que asercia de
 // menos —o que ni existe— sale verde igual, y el guard de verify tampoco lo ve porque también mira exit
 // codes. Por eso `uncovered` se contrasta contra la aceptación leyendo el fuente, no la salida (R9).
@@ -274,6 +283,8 @@ const VERDICT = ' Cerrá con verdict=aprobado si no queda nada por corregir ante
   'si algo no se resuelve acá —el diseño no lo cubre, falta una decisión ajena, o la corrección excede el ' +
   'alcance—. Marcá blocking=true sólo en el hallazgo que impide entregar: el resto queda registrado y no ' +
   'manda a tocar código.'
+// Acompaña a todo prompt con schema REVIEWED.
+const RULED = ' En rules nombrá, por su ruta, cada una de las reglas que rigen contra la que revisaste el diff.'
 // Lo que hay que corregir antes de entregar. El resto de los hallazgos no desaparece: se registra.
 const blockers = (verdict) => verdict.concerns.filter((one) => one.blocking).map((one) => one.detail)
 // Atajo para reconocer un gate que corrió pruebas sin preguntarle a nadie. No alcanza solo y no
@@ -331,12 +342,19 @@ if (!contract.rootOk) {
 
 const bounds = contract.boundaries || []
 const limits = bounds.length ? ` Límites del proyecto: ${bounds.join('; ')}.` : ''
+// Las reglas que rigen el proyecto (caso 105). Las lista `context`, que se lee después del contrato, así que
+// entran al preámbulo cuando esa lectura vuelve. Viajan las rutas y no el texto: el preámbulo se reenvía a cada
+// subagente que toca código, y el texto de las reglas multiplicaría su tamaño por cada uno.
+let governing = []
 // Alcance de escritura: para subagentes que tocan código o ejecutan gates del producto.
-const SCOPE = `${BASE}\n\nProyecto ${contract.project}. workspaceRoots es el límite completo de escritura del ` +
-  `producto: ${contract.workspaceRoots.join('; ')}.${limits} Este preámbulo ya trae el contrato; no vuelvas a leer ` +
-  `${ROOT}/AGENTS.md, ${ORG}/workspace.md, ${CONFIG} ni ${P}/PROTOCOL.md.`
+const SCOPE = () => `${BASE}\n\nProyecto ${contract.project}. workspaceRoots es el límite completo de escritura ` +
+  `del producto: ${contract.workspaceRoots.join('; ')}.${limits} Este preámbulo ya trae el contrato; ` +
+  `no vuelvas a leer ${ROOT}/AGENTS.md, ${ORG}/workspace.md, ${CONFIG} ni ${P}/PROTOCOL.md.` +
+  (governing.length ? ` Las reglas que rigen este proyecto son éstas, relativas a ${ROOT}: ${governing.join(', ')}. ` +
+    'Leé las que toquen tu fase antes de planificar, construir o revisar; donde una propia contradice a una del ' +
+    'sistema, rige la propia.' : '')
 // Formatos de planning: sólo para subagentes que escriben roadmap, BACKLOG, WIP, DONE o gates.
-const LEDGER = `${SCOPE}\n\nContratos de planning, textuales de ${P}/PROTOCOL.md:\n${contract.contracts}`
+const LEDGER = () => `${SCOPE()}\n\nContratos de planning, textuales de ${P}/PROTOCOL.md:\n${contract.contracts}`
 
 // Un subagente puede morir —error terminal tras reintentos, o alguien que lo saltea— y entonces el
 // runtime devuelve `null`. Sin comprobarlo, la primera propiedad que se le pide revienta el recorrido
@@ -352,8 +370,8 @@ const LEDGER = `${SCOPE}\n\nContratos de planning, textuales de ${P}/PROTOCOL.md
 // justo la distinción que hace falta. Lo que evita el olvido es el arnés, que rechaza la llamada sin
 // etiqueta en las cuatro suites del recorrido.
 const read = (prompt, options = {}) => agent(`${BASE}\n\n${prompt}`, options)
-const run = (prompt, options = {}) => agent(`${SCOPE}\n\n${prompt}`, options)
-const write = (prompt, options = {}) => agent(`${LEDGER}\n\n${prompt}`, options)
+const run = (prompt, options = {}) => agent(`${SCOPE()}\n\n${prompt}`, options)
+const write = (prompt, options = {}) => agent(`${LEDGER()}\n\n${prompt}`, options)
 
 // Las tres paradas que dejan una fila en HUMAN_ACTIONS delegan esa escritura a un agente, y esa fila es
 // el único rastro de la parada: sin ella el recorrido informa un estado que el disco no tiene. Por eso
@@ -368,10 +386,11 @@ const registerHuman = async (prompt, label) => (await write(prompt, { label })
 const readContext = () => read(
   `Corré "node tools/ops.js context ${P} --json" desde ${ROOT} y reportá sólo lo que imprimió. Derivá hasTask ` +
   `de si task es null, wipActive de si wip es null, claimed del campo claimed, today y wipFile de sus ` +
-  `campos, y lane ` +
+  `campos, rules del campo rules tal cual, y lane ` +
   `de task.tier; copiá slug, ` +
   `hito, service, acceptance, ` +
-  `epic y cast de task, y epicContext de epic.context —vacío si no hay épica—. El comando es la fuente de ` +
+  `epic y cast de task, epicContext de epic.context —vacío si no hay épica— e inbox tal cual. El comando es ` +
+  `la fuente de ` +
   `verdad: no abras archivos de planning para completarlo. Poné readOk en true sólo si el comando salió ` +
   `con código 0 y devolvió JSON; si falló, readOk en false y el resto en sus valores vacíos, sin ` +
   `deducir el estado de ninguna otra fuente.`,
@@ -405,6 +424,7 @@ if (blocker === 'blocked-on-human') {
 }
 if (blocker) return stop('context-unavailable', `${P} contestó blocked=${JSON.stringify(planning.blocked)}, `
   + 'que no es del vocabulario. No se sabe si hay bloqueo, así que no se sigue como si no lo hubiera.')
+governing = planning.rules || []
 
 let currentMilestone = planning.wipActive ? planning.hito : ''
 const completed = []
@@ -565,7 +585,7 @@ while (rounds++ < MAX_TASKS) {
     const nota = await registerHuman(
       `Registrá ${unit.id} en ${HUMAN}: nadie pudo escribir un plan que sobreviva a la crítica. `
       + `Motivo: ${detail}. La acción humana es revisar si la unidad son dos resultados con vidas `
-      + `distintas y partirla —R17—, o dejarla entera con la razón escrita.`, 'plan-human')
+      + `distintas y partirla, o dejarla entera con la razón escrita.`, 'plan-human')
     return stop(reason, `${detail}${nota}`)
   }
 
@@ -746,8 +766,8 @@ while (rounds++ < MAX_TASKS) {
     let review = await run(
       `${asRole(cast.review)}Revisá el diff real por aceptación, regresiones, seguridad, arquitectura, código ` +
       `generado, migraciones y alcance accidental. Cada cargo revisa su dominio, no el ajeno.${MANIFEST}` +
-      `${VERDICT}`,
-      { schema: DECISION, label: 'review' },
+      `${VERDICT}${RULED}`,
+      { schema: REVIEWED, label: 'review' },
     )
     if (!review) return stop('agent-unavailable', 'Review no devolvió resultado')
     if (review.verdict === 'bloqueado') {
@@ -756,24 +776,42 @@ while (rounds++ < MAX_TASKS) {
     if (blockers(review).length) {
       await write(`Corregí sólo estos hallazgos con evidencia y actualizá el WIP: ${blockers(review).join('; ')}`,
         { label: 'review-fix' })
-      review = await run(`Volvé a revisar el diff corregido de ${task.id}.${MANIFEST}${VERDICT}`,
-        { schema: DECISION, label: 'review' })
+      review = await run(`Volvé a revisar el diff corregido de ${task.id}.${MANIFEST}${VERDICT}${RULED}`,
+        { schema: REVIEWED, label: 'review' })
       if (!review) return stop('agent-unavailable', 'la re-revisión no devolvió resultado')
       if (review.verdict === 'bloqueado' || blockers(review).length) {
         return stop('review-failed', blockers(review).join('; ') || 'sin condiciones nombradas')
       }
     }
+    // Con reglas que rigen, aprobar sin nombrar contra cuáles es la misma falla que la de abajo en otro eje.
+    if (governing.length && !(review.rules || []).length) {
+      return stop('review-unbacked', 'aprobó el diff sin nombrar contra qué reglas revisó')
+    }
+    if (governing.length) log(`Review contra: ${review.rules.join(', ')}`)
     // Aprobar sin declarar qué se abrió no se arregla mandando a tocar código: falló quien revisó.
     if (!review.consulted.length) return stop('review-unbacked', 'aprobó el diff sin declarar qué inspeccionó')
     reviewFact = `${review.verdict} por ${cast.review}, sobre ${review.consulted.join(', ')}`
     // Lo que no impide entregar no manda a tocar código, y tampoco desaparece: la mejora opinable que se
     // corrige a las apuradas cuesta una vuelta y un riesgo que nadie pidió. Va a Propuestas y no a
-    // Lecciones porque lo que la revisión anotó es un cambio del producto con su evidencia; Lecciones es
-    // sobre cómo trabajamos, y ahí el hallazgo queda esperando una promoción que nadie va a hacer.
-    const noted = review.concerns.filter((one) => !one.blocking).map((one) => one.detail)
-    if (noted.length) {
+    // Lecciones porque lo que la revisión anotó es un cambio del producto —su evidencia es la de la
+    // tarea, que queda en `done/`—; Lecciones es sobre cómo trabajamos, y ahí el hallazgo queda
+    // esperando una promoción que nadie va a hacer.
+    // De qué vía salió cada una: este recorrido, la tarea que la dejó anotada y la fecha del motor. La
+    // arma el recorrido, que es el único de los dos que sabe las tres cosas (caso 115).
+    const origin = inboxOrigin('autobuild', task.id, planning.today)
+    const noted = review.concerns.filter((one) => !one.blocking).map((one) => withOrigin(one.detail, origin))
+    const kept = noted.slice(0, INBOX_CAP)
+    // Lo que pasa del tope no se escribe y tampoco desaparece: queda contado en el hecho de revisión, que
+    // viaja a `done/`. Una revisión que anota treinta y seis cosas no está priorizando, y el INBOX no las
+    // iba a leer (caso 101).
+    if (noted.length > kept.length) {
+      reviewFact += ` · ${noted.length - kept.length} anotado(s) sin volcar al INBOX`
+    }
+    if (kept.length) {
       await write(`Registrá en la sección Propuestas de ${P}/INBOX.md lo que la revisión de ${task.id} dejó ` +
-        `anotado sin frenar la entrega, sin promover ninguna: ${JSON.stringify(noted)}`, { label: 'review-noted' })
+        `anotado sin frenar la entrega, sin promover ninguna. ` +
+        `${inboxAsk(['Propuestas'], planning.inbox, origin)} ` +
+        `Lo anotado: ${JSON.stringify(kept)}`, { label: 'review-noted' })
     }
   }