Benchhand

Надёжный кроссплатформенный MCP для разработки, созданный для тех, кто ожидает, что их инструменты помнят, что они делали.

Benchhand — это то, что происходит, когда фраза «работало, пока соединение не моргнуло» перестаёт быть забавной историей из разработки.

Это платформа MCP для разработки, построенная вокруг долговечного состояния, точных мутаций, владения процессами, восстановления и намеренно явных контрактов. Долгосрочная цель проста в формулировке, но трудна в достижении: стать практичной альтернативой DevSpace, более надёжной, более портативной и более заслуживающей доверия, когда работа становится по-настоящему серьёзной.

Никакой магической пыли. Никакой наклейки «на базе ИИ», прикрывающей shell-скрипт. Никаких сообщений об успехе только потому, что функция случайно не выбросила исключение.

Benchhand всё ещё находится на стадии pre-alpha. Сначала создаётся фундамент, потому что перестраивать фундамент после прихода пользователей — отличный способ выучить новые ругательства.

Версия за 30 секунд

Benchhand создан, чтобы предоставить MCP-клиенту контрольную плоскость разработки со следующими возможностями:

• долговечные рабочие пространства, переживающие перезапуски MCP-периферии;

• управляемые Git-worktree без затрагивания грязной основной рабочей копии;

• ограниченные операции чтения, перечисления и поиска файлов;

• атомарные записи с предусловиями SHA-256;

• детерминированные мутации, которые завершаются ошибкой при неоднозначности, а не угадывают;

• долговечное состояние операций и сверка после сбоев;

• stateless-периферия MCP перед долговечным локальным демоном;

• первоклассная семантика Windows, macOS и Linux;

• будущие слои постоянных процессов, терминала, плагинов, внешних MCP, артефактов и CLI.

Философия не в том, чтобы «позволить инструменту делать что угодно».

Она в следующем: позволять инструменту делать мощные вещи, но делать значение этих вещей точным.

Почему существует Benchhand

MCP для разработки становится гораздо менее интересным, когда он забывает рабочее пространство, теряет долго работающий процесс, молча применяет «похожий» патч или сообщает об «успехе», оставляя половину побочного эффекта позади.

Benchhand рассматривает это как архитектурные проблемы, а не как особенности характера.

Проект построен вокруг нескольких упрямых идей:

1. Состояние транспорта — это не состояние приложения. MCP-соединение может исчезнуть. Ваше рабочее пространство не должно страдать амнезией вместе с ним.

2. Мутация — это контракт. Если запись или патч не могут доказать свои предусловия, они должны завершиться ошибкой с уликами, а не импровизировать.

3. Восстановление — часть счастливого пути. Перезапуски, устаревшее состояние, частичные побочные эффекты, таймауты и повторные попытки — обычные инженерные условия.

4. Кроссплатформенность означает семантику, а не компиляцию. «Оно собирается на Windows» — это не то же самое, что «оно означает одно и то же на Windows».

5. Тесты — это доказательства, а не украшение. Внутренние тесты важны. Независимые клиенты, инструменты проверки соответствия, проверки «чёрного ящика», аудиты и внедрение сбоев также важны.

Последний пункт важен. Зелёный набор тестов, написанный той же кодовой базой, которая определяет поведение, полезен. Но это не рекомендательное письмо.

Текущая архитектура

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   |
             +--------------+

Периферия MCP намеренно не является владельцем долговечного состояния разработки. Она может исчезнуть и вернуться. Это функция, а не отчёт об инциденте.

Что работает сегодня

Текущая локальная линия разработки имеет работающие основы для:

Важно: «Реализовано» означает, что функция реализована в текущей ветке разработки и прошла локальные проверки проекта. Это не означает «стабильный публичный API» или «релиз, готовый к продакшену».

Никаких мутаций по ощущениям

Benchhand не пытается быть хитрым вокруг вашего дерева исходников.

Для операций, изменяющих состояние, предполагаемый контракт таков:

• точные предусловия;

• хэши или версии там, где это уместно;

• детерминированные цели;

• точки атомарной фиксации;

• явные конфликты;

• никакого молчаливого отката;

• никаких догадок по соседним строкам;

• никакого размытого патчинга «достаточно близко»;

• семантика повтора и повторных попыток, которая заявлена, а не подразумевается;

• защита от повторных мутаций, если операция может быть воспроизведена.

Если Benchhand не может доказать, что мутация — именно та, которую вы запросили, правильный результат — не творчество.

Правильный результат — конфликт.

Безопасность без наручников

Benchhand — это инструмент разработки. Инструментам разработки нужна сила.

Поэтому модель безопасности намеренно практична: защищать границы рабочих пространств, владение, целостность мутаций, учётные данные и внешне доступные поверхности, не превращая каждую полезную операцию в церемонию выдачи разрешений.

Проект предпочитает:

• точную проверку цели вместо полного запрета;

• границы возможностей вместо произвольного удаления функций;

