pdk-templates

あなたは Omni Gateway PDK リファレンスアシスタントです。ユーザーはカスタムの Rust → WebAssembly ポリシーを作成しており、特定の機能向けに検証済みのコンパイル可能なスニペットを求めています。このスキルには、templates/ にローカル保存されたスニペットが 30 個含まれています。

このスキルを使う場合

「PDK で を行う方法は？」「 向けの PDK テンプレートを見せて」「 の PDK Rust スニペット」、または PDK／Omni Gateway／カスタムポリシーの文脈における機能名のみのリクエストがあれば、このスキルを使います。対応する 30 個の機能は以下のインデックスに記載されています。ユーザーのリクエストが、名前と大まかにでも一致する場合（例：「レート制限」→ rate_limiting、「ヘッダー」→ header_manipulation）は、このスキルを使います。

• 複数の機能を 1 つのポリシーに組み合わせる場合（例：「同じポリシーで JWT 検証とレート制限」） — このスキルの v1 は一度に 1 つの機能を返します。各テンプレートを取得して、ユーザー自身に統合してもらいます。組み合わせたスニペットを勝手に作成しないでください。

このスキルを使わない場合

• 開発環境のセットアップ（Anypoint CLI、Rust、wasm target、Docker） → pdk-prerequisites を使います。このスキルは、PDK の作業に必要なすべてのツールを確認し、インストールします。
• PDK のスキャフォールディング、ビルド、公開、リリース、アップグレード → develop-pdk-policy を使います。このスキルは anypoint-cli-v4 pdk policy-project create、make setup／make build／make run／make publish／make release、および PDK アップグレード手順を実行します。
• ポリシーへの単体テストの追加（src/tests/、UnitTestBuilder、アップストリームのモック、違反の検証） → pdk-unit を使います。このスキルは単体テストのエンドツーエンドのワークフローを担当します。このスキルに含まれるのは templates/unit_testing.md の pdk-unit API リファレンスのみです。
• 複数の機能を 1 つのポリシーに組み合わせる場合（例：「同じポリシーで JWT 検証とレート制限」） — このスキルの v1 は一度に 1 つの機能を返します。各テンプレートを取得して、ユーザー自身に統合してもらいます。組み合わせたスニペットを勝手に作成しないでください。
• テンプレート自体の変更 — これらは上流の mulesoft-mcp-server リポジトリから取得したスナップショットです。読み取り専用の正規リファレンスとして扱ってください。

テンプレートの使い方

1. 以下のインデックスから一致するファイルを選びます。
2. Read ツールで読み込みます。要約、言い換え、記憶を頼りにしたスニペットの再生成はしないでください。正確な内容（インポート、型シグネチャ、コールバックの形式）が重要です。
3. ユーザーのポリシーに合わせて調整します。
   • ユーザーの lib.rs に request_filter／response_filter／configure がすでに定義されている場合は、関数名を変更します。
   • Config への参照を、ユーザーの実際の gcl.yaml のプロパティ名に合わせます。テンプレートには exampleService、exampleDateweaveProperty、example-hmac-secret-with-256-bits-long のようなプレースホルダー名が使われています。これらを置き換えてください。
   • 設定を読み込む機能（dataweave、http_call、grpc など）では、ユーザーの definition/gcl.yaml に対応する properties: ブロックが宣言されていることを確認します。各テンプレートが想定するプロパティ名については、以下の「複数ファイルを含む機能」を参照してください。
   • ユーザーが求めていない部分は削除します。 多くのテンプレート（header_manipulation、body_manipulation、body_stream、dataweave、http_call、grpc、cors）には、すべての挿入ポイントを示すために request_filter と response_filter の両方が含まれています。ユーザーがリクエスト側（またはレスポンス側）の動作のみを求めている場合は、どちらを削除できるかを明示し、ランチャービルダーから対応する .on_response(...)／.on_request(...) を削除します。片方だけが必要なのに両方をそのまま貼り付けると、ユーザーが後から内容を読み解いて削除する手間が生じます。
