OKF Agent Memory 0.2、アーキテクチャルールをコードパスに紐付け、エージェントが編集前に変更禁止範囲を照会可能に

OKF Agent Memory 0.2.0は9月12日にリリースされ、coding agentによくある「プロジェクトのルールは把握していても、どのルールがどのファイルに適用されるのか分からない」という問題の解決を試みている。ナレッジ文書では、YAML frontmatterに`code_refs`を追加し、globで制約対象のモジュールやファイルを指定できるようになった。エージェントは編集前に`okf search --for-path <file> knowledge`を実行するか、内蔵のstdio MCPを介して`okf_search({"for_path":"<file>"})`を呼び出すことで、対象パスに関連する意思決定だけを取得できる。

返される結果は`hold`、`constraint`、`context`の順に並ぶ。`hold`は人間の承認なしに変更してはならないこと、`constraint`は変更時に必ず従うべき要件、`context`は設計上の背景情報のみを示す。レベルが明記されていない場合、ツールは`knowledge/convention/`配下の内容をconstraint、ドメイン文書とアーキテクチャ文書をcontextと推定する。これは、`AGENTS.md`全体やルールセットを毎回のプロンプトに詰め込む方法よりも追跡しやすく、コードレビューでルールとパスの紐付けに対する変更を直接確認することも可能にする。

新版では境界チェックも強化された。`ValidateBundle`は、`..`またはシステム上の絶対パスを含む`code_refs`を拒否する。`okf validate --drift`は、参照先ファイルが存在するかどうかをプロジェクトのルートディレクトリ内に限って検証する。MCPのbundle解決もcanonical workspace root内に制限され、エージェントがパラメーターを利用してワークスペース外のファイルを探索するリスクを低減している。プロジェクトは、インメモリのBM25検索が300マイクロ秒未満だとしているが、この数値はメンテナー自身の小規模なナレッジセットに基づくものであり、大規模なmonorepoにも当てはまるとは限らない。さらに重要なのは、これらのガバナンスタグは本質的にエージェントへ渡す構造化された指示にすぎず、ファイルシステムのACLと同等ではないという点だ。デプロイ担当者は、実行環境または承認レイヤーでも`hold`を別途強制すべきである。