SERIE AI-NATIVE · HARNESS ENGINEERING

Todo Es un Plugin. Los Calibres Son el Trabajo.

Por Paul Jialiang Wu · agentic-portfolio-lovat.vercel.app · 2026-08-17

1. Cuatro días, 147,620 estrellas, y el titular equivocado

deepseek-ai/deepseek-harness (dsh) se hizo público el 13 de agosto 2026-08-13 bajo licencia MIT. Cuando consulté la API de GitHub el 17 de agosto, marcaba 147,620 estrellas, 15,083 forks, con el último push esa misma mañana. La cobertura mediática lo enmarcó como una jugada competitiva — un runtime abierto apuntado a Claude Cowork, una empresa de modelos reclamando la capa por encima del modelo.

Ese encuadre probablemente sea correcto, pero a mí no me resulta útil. La velocidad de estrellas te habla de distribución, no de ingeniería. Así que hice lo que el propio repositorio AGENTS.md recomienda — "We recommend using an agent to explore the codebase" (Traducción: Recomendamos usar un agente para explorar el código base) — cloné sus 81 MB, y me puse a buscar reglas que pudiera robarme.

Encontré una que me hizo cerrar la laptop por un minuto, porque es un mecanismo para una disciplina que llevaba dos semanas reclamando en prosa y que nunca había construido.

2. Lo que realmente leí, y cómo

Cuatro ventanas de investigación, que es como acoto cualquier cosa sobre la que pienso actuar: de qué se habla ahora, qué pasó de demo a default en treinta meses, qué sigue siendo estructural después de treinta años, y qué sobrevivió trescientos. Esta última ventana no es decoración. Es la única lo bastante larga como para haber matado las ideas que solo sonaban bien.

Solo fuentes primarias, y contadas en lugar de hojeadas:

• el repositorio mismo: docs/architecture.md, raíz y paquete AGENTS.md, docs/testing.md, el árbol .agents/notes/, scripts/, y un invariant.ts real de cada categoría;
• Agent Harness Engineering: A Survey — una revisión de 37,794 palabras de CMU, UAB, Tulane, Yale, Northeastern, Stanford, Amazon, UChicago, Virginia Tech y Rutgers, que mapea más de 170 proyectos de código abierto sobre una taxonomía de siete capas;
• el registro marítimo y de manufactura para las dos ventanas largas, verificado contra fuentes de museos y estándares en lugar de recordado de memoria.

Todo lo numérico a continuación es o bien un conteo que hice yo mismo, o una cifra citada de una fuente identificada. Donde no pude verificar algo, lo digo.

3. La única regla que vale la pena robar

De packages/AGENTS.md, textual:

Cada paquete es dueño de una relación,./invariant. y esa relación se prueba: registra el nombre del manifiesto; verifica una relación evento/dato o dale a los instaladores vacíos razones específicas del paqueteNo runtime invariant: Los acompañantes invariantes generados sin más, los vacíos sin explicar y los reporteros ignorados hacen fallar la compuerta.verify-package-invariants.

Lo que medí en su árbol:

Un vacío explicado real, de packages/code-runtime/code-runtime/src/invariant.ts:

/**
 * No runtime invariant: this package exposes no independent event sequence or mutable
 * data relation beyond contracts enforced at its owning seam.
 */
const install: InvariantInstaller = () => {}

Lee de nuevo la proporción: 84% del resultado es una declaración firmada de que no hay nada que afirmar. Un colega que vea esto pensará que es desperdicio. Yo veo el diseño completo. El producto de la compuerta no son 35 afirmaciones; son 184 oraciones con las que un humano puede estar en desacuerdo, en lugar de 184 silencios con los que nadie puede.

Y luego la frase que de verdad me dolió, porque describe cada compuerta de deriva que he escrito en mi vida:

