@ingeniomaps/cauce 0.80.0 → 0.82.0

package/engine/hooks/shell.js

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

package/engine/integrations/registry.js

@@ -64,11 +64,22 @@ function adapter(root, name, entry = {}) {
   return impl
 }
 
+// Qué nombre tiene forma de secreto. Es una sola regla para los tres que la necesitan: la configuración
+// de una integración, la declaración de secretos y el aviso de credenciales sin dueño de «ops check».
+// La clave cuenta sólo como palabra propia —API_KEY sí, projectKey no—, porque el campo de Jira con la
+// clave del proyecto está en instancias reales y rechazarlo les rompería la validación (caso 102, donde
+// está la medición).
+const SENSITIVE = /(password|secret|token|authorization|cookie|dsn|credentials?|(?:^|_)key)$/i
+
+function sensitiveKey(key) {
+  return SENSITIVE.test(key)
+}
+
 function sensitivePath(value, trail = '') {
   if (!value || typeof value !== 'object') return ''
   for (const [key, child] of Object.entries(value)) {
     const next = trail ? `${trail}.${key}` : key
-    if (/(password|secret|token|authorization|cookie)$/i.test(key) && !/Env$/i.test(key)) return next
+    if (sensitiveKey(key)) return next
     const nested = sensitivePath(child, next)
     if (nested) return nested
   }
@@ -442,6 +453,7 @@ module.exports = {
   providerConfig,
   reconcile,
   safeSegment,
+  sensitiveKey,
   sensitivePath,
   sync,
   validate,

package/engine/planning/inbox.js

@@ -0,0 +1,36 @@
+'use strict'
+
+// Lo que `check` dice sobre el INBOX. Son advertencias y nunca errores: el INBOX es de la persona, y un
+// `check` rojo por lo que tiene adentro la frenaría a ella por lo que escribió un recorrido (caso 101).
+
+const path = require('node:path')
+const P = require('./parser')
+
+const FILE = 'INBOX.md'
+// Un archivo que todavía se recorre de una sentada; el molde vacío ocupa menos de treinta. La instancia
+// lo cambia en `inbox.warnLines`.
+const WARN_LINES = 300
+
+function warnings(root, done, config) {
+  const text = P.read(path.join(root, FILE))
+  if (!text.trim()) return []
+  const found = []
+  const declared = config && config.inbox && config.inbox.warnLines
+  const limit = Number.isInteger(declared) && declared > 0 ? declared : WARN_LINES
+  const count = text.replace(/\n$/, '').split('\n').length
+  if (count > limit) {
+    found.push(`${FILE}: ${count} líneas, más que el umbral de ${limit} (inbox.warnLines en ops.config.json); `
+      + 'recorrelo y borrá lo que ya se decidió')
+  }
+  // Una entrada que se llama como una tarea cerrada probablemente se promovió y nadie la borró. Es un
+  // indicio y no una prueba —el molde no obliga a que la tarea conserve el nombre del ítem—, y por eso
+  // avisa en vez de fallar (caso 106).
+  for (const name of Object.values(P.inboxHeads(root)).flat()) {
+    if (done.set.has(name)) {
+      found.push(`${FILE}: **${name}** se llama como done/${name}.md; si ya se promovió, borrala`)
+    }
+  }
+  return found
+}
+
+module.exports = { warnings }

package/engine/planning/parser.js

@@ -405,18 +405,31 @@ function readWips(dir) {
 // La plantilla no traía ningún ejemplo, así que quien escribía viñetas planas veía cero ítems sobre un
 // archivo con doce y nada se lo decía. `skipped` es lo que vuelve visible esa diferencia.
 function readInbox(dir) {
-  const result = { deuda: 0, ideas: 0, propuestas: 0, lecciones: 0, skipped: 0 }
+  const { heads, skipped } = inboxSections(dir)
+  return { ...Object.fromEntries(Object.entries(heads).map(([key, names]) => [key, names.length])), skipped }
+}
+
+// Los nombres en negrita de cada sección, que es lo que un recorrido necesita para no volver a escribir
+// lo que ya está: el nombre y no la entrada, porque pasar el archivo entero a cada tarea cuesta lo que
+// el INBOX pesa (caso 101).
+function inboxHeads(dir) {
+  return inboxSections(dir).heads
+}
+
+function inboxSections(dir) {
+  const heads = { deuda: [], ideas: [], propuestas: [], lecciones: [] }
+  let skipped = 0
   for (const part of read(path.join(dir, 'INBOX.md')).split(/^##\s+/m)) {
     const title = part.split('\n')[0]
     const bullets = (part.match(/^[-*]\s+(?:\[[ xX]\]\s+)?/gm) || []).length
-    const count = (part.match(/^[-*]\s+(?:\[[ xX]\]\s+)?\*\*/gm) || []).length
-    if (/Deuda|Ideas|Visi[oó]n|Propuestas|Lecciones/i.test(title)) result.skipped += bullets - count
-    if (/Deuda/i.test(title)) result.deuda = count
-    if (/Ideas|Visi[oó]n/i.test(title)) result.ideas = count
-    if (/Propuestas/i.test(title)) result.propuestas = count
-    if (/Lecciones/i.test(title)) result.lecciones = count
+    const names = [...part.matchAll(/^[-*]\s+(?:\[[ xX]\]\s+)?\*\*([^*\n]*)/gm)].map((hit) => hit[1].trim())
+    if (/Deuda|Ideas|Visi[oó]n|Propuestas|Lecciones/i.test(title)) skipped += bullets - names.length
+    if (/Deuda/i.test(title)) heads.deuda = names
+    if (/Ideas|Visi[oó]n/i.test(title)) heads.ideas = names
+    if (/Propuestas/i.test(title)) heads.propuestas = names
+    if (/Lecciones/i.test(title)) heads.lecciones = names
   }
-  return result
+  return { heads, skipped }
 }
 
 module.exports = {
@@ -424,5 +437,5 @@ module.exports = {
   TASK_LINE, TASK_LINE_ANY_LANE,
   read, section, withoutComments, frontmatter, readEpics, readBacklog, readDone, readWip, readWips, wipName,
   acceptanceConditions, tableRows, taskFromLine,
-  readInbox, readHumanActions,
+  readInbox, inboxHeads, readHumanActions,
 }

package/engine/planning/recurring.js

@@ -19,6 +19,10 @@ const CADENCES = { mensual: 1, trimestral: 3, semestral: 6, anual: 12 }
 
 const ID = /^[a-z0-9]+(?:-[a-z0-9]+)*$/
 const DATE = /^\d{4}-\d{2}-\d{2}$/
+// La fila que el molde trae activa escribe su `Desde` como marcador, porque la fecha depende del día en
+// que se crea la instancia y la reemplazan `init` y `upgrade`. Sin resolver sólo existe en el molde
+// mismo —el que `npm run check` valida en el toolkit—, y ahí no vence: `status` la descarta por fecha.
+const PLACEHOLDER = /^\{\{[A-Z_]+\}\}$/
 // `- **qué** AAAA-MM-DD — razón`. El nombre en negrita adelante es la misma convención del INBOX, y por
 // el mismo motivo: es con lo que se cita la fila desde otro lado.
 const POSTPONEMENT = /^-\s+\*\*([^*]+)\*\*\s+(\S+)\s+[—-]\s+(.+)$/
@@ -77,7 +81,7 @@ function validate({ exists, rows, postponements }) {
     if (!CADENCES[row.cadence]) {
       errors.push(`${at}: cadencia "${row.cadence}" fuera de ${Object.keys(CADENCES).join(' | ')}`)
     }
-    if (!DATE.test(row.since)) errors.push(`${at}: Desde debe ser AAAA-MM-DD`)
+    if (!DATE.test(row.since) && !PLACEHOLDER.test(row.since)) errors.push(`${at}: Desde debe ser AAAA-MM-DD`)
     // Se juzga la línea armada y no la celda suelta: lo que se promueve es esa línea, y quien la va a
     // leer es el mismo lector de BACKLOG. Una celda que pasa acá y una línea que BACKLOG rechaza es el
     // error que aparece un mes después, con la tarea ya pegada.
@@ -145,4 +149,11 @@ function warnings(state) {
   return lines
 }
 
-module.exports = { FILE, read, validate, status, warnings, taskLine }
+// Los marcadores de fecha del molde, resueltos para una instancia que nace hoy. `Desde` es la primera
+// fecha de vencimiento y no el día en que se declara la fila, así que va un período después: con la
+// fecha de hoy la fila nacía «vence hoy» (caso 106). Trimestral es la cadencia de la fila del molde.
+function sinceValues(today) {
+  return { '{{INBOX_SINCE}}': addMonths(today, CADENCES.trimestral) }
+}
+
+module.exports = { FILE, read, validate, status, warnings, taskLine, sinceValues }

package/engine/schemas/ops-config.schema.json

@@ -83,6 +83,15 @@
         },
         "allowPush": {
           "type": "boolean"
+        },
+        "pushToLiveBranches": {
+          "type": "array",
+          "description": "Las ramas vivas —main, master y la rama por defecto de cada remoto— en las que se puede publicar. Sin nombrarla acá, ni allowPush ni una orden en el chat llegan a una rama viva. Nombres exactos, sin patrones.",
+          "items": {
+            "type": "string",
+            "pattern": "^[^\\s*?\\[]+$"
+          },
+          "uniqueItems": true
         }
       },
       "additionalProperties": false
@@ -102,6 +111,18 @@
           "minItems": 1
         }
       }
+    },
+    "inbox": {
+      "type": "object",
+      "description": "El aviso de tamaño del INBOX. `check` advierte —nunca falla— cuando `planning/INBOX.md` pasa de este número de líneas: el INBOX es de la persona, y lo que el aviso pide es recorrerlo, no dejar de escribir.",
+      "additionalProperties": false,
+      "properties": {
+        "warnLines": {
+          "type": "integer",
+          "minimum": 1,
+          "description": "Líneas a partir de las cuales `check` avisa. Por defecto 300."
+        }
+      }
     }
   },
   "additionalProperties": false

