@ingeniomaps/cauce 0.20.0 → 0.22.0

package/CHANGELOG.md

@@ -8,6 +8,84 @@ esa operación sea confiable en vez de sólo cómoda: acá se lee qué cambió a
 un cambio en el protocolo, en las reglas del sistema o en un guard es visible para el usuario y sube
 minor aunque no toque una sola línea de código.
 
+## [0.22.0] - 2026-08-17
+
+### Corregido
+
+- **El juez de un caso ve lo que el cargo escribió, no sólo lo que dijo.** La respuesta de un cargo no
+  es necesariamente su entrega: pedido un webhook de pagos, `backend-engineer` contestó un resumen y
+  dejó el contrato real —orden de verificación de firma, comparación en tiempo constante, ventana
+  antirreplay, catorce pruebas— en su `INBOX.md`. El juez, leyendo sólo la respuesta, marcó esos
+  comportamientos como ausentes.
+
+  El banco pasa a ser un repositorio git commiteado en su estado limpio, así que `git status` y
+  `git diff` muestran exactamente qué produjo el cargo, separado del andamiaje. Es el cuarto hueco de
+  fidelidad del arnés, y lo abrió el arreglo anterior: antes los cargos no podían escribir, así que
+  todo lo que tenían estaba en el texto.
+
+  Medido en la corrida de tres cargos, ese acceso decidió **seis comportamientos** repartidos en tres
+  casos. Y sirve para lo inverso: para un comportamiento negativo —«no exportar ni borrar datos»— un
+  diff vacío es prueba positiva, que un texto sólo puede afirmar.
+
+- **Rehacer un banco con trabajo sin recoger se niega.** El registro de la evaluación se escribe
+  *desde* el banco, así que recrearlo antes de recogerlo destruye justo lo que se iba a anotar. Pasó:
+  se rehizo un banco probando otra cosa y con él se fue lo que un cargo había escrito. Ahora hace
+  falta `--force`.
+
+- **La suite dependía de directorios que sólo mantenían vivos unos restos.** `learning/reports/`
+  existía en cada cargo porque contenía un molde; retirados los moldes muertos, git dejó de trackearlo
+  —no versiona directorios vacíos— y desaparece en cuarenta y cinco de los cuarenta y siete cargos al
+  clonar. La prueba lo leía directo y pasaba sólo en una máquina con los restos. Verificado ahora
+  contra un clon limpio.
+
+- **El conteo de guards se deriva del registro.** `automation check` informaba «11 guards» como
+  literal mientras el motor registraba doce; quedó viejo al agregar uno y nada falló. Un número de
+  auditoría que no sale de lo que describe envejece sin avisar.
+
+### Removido
+
+- **Código muerto, ayudantes duplicados y una configuración inerte.** `template/automatization/config.json`
+  se distribuía a cada instancia y no lo leía nadie: qué guard corre lo decide la configuración del
+  runner, que es la única fuente. El README de la plantilla ahora lo dice.
+
+### Notas
+
+- **Primera medición de tres cargos del catálogo**: `product-manager` 5/5, `privacy-compliance-specialist`
+  6/6, `backend-engineer` 4/6. Sesenta y siete citas textuales sostienen los comportamientos.
+
+  Los dos fallos son reales y están descritos con su razón. Uno de ellos deja además una pregunta
+  sobre el caso, escrita en el registro en vez de escondida: `backend-engineer/06-adversarial-docs`
+  falló «verificar fuente oficial y versión aplicable» mientras el caso equivalente de
+  `privacy-compliance-specialist` pasó una versión más amplia. Si los dos deberían medir lo mismo es
+  discutible, y esa discusión va por propuesta firmada.
+
+## [0.21.0] - 2026-08-17
+
+### Corregido
+
+- **Cada caso adversarial recibe su propio banco.** Con uno por cargo, los casos corren a la vez sobre
+  el mismo `planning/` y se leen entre sí. Correr `product-manager` lo mostró sin lugar a dudas: un
+  caso tomó por «una sesión anterior de este mismo cargo» lo que otro acababa de escribir, y otro
+  construyó su respuesta entera alrededor de cuatro candidatas que en su enunciado no existían.
+
+  Ninguno de los dos cambió de veredicto, así que nada parecía roto — pero sus respuestas dejaron de
+  ser las que esos casos pedían medir, y la independencia entre casos es la premisa de medir con
+  ellos. La bandera pasa a ser `evaluate <cargo> --bench <caso>`.
+
+  Preparar un banco ya no borra el del vecino, que puede estar a mitad de corrida, y el nombre del
+  caso se valida antes de convertirse en una ruta.
+
+### Notas
+
+- **`product-manager` tiene su primera medición válida: 5 de 5.** El registro anterior se había
+  descartado por tomarse dentro del toolkit, donde el cargo no tenía dónde escribir y se negaba —con
+  razón— en los dos casos que escriben. Con el banco, esos dos pasan.
+
+  Veinte citas textuales sostienen los veinte comportamientos. Queda escrito en el propio registro lo
+  que el juez de `03-epic` dejó anotado: no se produjo ningún criterio `CN`, y bajo un estándar que
+  exigiera criterios de épica específicamente ese comportamiento caería. El caso presupone una
+  oportunidad aprobada que no existía, y el cargo se negó a inventarla.
+
 ## [0.20.0] - 2026-08-17
 
 Casi todo lo de abajo sale de la primera investigación semanal del cargo `security-engineer` corriendo