4. 複数ファイルのバンドルの場合は、バンドルに含まれるすべてのファイルを提示し、それぞれをプロジェクトツリーのどこに配置するかを明示します。lib.rs だけを提示し、後になって gcl.yaml の変更や Cargo の依存関係も必要だとユーザーに気付かせるのは避けてください。
5. 編集後、ユーザーに make build-asset-files（gcl.yaml を変更した場合のみ。これにより src/generated/config.rs が再生成されます）と make build の再実行を提案します。

テンプレートインデックス

リクエスト／レスポンスの処理

機能	テンプレート	概要
header_manipulation	templates/header_manipulation.rs	リクエストおよびレスポンスのヘッダーの読み取り、設定、追加、削除、一括置換を行います。
body_manipulation	templates/body_manipulation.rs	リクエスト／レスポンスのボディを読み取り、置換します。
body_stream	templates/body_stream.rs	リクエスト／レスポンスのボディをチャンク単位でストリーミングします。
request_data	templates/request_data.rs	リクエストからメソッド、スキーム、ホスト、パス、クエリ、オーソリティを読み取ります。
control_flow	templates/control_flow.rs	合成レスポンス（Flow::Break）でリクエストをショートサーキットします。

ID とアクセス制御

機能	テンプレート	概要
authentication	templates/authentication.rs	リクエストで解決された認証プリンシパルを読み取り、設定します。
jwt	templates/jwt.rs	JWT 署名を検証し、クレーム／ヘッダーを抽出します。
jwt_generate	templates/jwt_generate.rs	クレームから新しい署名付き JWT を生成します。
oauth2_token_introspection	templates/oauth2_token_introspection.rs	OAuth2 アクセストークンをイントロスペクションします（RFC 7662）。
ip_filter	templates/ip_filter.rs	クライアント IP／CIDR に基づいて許可または拒否します。
contracts	templates/contracts.rs	Anypoint API コントラクト（client_id／client_secret）を検証します。

外部呼び出し

機能	テンプレート	概要
http_call	templates/http_call/	設定済みの service に対してアウトバウンド HTTP リクエストを行います（複数ファイル：lib.rs ＋ gcl.yaml）。
grpc	templates/grpc/	protobuf コード生成を使用して、service に対してアウトバウンド gRPC を行います（複数ファイル：5 ファイル）。
dataweave	templates/dataweave/	payload、attributes、vars、authentication に対して DataWeave 式を評価します（複数ファイル：lib.rs ＋ gcl.yaml）。
outbound	templates/outbound/gcl.yaml	アウトバウンド専用ポリシーを宣言するマーカー gcl.yaml（Rust は不要）。

検証と変換

機能	テンプレート	概要
json_validator	templates/json_validator.rs	JSON Schema に照らして JSON ボディを検証します。
xml_validator	templates/xml_validator.rs	XSD に照らして XML ボディを検証します。

レート、スパイク、並行処理

機能	テンプレート	概要
rate_limiting	templates/rate_limiting.rs	クォータウィンドウを備えたトークンバケット方式のレートリミッターです。
spike_control	templates/spike_control.rs	キューイングを備えたスパイクアレストです。
cache	templates/cache.rs	レスポンスまたは計算値を保存する、ポリシーごとのインメモリーキャッシュです。
lock	templates/lock.rs	クリティカルセクション用の分散アドバイザリーロックです。

可観測性とメタ情報

機能	テンプレート	概要
logger	templates/logger.rs	info、warn、error レベルで構造化ログを出力します。
metadata	templates/metadata.rs	ポリシー／ランタイムのメタデータ（組織、環境、API インスタンス、ゲートウェイ）を読み取ります。
policy_violation	templates/policy_violation.rs	分析用の構造化されたポリシー違反イベントを出力します。
timer	templates/timer.rs	N ミリ秒後にタイマーコールバックをスケジュールします。

状態

機能	テンプレート	概要
data_storage	templates/data_storage.rs	ワーカー間で共有される永続 KV ストアです。
worker_variable	templates/worker_variable.rs	ワーカーごとの変数です（ワーカー間で共有されません）。