Runtime invariants assert owned relationships. Verifica flujos de eventos autoritativos o datos mutables, not service or method presence (Traducción: no la presencia de servicio o método), metadatos o efectos de plugins, o ejemplos puros fijos. Sin una relación plausible, un acompañante vacío y explicado es correcto.

Mi harness tiene una compuerta de deriva que falla si un comando documentado no existe. Tiene un doctor que falla si el hash del CLI instalado difiere del de la fuente. Ambas son verificaciones de presencia. Detectan un cambio de nombre. Pasarán, en verde, para siempre, en un módulo que lleva mal desde el día en que se escribió — que es exactamente el fallo que sigo enviando a producción. Hace seis días publiqué un lector de tarjetas bilingüe con 945 pruebas en verde y encontré dos defectos reales al escucharlo. La presencia nunca fue el problema.

4. 1785: la afirmación sale barata, los calibres son el trabajo

El 8 de julio de 1785, en el patio del Château de Vincennes, Honoré Blanc hizo algo más radical que construir piezas modulares: desarmó cerrojos de mosquete, mezcló las piezas entre sí y las volvió a ensamblar. No presentó un diseño y lo defendió con argumentos. Barajó componentes reales frente a testigos y dejó que el resultado hablara por sí solo.

Para hacerlo posible construyó 63 calibres. No 63 máquinas — 63 instrumentos de verificación. Jean-Baptiste de Gribeauval ya había formalizado el calibre pasa/no pasa para las balas de cañón, que responde a una pregunta más sutil que "¿esta pieza tiene el tamaño correcto?": pregunta si una pieza cae dentro de una banda de tolerancia, y devuelve exactamente una de dos respuestas: aceptar o rechazar.

Y aquí llega la parte que enfría los ánimos. Springfield Armory adoptó la ambición en la década de 1810, tenía 11 calibres maestros hacia 1825 — y no logró la intercambiabilidad real sino hasta 1849. Sesenta y cuatro años entre la demostración de Blanc y piezas que encajan de manera confiable a escala. La idea nunca fue el cuello de botella. Los instrumentos sí lo fueron.

Esta es la lente que me permitió entenderdsh el anuncio. «Todo es un plugin» es la ambición de Springfield en la década de 1810, reformulada con un sistema de tipos. Lo interesante es que lanzaron 219 calibres y 36 estaciones de inspección el mismo día que hicieron el anuncio. Y la demostración de Blanc de mezclar y reensamblar tiene un descendiente directo en su política de pruebas: "Registry contributions prove disposal through the HMR-safety test: dispose the fiber and observe removal." (Traducción: Las contribuciones al registro demuestran la eliminación mediante la prueba de seguridad HMR: se elimina la fibra y se observa su remoción.) No certificas que un plugin pueda descargarse leyendo su código. Lo descargas y observas.

5. 1876: un límite que te pintas tú mismo no es un límite

El segundo hallazgo histórico es el que convirtió esto de una lectura interesante en un diagnóstico de mi propio trabajo.

En la década de 1870, los barcos mercantes británicos eran sobrecargados deliberadamente y se perdían, asegurados, junto con sus tripulaciones — barcos ataúd. Samuel Plimsoll consiguió una Comisión Real en 1872 y luego la Merchant Shipping Act de 1876, que hizo obligatoria una marca de línea de carga: un disco de doce pulgadas con una línea de dieciocho pulgadas que lo atraviesa, pintado a la altura del centro del casco en ambos costados. Un límite estricto, visible desde el muelle, exigido por ley.

Salvo que la Ley de 1876 "left the shipowner to decide where on the hull to paint it" (Traducción: dejaba que el propio armador decidiera en qué parte del casco pintarla).

La Junta de Comercio publicó tablas de línea de carga en 1886; la posición quedó fijada por ley en 1890, y se terminó de asentar en 1894. Así que la secuencia es: catorce años entre "you must declare a limit" (Traducción: debes declarar un límite) y "you do not get to choose your own limit." (Traducción: no te corresponde elegir tu propio límite.) La primera ley hizo visible la sobrecarga. La segunda logró que se detuviera.

