@ingeniomaps/cauce 0.90.0 → 0.92.0

package/CHANGELOG.md

@@ -14,6 +14,162 @@ 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.92.0] - 2026-09-15
+
+### Agregado
+
+- **El ciclo de aprendizaje ya no deja la propuesta mensual en «por definir».** Cada mes, el ciclo
+  consolida lo que recomendaron los informes semanales de un cargo y abre su propuesta. Hasta ahora la
+  dejaba con el molde intacto en «Cambio propuesto», y eso no es aprobable: nadie firma una intención.
+  Medido sobre `2026-09`: de **25** propuestas, **15** se archivaron con el molde y sólo 10 llegaron a
+  algo, las que alguien completó a mano.
+
+  El recorrido que escribe el cambio exacto —archivo por archivo, contrastado contra los casos
+  adversariales vigentes— ya existía; lo que faltaba era que el ciclo lo corriera. Ahora lo corre, y sólo
+  sobre las propuestas que quedaron sin decidir.
+
+  **Sin credencial no se rompe nada**: el paso avisa y el mes queda como quedaba antes, con la rama
+  empujada y sus sellos puestos. Lo mismo si la corrida falla. Lo que decide si se te pide una firma
+  sigue siendo el documento, no quién lo llenó.
+
+- **Tu proyecto puede declarar sus límites en una lista, y `check` avisa del que no llegue a los agentes.**
+  Los límites que tu proyecto amplía o restringe viven en `organization/workspace.md`, y de ahí viajan al
+  preámbulo de cada subagente. Hasta ahora se reconocían **por cómo arrancaba el párrafo** —«El runner»,
+  «Debe», «Nunca»—, que es la gramática del molde: un límite escrito de cualquier otra forma, que es como
+  lo escribiría cualquiera, no llegaba a ningún agente y nada lo decía. La lista salía más corta y se leía
+  igual de completa.
+
+  Ahora esa sección trae un `### Límites` con una viñeta por límite:
+
+  ```markdown
+  ### Límites
+
+  - En `api/` no se tocan migraciones sin aprobación de quien administra la base.
+  ```
+
+  **Lo que ya tenías escrito sigue contando**: la gramática vieja se lee igual, así que no hay nada que
+  migrar. Y lo que no entra por ninguno de los dos caminos ya no se pierde callado — `ops check` lo
+  reporta citando el párrafo, para que sepas cuál de tus límites se quedó afuera.
+
+  El ejemplo del molde viene comentado a propósito: un límite de ejemplo que se obedece es peor que
+  ninguno, porque nadie lo escribió y todos lo cumplirían.
+
+- **Reanudar una tarea dejó de pagar la fase que no tiene nada que hacer, y la corrida dice cuándo lo
+  hizo.** Una tarea que para antes de Commit —una revisión que pidió algo, un gate en rojo— deja su plan
+  en disco con los pasos tildados. Al relanzar, el recorrido entraba igual a Build: el agente releía el
+  WIP, comprobaba el disco y contestaba que no había nada pendiente. Hacía lo correcto; lo que costaba
+  era haberlo llamado — **893.000 tokens sobre tres corridas de una sola tarea**, medido.
+
+  Ahora, si el WIP no tiene pasos pendientes, esa llamada no se hace y la fase se anuncia como
+  `Build (reanudado)`, que viaja al resultado de la corrida y a la entrada de DONE. Antes una corrida
+  reanudada se veía idéntica a una que construyó salvo por el costo, así que comprobar qué se reutilizó
+  exigía abrir la salida cruda y sumar tokens a mano.
+
+  **Lo que no cambia es qué se revisa.** No se saltea la fase, se saltea la llamada: Review, Verify y QA
+  siguen mirando el diff real que quedó en disco, venga de la corrida que venga. Y si tu instancia no
+  emite ese dato, todo se comporta como antes.
+
+- **Una raíz puede declarar qué rutas lee su puerta, y un archivo sucio que el gate no va a abrir deja de
+  forzar la copia del índice.** Al commitear, `verify` corre sobre el árbol cuando árbol e índice
+  coinciden y materializa el índice en un temporal cuando difieren. Hasta ahora alcanzaba **cualquier**
+  archivo sin trackear para materializar: un README a medio escribir, un `tsconfig.json` que dejó otra
+  sesión, o el propio `planning/.ops-approval` que el bloqueo te manda crear para aprobar unas rutas.
+
+  Ahora, junto a `verify`, una raíz puede declarar `scope`:
+
+  ```json
+  "workspaceRoots": [
+    { "name": "web", "path": "apps/web", "verify": "pnpm build",
+      "scope": ["src/**", "package.json", "tsconfig.json"] }
+  ]
+  ```
+
+  Con eso, sólo materializa si alguna ruta que difiere cae dentro de ese alcance. Los patrones son
+  relativos a la raíz —el `scope` de `apps/web` habla de `src/**`, no de `apps/web/src/**`— y admiten
+  `*` dentro de un segmento, `**` cruzando segmentos y `?` por un carácter.
+
+  **Sin `scope` declarado no cambia nada**: cualquier delta sigue forzando la copia, que es el
+  comportamiento de siempre. El campo es opcional y no hay que adoptarlo.
+
+  Lo que se gana no es tiempo. Dentro de la copia `node_modules` viaja por **enlace**, y eso rompe
+  cualquier build de Turbopack sin salida del lado del proyecto: ahí un archivo ajeno al commit no cuesta
+  segundos, deja el gate sin poder pasar. Declarar el alcance es lo que lo destraba.
+
+  Dos bordes que valen la pena saber. Un directorio sin trackear llega colapsado —git reporta `extra/` y
+  no dice qué hay adentro—, así que se materializa igual si algún patrón apunta hacia adentro de él. Y
+  una ruta que no cuelga de **ninguna** raíz declarada también cuenta: puede ser de la instancia o de un
+  servicio que nadie declaró, y suponer que no importa es justo lo que este campo existe para evitar.
+
+### Corregido
+
+- **El motor se encuentra aunque lo hayas instalado un nivel arriba de tu instancia.** Si corrés
+  `npm install @ingeniomaps/cauce` en la carpeta de tu empresa y después `cauce init ops`, la instancia
+  queda adentro y el motor arriba. Ese es el árbol que el propio comando sugiere, y hasta ahora
+  `automation check` devolvía **nueve errores** sobre un motor que estaba instalado, cada uno mandándote a
+  correr `npm install` otra vez un nivel más abajo — o sea a bajar una segunda copia del paquete.
+
+  Ahora se busca también en la raíz que tu `ops.config.json` declara, que es la misma que el motor ya usa
+  para decidir dónde instalar el runner. Si tu `<empresa>-ops` tiene su propio `node_modules`, ése sigue
+  ganando y nada cambia.
+
+  **No se adivina el layout, se lee el declarado**: no se sube por el árbol como hace Node —en un monorepo
+  podría encontrar un motor de otra versión, en silencio— ni se mira si hay repositorio git, porque tener
+  la instancia sin versionar es un uso legítimo.
+
+  Vale para los tres caminos, no sólo para el CLI: el shim que lanza cada guard y el bridge de Antigravity
+  repiten esa búsqueda porque corren antes de poder cargar el motor, y los tres se actualizaron juntos.
+
+## [0.91.0] - 2026-09-15
+
+### Agregado
+
+- **`ops contract <ops-root> [--json]`: el contrato de tu proyecto sin pasarlo por un modelo.** Devuelve lo
+  que un recorrido necesita antes de la primera fase —cómo se llama el proyecto, dónde puede escribir, con
+  qué se verifica, qué límites rigen y qué formatos exige `planning/`—, derivado de `ops.config.json`,
+  `AGENTS.md`, `organization/workspace.md` y `planning/PROTOCOL.md`.
+
+  Los diez campos salen de parsear, así que el comando no inventa nada y cuesta cero tokens. `autobuild` los
+  derivaba con un agente que leía esos cuatro archivos y los transcribía; el comando existe para que deje de
+  hacerlo, aunque el recorrido todavía no lo use.
+
+  **Falla en vez de contestar a medias.** Si falta uno de los cuatro archivos, o si `AGENTS.md` o
+  `PROTOCOL.md` perdieron la sección de la que sale el contrato, se niega nombrando cuál y manda a correr
+  `ops upgrade`, que es quien los repone: entregar límites vacíos es peor que parar, porque un límite que no
+  llega se lee igual que uno que no existe. Que `organization/workspace.md` no declare excepciones **no** es
+  un error: es tuyo y puede no tenerlas.
+
+### Corregido
+
+- **La protección que evita que un gate te borre el `node_modules` no estaba puesta.** `verify` corre los
+  gates sobre una copia del índice con el `node_modules` enlazado a tu proyecto, y le pedía a pnpm que no
+  sincronizara dependencias antes de correr el script. Se lo pedía con un nombre que pnpm ignora: sus
+  ajustes se leen del entorno con el prefijo `pnpm_config_`, no con el de npm. La petición viajaba y se
+  descartaba en silencio desde 0.75.0, que es cuando entró.
+
+  Con pnpm 11, donde esa comprobación viene encendida, se nota al commitear un cambio de `pnpm-lock.yaml`:
+  pnpm decide reinstalar, la reinstalación **empieza borrando** el directorio de módulos —el tuyo, por el
+  enlace— y sin TTY aborta con `ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY`. Los gates vuelven en poco más
+  de un segundo, así que se leen como una suite en rojo que no lo es.
+
+  Si te está pasando, alcanza con actualizar. Lo que **no** corresponde, aunque el bloqueo lo sugiera, es
+  aprobar las rutas o `OPS_SKIP_VERIFY=1` —las dos commitean sin haber corrido el gate— ni `CI=true`, que
+  desarma justamente la confirmación con la que pnpm frena antes de purgar.
+
+- **`plan-first` decía que no tenías plan cuando lo que pasaba es que no veía el tuyo.** El guard busca el
+  WIP de tu id, y ese id sale del árbol donde corre el proceso mientras no exportes `CAUCE_RUNNER`. Con la
+  instancia al lado de dos repositorios, el mismo cambio se frenaba o pasaba según el directorio desde el
+  que saliera la llamada — y el bloqueo decía «WIP está en IDLE» con el plan escrito y a la vista, así que
+  mandaba a escribir de nuevo algo que ya existía.
+
+  Ahora distingue las dos causas: si hay un plan bajo otro id, lo nombra con su tarea y te manda a volver a
+  ese id —`ops runners <planning>` los lista— o a montar el tuyo con `ops worktree <planning> <tarea>`. Y
+  **deja de ofrecerte aprobar la ruta**, porque con un plan a la vista eso escribe por vos que el cambio no
+  es trabajo de ninguna tarea, que es falso y queda en el registro.
+
+  Lo que no cambia: el plan de otro runner sigue sin autorizarte a escribir. Si van a trabajar en paralelo,
+  cada agente necesita su árbol —`git worktree`, que es lo que `ops worktree` prepara—, y ahí el problema no
+  existe porque no comparten archivos.
+
 ## [0.90.0] - 2026-09-15
 
 ### Corregido

