Workspace Intelligence

Workspace Intelligenceが答えるのは、ひとつの問いです。このプロジェクトはどう動いているのか。

ファイルに何が書かれているか、ではありません。それはエージェントが自分で読めますし、上手に読みこなします。エージェントが読めないのは、リポジトリのコードの周りに蓄積していく実務上のナレッジです。そしてまさにそのナレッジこそが、変更が正しいのか、それとももっともらしいだけなのかを左右します。

何をモデル化するか

• アーキテクチャ上の決定と、その決定に至った理由。
• コードのどこにも表れていない隠れた制約。
• 検証要件: 何をもって完了とみなすか、その前に何を確認すべきか。
• 過去の修正: まさにこの問題が前回起きたとき、実際に効果があった対処。
• チームが文書化せずに守っている規約。
• 手順: このプロジェクトで繰り返し発生する作業の進め方と順序。
• データベースが読み取り専用のレプリカである、といった、取るべきアプローチを変える文脈上の事実。
• 技術的な根拠。これがあることで、エージェントが良かれと思って意図的な決定を元に戻してしまうのを防げます。
• どれでも動く複数の実装のうち、推奨される実装。
• 置き換えられた決定。古い決定が現行のものとして扱われ続けないようにします。

これらはすべて、チームが読んで編集できる3種類のコンテンツ、メモリ、ルール、スキルとして保持されます。

スコープ

Workspace Intelligenceはリポジトリを単位とし、その中ではパスを単位とします。

これは、ナレッジレイヤーが本来解決するはずだった問題そのものになってしまうのを防ぐための仕組みです。モノレポについて正しいことのすべてが、1つのパッケージへの変更に関係するわけではありません。すべてを配信すれば、重要な3文が、関係のない200文と競い合うことになります。ナレッジはそれが適用されるパスに紐づけられ、そのパスでのタスクには、そこに適用されるナレッジが届きます。

ワークスペースが成長し続けても、ターンごとの負荷が重くならないのも、パス単位のスコープのおかげです。詳しくは検索の仕組みを参照してください。

権威

Workspace Intelligenceは、必須要件を保持できるレイヤーです。

要件はルールとして保持されます。ルールは、あるスコープで何をしなければならないか、何をしてはならないかを定め、優先度を持ち、助言とは別の専用セクションで届けられます。ルールは実行可能な制約、つまり変更に含まれてはならないパターンを持つこともできます。エージェントが提案した制約は提案として保存され、強制はされません。人が承認すると、フックをサポートするクライアントでは、pre-toolフックが該当する編集をブロックできるようになります。詳しくはガードレールとしてのルールを参照してください。

これらはプロジェクトの性質です。個人の好みのほうが都合がよいからといって外されることはなく、User Intelligenceがこれを上書きすることもできません。Workspace Intelligenceが保持するそれ以外のものはすべて助言であり、助言として届けられます。そのため、過去の修正がルールより優先されるかのように提示されることはありません。

ソース

ソースは4種類あり、どれがどれなのかを区別することが重要です。

作成されたもの。 人が意図して書いたメモリ、ルール、スキル、またはエージェントがPathruleのツールを通じて書いたもので、後者は通常、事前にあなたに提案されます。チームが指し示して議論できるのはこれらであり、ナレッジの中核を成します。

コードから得た知見。 エージェントがコードを読んで導き出した結論です。根拠となるファイルとともに保存され、それらのファイルが変更されていない間に限り、助言として届けられます。詳しくはプロジェクト学習を参照してください。

実際の作業から得たエビデンス。 エージェントのセッションが自ら報告した内容です。どのナレッジが配信され、どれが実際に参照されたか、どのファイルが一緒に変更されたか、エージェントがどこで繰り返しつまずいたか、といった情報です。詳しくはPathruleが計算するものを参照してください。