package/package.json

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

package/template/AGENTS.md

@@ -2,7 +2,9 @@
 
 Este archivo gobierna el qué y el cuándo. `planning/PROTOCOL.md` gobierna el flujo y
 `planning/rules/` el cómo: sus reglas rigen cada tarea y se leen antes de empezar, no cuando algo sale
-mal. Los tres los mantiene Cauce y valen para cualquier proyecto. Lo que este proyecto tiene de propio
+mal. Este archivo, el protocolo y `planning/rules/system/` los mantiene Cauce y valen para cualquier
+proyecto; las reglas propias viven junto a `system/`, y donde una de ellas sobrescribe, contradice o
+restringe una del sistema, rige la del proyecto. Lo que este proyecto tiene de propio
 —su mapa, sus integraciones, hasta dónde llega la autonomía acá— vive en `organization/workspace.md`.
 
 ## Qué sabe este proyecto y no este archivo
@@ -103,9 +105,19 @@ Un guard existente **no se edita**: `upgrade` detecta el cambio y se detiene ant
 Algunos bloqueos tienen salida, y conviene saber cuál antes de necesitarla — el momento en que un guard
 te frena es el peor para elegir bien.
 
-**La salida de todos ellos es la misma**: escribir en `planning/.ops-approval` las rutas que autorizás,
-una por línea, con `#` para lo que no sea una ruta. Es un solo archivo para todos los guards, porque lo
-que escribís son rutas y quién las mira lo decide qué guard esté juzgando esa ruta.
+**Si lo pediste vos en el chat, no hace falta nada.** Los guards contienen al agente cuando decide solo o
+cuando trabaja dentro de un recorrido; lo que vos pedís directo no se frena. Nombrá lo que querés que
+toque —«borrá la prueba de altas», «reescribí la migración 004»— y pasa sin preguntarte de nuevo. Si tu
+pedido no lo nombraba y algo se frena, el agente te dice qué y por qué: contestá «dale» y pasa exactamente
+eso. Y `plan-first` no te pide un plan cuando el cambio lo pediste vos: el plan es para el trabajo que va
+por tareas. Funciona en Claude Code, Codex y Gemini, que le avisan a Cauce cuando mandás un mensaje; en
+Antigravity, y cuando nadie está en el chat —CI, un recorrido, un subagente—, queda el archivo de abajo.
+
+**Sin chat, la salida de todos ellos es la misma**: escribir en `planning/.ops-approval` las rutas que
+autorizás, una por línea, con `#` para lo que no sea una ruta. En sidecar es el `planning/` de la
+instancia y no una carpeta al lado de tus proyectos; el bloqueo dice la ruta exacta. Es un solo archivo
+para todos los guards, porque lo que escribís son rutas y quién las mira lo decide qué guard esté
+juzgando esa ruta. Lo escribís vos: si el agente intenta escribírselo, un guard lo frena.
 
 | lo que te frena | qué ruta aprobás |
 |---|---|
