@ingeniomaps/cauce 0.81.0 → 0.82.0

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.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
@@ -250,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.