Ahora mira mis propios instrumentos con esto en mente.

• Mi archivo de habilidades del agente tiene un presupuesto de bytes que una prueba hace cumplir. Yo elegí el número, y el propio mensaje de error de la prueba dice que se puede elevar un tope "when the required content genuinely needs more space." (Traducción: cuando el contenido requerido realmente necesita más espacio). Yo lo elevé. Autopintado.
• Cada entrega en mi sistema archiva un boletín con resultados clave puntuados de 0 a 1. Los niveles de evidencia limitan el puntaje, y una aguja lo limita de nuevo según la consecuencia — restricciones reales. Pero el propio autor sigue fijando las metas. Mi propio registro de campaña ha arrastrado este hilo abierto durante semanas, en mis propias palabras: "the Mate still sets its own targets, and sets them low." (Traducción: el Mate sigue fijando sus propias metas, y las fija bajas). Lo había diagnosticado y lo había dejado ahí.
• dsh no está exento: su manifiesto de presupuesto de documentación son nueve enteros elegidos a mano (AGENTS.md: 1950 palabras, docs/architecture.md: 2400 …) y su propia regla permite elevar un tope. La misma línea de Plimsoll, pintada por el dueño.

La regla generalizable, y hizo falta una ley naviera de 150 años para plantearla con claridad: un umbral fijado por la misma parte a la que ese umbral restringe es una divulgación, no un control. Ambas cosas valen la pena tenerlas. Solo una de las dos salva barcos. Saber cuál de las dos tienes es todo el juego.

6. 2024–2026: dónde dice la literatura que están los agujeros

Agent Harness Engineering: A Survey mapea más de 170 proyectos sobre ETCLOVG — Execution, Tool interface, Context management, Lifecycle/Orchestration, Observability, Verification, Governance — y su hallazgo agregado apunta exactamente a donde yo ya estaba parado:

Execution, tool interfaces, lifecycle orchestration, and verification have the densest visible coverage… (Traducción: la ejecución, las interfaces de herramientas, la orquestación del ciclo de vida y la verificación tienen la cobertura visible más densa…) Observability and governance are thinner in open-source coverage (Traducción: la observabilidad y la gobernanza tienen una cobertura más delgada en el código abierto) y aparecen con más frecuencia a través de plataformas comerciales, funciones de SDK o artículos de ingeniería, lo que sugiere que el control operativo maduró más tarde que la infraestructura de runtime y de benchmarks.

Cuatro hallazgos de ese paper que cambiaron lo que planeaba construir:

La mayoría de las fallas de los agentes no son fallas del modelo. AgentFixer, desplegado contra el sistema de producción CUGA de IBM con 15 herramientas de validación, alcanzó entre 64% y 88% de detección de fallos y encontró que 38% de los fallos de tareas se deben a errores de parsing —descrito por los autores como "a failure mode fully addressable by deterministic checks." (Traducción: un modo de fallo completamente abordable mediante verificaciones determinísticas). Más de un tercio de los fallos en un sistema de agentes en producción eran mecánicos. Ese es el argumento empírico a favor de las compuertas, y pesa más que cualquier argumento basado en el gusto.

Todos observan; apenas la mitad evalúa. El paper cita la encuesta 2026 de LangChain: 89% of teams use observability, 52.4% run offline evaluations (Traducción: el 89% de los equipos usa observabilidad, el 52,4% ejecuta evaluaciones fuera de línea). Los autores lo llaman la brecha observabilidad-evaluación, y nombran la consecuencia con precisión: "teams can see what agents did without systematically judging whether the behavior was correct." (Traducción: los equipos pueden ver lo que hicieron los agentes sin juzgar sistemáticamente si el comportamiento fue correcto).