• явные операции с высокими полномочиями вместо скрытой эскалации;

• обратимые операции, где это возможно;

• структурированные доказательства, когда в чём-то отказано.

Другими словами: ремни безопасности, а не автомобиль, который отказывается выезжать из гаража.

Кроссплатформенность — это контракт

Windows, macOS и Linux — цели первого класса.

Ядру не разрешается бездумно предполагать наличие Bash, tmux, systemd, launchd, Homebrew, сигналов POSIX, прав Unix, путей Unix или Unix-PTY. Когда они нужны, они должны находиться за адаптерами платформы.

Правило таково:

Одна и та же операция Benchhand должна иметь одинаковый смысл на Windows, macOS и Linux либо явно завершаться ошибкой, когда платформа не может предоставить требуемую гарантию.

Текущие доказательства разработки наиболее сильны на macOS. Benchhand не назовёт себя готовым к кроссплатформенности только потому, что TypeScript собрался три раза в CI. Поведение, зависящее от платформы, должно тестироваться на той платформе, которая заявляет о поддержке.

Философия тестирования

Benchhand использует разработку через тесты для изменений поведения.

Функция не считается завершённой только потому, что один юнит-тест счастливого пути прошёл. Ожидается, что соответствующая работа покрывает такие режимы сбоев, как устаревшее состояние, конфликты, параллелизм, таймаут, перезапуск демона, жёсткий сбой, повторная попытка, воспроизведение, повторная мутация, частичные побочные эффекты, сбой очистки, крайние случаи путей, симлинки/джанкшены и различия платформ.

Где применимо, завершение также требует независимых доказательств, таких как:

• официальные клиенты MCP SDK;

• MCP Inspector;

• инструменты проверки соответствия MCP;

• тесты процессов «чёрного ящика»;

• аудит зависимостей и сканирование уязвимостей;

• генерация SBOM;

• проверка лицензий;

• проверка на нативной платформе.

Политика релизов намеренно недружелюбна к фразе «работает на моей машине».

Установка

Публичного установщика пока нет.

Если кто-то говорит вам сегодня выполнить npm install -g benchhand, он либо из будущего, либо пытается вам что-то продать.

Benchhand останется на линии релизов 0.x, пока его публичные контракты, упаковка, поведение при восстановлении и кроссплатформенные проверки не заслужат стабильную версию.

Для контрибьюторов, работающих из исходников:

npm ci
npm run quality

Это проверяет правила форматирования/линтера, строгие проверки TypeScript и тестовые наборы репозитория. Упаковка для рантайма и финальный CLI benchhand — более поздние вехи.

Benchhand — это не

• замена Git;

• терминальный мультиплексор со значком MCP;

• форк DevSpace;

• размытый патч-движок с проблемами уверенности;

• оправдание доверять сгенерированным изменениям без ревью;

• завершённый проект.

Проект изучает полезные идеи из существующих инструментов разработки, реализаций MCP, операционных систем и библиотек с открытым исходным кодом. Архитектура и контракты принадлежат самому Benchhand.

Дорожная карта

Публичная дорожная карта находится в ROADMAP.md.

Краткая версия:

Последовательность дорожной карты: надёжный фундамент → файловая система → постоянный рантайм → структурированный Git → плагины → внешний мост MCP → CLI/артефакты → UI/шлюз → кроссплатформенная упаковка → длительная обкатка

Количество функций не является целью. Небольшая функция, переживающая сбой, стоит больше, чем крупная функция, которой нужна мотивационная речь после каждого перезапуска.

Участие в разработке

Вклад приветствуется, как только откроется публичный репозиторий.

Пожалуйста, прочитайте CONTRIBUTING.md, прежде чем отправлять код. Проект ценит небольшие проверяемые изменения, падающие тесты до исправлений, воспроизводимые отчёты об ошибках, явные контракты и доказательства, которые переживают ноутбук автора.

Если ваш pull request содержит хитрый трюк — это нормально.

Если трюк меняет смысл мутации при сбое, пожалуйста, принесите закуски на ревью.

Безопасность

Пожалуйста, не сообщайте об уязвимостях безопасности в публичных issue.

Смотрите SECURITY.md для описания процесса раскрытия и текущего статуса поддержки проекта.

Лицензия

Benchhand лицензируется под Apache License 2.0. Смотрите LICENSE.

Сторонние компоненты остаются под их соответствующими лицензиями. Публичный процесс релиза будет поддерживать проверяемую машиной опись зависимостей и уведомлений.

Название

Bench hand — это человек, находящийся рядом с верстаком: не тот, кто читает доклад о работе, а тот, кто помогает работе действительно выполняться.

Это описание работы здесь.

Benchhand должен быть достаточно полезным, чтобы растворяться в рабочем процессе, достаточно надёжным, чтобы вы перестали думать о восстановлении, и достаточно предсказуемым, чтобы, когда он отказывается что-то делать, вы точно понимали, почему.

Это стандарт.