チェックアウトからのシード（Cloudワークスペースのみ）。 Cloudワークスペースでエージェントが初めてPathruleに詳細なコンテキストを求めたとき、ローカルランタイムは最近のgit履歴からファイルパスを読み取り、どのファイルが一緒に変更されてきたかを把握します。また、フォルダツリーの上位階層にあるファイル名を一覧し、TypeScript、Docker、GitHub Actionsの設定など、使われている技術を認識します。パスの組み合わせは一緒に変更されるファイルの出発点としてワークスペースに保存されるため、チームの作業記録がまだ少ないうちからこのシグナルが役立ちます。認識された技術はそれぞれ、「TypeScript project」のような短いメモリとして、確認を求めずにワークスペースのルートに書き込まれます。これは通常のメモリなので、編集も削除もできます。ローカルワークスペースではこのステップを行わず、一緒に変更されるファイルは記録された作業だけから学習します。

ソースに含まれないもの、それはあなたのソースコードです。Pathruleはコードを自動的にアップロードしません。上記のシードが読み取るのはファイル名とパスであり、ファイルの内容、diff、コミットメッセージは読みません。Cloudワークスペースでは、あなたやエージェントがpathrule snapshotを実行すると、Pathruleがプロジェクトを説明できるよう、ファイルツリー、マニフェスト、ドキュメントの短いサンプル、最近のgitメタデータがアップロードされます。何が読み取られ、何が保持されるかはPathruleが計算するものにまとめています。

Team Intelligence

Pathrule Cloudでは、Team Intelligenceがチームの作業から生まれるエビデンスを横断的に分析し、繰り返し現れる規約、修正、決定をパターンとして提案します。TeamプランとEnterpriseプランで利用でき、組織のオーナーと管理者がWebコンソールの組織のTeam guidance設定で管理します。

パターンは下書きから提案へと進み、人がそれを検証するか却下します。誰も対応しなかった提案は期限切れになります。エージェントに届くのは検証済みのパターンだけです。 Team Intelligenceが推測したものが、それだけで信頼されることはありません。

ライフサイクル

1. 作成または提案。 人がCLI、VS Code拡張機能、またはエージェントを使って書きます。残す価値のあることを見つけたエージェントは、通常はあなたに提案したうえで、Pathruleの書き込みツールを通じて保存します。その書き込みは作成者が記録され、バージョン管理され、元に戻せます。エージェントに「Set up Pathrule for this project」と頼むと、ガイド付きのスキャンが実行され、エージェントがメモリ、ルール、スキルを提案し、あなたが承認したものを書き込みます。Cloudワークスペースでは、上で説明した短い技術メモリもPathruleが追加します。
2. 承認（推測による内容の場合）。 推測されたナレッジは人の判断を待ちます。ルールの実行可能な制約は承認後にのみ強制され、Team Intelligenceのパターンは検証されて初めてエージェントに届きます。唯一の例外はエージェントの知見で、これは助言のままにとどまります。詳しくはProposed Knowledgeを参照してください。
3. 配信。 タスクに関係する部分が、クライアントがサポートする仕組みを通じてエージェントに届きます。詳しくはAgent IRを参照してください。
4. 計測。 配信の事実と、エージェントがそれをどう使ったかが記録されます。そのため、各エントリの評価は誰が書いたかではなく、実際に何が起きたかを反映します。
5. 更新、置き換え、または廃止。 古くなったように見えるナレッジはリフレッシュタスクとしてフラグを立てられ、人またはエージェントがそれに対応します。後の決定に置き換えられた決定は、現行のものとして扱われなくなります。詳しくは提案とセルフ監査を参照してください。

プロジェクトを切り替えると何が変わるか

すべてが変わります。Workspace Intelligenceはリポジトリに属するものであり、別のリポジトリを開けば、別のプロジェクトナレッジになります。そのナレッジは、同じリポジトリで作業する他のメンバーと共有されます。

あなたと一緒に移るのは、あなた自身に属するUser Intelligenceです。つまり、あなたがPathruleに教え、どこでも適用すると選んだ好みです。