Los puntajes finales son el instrumento equivocado. Del §12.3: "a failed rollout may originate from model reasoning, a misleading tool schema, sandbox misconfiguration, stale context, flaky tests, benchmark ambiguity, judge instability, or orchestration loops." (Traducción: un despliegue (rollout) fallido puede originarse en el razonamiento del modelo, un esquema de herramienta engañoso, una mala configuración del sandbox, contexto obsoleto, pruebas inestables, ambigüedad del benchmark, inestabilidad del juez, o bucles de orquestación). La recomendación es la evaluación nativa de trazas (trace-native) —las trazas como objeto primario, no el número final— y aparece listada como un problema abierto, no como práctica resuelta.

La orquestación multi-repositorio es una brecha del ecosistema con nombre propio. Una de cinco brechas que "recurren en los límites entre capas", junto con la atribución de costos, la recuperación ante fallos, la interoperabilidad entre herramientas y el traspaso humano-agente. Mis herramientas de flota han estado viviendo en esa brecha durante un mes sin saber que tenía nombre.

Y un principio del mismo paper que justifica retroactivamente lo menos popular que hago —borrar mi propio texto de prompt:

The harness-as-assumption principle. (Traducción: el principio del harness como supuesto). Cada componente del harness codifica un supuesto sobre lo que el modelo no puede hacer por sí solo. A medida que los modelos mejoran, los sistemas de observabilidad deben detectar no solo cuándo fallan los agentes, sino también cuándo los componentes del harness se han vuelto unnecessary overhead (Traducción: sobrecarga innecesaria).

7. Tres frentes, y lo que ya está construido

Las cuatro ventanas convergen en una sola frase: afirma una relación real, demuéstrala sobre la salida ensamblada real, y no dejes que el autor fije el propio listón. Eso se descompone en tres programas. Construí el primero esta semana. Estoy especificando los otros dos y diciendo con todas sus letras que no están construidos, porque la alternativa es lo que hice hace seis días —enviar a producción una capacidad escrita contra una API publicada que nunca se había ejecutado, para descubrir a los diez minutos de instalarla que dos de mis supuestos estaban equivocados.

I+D 1 — Invariante-o-explica, por módulo, forzado por la compuerta (construido)

anyagent invariants [repo] [--fleet] [--gate --baseline …]. Cada módulo debe llevar una de dos declaraciones en su encabezado:

Runtime invariant: concatenating a text's segments reproduces that text EXACTLY, so
segmentation can never drop or duplicate a character.
@invariant-test: test_invariant_segmentation_is_lossless

…o una No runtime invariant: <reason> explícita. Cuatro estados: asserted (nombra una relación y una prueba que existe), declared (vacío honesto, con una razón), absent (la violación), broken (afirma una relación pero no nombra ninguna prueba, o nombra una que no existe).

Tres decisiones de diseño que vale la pena defender. Un vacío honesto cuenta como cubierto — si fallara, los autores inventarían aserciones huecas para pasar la compuerta, lo cual es peor que "aquí no hay nada". La compuerta se niega a juzgar la calidad: si un invariante es un buen invariante es una cuestión de revisión, y un script que pretendiera decidirlo reconstruiría la verificación de presencia un nivel más arriba. Sin línea base, falla en vez de pasar, porque un verde sin fundamento es exactamente el defecto que todo este ejercicio busca evitar.

Escribir los cuatro invariantes dio frutos de inmediato. Afirmar que mi segmentador de idiomas no pierde información me obligó a intentar romperlo, así que lo sometí a fuzzing con 20,000 cadenas bilingües aleatorias antes de afirmar nada, y guardé una versión sembrada de 4,000 casos para que una falla sea reproducible en vez de un fallo intermitente. Resistió. Pero jamás habría corrido ese fuzzing si la declaración no me hubiera obligado a nombrar una prueba — el invariante fue el mecanismo forzador, no la prueba.

I+D 2 — Evidencia nativa de trazas: instantáneas de la transcripción ensamblada (especificado, no construido)

