El arnés ya tiene canon. Sus preguntas abiertas tienen respuesta.

La conversación del arnés ya tiene texto canónico. «Harness engineering for coding agents», de Birgitta Böckeler, hace por esta disciplina lo que lo mejor de ese catálogo ha hecho siempre: tomar una práctica que todo el mundo improvisaba y darle un vocabulario estable. Un agente es modelo + arnés. El arnés dirige con guías — controles feedforward que suben la probabilidad de un buen resultado antes de generar: documentación de arquitectura, ficheros de convenciones, skills — y corrige con sensores — controles feedback que disparan después: linters, tests, comprobaciones estructurales, agentes revisores. Los sensores se dividen en computacionales (deterministas, baratos, milisegundos) e inferenciales (un LLM juzgando semántica: más rico, más lento, probabilístico). Y por encima de todo gira un bucle de gobierno: cada vez que un problema ocurre dos veces, un humano mejora guías y sensores para que ocurra menos.

Adoptamos este vocabulario entero. Es mejor que el que usábamos, y un canon compartido abarata todas las conversaciones que vienen después. Cuando nuestro post anterior argumentó que el arnés gobierna el verbo y no nombra ningún sujeto, argumentaba contra la literatura del arnés de benchmarks y capas envolventes. El marco de Böckeler es más fuerte — y eso afila el hueco que deja, porque el propio canon lo nombra. Tres veces.

Las preguntas abiertas del canon

El artículo cierra con la honestidad que distingue la buena escritura de ingeniería de la propaganda. Tres de sus problemas abiertos, en sus propios términos:

1. Coherencia — ¿cómo se mantienen sincronizados guías y sensores cuando el arnés crece? Una guía que promete una arquitectura mientras los sensores hacen cumplir otra es peor que no tener arnés.
2. Cobertura — ¿cómo se evalúa qué comprueba de verdad el arnés? No hay una forma establecida de medir si tus sensores vigilan lo que importa o solo lo que es fácil de vigilar.
3. Silencio — cuando una herramienta no reporta nada, ¿el código está limpio o el sensor está ciego? El silencio de una herramienta no se puede interpretar sin saber hacia dónde apuntaba.

No son detalles de implementación dejados como ejercicio. Son las preguntas estructurales — y comparten una raíz. Un arnés es un conjunto de controles alrededor de un acto: esta generación, este diff, esta sesión. Coherencia, cobertura y silencio son preguntas sobre un sujeto: qué ha declarado ser este proyecto, y si esa declaración se puede comprobar a lo largo del tiempo. No se pueden responder desde dentro del acto, por buenos que sean los controles.

Sensores que declaran su alcance

Empecemos por el silencio, porque tiene la respuesta más nítida: un check en verde que no dice qué miró es un arnés que miente por omisión. Esa línea es la bisagra de nuestra charla sobre las cuatro disciplinas, y es una regla de diseño, no un eslogan. En ontoref una verificación no devuelve un booleano; devuelve un veredicto ligado a un alcance declarado — se comprobó esta porción contra esta declaración — y el veredicto es un testigo firmado y direccionado por contenido. El silencio se vuelve interpretable: un check que pasa «por ausencia» — nada dentro de su alcance declarado — se distingue a simple vista de un check que examinó la cosa y la encontró sana. La pregunta de Böckeler — «¿calidad insuficiente o detección inadecuada?» — deja de ser filosófica en el momento en que el alcance forma parte de la salida del sensor y no de su documentación.

El mismo movimiento responde a la cobertura. La cobertura del arnés no se evalúa por intuición; se hace que cada sensor declare sus criterios por adelantado y emita veredictos atestiguados, y entonces la cobertura es una consulta, no una estimación. El ejecutor de auditorías de ontoref converge todos sus checks en un solo vocabulario — criterios declarados a la entrada, registros de veredicto a la salida, y la directiva (parar, rectificar, continuar) derivada mecánicamente del veredicto, nunca elegida por el autor del check. Un sensor cuya severidad es una opinión es un sensor con el que acabarás discutiendo.

