doca-version

DOCA バージョン

例

• 「実際にインストールされている DOCA のバージョンは？」 — 4 つの情報源を使った検出チェーンを実行し、4 つすべてが一致することを確認します。
• 「プログラムはビルドできたのに、通信上では何も起きません。」 — アプリケーションコードを書き直す前に、混在インストールによる不整合をバージョンの問題として扱います。

手順

以下の読み込み順序に従ってください。検出／検証／診断についてはタスク用コンパニオンを開き、4 つの情報源の一致と NGC タグのルールについては機能用コンパニオンを開いてください。コンパニオンファイルをすべて開かないでください。

最初に開くファイル： このスキルは、バンドルにおける DOCA の バージョン処理 の唯一の信頼できる情報源です。ユーザーがバージョンを使って何かを実行したい場合（不一致の検出／検証／診断）はタスク用コンパニオンを開き、質問がバージョン処理で何をカバーするか（4 つの情報源の一致、検出チェーン、NGC の意味、ライブラリごとのオーバーレイパターン）に関する場合は機能用コンパニオンを開いてください。バージョンに触れるバンドル内の他のすべてのスキルは、ここに誘導します。ルールを再定義してはいけません。

このスキルが得意とする質問の例

このスキルが回答するよう設計された、バージョン処理に関する質問のクラスと、それぞれの具体例です。エージェントは、回答の要となるのはクラスだと考えてください。具体例は個別の事例にすぎません。

• 「実際にインストールされている DOCA のバージョンは？」 — 具体例：「ドキュメントには 3.3 と書いてありますが、このホストに何が入っているのか確信がありません」。## configure + ## Capabilities and modes の信頼できる情報源テーブルにある正式な検出チェーンで回答します。
• 「プログラムはビルドできたのに通信上では何も起きません。インストールに不整合はありますか？」 — 具体例：「pkg-config --modversion は 3.3.0 と表示しますが、doca_caps --version は 3.2.0 と表示します」。## Version compatibility の4 つの情報源の一致ルールと、## debug の部分的なインストールの診断で回答します。
• 「この DOCA の機能／API／サンプルは、手元のバージョンに含まれていますか？」 — 具体例：「対称 RSS のハッシュモードは Flow 2.6.0 にありますか」。doca-structured-tools-contract/SKILL.md#schemas で定義されている version-matrix.json スキーマを使用する ## test のバージョンマトリックス検索手順で回答し、必要に応じて doca-public-knowledge-map/SKILL.md を通じてライブラリごとのドキュメントを参照します。
• 「ホストのパッケージバージョン X を BFB バージョン Y に対して実行できますか？」 — 具体例：「ホストは 3.5.0 GA、BlueField BFB は 3.2.3 LTS です」。## Version compatibility に記載されている DOCA Compatibility Policy への誘導で回答します。
• 「NGC DOCA コンテナー内にいます。バージョンの一致はどのように確認すればよいですか？」 — 具体例：「それでも pkg-config／applications/VERSION／doca_caps を個別に確認する必要がありますか？」。## Version compatibility の NGC コンテナールールと、## configure のコンテナーパスで回答します。
• 「新しいスキル用に、ライブラリごとのバージョン互換性セクションを書くにはどうすればよいですか？」 — 具体例：「バンドルに doca-comch を追加する場合、その ## Version compatibility はどのようなものになりますか？」。## Safety policy のライブラリごとのオーバーレイパターンと、## modify の具体例テンプレートで回答します。
• 「apt list には DOCA 3.3.0109 と表示されていますが、/etc/apt/sources.list.d/doca.list は latest／別のリリースに固定されています。次の apt install doca-* で、気付かないうちにアップグレードされますか？」 — 具体例：「BFB を 3.1.0105 にロールバックしましたが、ソースはまだ最新チャンネルを参照しています」。## apt-source consistency の apt ソース整合性事前チェックで回答します。このチェックでは、設定済みの DOCA apt ソースとして正当な 3 つの形（ネットワーク URL、ローカルの file-repo、RHEL/OEL 相当）を列挙し、固定インストールが意図せず変わるのを防ぐための、ソースが一致するまでインストールしないというルールを示します。

