@ingeniomaps/cauce 0.96.0 → 0.98.0

package/engine/planning/contracts.js

@@ -383,6 +383,25 @@ function validateState({
     if (!row.valid) {
       errors.push(`HUMAN_ACTIONS ${row.task}: estado "${row.state}" fuera de `
         + `${P.HUMAN_ACTION_STATES.join(' | ')}; mientras no se entienda, la tarea queda bloqueada`)
+      continue
+    }
+    // La primera columna es a la vez lo que una persona lee y la clave con la que el motor bloquea:
+    // la selección de tarea (`state.js`) arma su conjunto de bloqueadas con ella tal cual. Esa doble
+    // función es libre a propósito —el molde manda
+    // nombrar la épica o el recorrido cuando la tarea todavía no existe— así que lo que no se puede
+    // recortar es la libertad, y lo que sí se puede es la forma intermedia: la celda que **menciona** una
+    // tarea de la cola sin ser su slug.
+    //
+    // Es la peor de las tres porque promete un bloqueo que no ocurre, y nada lo dice: la fila se escribe
+    // sin error, sale en `ops context` bajo HUMAN como si estuviera registrada, y la tarea se sigue
+    // ofreciendo. `**slug: de qué se trata**` es la que sale natural, porque esta tabla la lee una
+    // persona. Sin esto la ausencia no deja rastro, que es la forma de R15 aplicada a un mecanismo.
+    if (backlogSlugs.has(row.task)) continue
+    const casi = [...backlogSlugs].find((slug) => new RegExp(`\\b${slug}\\b`).test(row.task))
+    if (casi) {
+      errors.push(`HUMAN_ACTIONS: la fila "${row.task}" nombra a ${casi} y no bloquea nada, porque el `
+        + `motor bloquea por la primera columna exacta. Dejá "${casi}" sola ahí y contá el resto en la `
+        + 'acción, o nombrá la épica o el recorrido si lo que se frena no es esa tarea')
     }
   }
 

package/engine/planning/parser.js

@@ -176,6 +176,10 @@ function readCast(rest) {
 // devolvía `MAX` con `check` en verde, que es la forma cara del error —la tarea se lee completa y no
 // lo está—. Cierra el `_` que markdown cerraría: el que no está entre caracteres de palabra.
 const ACCEPTANCE = /_Aceptaci[oó]n:\s*(.*?\S)_(?![A-Za-z0-9])/i
+// Los paréntesis del contrato de una línea de tarea. Se enumeran por su clave y no como «cualquier
+// paréntesis» para no llevarse puesta una aclaración de la prosa: la descripción usa paréntesis igual
+// que cualquier texto, y el criterio `(→ C1)` va acá porque `criteria` ya lo extrae.
+const MARKERS = /\((?:→|->|criterios?\s|epic:|service:|cast:|depende:|sin partir:)[^)]*\)/gi
 
 // Cuántas condiciones tiene una aceptación escrita en prosa. Estuvo mucho tiempo sin contarse con una
 // razón buena —contar condiciones en una frase es una lectura, y un número inventado es peor que
@@ -207,6 +211,19 @@ function taskFromLine(line) {
     epic: ((rest.match(/\(epic:\s*(\d{3})\)/) || [])[1] || ''),
     service: ((rest.match(/\(service:\s*([^)]+)\)/) || [])[1] || '').trim(),
     acceptance,
+    // Lo que la aceptación no puede decir y alguien ya decidió: dónde vive un símbolo, qué queda fuera de
+    // alcance, con qué se produce la evidencia. Por contrato la aceptación describe estado observable del
+    // producto, así que una decisión de diseño no cabe ahí — y hasta acá tampoco salía del BACKLOG: el
+    // texto vivía en `rest` y se descartaba.
+    //
+    // Sin ella el que planifica vuelve a decidir lo ya decidido, y decide distinto. La crítica **sí** abre
+    // el BACKLOG y bloquea el plan citando la línea palabra por palabra: una compuerta juzga contra un
+    // texto que la otra no recibió. Dos corridas reales se pagaron enteras para descubrirlo, 1,10 M y
+    // 815 k tokens, la segunda con sus cuatro objeciones diciendo lo mismo (caso 177).
+    //
+    // Se recorta la aceptación y los marcadores del contrato porque cada uno ya tiene su campo: repetirlos
+    // acá los pone dos veces en el prompt de cada fase, que es lo que R16 cobra una vez por etapa.
+    description: rest.replace(ACCEPTANCE, '').replace(MARKERS, '').replace(/\s+/g, ' ').trim(),
     conditions: acceptanceConditions(acceptance),
     criteria: criteriaRefs(rest),
     // De qué otras tareas depende. El orden del BACKLOG alcanzaba mientras hubiera un runner: con dos,
@@ -388,6 +405,23 @@ function readWip(dir, runner) {
   return parseWip(read(path.join(dir, 'wip', `${name}.md`)), name)
 }
 
+// Si el checkpoint de hito sigue frenando, leído del archivo y no de que el archivo esté. Es la misma
+// forma que el WIP de acá arriba —`status: IDLE` es un estado escrito— y la razón es R28: un centinela
+// cuya única información es existir obliga a que el borrado sea parte de la resolución, y esa es una
+// convención que alguien va a olvidar. Cuando se olvida, quien revisa lee que el hito ya se revisó
+// mientras el mecanismo sigue leyendo que el archivo está, y la corrida siguiente muere en la puerta de
+// entrada habiendo cargado el estado entero.
+//
+// Cerrado por defecto (R27): frena salvo que diga `resuelta`. Un archivo de una instancia anterior no
+// trae `status`, y abrirlo por eso destrabaría en silencio al actualizar, que es la quita escrita como
+// agregado que R9 nombra. El vocabulario es el mismo de `HUMAN_ACTIONS.md` a propósito: es el mismo acto
+// —una persona contesta— y dos palabras para eso serían dos convenciones que aprender.
+function checkpointHolds(dir) {
+  const text = read(path.join(dir, 'AWAITING_REVIEW.md'))
+  if (!text) return false
+  return !/^status:\s*resuelta\b/mi.test(text)
+}
+
 // Todos los que hay. Lo pregunta `check`, que juzga si cada plan apunta a una tarea que existe, y `tree`,
 // que muestra qué está en vuelo: las dos son preguntas sobre la instancia y no sobre quien pregunta.
 function readWips(dir) {
@@ -436,6 +470,7 @@ module.exports = {
   EPIC_STATES, HUMAN_ACTION_STATES, LANES, MILESTONE_HEADING, STOP_REASONS,
   TASK_LINE, TASK_LINE_ANY_LANE,
   read, section, withoutComments, frontmatter, readEpics, readBacklog, readDone, readWip, readWips, wipName,
+  checkpointHolds,
   acceptanceConditions, tableRows, taskFromLine,
   readInbox, inboxHeads, readHumanActions,
 }

package/package.json

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

package/template/AGENTS.md

@@ -57,7 +57,7 @@ comando, sin cron —activarlo en tu repositorio es decisión tuya—:
 
 ```bash
 node tools/ops.js agents list --own          # sólo los tuyos, sin los del catálogo
-node tools/ops.js learn <slug>               # arma el informe de la semana
+node tools/ops.js learn <slug>               # arma el informe de investigación
 /agent-propose <slug>                        # escribe el cambio concreto sobre esos informes
 #   ↑ firmá «Aprobación humana» en la propuesta antes de seguir
 /agent-promote <slug>                        # lo aplica, registra y manda a verificar
@@ -108,8 +108,9 @@ te frena es el peor para elegir bien.
 **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. **Con los gates de un commit se pregunta cada vez**, como con publicar: gobernanza, los gates del
+pedido no lo nombraba y algo se frena, el agente te dice qué y por qué: confirmalo con tus palabras —un
+«dale» alcanza, pero no hace falta esa palabra— y pasa exactamente eso. Si contestás negando, frenando o
+preguntando, no pasa. **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
@@ -258,7 +259,7 @@ Publicar es lo único de todo eso que este proyecto puede habilitar, y `runner.a
 `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».
+que la persona pide en el chat nombrando el remoto y la rama, o el que ella confirma cuando se frena.
 Reescribir historia publicada no entra en el trato: un `push --force` se frena con la llave prendida o
 apagada.
 

package/template/Makefile

@@ -53,7 +53,7 @@ integration-promote: require-key ## Promueve el draft KEY=<clave> al roadmap
 require-agent:
 	@test -n "$(AGENT)" || (echo "Falta AGENT=<slug>" >&2; exit 2)
 
-agent-learn: require-agent ## Prepara el informe semanal de AGENT=<slug>
+agent-learn: require-agent ## Prepara el informe de investigación de AGENT=<slug>
 	@node tools/ops.js learn "$(AGENT)"
 
 agent-propose: require-agent ## Consolida una propuesta para AGENT=<slug>

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

@@ -3,7 +3,13 @@
 ## R8 — Un commit por naturaleza
 
 Stagear rutas explícitas, revisar el diff staged y crear un Conventional Commit en inglés. No usar
-`git add .`, `git add -A`, amend, force ni trailers de IA.
+`git add .`, `git add -A`, force ni trailers de IA.
+
+**Y no reescribir historia que otro ya leyó.** Lo que se protege es eso, no el comando: un `--amend`
+sobre un commit publicado es la misma reescritura que un force-push y se frena igual; sobre uno que no
+salió de tu máquina es la corrección, y prohibirlo no impide el resultado —`git reset --soft HEAD~1` y
+volver a commitear produce exactamente lo mismo— sino el comando que lo nombra. Una regla que se cumple
+mejor esquivándola se termina esquivando siempre.
 
 Dónde corta un commit lo decide la naturaleza del diff, no su tamaño ni un conteo. Una tarea suele
 tener una sola, y por eso un commit por tarea es lo habitual; cuando tiene dos, se hacen dos. Un
@@ -90,7 +96,8 @@ Push, PR, merge, tags, deploy y rollback requieren la autorización configurada
 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
+no entra en esa autorización y se frena siempre — también cuando la reescritura es un `--amend`, que el
+guard distingue mirando si algún remoto alcanza al commit. 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.