@@ -240,12 +252,16 @@ aprobación que pide BR-OPS-002 — `context` la nombra para que la vea una pers
 `BACKLOG.md` es esa persona.
 
 Publicar es lo único de todo eso que este proyecto puede habilitar, y `runner.allowPush` en
-`ops.config.json` es la autorización que R10 pide. Reescribir historia publicada no entra en el trato:
-un `push --force` se frena con la llave prendida o apagada.
+`ops.config.json` es la autorización que R10 pide para las ramas de trabajo. La rama viva —`main`,
+`master` o la rama por defecto del remoto— no la alcanza si el proyecto no la nombra en
+`runner.pushToLiveBranches`, y un subagente no publica con ningún permiso. Sin la llave, pasa el push
+que la persona pide en el chat nombrando el remoto y la rama, o el que ella aprueba contestando «dale».
+Reescribir historia publicada no entra en el trato: un `push --force` se frena con la llave prendida o
+apagada.
 
 Eso rige sin que nadie escriba nada. Lo que este proyecto amplíe o restrinja va en
 `organization/workspace.md`, con su razón; ninguna de esas prohibiciones se amplía ahí, y la
-publicación tampoco se decide ahí: la decide `allowPush`.
+publicación tampoco se decide ahí: la deciden `allowPush` y `pushToLiveBranches`.
 
 ## Definición de terminado
 

