@ingeniomaps/cauce 0.82.0 → 0.83.0

package/CHANGELOG.md

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

package/automatization/hooks/README.md

@@ -76,14 +76,18 @@ guards lo leen:
   `.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/shared/inbox.js

@@ -9,20 +9,39 @@ const INBOX_ENTRY = '- **slug-del-item** — Qué es, y qué se decide o se resu
 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) => {
+const oneLine = (text, reserved = 0) => {
   const first = String(text || '').split('\n')[0].trim()
-  return first.length > 240 ? `${first.slice(0, 239)}…` : first
+  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) {
+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. Por nombre, ${known}: lo que ya esté con uno de esos nombres no 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/autobuild.js

@@ -796,7 +796,10 @@ while (rounds++ < MAX_TASKS) {
     // 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.
-    const noted = review.concerns.filter((one) => !one.blocking).map((one) => oneLine(one.detail))
+    // 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
@@ -806,7 +809,8 @@ while (rounds++ < MAX_TASKS) {
     }
     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. ${inboxAsk(['Propuestas'], planning.inbox)} ` +
+        `anotado sin frenar la entrega, sin promover ninguna. ` +
+        `${inboxAsk(['Propuestas'], planning.inbox, origin)} ` +
         `Lo anotado: ${JSON.stringify(kept)}`, { label: 'review-noted' })
     }
   }

package/automatization/workflows/flow.js