dsh tiene una regla que no puedo rebatir y que no he implementado:

Modelo-visible ⟺ registrado: todo lo que llega a una solicitud de modelo debe poder reconstruirse a partir del registro de sesión; una nueva entrada visible para el modelo requiere un evento de sesión.

…reforzado por un invariante de runtime, con una política de pruebas equivalente: "Package tests, e2e assertions, mock/test-only compositions, and PR rationale do not replace the assembled transcript." (Traducción: las pruebas de paquete, las aserciones e2e, las composiciones mock/solo-para-pruebas y la justificación del PR no sustituyen la transcripción ensamblada.) Su documento de cobertura añade la línea que quiero grabar en el mío propio: "Line coverage is necessary, never sufficient — it proves lines ran, not that the feature works as shipped." (Traducción: la cobertura de líneas es necesaria, nunca suficiente: prueba que las líneas se ejecutaron, no que la función funciona tal como se entregó.) Y, maravillosamente: "An uncovered line is often dead code the gate is correctly flagging for deletion, not a missing test to bolt on." (Traducción: una línea sin cubrir suele ser código muerto que la compuerta está señalando correctamente para su eliminación, no una prueba faltante que haya que añadir a la fuerza.)

Mi evidencia de que necesito esto es reciente y bochornosa. 945 pruebas unitarias en verde; dos defectos encontrados poniéndome el resultado en los oídos. Una frase recortada arrastró una invitación de "cuéntame más" hasta la mitad de un informe, de modo que sonaba terminado antes de empezar. Un resultado clave en singular se leyó como plural. Ninguno de los dos es detectable en una prueba unitaria de una función pura; ambos son evidentes en una sola grabación. Blanc no inspeccionó los planos: mezcló las piezas. La regla heredera de Springfield Armory dice que hay que desechar la fibra y observar su eliminación. La mía debería decir: reproducir la salida ensamblada y compararla con un diff.

I+D 3 — Umbrales fijados externamente (especificado, no construido)

La corrección Plimsoll. Cada umbral de la flota se clasifica como autoimpuesto o fijado externamente, y los autoimpuestos se etiquetan como tales dondequiera que se reporten. Un presupuesto que yo elegí, una meta que yo mismo califiqué, un umbral de cobertura que yo escogí: cada uno es una divulgación, y debería imprimirse como tal. La lección de 1876→1890 es que la visibilidad va primero y no basta; el paso intermedio honesto es dejar de permitir que una línea pintada por uno mismo se lea como una marca de inspección independiente.

8. Lo que midió en mí: 0.27%

Apunté la nueva compuerta a 27 repositorios en esta máquina. Primera corrida, sin corregir:

A modo de comparación: dsh en 219/219 el día en que se hizo público.

Dos cosas sobre publicar ese número. Primero, es el resultado correcto — la herramienta que califica todo lo que entrego bajo la doctrina de "no evidence means not measured" (Traducción: sin evidencia no hay medición) nunca había declarado qué debe cumplirse siempre en sus propios módulos. La doctrina sin un mecanismo es solo un estado de ánimo. Segundo, es "ratcheted, not absolute" (Traducción: progresiva, no absoluta): 1.501 módulos silenciosos harían que una compuerta absoluta quedara en rojo para siempre, y una señal que nunca cambia deja de leerse. Un módulo silencioso nuevo hace fallar la corrida semanal. El silencio heredado es una deuda con un número asignado, que es la diferencia entre un backlog y una simple sensación.

Las cuatro declaraciones son relaciones reales, no comprobaciones de presencia: la segmentación no pierde datos (verificada con fuzzing); un resultado de la reproducción (playback) conserva sus partes; cada tema hablado cabe en su presupuesto tanto en inglés como en chino; y una selección vacía de motor de voz siempre lleva una razón — esta última es la regla de no-fallback-silencioso, finalmente expresada como una propiedad de los datos en lugar de una promesa en un docstring.