このスキルを読み込むタイミング

バージョンの取り扱いが最も重要な関心事となる場合は、いつでもこのスキルを読み込んでください。判断は、エージェントが最初の文を作成する前に行う必要があります。以下の有効化チェックリストは、AGENTS.md ## Cross-cutting overlay activation triggers（バンドルの AGENTS.md#cross-cutting-overlay-activation-triggers）から参照されているものと同じです。このスキルを参照する際に有効化ルールをすぐ確認できるよう、ここにも記載しています。

エージェントの有効化チェックリスト — 以下のいずれかの条件に当てはまる場合、回答の作成を開始する時点でこのスキルを読み込んでください

トリガーの分類	具体的なプロンプト側の兆候（いずれか1つでオーバーレイが有効になります）
バージョンに関する直接的な質問	「使用中の DOCA のバージョンは」、「X に一貫性はあるか」、「バージョン Z で機能 Y はサポートされているか」、「ホストパッケージのバージョン A と BFB のバージョン B を混在させてもよいか」、「現在の LTS はまだサポートされているか」、「バージョン文字列の意味は」
コンテナーのタグに関する質問	特定の NGC コンテナータグに言及するプロンプト、latest についての質問、または Dockerfile／ポッド仕様／Compose ファイルでタグを固定する方法についての質問。エージェントは、## Safety policy の 「タグ文字列を記憶から決して捏造しないこと。確認せずに latest を引用しないこと」 というルールも必ず引用してください。
ビルド時と実行時の不整合	「プログラムは正常にビルドできたのに、実行時に DOCA_ERROR_NOT_SUPPORTED が発生する」、「ドキュメントに存在すると書かれているシンボルが未定義として参照される」、「コードを実行しても通信上何も起きない」、「カウンターが増えない」といった症状があるデバッグセッション。これらは典型的な部分インストールの症状です。
アップグレード／ダウングレード計画	他の DOCA ワークロードがすでに実行されているホスト上で DOCA をアップグレードまたはダウングレードする計画、あるいはホストに接続済みの BlueField ペア上で BFB を更新する計画がある場合。
アーティファクトごとの相互参照	アーティファクトごとのスキルにある ## Version compatibility セクションから、このスキルのルール本文を参照している場合、またはエージェントが新しいアーティファクトごとのスキルを作成しようとしていて、オーバーレイのテンプレートが必要な場合。

上記のいずれかの条件に当てはまる場合、エージェントは必ず次の操作を行います。

1. Capabilities and modes に記載されている4つのソースによる検出手順を、回答内で明示的に引用してください。pkg-config --modversion doca-common → cat /opt/mellanox/doca/applications/VERSION → doca_caps --version → bfver と cat /etc/mlnx-release（BlueField ホストの場合）です。言い換えたり要約したりせず、コマンド名を引用してください。BFB の確認には mlxprivhost や bfb-info を代用しないでください。これらはよくある誤った情報であり、このバンドルの ## Capabilities and modes で明示的に禁止されています。

2. 不整合の可能性が少しでもある場合（デプロイ形態に関する質問とデバッグ形態に関する質問はすべて該当し、概要を尋ねる質問は通常該当しません）、## Version compatibility に記載されている4項目の一致ルールを一字一句そのまま提示してください。
3. バージョン文字列を捏造しないでください。ユーザーのホストから実際に取得した pkg-config --modversion の出力がない場合は、その旨を述べて検出手順を案内してください。学習データの記憶からバージョンを断定してはいけません。

バージョン整合性に関する共通トリガー

