@zhivex-ai/harness 1.0.0 → 1.1.0-rc.3

package/docs/reports/GA_VALIDATION_2026-09-19.md

@@ -1,111 +0,0 @@
-# Validación externa automatizada de GA — 19 de septiembre de 2026
-
-**Veredicto: NO-GO para RC.14 / promoción a 1.0.0.** Se reproduce un bloqueo
-funcional de los flujos de varios turnos de Meta y OpenAI con el presupuesto
-predeterminado. La suite existente pasa, pero no detecta esta combinación.
-
-Evaluador: Codex, actuando como validador externo automatizado por pedido del
-operador. Este informe no es una firma humana, una auditoría integral de seguridad
-ni evidencia de publicación. No se modificaron el runtime ni los criterios de GA.
-
-## Identidad y reproducibilidad
-
-- Commit: `28723ff3350b7572d5bd68f2d40b6feef1e0e6b4`.
-- Versión: `1.0.0-rc.14`; Bun 1.4.0, Node 22.21.0, macOS arm64.
-- Se exportó el commit con `git archive` y se instaló su lockfile con
-  `bun install --frozen-lockfile --ignore-scripts` en una carpeta temporal aislada.
-- El checkout original tenía dependencias desactualizadas y después recibió
-  cambios concurrentes en `package.json`, `bun.lock` y `node_modules`. Los
-  resultados definitivos proceden de la copia aislada; no certifican esos cambios.
-- [Evidencia estructurada](evidence/ga-validation-2026-09-19.json): resultados,
-  hash del tarball local, versiones, CI y diagnósticos sin contenido de proveedores.
-- El tarball local pasó inspección de contenido e instalación independiente de
-  esos mismos bytes. No tiene identidad de release protegida ni provenance npm.
-
-## Resultados ejecutados
-
-| Frontera | Resultado |
-| --- | --- |
-| `ZHIVEX_HARNESS_OCI_REQUIRED=1 bun run check` | PASS, salida 0 en copia aislada |
-| Suite existente | 512/512 tests, 59 archivos |
-| Docs, contratos de preparación, tipos de fuente y tooling | PASS |
-| Migraciones históricas 0.10.0 / 0.11.1 | PASS |
-| Evaluaciones determinísticas | 7/7 |
-| Benchmarks de workspace y safe-fix scripted | PASS; no acreditan capacidad de modelos |
-| MCP e interoperabilidad con SDK oficial | PASS |
-| OCI real | PASS, Docker 29.8.0, secretos excluidos, red denegada e importación gobernada |
-| Paquete instalado y tarball exacto | PASS |
-| Auditoría de dependencias | BLOQUEADA: servicio de advisories npm HTTP 503, dos intentos |
-| Scripts de dependencias no confiables | 0 |
-| Gate formal `readiness:1.0:release` | FAIL: RC.14 incompleta, revisión pendiente, fase y versión sin promover |
-
-La imagen OCI usada fue
-`node:24-bookworm-slim@sha256:0e0ff40c39bc087845bfb27465a0df4ea419520094bc35842ff83dd8cbe6f9b6`.
-
-| Prueba live de fuente aislada | Meta muse-spark-1.2 | Qwen qwen3.8-max | OpenAI gpt-5.6-luna |
-| --- | --- | --- | --- |
-| Aprobación, persistencia y reinicio | FAIL | PASS | FAIL |
-| Orquestación, hijo persistido y reapertura | PASS | PASS | PASS |
-| Ejecución OCI e importación al host | FAIL | PASS | FAIL |
-
-Routing OpenAI → Qwen: PASS, una delegación y una herramienta del revisor.
-Estos smokes usan las credenciales existentes y fixtures temporales; no son la
-matriz representativa de un release protegido. Gemini no pertenece a la cohorte GA.
-
-## Hallazgo GA-01 — P1 funcional: reserva de salida impide el segundo turno
-
-Con `subagentProfiles: []`, Meta y OpenAI activan el presupuesto de transporte en
-`src/harness.ts` (`createProviderCompatibleBudget`) y `src/runtime-policy.ts`.
-La integración con Core 1.14.0 vuelve a exigir la reserva completa de salida en
-el preflight del siguiente turno. La reserva no cabe después del primer consumo:
-
-| Proveedor | Límite | Consumido | Reserva solicitada | Disponible | Resultado |
-| --- | ---: | ---: | ---: | ---: | --- |
-| Meta | 30.000 | 2 | 30.000 | 29.998 | GuardrailTriggeredError, etapa input |
-| OpenAI | 30.000 | 2 | 30.000 | 29.998 | GuardrailTriggeredError, etapa input |
-| Qwen, control | 30.000 | 4 al terminar | — | — | completed |
-
-Se reprodujo sin red ni modelo real usando un primer turno `list_files` de dos
-tokens y un segundo turno de finalización. También se observó el guardrail de
-presupuesto de salida en diagnósticos adicionales de los fallos live de aprobación.
-Los fallos live OCI tienen el mismo fingerprint; no se afirma una inspección
-independiente de su causa interna.
-
-Ejecutar desde un checkout con el lockfile del commit evaluado:
-
-```sh
-bun run scripts/validate-ga-budget.ts
-```
-
-La nueva prueba de aceptación sale con código 1 en el candidato evaluado; Qwen
-actúa como control positivo. No se incluye silenciosamente como un test verde.
-El script valida finalización, salida esperada, uso y ejecución de herramienta.
-Debe pasar para los tres proveedores después de corregir la coordinación entre
-presupuesto acumulado y reserva por llamada, manteniendo límites y aprobaciones.
-
-## Evidencia remota y pendientes
-
-La consulta actual de [CI del mismo commit](https://github.com/Zhivex/zhivex-harness/actions/runs/35458111045)
-mostró ambos jobs de consumidores Node 22.13/24 verdes. Los jobs de tooling macOS
-y Ubuntu fallaron en auditoría de dependencias; el log de Ubuntu confirma HTTP 503.
-[CodeQL del mismo commit](https://github.com/Zhivex/zhivex-harness/actions/runs/35458110958)
-pasó. La indisponibilidad de advisories no equivale a cero vulnerabilidades.
-
-Para levantar el NO-GO se requiere:
-
-1. Corregir GA-01 y repetir esta aceptación y los smokes live afectados.
-2. Resolver la retención por entrega de reparaciones registrada en
-   [la validación previa de RC.14](RC14_VALIDATION_2026-09-10.md), con una cohorte
-   nueva y criterios predeclarados. Esta validación no la reejecutó ni la cerró.
-3. Recuperar auditoría de dependencias y CI completos.
-4. Certificar el candidato final inmutable: tag, artefacto, OCI, live y matriz
-   representativa completa de 42 casos; verificar publicación y SLSA. No se
-   despachó publicación ni se ejecutó esa matriz sobre un candidato ya bloqueado.
-5. Completar la revisión de seguridad de todas las fronteras y herramientas del
-   candidato final con la identidad exigida por la política vigente. El borrador
-   de RC.13 no cubre RC.14 y este informe no sustituye su firma humana.
-6. Sólo después, preparar versión `1.0.0`, fase `ready` y ejecutar el gate formal.
-
-No se cambiaron estados del ledger, se declararon cero hallazgos de seguridad,
-se crearon tags ni se publicó ningún paquete. La revisión completa de seguridad
-queda pendiente, no aprobada por inferencia a partir de tests o CodeQL verdes.

package/docs/reports/HARNESS_ARCHITECTURE_REVIEW_2026-09-09.md

@@ -1,202 +0,0 @@
-# Revisión estructural del harness tras la reevaluación Qwen
-
-> Historical snapshot: versions, findings and measurements below describe the recorded run, not the current checkout. See the [report index](README.md) for follow-up work and the [documentation index](../README.md) for maintained guides.
-
-El principal margen de mejora está en el controlador de reparación. El harness
-dispone de mecanismos de ejecución gobernada, pero sigue delegando en el modelo
-la decisión de abandonar la exploración, recuperar memoria, seleccionar una
-verificación e importar. Las políticas añadidas restringen ciertas herramientas;
-no implementan todavía un flujo de reparación con progreso comprobable y
-presupuesto de cierre. Más instrucciones y herramientas no resolvieron esa
-carencia y aumentaron el contexto fijo.
-
-## Alcance y método
-
-Revisión del checkout actual, incluidos cambios locales: instrucciones y catálogo,
-lectura/búsqueda/edición, progreso, compacción/memoria, presupuesto, aprobación y
-finalización, ciclo OCI, configuración CLI/orquestación, driver, métricas y pruebas.
-Se contrastó con las veinte muestras archivadas de la última comparación y con
-los informes históricos. No se hicieron llamadas nuevas a proveedores ni se
-modificó el runtime. No es una recertificación completa de seguridad, proveedores,
-servicios externos, concurrencia, plataformas o publicación.
-
-Se ejecutaron 46 pruebas focalizadas en cinco archivos: progreso, remediación,
-compacción, recuperación de verificación y SWE-bench. Pasaron todas. El nuevo
-`../../evaluations/audits/repair-architecture-2026-09-09.ts` (source checkout)
-usa herramientas reales de lectura sobre archivos temporales y llamadas simuladas
-al middleware presupuestario. Pasó typecheck con las opciones estrictas del repo.
-La [evidencia estructurada](../../benchmarks/baselines/repair-architecture-audit-2026-09-09.json)
-incluye hashes de fuentes, resultados de los reproductores y métricas derivadas.
-
-## Por qué las iteraciones no dieron el avance esperado
-
-1. Se corrigieron defectos reales de integridad, cancelación, compatibilidad y
-   observabilidad. Esas correcciones son necesarias, pero su aprobación local
-   no demostraba que el agente fuera a resolver más tareas.
-2. Se intervino con frecuencia sobre síntomas: más contexto recuperable,
-   instrucciones de cierre y contadores de exploración. Ninguno obliga a que
-   un candidato llegue a verificación con recursos suficientes.
-3. La remediación agrupó once mejoras. La última matriz permite evaluar el
-   paquete completo, pero no atribuir el resultado a cada intervención. Sí hubo
-   un estudio anterior aislado de recuperación de verificador; no alcanzaba a
-   reparar intentos que nunca llegaban al verificador.
-4. Se reutilizaron cinco tareas conocidas. Sirven para depurar; repetirlas no
-   amplía cobertura de generalización. Dos repeticiones tampoco estabilizan
-   suficientemente resultados de un agente estocástico.
-5. Las nuevas ayudas también cuestan: sistema más catálogo aumentó de 11.157
-   a 13.755 caracteres por petición. No se exigió una mejora de resultado final
-   antes de considerar completada la mejora del mecanismo.
-
-El resultado actual sigue siendo 0/10 entregas de Zhivex frente a 4/10 de mini
-con el mismo Qwen solicitado. Los tres candidatos correctos de Zhivex identifican
-una pérdida posterior a la edición, no tres éxitos ni una mejora medida respecto
-de una baseline que no capturaba candidatos.
-
-## Hallazgos y cambios necesarios
-
-| ID | Prioridad | Diagnóstico | Cambio y criterio de aceptación |
-| --- | --- | --- | --- |
-| A01 | P1 | El cierre depende de otra decisión del modelo | Controlador durable por etapas y revisión de parche. Una edición activa una obligación pendiente de verificación; completar requiere recibo válido. |
-| A02 | P1 | No hay reserva efectiva para cerrar | Separar presupuesto de trabajo y cierre, estimar la siguiente petición completa, reservar inspección/verificación y recuperación acotada. El trabajo ordinario no puede consumir la reserva. |
-| A03 | P1 | La fase declarada no representa evidencia de progreso | Transiciones basadas en reproducción, digest del candidato y recibos; un plan es una hipótesis, no una reparación. |
-| A04 | P2 | El alcance del plan no se aplica a lecturas por lotes | Normalizar y validar todos los paths de cada herramienta. La política debe ser consistente entre lectura individual, lote y búsqueda. |
-| A05 | P1 | Recuperar memoria sigue siendo opcional; checks compactados pierden identidad | Proyección automática y acotada del estado de trabajo: requisito activo, hipótesis, evidencia, revisión del candidato y próximo check. Conservar vínculos a recibos completos. |
-| A06 | P2 | Catálogo estático y estimación parcial del contexto | Catálogo mínimo por etapa y medición de mensajes + sistema + esquemas + margen del transporte; verificar compatibilidad con historia y aprobaciones. |
-| A07 | P2 | El contrato de verificación exige salida cero, no suficiencia del check | Registrar propósito, aserciones y revisión probada; distinguir ejecución exitosa, reproducción corregida y regresión. No sustituir pruebas independientes por autoevaluación del modelo. |
-| A08 | P2 | Crear/sincronizar el entorno consume una parte medible de los comandos | Explorar sesión por ejecución lógica y sincronización incremental conservando leases, cancelación e integridad. Medir por separado antes de cambiar. |
-| A09 | P1 | Los gates de mecanismo no prueban mejora del agente | Regresiones de trayectorias difíciles, ablaciones pequeñas y promoción por resultados entregados, sin alterar métricas ni presupuestos tras observar fallos. |
-| A10 | P2 | Perfil y entorno del benchmark difieren del producto y el competidor | Manifiesto efectivo exportable para CLI y benchmark; comparar calidad del candidato y entrega gobernada por separado. |
-
-### A01–A03: cambiar quién controla el progreso
-
-`runHarness` retorna un resultado no pendiente de aprobación sin conducir una
-transición de reparación. La ruta terminal solo se activa si el modelo ya pidió
-una herramienta terminal y quedó una aprobación única aprobada. Es una
-optimización útil del cierre solicitado, no un controlador que garantice llegar a él.
-
-`createRepairProgress` establece `phase=repair` al recibir `repair_plan`, incluso
-antes de reproducir o editar. No tiene estados basados en candidato modificado,
-verificación necesaria o importación pendiente. `closing()` activa un booleano
-al 70% de uso y permite hasta cuatro lecturas y tres comandos adicionales. Un
-modelo puede gastar lo restante antes de agotar esos contadores.
-
-El reproductor consume 70.000 tokens, acepta tres respuestas de 10.000 y bloquea
-la siguiente: reserva efectiva cero. En las trazas reales, nueve intentos entran
-en cierre con cero bloqueos de fase y ninguno solicita verificación. No hace
-falta una avería del SDK para explicar ese comportamiento.
-
-Propuesta de flujo: explorar → reproducir → editar → verificar → importar →
-completar. Debe permitir corregir hipótesis, reproducir con fixtures nuevos y
-volver a editar tras una verificación fallida. La transición puede automatizar
-inspección y preparación del próximo paso; nunca debe inventar aprobaciones,
-usar pruebas ocultas ni importar candidatos solo porque el evaluador posterior
-los considere correctos. Si falta autorización, termina como pendiente; si falta
-evidencia o presupuesto, conserva candidato y causa sin declarar éxito.
-
-La reserva debe calcularse antes de pedir otra respuesta, no solo después del
-70%. Debe incluir el catálogo, la petición de cierre y una recuperación acotada.
-Un porcentaje fijo puede ser un límite inicial, pero su efectividad depende del
-tamaño de las peticiones. No se propone subir los 100.000 tokens para ocultar el
-problema. La telemetría de transporte debe persistir como contabilidad propia;
-restaurarla únicamente desde uso del SDK hereda los huecos ya documentados.
-
-### A04: el plan no cubre la herramienta más utilizada
-
-El wrapper consulta `input.path`. `read_files` usa `input.files[].path`, por lo
-que queda fuera de esa comprobación. El reproductor registra `planned.txt`:
-`read_file(unplanned.txt)` se rechaza por alcance y el lote equivalente devuelve
-el archivo. Es un defecto de estrategia; las restricciones de seguridad del
-workspace continúan aplicándose.
-
-Hubo 52 ejecuciones de `read_files`, 27 de `search_files` y 7 de `search_many`.
-Por ello no basta probar un wrapper con un schema ficticio que solo contiene
-`path`: hay que probar los schemas reales y sus equivalencias. Contar un lote
-como una lectura también separa cantidad de llamadas de cantidad de evidencia.
-
-### A05–A06: memoria utilizable, no solo disponible
-
-Las trazas contienen 14 eventos de compacción y una solicitud de `read_task`.
-Esto no demuestra por sí solo qué requisito olvidó cada intento, pero sí que la
-instrucción de recuperar la tarea después de compactar no se cumple de forma
-sistemática. La tarea completa ahora está conservada en metadata; el siguiente
-paso es presentarle al modelo automáticamente la parte necesaria, con acceso
-a la fuente completa, sin reinyectar documentos enteros en todas las peticiones.
-
-El compactor conserva paths, digests y códigos de salida, pero el reproductor
-muestra que pierde `assert 2 + 2 == 4` y mantiene `exitCode=0`. Hace falta un
-registro de evidencias ligado a `commandId`, propósito y revisión, cuya proyección
-resuma resultados y ubicación de fallos. Los logs completos deben quedar acotados
-y accesibles bajo la política de redacción; no incorporarse indiscriminadamente.
-
-El estimador usado por compacción recibe mensajes y divide caracteres por cuatro;
-no recibe el catálogo de herramientas. El medidor de transporte sí lo observa,
-pero esa observación no alimenta una predicción del costo siguiente. Catálogo
-y sistema crecieron 23,3%, mientras los resultados de herramientas presentes por
-petición bajaron solo 7,2% en la cohorte. Es evidencia de un tradeoff; no prueba
-causal de que retirar memoria aumente la tasa de resolución.
-
-Un catálogo dinámico debe conservar consistencia del protocolo de herramientas
-anteriores y de aprobaciones pendientes. No basta eliminar nombres del objeto
-antes de cada llamada. Primero conviene medir una variante estática mínima,
-manteniendo edición gobernada e importación, y luego agregar selección por fase.
-
-### A07–A08: calidad de verificación y costo OCI
-
-`verify_and_apply_environment_patch` verifica patchId, ejecuta argv aprobado,
-exige salida cero, rechaza cambios producidos por el verificador e importa bajo
-las comprobaciones existentes. Esas garantías deben conservarse. Una salida cero
-no demuestra que el comando haya comprobado el requisito: un contrato de evidencia
-debe hacer explícito qué se comprobó, sin confundirlo con una prueba matemática
-de cobertura. El evaluador independiente sigue siendo necesario.
-
-En los 17 comandos nativos observados, las métricas acumulan 68,84 s, de los cuales
-11,60 s corresponden a creación de sesión y 12,35 s a exportación de workspace:
-34,8% del tiempo instrumentado de comandos entre ambas fases. No es 34,8% de toda
-la ejecución ni demuestra que OCI explique el fracaso. El runtime elimina los
-contenedores al liberar una sesión; su calentamiento depende de la duración de
-la adquisición. Hay margen para estudiar persistencia bajo una misma ejecución
-lógica, pero corregir el cierre y el contexto tiene prioridad sobre este ahorro.
-
-### A09–A10: evaluar resultados y trasladarlos al producto
-
-Los tests de progreso verifican contadores y excepciones. Los de recuperación
-usan un modelo simulado que emite `read_task` o el verificador cuando el fixture
-lo programa. Son regresiones válidas del mecanismo; no evidencia de que Qwen
-vaya a tomar esas decisiones. `scripts/evaluate.ts` también usa modelos simulados.
-
-Añadir trayectorias con edición correcta temprana seguida de exploración,
-memoria compactada, lotes fuera de alcance, aprobación tardía, cancelación,
-verificación fallida y reinicio durable. Medir qué decisiones puede forzar el
-controlador sin depender de que el mock le entregue el final feliz. En live,
-registrar tokens hasta primera edición, primera reproducción y verificación,
-tokens después del último candidato, candidato correcto y entrega final.
-
-El benchmark activa `repair`, desactiva contexto de proyecto y subagentes, y
-recorta el catálogo. La CLI por defecto resuelve `strict`. No se concluye que
-estos resultados cubran toda la CLI, MCP, skills u orquestación. El siguiente
-experimento debe exportar el perfil efectivo y reutilizar el mismo ensamblado
-del producto donde sea posible.
-
-## Orden de trabajo y criterio de avance
-
-1. **Cerrar correctamente un candidato existente.** Regresión de flujo sin modelo
-   real que conserve permisos, integridad y cancelación; luego un ensayo live
-   acotado. El objetivo es elevar entregas, no solo llegar a editar.
-2. **Integrar presupuesto y estado de reparación.** Hacer imposible gastar la
-   reserva en exploración ordinaria; persistir estado/contabilidad y probar resume.
-3. **Reducir contexto efectivo.** Variante mínima del catálogo y memoria proyectada,
-   cambiadas por separado para identificar el aporte de cada una.
-4. **Evaluar generalización.** Tras una mejora repetida en desarrollo, congelar
-   configuración y abrir una cohorte nueva por tipo de tarea y repositorio.
-
-Predeclarar para cada ensayo hipótesis, cambio, tareas, repeticiones, límites,
-métrica principal y regla de parada. Mantener comparables modelo, razonamiento y
-transporte; la comparación anterior OpenAI/Qwen variaba esas tres dimensiones.
-No iniciar otra matriz completa por cada ajuste menor. Un resultado sin mejora
-final exige revisar la hipótesis, no acumular más herramientas por defecto.
-
-La HU del SDK sobre herramientas desconocidas y pérdida de uso durable ya está
-[en Zhivex](https://app.notion.com/p/3d7777b104f681248ed3cecffe9328d2).
-Los nuevos hallazgos reproducidos aquí pertenecen al harness y no requieren
-esperar al SDK. Muse o un modelo con mayor razonamiento podrían cambiar las
-decisiones, pero no garantizan resolver estos defectos del controlador.

package/docs/reports/HARNESS_AUDIT_2026-09-09.md

@@ -1,306 +0,0 @@
-# Auditoría integral del harness — 2026-09-09
-
-> Historical snapshot: versions, findings and measurements below describe the recorded run, not the current checkout. See the [report index](README.md) for follow-up work and the [documentation index](../README.md) for maintained guides.
-
-> Estado posterior: los once hallazgos tienen implementaciones y regresiones locales.
-> Ver [cierre de implementación](HARNESS_REMEDIATION_2026-09-09.md).
-> El cuerpo de este documento y el baseline original conservan la evidencia previa;
-> sus ubicaciones de líneas son históricas y los resultados no describen el código corregido.
-
-La revisión encontró problemas adicionales a la adaptación de Qwen. Los más
-urgentes son la cancelación de la ruta terminal, una carrera en la validación de
-directorios y la pérdida de requisitos durante la compactación. No hay evidencia
-para atribuir estos hallazgos al SDK nuevo.
-
-El análisis cubre el checkout de `1.0.0-rc.13`, incluido el trabajo local sin
-commit, con Core 1.14.0, Agents 1.4.0 y Qwen 0.11.4. No se modificó código de
-producción. Se añadieron un reproductor local y evidencia; no se hicieron llamadas
-nuevas a modelos, publicación ni cambios en servicios externos.
-
-## Alcance y método
-
-Se inspeccionaron las fronteras entre instrucciones, herramientas, SDK, contexto,
-OCI, aprobaciones, persistencia, CLI, orquestación, telemetría y evaluación. Se
-revisaron también los contratos de seguridad y los gates locales de CI/release.
-Esto es una auditoría de superficies y riesgos, no una certificación de todas las
-líneas, plataformas o condiciones concurrentes del producto.
-
-- **466 pruebas existentes:** pasaron, sin fallos.
-- **7 evaluaciones determinísticas:** pasaron; usan modelos simulados.
-- Typecheck de producción, contratos y migraciones publicadas 0.10.0/0.11.1: pasaron.
-- Reproductor de auditoría: ejecutado y validado con TypeScript por separado.
-- El contrato de preparación sigue declarando abierto el gate de revisión de seguridad.
-- La evidencia live consultada es la matriz Qwen anterior de diez intentos; no se repitió.
-- No se revalidaron servicios MCP externos, el paquete publicado, CI remoto ni OCI real en esta auditoría.
-
-Reproducción local sin credenciales ni Docker:
-
-```sh
-bun --no-env-file run evaluations/audits/harness-review-2026-09-09.ts
-```
-
-El `../../evaluations/audits/harness-review-2026-09-09.ts` (source checkout) sólo escribe
-fixtures temporales que elimina al terminar. La [evidencia estructurada](../../benchmarks/baselines/harness-audit-2026-09-09.json)
-registra observaciones, versiones y hashes. No es una suite que obligue a conservar
-los defectos: después de corregirlos deben cambiar las observaciones y agregarse
-regresiones con el comportamiento deseado.
-
-## Hallazgos priorizados
-
-| ID | Prioridad | Hallazgo | Evidencia | Responsable |
-| --- | --- | --- | --- | --- |
-| H01 | P1 | La importación terminal puede ejecutarse después de cancelar | Reproducido | Harness |
-| H02 | P1 condicional a mutación concurrente | Una lectura puede seguir un directorio padre sustituido | Reproducido con intercalado controlado | Harness/filesystem |
-| H03 | P1 | La compactación elimina criterios de aceptación del objetivo | Reproducido | Harness/contexto |
-| H04 | P2 | Búsquedas válidas pueden producir más de 300.000 caracteres | Reproducido | Harness/herramientas |
-| H05 | P2 | Búsqueda incompleta se presenta como ausencia de coincidencias | Reproducido | Harness/herramientas |
-| H06 | P2 | Las instrucciones y el catálogo de herramientas no coinciden | Código y fixture | Harness/driver |
-| H07 | P2 | Readquirir OCI pierde el historial visible de mutaciones | Reproducido | Harness/OCI |
-| H08 | P2 | El control de exploración no representa el progreso de reparación | Código, fixture y matriz live | Harness/estrategia |
-| H09 | P2 | Las mejoras del driver no equivalen a mejoras activas en CLI | Código | Harness/producto |
-| H10 | P2 | La evaluación pierde los parches candidatos y etapas intermedias | Código y resultados | Harness/evaluación |
-| H11 | P2 | La telemetría no permite cerrar ciertas causas de fallo ni tiempos | Código y matriz live | Harness/observabilidad |
-
-### H01 — Cancelación omitida en la ruta terminal
-
-`src/harness.ts:1030`, `:1054`, `:1098`, `:1472`.
-
-`executeTerminalReceiptTool` readquiere el entorno y construye un
-`ToolExecutionContext` sin propagar el `abortSignal` del llamado. `runHarness`
-tampoco vuelve a comprobarlo después de resolver la aprobación y antes de tomar
-esta ruta. Se sale del circuito normal del SDK para ejecutar e importar.
-
-La prueba canceló la señal dentro del resolver de aprobación, antes de devolver
-la respuesta. Resultado: `status=completed`, una ejecución, sin señal en el runtime
-e importación efectiva del archivo de prueba. El verificador fue simulado; las
-aprobaciones, snapshots, journal y escritura del host fueron los reales del harness.
-
-Alcance: ruta opt-in `terminalReceiptTools`, usada por el benchmark y disponible
-en la biblioteca. No demuestra que toda cancelación de la CLI falle.
-
-Corrección: propagar señal y deadline, comprobar cancelación antes de ejecutar y
-antes de importar, y mantener la finalización de estado bajo las mismas garantías
-de cancelación/concurrencia del circuito ordinario. Validar cancelación antes,
-durante y después del verificador; ninguna debe producir una importación posterior.
-
-### H02 — El descriptor protege la hoja, no toda la ruta
-
-`src/workspace.ts:478`, `:508`; `src/file-security.ts:45`.
-
-Se validan ancestros con `lstat`, pero después se abre una ruta absoluta. El
-`O_NOFOLLOW` usado al abrir protege la hoja; un ancestro puede haber cambiado.
-La prueba sustituye el directorio padre por un symlink después de `safePath` y
-antes de la lectura real. Se devolvió el sentinel externo como si perteneciera a
-`parent/fixture.txt` dentro del workspace.
-
-Es un intercalado determinístico mediante instrumentación del objeto de prueba,
-no una medición de probabilidad de explotación. Requiere otro actor capaz de
-modificar el directorio durante la operación; un symlink estático sigue siendo
-rechazado. No se usaron secretos ni se demostró escritura externa.
-
-Corrección: ligar la resolución completa a directorios confiables y a descriptores
-(o un mecanismo equivalente soportado por plataforma). Repetir `lstat` antes o
-después no cierra por sí solo la carrera. Auditar también lecturas de contexto y
-operaciones de publicación que combinan validación de padres con uso posterior de
-rutas. No marcar estas otras superficies como explotadas sin reproducirlas.
-
-### H03 — La memoria conserva ubicaciones, pero pierde la tarea
-
-`src/compaction.ts:18`, `:75`, `:89`, `:163`; `src/harness.ts:694`.
-
-El primer objetivo se recorta a 768 caracteres y los mensajes de seguimiento a
-512. Se trata de un prefijo, no de una extracción semántica de requisitos. Un
-objetivo de 1.589 caracteres perdió el criterio final `MANDATORY_ACCEPTANCE` al
-compactar. Las compactaciones siguientes sólo pueden conservar lo que sobrevivió.
-El SDK invoca el compactor sobre el prefijo que reemplazará; el texto completo del
-objetivo no queda garantizado en el contexto enviado al modelo.
-
-Además, se conservan códigos de salida de checks sin toda su asociación a comandos,
-aserciones y revisión probada. Un historial de `exitCode=0` no permite reconstruir
-por sí solo qué comportamiento fue validado. Los recibos durables son otra fuente;
-no deben confundirse con esta memoria.
-
-Corrección: mantener objetivo, restricciones y criterios activos separados del
-historial comprimible; ofrecer recuperación controlada del pedido original y una
-memoria de trabajo con hipótesis, decisiones, cambios y comprobaciones asociadas.
-Probar requisitos ubicados al final, cambios de objetivo, varias compactaciones
-y continuidad luego de aprobaciones. No aumentar simplemente el límite global.
-
-### H04 — Se limita el número de resultados, pero no su costo agregado
-
-`src/workspace.ts:855`, `:937`; `src/harness.ts:369`, `:688`.
-
-Una búsqueda legal de 500 coincidencias devolvió **310.975 caracteres**. Las
-lecturas ya tienen límites de contenido de 16.000/32.000 caracteres, pero búsquedas
-repiten texto, path y digest en cada coincidencia sin un presupuesto equivalente.
-El modelo puede recibir un payload grande de golpe. La estimación de compactación
-usa caracteres de mensajes divididos por cuatro; no incluye las definiciones de
-herramientas y no garantiza un límite exacto de tokens del proveedor.
-
-Corrección: presupuesto agregado por respuesta y por turno, paginación con aviso
-de cobertura, menos repetición de metadata y catálogo de herramientas por fase.
-Medir tokens reales; no traducir mecánicamente los caracteres a tokens facturados.
-
-### H05 — Cero coincidencias no implica búsqueda completa
-
-`src/workspace.ts:891`, `:970`.
-
-Las búsquedas de directorio descartan errores de lectura. Con un archivo de más de
-1 MiB que contenía el marcador buscado, el resultado fue `matches=[]` y
-`truncated=false`, sin contador de archivos omitidos. El límite de lectura es
-razonable; la falsa impresión de cobertura completa no lo es.
-
-Corrección: informar archivos inspeccionados/omitidos y motivos tipados, con
-`incomplete` independiente de la truncación por cantidad de coincidencias. La
-búsqueda por archivo exacto debe mantener sus errores explícitos.
-
-### H06 — Instrucciones que no corresponden a las herramientas activas
-
-`src/harness.ts:154`, `:369`; `scripts/swebench/zhivex-driver.ts:51`, `:75`.
-
-El benchmark selecciona nueve herramientas, pero reutiliza instrucciones que
-ordenan inspeccionar `mutation_audit` y mencionan `git_diff`, `load_skill`,
-`apply_patch` y `run_check`. Varias no están disponibles. El prompt indica usar
-rutas relativas y después introduce `/workspace`; las descripciones de herramientas
-no explican uniformemente la diferencia entre ruta de herramienta y cwd del shell.
-La matriz muestra errores ENOENT iniciales, pero no conserva sus argumentos:
-no se puede atribuir esos errores concretos a esta ambigüedad.
-
-En el harness normal, `search_files` sólo acepta directorios aunque la guía general
-recomienda buscar en el archivo exacto. El fixture falla con `search_files` y
-funciona con `search_many` sobre ese mismo archivo.
-
-Corrección: generar instrucciones a partir del catálogo y backend efectivos,
-unificar contratos de búsqueda y dar ejemplos breves de rutas válidas. Validar que
-cada instrucción ejecutable tenga una herramienta disponible.
-
-### H07 — El journal durable y mutation_audit cuentan historias distintas
-
-`src/execution-environment.ts:1677`; `src/workspace.ts:442`, `:1006`;
-`src/harness.ts:486`.
-
-Cada adquisición crea otra instancia de `Workspace`, cuyo audit es un array en
-memoria. Tras editar y readquirir la misma sesión OCI: entradas de audit **1 → 0**,
-pero el parche conservaba una entrada. Esto ocurre dentro del flujo de un run;
-no requiere reiniciar toda la aplicación.
-
-No demuestra pérdida del journal de ejecución del SDK ni del parche. Demuestra
-que la herramienta de audit no reconstruye la historia que el modelo y la
-documentación esperan consultar al final.
-
-Corrección: reconstruir por run desde eventos persistidos o mantener un registro
-ligado a la sesión durable. Distinguir las ediciones directas de los cambios hechos
-por comandos y probar continuidad a través de varias aprobaciones.
-
-### H08 — El contador de duplicados no mide estancamiento
-
-`src/repair-progress.ts:28`, `:34`; baseline Qwen actualizado.
-
-El controlador borra su memoria ante toda herramienta fuera de la lista de lecturas.
-Eso incluye `inspect_environment_patch`, que es de sólo lectura. Alternar cuatro
-lecturas idénticas con esa inspección produjo cero duplicados y cero supresiones.
-
-La fase de cierre bloquea listados y búsquedas en la raíz; permite distintas
-lecturas, búsquedas en directorios y exploración vía shell. En la matriz se activó
-en cuatro intentos, bloqueó una llamada y no evitó cuatro agotamientos de presupuesto.
-No existe una reserva rígida del 30% ni una transición obligatoria hacia un parche.
-
-Corrección: invalidar sólo por posibles efectos reales, detectar solapamiento y
-progreso semántico, y asignar presupuestos a explorar/reproducir/editar/verificar.
-No bloquear una lectura necesaria para corregir con seguridad ni ejecutar cambios
-sólo porque se agotó el tiempo de exploración.
-
-### H09 — Driver experimental y producto tienen políticas distintas
-
-`src/harness.ts:966`, `:1345`; `scripts/swebench/zhivex-driver.ts:38`, `:93`.
-
-La recuperación de schemas, el middleware de presupuesto de transporte y el
-control de progreso se habilitan en el driver. El runtime ordinario mantiene
-`stopOnError=true`, recuperación terminal deshabilitada por defecto y no instala
-el controlador de progreso automáticamente. Compactación v3 y herramientas nuevas
-sí están compartidas.
-
-Es una elección conservadora explícita, no un bug del SDK. Pero impide presentar
-el comportamiento de la corrida como el comportamiento general de la CLI.
-
-Corrección: perfiles de política explícitos, versionados y comprobables, con
-recuperación acotada por clase de error. Mantener denegaciones, límites, cancelación
-y errores de integridad como fronteras estrictas. Validar el mismo perfil desde
-la CLI, biblioteca y evaluación antes de habilitarlo por defecto.
-
-### H10 — La métrica final oculta dónde se perdió la reparación
-
-`scripts/swebench/run.py:214`; `mini_driver.py:101`;
-`zhivex-driver.ts:109`.
-
-Mini exporta el diff existente de su contenedor incluso tras terminar por límites.
-Zhivex entrega el diff del host, que sólo recibe cambios mediante importación
-verificada. Después borra el directorio de estado, incluido el snapshot candidato.
-
-El score 0/5 frente a 2/5 sigue describiendo los resultados de esas dos políticas
-completas. No aísla calidad de razonamiento, calidad del parche candidato, costo
-adicional de gobierno ni el efecto del SDK. **Un diff exportado vacío no permite
-concluir que el agente nunca editó dentro de OCI.** Las llamadas de shell pueden
-editar; la telemetría proyectada no permite reconstruir siempre su intención.
-
-Corrección: conservar separadamente candidato, verificado e importado; registrar
-etapas alcanzadas; evaluar el candidato en un entorno independiente después de
-terminar, sin importarlo ni mostrarle tests ocultos al agente. Mantener el score
-oficial de reparación segura y añadir un diagnóstico comparable de capacidad.
-Usar holdout nuevo y varias repeticiones una vez congelada cada variante.
-
-### H11 — Telemetría insuficiente para atribución y rendimiento
-
-`scripts/swebench/telemetry.ts`; `zhivex-driver.ts:111`, `:126`;
-`scripts/time-to-safe-fix-efficiency.ts`.
-
-SymPy terminó con un fingerprint sin causa identificada y uso incompleto. Algunas
-filas tienen `status=failed` y `failure=null`; la causa está en guardrails. El
-instrumentador recoge tiempos por herramienta, pero el driver devuelve sólo la
-suma de llamadas. Se observan respuestas, no todas las transiciones de etapa, y
-los códigos de salida del verificador no explican la aserción que falló.
-
-Corrección: taxonomía estructurada para transporte/parsing/schema/herramienta/
-verificación/presupuesto/cancelación; conservar finish reason, herramientas
-solicitadas con nombres permitidos, etapa y uso faltante. Añadir latencia de modelo,
-TTFT cuando exista, herramientas, aprobaciones, OCI y grading. Mantener artefactos
-de diagnóstico privados y acotados; no imprimir prompts, secretos o logs crudos.
-
-## Superficies revisadas sin nuevo fallo confirmado
-
-| Superficie | Qué se contrastó | Límite de la conclusión |
-| --- | --- | --- |
-| Persistencia y sesiones | revisiones, scope, leases del SDK, migraciones, backup y estados activos | No se ensayó caída real del proceso durante cada escritura ni multi-host |
-| Presupuestos | guardrails, medición de transporte, continuación por aprobación | El probe `maxSteps=1` hizo una petición y terminó por límite; no se confirmó un reset de steps |
-| Orquestación | selección de roles, presupuestos hijos, promoción de aprobación e herencia de entorno del SDK | Grupos de review y perfiles necesitan evaluaciones de calidad, además de mocks |
-| MCP | límites de payload, permisos, aprobación, tratamiento no confiable | No se ensayaron todos los servidores/transportes externos; filtros de texto no son garantía universal contra inyección |
-| OCI | políticas, transacciones por comando, rechazo de drift, importación | El nuevo probe usa un proceso simulado; no constituye certificación del daemon |
-| Proveedores | configuración instalada, capability gate y recuperación comprobada | Sin llamadas live nuevas ni comparación de modelos con reasoning equivalente |
-| Build/release | contratos, CI declarada, versiones y gate de seguridad | Sin consulta de registry ni certificación del paquete publicado |
-
-Otros puntos para el backlog: `tester` ejecuta scripts de `package.json` y no es
-un verificador genérico de repositorios Python; un `read_files` con un archivo
-inválido pierde todos los resultados del batch; la compactación no guarda una
-hipótesis estructurada; el contexto de proyecto puede consumir una parte grande
-del prompt fijo. Son superficies de producto que requieren pruebas de uso y
-medición antes de rediseñar la API.
-
-## Orden recomendado de trabajo
-
-1. **Cerrar H01/H02** con regresiones adversariales y validación en las plataformas soportadas.
-2. **Corregir H03/H04/H05/H06**: objetivo recuperable, salidas acotadas, cobertura explícita e instrucciones coherentes.
-3. **Resolver H07/H08/H09**: continuidad de audit y perfiles de ejecución compartidos con presupuesto por fase.
-4. **Instrumentar H10/H11** antes de otra campaña de gasto live.
-5. Ablaciones: contrato/instrucciones; memoria de tarea; control de exploración;
-   herramientas por fase. Cambiar una familia a la vez, manteniendo modelo,
-   reasoning, imágenes y límites. Luego confirmar en un holdout nuevo.
-
-Medir resolución candidata/verificada/importada, tokens completos por reparación,
-tiempo hasta primer cambio y primera verificación, errores recuperados, cobertura
-de búsqueda y uso incompleto. Comparar presupuesto bajo, medio y alto para saber
-si la curva mejora; un solo punto de 100k no responde esa pregunta.
-
-No hay base para prometer que Muse cierre estas brechas. Una memoria adicional
-puede ayudar a la continuidad, pero no corrige cancelación, resolución de rutas,
-contratos incompatibles ni una evaluación que pierde etapas. Los hallazgos
-confirmados de esta revisión pertenecen al harness; no se creó una HU nueva del SDK.