Una corrección que le debo a este artículo, ganada mientras lo publicaba

Publicar esta pieza hizo fallar mi propio CI dos veces, y ambos fallos fueron exactamente el patrón que llevo 3.000 palabras diciendo que a mi flota le falta.

El primero: un archivo de promoción debe llevar una URL, una publicación de LinkedIn, un comentario y un hilo, o la compilación falla. Lo publiqué sin el hilo. El segundo es el mejor de los dos — un artículo debe tener traducciones en cuatro idiomas o un aplazamiento explícito, fechado y con vencimiento, y el mensaje de error de la propia compuerta dice: "no translation AND no explicit deferral — the silent-gap state this gate exists to forbid." (Traducción: ni traducción ni aplazamiento explícito — el estado de vacío silencioso que esta compuerta existe para prohibir.)

Eso es invariante-o-explica. Lleva semanas corriendo en mi repositorio de portafolio. Incluso tiene el vencimiento que mi nueva compuerta no tiene: un aplazamiento de más de 90 días falla. Así que la versión honesta del 0,27% es más acotada de lo que sugiere el número del titular — la flota casi no tiene invariantes de runtime a nivel de módulo, y sí tiene esta disciplina a nivel de repositorio, en al menos un lugar, construida antes de que yo leyera nada de DeepSeek. No conecté ambas cosas hasta que una compuerta que yo mismo escribí se negó a publicar un artículo sobre compuertas.

Lo cual es el argumento, llegando desde la dirección equivocada: el mecanismo ya estaba en mis manos y no podía verlo, porque no estaba nombrado como regla general en ningún lado. Leer el código de otra persona muchas veces no es aprender una idea nueva. Es que te den un nombre para algo que ya usabas en un solo lugar y nunca habías generalizado.

9. Lo que deliberadamente no copié

Al leer un repositorio impresionante, el modo de fallo es la imitación. Tres cosas que dejo intactas, con sus razones:

219 paquetes. Esa granularidad viene con un equipo y una compuerta de cobertura del 100% por archivo. Para una flota de una sola persona más agentes produciría ceremonia, no claridad. Róbate el calibre, no el organigrama.

693 Agent Notes. Para un repositorio con cuatro días de vida pública, eso implica una larga historia privada, no una meta. Lo que sí estoy robándome es el ciclo de vida: proposed/ → implemented/ → archived/, un conjunto cerrado de estados, y una regla excelente: una nota archivada está "permanently frozen and must not be treated as authority for current behaviour" (Traducción: "permanentemente congelada y no debe tratarse como autoridad para el comportamiento actual"). Documentos obsoletos citados como verdad es un modo de fallo que yo tengo y que no había nombrado.

"Do not use metaphors." (Traducción: "No usar metáforas.") Su estándar de prosa las prohíbe y exige sustantivos exactos en lugar de contrato, límite, forma. Para la prosa de contratos eso es sencillamente correcto, y lo he adoptado ahí. Pero mi sistema narra cada entrega como un capítulo de una sola historia continua, deliberadamente, para un lector que no va a leer un registro de cambios, con calificaciones y evidencia impresas textualmente al lado, nunca dentro. Ambas reglas son correctas en su propio dominio. El error sería aplicar cualquiera de las dos en todas partes.

10. Cómo se aplica esto, no solo se anota

Enviado esta semana, para que el hallazgo no decaiga en un simple marcador: la compuerta existe como comando; el flujo semanal de la flota la ejecuta con el mismo trinquete que la auditoría de seis dimensiones y sube su reporte como artefacto; la línea base queda confirmada; el contrato vive en el manual de actualización como el §8 junto al 0.27% medido; y 22 pruebas nuevas cubren la compuerta y los cuatro invariantes declarados, incluyendo el caso en que la compuerta no tiene línea base y debe negarse a pasar.

