Benchhand

Un MCP de desarrollo duradero y multiplataforma para personas que esperan que sus herramientas recuerden lo que estaban haciendo.

Benchhand es lo que ocurre cuando «funcionaba hasta que la conexión parpadeó» deja de ser una historia divertida de desarrollo.

Es una plataforma MCP de desarrollo construida en torno a estado duradero, mutaciones exactas, propiedad de procesos, recuperación y contratos aburridamente explícitos. El objetivo a largo plazo es fácil de decir y difícil de merecer: ser una alternativa práctica a DevSpace que sea más fiable, más portable y más fácil de confiar cuando el trabajo se pone serio.

Sin polvo mágico. Sin una pegatina de “con IA” que cubra un script de shell. Sin un mensaje de éxito porque una función no lanzó una excepción.

Benchhand sigue en pre-alpha. Los cimientos se están construyendo primero, porque reconstruir los cimientos después de que lleguen los usuarios es una manera maravillosa de aprender nuevas palabrotas.

La versión en 30 segundos

Benchhand está diseñado para dar a un cliente MCP un plano de control de desarrollo con:

• espacios de trabajo duraderos que sobreviven a los reinicios del edge de MCP;

• worktrees gestionados de Git sin tocar un checkout principal sucio;

• operaciones acotadas de lectura, listado y búsqueda de archivos;

• escrituras atómicas con precondiciones SHA-256;

• mutaciones deterministas que fallan ante la ambigüedad en lugar de adivinar;

• estado de operación duradero y reconciliación ante caídas;

• un edge de MCP sin estado frente a un daemon local duradero;

• semántica de primera clase para Windows, macOS y Linux;

• futuras capas de procesos persistentes, terminal, plugins, MCP externo, artefactos y CLI.

La filosofía no es “deja que la herramienta haga cualquier cosa”.

Es: deja que la herramienta haga cosas potentes, pero haz que el significado de esas cosas sea preciso.

Por qué existe Benchhand

Un MCP de desarrollo se vuelve mucho menos interesante cuando olvida el espacio de trabajo, pierde un proceso de larga duración, aplica silenciosamente un parche cercano o dice “éxito” mientras deja a medias el efecto secundario.

Benchhand trata todo eso como problemas de arquitectura, no de personalidad.

El proyecto se construye en torno a unas pocas ideas obstinadas:

1. El estado del transporte no es el estado de la aplicación. Una conexión MCP puede desaparecer. Tu espacio de trabajo no debería desarrollar amnesia con ella.

2. La mutación es un contrato. Si una escritura o un parche no puede demostrar sus precondiciones, debería fallar con evidencia en lugar de improvisar.

3. La recuperación es parte del camino feliz. Reinicios, estado obsoleto, efectos secundarios parciales, tiempos de espera y reintentos son condiciones normales de ingeniería.

4. Multiplataforma significa semántica, no compilación. “Compila en Windows” no es lo mismo que “significa lo mismo en Windows”.

5. Las pruebas son evidencia, no decoración. Las pruebas internas importan. También importan los clientes independientes, las herramientas de conformidad, las comprobaciones de caja negra, las auditorías y la inyección de fallos.

Ese último punto es importante. Una suite de pruebas en verde escrita por el mismo código que define el comportamiento es útil. No es una carta de recomendación.

Arquitectura actual

MCP client
   |
   v
+------------------------+
| Benchhand MCP edge     |   disposable / protocol-facing
+------------------------+
   |
   | OS-local RPC
   v
+------------------------+
| Benchhand daemon       |   durable ownership / orchestration
+------------------------+
   |             |
   |             +--------------------+
   v                                  v
+------------------------+   +------------------------+
| Workspace/filesystem   |   | Operation journal      |
+------------------------+   +------------------------+
   |                                  |
   +----------------+-----------------+
                    v
             +--------------+
             | SQLite state |
             | WAL + FULL   |
             +--------------+

El edge de MCP intencionadamente no es el dueño del estado de desarrollo duradero. Puede irse y volver. Eso es una característica, no un informe de incidente.

Lo que funciona hoy

La línea actual de desarrollo local tiene cimientos funcionales para:

Importante: “Implementado” significa implementado en la rama de desarrollo actual y sometido a los controles locales del proyecto. No significa “API pública estable” ni “versión lista para producción”.

Sin mutación basada en vibraciones

Benchhand no quiere ser ingenioso con tu árbol de código fuente.

Para las operaciones que cambian el estado, el contrato previsto es:

• precondiciones exactas;

• hashes o versiones cuando corresponda;

• objetivos deterministas;

• puntos de confirmación atómica;

• conflictos explícitos;

• sin retroceso silencioso;

• sin adivinación de líneas cercanas;

• sin parcheo difuso de “más o menos”;

• semántica de repetición y reintento que se declara, no se sobreentiende;

• protección contra mutaciones duplicadas cuando una operación puede repetirse.

Si Benchhand no puede demostrar que una mutación es exactamente la que pediste, el resultado correcto no es la creatividad.

El resultado correcto es un conflicto.

Seguridad sin esposas

Benchhand es una herramienta de desarrollo. Las herramientas de desarrollo necesitan poder.

Por lo tanto, el modelo de seguridad es deliberadamente práctico: proteger los límites del espacio de trabajo, la propiedad, la integridad de las mutaciones, las credenciales y las superficies expuestas externamente sin convertir cada operación útil en una ceremonia de permisos.

