@ingeniomaps/cauce 0.76.0 → 0.77.0

package/CHANGELOG.md

@@ -14,6 +14,109 @@ 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.77.0] - 2026-09-10
+
+### Corregido
+
+- **`check` dice cuánto del trabajo que entró al repositorio quedó registrado.** Cuenta, por raíz de
+  trabajo, los commits que **ninguna entrada de DONE nombra** desde la última tarea cerrada. Es un aviso,
+  no un error: es un hecho del pasado que no se arregla editando nada.
+
+  El número no existía y sacarlo pedía cruzar a mano los `commit:` contra la historia de cada
+  repositorio. Hecho así sobre una instancia real: **312 commits, 75 registrados**. Y el desglose de los
+  que faltaban no era trabajo suelto — **69 `feat` y 51 `fix` de 173**—, ni tareas que produjeron varios
+  commits: de 80 entradas, una sola registra más de uno.
+
+  La ventana arranca en la última tarea cerrada y no en la primera, y esa decisión es la que hace que
+  sirva: contar toda la historia da una deuda que nunca baja y se lee como decorado. Así vuelve a cero
+  cada vez que el flujo se cierra, y lo que queda a la vista es la deriva de ahora.
+
+  **Lo que te pide algo**: si el número no es cero, ese trabajo no está en `planning/` y `OPS-001` dice
+  que ahí está la fuente de verdad. Qué hacer con él es tuyo — el aviso no propone cerrar nada
+  retroactivamente, porque escribir entradas de memoria sería inventar la evidencia que el registro
+  existe para tener.
+
+- **Un plan que ninguna crítica aprueba deja de reintentarse a ciegas.** `autobuild` cortaba con
+  `plan-rejected` sin dejar rastro, así que relanzar repetía **la corrida entera** sobre la misma tarea:
+  Ready y Decompose la volvían a dejar pasar —su criterio no cambió y la tarea tampoco— y Critique la
+  volvía a rechazar. Medido en dos corridas consecutivas: idénticas, **9 agentes y ~780 k tokens cada
+  una, sin escribir una línea de código**.
+
+  Ahora la tarea queda registrada en `HUMAN_ACTIONS.md` con el motivo, y eso hace las dos cosas de una
+  vez: `context` deja de ofrecerla —una acción pendiente saca esa tarea de la cola y ofrece la siguiente,
+  sin frenar la corrida— y alguien ve la fila. Vale igual para `plan-blocked`, que cortaba igual de mudo.
+
+  **Lo que te pide algo**: esa fila es tuya. Lo que pide R17 es mirar si la unidad son dos resultados con
+  vidas distintas y partirla, o dejarla entera con la razón escrita.
+
+- **El guard de migraciones deja de ser inerte en todo proyecto cuyas migraciones no sean `.sql`.** Filtraba
+  por ruta **y por extensión**, así que en TypeORM, Prisma, Django, Rails o Alembic no miraba nada: ni
+  frenaba el SQL destructivo, ni protegía una migración existente de ser reescrita. Y no lo decía — aparecía
+  cableado y en verde. Medido en una instancia real: **64 migraciones `.sql` cubiertas y 409 TypeORM `.ts`
+  invisibles**.
+
+  Ahora la extensión la declara el proyecto:
+
+  ```json
+  "migrations": { "extensions": ["sql", "ts"] }
+  ```
+
+  El default sigue siendo `["sql"]`, así que nada cambia para quien no lo declare — y ampliarlo por
+  nuestra cuenta reintroduciría el falso positivo que 0.63.0 vino a cerrar: un archivo de lenguaje que
+  menciona `DROP TABLE` en un comentario. La ruta la sigue fijando el motor: `migrations/`, `migration/`
+  o `migrate/`.
+
+  Y la descripción del guard dejó de prometer de más: nombra el campo que amplía la cobertura y el
+  default de quien no lo declara.
+
+  **Lo que te pide algo**: si tus migraciones no son `.sql`, declaralas. Hasta que lo hagas, ese guard
+  no las mira — y ahora `automation list-hooks` te lo dice.
+
+- **La tabla que dice qué ruta aprobar cuando un guard te frena estaba ofreciendo la salida ancha para el
+  freno más común.** `plan-first` —el que exige un plan escrito antes de cambiar el producto— no figuraba
+  entre las aprobaciones por ruta, y sí en la tabla de variables que apagan un guard **para toda la
+  sesión**. Quien se topaba con ese bloqueo encontraba documentado `OPS_PLAN_FIRST_OVERRIDE=1` y no la
+  aprobación acotada, que es la vía recomendada.
+
+  Ahora está la fila, con la pregunta que va antes —**¿esto es trabajo de una tarea?**— y con lo que
+  cuesta: si lo es, la salida no es aprobar la ruta sino escribir el WIP con su plan; si no lo es —un
+  typo, un umbral que corregís de paso—, aprobar es la respuesta correcta, y ese cambio entra **sin
+  entrada de DONE**, así que `planning/` no lo registra.
+
+  **Lo que te pide algo**: si venías apagando ese guard con la variable, la aprobación por ruta hace lo
+  mismo para el archivo que vas a tocar y se apaga sola en cuanto el conjunto cambia.
+
+### Cambiado
+
+- **R17 gana un tercer disparador de división: un plan que ninguna crítica aprueba.** Los dos que ya
+  tenía —cinco condiciones de aceptación, cuatro horas de esfuerzo— miran la unidad **escrita**. Éste mira
+  lo que pasó al intentarla, y por eso es la evidencia más directa de las tres y la única que no se puede
+  tener de antemano.
+
+  Lo que lo hace fácil de perder es que llega **después** de que las otras dos dieron el visto bueno, y
+  las dos acertaron: la aceptación era concreta y las condiciones no cruzaban el umbral. Una unidad puede
+  estar bien escrita y no ser planificable, y eso sólo se sabe habiéndolo intentado.
+
+  **Lo que te pide algo**: es una regla del sistema, así que baja a tu `planning/` en el próximo
+  `upgrade`. Como las otras dos, dispara una revisión y no una partición automática.
+
+### Agregado
+
+- **R23: un borrado se lee resuelto antes de correrlo, y sólo alcanza lo desechable.** Antes de destruir
+  —`rm -rf`, un borrado recursivo, un `DROP`, un `reset --hard`— se resuelve el objetivo y **se lee la
+  ruta final**, no la variable que la contiene. El destino tiene que colgar de algo desechable, y eso se
+  comprueba: la raíz de un repositorio, un directorio de trabajo, el home de nadie y `/` no lo son.
+
+  Con dos cosas que la regla dice y que son menos obvias. Las pruebas **no montan nada bajo el home**: un
+  banco ahí pone la carpeta personal de quien las corre dentro del alcance de todo lo que la suite borra.
+  Y **decidir se separa de destruir**: la función que juzga si algo se puede borrar no borra, así que
+  probarla con `/` o con la raíz de un repositorio no puede destruir nada. Mezcladas, la prueba que
+  ejerce la defensa tiene que apuntarle a rutas reales, y ahí apagar la defensa **es** el desastre.
+
+  **Lo que te pide algo**: es una regla del sistema, así que baja a tu `planning/` en el próximo
+  `upgrade`. Si tenés pruebas o scripts que borran, la pregunta que contesta es «¿de dónde salió esta
+  ruta?», no «¿está bien escrita esta línea?».
+
 ## [0.76.0] - 2026-09-10
 
 ### Corregido

