@ingeniomaps/cauce 0.75.0 → 0.77.0

package/CHANGELOG.md

@@ -14,6 +14,156 @@ 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
+
+- **Un comando que no encuentra tu planning lo dice, en vez de contestar un hecho sobre un directorio que
+  no existe.** `context` y `tree` ya lo hacían desde 0.71.0; los otros nueve no. `claim` contestaba «no
+  está en BACKLOG», `release` «no está tomada por nadie», `evidence` «DONE no tiene ninguna entrada»,
+  `runners` «ningún runner tiene trabajo abierto» — todos hechos concretos sobre lo que no pudieron leer.
+  **Cuatro de ellos salían con exit 0**, así que un script veía éxito.
+
+  El daño no es el mensaje sino lo que induce: en una corrida real, `claim` dijo «no está en BACKLOG»
+  sobre una tarea que **sí** estaba, y el recorrido mandó a una persona a promover lo único que ya estaba
+  bien, citando la regla correcta con la conclusión al revés. Ahora los once comandos que reciben un
+  planning fallan igual, con la ruta **resuelta** puesta — que es lo que hace falta cuando el error es de
+  resolución: en sidecar, `<empresa>-ops/planning` escrito desde adentro de la raíz apunta a
+  `<empresa>-ops/<empresa>-ops/planning`.
+
+  **Lo que te pide algo**: si tenías un script que trataba ese vacío como «nada que hacer», ahora falla.
+  Es la misma dirección que 0.63.0 y 0.71.0 ya tomaron. Y `ops check` sobre una ruta que no existe pasa a
+  decir eso en vez de «falta BACKLOG.md»: sale con 2 y nombra la ruta.
+
+### Agregado
+
+- **La entrada declara también `review:`, y `check` cruza los dos.** El carril dice cuánta ceremonia
+  **merecía** la tarea; `review:` dice cuánta **recibió** —el veredicto y quién revisó, o `n/a — razón`
+  cuando no corrió—. Es la dimensión que la propia ADR OPS-006 nombraba como la que falta: «se sabría
+  comparando hallazgos de review por carril, y hoy no se registra esa dimensión en DONE».
+
+  Con los dos campos, `check` avisa lo que hasta ahora no tenía cómo ver: una entrada cuyo carril convoca
+  revisor —`directo`, `lite`, `full`— y cuya revisión no corrió. `express` queda afuera porque es el único
+  que legítimamente no convoca a nadie. Avisa y no falla: es un hecho del pasado que no se arregla
+  editando la entrada, y el único camino al verde sería reescribir el registro.
+
+- **La entrada de una tarea cerrada declara `lane:`, el carril con el que corrió.** El carril decide qué
+  fases recibe una tarea —`express` se saltea Ready, Plan y QA; `full` las corre todas— y viajaba sólo en
+  la línea del BACKLOG, que **se borra al cerrar**. Con eso, «¿esta tarea recibió la ceremonia que su
+  superficie pedía?» dejaba de tener dónde contestarse: en una instancia real, **0 de 79 entradas de DONE
+  registraban el carril**. Ahora queda en el registro, y `sin clasificar` es un valor y no un hueco — dice
+  que la línea no lo declaraba, que es distinto de que nadie llenara el campo.
+
+  El plan en vuelo también lo lleva: una corrida que se reanuda arma la tarea desde `wip/<runner>.md`, y
+  sin el campo ahí llegaba al cierre con el carril ya perdido aunque la tarea sí lo tuviera.
+
+  **Lo que te pide algo**: `ops check` **avisa** cuántas entradas no lo traen y **no falla** — las
+  escritas antes de esta versión no lo tienen y no hay de dónde sacárselo. Lo que sí falla es un valor
+  inventado. Si cerrás a mano, agregá `lane:` a la entrada; si cerrás con `autobuild`, ya lo escribe.
+
 ## [0.75.0] - 2026-09-10
 
 ### Cambiado

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.
@@ -607,7 +630,8 @@ while (rounds++ < MAX_TASKS) {
       `Escribí el WIP y nada más: no toques código, no corras pruebas, no cierres la tarea y no escribas ` +
       `en DONE. Los pasos van sin tildar porque todavía no ocurrieron. task=${task.id}, ` +
       `hito=${JSON.stringify(task.hito)}, phase=Build, service=${task.service}, ` +
-      `acceptance=${JSON.stringify(task.acceptance)}, pasos sin tildar=${JSON.stringify(plan.steps)}. ` +
+      `acceptance=${JSON.stringify(task.acceptance)}, lane=${planning.lane || 'sin clasificar'}, ` +
+      `pasos sin tildar=${JSON.stringify(plan.steps)}. ` +
       `Registrá el reparto de cargos ${JSON.stringify(cast)} en las decisiones del WIP, para que después se ` +
       `pueda auditar quién revisó qué. Seguí el contrato de WIP exactamente y reportá con qué status quedó.`,
       { label: 'wip', schema: {
@@ -790,7 +814,8 @@ while (rounds++ < MAX_TASKS) {
   phase('Done')
   await write(
     `Cerrá ${task.id} de forma atómica: escribí ${doneFile(task.id)} con su evidencia —acept, ` +
-    `fecha: ${planning.today}, done, qa, tests y commit, en el formato de entrada que trae este preámbulo—; ` +
+    `fecha: ${planning.today}, done, qa, tests, commit, lane y review, en el formato de entrada que trae ` +
+    `este preámbulo—; ` +
     `sacala junto con sus notas indentadas de ${BACKLOG}; cerrá su épica sólo si no queda ` +
     `ninguna tarea etiquetada; dejá ${P}/${planning.wipFile} en status IDLE; y soltá la reserva corriendo ` +
     `"node tools/ops.js release ${P} ${task.id}". En decisions no nombres una fase ni un cargo ` +

package/engine/cli/archive.js

@@ -11,7 +11,7 @@ const P = require('../planning/parser')
 const PC = require('../planning/contracts')
 const AD = require('../planning/adoption')
 const F = require('../core/files')
-const { fail } = require('./io')
+const { fail, planningRoot } = require('./io')
 
 // La fecha de hoy, la misma que usan los comandos que leen.
 const TODAY = () => new Date().toISOString().slice(0, 10)
@@ -24,7 +24,7 @@ const TODAY = () => new Date().toISOString().slice(0, 10)
 // trabajo de arreglar, y uno que crece a mano deja de ser una lista de perdones para ser una amnistía.
 // Achicarlo sí es a mano, borrando el renglón que `check` señala.
 function adopt(dir) {
-  const root = path.resolve(dir || '.')
+  const root = planningRoot(dir)
   const target = path.join(root, AD.BASELINE)
   if (fs.existsSync(target)) {
     // Un baseline que ya trae huella no se toca: regenerarlo es exactamente lo que la huella impide.
@@ -79,7 +79,7 @@ function archiveHumanActions(root) {
 // no hace falta: sin esto contestaría «La épica debe ser NNN», que manda a corregir la forma de algo que
 // no existe.
 function archive(dir, rawNum) {
-  if (String(rawNum || '') === 'human-actions') return archiveHumanActions(path.resolve(dir || '.'))
+  if (String(rawNum || '') === 'human-actions') return archiveHumanActions(planningRoot(dir))
   return fail('Sólo se archiva `human-actions`. La evidencia de una tarea ya vive en su propio archivo '
     + 'de `done/`, así que archivar una épica dejó de tener sentido.', 2)
 }

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/claims.js

@@ -9,12 +9,12 @@ const path = require('node:path')
 const CL = require('../planning/claims')
 const R = require('../core/repos')
 const ST = require('../planning/state')
-const { fail } = require('./io')
+const { fail, planningRoot } = require('./io')
 
 const TODAY = () => new Date().toISOString().slice(0, 10)
 
 function claim(dir, slug, cli) {
-  const root = path.resolve(dir || '.')
+  const root = planningRoot(dir)
   if (!slug) return fail('Falta el slug. `ops claim <planning-dir> <tarea>`', 2)
   const state = ST.snapshot(root)
   const task = state.milestones.flatMap((milestone) => milestone.tasks).find((one) => one.slug === slug)
@@ -82,7 +82,7 @@ function claim(dir, slug, cli) {
 }
 
 function release(dir, slug) {
-  const root = path.resolve(dir || '.')
+  const root = planningRoot(dir)
   if (!slug) return fail('Falta el slug. `ops release <planning-dir> <tarea>`', 2)
   const from = CL.runner()
   const taken = CL.read(root).find((one) => one.slug === slug)
@@ -103,7 +103,7 @@ function release(dir, slug) {
 // La persona elige; el agente exporta. Pedirle a una persona que escriba una variable de entorno para
 // retomar su propio trabajo es hacerle hacer de intérprete.
 function runners(dir, cli) {
-  const root = path.resolve(dir || '.')
+  const root = planningRoot(dir)
   const done = ST.snapshot(root).done
   const abiertos = CL.read(root).filter((one) => !done.set.has(one.slug))
   const hoy = TODAY()

package/engine/cli/io.js

@@ -1,5 +1,6 @@
 'use strict'
 
+const fs = require('node:fs')
 const path = require('node:path')
 
 // Terminar la corrida con un mensaje y un código. Vive aparte porque lo usa cada familia de comandos, y
@@ -15,4 +16,32 @@ function opsRoot(dir) {
   return path.resolve(dir || process.env.OPS_ROOT || '.')
 }
 
-module.exports = { fail, opsRoot }
+// La raíz de planning de un comando: resuelta **y comprobada**, en un solo lugar. Lo que no se pudo leer
+// no contesta como si se hubiera leído, y eso no puede depender de que cada comando se acuerde: sobre un
+// directorio ausente, `claim` no encuentra el slug, `evidence` no encuentra entradas y `runners` no
+// encuentra runners, y los tres reportan ese vacío como un hecho del dominio.
+//
+// El daño no es el mensaje sino la acción que induce. Medido en una corrida real: `claim` contestó «no
+// está en BACKLOG» sobre una tarea que **sí** estaba, y el recorrido mandó a una persona a promover lo
+// único que ya estaba bien, citando la regla correcta con la conclusión al revés (caso 075). Y cuatro de
+// los ocho comandos que lo hacían salían con **exit 0**, así que un script veía éxito.
+//
+// Va en la resolución y no en cada comando porque es lo que cierra la clase en vez de la instancia: la
+// misma se arregló de a una en `stagedFiles` (0.63.0) y en `context` (0.71.0), y volvió las dos veces.
+//
+// La ruta va **resuelta** y no como se escribió, porque el error que ataca es de resolución: en sidecar
+// `<empresa>-ops/planning` desde adentro de la raíz apunta a `<empresa>-ops/<empresa>-ops/planning`.
+function planningRoot(dir) {
+  const root = path.resolve(dir || '.')
+  if (!fs.existsSync(root)) {
+    return fail(`no existe el planning en ${root} (ruta resuelta). Comprobá desde dónde estás invocando.`, 2)
+  }
+  // Existir no alcanza: un directorio cualquiera contestaría cola vacía igual. `BACKLOG.md` es el archivo
+  // del que sale la cola, así que sin él la respuesta no significa nada.
+  if (!fs.existsSync(path.join(root, 'BACKLOG.md'))) {
+    return fail(`${root} (ruta resuelta) no es un planning: falta BACKLOG.md.`, 2)
+  }
+  return root
+}
+
+module.exports = { fail, opsRoot, planningRoot }

package/engine/cli/planning.js

@@ -23,7 +23,7 @@ const OB = require('../core/onboarding')
 const C = require('../config/validate')
 const CP = require('../config/paths')
 const AG = require('../agents/catalog')
-const { fail } = require('./io')
+const { fail, planningRoot } = require('./io')
 
 // Qué dimensiones enumera el molde de `organization/` y cuáles dejaron de estar. Un agente que reescribe
 // esos archivos tiende a quedarse con el contenido y perder la estructura: el resultado se lee entero y
@@ -36,7 +36,7 @@ const { fail } = require('./io')
 // entrada de hace tres meses no tiene con qué cruzarse—. Acá se pregunta por una entrada, que es como
 // se cierra una tarea: se escribe la evidencia y se la mira contra el árbol y contra lo que corrió.
 function evidence(dir, cli) {
-  const root = path.resolve(dir || '.')
+  const root = planningRoot(dir)
   const opsDir = path.join(root, '..')
   const entries = P.readDone(root).entries
   const slug = cli.value('--task')
@@ -76,7 +76,7 @@ function evidence(dir, cli) {
 const TODAY = () => new Date().toISOString().slice(0, 10)
 
 function check(dir, cli) {
-  const root = path.resolve(dir || '.')
+  const root = planningRoot(dir)
   const errors = []
   const warnings = []
   // El plan no está: `wip/` es local y gitignoreado, así que un clon nuevo no lo trae y eso no es un
@@ -148,6 +148,8 @@ function check(dir, cli) {
     epics, milestones, done, wips, roles, humanActions: P.readHumanActions(root), adopted: new Set(adopted),
   }))
   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.
@@ -265,10 +267,9 @@ function treeJson({ epics, milestones, done, wips, inbox, queued, claims }) {
 }
 
 function tree(dir, cli) {
-  const root = path.resolve(dir || '.')
+  const root = planningRoot(dir)
   // Mismo motivo que en `context`, y por eso comparten la comprobación: sin ella un planning ausente
   // dibujaba un árbol vacío, que se lee como un roadmap sin épicas en vez de como una ruta equivocada.
-  assertPlanning(root)
   const state = ST.snapshot(root)
   if (cli.has('--json')) return treeJson(state)
   const { epics, milestones, done, wips, inbox, queued, claims } = state
@@ -307,29 +308,9 @@ function tree(dir, cli) {
   console.log(`${paint('1', 'DONE')}   ${done.entries.length} tareas\n`)
 }
 
-// Lo que no se pudo leer no contesta como si se hubiera leído: la misma regla que `stagedFiles` aplica
-// sobre el índice de git, y que esta familia ya aplicaba al `--hito` inexistente. Faltaba la raíz, y ahí
-// pesa más, porque el consumidor no siempre es una persona: `autobuild` toma la cola vacía como permiso
-// para expandir una épica, así que un error de ruta promovía trabajo en vez de fallar.
-//
-// La ruta va **resuelta** y no como se escribió, porque el error que ataca es de resolución: en sidecar
-// `<empresa>-ops/planning` desde adentro de la raíz apunta a `<empresa>-ops/<empresa>-ops/planning`.
-function assertPlanning(root) {
-  if (!fs.existsSync(root)) {
-    return fail(`no existe el planning en ${root} (ruta resuelta). Comprobá desde dónde estás invocando.`, 2)
-  }
-  // Existir no alcanza: un directorio cualquiera contestaría cola vacía igual. `BACKLOG.md` es el archivo
-  // del que sale la cola, así que sin él la respuesta no significa nada.
-  if (!fs.existsSync(path.join(root, 'BACKLOG.md'))) {
-    return fail(`${root} (ruta resuelta) no es un planning: falta BACKLOG.md.`, 2)
-  }
-  return null
-}
-
 // Contexto mínimo suficiente para ejecutar una tarea, en lugar de releer roadmap, BACKLOG y WIP enteros.
 function context(dir, cli) {
-  const root = path.resolve(dir || '.')
-  assertPlanning(root)
+  const root = planningRoot(dir)
   const state = ST.snapshot(root)
   // Acotar la cola a un hito es como un equipo se reparte trabajo sin coordinarse: dos personas en hitos
   // distintos casi nunca dependen entre sí ni tocan los mismos archivos. Lo que se acota es qué se
@@ -473,7 +454,7 @@ function context(dir, cli) {
 // `BACKLOG.md` es la cola de lo aprobado y la escribe una persona — ningún comando del motor la toca,
 // ni siquiera `integration promote`, que aterriza en el roadmap. Pegarla es el acto de promoción.
 function recurring(dir, cli) {
-  const root = path.resolve(dir || '.')
+  const root = planningRoot(dir)
   const file = RC.read(root)
   if (!file.exists) return console.log(`= este planning no declara trabajo recurrente (${RC.FILE})`)
   const state = RC.status({ ...file, done: P.readDone(root), today: TODAY() })

package/engine/cli/worktree.js

@@ -15,7 +15,7 @@ const ST = require('../planning/state')
 const CL = require('../planning/claims')
 const R = require('../core/repos')
 const O = require('../core/ownership')
-const { fail } = require('./io')
+const { fail, planningRoot } = require('./io')
 
 const git = (cwd, ...args) => spawnSync('git', args, { cwd, encoding: 'utf8' })
 
@@ -33,7 +33,7 @@ function existing(repo, branch) {
 }
 
 function worktree(dir, slug, cli) {
-  const root = path.resolve(dir || '.')
+  const root = planningRoot(dir)
   if (!slug) return fail('Falta el slug. `ops worktree <planning-dir> <tarea>`', 2)
   const state = ST.snapshot(root)
   const task = state.milestones.flatMap((milestone) => milestone.tasks).find((one) => one.slug === slug)

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/planning/contracts.js

@@ -87,6 +87,12 @@ function validateDoneEntry(entry, cited = []) {
 //
 // Los criterios que la historia declaró cubrir los cita el roadmap y no la entrada, así que el cruce
 // sólo existe si la entrada dice de qué épica viene.
+// El vocabulario del carril tal como se escribe en una entrada de DONE: los cuatro de la línea del
+// BACKLOG más el que dice que la línea no lo declaraba. `sin clasificar` no es un hueco disimulado — es
+// el estado que `PROTOCOL.md` ya llama estado y no error, y escribirlo distingue «corrió sin carril» de
+// «nadie escribió el campo», que es justo lo que este campo vino a poder contestar.
+const LANE_VALUES = [...P.LANES, 'sin clasificar']
+
 function doneEntryErrors(entry, epics = []) {
   const at = `${entry.source} ${entry.slug}`
   const errors = []
@@ -97,11 +103,58 @@ function doneEntryErrors(entry, epics = []) {
   if (!entry.done) errors.push(`${at}: falta done:`)
   if (!entry.qa) errors.push(`${at}: falta qa:`)
   if (!entry.commit) errors.push(`${at}: falta commit:`)
+  // El carril con el que la tarea corrió. Ausente **avisa** y no frena, porque toda entrada escrita antes
+  // de que el campo existiera lo está y no hay de dónde sacárselo: exigirlo pondría en rojo el `check` de
+  // cada instancia que actualiza, por algo que nadie puede arreglar. Escrito mal sí frena, porque eso es
+  // un valor que alguien puso y de él depende leer si la ceremonia fue la que correspondía (OPS-006).
+  if (entry.lane && !LANE_VALUES.includes(entry.lane)) {
+    errors.push(`${at}: lane "${entry.lane}" no existe; usá ${LANE_VALUES.join(' | ')}`)
+  }
   const story = epics.find((epic) => epic.num === entry.epic)?.stories
     .find((candidate) => candidate.slug === entry.slug)
   return [...errors, ...validateDoneEntry(entry, story ? story.criteria : [])]
 }
 
+// Un carril declara **cuánta ceremonia** merecía la tarea; `n/a` en `review:` dice que la revisión no
+// corrió. `express` es el único que no convoca revisor, así que en los otros tres esa combinación es la
+// ADR incumplida, escrita en el propio registro.
+const CONVOCAN_REVISOR = ['directo', 'lite', 'full']
+const SIN_REVISION = /^n\/a\b/i
+
+// Lo que el registro puede decir sobre la ceremonia, y lo que todavía no. Los dos campos avisan en vez de
+// fallar por lo que dice `doneEntryErrors`, y cuentan en vez de listar porque al principio son todas: lo
+// que se lee es que el número baje. Cuando llegue a cero, exigirlos deja de costarle nada a nadie.
+//
+// El cruce sí nombra las tareas, porque son pocas y cada una es una pregunta concreta para una persona.
+// Y también avisa en vez de fallar, por una razón distinta de la de los campos: es un hecho del pasado
+// que no se arregla editando la entrada, así que el único camino al verde sería reescribir el registro.
+// Un gate que se apaga mintiendo es peor que no tenerlo.
+//
+// `sin clasificar` queda afuera del cruce a propósito: el recorrido corre esas tareas por el carril
+// completo, pero eso lo sabe el recorrido y no la entrada. Avisar sobre lo que hay que deducir es lo que
+// llena de ruido un aviso que después nadie mira.
+function doneCeremonyWarnings(done, adopted = new Set()) {
+  const propias = done.entries.filter((entry) => !adopted.has(entry.slug))
+  const warnings = []
+  const sinLane = propias.filter((entry) => !entry.lane)
+  if (sinLane.length) {
+    warnings.push(`planning/done: ${sinLane.length} entrada(s) sin lane:, así que no se puede comprobar `
+      + 'sobre el registro que la ceremonia que recibieron fue la que su superficie pedía (OPS-006)')
+  }
+  const sinReview = propias.filter((entry) => !entry.review)
+  if (sinReview.length) {
+    warnings.push(`planning/done: ${sinReview.length} entrada(s) sin review:, que es la dimensión con la `
+      + 'que OPS-006 dice que se mide si el carril elegido fue el correcto')
+  }
+  const saltadas = propias.filter((entry) => CONVOCAN_REVISOR.includes(entry.lane)
+    && entry.review && SIN_REVISION.test(entry.review))
+  if (saltadas.length) {
+    warnings.push(`planning/done: ${saltadas.map((entry) => entry.slug).join(', ')} declara(n) un carril `
+      + 'que convoca revisor y una revisión que no corrió: el carril reduce ceremonia, nunca evidencia')
+  }
+  return warnings
+}
+
 function duplicates(values) {
   return [...new Set(values.filter((value, index) => values.indexOf(value) !== index))]
 }
@@ -308,6 +361,7 @@ function validateState({
 module.exports = {
   validateState,
   doneEntryErrors,
+  doneCeremonyWarnings,
   validCommitTrace,
   validDecisionTrace,
   validTestTrace,

package/engine/planning/parser.js

@@ -254,7 +254,7 @@ function doneFiles(dir) {
 
 // `fecha` entra al vocabulario porque un campo que no esté acá no corta al anterior: sin nombrarlo, el
 // `done:` de la entrada se lo tragaría entero como parte de su propio texto.
-const DONE_FIELDS = 'acept|fecha|done|qa|tests|decisions|commit'
+const DONE_FIELDS = 'acept|fecha|done|qa|tests|decisions|commit|lane|review'
 
 // Un campo vale hasta el próximo campo, una línea en blanco o el fin de la entrada. Mismo corte que ya
 // se arregló para los criterios y las historias, con el mismo síntoma: el valor es prosa y se envuelve a
@@ -287,7 +287,8 @@ function readDone(dir) {
         epic: ((match[2].match(/\(epic:\s*(\d{3})\)/) || [])[1] || ''),
         acceptance: field('acept'), fecha: field('fecha'),
         done: field('done'), qa: field('qa'), tests: field('tests'),
-        decisions: field('decisions'), commit: field('commit'),
+        decisions: field('decisions'), commit: field('commit'), lane: field('lane'),
+        review: field('review'),
         source: path.relative(dir, file), raw: match[0].trimEnd(),
       })
     }
@@ -370,6 +371,10 @@ function parseWip(text, runner) {
   if (!task) return null
   return {
     task, runner, phase: field('phase') || '?', service: field('service'),
+    // El carril viaja en el WIP porque la línea del BACKLOG deja de existir al cerrar, y sin esto una
+    // corrida que se reanuda llega al cierre con el carril ya perdido: `currentTask` arma la tarea desde
+    // el WIP y le pone `tier` vacío. Medido — la tarea reanudada devolvía `""` (caso 074).
+    lane: field('lane'),
     complete: (text.match(/^\d+\.\s+\[[xX]\]/gm) || []).length,
     pending: (text.match(/^\d+\.\s+\[\s\]/gm) || []).length,
   }

package/engine/planning/state.js

@@ -50,7 +50,7 @@ function currentTask({ milestones, done, wips = [], claims = [] }, blockers = []
   if (wip) {
     const active = queue.find((task) => task.slug === wip.task)
       || {
-        slug: wip.task, hito: '', tier: '', cast: { build: '', review: [] },
+        slug: wip.task, hito: '', tier: wip.lane || '', cast: { build: '', review: [] },
         service: wip.service, acceptance: '', epic: '', criteria: [],
       }
     return { task: active, claimed: mine.has(wip.task), skipped: [], taken: [], waiting: [] }

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.75.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/PROTOCOL.md

@@ -13,7 +13,14 @@ invariantes.
   opcionales: sin ellos la tarea está sin clasificar, que es un estado y no un error. Una tarea con
   dependencias no se ofrece ni se toma hasta que todas estén en DONE.
 - DONE: un archivo por tarea cerrada, `done/<slug>.md`, con su entrada `[x]` y los campos `acept:`,
-  `fecha:` en AAAA-MM-DD, `done:`, `qa:`, `tests:` y `commit:`. La fecha es la del cierre, y es lo que
+  `fecha:` en AAAA-MM-DD, `done:`, `qa:`, `tests:`, `commit:` y `lane:`. `lane:` repite el carril con el
+  que la tarea corrió —`express`, `directo`, `lite`, `full`— o `sin clasificar` si su línea no lo
+  declaraba, y existe porque el carril decide qué fases corren y su línea del BACKLOG se borra al cerrar:
+  sin él, si una tarea recibió la ceremonia que le tocaba sólo lo sabe quien estuvo en la sesión.
+  `check` avisa cuántas entradas no lo traen y falla si trae un valor que no existe. `review:` dice qué
+  pasó con la revisión —el veredicto y quién revisó— o `n/a — razón` cuando no corrió; es la dimensión con
+  la que OPS-006 dice que se mide si el carril elegido fue el correcto, y `check` cruza los dos: un carril
+  que convoca revisor con una revisión que no corrió es la ADR incumplida, escrita en el propio registro. La fecha es la del cierre, y es lo que
   ordena una evidencia que ya no depende de su posición dentro de un archivo. `tests:` enlaza cada criterio
   mediante `CN → prueba`; usa `A → prueba` cuando no hay épica o `n/a — razón` si no existe una
   superficie ejecutable. `decisions:` es opcional y, si aparece, cita `[fuente: ...]` o

package/template/planning/done/README.md

@@ -12,6 +12,8 @@ tarea entregó y con qué se comprueba.
   tests: C1 → nombre de prueba o comando; C2 → nombre de prueba o comando
   decisions: decisión no obvia [fuente: ruta/archivo] o [supuesto: motivo verificable]
   commit: abc1234 feat(scope): subject (repo@branch)
+  lane: full
+  review: aprobado por tech-lead, sobre api/alta.go
 ```
 
 El contrato completo de esos campos está en `../PROTOCOL.md`; acá va por qué el archivo es uno por tarea.
@@ -27,6 +29,27 @@ El nombre del archivo es una conveniencia; lo que identifica la tarea es el slug
 el archivo no cambia de qué tarea habla, y cerrar dos veces la misma sigue siendo un error que `check`
 rechaza, ahora entre archivos.
 
+## Por qué el carril
+
+El carril decide qué fases corre una tarea: `express` se saltea Ready, Plan y QA; `full` las corre
+todas. Ese dato vive en la línea del BACKLOG, y la línea **se borra al cerrar** — así que la pregunta
+«¿esta tarea recibió la ceremonia que su superficie pedía?» dejaba de tener dónde contestarse, y quedaba
+en la memoria de quien estuvo en la sesión. `lane:` la devuelve al registro.
+
+Se escribe aunque sea `sin clasificar`, que es distinto de no escribirlo: uno dice que la tarea corrió
+sin carril declarado y el otro, que nadie llenó el campo.
+
+## Por qué la revisión
+
+El carril dice cuánta ceremonia **merecía** la tarea; `review:` dice cuánta **recibió**. Con los dos, la
+pregunta que OPS-006 dejó pendiente —«¿el carril elegido fue el correcto?»— se contesta desde el registro
+en vez de desde la memoria de la sesión.
+
+`express` es el único carril que no convoca revisor, así que ahí `n/a — razón` es lo correcto. En
+`directo`, `lite` y `full` una revisión que no corrió es la ADR incumplida, y `check` lo avisa nombrando
+la tarea. Avisa y no falla: es un hecho del pasado que no se arregla editando la entrada, y el único
+camino al verde sería reescribir el registro.
+
 ## Por qué la fecha
 
 Mientras las entradas vivían en un archivo, «la última» era la última del archivo. Con archivos sueltos

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.
 

package/template/planning/wip/README.md

@@ -12,6 +12,7 @@ phase: Build
 started: AAAA-MM-DD
 service: ruta
 acceptance: "criterio observable"
+lane: full
 ---
 
 ## Plan aprobado
@@ -24,6 +25,10 @@ acceptance: "criterio observable"
 - (ninguno)
 ```
 
+`lane:` viaja acá por la misma razón por la que existe en DONE: la línea del BACKLOG se borra al
+cerrar, y una corrida que se reanuda arma la tarea desde este archivo. Sin el campo, el cierre de una
+corrida reanudada escribe `sin clasificar` sobre una tarea que sí tenía carril.
+
 Sin archivo, el runner está en IDLE: un clon nuevo no trae ninguno y eso no es un error.
 
 ## Por qué uno por runner y no uno solo