El proyecto prefiere:

• validación exacta del objetivo en lugar de denegación general;

• límites de capacidad en lugar de eliminación arbitraria de funciones;

• operaciones explícitas de alto poder en lugar de escalada oculta;

• operaciones reversibles cuando sea posible;

• evidencia estructurada cuando algo se rechaza.

En otras palabras: cinturones de seguridad, no un coche que se niega a salir del garaje.

Multiplataforma es un contrato

Windows, macOS y Linux son objetivos de primera clase.

Al núcleo no se le permite asumir a la ligera Bash, tmux, systemd, launchd, Homebrew, señales POSIX, permisos Unix, rutas Unix o PTYs Unix. Esos elementos pertenecen detrás de adaptadores de plataforma cuando se necesiten.

La regla es:

La misma operación de Benchhand debería tener el mismo significado en Windows, macOS y Linux, o fallar explícitamente cuando una plataforma no pueda ofrecer la garantía requerida.

La evidencia de desarrollo actual es más sólida en macOS. Benchhand no se autodenominará listo para multiplataforma solo porque TypeScript compile tres veces en CI. El comportamiento nativo de la plataforma debe probarse en la plataforma que afirma soportarlo.

Filosofía de pruebas

Benchhand utiliza desarrollo orientado a pruebas para los cambios de comportamiento.

Una característica no se considera terminada porque una prueba unitaria del camino feliz haya pasado. Se espera que el trabajo relevante cubra modos de fallo como estado obsoleto, conflictos, concurrencia, tiempo de espera, reinicio del daemon, caída dura, reintento, repetición, mutación duplicada, efectos secundarios parciales, fallo de limpieza, casos límite de rutas, enlaces simbólicos / junctions y diferencias entre plataformas.

Cuando corresponda, la finalización también requiere evidencia independiente como:

• clientes oficiales del SDK de MCP;

• MCP Inspector;

• herramientas de conformidad MCP;

• pruebas de procesos de caja negra;

• auditoría de dependencias y escaneo de vulnerabilidades;

• generación de SBOM;

• inspección de licencias;

• verificación nativa de la plataforma.

La política de lanzamiento es intencionadamente hostil a la frase «funciona en mi máquina».

Instalación

Todavía no hay un instalador público.

Si alguien te dice que ejecutes npm install -g benchhand hoy, o viene del futuro o intenta venderte algo.

Benchhand permanecerá en una línea de lanzamiento 0.x hasta que sus contratos públicos, empaquetado, comportamiento de recuperación y controles multiplataforma hayan ganado una versión estable.

Para contribuidores que trabajan desde el código fuente:

npm ci
npm run quality

Eso valida las reglas de formato/lint, las comprobaciones estrictas de TypeScript y las suites de pruebas del repositorio. El empaquetado en tiempo de ejecución y la CLI final benchhand son hitos posteriores.

Benchhand no es

• un reemplazo de Git;

• un multiplexor de terminal con una insignia de MCP;

• un fork de DevSpace;

• un motor de parches difusos con problemas de confianza;

• una excusa para confiar en cambios generados sin revisión;

• algo terminado.

El proyecto estudia ideas útiles de herramientas de desarrollo existentes, implementaciones de MCP, sistemas operativos y bibliotecas de código abierto. La arquitectura y los contratos son propios de Benchhand.

Hoja de ruta

La hoja de ruta pública está en ROADMAP.md.

La versión corta:

Secuencia de la hoja de ruta: cimientos fiables → sistema de archivos → runtime persistente → Git estructurado → plugins → puente MCP externo → CLI/artefactos → UI/pasarela → empaquetado multiplataforma → periodo largo de rodaje

El número de funciones no es el objetivo. Una función más pequeña que sobrevive a los fallos vale más que una función más grande que necesita un discurso motivador después de cada reinicio.

Contribuciones

Las contribuciones serán bienvenidas cuando se abra el repositorio público.

Por favor, lee CONTRIBUTING.md antes de enviar código. El proyecto valora cambios pequeños y revisables, pruebas que fallan antes de las correcciones, informes de errores reproducibles, contratos explícitos y evidencia que sobreviva más allá del portátil del autor.

Si tu pull request contiene un atajo ingenioso, está bien.

Si el atajo cambia el significado de una mutación bajo fallo, por favor trae aperitivos a la revisión.

Seguridad

Por favor, no reportes vulnerabilidades de seguridad en issues públicas.

Consulta SECURITY.md para ver el proceso de divulgación y el estado de soporte actual del proyecto.

Licencia

Benchhand está licenciado bajo la Apache License 2.0. Consulta LICENSE.

Los componentes de terceros permanecen bajo sus respectivas licencias. El proceso de lanzamiento público mantendrá un inventario de dependencias y avisos verificado por máquina.

El nombre

Un bench hand es la persona cercana al banco de trabajo: no es quien da una charla sobre el trabajo, sino quien ayuda a que el trabajo realmente se haga.

Esa es la descripción del puesto aquí.

Benchhand debería ser lo bastante útil como para desaparecer en el flujo de trabajo, lo bastante fiable como para que dejes de pensar en la recuperación, y lo bastante predecible como para que cuando se niegue a hacer algo, entiendas exactamente por qué.

Ese es el estándar.