package/automatization/hooks/run-hook.sh

@@ -14,12 +14,12 @@ if [ -z "$hook_name" ]; then
   exit 2
 fi
 
-# La misma cascada que `packagePath` en engine/core/ownership.js, repetida acá porque el shim corre
-# antes de poder cargar el motor: si cambia allá, cambia acá.
+# Copia de `packagePath`; su porqué vive allá. Son tres los que la repiten y el motor los nombra.
 runner=""
 for candidate in \
   "$ops_root/node_modules/@ingeniomaps/cauce/engine/hooks/run.js" \
-  "$ops_root/engine/hooks/run.js"
+  "$ops_root/engine/hooks/run.js" \
+  "$ops_root/../node_modules/@ingeniomaps/cauce/engine/hooks/run.js"
 do
   if [ -f "$candidate" ]; then runner="$candidate"; break; fi
 done
@@ -27,7 +27,7 @@ done
 # Un guard que no encuentra su motor bloquea, nunca permite.
 if [ -z "$runner" ]; then
   echo "BLOQUEADO [$hook_name]: no se encontró el motor de hooks de Cauce." >&2
-  echo "  Buscado en node_modules/@ingeniomaps/cauce y engine/ bajo $ops_root" >&2
+  echo "  Buscado en node_modules/@ingeniomaps/cauce y engine/ bajo $ops_root y su carpeta padre" >&2
   exit 2
 fi
 