別のオーバーレイ（例：doca-setup/SKILL.md、doca-hardware-safety/SKILL.md、doca-container-deployment/SKILL.md、doca-bare-metal-deployment/SKILL.md）で、「インストールが正常であること」または「バージョンに一貫性があること」を必要とする ## test／## configure／## modify の手順が呼び出された場合、その手順では必ず、このスキルの4つのソースによる検出手順と4項目の一致ルールを引用してください。エージェントはオーバーレイごとにルールを再定義しません。バージョン確認が必要な手順はすべて、ここを参照してください。ルール本文を管理するのは、このバンドル内でここだけです。

一般的な DOCA の概要を把握する場合や、インストール手順（doca-setup/SKILL.md を使用してください）、ライブラリ固有の API に関する質問（対応するライブラリのスキルを使用してください）には、このスキルを読み込まないでください。

このスキルでできること

これは薄いローダーです。本文には、次に読むべきファイルを選ぶために必要な概要だけを記載しています。バージョンの取り扱いに関する詳しい内容は、2 つの関連ファイルに記載されています。

• capabilities 関連ファイル — バージョンの取り扱いに関する内容です。バージョン検出の正規の情報源となるテーブル、4 方向の一致ルール、NGC コンテナーのセマンティクス、ライブラリごとのオーバーレイパターン、DOCA Compatibility Policy への案内、バージョン関連のエラー分類（pkg-config の欠落、部分的なインストール、BFB とホストの不一致、NGC の混在）、可観測性に関する内容（バージョン情報の取得元ごとに確認するコマンド）、および安全ポリシー（「バージョンを決して推測しない。latest を決して引用しない」）が含まれます。
• tasks 関連ファイル — 対象となる 6 つのバージョン関連動詞について、手順を追ったワークフローが記載されています。configure（このホストで検出）、build（ビルド時の一致確認）、modify（ビルドマニフェスト内のバージョンピンを更新）、run（実行時の確認）、test（4 方向の検証とバージョンマトリックスの参照）、debug（不一致や部分的なインストールの診断）が対象です。また、Deferred task verbs ブロックも含まれます。

読み込み順序

1. ユーザーの質問が対象範囲内であることを確認するため、最初にこのスキルを読みます。
2. バージョン検出の情報源、4 方向の一致ルール、NGC のセマンティクス、ライブラリごとのオーバーレイパターン、エラー分類、可観測性、安全ポリシーについては、capabilities 関連ファイルを参照してください。
3. 手順を追ったワークフロー（configure、build、modify、run、test、debug）については、tasks 関連ファイルを参照してください。

関連スキル

• doca-structured-tools-contract/SKILL.md — 利用可能な場合にエージェントが優先して使うべきヘルパーツールの JSON スキーマが記載されています。このスキルの ## test ワークフローでは、ここで定義されている version-matrix.json スキーマを使用します。このスキーマをここで再定義しないでください。
• doca-public-knowledge-map/SKILL.md — Compatibility Policy を含む、一般公開されている DOCA ドキュメントへの案内表が記載されています。このスキルは、このマップを介して Compatibility Policy の URL を 1 回参照します。案内内容を重複して記載しません。
• doca-setup/SKILL.md — 環境側のインストール／確認／NGC コンテナーの手順が記載されています。このスキルでは、その前提条件が満たされていること（つまり、どこかに何かがインストールされていること）を想定しています。バージョンに関する問いは、「何がインストールされていて、整合性があるか」です。
• doca-programming-guide/SKILL.md — プログラム側のガイダンスが記載されています（確認したバージョンを引用する、ヘッダーを優先する、機能検出のルール）。プログラム側の ## Version compatibility セクションは現在、このスキルとプログラム側のオーバーレイ（引用するか仮定するか、エージェントのメモリーにあるバージョンは決して使わない）への案内を 3～5 行で記載しています。
• doca-debug/SKILL.md — 横断的な デバッグ手順が記載されています。このスキルの ## debug ワークフローでは、その手順のレイヤー 2（バージョンの不一致）を扱います。