package/template/planning/INBOX.md

@@ -14,7 +14,8 @@ Lo que separa a las cuatro secciones es el sujeto del ítem, no su tamaño ni su
 
 - **Deuda** — un costo que ya estamos cargando en código nuestro, conocido y no bloqueante.
 - **Ideas** — una pregunta abierta, sin respuesta propuesta.
-- **Propuestas** — un cambio concreto del producto, con su evidencia y su fix propuesto.
+- **Propuestas** — un cambio concreto del producto y su fix propuesto. La evidencia no se copia acá: se
+  cita dónde vive —el `done/` de la tarea, el informe—.
 - **Lecciones** — sobre cómo trabajamos; es lo que alimenta reglas y propuestas de cargo.
 
 Ideas y Propuestas se separan por si hay una respuesta propuesta. Deuda y Propuestas, por si el costo

package/template/planning/RECURRING.md

@@ -16,7 +16,8 @@ vencimiento se calcula cuando alguien corre el CLI. Promover sigue siendo un act
 - **Cada** — vocabulario cerrado: `mensual`, `trimestral`, `semestral`, `anual`. No hay expresiones de
   cron, y esa ausencia es el enunciado: si hiciera falta una, lo que estarías declarando es otra cosa.
   Tampoco hay `semanal`, porque el slug de cada vuelta tiene grano de mes.
-- **Desde** — `AAAA-MM-DD`. Ancla la primera vuelta y después no se toca.
+- **Desde** — `AAAA-MM-DD`. Ancla la primera vuelta y después no se toca. Es la primera fecha en que
+  vence, no el día en que se escribe la fila: con la fecha de hoy nace vencida.
 - **Tarea y aceptación** — lo que se va a promover, con su aceptación observable escrita una sola vez y
   con calma. Improvisada en cada vuelta, la misma recurrencia termina significando cosas distintas sin
   que nadie lo decida.
@@ -47,12 +48,12 @@ slug son un error de `check`, y ese error llega un mes tarde.
 
 | Qué | Cada | Desde | Tarea y aceptación observable |
 |---|---|---|---|
+| inbox | trimestral | {{INBOX_SINCE}} | Recorrer el INBOX entero. _Aceptación: ninguna viñeta queda sin decisión de promover, dejar o borrar._ (service: planning) |
 
 <!--
-| deps | mensual | 2026-09-01 | Actualizar dependencias. _Aceptación: `npm outdated` no deja una versión mayor sin decisión escrita y la puerta queda verde._ |
-| accesos | trimestral | 2026-07-01 | Revisar quién tiene acceso a producción. _Aceptación: cada cuenta activa figura en `organization/`, y las demás están dadas de baja._ |
-| costos | mensual | 2026-09-01 | Revisar el gasto de infraestructura del mes. _Aceptación: cada línea que subió más de 20% tiene una razón escrita._ |
-| inbox | trimestral | 2026-08-01 | Recorrer el INBOX entero. _Aceptación: ninguna viñeta queda sin decisión de promover, dejar o borrar._ |
+| deps | mensual | 2026-09-01 | Actualizar dependencias. _Aceptación: `npm outdated` no deja una versión mayor sin decisión escrita y la puerta queda verde._ (service: .) |
+| accesos | trimestral | 2026-07-01 | Revisar quién tiene acceso a producción. _Aceptación: cada cuenta activa figura en `organization/`, y las demás están dadas de baja._ (service: organization) |
+| costos | mensual | 2026-09-01 | Revisar el gasto de infraestructura del mes. _Aceptación: cada línea que subió más de 20% tiene una razón escrita._ (service: .) |
 -->
 
 ## Postergaciones

package/template/planning/rules/system/commits.md

@@ -65,7 +65,9 @@ dice qué había que hacer, no qué se apoyaba en lo que había.
 
 Push, PR, merge, tags, deploy y rollback requieren la autorización configurada para el proyecto.
 
-De esos seis, el motor comprueba uno: el push, contra `runner.allowPush`. Reescribir historia publicada
+De esos seis, el motor comprueba uno: el push, contra `runner.allowPush` —que no llega a la rama viva
+sin `runner.pushToLiveBranches`, ni a un subagente— o contra la orden que la persona da en el chat
+nombrando el remoto y la rama. Reescribir historia publicada
 no entra en esa autorización y se frena siempre, igual que `--amend`. Los otros cinco no tienen una
 forma reconocible en un comando —un deploy es `kubectl`, `terraform`, un script o un botón— y los
 sostiene esta regla y el review, no un guard.