Sparraは、長時間のソフトウェア開発を進めるためのビルドハーネスです。エージェントにプロンプトを渡すだけでは足りず、作業ごとにチェック可能なコントラクト、保存された状態、成果物を実行する評価役が必要だと考えて作りました。編集セッションから操作することも、キューを渡して無人で続けることもできます。
仕組み
計画役が作業を単位ごとに分けます。各作業では、実装を始める前にコントラクト作成役と評価役が少数の検証項目に合意します。実装役がそのコントラクトに沿って作り、別の評価役が差分を読み、検証コマンドと弱い入力を試して、証拠付きの判定を返します。Claudeが実装してCodexが判定する構成も、その逆も使えます。モデルの系統を分けることで、実装時と同じ見落としを評価側も持つ可能性を下げます。
Sparra自身のリポジトリで複数の役割が動いています。各項目のコントラクト、レポート、判定はディスクに保存されます。
共有状態はファイルシステムに置きます。各フェーズがディスクから入力を読み、結果を書き戻すので、モデル提供元の制限で止まっても、確認、差分表示、再開ができます。実装役にはコントラクトを渡しますが、評価役だけが使う非公開の確認項目は見せません。通過した変更は、対象プロジェクトのmainブランチではなくSparra用ブランチへコミットします。
成果物を実行する部分は、重要なセキュリティ境界でもあります。コマンド実行部は、既知のビルド・テストランナーと安全な引数の形を許可リストで管理します。シェルのメタ文字、インタープリターの評価フラグ、変更を加えるサブコマンド、タスク名だけを受け付ける場所に渡されたファイル名を拒否します。コマンドはシェルを使わずに起動します。危険な実行ファイルをすべて拒否リストへ追加する方法は、評価役が別のツールで同じ操作を試せば回避できるため採用しませんでした。
検証
評価役は、読みやすいコードだけを証拠にせず、届いた成果物を実行します。Appleプラットフォームのプロジェクトでは、アプリをビルドし、シミュレータを起動し、UIを操作してスクリーンショットを確認できます。ある実行では、起動画面がなくレターボックス表示になる問題を見つけました。別の実行では、実際のスコープ漏れと不完全な文書更新を見つけ、最初の実装を75点中72点で不合格にしました。
評価に失敗すると、作業は次の実装ラウンドへ戻ります。各フェーズが状態を記録するため、現在地を復元できます。
現在
Sparraには、対話的な役割実行と無人実行用のコンダクターがあります。非公開のHTTPブリッジを使うと、モデルの生出力や評価役専用の確認項目を公開せず、Tailscale経由でジョブを開始して監視できます。Sparra自身と、私のほかのプロジェクトも実際に作っています。評価役が、弱い検証項目を満たしながら意図した結果を出さない方法を見つけるたび、コントラクトとコマンドポリシーを更新しています。