スコープ

v1の対象範囲、以前の実行レイヤー計画から削除されたもの、その理由。

Runicは常にキャッシュだったわけではありません。以前の計画（リポジトリ内の_deprecated/にアーカイブされており、歴史的な背景についてはALPHA.md/ROADMAP.mdも参照）では、ツール呼び出しのインターセプト、権限の適用、ファイルシステム／ネットワークアクセスのサンドボックス化、厳格な予算の計測を行う実行ランタイムが説明されていました。このページでは、その計画が拡張ではなく削除された理由を説明します。

v1の対象範囲

意思決定の結果をキャッシュします。キーには、正規化された完全一致シグネチャ — { intent, params } — を使用し、生のタスクテキストや推論トレースは決して使用しません。
消費トークン数（エージェント報告）と、キャッシュヒット時に節約されたトークン数を記録します。
セッション単位のスコープ。セッション間／エージェント間の共有は、セッション内再利用が実運用で重要だと証明された後のフェーズです。

明示的に対象外

いかなる実行も行いません。 Runicは能力を呼び出さず、何かをデプロイせず、コードも実行しません。以前のpackages/runtimeは廃止されています。
権限管理やサンドボックス化。 何も実行しないなら、確認するものもありません。以前のpackages/permissionsとpackages/sandboxは廃止されています。
意味的または曖昧なタスク照合。 これは意図的に狭く設計されています — 完全一致のみです。これは制約として維持されるべき設計上の制約であり、後で「キャッシュヒットが本当に同じ意思決定なのか」という問いを再検討せずに拡大するv1の近道ではありません。

これは追加ではなく方針転換である理由

以前の実行レイヤー計画の大半 — 権限適用、サンドボックス化、能力の実行 — は、MCPがツール呼び出しに対してすでに標準化しているものと重複していることが判明しました。その上に並行する権限／実行システムを構築することは、それ自体で正当化できる切り口ではありません。すでに存在する標準と競合する、冗長なインフラストラクチャになるためです。

キャッシュと台帳という考え方が削除後も残ったのは、MCPが答えない問いに答えるからです。この完全に同じ意思決定はすでに解決されているか、そしてそのコストはいくらだったか？ これは「Runicがエージェントの実行を管理する」という主張よりも狭く、より誠実な主張です — そして、アーキテクチャ図ではなく、それを裏付ける実際のベンチマーク数値とともに、このリポジトリが実際に提供しているものです。

実行レイヤー計画を探している場合

履歴のために、リポジトリルートのALPHA.mdとROADMAP.mdに保存されており、コード自体は_deprecated/にアーカイブされています。どちらも保守されておらず、現在Runicが提供しているものを反映していません — その内容についてはIntroductionをお読みください。