package/README.md

@@ -80,7 +80,7 @@ Lee [template/planning/PROTOCOL.md](template/planning/PROTOCOL.md) para el contr
 | `ops learn <agent>` | Prepara el informe semanal que completa la automatización de Codex. |
 | `ops learn <agent> --proposal` | Consolida informes mensuales en una propuesta sin aplicar cambios. |
 | `ops evaluate <agent>` | Valida controles, casos y propuestas del agente. |
-| `ops evaluate <agent> --bench` | Arma el banco desechable donde un cargo del catálogo trabaja. |
+| `ops evaluate <agent> --bench <caso>` | Arma el banco desechable donde un cargo trabaja ese caso. |
 | `ops team list` | Lista equipos disponibles. |
 | `ops team check <team>` | Valida manifiesto, agentes, dependencias y gates del equipo. |
 | `ops team show <team>` | Muestra el recorrido y artefactos del equipo; `--json` para consumirlo. |
@@ -192,7 +192,7 @@ de INBOX necesita un `planning/` donde escribir sea legítimo. El toolkit no lo
 el único `planning/` que vive acá es `template/planning`, el molde que se distribuye.
 
 ```bash
-node engine/cli/ops.js evaluate product-manager --bench
+node engine/cli/ops.js evaluate product-manager --bench 03-epic
 ```
 
 Devuelve la ruta de una instancia desechable —`check` pasa, el catálogo resuelve desde adentro,
@@ -200,6 +200,11 @@ Devuelve la ruta de una instancia desechable —`check` pasa, el catálogo resue
 recrea entera en cada corrida: reutilizarla dejaría que lo que un cargo escribió el lunes sea contexto
 del que responde el martes.
 
+**Una por caso**, y eso se aprendió corriendo. Con un banco compartido los casos de un cargo trabajan a
+la vez sobre el mismo `planning/` y se leen entre sí: un caso tomó por «una sesión anterior de este
+mismo cargo» lo que otro acababa de escribir, y otro evaluó cuatro candidatas que en su enunciado no
+existían. Ninguno cambió de veredicto, pero sus respuestas dejaron de ser las que el caso pedía medir.
+
 El veredicto se escribe **junto al cargo**, no en el banco. El banco se borra; el contrato queda.
 
 Desde una empresa esto no aplica: su instancia ya es el lugar, y lo que se evalúa ahí tiene que ser un