package/automatization/runners/antigravity/hook.js

@@ -82,9 +82,9 @@ function runtimeAt(root) {
   const candidates = [
     path.join(root, 'node_modules', '@ingeniomaps', 'cauce', 'engine', 'hooks', 'run.js'),
     path.join(root, 'engine', 'hooks', 'run.js'),
+    path.join(root, '..', 'node_modules', '@ingeniomaps', 'cauce', 'engine', 'hooks', 'run.js'),
   ]
-  // El bridge corre antes de poder cargar el motor, así que repite la cascada de
-  // engine/core/ownership.js en vez de requerirla. Si cambia una, cambian las dos.
+  // Copia de `packagePath`; su porqué vive allá. Son tres los que la repiten y el motor los nombra.
   const runtime = candidates.find(fs.existsSync)
   if (!runtime) throw new Error('No se encontró el runtime engine/hooks/run.js.')
   return require(runtime)

package/automatization/workflows/agent-eval.js

@@ -5,7 +5,7 @@
 // misma razón por la que nadie corrige su propio examen.
 //
 // Dónde trabaja el cargo lo decide el modo: en el toolkit, un banco desechable por caso; en una
-// empresa, su propia instancia. El porqué del banco está en `evaluationBench` (engine/cli/catalog.js).
+// empresa, su propia instancia. El porqué del banco está en `evaluationBench` (engine/cli/bench.js).
 // El veredicto, en cambio, se escribe siempre junto al cargo: el banco se borra, el contrato queda.
 export const meta = {
   name: 'agent-eval',

package/automatization/workflows/autobuild.js

@@ -87,6 +87,21 @@ const CONTEXT = {
     inbox: { ...INBOX_HEADS },
     // Las reglas que rigen el proyecto, con los overrides ya resueltos por el motor (caso 105).
     rules: { type: 'array', items: { type: 'string' } },
+    // Cuántos pasos del plan están tildados y cuántos no. Es lo único que separa «esta tarea viene de una
+    // corrida que paró a mitad» de «esta tarea no empezó», y sin eso Build se lanzaba igual con los nueve
+    // pasos hechos: el agente releía el WIP, miraba el disco y contestaba que no había nada pendiente —
+    // medido en 893.000 tokens sobre tres corridas de una sola tarea (caso 154).
+    //
+    // Viene de `ops context --json`, que ya lo emite; acá sólo hacía falta declararlo, porque
+    // `additionalProperties: false` lo descartaba aunque llegara. Es opcional: una instancia sin WIP
+    // activo no lo trae, y pedirlo siempre obligaría a inventar ceros donde no hay plan.
+    wip: {
+      type: 'object', additionalProperties: false, required: ['complete', 'pending'],
+      properties: {
+        phase: { type: 'string' },
+        complete: { type: 'integer' }, pending: { type: 'integer' },
+      },
+    },
   },
 }
 const CLAIM = {
@@ -290,6 +305,22 @@ const VERDICT = ' Cerrá con verdict=aprobado si no queda nada por corregir ante
 const RULED = ' En rules nombrá, por su ruta, cada una de las reglas que rigen contra la que revisaste el diff.'
 // Lo que hay que corregir antes de entregar. El resto de los hallazgos no desaparece: se registra.
 const blockers = (verdict) => verdict.concerns.filter((one) => one.blocking).map((one) => one.detail)
+// El resultado de Build cuando no hubo nada que construir en esta corrida. Devuelve lo que de verdad
+// pasó y nada más: `redFirst` y `discovered` van **vacíos** porque acá no hubo ningún rojo nuevo que
+// mostrar ni ningún borde nuevo que fijar, y rellenarlos para que se parezca a una construcción sería
+// fabricar la evidencia que este recorrido exige justamente para no tener que creerle a nadie.
+//
+// `completed: true` afirma que el plan no tiene pasos pendientes, que es lo que el WIP dice y lo único
+// que se está usando. No afirma que lo construido esté bien: eso lo miran Review, Verify y QA sobre el
+// diff real, que existe en disco venga de la corrida que venga.
+const reusedBuild = (wip) => ({
+  completed: true,
+  closedTask: false,
+  redFirst: [],
+  discovered: [],
+  summary: `sin construir en esta corrida: el WIP traía ${wip.complete} paso(s) tildado(s) y ninguno `
+    + 'pendiente, así que lo que sigue revisa lo que ya estaba en disco',
+})
 // Atajo para reconocer un gate que corrió pruebas sin preguntarle a nadie. No alcanza solo y no
 // pretende hacerlo: `mvn verify`, `gradle build`, `tox`, `bin/rails t` y cualquier `make` con nombre
 // propio corren pruebas y no se parecen a esto, así que el que corrió el comando además lo declara en
@@ -389,7 +420,8 @@ const registerHuman = async (prompt, label) => (await write(prompt, { label })
 const readContext = () => read(
   `Corré "node tools/ops.js context ${P} --json" desde ${ROOT} y reportá sólo lo que imprimió. Derivá hasTask ` +
   `de si task es null, wipActive de si wip es null, claimed del campo claimed, today y wipFile de sus ` +
-  `campos, rules del campo rules tal cual, y lane ` +
+  `campos, rules del campo rules tal cual, wip con sus campos complete y pending tal cual si viene —y ` +
+  `omitilo entero si wip es null, sin inventar ceros—, y lane ` +
   `de task.tier; copiá slug, ` +
   `hito, service, acceptance, ` +
   `epic y cast de task, epicContext de epic.context —vacío si no hay épica— e inbox tal cual. El comando es ` +
@@ -710,8 +742,25 @@ while (rounds++ < MAX_TASKS) {
     }
   }
 
-  phase('Build')
-  const build = await run(
+  // Un WIP que viene de una corrida anterior con todos sus pasos tildados no tiene nada que construir, y
+  // lanzar el agente para que lo confirme cuesta lo mismo que construir. El recorrido delegaba la
+  // reanudación en el prompt —«retomá en el primer paso pendiente»—, así que el agente hacía lo correcto
+  // y lo caro era haberlo llamado (caso 154).
+  //
+  // **La fase no se saltea: se saltea la llamada.** Los cuatro contrastes de abajo —la tarea cerrada en
+  // Build, el rojo sin su fallo literal, el borde sin prueba, las decisiones abiertas— son lo único que
+  // vuelve a mirar el disco, y darlos por buenos porque el WIP dice que está todo hecho camina al modo de
+  // fallo que registra la fase WIP acá arriba: alguien construyó todo y Review, Verify y QA no lo vieron.
+  // Por eso lo que sigue no afirma que la construcción estuvo bien, sólo que en **esta** corrida no hubo
+  // ninguna: lo que ya estaba en disco lo revisan igual las fases siguientes, sobre el diff real.
+  // Y la fase se anuncia distinto, que es la otra mitad del caso: hoy «Build corrió y construyó» y «Build
+  // corrió, miró y no hizo nada» se ven idénticos salvo por el costo, así que R21 —que manda comprobar la
+  // reanudación en vez de suponerla— no se puede cumplir sobre este recorrido sin abrir el `.output` y
+  // sumar tokens a mano. El nombre viaja por el mismo canal que las otras quince fases: entra en `ran`,
+  // que va al resultado de la corrida y a la entrada de DONE.
+  const resumed = planning.wip && planning.wip.pending === 0 && planning.wip.complete > 0
+  phase(resumed ? 'Build (reanudado)' : 'Build')
+  const build = resumed ? reusedBuild(planning.wip) : await run(
     `${asRole(cast.build)}Implementá sólo ${task.id} dentro de ${task.service}. Retomá en el primer paso ` +
     `pendiente del WIP; comprobá en el disco los pasos ya hechos y tildá cada uno que salga bien. Para cada ` +
     `comportamiento escribí primero la prueba, corréla y anotá en redFirst el test y el fallo literal que ` +

package/engine/cli/args.js

@@ -20,6 +20,8 @@ const FLAGS = {
   check: ['--json'],
   tree: ['--json', '--no-color'],
   context: ['--json', '--hito'],
+  contract: ['--json'],
+  bench: ['--force'],
   recurring: ['--json', '--promote'],
   claim: ['--json'],
   runners: ['--json'],

package/engine/cli/bench.js

@@ -0,0 +1,314 @@
+'use strict'
+
+// El banco desechable: una instancia de verdad que nace limpia, se usa una vez y se borra. Vive acá y no
+// en `core/` porque lo arma con `scaffold` y `PROJECT_ROOT`, que son del CLI, y `core/` no importa de
+// `cli/` en ningún archivo — invertir esa dirección por una herramienta del CLI sería la primera
+// excepción a una regla que el repositorio sostiene entero.
+//
+// Salió de `catalog.js` cuando dejó de tener un solo consumidor: evaluar un cargo necesita un banco, y
+// medir cualquier otra cosa también. Lo que se comparte no es la idea sino lo aprendido a los golpes —el
+// borrado que se comprueba, el `GIT_DIR` que se limpia, el mantenimiento de git que se apaga—, y eso
+// copiado se pudre en una de las dos copias.
+
+const fs = require('node:fs')
+const path = require('node:path')
+const { spawnSync } = require('node:child_process')
+const EV = require('../agents/evaluations')
+const CL = require('../planning/claims')
+const P = require('../planning/parser')
+const IN = require('./instance')
+const O = require('../core/ownership')
+const { fail, opsRoot, TODAY } = require('./io')
+
+// Qué decir cuando el banco sobrevivió a su propio borrado, que es lo único que va a permitir
+// establecer la causa. Devuelve el mensaje en vez de escribirlo donde ocurre, y eso es lo que lo hace
+// medible sin provocar el fallo; por qué eso importa acá lo dice su prueba.
+//
+// Tres cosas que el listado anterior no traía, y cada una separa dos diagnósticos distintos:
+//
+// - **Cuánto**, y no una muestra. Cortaba en cinco, así que «borró casi todo y quedaron cuatro objetos»
+//   y «no borró nada» se leían idénticos, y son problemas opuestos.
+// - **Si lo que quedó es anterior al borrado o se escribió durante.** Posterior significa que alguien
+//   reescribió mientras borrábamos; anterior, que el borrado no lo tocó. Es la pregunta central del
+//   caso y la contesta la fecha de modificación.
+// - **Qué hace un segundo borrado.** No lo rodea: quien lo llama corta igual.
+//   Distingue lo transitorio de lo permanente, que se arreglan distinto.
+function benchSurvived(dir, since) {
+  let files = 0
+  let dirs = 0
+  const sample = []
+  const walk = (base, relative = '') => {
+    for (const entry of fs.readdirSync(base, { withFileTypes: true })) {
+      const next = relative ? `${relative}/${entry.name}` : entry.name
+      if (entry.isDirectory()) { dirs += 1; walk(path.join(base, entry.name), next); continue }
+      files += 1
+      if (sample.length >= 5) continue
+      const stat = fs.statSync(path.join(base, entry.name), { throwIfNoEntry: false })
+      sample.push(`${next} (${!stat ? 'ya no está'
+        : stat.mtimeMs >= since ? 'escrito durante el borrado' : 'anterior al borrado'})`)
+    }
+  }
+  try { walk(dir) } catch { /* el listado es la explicación, no la comprobación */ }
+  let again = 'no se pudo reintentar'
+  try {
+    fs.rmSync(dir, { recursive: true, force: true, maxRetries: 5, retryDelay: 50 })
+    again = fs.existsSync(dir) ? 'un segundo borrado tampoco lo sacó' : 'un segundo borrado sí lo sacó'
+  } catch (error) { again = `un segundo borrado lanzó ${error.code || error.message}` }
+  return `${dir} no se pudo borrar entero y el banco tiene que ser nuevo. Sobrevivieron ${files} `
+    + `archivo(s) en ${dirs} directorio(s), con Node ${process.version}: `
+    + `${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 solo autor para todo banco desechable. Eran tres literales para lo mismo —el de evaluación, el de
+// medición y el del producto del sidecar—, ninguna prueba los afirmaba y la distinción no distinguía nada:
+// el commit es andamiaje, y quien mira `git log` de un banco busca qué escribió el cargo, no quién firmó.
+const AUTHOR = 'banco de cauce'
+
+// Armar el banco, que es lo que el de evaluación y el de medición comparten: de acá vuelve un directorio
+// que no existía hace un instante, con una instancia adentro y git listo para versionarla. Lo que cambia
+// entre medir un cargo y medir un comando es **qué queda adentro**, no cómo se lo prepara.
+//
+// Recrear un banco donde alguien ya trabajó borra la evidencia de esa corrida, y el registro de una
+// evaluación se escribe **desde** el banco. Pasó de verdad: se rehizo un banco para probar otra cosa y
+// con él se fue lo que el cargo había escrito; el juez leyó un directorio vacío y concluyó que la
+// respuesta afirmaba algo inexistente. Con el banco versionado, «acá se trabajó» es una pregunta que git
+// contesta exacto.
+function makeBench(root, dir, force, name) {
+  const dirty = spawnSync('git', ['-C', dir, 'status', '--porcelain'], { encoding: 'utf8' })
+  if ((dirty.stdout || '').trim() && !force) {
+    fail(`${dir} tiene trabajo sin recoger. Guardá lo que esa corrida dejó antes de rehacerlo, `
+      + 'o usá --force si ya lo tenés.', 2)
+  }
+  // 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.
+  //
+  // **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, 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. Quien use el banco llega a un lugar donde el CLI funciona.
+  //
+  // Y el enlace se crea sin borrarlo antes, por lo mismo que el andamiaje: `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 scope = path.join(dir, 'node_modules', '@ingeniomaps')
+  fs.mkdirSync(scope, { recursive: true })
+  fs.symlinkSync(IN.PROJECT_ROOT, path.join(scope, 'cauce'), 'dir')
+  // El git del banco, sin herencia. `-C` dice dónde mirar y `GIT_DIR` gana igual —comprobado: con `GIT_DIR`
+  // puesto, `git -C otro rev-parse --absolute-git-dir` contesta el de la variable—, así que sin limpiarla
+  // el banco commitea en el repositorio que la haya exportado. Es lo que hizo el caso 045 antes de
+  // arreglarse en `hooks/shell.js`: el banco de una evaluación dejó sus commits en la rama del usuario.
+  const env = { ...process.env }
+  delete env.GIT_DIR
+  delete env.GIT_WORK_TREE
+  return { env, git: (...args) => spawnSync('git', ['-C', dir, ...args], { stdio: 'ignore', env }) }
+}
+
+// Versionar el banco desde su estado limpio. Lo que garantiza: todo lo que aparezca después es obra de
+// quien usó el banco, y `git status` lo separa del andamiaje sin que nadie tenga que acordarse de qué
+// había antes. Por qué eso decide un veredicto lo mide `bench.test.js`, que trae el caso con nombre y
+// fecha. Se ignora `node_modules`: es un symlink al toolkit, no obra de nadie.
+//
+// Y se le apaga el mantenimiento automático, que es el escritor de fondo que rompía el borrado del banco
+// siguiente. `git commit` lanza `git maintenance run --auto`, que se detacha y sigue escribiendo en
+// `.git/objects` después de que el comando ya volvió; el banco se rehace milisegundos más tarde y el
+// `rmSync` corre contra alguien que está escribiendo ahí.
+//
+// Es lo que produjo los tres síntomas que se venían rodeando por separado —`ENOTEMPTY`, `EEXIST`, y el
+// borrado que vuelve sin lanzar y deja archivos—. La guarda lo nombró el 2026-09-10: `maintenance.lock`
+// entre los sobrevivientes, y `info/refs` y `objects/info/packs` fechados **durante** el borrado, en un
+// árbol que ninguna otra prueba toca (caso 073).
+//
+// `maintenance.auto=false` y no `gc.auto=0`: medido con `GIT_TRACE=1`, el segundo deja que el commit
+// lance el mantenimiento igual —sólo hace que su tarea de `gc` no encuentre trabajo— y el proceso toma su
+// lock y escribe lo mismo. Se le quita el motivo de lanzarlo, no lo que hace una vez lanzado.
+function seal(dir, git, mensaje) {
+  fs.appendFileSync(path.join(dir, '.gitignore'), '\nnode_modules/\n')
+  git('init', '-q')
+  git('config', 'user.email', 'banco@cauce.local')
+  git('config', 'user.name', AUTHOR)
+  git('config', 'maintenance.auto', 'false')
+  git('add', '-A')
+  git('commit', '-q', '-m', mensaje)
+}
+
+// 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
+// `template/planning`, el molde que se distribuye. Un cargo cuya entrega es una épica no tiene dónde
+// escribir, así que se niega —con razón—, y su caso cuenta como fallo: eso midió una configuración.
+//
+// Uno por caso, y se aprendió corriendo: con un banco compartido los casos se leen entre sí, y uno
+// tomó por «una sesión anterior de este mismo cargo» lo que otro acababa de escribir. La
+// independencia entre casos es la premisa de medir con ellos.
+//
+// Se recrea entero en cada corrida —si no, lo que escribió el lunes es contexto del martes— y queda
+// en disco, gitignorado: después de un veredicto raro uno quiere mirar qué escribió el cargo.
+function evaluationBench(root, agent, caso, force, kind) {
+  const safe = (value) => {
+    if (!/^[a-z0-9_][a-z0-9._-]*$/i.test(value) || value.includes('..')) {
+      fail(`nombre inválido para el banco: ${value}`, 2)
+    }
+    return value
+  }
+  const dir = path.join(root, '.cauce-eval', safe(agent), safe(caso || '_libre'))
+  const { git } = makeBench(root, dir, force, 'Banco de evaluación')
+
+  // El artefacto del caso, si lo tiene: la guía del proveedor que el pedido manda implementar, el CSV
+  // con instrucciones adentro. Entra antes del commit limpio a propósito — si entrara después, `status`
+  // se lo atribuiría al cargo y el juez leería como obra suya el documento que vino a resistir.
+  if (caso) {
+    const fixture = EV.fixtures(root, agent, caso, kind)
+    if (fixture.files.length) fs.cpSync(fixture.dir, dir, { recursive: true })
+  }
+
+  seal(dir, git, 'banco limpio')
+  return dir
+}
+
+// Los escenarios que una medición necesita montados, y no un banco vacío que cada una vuelva a poblar a
+// mano. De cinco bancos improvisados en una sesión, tres no midieron nada: uno con un `BACKLOG.md` cuya
+// línea el parser no acepta —`hasTasks` daba `false` y el guard medido salía por la puerta del día uno—,
+// otro sin control. Un banco que no enciende se lee igual que uno que mide, y eso no lo dice ninguna
+// salida: lo dice la ausencia de lo que se esperaba ver.
+//
+// Son tres porque son las tres formas en que una medición necesita el mundo, y cada una se agrega cuando
+// hace falta, no antes:
+//
+// - `suelto`: la instancia sola. Para medir un comando que no depende de la cola.
+// - `tarea`: con una tarea en cola, reclamada y con plan. Para los guards que miran ese estado.
+// - `sidecar`: instancia y producto en repositorios distintos, que es lo que hace falta para medir algo
+//  cuyo resultado depende de desde qué árbol se pregunte — ahí `runner()` resuelve un id distinto.
+const SCENARIOS = ['suelto', 'tarea', 'sidecar']
+
+// La línea de tarea tal como el parser la acepta, copiada del molde y no inventada: sin la aceptación
+// entre guiones bajos no es una tarea para `taskFromLine`, y el banco nacería mudo.
+const BACKLOG = `# Backlog promovido
+
+## Hito medicion — Lo que esta medición necesita en cola
+
+- [ ] **tarea-medida** [lite] — Resultado a construir. _Aceptación: conducta observable._ (service: app)
+`
+
+// Poblar el banco según el escenario. Devuelve nada: lo que importa queda en disco, y quien lo llama ya
+// tiene la ruta.
+function populate(dir, scenario, git) {
+  if (scenario === 'suelto') return
+  const planning = path.join(dir, 'planning')
+  fs.writeFileSync(path.join(planning, 'BACKLOG.md'), BACKLOG)
+  if (scenario === 'tarea') {
+    // Reclamo y WIP escritos acá y no con `ops claim`: el comando resuelve el runner desde el entorno, y
+    // un banco tiene que nacer igual lo corra quien lo corra. El id es el del banco, que es lo que
+    // `readWip` va a buscar.
+    const runner = dir
+    fs.mkdirSync(path.join(planning, 'claims'), { recursive: true })
+    fs.writeFileSync(path.join(planning, 'claims', 'tarea-medida.md'),
+      CL.content({ task: 'tarea-medida', owner: 'banco@cauce.local', runner, started: TODAY(), service: 'app' }))
+    fs.mkdirSync(path.join(planning, 'wip'), { recursive: true })
+    fs.writeFileSync(path.join(planning, 'wip', `${P.wipName(runner)}.md`),
+      '---\ntask: tarea-medida\nphase: Build\nservice: app\nlane: lite\n---\n\n'
+      + '## Plan aprobado\n1. [x] Leer lo que hay\n2. [ ] Construir lo medido\n')
+    return
+  }
+  // `sidecar`: el producto es un repositorio aparte, con su propio `.git`. Sin eso los dos lados resuelven
+  // el mismo id y el defecto que se quiere medir no aparece — pasó al reproducir el caso 152.
+  //
+  // Y va **dentro** del banco, no al lado. Afuera quedaba fuera de lo que `clearBench` alcanza, así que la
+  // instancia nacía limpia y su producto seguía con la historia de la corrida anterior: un banco a medias,
+  // que es peor que ninguno porque se lee como nuevo. Medido rehaciéndolo dos veces — la marca de la
+  // primera sobrevivía y el conteo de commits no se movía.
+  const app = path.join(dir, 'app')
+  fs.mkdirSync(path.join(app, 'src'), { recursive: true })
+  fs.writeFileSync(path.join(app, 'src', 'app.js'), 'module.exports = 1\n')
+  const config = path.join(dir, 'ops.config.json')
+  const declared = JSON.parse(fs.readFileSync(config, 'utf8'))
+  declared.workspaceRoots = [{ name: 'app', path: path.relative(dir, app) }]
+  fs.writeFileSync(config, `${JSON.stringify(declared, null, 2)}\n`)
+  const suyo = (...args) => spawnSync('git', ['-C', app, ...args], { stdio: 'ignore', env: git.env })
+  suyo('init', '-q')
+  suyo('config', 'user.email', 'banco@cauce.local')
+  suyo('config', 'user.name', AUTHOR)
+  suyo('config', 'maintenance.auto', 'false')
+  suyo('add', 'src/app.js')
+  suyo('commit', '-q', '-m', 'producto del banco')
+}
+
+// El banco de una medición. Vive junto al de evaluación —un solo lugar desechable, un solo gitignore, y
+// `clearBench` ya se niega a borrar fuera de ahí— y se distingue por el escenario, que es lo que lo puebla.
+function measurementBench(root, scenario, force) {
+  if (!SCENARIOS.includes(scenario)) {
+    fail(`escenario desconocido: ${scenario || '(ninguno)'}. Hay ${SCENARIOS.join(', ')}.`, 2)
+  }
+  const dir = path.join(root, '.cauce-eval', '_medicion', scenario)
+  const { env, git } = makeBench(root, dir, force, `Banco de medición (${scenario})`)
+  populate(dir, scenario, { env })
+  seal(dir, git, `banco de medición: ${scenario}`)
+  return dir
+}
+
+// El comando. Vive acá y no en `catalog.js` porque medir no es evaluar un cargo: comparten el banco y
+// nada más.
+//
+// Se niega fuera del toolkit por la misma razón que `--bench`: en una empresa lo que hay que medir es su
+// propia instancia, y fabricar una al lado mediría el molde en vez del proyecto. Y la ruta se imprime
+// **relativa** a la raíz por la misma razón que la de `--bench`, que está escrita donde nació, en
+// `catalog.js`.
+function bench(scenario, cli) {
+  const root = opsRoot()
+  if (O.mode(root) !== 'toolkit') {
+    fail('ops bench es del toolkit: arma un banco desechable para medir a Cauce. En una instancia, lo '
+      + 'que se mide es tu propio proyecto — corré el comando que quieras medir sobre tu planning/.', 2)
+  }
+  const dir = measurementBench(root, scenario, cli.has('--force'))
+  console.log(path.relative(root, dir))
+  // El id con el que el banco escribió su plan, porque quien mida lo necesita y deducirlo es la clase de
+  // paso que se hace mal en silencio: sin él, `context` contesta sobre otro runner y la medición mide
+  // otra cosa.
+  //
+  // Va por `stderr` y no por `stdout`, a diferencia de `ops worktree` y `ops claim`: aquéllos le hablan a
+  // una persona, y **esta salida es entrada de otra cosa**. Puesto en `stdout` el comando pasó a imprimir
+  // dos líneas, y quien resolvía la ruta se quedó con las dos concatenadas — la misma forma del caso 080,
+  // donde una salida que no era la ruta se trató como ruta.
+  if (scenario === 'tarea') console.error(`  export CAUCE_RUNNER=${dir}`)
+}
+
+// Sólo lo que otro módulo consume. `measurementBench`, `populate` y `SCENARIOS` se quedan adentro: los
+// ejercita el comando, que es como se los usa de verdad, y exportarlos para poder probarlos por separado
+// habría dejado superficie que nadie llama — que es lo que `dead-code` frena.
+module.exports = { benchSurvived, clearBench, evaluationBench, bench }