Harness Distiller（Agent Harness 蒸留器）

公開エビデンスを実装可能・検証可能・アップグレード可能な Agent Harness に蒸留します。製品名は「動作と能力のレシピ」として扱い、ブランド、専有プロンプト、保護対象素材、または検証不能な内部実装を複製しません。

必須遵守事項

code、official-doc、protocol、behavior、inference を区別し、クローズドソース製品の推論をソースコードの事実として書かないこと。
4つの成熟度レベルは同一のプロトコル、状態モデル、モジュール境界を共有し、アップグレードでは能力の追加と最適化のみを行い、互換性のない4つのエンジニアリングセットを生成しないこと。
まず垂直スライスを通すこと：モデル → Agent loop → 1つの読み取りツール → 権限 → 実行 → イベント → 状態 → インターフェース。
runtime は headless を維持し、CLI、TUI、IDE、Desktop、Web はバージョン管理された command/event プロトコルを介してのみ対話する。
approval policy と sandbox enforcement を分離し、ユーザー承認で OS、コンテナ、パス、ネットワークの強制境界を代替しないこと。
各「実装済み」にはコード上の位置、「検証済み」には実行可能テストまたは再現可能な挙動のエビデンスが必要。
「モデルがシェルを呼び出せる」ことを完全な Harness と見なさないこと。キャンセル、失敗、復旧、永続化、権限、インターフェース状態の再構築を実装すること。

必要に応じて参照

製品の選択とカタログの完全性確認：references/catalog.md を読む。
レベルの選択またはレベル間のアップグレード：references/levels.md を読む。
各 capability をいつ verified とマークできるかの判断：references/capabilities.md を読む。
エビデンスの信頼性判断：references/evidence.md と references/source-registry.md を読む。
共有境界の理解：references/architecture.md を読む。
実装コードを書き始める前に：references/implementation/index.md を必ず読み、そのルーティングに従って実装仕様をロードする。
共有能力の選択：references/knowledge/index.md を読み、ブループリントで選択された知識モジュールのみをロードする。
製品の複製：references/products/<product>/index.md を読み、インデックスで指定された順序でその製品の13のドシエをロードする。
新規プロジェクト：references/workflows/build.md を読む。
既存プロジェクトのアップグレード：references/workflows/upgrade.md を読む。
プロジェクトの検収：references/workflows/validate.md を読む。

リクエストの解析

ユーザーリクエストとターゲットリポジトリから以下を解析する：

recipe：製品、hybrid、または custom
level：runnable、usable、productive、または polished
surfaces：cli、tui、ide、desktop、web、sdk、headless
execution：local、container、remote、またはこれらの組み合わせ
stack：優先的にターゲットリポジトリのものを使用。新規プロジェクトは製品の表面とセキュリティ要件に基づいて選択。
providers：モデルプロバイダー、ローカルモデル、能力低下要件。
security：個人、チーム、または企業の脅威モデル。
distribution：ソースコード、パッケージ、拡張機能、デスクトップアプリ、またはホスト型サービス。

ユーザーが「Codex/Claude Code/QoderWork のようなものを作って」とだけ言った場合、デフォルトで対応するレシピ、usable、製品の主表面に加えて headless を選択し、その仮定を決定記録に書き込む。

その他の選択がない場合は、フォールバックデフォルト値を使用する：execution=local、security=personal、distribution=source。Codex 風は Rust + headless/TUI、Claude-Code 風は TypeScript + headless/CLI、QoderWork 風は TypeScript + Tauri/Rust executor + headless/Desktop、Aider 風は Python + headless/CLI、OpenCode 風は TypeScript/Bun + headless/TUI、OpenHands 風は Python + TypeScript/React + headless/Web/SDK、AgentScope、LangGraph、Deep Agents は Python + headless/SDK がデフォルト。Provider が指定されていない場合は、まず provider-neutral contract、決定論的な scripted fixture、OpenAI-compatible adapter インターフェースを実装し、有料サービスを勝手にバインドしない。実際の結合テストの前に、ユーザーに provider 設定を要求する。

生成フロー

