プラグインの作り方

プラグインとは、以下を行う任意のプロセスです:

RabbitMQに接続し、datacore.resource-lifecycle トピックエクスチェンジ上のルーティングキー pipeline.step.dispatched.<your-plugin-id> にキューをバインドする。
各メッセージを受け取るたびに処理を行い、コールバックする: POST {CORE_API_URL}/api/v1/internal/artifacts/{resource_id}。
それ以外は何もしません。この1つのコールバックを除いてコアを同期的に呼び出すことはなく、他のプラグインと直接やり取りすることもありません (プラグインの分離)。

同梱されている3つのサンプル (plugins/markdown-summarizer、plugins/vector-embedder、 plugins/github-profile-scanner) はそれぞれ約100〜150行のTypeScriptで、最良のリファレンスです — 作ろうとしているものに最も近いものをコピーしてください。

受け取るディスパッチメッセージ

json

{
  "event": "PIPELINE_STEP_DISPATCHED",
  "resource_id": "uuid",
  "occurred_at": "ISO-8601",
  "payload": {
    "pipeline_id": "uuid",
    "step_position": 0,
    "plugin_id": "your-plugin-id",
    "attempt_count": 0,
    "source_uri": "s3://bucket/key or https://...",
    "upstream_artifacts": [{ "type": "SUMMARY", "external_ref": "...", "producing_plugin_id": "..." }]
  }
}

upstream_artifacts は、パイプライン内の前段のステップが生成したものを提供します。ステップがそれらを入力として必要とする場合に使えます (例えば Vector Embedder プラグインは、生のソースを再取得するのではなく Markdown Summarizer の出力を埋め込みます)。

送信すべきコールバック

json

// success
{ "plugin_id": "your-plugin-id", "step_position": 0, "outcome": "SUCCESS", "artifact": { "type": "SUMMARY", "external_ref": "s3://bucket/key" } }

// failure (Core will retry per that step's configured policy, or mark the resource FAILED once exhausted)
{ "plugin_id": "your-plugin-id", "step_position": 0, "outcome": "FAILURE", "error": "a specific, human-readable reason" }

artifact.type は組み込み型 (VECTOR、GRAPH、SUMMARY) のいずれか、またはプラグインが定義する新しい型にできます — 新しい成果物タイプの追加は、コアウェアハウス側でのPrismaスキーマの1行変更とマイグレーションだけで済みます (実例として github-profile-scanner の REPO_ANALYSIS 型を参照)。

external_ref は実際の内容を保存した場所への参照です — コアがコールバック経由で生の成果物バイト列を送るよう求めることは決してありません。出力は自分のバケット/コレクションに保存するか (コアと同居させてデプロイする場合はコアのMinIO/Qdrantを再利用しても構いません)、単にロケーター文字列を報告してください。

成果物の内容が表示される仕組み

成果物をWeb UIで表示可能にしたい場合 (成果物チップ→「結果を表示」モーダル経由)、コアは external_ref からその内容を取得する方法を知る必要があります。現状これは s3:// プレフィックス (テキストまたはJSONとして取得) か qdrant:// プレフィックス (ベクトル+ペイロードとして取得) のいずれかを意味します — backend/src/routes/resources.ts の GET /:id/artifacts/:artifactId ハンドラーを参照してください。異なるストレージ方式を使う場合、成果物の内容はそこには表示されません (ただし、ステータス追跡、リトライ、削除時のクリーンアップなど、それ以外はすべて external_ref だけで機能します)。

パッケージ化とデプロイ

各プラグインは独自のDockerfile + docker-compose.yml サービスであり、独自の環境変数 (RABBITMQ_URL、CORE_API_URL、PLUGIN_ID、および必要なストレージ認証情報) を持ちます。このリポジトリに存在する必要はありません — プラグインは、RabbitMQブローカーとコアAPIに到達できる限り、完全に独立してビルド・ホスト・デプロイできます。

他の人と共有する

プラグインが動作するようになったら、コミュニティプラグインレジストリに掲載して、他のDataCore運用者が発見できるようにできます。これはメタデータとリポジトリへのリンクを投稿するものであり、コード自体ではありません — 興味を持った人は自分でリポジトリをクローンし、レビューし、自分でデプロイします。

プラグインの作り方 ​

受け取るディスパッチメッセージ ​

送信すべきコールバック ​

成果物の内容が表示される仕組み ​