La mitad proactiva es una regla para el trabajo nuevo, no un proyecto de limpieza. Un módulo nuevo declara su invariante o su razón cuando se escribe, mientras el autor todavía recuerda qué debe ser siempre verdad. Retroadaptar 1,505 módulos no es la meta y en su mayoría produciría 1,505 oraciones huecas. La meta es que el número solo se mueva en una dirección.

Límites honestos

• Cuatro días no son un historial. dsh está en vista previa para desarrolladores y lo dice bien alto: "THERE WILL BE COMPATIBILITY-BREAKING CHANGES." (Traducción: HABRÁ CAMBIOS QUE ROMPEN LA COMPATIBILIDAD.) Estoy reportando sus disciplinas, que puedo leer y contar, no su durabilidad, que todavía nadie puede conocer.
• Ejecuté la lógica de sus compuertas, no sus compuertas. Mis conteos vienen del sistema de archivos — paquetes, acompañantes invariantes, vacíos explicados, archivos de compuerta, notas. No ejecuté su CI.
• Mi 0.27% depende de mi propia definición de módulo. Acoto el alcance a la raíz del código fuente del motor y excluyo tests, marcadores de paquete, archivos de tipos puros y árboles vendorizados. Una primera pasada que escaneó todo devolvió 196 módulos para este repo en lugar de 178. Distinto alcance, distinto denominador.
• Dos de los tres programas no están construidos. I+D 2 y 3 están especificados. Decir lo contrario sería exactamente el error que cometí la semana pasada.
• Las cifras del survey son suyas, no mías. La proporción 89%/52.4%, el hallazgo del 38% de errores de parsing y el rango de detección de 64–88% están citados de fuentes nombradas en ese paper; no he replicado ninguna de ellas.

Una cifra más para el camino. Entre la demostración de Blanc y los mosquetes intercambiables a escala: 64 años. Entre "declare a load limit" (Traducción: declare un límite de carga) y "you may not choose your own load limit" (Traducción: no puede elegir su propio límite de carga): 14 años. Ambas brechas se llenaron construyendo instrumentos, no teniendo ideas. Si tu harness es una arquitectura de plugins sin calibres, estás en 1785 — lo cual está bien, siempre que sepas en qué año estás.

Fuentes

1. deepseek-ai/deepseek-harness — repositorio, docs/architecture.md, AGENTS.md, packages/AGENTS.md, docs/testing.md, .agents/notes/README.md, scripts/. Conteos tomados de un clon superficial el 2026-08-17; metadatos (147,620 estrellas · 15,083 forks · creado 2026-08-13) de la API de GitHub ese mismo día.
2. Cordis y A Programming Paradigm for Spatiotemporal Composability — el framework de plugins dsh está construido sobre esto.
3. Li, Xiao, Zhang, Liu et al., Agent Harness Engineering: A Survey (el ejemplar que leí y del que cito; también está en OpenReview como eONq7FdiHa, que muestra un muro de verificación de navegador en lugar del PDF) — taxonomía ETCLOVG, mapeo de más de 170 proyectos, la brecha entre observabilidad y evaluación, el harness-as-assumption principle (Traducción: el principio del harness como suposición), problemas abiertos del §12.
4. RUCAIBox/awesome-agent-harness — el índice de proyectos que acompaña al survey.
5. Royal Museums Greenwich — Samuel Plimsoll and ship safety y Lloyd's Register Foundation Heritage — What is the Plimsoll line? — Merchant Shipping Act de 1876, la posición elegida por el propietario, tablas del Board of Trade de 1886, posición fijada por ley en 1890.
6. 230 Years of Interchangeable Parts y go/no-go gauge — la demostración de Blanc de 1785 y sus 63 calibres, las bandas de tolerancia de Gribeauval, los 11 calibres maestros de Springfield Armory hacia 1825 y la intercambiabilidad lograda en 1849.
7. Chatterbox, Qwen3-TTS — el trabajo de voz con acceso restringido por licencia (licence-gated) referenciado como evidencia propia de esta semana.