package/automatization/workflows/autobuild.js

@@ -505,6 +505,29 @@ while (rounds++ < MAX_TASKS) {
       `\`<path>/SKILL.md\`.\n\n`
     : '')
 
+  // Un plan que no sobrevive a la crítica deja de reintentarse a ciegas. Se registra la tarea como acción
+  // humana, y eso hace dos cosas con un solo acto: `context` deja de ofrecerla —una acción pendiente saca
+  // esa tarea de la cola y ofrece la siguiente, sin frenar la corrida— y alguien ve la fila.
+  //
+  // Antes, relanzar repetía **la corrida entera**: Ready y Decompose volvían a pasarla, porque su criterio
+  // no cambió y la tarea tampoco, y Critique volvía a rechazarla. Medido en dos corridas consecutivas
+  // sobre la misma tarea: idénticas, 9 agentes y ~780 k tokens cada una, sin escribir una línea (caso 081).
+  //
+  // Es el razonamiento de `claim-stuck`: si repetir no puede cambiar el resultado, no se repite. Y la
+  // evidencia ya está completa dentro de una corrida —el rechazo llega después de una crítica, una
+  // corrección y una segunda crítica—, así que no hace falta contar entre corridas ni inventar dónde
+  // guardar ese contador: cuando esto ocurre, el WIP todavía no existe.
+  //
+  // Lo que la fila le pide a una persona lo dice R17: dos rechazos sobre lo mismo son el disparador
+  // posterior de división. No se parte acá porque partir es una decisión, y ésa no le toca al recorrido.
+  const planRejected = (reason, unit, found) => {
+    const detail = found.join('; ') || 'sin condiciones nombradas'
+    write(`Registrá ${unit.id} en ${HUMAN}: nadie pudo escribir un plan que sobreviva a la crítica. `
+      + `Motivo: ${detail}. La acción humana es revisar si la unidad son dos resultados con vidas `
+      + `distintas y partirla —R17—, o dejarla entera con la razón escrita.`, { label: 'plan-human' })
+    return stop(reason, detail)
+  }
+
   if (!planning.wipActive) {
     if (!mechanical || !vouched) {
       phase('Ready')
@@ -575,7 +598,7 @@ while (rounds++ < MAX_TASKS) {
       // Un plan bloqueado no se corrige: lo que lo bloquea está fuera de lo que una segunda pasada puede
       // tocar, así que insistir gasta dos llamadas para llegar al mismo lugar.
       if (critique.verdict === 'bloqueado') {
-        return stop('plan-blocked', blockers(critique).join('; ') || 'sin condiciones nombradas')
+        return planRejected('plan-blocked', task, blockers(critique))
       }
       if (blockers(critique).length) {
         plan = await read(
@@ -589,7 +612,7 @@ while (rounds++ < MAX_TASKS) {
         )
         if (!plan || !critique) return stop('agent-unavailable', 'la revisión del plan no devolvió resultado')
         if (critique.verdict === 'bloqueado' || blockers(critique).length) {
-          return stop('plan-rejected', blockers(critique).join('; ') || 'sin condiciones nombradas')
+          return planRejected('plan-rejected', task, blockers(critique))
         }
       }
       // Acá el plan ya está aprobado por los dos caminos posibles, así que el contraste va una sola vez.

package/engine/cli/catalog.js

@@ -105,6 +105,35 @@ function benchSurvived(dir, since) {
     + `${sample.join(', ') || '(sólo directorios)'}. ${again}. Borralo a mano y volvé a correr.`
 }
 
+// Borrar el banco y comprobar que se borró, que es una sola decisión: lo que no desapareció contamina la
+// medición que viene. Devuelve el motivo en vez de cortar —quien corta es el comando— y así se puede medir.
+//
+// **El destino se comprueba antes de destruir** (R23). `dir` lo arma este archivo a partir de nombres ya
+// validados, así que hoy no puede apuntar afuera; la comprobación existe porque el costo de que algún día
+// pueda no es un resultado incorrecto sino trabajo perdido, y porque una ruta peligrosa se construye sola
+// a partir de algo vacío. Se niega nombrando la ruta y contra qué la comparó.
+//
+// `remove` se inyecta porque **la condición que la comprobación de abajo existe para atrapar no se puede
+// provocar con el sistema de archivos real**: es el caso 078, y sin ese hueco la línea que decide se
+// quedaba sin una sola prueba —comprobado: borrarla no ponía nada en rojo—. Con un borrado que no borra,
+// la rama se ejerce en milisegundos y sobre un temporal que la prueba acaba de crear.
+function clearBench(dir, scratch, remove = fs.rmSync) {
+  const target = path.resolve(dir)
+  const banco = path.resolve(scratch)
+  if (!target.startsWith(banco + path.sep)) {
+    return `no se borra ${target}: no cuelga de ${banco}, así que no es un banco de evaluación.`
+  }
+  // El instante de arranque, para poder fechar lo que sobreviva: es lo único que separa un archivo que el
+  // borrado no tocó de uno que alguien reescribió mientras borrábamos.
+  const since = Date.now()
+  // Con reintentos. Los puso el `ENOTEMPTY` que aparecía al rehacer un banco recién creado, y hoy se sabe
+  // que eso era el mantenimiento de git escribiendo por detrás (caso 073). Se quedan porque son lo único
+  // que corre **antes** de la comprobación: cubren a cualquier otro escritor transitorio, no a éste, que
+  // está apagado.
+  remove(target, { recursive: true, force: true, maxRetries: 5, retryDelay: 50 })
+  return fs.existsSync(target) ? benchSurvived(target, since) : null
+}
+
 // Un banco de trabajo desechable donde un cargo del catálogo puede realmente trabajar.
 //
 // Hace falta porque el toolkit no es una raíz ops: el único `planning/` que vive acá es
@@ -135,48 +164,27 @@ function evaluationBench(root, agent, caso, force, kind) {
     fail(`${dir} tiene trabajo sin recoger. Guardá el registro de esa corrida antes de rehacerlo, `
       + 'o usá --force si ya lo tenés.', 2)
   }
-  // El instante de arranque, para poder fechar lo que sobreviva: es lo único que separa un archivo que
-  // el borrado no tocó de uno que alguien reescribió mientras borrábamos.
-  const since = Date.now()
-  // Con reintentos. Los puso el `ENOTEMPTY` que aparecía al rehacer un banco recién creado, y hoy se
-  // sabe que eso era el mantenimiento de git escribiendo por detrás —la causa está apagada quince líneas
-  // más abajo, en la creación—. Se quedan porque cubren a cualquier otro escritor transitorio, no porque
-  // sigan tapando éste; sacarlos es una decisión aparte y lo que la activaría es que nunca más disparen.
-  fs.rmSync(dir, { recursive: true, force: true, maxRetries: 5, retryDelay: 50 })
-  // Y se comprueba que haya borrado. `rmSync` puede volver sin lanzar y dejar cosas, y hasta acá cada
-  // síntoma se rodeaba por separado: `force` en el andamiaje, un `rm` antes del enlace. Rodearlo deja la
-  // corrida siguiendo sobre un banco que no es nuevo, y lo que falla después no dice nada del borrado: el
-  // test que lo destapó reportaba `true !== false` sobre un archivo de la corrida anterior, sin nombrar
-  // de dónde salía.
-  //
-  // Esta guarda es la que estableció la causa: fue su primer disparo instrumentado el que nombró al
-  // escritor. Se queda igual —lo que cubre ahora es que aparezca otro—.
+  // Rodear un borrado a medias deja la corrida siguiendo sobre un banco que no es nuevo, y lo que falla
+  // después no dice nada del borrado: el test que lo destapó reportaba `true !== false` sobre un archivo
+  // de la corrida anterior, sin nombrar de dónde salía. Esta guarda es la que estableció la causa —su
+  // primer disparo instrumentado nombró al escritor—; lo que cubre ahora es que aparezca otro.
   //
-  // Falla en vez de seguir, porque un banco a medio borrar contamina la medición que viene, que es lo
-  // que la recreación existe para evitar. Qué trae el mensaje y por qué, en `benchSurvived`.
-  if (fs.existsSync(dir)) fail(benchSurvived(dir, since), 2)
-  // Con `force`: el banco es desechable y se acaba de borrar, así que lo que sobreviva al `rmSync` se
-  // pisa en vez de cortar la corrida. Sin esto, `copyTemplate` se niega ante cualquier archivo que
-  // quede —«El destino contiene …/AGENTS.md»— y el mismo test falló así tres veces en un día, en las
-  // dos patas de la matriz.
-  //
-  // No ablanda ninguna protección: la pregunta «¿acá alguien trabajó?» la contesta el `git status` de
-  // arriba, que exige `--force` explícito para seguir. Esta segunda puerta no la eligió nadie y sólo
-  // se cerraba a veces, que es la clase de freno que enseña a re-correr sin leer. Ese «a veces» era el
-  // mismo escritor de fondo; con la causa apagada, esto cubre el residuo.
-  IN.scaffold(dir, { name: 'Banco de evaluación', mode: 'sidecar', quiet: true, force: true })
+  // **Y de acá para abajo el directorio no existe.** Eso es lo que sostiene que el andamiaje y el enlace
+  // se escriban sin defensas: hasta el 073, los dos llevaban una por si algo sobrevivía al borrado.
+  const problema = clearBench(dir, path.join(root, '.cauce-eval'))
+  if (problema) fail(problema, 2)
+  // Sin `force`, y eso es lo que hay que poder decir: sólo servía si algún archivo sobrevivía al borrado,
+  // y la comprobación de arriba garantiza que no queda ninguno. Lo llevaba porque el mismo test falló tres
+  // veces en un día con «El destino contiene …/AGENTS.md», y eso era el escritor de fondo que apagó el 073.
+  IN.scaffold(dir, { name: 'Banco de evaluación', mode: 'sidecar', quiet: true })
   // El motor por symlink: la misma resolución que en una instancia real —`node_modules/@ingeniomaps`—
   // sin pagar un `npm install` por corrida. El cargo llega a un banco donde el CLI funciona.
   const scope = path.join(dir, 'node_modules', '@ingeniomaps')
   fs.mkdirSync(scope, { recursive: true })
-  // El enlace se pisa por lo mismo que el andamiaje de arriba: a veces sobrevive al borrado del banco, y
-  // entonces crearlo corta la corrida con `EEXIST` en vez de rehacerlo. Es el único paso que no seguía esa
-  // regla, y el que falló en CI rehaciendo el mismo `11-otro` que ya tiene reintentos por esto.
-  //
-  // `rmSync` sobre un enlace lo quita a él y no a lo que apunta —que acá es la raíz del toolkit—, así que
-  // esto no puede llevarse por delante el repositorio.
+  // Y el enlace se crea sin borrarlo antes, por lo mismo: `scope` acaba de nacer dentro de un directorio
+  // que no existía, así que no puede haber un enlace que pisar. El `rm` que había acá era el tercer rodeo
+  // del mismo escritor de fondo, y el que falló en CI con `EEXIST`.
   const link = path.join(scope, 'cauce')
-  fs.rmSync(link, { force: true })
   fs.symlinkSync(IN.PROJECT_ROOT, link, 'dir')
 
   // El artefacto del caso, si lo tiene: la guía del proveedor que el pedido manda implementar, el CSV
@@ -398,4 +406,4 @@ function flow(action, slug, cli) {
   } catch (error) { fail(error.message, 2) }
 }
 
-module.exports = { agents, learn, evaluate, flow, benchSurvived }
+module.exports = { agents, learn, evaluate, flow, benchSurvived, clearBench }

package/engine/cli/planning.js

@@ -149,6 +149,7 @@ function check(dir, cli) {
   }))
   warnings.push(...AD.report({ done, epics, adopted }))
   warnings.push(...PC.doneCeremonyWarnings(done, new Set(adopted)))
+  warnings.push(...R.coverageWarnings(path.resolve(root, '..'), done))
   // Sin `RECURRING.md` no dice una palabra: una instancia que actualiza y no declara trabajo recurrente
   // no tiene por qué enterarse de que el contrato existe. Vencida avisa y no frena — lo que frena vive
   // en `HUMAN_ACTIONS.md`, y un aviso que salta siempre se termina apagando.

package/engine/config/validate.js

@@ -20,6 +20,7 @@ function validateOpsConfig(config) {
   // `cauceVersion` la escribe el toolkit, no la persona: registra de qué versión salió la instancia.
   const allowed = new Set([
     '$schema', 'cauceVersion', 'project', 'mode', 'workspaceRoots', 'writableOutsideRoots', 'runner',
+    'migrations',
   ])
   for (const key of Object.keys(config)) {
     if (RETIRED[key]) errors.push(`ops.config.json: ${key} ya no se usa: ${RETIRED[key]}`)
@@ -32,9 +33,41 @@ function validateOpsConfig(config) {
   validateWorkspaces(config.workspaceRoots, errors)
   validateWritable(config.writableOutsideRoots, errors)
   validateRunner(config.runner, errors)
+  validateMigrations(config.migrations, errors)
   return errors
 }
 
+// Qué cuenta como migración para el guard. Sin declararlo, sólo `.sql` — y ése es el default que hace
+// falta decir, porque un proyecto TypeORM, Prisma, Django o Rails tiene el guard cableado y en verde sin
+// que mire una sola migración (caso 077).
+//
+// La extensión se valida contra `[a-z0-9]+` por dos razones que se juntan: entra en una expresión
+// regular, así que un valor con metacaracteres la rompería o la ampliaría sin que nadie lo pidiera; y
+// declarar `.SQL` o `sql;` es un error de tipeo que conviene que se vea acá y no como cobertura que no
+// existe.
+function validateMigrations(migrations, errors) {
+  if (migrations === undefined) return
+  if (!migrations || typeof migrations !== 'object' || Array.isArray(migrations)) {
+    errors.push('ops.config.json: migrations debe ser un objeto')
+    return
+  }
+  for (const key of Object.keys(migrations)) {
+    if (key !== 'extensions') errors.push(`ops.config.json: migrations.${key} no está permitido`)
+  }
+  if (!('extensions' in migrations)) return
+  const declaradas = migrations.extensions
+  if (!Array.isArray(declaradas) || !declaradas.length) {
+    errors.push('ops.config.json: migrations.extensions debe listar al menos una extensión, o no estar')
+    return
+  }
+  for (const one of declaradas) {
+    if (typeof one !== 'string' || !/^[a-z0-9]+$/.test(one)) {
+      errors.push(`ops.config.json: migrations.extensions "${one}" debe ser la extensión sin el punto `
+        + 'y en minúscula, como "sql" o "ts"')
+    }
+  }
+}
+
 function validateWorkspaces(workspaces, errors) {
   if (!Array.isArray(workspaces) || !workspaces.length) {
     errors.push('ops.config.json: workspaceRoots debe contener al menos una raíz')

package/engine/core/repos.js

@@ -64,4 +64,59 @@ function lastCommit(repo, branch) {
   return shown.status === 0 ? shown.stdout.trim() : ''
 }
 
-module.exports = { reposFor, repoOf, lastCommit }
+// Cuánto del trabajo que entró al repositorio quedó registrado. Devuelve, por raíz, los commits que
+// ninguna entrada de DONE nombra desde la fecha que se le pase.
+//
+// Existe porque el número no se podía tener: sacarlo pedía cruzar a mano los `commit:` de `planning/done`
+// contra la historia de cada repositorio. Hecho así sobre una instancia real dio **312 commits y 75
+// registrados**, y el desglose de los que faltaban no era trabajo suelto: 69 `feat` y 51 `fix` de 173
+// (caso 082).
+//
+// Se cuenta desde una fecha y no desde el principio a propósito: contar toda la historia da una deuda que
+// nunca baja y que se termina leyendo como decorado. Desde la última tarea cerrada, en cambio, el número
+// vuelve a cero cada vez que el flujo se cierra, y lo que queda visible es la deriva de ahora.
+//
+// Los merges quedan afuera: no son trabajo, son la forma de integrarlo.
+function unrecordedCommits(repo, since, recorded) {
+  if (!repo || !since) return []
+  // La fecha se compara acá y no con `--since`, y eso lo encontró una prueba: `--since` **poda la
+  // caminata**, así que un commit con fecha vieja en la punta esconde todo lo que tiene detrás. Con un
+  // historial reescrito o un `commit --date` la cuenta daba cero sobre un repositorio lleno.
+  const log = git(repo, 'log', '--no-merges', '--date=short', '--format=%h %ad %s')
+  if (log.status !== 0) return []
+  const conocidos = new Set([...recorded].map((sha) => String(sha).slice(0, 7)))
+  return log.stdout.split('\n').map((line) => line.trim()).filter(Boolean)
+    .filter((line) => line.slice(8, 18) >= since)
+    .filter((line) => !conocidos.has(line.slice(0, 7)))
+}
+
+// Cuánto del trabajo que entró a los repositorios quedó registrado, desde la última tarea cerrada. Avisa
+// y no falla, por lo mismo que el resto de esta familia: es un hecho del pasado que no se arregla
+// editando nada, y el único camino al verde sería escribir entradas de memoria.
+//
+// La ventana arranca en la entrada más reciente y no en la primera: contar toda la historia da una deuda
+// que nunca baja y que se lee como decorado. Así el número vuelve a cero cada vez que se cierra una tarea,
+// y lo que queda a la vista es la deriva de ahora. Comprobado sobre una instancia real: **0 desde la
+// última tarea cerrada, 54 desde dos semanas antes** — el día que tuvo 64 commits y ninguna entrada.
+//
+// Y no dice cuántos *deberían* tener entrada, porque eso no se sabe desde acá: lo dice el desglose, y en
+// la instancia medida 120 de 173 eran `feat` o `fix` (caso 082).
+function coverageWarnings(opsRoot, done) {
+  const fechas = done.entries.map((entry) => entry.fecha).filter(Boolean).sort()
+  const desde = fechas[fechas.length - 1]
+  if (!desde) return []
+  const recorded = new Set()
+  for (const entry of done.entries) {
+    for (const sha of String(entry.commit || '').matchAll(/\b[0-9a-f]{7,40}\b/g)) recorded.add(sha[0])
+  }
+  const warnings = []
+  for (const repo of reposFor(opsRoot, '.')) {
+    const sueltos = unrecordedCommits(repo, desde, recorded)
+    if (!sueltos.length) continue
+    warnings.push(`${path.basename(repo)}: ${sueltos.length} commit(s) desde ${desde} que ninguna `
+      + 'entrada de DONE nombra, así que ese trabajo no está en planning/ (OPS-001)')
+  }
+  return warnings
+}
+
+module.exports = { reposFor, repoOf, lastCommit, coverageWarnings }

package/engine/hooks/files.js

@@ -171,6 +171,35 @@ function workspaceBoundary(input) {
   }
 }
 
+// Qué archivos son migraciones para este proyecto. La ruta la fija el motor —`migrations/`, `migration/`
+// o `migrate/`, que es donde las ponen todas las herramientas— y **la extensión la declara el proyecto**,
+// con `sql` de default.
+//
+// Sin esto el guard sólo veía `.sql`, así que en TypeORM, Prisma, Django, Rails o Alembic no miraba nada:
+// ni frenaba el SQL destructivo, ni protegía una migración existente de ser reescrita. Y no lo decía —
+// aparecía cableado y en verde—. Medido en una instancia real: 64 migraciones `.sql` cubiertas y **409
+// TypeORM `.ts` invisibles** (caso 077).
+//
+// No se amplía el default a `.ts`/`.py`/`.rb` por su cuenta: eso reintroduciría el falso positivo del
+// caso 039 —un archivo de lenguaje que menciona `DROP TABLE` en un comentario o en un string— por otra
+// puerta. Declararlo es opt-in porque el que sabe si sus migraciones son de lenguaje es el proyecto, y
+// porque así el costo lo elige quien lo paga.
+//
+// La extensión inválida no se descarta en silencio: descartarla dejaría al proyecto creyendo que declaró
+// una cobertura que no tiene, que es exactamente el defecto que este helper vino a cerrar. La valida
+// `validateOpsConfig`, y acá se ignora lo que no pasa ese filtro porque el guard no es el lugar donde se
+// enseña a escribir la configuración.
+const DEFAULT_MIGRATION_EXTENSIONS = ['sql']
+
+function migrationPattern(input) {
+  const root = opsRoot(input)
+  const declared = root ? (configOf(root).migrations || {}).extensions : null
+  const extensions = (Array.isArray(declared) ? declared : DEFAULT_MIGRATION_EXTENSIONS)
+    .filter((one) => typeof one === 'string' && /^[a-z0-9]+$/.test(one))
+  const usable = extensions.length ? extensions : DEFAULT_MIGRATION_EXTENSIONS
+  return new RegExp(`(?:^|/)(?:migrations?|migrate)/.*\\.(?:${usable.join('|')})$`, 'i')
+}
+
 function migrations(input) {
   if (process.env.OPS_MIGRATIONS_OVERRIDE === '1') return
   // Cada rama cierra su propio límite. Cuando el `\b` estaba al final del grupo se aplicaba a las tres, y
@@ -195,9 +224,10 @@ function migrations(input) {
   // El precio de compartir el filtro es que una migración escrita fuera de un directorio con ese nombre
   // deja de frenarse. Es deliberado: el otro chequeo ya vivía con esa convención, y dos condiciones de
   // la misma función con dos alcances distintos es lo que hizo falta arreglar acá.
+  const esMigracion = migrationPattern(input)
   for (const raw of filesOf(input)) {
     const normalized = raw.replace(/\\/g, '/')
-    if (!/(?:^|\/)(?:migrations?|migrate)\/.*\.sql$/i.test(normalized)) continue
+    if (!esMigracion.test(normalized)) continue
     if (approved(input, normalized)) continue
     if (destructiveSql.test(contentOf(input))) {
       block(`${raw} contiene SQL destructivo.\n${AP.HOW('OPS_MIGRATIONS_OVERRIDE')}`)

package/engine/hooks/run.js

@@ -108,7 +108,8 @@ const hookMetadata = [
   {
     name: 'migrations',
     event: 'PreToolUse · files',
-    purpose: 'Protege migraciones existentes y bloquea SQL destructivo sin override.',
+    purpose: 'Protege migraciones existentes y bloquea SQL destructivo, sobre las extensiones que el '
+      + 'proyecto declare en migrations.extensions — sólo .sql si no declara ninguna.',
   },
   {
     name: 'integration-snapshot',

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

@@ -86,6 +86,22 @@
         }
       },
       "additionalProperties": false
+    },
+    "migrations": {
+      "type": "object",
+      "description": "Qué cuenta como migración para el guard `migrations`. Sin esto sólo juzga `.sql`, así que en un proyecto TypeORM, Prisma, Django, Rails o Alembic el guard no mira nada.",
+      "additionalProperties": false,
+      "properties": {
+        "extensions": {
+          "type": "array",
+          "description": "Extensiones, sin el punto y en minúscula. Por defecto [\"sql\"].",
+          "items": {
+            "type": "string",
+            "pattern": "^[a-z0-9]+$"
+          },
+          "minItems": 1
+        }
+      }
     }
   },
   "additionalProperties": false

package/package.json

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

package/template/AGENTS.md

@@ -114,6 +114,7 @@ que escribís son rutas y quién las mira lo decide qué guard esté juzgando es
 | borrar o apagar una prueba | la prueba |
 | un manifiesto que va sin su lockfile, o al revés | el archivo que cambió |
 | los gates del stack en rojo, o una fuente sin regenerar | **todo** lo que está en el índice |
+| un cambio del producto sin plan escrito —el WIP en IDLE, o con la tarea puesta y ningún paso— | el archivo que vas a tocar |
 
 **Vale para ese conjunto y para ningún otro.** Si después sumás un archivo, ese archivo no está aprobado
 y el guard vuelve a frenarte nombrándolo. Eso es lo que la hace por operación sin fecha ni contador: no
@@ -126,6 +127,16 @@ mientras exista, y borrarla es parte de terminar.
 **Publicar un paquete o instalar algo global no se aprueba así**, porque ahí no hay ninguna ruta sobre
 la cual decidir. Esa sigue siendo una acción humana y su única llave es la variable de abajo.
 
+**Y la última fila tiene una pregunta antes**: ¿esto es trabajo de una tarea? Si lo es —aunque sea
+chico—, la salida no es aprobar la ruta sino escribir el WIP con su plan, y aprobar sería saltarse la
+fase que iba a mirarlo. Si no lo es —un typo en un README, un umbral que corregís de paso, «esto lo
+arreglo en dos minutos»—, aprobar la ruta **es** la respuesta correcta y no un rodeo.
+
+Lo que conviene saber antes de tomarla: ese cambio entra **sin entrada de DONE**, así que no tiene
+aceptación, ni evidencia, ni carril, ni revisión, y `planning/` no lo registra. Para un typo eso está
+bien y para lo demás casi nunca; el día que empiece a pasar seguido, el que está mal es el flujo y no
+quien aprueba la ruta.
+
 ### Las variables siguen existiendo, y son de sesión
 
 Cada guard se puede apagar entero con su variable. Hay que decir su alcance porque no es el que uno

package/template/planning/rules/README.md

@@ -6,8 +6,8 @@
   estado, medición y retomar lo interrumpido.
 - `system/code-shape.md` — R5..R7, R11, R18: simplicidad y forma del cambio.
 - `system/commits.md` — R8..R10: historia versionada y entrega.
-- `system/conduct.md` — R12..R15, R19: trato con sistemas externos, lo que llega de ellos, y la
-  obligación de entregar al negarse.
+- `system/conduct.md` — R12..R15, R19, R23: trato con sistemas externos, lo que llega de ellos, lo que
+  se destruye, y la obligación de entregar al negarse.
 
 El número es el identificador: una regla se cita por él desde un cargo, un workflow o una entrada de
 DONE, y por eso no se reordena ni se reusa.

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

@@ -52,6 +52,47 @@ cargo no tenga (R17). La pide elegir el objetivo, que es lo único que no se pue
 Esto no afloja ningún límite: no promover, no prometer fechas, no inventar evidencia y no exceder la
 autoridad del cargo siguen siendo absolutos. Lo que se cierra es la salida de cumplirlos sin entregar.
 
+## R23 — Un borrado se lee resuelto antes de correrlo, y sólo alcanza lo desechable
+
+Antes de ejecutar algo que destruye —un `rm -rf`, un borrado recursivo, un `DROP`, un `prune`, un
+`reset --hard`— se **resuelve el objetivo y se lee**. No la variable que lo contiene ni el patrón que lo
+arma: la ruta final, la que el sistema va a recibir.
+
+**El destino cuelga de algo desechable, y eso se comprueba.** Desechable es el temporal del sistema, un
+scratch declarado, un banco que se recrea en cada corrida. No lo son la raíz de un repositorio, un
+directorio de trabajo, **el home de nadie**, ni `/`. Cuando el borrado lo hace código propio la
+comprobación va en el código, y se niega **nombrando la ruta que iba a borrar y contra qué la comparó**:
+un rechazo mudo deja sin saber de qué se salvó ni por qué la ruta salió mal.
+
+Y las pruebas no son la excepción: **no montan nada bajo el home**. Un banco ahí pone la carpeta personal
+de quien las corre dentro del alcance de todo lo que la suite borra, y ahí un defecto no cuesta una
+corrida — cuesta el trabajo de alguien.
+
+**Dónde se prueba importa tanto como qué se prueba.** Un cambio que puede hacer fallar la herramienta que
+las pruebas invocan se ejercita en una copia, nunca en el árbol que contiene el trabajo. Y una mutación
+que apaga una defensa se corre en una copia **siempre**: es, literalmente, ejecutar el código sin lo que
+lo hace seguro.
+
+De ahí sale la única forma que sostiene todo lo anterior cuando falla: **decidir y destruir se separan**.
+La función que decide si algo se puede borrar no borra —recibe rutas y devuelve un motivo—, así que
+probarla con `/`, con un home o con la raíz de un repositorio no puede destruir nada. Mezcladas, la
+prueba que ejerce la defensa tiene que pasarle rutas reales y peligrosas a la función que borra, y ahí
+apagar la defensa **es** el desastre. Con eso, la propiedad que hay que poder afirmar es ésta: *ninguna
+prueba le pasa a la función que borra una ruta que no quiera perder*.
+
+Lo que vuelve traicionera a esta clase es que la ruta peligrosa **se construye sola** a partir de algo
+vacío. `path.resolve(raíz, '')` es la raíz. `rm -rf "$DIR/"*` con `DIR` sin definir es `/*`. `cd $X && rm
+-rf .` con `X` inexistente borra donde estabas. Cada línea es correcta por separado y el desastre sale de
+una salida que vino en blanco porque algo, más arriba, falló — que es exactamente lo que una prueba está
+ahí para provocar. Por eso la comprobación es del destino y no de la intención: la intención siempre es
+correcta.
+
+El costo de equivocarse no es simétrico con nada. Un borrado mal apuntado no da un resultado incorrecto
+que alguien pueda revisar: se lleva el trabajo, y con él la posibilidad de revisarlo. Sobrevive lo que
+estaba empujado; lo que nunca viaja —credenciales locales, notas, lo que todavía no se commiteó— no
+vuelve. Por eso esto no admite «pero acá es obvio que apunta bien»: si es obvio, leer la ruta resuelta
+cuesta un segundo y confirma; si no lo es, acaba de salvarte.
+
 ## R14 — Una afirmación de mecanismo lleva su registro
 
 El comportamiento de una herramienta, un motor, un formato, una norma o un sistema de terceros es material

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

@@ -48,7 +48,21 @@ Dos barras, y cada una encuentra lo que la otra deja pasar: **cinco condiciones
 tarea, y **cuatro horas de esfuerzo humano**. Arriba de la tarea el conteo sigue: siete criterios en una
 épica, nueve tareas en un hito.
 
-Ninguna de las dos decide la división: la dispara. Al cruzarla se revisa si la unidad mezcla dos
+Y hay una tercera que no se mide antes sino después: **un plan que ninguna crítica aprueba**. Las dos
+primeras miran la unidad escrita; ésta mira lo que pasó al intentarla, y por eso es la evidencia más
+directa de las tres — y la única que no se puede tener de antemano. Cuando nadie pudo escribir un plan
+que sobreviva, lo que sigue no es escribir un tercero: es mirar la unidad.
+
+Dos rechazos sobre lo mismo dicen más que dos rechazos sobre cosas distintas. Si los dos señalan la misma
+dimensión de la aceptación, ahí está la costura por donde parte. En el caso que originó esto, una crítica
+objetó cómo se probaba un número con unidades y la otra un estado que ya se cumplía: dos formas de
+comprobar dentro de una sola aceptación, que es la definición de dos resultados con vidas distintas.
+
+Lo que la hace fácil de perder es que llega **después** de que las otras dos dieron el visto bueno, y las
+dos acertaron: la aceptación era concreta y las condiciones no cruzaban el umbral. Una unidad puede estar
+bien escrita y no ser planificable, y eso sólo se sabe habiéndolo intentado.
+
+Ninguna de las tres decide la división: la dispara. Al cruzarla se revisa si la unidad mezcla dos
 resultados con vidas distintas, y recién ahí se parte, o se deja con la razón escrita —igual que R7 con
 el código—. Un número usado como límite se cumple partiendo por la mitad lo que era una sola cosa.