リポジトリ、テクノロジースタック、既存の命令、dirty changes、利用可能な実行環境を確認する。
references/catalog.md で製品が実装レベルであることを確認する。13のドシエが未完了のレシピでは製品複製を生成せず、まずドシエを補うか、明示的に hybrid/custom に切り替える。次に scripts/new_blueprint.py を実行して .harness-distill/blueprint.yaml を作成する。
製品の index.md、product-contract.md、recipe.md、acceptance-tests.md を読む。
レシピに従って実装仕様と共有知識ドキュメントをロードし、capability の依存関係クロージャを構築する。
.harness-distill/evidence.md を書き、主張、URL、日付、バージョン/コミット、エビデンスの種類、信頼度を記録する。
.harness-distill/decisions.md を書き、アーキテクチャ選択、クローズドソースの推論、非目標、リスク、ロールバックポイントを記録する。
まずプロトコル、状態スケルトン、実行可能な垂直スライスを実装し、イベントトレースを保存してリプレイする。
schema → protocol → runtime → executor/policy → surface → migration の順序で能力を追加する。
同時に contract、scenario、security、recovery、migration、および製品ブラックボックステストを追加する。
scripts/validate_blueprint.py、ターゲットリポジトリチェック、製品の acceptance-tests.md を実行する。
実装箇所とテストエビデンスを持つ capability のみを verified とマークする。

成果物の最低契約

ターゲットプロジェクトには、同等の境界を含める必要がある：

.harness-distill/
  blueprint.yaml       # 選択、レベル、能力、状態、契約バージョン
  evidence.md          # 公開エビデンスと推論境界
  decisions.md         # アーキテクチャ決定、非目標、リスク、移行
src/
  protocol/            # command/event/error/schema/capability negotiation
  runtime/             # turn 状態マシン、キャンセル、リトライ、予算、steering
  model/               # provider adapter と能力ネゴシエーション
  context/             # 指示、検索、記憶、予算、圧縮、キャッシュ
  tools/               # schema、registry、router、lifecycle、artifact
  policy/              # allow/deny/ask/amend と承認範囲
  execution/           # workspace、ファイル、shell、patch、ネットワーク、sandbox
  state/               # thread/turn/item/event/checkpoint/migration
  surfaces/            # CLI/TUI/IDE/Desktop/Web adapter
tests/
  contracts/           # プロトコル、provider、ツール、ストレージ契約
  scenarios/           # 実タスクのエンドツーエンドテスト
  security/            # 境界越え、インジェクション、シークレット、ネットワーク、エスケープ
  recovery/            # クラッシュ、重複配信、切断、移行

言語の慣習に従って名前を変更することは許容されるが、ポリシーと強制、ドメイン状態とUI投影、モデル履歴と永続的事実の間の境界を統合してはならない。

完全性ゲート

選択されたレベルの完全な Harness と呼ぶには、以下のすべての条件を満たす必要がある：

blueprint、製品契約、実装箇所が一致していること。
runnable の thread/turn/item/event トレースが永続化され、リプレイ可能であること。usable 以降はページネーションとプロセス再起動後の復旧をサポートすること。polished ではさらにバージョン間の移行が必要。
tool call/result がアトミックにペアリングされ、キャンセル、タイムアウト、遅延結果のセマンティクスが明確であること。
選択的コンテキスト圧縮後に、ツール呼び出しのアトミック性、指示階層、監査範囲が損なわれないこと。
制限されたアクションは、最初にポリシーによって決定され、次に実際の実行境界によって強制されること。
UI はスナップショット + イベントで再構築可能であり、ランタイムのメモリオブジェクトに依存しないこと。
usable 以上のクラッシュリカバリが、元に戻せない副作用を重複させないこと。
製品の acceptance-tests.md における現在のレベルのシナリオがパスすること。
納品説明書には、未サポートの動作、エビデンスのギャップ、直接的なアップグレードパスを列挙すること。

レベル間アップグレード

任意の低レベルから高レベルへ直接アップグレードする場合：

現在の blueprint、プロトコル、データベーススキーマを検証する。
capability デルタを計算し、中間依存関係を展開する。
まずスキーマを移行し、次にプロトコル、ランタイム、エグゼキュータ、インターフェースを拡張する。
古い設定と古いイベントに対して、少なくとも1つの互換性のある移行境界を維持する。
元に戻せない外部アクションに対して、チェックポイント、冪等キー、または手動確認を確立する。
すべての低レベル回帰テストと新しいレベルの検収テストを実行する。
テストがパスした後に、capability の状態を更新する。

Harness Distiller（エージェントハーネス蒸留器）