Benchhand

何をしていたかをツールが覚えていることを期待する人々のための、耐久性のあるクロスプラットフォーム開発MCP。

Benchhandは、「接続が瞬断するまで動いていた」 が面白い開発エピソードでなくなる瞬間に生まれるものです。

これは、耐久性のある状態、厳密なミューテーション、プロセス所有権、リカバリ、そして退屈なほど明示的な契約を中心に構築された開発MCPプラットフォームです。長期的な目標は言うのは簡単ですが達成は難しいものです。作業が本格的になったときに、より信頼性が高く、より移植性が高く、より信頼しやすい実用的なDevSpaceの代替となること。

魔法の粉はありません。シェルスクリプトを覆う「AI搭載」ステッカーもありません。関数がたまたま例外を投げなかったからといって成功メッセージを出すこともありません。

Benchhandはまだプレアルファ段階です。土台が最初に構築されています。なぜなら、ユーザーが来てから土台を作り直すのは、新しい悪態を学ぶ素晴らしい方法だからです。

30秒バージョン

Benchhandは、MCPクライアントに開発コントロールプレーンを提供するように設計されています。

• MCPエッジの再起動後も存続する耐久性のあるワークスペース;

• 汚れたmainチェックアウトに触れずに管理されるGit worktree;

• 制限付きのファイル読み取り、一覧表示、検索操作;

• SHA-256前提条件付きのアトミック書き込み;

• 推測ではなく曖昧さで失敗する決定論的ミューテーション;

• 耐久性のある操作状態とクラッシュ調整;

• 耐久性のあるローカルデーモンの前にあるステートレスな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は、CIでTypeScriptが3回コンパイルされたというだけでは、クロスプラットフォーム対応とは呼びません。プラットフォームネイティブの動作は、それをサポートすると主張するプラットフォームでテストされる必要があります。

テスト哲学

Benchhandは動作変更に対してテストファースト開発を使用します。

1つのハッピーパス単体テストが通ったからといって、機能が完了したとは見なされません。関連する作業は、古い状態、競合、並行性、タイムアウト、デーモン再起動、ハードクラッシュ、再試行、リプレイ、重複ミューテーション、部分的な副作用、クリーンアップ失敗、パスのエッジケース、シンボリックリンク/ジャンクション、プラットフォームの違いなどの障害モードをカバーすることが期待されます。

該当する場合、完了には以下のような独立した証拠も必要です：

• 公式MCP SDKクライアント;

• MCP Inspector;

• MCP適合ツール;

• ブラックボックスプロセステスト;

• 依存関係監査と脆弱性スキャン;

• SBOM生成;

• ライセンス検査;

• プラットフォームネイティブ検証。

リリースポリシーは意図的に*「私のマシンでは動く」*というフレーズに好意的ではありません。

インストール

公開インストーラはまだありません。

今日、誰かがnpm install -g benchhandを実行するように言ったら、その人は未来から来たか、何かを売りつけようとしているかのどちらかです。

Benchhandは、公開契約、パッケージング、リカバリ動作、クロスプラットフォームゲートが安定版に値するまで、0.xリリースラインに留まります。

ソースから作業するコントリビューター向け：

npm ci
npm run quality

これにより、フォーマット/リントルール、厳格なTypeScriptチェック、リポジトリのテストスイートが検証されます。ランタイムパッケージングと最終的なbenchhand CLIは後のマイルストーンです。

Benchhandは～ではありません

• Gitの置き換え;

• MCPバッジを付けたターミナルマルチプレクサ;

• DevSpaceのフォーク;

• 信頼性問題を抱えたファジーパッチエンジン;

• レビューなしで生成された変更を信頼するための言い訳;

• 完成品。

このプロジェクトは、既存の開発ツール、MCP実装、オペレーティングシステム、オープンソースライブラリから有用なアイデアを研究しています。アーキテクチャと契約はBenchhand独自のものです。

ロードマップ

公開ロードマップはROADMAP.mdにあります。

短いバージョン：

ロードマップの順序：信頼性の高い基盤 → ファイルシステム → 永続ランタイム → 構造化Git → プラグイン → 外部MCPブリッジ → CLI/アーティファクト → UI/ゲートウェイ → クロスプラットフォームパッケージング → 長期バーンイン

機能数は目標ではありません。障害を乗り越える小さな機能は、再起動のたびにやる気スピーチが必要な大きな機能よりも価値があります。

コントリビューティング

公開リポジトリがオープンしたら、コントリビューションを歓迎します。

コードを送る前にCONTRIBUTING.mdをお読みください。プロジェクトは、小さなレビュー可能な変更、修正前の失敗テスト、再現可能なバグレポート、明示的な契約、作者のラップトップを超えて生き残る証拠を重視します。

プルリクエストに賢い近道が含まれていても問題ありません。

その近道が障害時のミューテーションの意味を変える場合は、レビューにお菓子を持ってきてください。

セキュリティ

公開イシューでセキュリティ脆弱性を報告しないでください。

開示プロセスとプロジェクトの現在のサポート状況については、SECURITY.mdを参照してください。

ライセンス

BenchhandはApache License 2.0の下でライセンスされています。LICENSEを参照してください。

サードパーティコンポーネントはそれぞれのライセンスの下にあります。公開リリースプロセスは、機械チェックされた依存関係と通知インベントリを維持します。

名前について

ベンチハンドとは、作業台の近くにいる人のことです。その作業について基調講演を行う人ではなく、実際に作業が完了するのを助ける人です。

それがこのプロジェクトの職務記述書です。

Benchhandは、ワークフローに溶け込んで存在感を消せるほど有用で、リカバリについて考えるのをやめられるほど信頼性が高く、何かを拒否したときにその理由を正確に理解できるほど予測可能であるべきです。

それが基準です。