PathrulePathruleが計算するもの
チームが書くのはメモリ、ルール、スキルです。レイヤーが保持する情報の大半は書かれたものではなく実際の作業から導き出されたもので、このページでは派生する各要素とその入力元を説明します。
このページの内容
あなたが書くのは、メモリ、ルール、スキルの3種類です。この部分は意図して作られ、手入れされた、あなた自身のものです。
ただし、これは全体の小さいほうの半分にすぎません。レイヤーがある時点で保持している情報の大半は、誰かが入力したものではありません。実際の作業の進み方から導き出され、ワークスペースごとに保持され、作業が続くにつれて再計算されます。このページでは派生する各要素を説明します。何があるかを知れば、検索がなぜそのように振る舞うのかがわかるからです。
すべてのエントリに意味表現
すべてのメモリ、ルール、スキルは、その意味を計算した表現としても存在します。リクエストが届くと、リクエストも同じ種類の表現に変換され、それらと直接比較されます。
言語をまたいだマッチングを可能にしているのはこの仕組みです。トルコ語のプロンプトでも、英語で書かれたメモリと考え方が共通していれば、単語がひとつも一致しなくてもそのメモリが見つかります。キーワード検索ではこれはできません。一致させる共通の文字列がないからです。比較は「the payment webhook retries twice」と「ödeme webhook'u iki kez deniyor」が近くに並ぶ空間で行われます。
エントリの内容が変わると表現も作り直されます。そのため、マッチングは作成時点の内容ではなく、エントリが現在述べている内容を反映します。
配信ごとの計測ウィンドウ
Pathruleがあるターンにナレッジを配信すると、その配信の記録が開かれます。この記録には、どのエントリが、どのパスで、どの種類の意図に対して送られたかが保持されます。
その後、ターンは同じウィンドウに次の内容を報告します。
- 配信されたエントリのうち、単に受け取っただけでなくアシスタントが実際に参照したもの
- そのターンのツール呼び出し回数と、そのうち失敗した回数
- 編集されたファイル（ワークスペース相対の形式）
- 失敗の内訳（エラーテキストではなく短いコード）
このウィンドウが、以降に説明するすべての素材になります。誰も評価をつけなくても、Pathruleがうまくいったターンとうまくいかなかったターンを見分けられるのもこのためです。
作業の種類ごとに学習される重み
ウィンドウは蓄積されます。時間がたつと、各エントリは配信された作業の種類ごとに評価を持つようになり、その評価は根拠に応じて変動します。問題なく進んだ作業で参照されれば上がり、苦戦したターンに配信されれば下がります。
その結果、優先度はエントリごとに1つの数値ではありません。同じメモリでも、マイグレーションでは優先度が高く、UIの微調整では低くなることがあります。これらは異なる種類の作業で、根拠も異なるからです。ファイル上の単一の「重要度」フィールドではこれを表現できず、手作業で管理する人は推測に頼るしかありません。
学習は意図的に慎重に設計されています。結果があいまいなときは誤ったことを学ぶのではなく何も学ばず、明確な外れが1回あっても履歴を消すのではなく評価を下げるだけで、コードが変化するにつれて影響力は薄れていきます。この挙動の詳細は検索が適切なナレッジを見つける仕組みで説明しています。
一緒に変更されるファイルのグラフ
ターンが報告するパスから、Pathruleはチームが同じ作業の中でよく一緒に変更するファイルの関係を把握します。そうしたファイルの1つに紐づいたナレッジは、その隣のファイルを扱うセッションにも届くようになります。
この関係は誰かが宣言するものではなく、見つけるためにファイルを開くこともありません。記録された作業から導き出され、1回の偶然が数に入らないようノイズの下限が設けられ、ペアでの変更が起きなくなると減衰します。Cloudワークスペースでは、グラフは最初から手がかりを持った状態で始まります。エージェントが初めてディープコンテキストを要求したときに、最近のgit履歴のファイルパスから初期データが作られるため、チームの作業記録がまだ少ないうちから役に立ちます。一緒に変更されるファイルを参照してください。
フリクションマップ
失敗は、ツールの種類、ファイル、失敗の仕方を表す短いコードの3つ組にまとめられます。これを週ごとにまとめると、コードベースのどこでアシスタントがどのように繰り返しつまずいているかが見えてきます。また、ナレッジを受け取ったターンでも問題が起きた場合には、優先度付けへの負のシグナルとして使われます。アシスタントの作業を遅らせるファイルを参照してください。
ルーティングが正しかったかの計測
すべてのプロンプトにはルートも割り当てられます。アシスタントが何かを開く前に、作業がありそうなパスを示すものです。Pathruleはその後、アシスタントが実際にそこへ向かったかを記録します。これは一定期間の移動ウィンドウで1つの精度の数値にまとめられ、ルーティングされたセッションとされなかったセッションでファイル系ツールの作業量がどれだけ違うかもあわせて示されます。
パスを示すことが役立つように聞こえるだけでなく、実際に役立っているかを示す唯一の数値であり、ルーティングを好みではなく根拠に基づいて調整できるのはこのためです。
各レイヤーはデータが供給されているかを報告する
ここまでの派生レイヤーはどれも作業データが流れ込むことを前提としており、何も受け取らなくなったレイヤーは何も返しません。これは報告すべきことがないレイヤーとまったく同じに見えます。この2つのケースには正反対の対応が必要なので、Pathruleはこれらが同じように見えたままにはしません。
各レイヤーについて、最後にデータを受け取った時期が定期的に確認され、その結果は「最新」「最近は何も受信していない」「一度も供給されていない」の3つの状態のいずれかとして記録されます。同じチェックで、記録の一部より古いクライアントから届いたターンも検出されます。そのため、インストールする価値のあるアップデートは、結果が静かに悪化する形ではなく、名前のついた件数として表に出ます。
派生レイヤーが静かになったときに、なぜ結果が悪くなったのかを不思議に思った誰かが数か月後に気づくのではなく、日付つきの報告された状態になるのはこのためです。
エピソードと鮮度の判定
同じアクティビティの上には、さらに2つの派生レイヤーがあります。
作業エピソードは関連するターンをつなぎ合わせ、何かがどのように解決されたかの経緯にします。そのため「前回はどうやったか」に、誰かの記憶ではない答えが用意されます。以前はどう解決したかを参照してください。
鮮度の判定は、エントリが主張している内容とその後のコードの変化を比較し、古くなったと思われるものを、黙って優先度を下げるのではなく編集案として提示します。提案とセルフ監査を参照してください。
個人の好みはあなたのマシン上に
記録された作業ではなく、あなた自身から始まるレイヤーが1つあります。たとえばpathrule me teach "I prefer incremental refactors"のように作業スタイルの好みをPathruleに伝えると、オプションのオンデバイスモデルがその文を短く、適用範囲を持った好みに変換します。これはアップロードされずにあなたのマシン上に保存され、該当する場面でエージェントに配信されます。
これはあなたが管理できます。pathrule me listで使用中のものを確認し、pathrule me explainで好みの出どころを確認し、pathrule me scopeで1つのワークスペースに限定するか複数のワークスペースにまたがって適用するかを設定し、pathrule me forgetで使用を止め、pathrule me contextでタスクに対してエージェントが受け取る内容をプレビューできます。User Intelligenceを参照してください。
何から作られていないか
ソースコードの内容からは作られていません。リポジトリのソースコードが自動でアップロードされることはありません。ここまでの派生レイヤーはすべて、チームが書き留めることを選んだ内容と、作業が自ら報告した情報から作られており、diffやコミットメッセージは保存されません。
チェックアウトから読み取られるものは2つあります。どちらもCloudワークスペースの場合のみで、どちらもエージェントが初めてディープコンテキストを要求したときです。
- 最近のgit履歴のファイルパス。同じコミットで変更されたファイルを見つけるために使います。非常に大きなコミット（通常はリファクタリングやリネーム）はスキップされます。得られたファイルパスのペアは、共変更グラフの出発点としてワークスペースに保存されます。コミットメッセージ、作成者、diffは読み取りません。
- フォルダツリー上位のファイル名。TypeScript、Vite、Docker、GitHub Actionsの設定など、設定ファイルから使用中の技術を認識するために使います。認識された技術はそれぞれ、確認なしでワークスペースのルートに短いメモリとして書き込まれます。これは通常のメモリなので、編集も削除もできます。
ワークスペース自体の履歴がまだ少ないうちは、同じディープな回答の中で、プロジェクトのトップレベルのフォルダと、最近のgit履歴で最も頻繁に変更されたファイルも示されます。これらはチェックアウトから読み取られてその回答のためにエージェントに渡されますが、Pathruleには保存されません。
アカウントなしであなたのマシン上に保持されるローカルワークスペースでは、これらは一切行われません。共変更グラフは記録された作業だけから作られます。
Cloudモードでは、ほかに2つの情報があなたのマシンの外に送られます。ここでどちらも明記しておきます。
- 各プロンプトの冒頭部分。 プロンプトの最初の部分、おおよそ最初の1,000文字が、ナレッジの優先度付けのためにPathrule Cloudに送信されます。
- あなたまたはエージェントが
pathrule snapshotを実行したときのプロジェクトスナップショット。 ファイルツリー、マニフェスト、ドキュメントの短いサンプル、最近のgitメタデータをアップロードします。実行されたときにのみ動作します。
プロジェクトスキャンは、エージェントにプロジェクトのPathruleセットアップを依頼することで、あなた自身が開始する別のステップです。エージェントはプロジェクトを読んでメモリ、ルール、スキルを提案し、あなたが承認したものだけが保存されます。
これとは別に、サインイン済みのマネージドCLIは、pathrule telemetry enableでオプトインした場合にのみ匿名の利用テレメトリを送信できます。これにはコード、パス、プロンプト、ナレッジ、ファイル名、メールアドレス、アカウントIDは含まれません。pathrule telemetry disable、NO_TELEMETRY=1、DO_NOT_TRACK=1のいずれかで無効のままにできます。
ファイルパスは保持される前にワークスペース相対の形式に正規化されるため、マシン固有の情報が送られることもありません。
フォルダに同じファイルを置いても同じにならない理由
同じメモリ、ルール、スキルをディレクトリに置いて、アシスタントにそこを参照させることもできます。実際にそうしているチームもあります。しかし、そのディレクトリにはこのページで説明したことが何ひとつできません。
前のターンで何が配信されたかを知らないので、何が役立ったかがわかりません。意味の表現を持たないので、言い回しが違う質問では何も見つかりません。どのファイルが一緒に変更されるかを知らないので、あるファイルに記録したナレッジが隣のファイルに届くことはありません。タスクの種類を区別できないので、どの作業に対してもすべてが同じ優先度になります。そして肥大化していきます。ディレクトリには重要な少数だけを送る手段がないため、エントリを追加するたびに以降のすべてのターンが重くなります。
書かれたエントリは、あなたが管理する部分です。派生レイヤーはそれらを、そのターンに適した少数のエントリに絞り込むものです。答えが書かれた日のまま変わらないのではなく、作業が続くにつれて良くなっていくのはこのためです。