Hay aquí un refinamiento que el canon no tiene, y es el que defenderíamos con más fuerza. No toda pregunta que un sensor vigila admite imposición. Parte de lo que un proyecto declara es binario — una restricción que un ADR congeló, un esquema del que depende un consumidor — y ahí el sensor debe fallar Hard. Pero otra parte de lo declarado son tensiones: dos polos que el proyecto mantiene abiertos a propósito, moviéndose entre ellos mientras madura. Un sensor que falla Hard sobre una tensión la colapsa hacia el polo que prefiriera el autor del check. Ontoref tipa esta distinción dentro del propio sensor: la severidad Hard solo es legal para preguntas que no son tensiones; un sensor que vigila una tensión solo puede reportar deriva y dirección, nunca fallo. Es un sensor que sabe qué preguntas tiene derecho a imponer. La regla no se afirma aquí: está tipada en ADR-050 —en inglés, como todos los ADR— y la comprobación se puede ejecutar. No hemos encontrado otro arnés que tipe la distinción, y preferimos que nos enseñen uno a ser los únicos que lo dicen.

La misma disciplina apunta hacia nosotros, y la cifra es justamente el argumento. Ejecuta hoy ontoref adr validate sobre este proyecto y reporta 199 restricciones que pasan, 4 violadas, 5 que el arnés no pudo evaluar — y 32 sin gate ninguno. Esa última es la cifra honesta: una restricción que nadie comprueba no es un suelo, es la descripción de uno. Con un arnés que publica su propia cobertura se puede discutir. Ésa es la propuesta entera.

La coherencia también se sensoriza

La pregunta del crecimiento — guías y sensores separándose — asume que guías y sensores son dos cosas que hay que mantener alineadas a mano. Se mantienen alineadas cuando ambas son proyecciones de un mismo sujeto declarado: la guía es lo que el sujeto sirve cuando se le consulta; el sensor es la comprobación de que el código sigue correspondiendo a la declaración. Cuando las dos comparten fuente, la incoherencia entre ellas no es un hallazgo de revisión; es un diff que la maquinaria puede detectar. Un observador de fondo vigila los artefactos de código por un lado y las declaraciones por otro, y cuando divergen emite una notificación de deriva — nunca aplica cambios por su cuenta; la reparación sigue siendo un acto deliberado. El bucle de gobierno que el canon describe como práctica humana — «cuando un problema se repite, mejora los controles» — se vuelve institución: deriva observada, encaminada a un backlog, resuelta en conocimiento aceptado o en una decisión registrada, y el automodelo que guías y sensores leen puede hacer fallar la CI cuando se vuelve incoherente.

Nada de esto exige poseer el todo. El modelo de confianza es explícitamente parcial: cualquier actor — humano o agente — puede verificar que una porción es coherente con lo declarado sin cargar conocimiento global del proyecto. Se renuncia a la completitud como base de la confianza; la reemplaza la suficiencia bajo verificación. Eso es lo que hace que la respuesta escale hacia abajo además de hacia arriba: no necesitas la pila completa del arnés para comprobar una operación contra una declaración.

Las «affordances» ambientales tienen generador

El concepto más silenciosamente importante del canon es la arnesabilidad: hay bases de código que responden al arnés y otras que se le resisten, y la diferencia son las «ambient affordances» — propiedades estructurales que hacen un entorno legible, navegable y tratable para los agentes. Los tipos permiten comprobar; las fronteras de módulo permiten reglas de arquitectura; los frameworks encogen el espacio de decisión.

Lee esa definición dos veces y deja de ser una propiedad que esperas que tu código tenga y pasa a ser algo que se puede instalar. Una declaración tipada y consultable de lo que el proyecto es — sus decisiones como restricciones, su vocabulario como contrato, su madurez como estado explícito — es una capa de affordances ambientales: hace el proyecto legible para cualquier arnés que pregunte, y es portable entre arneses y modelos precisamente porque vive fuera de ellos. Es la misma conclusión a la que el post anterior llegó desde el lado de la deriva, ahora alcanzable desde el lado del propio canon: ontoref no es un arnés rival. Es lo que hace a un proyecto arnesable — el sujeto que el arnés consulta.

El arnés ya tiene canon, y es bueno. Adopta su vocabulario. Después hazle sus tres preguntas abiertas a tu propia pila — y observa que cada respuesta exige algo que ningún arnés contiene: un sujeto, tipado y atestiguado, que sobrevive a la sesión.

El arco completo — del prompt al contexto, al arnés, al loop, y qué concedió cada disciplina a la siguiente — está en la charla «Del prompt al loop». El argumento del sujeto está en «Un arnés sin sujeto».

Lo que dejas dicho, alguien podrá comprobarlo.