@@ -61,6 +61,8 @@ const MANIFEST = {
     conditionalAgents: { type: 'array', items: { type: 'string' } },
     // Con los nombres que ya hay en el INBOX, lo que el recorrido escribe al final no repite uno.
     inbox: INBOX_HEADS,
+    // La fecha, del mismo comando que trae los nombres (caso 115).
+    today: { type: 'string' },
     owners: { type: 'array', items: { type: 'object', additionalProperties: false, properties: {
       domain: { type: 'string' }, agent: { type: 'string' },
     } } },
@@ -164,7 +166,8 @@ const contract = await agent(
   `only ran on failure the destination came out of memory.\n` +
   `   If command 1 failed, set exists=false, report flows, and stop.\n` +
   `3. "node tools/ops.js agents list --json", which gives each role its resolved path.\n` +
-  `4. "node tools/ops.js context planning --json" — copy only its inbox field into inbox, verbatim.\n` +
+  `4. "node tools/ops.js context planning --json" — copy its inbox field into inbox and its today field ` +
+  `into today, both verbatim, and nothing else it printed.\n` +
   `Report exists=true and these manifest fields: name, purpose, outcome, entryAgent, facilitator, ` +
   `guardrails, decisionOwners flattened into owners as domain/agent pairs, and stages with id, phase, ` +
   `agent, produces, dependsOn and exitGate. Drop every other field the command printed — the schema ` +
@@ -201,6 +204,11 @@ const RULES = `${BASE}\n\nRecorrido ${contract.name}: ${contract.purpose}\n` +
     + `destino, sale de esa lista; si ninguno sirve, decilo con su razón en vez de inventar uno.\n` : ''}` +
   `Contexto de la empresa en ${WORKDIR}/organization/. Intención a evaluar: ${GOAL}`
 
+// De qué vía sale lo que este recorrido escriba en el INBOX: el recorrido, el equipo que lo corrió y la
+// fecha que dio el motor. En modo informe la unidad es el informe y esa rama arma la suya, porque es
+// donde queda la evidencia de lo que se anotó.
+const ORIGIN = inboxOrigin('flow', FLOW, contract.today)
+
 phase('Stages')
 
 const handoffs = []
@@ -419,11 +427,13 @@ if (contract.outcome === 'report') {
   // El tope lo aplica el recorrido y no quien escribe, y lo que pasa de él ya está en el informe: al
   // INBOX va lo que alguien tiene que decidir, no todo lo que el informe dejó abierto (caso 101).
   const followUps = report.followUps || []
-  const listed = followUps.slice(0, INBOX_CAP).map((one) => ({ section: one.section, entry: oneLine(one.entry) }))
+  const reportOrigin = inboxOrigin('flow', report.file, contract.today)
+  const listed = followUps.slice(0, INBOX_CAP)
+    .map((one) => ({ section: one.section, entry: withOrigin(one.entry, reportOrigin) }))
   if (listed.length) {
     await agent(
       `${RULES}\n\nRegistrá en ${INBOX} estos seguimientos del informe ${report.file}, cada uno en su ` +
-      `sección y sin promover ninguno. ${inboxAsk(['Propuestas', 'Lecciones'], contract.inbox)} ` +
+      `sección y sin promover ninguno. ${inboxAsk(['Propuestas', 'Lecciones'], contract.inbox, reportOrigin)} ` +
       `Seguimientos: ${JSON.stringify(listed)}`,
       { label: 'report-inbox' },
     )
@@ -456,7 +466,8 @@ if (!epic) return stop('draft-unavailable', 'la propuesta de épica no devolvió
 if (epic.outcome === 'no-hacer') {
   await agent(
     `${RULES}\n\nRegistrá la conclusión en la sección Lecciones de ${INBOX}: por qué esta intención no ` +
-    `es viable hoy y qué la haría viable. ${inboxAsk(['Lecciones'], contract.inbox)} Motivo: ${epic.reason}`,
+    `es viable hoy y qué la haría viable. ${inboxAsk(['Lecciones'], contract.inbox, ORIGIN)} ` +
+    `Motivo: ${withOrigin(epic.reason, ORIGIN)}`,
     { label: 'inbox-lesson' },
   )
   return stop('no-viable', epic.reason)
@@ -467,7 +478,8 @@ if (epic.outcome === 'investigar') {
   await agent(
     `${RULES}\n\nRegistrá en ${HUMAN} qué hay que averiguar antes de poder decidir esta intención y quién ` +
     `puede hacerlo, sin inventar responsables ni fechas, y dejá la conclusión en la sección Ideas de ` +
-    `${INBOX} sin promoverla. ${inboxAsk(['Ideas'], contract.inbox)} Qué falta averiguar: ${epic.reason}`,
+    `${INBOX} sin promoverla. ${inboxAsk(['Ideas'], contract.inbox, ORIGIN)} ` +
+    `Qué falta averiguar: ${withOrigin(epic.reason, ORIGIN)}`,
     { label: 'investigar' },
   )
   return finish({ flow: FLOW, stages: handoffs.length, investigate: epic.reason, promoted: false })

package/automatization/workflows/onboard.js

@@ -89,6 +89,8 @@ const SCAN = {
     secrets: { type: 'array', items: { type: 'string' } },
     // Los nombres que ya hay en Ideas: con `force` el arranque reescribe una instancia que ya tiene INBOX.
     inboxIdeas: { type: 'array', items: { type: 'string' } },
+    // La fecha que lleva la procedencia de lo que se escriba en Ideas (caso 115).
+    today: { type: 'string' },
   },
 }
 
@@ -114,7 +116,8 @@ const state = await agent(
   `dimension, and every service with its path, its runtimes, its declared commands keeping the source ` +
   `file each command came from, and the variable names its "env" carries. Add nothing it did not print.\n` +
   `2. "node tools/ops.js check planning".\n` +
-  `3. "node tools/ops.js context planning --json": copy its inbox.ideas into inboxIdeas, verbatim.\n` +
+  `3. "node tools/ops.js context planning --json": copy its inbox.ideas into inboxIdeas and its today ` +
+  `into today, both verbatim.\n` +
   `The inventory already names every credential each service expects: never open a .env file to look for ` +
   `more. Report those names in secrets and the services they point at in externals. A name the inventory ` +
   `carries is declared, and saying otherwise is a claim the repository contradicts.`,
@@ -196,11 +199,15 @@ phase('Epic')
 // Las preguntas abiertas van al INBOX con tope, y el tope lo aplica el recorrido: por eso las escribe
 // este paso con lo que el anterior devolvió, y no el anterior mientras las redactaba (caso 101). Las que
 // no entran se dicen al cerrar, que es donde la persona que arrancó la instancia las lee.
+// De qué vía salieron: este recorrido y la fecha del motor. Un arranque no tiene ni tarea ni informe que
+// nombrar, así que su procedencia son esas dos partes y nada más (caso 115). El log de las que no entran
+// se queda sin ella: quien lo lee está mirando la corrida que las produjo.
+const ORIGIN = inboxOrigin('onboard', state.today)
 const questions = (drafted.openQuestions || []).map(oneLine)
-const inboxed = questions.slice(0, INBOX_CAP)
+const inboxed = questions.slice(0, INBOX_CAP).map((one) => withOrigin(one, ORIGIN))
 const INBOX_ASK = inboxed.length
   ? `Registrá además en la sección Ideas de ${INBOX}, sin promover, estas preguntas abiertas: ` +
-    `${JSON.stringify(inboxed)}. ${inboxAsk(['Ideas'], { ideas: state.inboxIdeas || [] })}\n\n`
+    `${JSON.stringify(inboxed)}. ${inboxAsk(['Ideas'], { ideas: state.inboxIdeas || [] }, ORIGIN)}\n\n`
   : ''
 
 const epic = await agent(

package/engine/hooks/approval.js

@@ -34,18 +34,37 @@ const APPROVAL = '.ops-approval'
 // Una ruta por línea, `#` para lo demás. El archivo ausente y el vacío son lo mismo: no hay nada
 // aprobado, que es el estado normal. Un push se aprueba igual, con la línea `push <remoto> <rama>`
 // tal cual y sin patrones: `feat/*` convertiría una aprobación puntual en un permiso (caso 103).
+//
+// El texto se lee aparte del archivo porque `self-approval` compara lo que se está por escribir contra lo
+// que ya está en disco: con dos parsers, una línea podría contar de un lado y no del otro (caso 119).
+const lines = (text) => text.split('\n').map((line) => line.replace(/#.*$/, '').trim()).filter(Boolean)
+
 function read(root) {
-  let text = ''
-  try { text = fs.readFileSync(path.join(root, 'planning', APPROVAL), 'utf8') } catch { return [] }
-  return text.split('\n').map((line) => line.replace(/#.*$/, '').trim()).filter(Boolean)
+  try { return lines(fs.readFileSync(path.join(root, 'planning', APPROVAL), 'utf8')) } catch { return [] }
 }
 
 // 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. Cuenta también lo que la
 // persona pidió en el chat.
-function pending(root, files, input) {
+const left = (root, files) => {
   const approved = new Set(root ? read(root) : [])
-  return CHAT.unauthorized(input, files.filter((file) => !approved.has(file)))
+  return files.filter((file) => !approved.has(file))
+}
+
+function pending(root, files, input) {
+  return CHAT.unauthorized(input, left(root, files))
+}
+
+// Lo mismo para los gates de commit —`governance`, `verify` y `dependencies`—, que preguntan cada vez: no
+// conceden nada y no heredan lo que la sesión venía concediendo.
+//
+// Commitear está del lado de publicar y no del de leer, y por qué esa diferencia decide quién hereda está
+// en `push.js`. Lo propio de un commit es que el objeto del permiso se mueve solo: lo que autoriza uno no
+// dice nada del siguiente, porque el índice ya es otro. Nadie lo había decidido para los gates —heredaban
+// por venir todos de `pending`—, y se midió: con otro mensaje en curso, un commit de gobernanza pasaba
+// (caso 119).
+function pendingNow(root, files, input) {
+  return CHAT.unauthorizedNow(input, left(root, files))
 }
 
 // El archivo que el guard va a leer, nombrado desde la carpeta en la que está la sesión. En sidecar la
@@ -70,16 +89,31 @@ function where(input) {
 // 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) {
+//
+// `pasteable` es lo que se puede aprobar por archivo, y por defecto es todo: un guard lo angosta cuando lo
+// que tiene a mano no sirve para pegar —por qué, en `secrets-shell.js` (caso 118)—. Lo frenado se anota
+// igual, así que el «dale» sigue cubriendo todo.
+function HOW(variable, lines, input, pasteable = lines) {
   const chat = CHAT.hold(input, lines)
-  return (chat
+  const stuck = lines.filter((one) => !pasteable.includes(one))
+  const ask = 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.'
+      + 'pasa. '
+    : ''
+  const paste = pasteable.length
+    ? (chat ? 'Si prefiere aprobarlo a mano, que pegue ella tal cual en' : 'Aprobalo pegando tal cual en')
+      + ` ${where(input)} estas líneas:\n`
+      + pasteable.map((line) => `  ${line}\n`).join('')
+      + 'Valen para ese conjunto y dejan de valer en cuanto cambie. '
+    : ''
+  const unresolved = stuck.length
+    ? `Por archivo no hay línea que pegar para ${stuck.join(', ')}: la ruta llegó con una expansión del shell `
+      + 'sin resolver, y la aprobación compara texto, así que esa línea sólo valdría para un comando escrito '
+      + 'igual. Volvé a correrlo con la ruta escrita y el bloqueo va a decir qué pegar. '
+    : ''
+  return ask + paste + unresolved
+    + `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, where, HOW }
+module.exports = { APPROVAL, lines, read, pending, pendingNow, where, HOW }

package/engine/hooks/chat.js

@@ -53,6 +53,12 @@ const CLAUSE = /[,;:!?\n]|\.(?=\s|$)/
 // archivo sin pedir nada (caso 109). La frase del nombre tiene que traer un verbo que pida una acción, en
 // español o en inglés; se compara sin tildes y sin el pronombre pegado —«leelo», «abrime»—. La lista va a
 // quedar corta, y lo que no reconoce no se pierde: se frena, y un «dale» lo aprueba.
+//
+// Autorizar también es pedir, y era lo que faltaba: «autorizo la lectura del .env» es la forma más
+// explícita de decir que sí y se frenaba igual, porque ninguna de sus palabras estaba (caso 118). Entran
+// las formas con que una persona **concede** —primera persona e imperativo— y no los sustantivos que
+// nombran el acto: `lectura`, `permiso` y `autorizacion` aparecen igual en una pregunta que no autoriza
+// nada, y dejarlos afuera es lo que el 109 decidió cuando dijo que nombrar no alcanza.
 const ASKS = new Set(('lee leer abri abre abrir mostra muestra mostrar ensena edita editar cambia cambiar borra '
   + 'borrar elimina eliminar escribi escribe escribir corre correr ejecuta ejecutar desactiva desactivar apaga '
   + 'apagar reescribi reescribe reescribir agrega agregar anadi anade anadir saca sacar quita quitar actualiza '
@@ -60,9 +66,11 @@ const ASKS = new Set(('lee leer abri abre abrir mostra muestra mostrar ensena ed
   + 'subi sube subir pushea pushear commitea commitear usa usar crea crear arregla arreglar carga cargar copia '
   + 'copiar toca tocar aproba aprueba aprobar habilita habilitar reemplaza reemplazar renombra renombrar mueve '
   + 'mover restaura restaurar imprimi imprime imprimir deci dime proba probar '
+  + 'autorizo autoriza autorizar autorizado permito permiti permite permitir apruebo habilito '
   + 'read open show print display edit change delete remove write run execute disable rewrite add update modify '
   + 'check review inspect look cat commit push install use create fix load copy touch approve enable replace '
-  + 'rename move restore skip').split(' '))
+  + 'rename move restore skip '
+  + 'authorize authorized allow allowed permit permitted grant granted approved').split(' '))
 const ENCLITIC = /(?:selo|sela|melo|mela|telo|tela|los|las|lo|la|le|me)$/
 
 function asks(clause) {
@@ -120,6 +128,10 @@ const YES = new RegExp(String.raw`^\s*(?:s[ií]|dale|ok(?:ay)?|hac[eé]lo|hazlo|
 // 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.
+//
+// Lo concedido es lo único que cruza de un mensaje al siguiente, y se hereda aunque este mensaje no lo
+// haya escrito una persona: un aviso del runner en el medio no le quita a nadie lo que ya autorizó. La
+// negación se aplica venga de donde venga, porque revocar es la dirección segura.
 function record(input) {
   try {
     if (!input.session_id) return
@@ -129,9 +141,10 @@ function record(input) {
     const approved = human && previous && YES.test(text)
       ? previous.pending.filter((item) => !mentions(text, item).denied)
       : []
+    const granted = previous ? (previous.granted || []).filter((one) => !mentions(text, one).denied) : []
     fs.mkdirSync(DIR, { recursive: true })
-    fs.writeFileSync(recordPath(input.session_id),
-      JSON.stringify({ id: idOf(input), text, human, flow: flowCommand(text), approved, pending: [] }))
+    fs.writeFileSync(recordPath(input.session_id), JSON.stringify(
+      { id: idOf(input), text, human, flow: flowCommand(text), approved, granted, pending: [] }))
   } catch { /* registrar es un extra: si falla, los guards siguen frenando lo que frenaban */ }
 }
 
@@ -146,14 +159,63 @@ function said(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 pidió en su mensaje ni lo
-// aprobó contestando. Qué cuenta como pedirlo depende de qué se frena: un archivo se nombra, un push se
-// ordena con su remoto y su rama.
+// Con qué autorización pasa un ítem, o vacío si no pasa: lo pidió este mensaje, un «dale» aprobó lo que
+// había quedado frenado, o se lo concedieron antes en esta sesión. Qué cuenta como pedirlo depende de qué
+// se frena: un archivo se nombra, un push se ordena con su remoto y su rama.
 const named = (text, item) => mentions(text, item).named
-function unauthorized(input, items, asked = named) {
+function why(saved, item, asked, inherit) {
+  if (asked(saved.text, item)) return 'orden'
+  if (saved.approved.includes(item)) return 'dale'
+  if (!inherit) return ''
+  return (saved.granted || []).includes(item) ? 'concedido' : ''
+}
+
+// Lo que un guard dejó pasar queda anotado, que es la contracara de `hold`: hasta 0.82.0 sólo se anotaba
+// lo frenado, así que una autorización usada moría con el mensaje y lo mismo se frenaba una y otra vez.
+// Ahí la salida barata era apagar el guard para toda la sesión con una variable, o sea el permiso más
+// ancho de los dos (caso 116).
+//
+// Se anota el ítem **como el guard lo nombró** —la ruta en la forma que ese guard tiene a mano— y no el
+// archivo que hay detrás: es el mismo alcance que tiene una línea de `.ops-approval`, angosto de más
+// antes que de menos.
+function grant(input, saved, items) {
+  const before = saved.granted || []
+  const granted = [...new Set([...before, ...items])]
+  if (granted.length === before.length) return
+  try {
+    saved.granted = granted
+    fs.writeFileSync(recordPath(input.session_id), JSON.stringify(saved))
+  } catch { /* sin anotarlo, se vuelve a pedir */ }
+}
+
+// Con qué autorización pasa cada uno de los que pasan. Lo pregunta quien necesita el porqué y no sólo el
+// qué —el rastro de un push lo anota (caso 112)—, y no concede nada: preguntar no cambia qué va a valer
+// en el mensaje siguiente.
+//
+// Conceder y heredar son dos cosas distintas y hasta 0.83.0 se movían juntas: conceder es escribir en el
+// registro, heredar es leer lo que escribió un mensaje anterior. Quien decide algo que vuelve a tener
+// consecuencia cada vez que ocurre apaga lo segundo con `inherit: false`, y ahí vale lo que la persona pidió
+// en el mensaje en curso o aprobó con un «dale» (caso 119).
+function authorized(input, items, { asked = named, inherit = true } = {}) {
+  const saved = said(input)
+  if (!saved) return []
+  return items.map((item) => ({ item, via: why(saved, item, asked, inherit) })).filter((one) => one.via)
+}
+
+// Lo que la persona no autorizó de lo que un guard está por frenar; lo que sí, queda concedido.
+function unauthorized(input, items) {
   const saved = said(input)
   if (!saved) return items
-  return items.filter((item) => !saved.approved.includes(item) && !asked(saved.text, item))
+  const passed = items.filter((item) => why(saved, item, named, true))
+  grant(input, saved, passed)
+  return items.filter((item) => !passed.includes(item))
+}
+
+// Lo mismo sin conceder y sin heredar: lo que no está en el mensaje en curso queda pendiente aunque la
+// sesión lo haya dejado pasar antes.
+function unauthorizedNow(input, items) {
+  const cleared = new Set(authorized(input, items, { inherit: false }).map((one) => one.item))
+  return items.filter((item) => !cleared.has(item))
 }
 
 // Lo que quedó frenado, para que un «dale» en el mensaje siguiente apruebe exactamente eso y nada más.
@@ -168,4 +230,4 @@ function hold(input, items) {
   } catch { return false }
 }
 
-module.exports = { DIR, record, said, unauthorized, hold, ordersPush }
+module.exports = { DIR, record, said, authorized, unauthorized, unauthorizedNow, hold, ordersPush }

package/engine/hooks/ops-config.js

@@ -0,0 +1,110 @@
+'use strict'
+
+// Las dos llaves que deciden si un `git push` se publica —`runner.allowPush` y `runner.pushToLiveBranches`—
+// viven en `ops.config.json`, y hasta 0.82.0 ningún guard miraba ese archivo: el bloqueo que dice «esto lo
+// decide una persona» se levantaba escribiendo el archivo que lo levanta, por `Write` o por `sed -i`, y el
+// mensaje del bloqueo nombra el campo exacto que hay que agregar (caso 114).
+//
+// **Protege esos dos campos y no el archivo.** Protegerlo entero repondría el candado que el 090 sacó: el
+// límite de raíces manda a declarar la ruta en `writableOutsideRoots`, de este mismo archivo, así que
+// frenar esa edición dejaría al agente sin la salida que el otro guard le acaba de indicar. Todo lo demás
+// —raíces, migraciones, lo que sea— sigue pasando como trabajo normal.
+//
+// Son dos guards y un solo archivo, como `secrets` y `secrets-shell`: corren en eventos distintos y cada
+// grupo cubre a cada guard una vez, mientras que lo que deciden —cuál es el archivo, qué llave cambió y
+// cómo se dice— es uno solo y copiarlo dejaría dos mitades que dejan de coincidir.
+
+const path = require('node:path')
+const { block, commandOf, configOf, contentOf, cwdOf, filesOf, opsRoot } = require('./input')
+const CHAT = require('./chat')
+const { writesWithBase } = require('./shell')
+
+const INSTANCE_CONFIG = 'ops.config.json'
+const PROTECTED = ['allowPush', 'pushToLiveBranches']
+const NAMES = PROTECTED.map((name) => `runner.${name}`).join(' y ')
+
+// El valor de cada llave en la forma en que se comparan. Ausente no es vacío: sacar `pushToLiveBranches`
+// cambia qué ramas alcanza el permiso y tiene que distinguirse de dejarlo en una lista sin ramas. Lo hace
+// `JSON.stringify`, que de un campo ausente no devuelve nada y de ninguno presente devuelve la cadena vacía.
+function keysOf(config) {
+  const runner = (config && typeof config.runner === 'object' && config.runner) || {}
+  return PROTECTED.map((name) => JSON.stringify(runner[name])).join(' ')
+}
+
+// El mensaje le habla a la persona y deja el permiso como cosa suya; el porqué de esa redacción está en
+// `HOW`, en `approval.js`.
+const HANDS_OFF = 'Lo decide una persona (R10): decile qué se frenó y esperá. Lo pone ella editando el '
+  + `archivo, o pidiéndotelo en el chat nombrando ${INSTANCE_CONFIG}.`
+
+function changeMessage(file) {
+  return `${file} lleva las dos llaves que deciden qué push se publica, ${NAMES}, y este cambio las toca. `
+    + `${HANDS_OFF}\nEl resto del archivo no lo frena este guard: si venías a declarar una raíz o a tocar `
+    + 'cualquier otro campo, mandá el mismo cambio sin mover esas dos llaves.'
+}
+
+// **Un contenido que no se puede leer como JSON se frena.** Un `Edit` manda el fragmento que reemplaza y no
+// el archivo, así que no hay con qué comparar: dejarlo pasar apagaría este guard con la herramienta más
+// común de todas, y frenarlo deja una salida más cara pero escrita —mandar el archivo entero, que sí se
+// compara—. Es el mismo criterio con el que el motor decide cuando no puede leer el índice de git.
+function unreadableMessage(file) {
+  return `${file} no llega como un JSON completo que se pueda leer, así que no hay cómo saber si el cambio `
+    + `toca ${NAMES}, las dos llaves que deciden qué push se publica. Un guard que no puede verificar no `
+    + 'autoriza: mandá el archivo entero en una sola escritura y el guard compara lo que cambia.'
+}
+
+// **Por shell se frena toda escritura, y no sólo la de las dos llaves.** La mitad de archivos compara dos
+// contenidos porque tiene los dos: el entrante viene en la llamada y el otro está en disco. Un comando no
+// trae ninguno —`sed -i 's/false/true/'` dice qué reemplaza, no con qué va a quedar el archivo—, y
+// averiguarlo sería ejecutarlo, que es justo lo que este guard corre antes de que ocurra. Sin contenido que
+// comparar quedan dos conductas posibles y ninguna intermedia, y se elige la que cierra la vía que el 114
+// midió.
+function commandMessage(file) {
+  return `el comando escribe en ${file}, donde viven las dos llaves que deciden qué push se publica, `
+    + `${NAMES}. Un comando no dice con qué va a quedar el archivo, así que acá se frena toda escritura y `
+    + `no sólo la de esas dos llaves. ${HANDS_OFF}\nSi el cambio es de cualquier otro campo, escribí el `
+    + 'archivo entero con la herramienta de edición, que el guard sí puede comparar.'
+}
+
+// Lo que la persona pidió nombrando el archivo pasa: ahí quien decide es ella, que es lo que este guard
+// cuida. Se pregunta cada vez —sin conceder y sin heredar—, igual que `self-approval`: las dos llaves que
+// viven acá son el permiso de push, y nombrar el archivo una vez no lo deja abierto toda la sesión. El
+// comentario decía «lo mismo» mientras el código concedía (caso 119).
+const asked = (input, file) => !CHAT.unauthorizedNow(input, [file]).length
+
+function judgeWrite(input, root, file) {
+  if (!filesOf(input).some((raw) => path.resolve(cwdOf(input), raw) === file)) return
+  if (asked(input, file)) return
+  let incoming = null
+  try { incoming = JSON.parse(contentOf(input)) } catch { block(unreadableMessage(file)) }
+  if (keysOf(configOf(root)) !== keysOf(incoming)) block(changeMessage(file))
+}
+
+function judgeCommand(input, file) {
+  for (const { raw, base } of writesWithBase(commandOf(input), cwdOf(input))) {
+    // Una ruta relativa sin base contra la que resolverla no se puede juzgar, y esa pregunta es de
+    // `shell-boundary`, que ya la contesta para todo destino.
+    if (!path.isAbsolute(raw) && base === null) continue
+    if (path.resolve(base || '/', raw) !== file) continue
+    if (asked(input, file)) return
+    block(commandMessage(file))
+  }
+}
+
+// La configuración que decide, o nada. Sin raíz ops no hay ninguna: `push.js` lee el `runner` de esta
+// misma raíz, así que donde no la hay tampoco hay permiso que escribirse.
+function target(input) {
+  const root = opsRoot(input)
+  return root ? { root, file: path.join(root, INSTANCE_CONFIG) } : null
+}
+
+function opsConfig(input) {
+  const found = target(input)
+  if (found) judgeWrite(input, found.root, found.file)
+}
+
+function opsConfigShell(input) {
+  const found = target(input)
+  if (found) judgeCommand(input, found.file)
+}
+
+module.exports = { opsConfig, opsConfigShell }

package/engine/hooks/push.js

@@ -19,6 +19,8 @@
 //
 // El `--force` no llega hasta acá: lo frena `destructive` antes, sin override (R8).
 
+const fs = require('node:fs')
+const path = require('node:path')
 const { spawnSync } = require('node:child_process')
 const { block, cwdOf, gitDirectory, opsRoot, configOf } = require('./input')
 const AP = require('./approval')
@@ -125,6 +127,37 @@ function workMessage(items, input) {
     + 'El permiso permanente es runner.allowPush en ops.config.json, y lo decide una persona.'
 }
 
+// El rastro de las aprobaciones que publicaron: una línea por push que pasó porque alguien lo autorizó.
+// Una aprobación se consume sin dejar nada —un «dale» publica y al mensaje siguiente ya no queda quién lo
+// autorizó— y un push no vuelve atrás, así que «quién, a qué rama y cuándo» no tenía de dónde salir
+// (caso 112).
+//
+// Sólo agrega, a diferencia del registro de gates, que es rodante: lo que una auditoría pregunta es
+// justamente la entrada vieja.
+//
+// No guarda el texto de la persona. La vía y la sesión alcanzan para reconstruir qué pasó, y el texto se
+// queda en el temporal, que es donde el 098 decidió dejarlo.
+//
+// Y anota la autorización, no el resultado: este hook corre antes del comando, así que un push que después
+// falla queda registrado igual. Por eso la fecha se llama `authorizedAt` y no `at`: leer la línea como
+// «esto se publicó» afirmaría algo que el hook no puede saber.
+const LOG = path.join('planning', '.push-log')
+
+function trail(root, session, entries) {
+  if (!root) return
+  try {
+    const authorizedAt = new Date().toISOString()
+    const file = path.join(root, LOG)
+    fs.mkdirSync(path.dirname(file), { recursive: true })
+    fs.appendFileSync(file, `${entries
+      .map((one) => JSON.stringify({ authorizedAt, ...one, session: session || null })).join('\n')}\n`)
+  } catch { /* el push ya estaba autorizado: no lo frena un registro que no se pudo escribir */ }
+}
+
+// Un destino en la forma en que se anota. Sin remoto ni rama resolubles va `null`, que es exactamente lo
+// que el comando dejó ver.
+const entryOf = (to, via) => ({ remote: to.remote || null, branch: to.branch || null, via })
+
 function publish(input, command) {
   const pushes = [...command.matchAll(PUSH)]
   if (!pushes.length) return
@@ -135,13 +168,27 @@ function publish(input, command) {
   const listed = new Set(Array.isArray(runner.pushToLiveBranches) ? runner.pushToLiveBranches : [])
   const filed = new Set(root ? AP.read(root) : [])
   const live = liveBranches(dir)
-  const left = pushes.flatMap((match) => destinationsOf(match[1], dir))
-    .filter((to) => !(to.item && to.item.startsWith('push ') && filed.has(to.item)))
+  const destinations = pushes.flatMap((match) => destinationsOf(match[1], dir))
+  const byFile = destinations.filter((to) => to.item && to.item.startsWith('push ') && filed.has(to.item))
+  const left = destinations.filter((to) => !byFile.includes(to))
   const unlisted = left.filter((to) => to.every || (live.has(to.branch) && !listed.has(to.branch)))
   if (unlisted.length) block(liveMessage(unlisted, input))
+  // Con la llave puesta no hizo falta ninguna aprobación, así que no hay ninguna que anotar: la
+  // autorización ya está escrita en `ops.config.json`, y repetirla en cada push sería registrar el archivo
+  // del proyecto contra sí mismo.
   if (runner.allowPush === true) return
-  const unordered = CHAT.unauthorized(input, [...new Set(left.map((to) => to.item))], CHAT.ordersPush)
+  const items = [...new Set(left.map((to) => to.item))]
+  // Se pregunta sin conceder, a diferencia de lo que pasa por `AP.pending`: volver a leer lo que ya se
+  // leyó no agrega consecuencia y volver a publicar sí, así que la autorización de un push vale para esa
+  // operación y no para el mensaje siguiente (R10).
+  const cleared = CHAT.authorized(input, items, { asked: CHAT.ordersPush })
+  const unordered = items.filter((item) => !cleared.some((one) => one.item === item))
   if (unordered.length) block(workMessage(unordered, input))
+  const destination = new Map(destinations.map((to) => [to.item, to]))
+  trail(root, input.session_id, [
+    ...new Map(byFile.map((to) => [to.item, entryOf(to, AP.APPROVAL)])).values(),
+    ...cleared.map((one) => entryOf(destination.get(one.item), one.via)),
+  ])
 }
 
 module.exports = { publish }

package/engine/hooks/run.js

@@ -14,6 +14,7 @@ const shell = require('./shell')
 const files = require('./files')
 const chat = require('./chat')
 const { secretsShell } = require('./secrets-shell')
+const { opsConfig, opsConfigShell } = require('./ops-config')
 
 function planningDrift(input) {
   const root = findOpsRoot(process.env.OPS_ROOT || process.env.CLAUDE_PROJECT_DIR || cwdOf(input))
@@ -42,6 +43,8 @@ const guards = {
   verify: shell.verify,
   'shell-boundary': shell.shellBoundary,
   'secrets-shell': secretsShell,
+  'ops-config-shell': opsConfigShell,
+  'ops-config': opsConfig,
   secrets: files.secrets,
   generated: files.generated,
   'workspace-boundary': files.workspaceBoundary,
@@ -58,9 +61,9 @@ const guards = {
 // 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',
-    'secrets-shell'],
+    'secrets-shell', 'ops-config-shell'],
   'pre-files': ['secrets', 'generated', 'workspace-boundary', 'engine', 'migrations',
-    'integration-snapshot', 'test-evidence', 'plan-first'],
+    'integration-snapshot', 'test-evidence', 'plan-first', 'ops-config'],
   'pre-read': ['secrets-read'],
   prompt: ['chat'],
   stop: ['planning-drift'],
@@ -114,6 +117,18 @@ const hookMetadata = [
     purpose: 'Bloquea leer por shell una credencial conocida o declarada; lo que la persona pidió en el chat '
       + 'pasa.',
   },
+  {
+    name: 'ops-config',
+    event: 'PreToolUse · files',
+    purpose: 'No deja al agente escribirse el permiso de push: frena la escritura que cambia '
+      + 'runner.allowPush o runner.pushToLiveBranches en ops.config.json. El resto del archivo pasa.',
+  },
+  {
+    name: 'ops-config-shell',
+    event: 'PreToolUse · shell',
+    purpose: 'Frena toda escritura por shell sobre ops.config.json: un comando no dice con qué va a '
+      + 'quedar el archivo, así que no hay contenido que comparar.',
+  },
   { name: 'generated', event: 'PreToolUse · files', purpose: 'Impide editar código generado manualmente.' },
   {
     name: 'workspace-boundary',

package/engine/hooks/secrets-shell.js

@@ -33,11 +33,21 @@ function verbOf(words) {
   return words[0] || ''
 }
 
+// `${VAR}` y `$VAR` son la misma expansión, y sólo la primera lleva llaves: la separación de palabras corta
+// ahí, así que de `ops/${O}/.env.infisical` quedaba suelto `/.env.infisical` —una ruta absoluta que el
+// comando no lee y que el bloqueo ofrecía aprobar—. Sin llaves, la expansión se queda pegada a su ruta y el
+// guard la ve como lo que es: algo que no resolvió (caso 118).
+const unbraced = (command) => String(command).replace(/\$\{(\w+)\}/g, '$$$1')
+
+// Lo que el shell iba a expandir y el guard no: una variable, un `$(…)` o un backtick. Lo que sale de ahí
+// no nombra ningún archivo, así que no se puede aprobar por archivo.
+const UNRESOLVED = /[$`]/
+
 // 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]+|\$\(|`/)) {
+  for (const segment of unbraced(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) || []))
@@ -56,7 +66,8 @@ function secretsShell(input) {
   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)}`)
+    + 'Si hace falta un valor, pedíselo a una persona.\n'
+    + AP.HOW('OPS_SECRETS_READ_OVERRIDE', left, input, left.filter((one) => !UNRESOLVED.test(one))))
 }
 
 module.exports = { secretsShell }

package/engine/hooks/self-approval.js

@@ -8,24 +8,104 @@
 // 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.
+//
+// **Nombrar el archivo autoriza el archivo, no lo que se escribe adentro**, y hasta 0.83.0 eso era todo lo
+// que se comprobaba: la persona pedía agregar una ruta inocua, el agente escribía `push origin main`, y esa
+// línea después publicaba en la rama viva —el alcance que el 108 le dio a propósito, apoyado en que sólo
+// una persona podía escribirla—. Medido punta a punta (caso 119). Por eso lo que llega se compara línea por
+// línea contra lo que la persona pidió, y son dos entradas porque cada vía tiene con qué distinto.
 
 const path = require('node:path')
-const { opsRoot } = require('./input')
+const { contentOf, 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 CHAT_RECORD = (file) => `${file} es el registro de lo que la persona dijo en el chat: lo escribe el `
+  + 'runner, nunca una herramienta.'
+
+const SELF = (file) => `${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.'
+
+// Las líneas van en el mensaje porque son lo que el «dale» va a aprobar: una confirmación que no muestra
+// qué autoriza es la que firma lo que nadie leyó.
+const UNASKED = (file, missing) => `${file} es la aprobación de una persona y estas líneas no las pidió:\n`
+  + missing.map((line) => `  ${line}\n`).join('')
+  + 'Escribí sólo lo que ella nombró en su mensaje. Si hacen falta las otras, decile cuáles y por qué, y '
+  + 'esperá: si contesta «dale», reintentá la misma escritura y pasa.'
+
+// **Por shell se frena toda escritura.** Es la misma decisión que toma `ops-config`, y por qué un comando
+// no se puede comparar está escrito allá. Lo que la trae hasta acá es que el contenido es lo único que
+// separa la línea que la persona pidió de la que el agente se escribe solo.
+const BY_COMMAND = (file) => `el comando escribe en ${file}, la aprobación de una persona, y no dice con `
+  + 'qué va a quedar el archivo: sin eso no hay cómo saber si lo que se agrega es lo que ella pidió. '
+  + 'Mandalo con la herramienta de edición, que trae el contenido y se compara línea por línea, o que lo '
+  + 'pegue ella.'
+
+// La raíz de la instancia si `file` es su aprobación, o `null`.
+function approvalRoot(input, file) {
   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.'
+  return root && file === path.join(root, 'planning', AP.APPROVAL) ? root : null
+}
+
+// Lo que las dos vías deciden igual: el registro del chat no se escribe nunca, y la aprobación sólo si la
+// persona la nombró en su mensaje.
+//
+// Se pregunta sin conceder: una concesión que sobreviviera al mensaje convertiría «agregá src/x.js a
+// .ops-approval» en permiso para escribirle después cualquier otra línea, que es aprobarse solo por la
+// puerta de al lado.
+function common(input, file) {
+  if (file === CHAT.DIR || file.startsWith(`${CHAT.DIR}${path.sep}`)) return CHAT_RECORD(file)
+  if (!approvalRoot(input, file)) return ''
+  return CHAT.authorized(input, [file]).length ? '' : SELF(file)
+}
+
+// Una línea de push no se pregunta como una ruta: `mentions` compara también el basename, así que para
+// `push origin feat/login` alcanzaría con que el mensaje pidiera algo del login (caso 103). Es la misma
+// partición que hace `push.js` cuando pregunta por un destino.
+const isPush = (line) => /^push\s+\S+\s+\S+$/.test(line)
+
+// Por qué no se puede escribir este contenido, o vacío.
+//
+// **Lo que ya estaba en disco no se vuelve a nombrar**: esta escritura no lo agrega, y exigirlo obligaría a
+// repetir el archivo entero para sumar una línea. Quitar tampoco se pregunta: una aprobación más corta
+// autoriza menos.
+//
+// **Un fragmento sí se juzga, al revés que en `ops.config.json`.** Allá el archivo entrante se compara
+// entero porque una llave cambia de sentido según lo que la rodea, y un `Edit` manda un pedazo; acá cada
+// línea vale por sí sola, así que el pedazo que llega es exactamente lo que se agrega. Lo que no se puede
+// leer como líneas —un parche con sus encabezados— no coincide con nada pedido y se frena, que es el lado
+// correcto para equivocarse.
+//
+// Y se pregunta sin heredar lo que la sesión concedió antes: una línea acá la leen todos los guards y llega
+// hasta la rama viva, así que tiene que ser la que la persona dijo en el mensaje en curso.
+function unasked(input, root, file) {
+  const filed = new Set(AP.read(root))
+  const added = AP.lines(contentOf(input)).filter((line) => !filed.has(line))
+  const pushes = CHAT.authorized(input, added.filter(isPush), { asked: CHAT.ordersPush, inherit: false })
+  const paths = CHAT.authorized(input, added.filter((line) => !isPush(line)), { inherit: false })
+  const cleared = new Set([...pushes, ...paths].map((one) => one.item))
+  const missing = added.filter((line) => !cleared.has(line))
+  if (!missing.length) return ''
+  // El archivo se anota junto con las líneas: sin él, el «dale» aprobaría las líneas y el guard volvería a
+  // frenar por el archivo, que en ese mensaje ya nadie nombra.
+  CHAT.hold(input, [file, ...missing])
+  return UNASKED(file, missing)
+}
+
+// Por qué el agente no puede escribir en `file` con la herramienta de edición, o vacío.
+function selfApproval(input, file) {
+  const stop = common(input, file)
+  if (stop) return stop
+  const root = approvalRoot(input, file)
+  return root ? unasked(input, root, file) : ''
+}
+
+// Lo mismo para el destino de un comando, o vacío.
+function selfApprovalShell(input, file) {
+  const stop = common(input, file)
+  if (stop) return stop
+  return approvalRoot(input, file) ? BY_COMMAND(file) : ''
 }
 
-module.exports = { selfApproval }
+module.exports = { selfApproval, selfApprovalShell }

package/engine/hooks/shell.js

@@ -14,7 +14,7 @@ const {
 } = require('./input')
 const AP = require('./approval')
 const { publish } = require('./push')
-const { selfApproval } = require('./self-approval')
+const { selfApprovalShell } = 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
@@ -177,7 +177,7 @@ function dependencies(input) {
   // Lo que se juzga acá es el archivo staged, así que la aprobación por ruta lo expresa: autorizar
   // `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),
+  const sinAprobar = (parent, names) => AP.pendingNow(opsRoot(input),
     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
@@ -315,7 +315,7 @@ function shellBoundary(input) {
     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)
+    const own = selfApprovalShell(input, file)
     if (own) block(own)
     if (!allowed || NEUTRAL.some((pattern) => pattern.test(file))) continue
     if (outsideRoots(file, allowed)) {
@@ -348,7 +348,7 @@ 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, input)
+  const pendientes = AP.pendingNow(opsRoot(input), governed, input)
   if (!pendientes.length) return
   block(`El commit toca gobernanza protegida.\n${AP.HOW('OPS_GOVERNANCE_OVERRIDE', pendientes, input)}`)
 }
@@ -489,7 +489,7 @@ 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, input)
+  const sinAprobar = AP.pendingNow(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 '
@@ -604,4 +604,4 @@ function verifyGates(root, dir, sinAprobar, env, input) {
     + AP.HOW('OPS_SKIP_VERIFY', sinAprobar, input))
 }
 
-module.exports = { destructive, gitAdd, dependencies, governance, verify, shellBoundary, run }
+module.exports = { destructive, gitAdd, dependencies, governance, verify, shellBoundary, run, writesWithBase }

package/package.json

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

package/template/AGENTS.md

@@ -109,7 +109,9 @@ te frena es el peor para elegir bien.
 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
+eso. **Con los gates de un commit se pregunta cada vez**, como con publicar: gobernanza, los gates del
+stack y los lockfiles no heredan lo que autorizaste en un mensaje anterior, porque cada commit es otra
+operación. 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.
 

package/template/gitignore

@@ -9,6 +9,11 @@ node_modules/
 # máquina. Committearlo sería historia que nadie lee y un conflicto por commit.
 planning/.verify-log
 
+# El rastro de los push que pasaron por una aprobación. Local por lo mismo que el de arriba, y encima
+# sólo crece: lo que contesta —quién autorizó qué rama y cuándo— se pregunta en la máquina donde corrió
+# la sesión que publicó.
+planning/.push-log
+
 # El plan de cada runner. Es de la máquina que lo corre —existe para recuperar una ejecución
 # interrumpida, y nadie más puede retomarla— y cambia en cada paso, así que compartirlo es un conflicto
 # por commit a cambio de nada. Lo que el equipo sí necesita saber vive en `planning/claims/`.

package/template/planning/delivery/teamwork.md

@@ -11,7 +11,7 @@ choques entre dos personas —o entre dos agentes— salen de tratarlas igual.
 |---|---|---|---|
 | **Compartido** | `roadmap/`, `BACKLOG.md`, `INBOX.md`, `HUMAN_ACTIONS.md`, `done/`, reglas y ADR | cualquiera, en actos humanos | baja |
 | **Coordinación** | `claims/`, un archivo por tarea tomada | uno por tarea | dos veces por tarea |
-| **Local** | `wip/<runner>.md`, `.verify-log`, el árbol de trabajo | vos | continua |
+| **Local** | `wip/<runner>.md`, `.verify-log`, `.push-log`, el árbol de trabajo | vos | continua |
 
 La regla que los separa: **un archivo con más de un escritor tiene que cambiar poco; uno que cambia mucho
 tiene que tener un solo escritor.** Cuando uno viola las dos a la vez, el equipo se pisa en cada commit.