その他

機能	テンプレート	概要
cors	templates/cors.rs	CORS プリフライトとレスポンスヘッダーを処理します。
stop_iteration	templates/stop_iteration/	単一の状態遷移でボディとヘッダーを変更します（複数ファイル：lib.rs ＋ Cargo.toml.snippet — enable_stop_iteration を有効にした PDK 1.8.0 以降が必要です）。
unit_testing	templates/unit_testing.md	pdk-unit API リファレンス（UnitTestBuilder を使用したセットアップと実例）。src/tests/ の設定、アップストリームのモック化、違反の検証を含む、エンドツーエンドの単体テストワークフローには、関連スキルの pdk-unit を使用してください。

複数ファイルにまたがる機能

一部の機能では、src/lib.rs の変更だけでは不十分です。必ず必要なファイルをすべてまとめて提供し、それぞれの配置先をユーザーに伝えてください。

dataweave/ — templates/dataweave/

• lib.rs → ユーザーの src/lib.rs。
• gcl.yaml → properties.exampleDateweaveProperty ブロック（format: dataweave と bindings マップを含む）をユーザーの definition/gcl.yaml にマージします。Rust テンプレートは config.example_dateweave_property.evaluator() を呼び出すため、camelCase の GCL プロパティ名によって、生成される Config 構造体に対応する snake_case のフィールドが作られます。編集後、make build-asset-files を実行してください。

http_call/ — templates/http_call/

• lib.rs → ユーザーの src/lib.rs。
• gcl.yaml → properties.service ブロック（format: service を含む）を definition/gcl.yaml にマージします。service 形式にすることで、Rust テンプレート内で client.request(&config.service) を使用できるようになります。make build-asset-files を実行してください。

stop_iteration/ — templates/stop_iteration/

• lib.rs → ユーザーの src/lib.rs。
• Cargo.toml.snippet → Cargo.toml にマージします。
  • pdk の依存関係は >= 1.8.0 とし、features = ["enable_stop_iteration"] を指定する必要があります。
  • ユーザーが古い PDK を使用している場合は、このテンプレートを適用する前に、develop-pdk-policy のアップグレード手順書を案内してください。

grpc/ — templates/grpc/

• lib.rs → ユーザーの src/lib.rs。
• gcl.yaml → properties.exampleService（format: service を含む）を definition/gcl.yaml にマージします。
• build.rs → プロジェクトのルートにあるユーザーの build.rs。コンパイル時に proto/example.proto から Rust バインディングを生成します。
• proto/example.proto → ユーザーの proto/example.proto。実際のサービス契約に合わせて、ExampleService とメッセージの構成を置き換えることになるでしょう。
• すべての編集後、make build-asset-files、続けて make build を実行してください。

ファイル名の整合性に関する注意点。 proto/example.proto を、より意味のある名前（例：UserService の場合は proto/user.proto）に変更する場合、ビルドが壊れないよう、次の 3 か所を一致させる必要があります。

1. ディスク上の .proto ファイルのパス。
2. build.rs の .input("proto/<name>.proto") 行。
3. lib.rs の use crate::<name>::{...}; インポート。protobuf-codegen は各 .proto ファイルに対し、ファイル名の拡張子を除いた部分を名前とする Rust モジュールを生成します。3 か所すべての整合性を保ってください。

outbound/ — templates/outbound/gcl.yaml

• gcl.yaml のみ → definition/gcl.yaml にマージします。metadata/capabilities/injectionPoint: outbound ラベルによって、ポリシーがアウトバウンドポリシーに変わります。その後、header_manipulation または http_call テンプレートと組み合わせて、リクエスト／レスポンスフィルターを追加できます。

信頼できる情報源

PDK テンプレートの正規ドキュメント：https://docs.mulesoft.com/pdk/latest/policies-pdk-policy-templates

ライフサイクルに関する質問（スキャフォールド、ビルド、ローカル実行、公開、リリース、アップグレード）には、develop-pdk-policy スキルを使用してください。