@ingeniomaps/cauce 0.81.0 → 0.83.0

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.81.0",
+  "version": "0.83.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
@@ -107,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.
 
@@ -250,12 +254,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/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/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/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.

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.