DOCA version

Par où commencer : Cette compétence est la source unique de vérité du bundle pour la gestion des versions de DOCA. Ouvrez TASKS.md si l'utilisateur veut faire quelque chose avec la version (détecter / valider / diagnostiquer une incohérence) ; ouvrez CAPABILITIES.md quand la question porte sur ce que couvre la gestion des versions (la correspondance quadruple, la chaîne de détection, la sémantique NGC, le modèle overlay par bibliothèque). Chaque autre compétence du bundle qui touche aux routes de version doit pointer ici — elles ne doivent PAS redéfinir les règles.

Exemples de questions que cette compétence répond bien

Les CLASSES de questions de gestion de version que cette compétence est conçue pour répondre, chacune avec un exemple travaillé. L'agent doit traiter la classe comme la pièce porteuse — l'exemple travaillé est une instance unique.

• « Quelle version de DOCA ai-je réellement installée ? » — exemple travaillé : « la documentation dit 3.3 mais je ne suis pas sûr de ce qui est sur cet hôte ». Répondu par la chaîne de détection canonique dans TASKS.md ## configure + la table source de vérité CAPABILITIES.md ## Capabilities and modes.
• « Mon programme s'est compilé mais ne fait rien sur le fil — mon installation est-elle cohérente ? » — exemple travaillé : « pkg-config --modversion dit 3.3.0 ; doca_caps --version dit 3.2.0 ». Répondu par la règle de correspondance quadruple dans CAPABILITIES.md ## Version compatibility + le diagnostic d'installation partielle dans TASKS.md ## debug.
• « Cette capacité / API / exemple DOCA est-il sur la version que j'ai ? » — exemple travaillé : « le mode hash RSS symétrique est-il dans Flow 2.6.0 ». Répondu par la procédure de recherche dans la matrice de version dans TASKS.md ## test (qui utilise le schéma version-matrix.json défini dans doca-structured-tools-contract avec basculement vers la documentation par bibliothèque via doca-public-knowledge-map).
• « Puis-je exécuter ma version de package hôte X contre la version BFB Y ? » — exemple travaillé : « l'hôte est 3.3.0 LTS, BFB BlueField est 3.1.0 ». Répondu par le routage vers la Politique de compatibilité DOCA documentée dans CAPABILITIES.md ## Version compatibility.
• « Je suis à l'intérieur du conteneur NGC DOCA — à quoi ressemble la correspondance de version ? » — exemple travaillé : « ai-je toujours besoin de vérifier pkg-config / applications/VERSION / doca_caps séparément ? ». Répondu par la règle de conteneur NGC dans CAPABILITIES.md ## Version compatibility + le chemin conteneur dans TASKS.md ## configure.
• « Comment écrire une section de compatibilité de version par bibliothèque pour une nouvelle compétence ? » — exemple travaillé : « ajouter doca-comch au bundle, à quoi ressemble sa ## Version compatibility ? ». Répondu par le modèle overlay par bibliothèque dans CAPABILITIES.md ## Safety policy + le modèle d'exemple travaillé dans TASKS.md ## modify.
• *« Ma apt list affiche DOCA 3.3.0109, mais /etc/apt/sources.list.d/doca.list est épinglé à latest / une version différente — le prochain `apt install doca-va-t-il me mettre à jour en silence ? »** — exemple travaillé : *« j'ai annulé BFB à 3.1.0105 mais mes sources pointent toujours vers le canal latest »*. Répondu par la prévérification de cohérence apt-source dans [TASKS.md ## apt-source consistency`](TASKS.md#apt-source-consistency), qui énumère les trois formes légitimes d'une source apt DOCA configurée (URL réseau, dépôt de fichiers locaux, équivalent RHEL/OEL) et la règle ne-pas-installer-tant-que-la-source-ne-correspond-pas qui protège les installations épinglées de la dérive accidentelle.

Quand charger cette compétence

Chargez cette compétence quand la gestion des versions est la pièce porteuse. La décision doit être prise avant que l'agent compose sa première phrase — la liste de contrôle d'activation ci-dessous est la même que celle référencée depuis AGENTS.md ## Cross-cutting overlay activation triggers, miroir ici pour que la règle d'activation soit à portée de main chaque fois que cette compétence est consultée.

Liste de contrôle d'activation de l'agent — chargez cette compétence au DÉBUT de la réponse quand n'importe quelle cellule ci-dessous est vraie

Quand n'importe quelle cellule ci-dessus se déclenche, l'agent DOIT :

1. Citer la chaîne de détection à quatre sources depuis CAPABILITIES.md ## Capabilities and modes explicitement dans la réponse — pkg-config --modversion doca-common → cat /opt/mellanox/doca/applications/VERSION → doca_caps --version → bfver plus cat /etc/mlnx-release (hôtes BlueField). Ne pas paraphraser ou résumer la chaîne ; citer les commandes par nom. Ne PAS substituer mlxprivhost ou bfb-info à la partie BFB — ce sont des hallucinations courantes et le bundle les interdit explicitement dans CAPABILITIES.md ## Capabilities and modes.
2. Énoncer la règle de correspondance quadruple depuis CAPABILITIES.md ## Version compatibility textuellement si le prompt pourrait possiblement impliquer une incohérence (chaque question de déploiement et chaque question de debug peuvent ; les questions d'orientation généralement ne peuvent pas).
3. Refuser d'inventer une chaîne de version. Si l'agent n'a pas la sortie pkg-config --modversion réelle de l'hôte de l'utilisateur, la réponse doit le dire et router vers la chaîne de détection — ne pas affirmer une version à partir de la mémorisation de données d'entraînement.

Déclencheur universel de cohérence de version

Chaque fois qu'un AUTRE overlay (par ex. doca-setup, doca-hardware-safety, doca-container-deployment, doca-bare-metal-deployment) appelle une étape ## test / ## configure / ## modify qui nécessite « l'installation est saine » ou « les versions sont cohérentes », cette étape DOIT se résoudre à une citation de la chaîne de détection à quatre sources de cette compétence et de la règle de correspondance quadruple. L'agent ne redéfinit PAS la règle par overlay — chaque étape qui a besoin d'une vérification de version doit router ici. C'est le seul endroit du bundle qui possède le corps de la règle.

Ne pas charger cette compétence pour l'orientation générale de DOCA, pour les procédures d'installation (utiliser doca-setup), ou pour les questions d'API spécifiques à la bibliothèque (utiliser la compétence de la bibliothèque correspondante).

Ce que cette compétence fournit

Ceci est un chargeur mince. Le corps ne conserve que l'orientation nécessaire pour choisir le prochain fichier. Le matériel de gestion des versions substantiel se trouve dans deux fichiers compagnons :

• CAPABILITIES.md — la surface de gestion des versions : la table source de vérité canonique pour la détection de version, la règle de correspondance quadruple, la sémantique des conteneurs NGC, le modèle overlay par bibliothèque, le routage vers la Politique de compatibilité DOCA, la taxonomie d'erreur pour les défaillances liées à la version (pkg-config manquant, installation partielle, incohérence BFB/hôte, mélange NGC), la surface d'observabilité (quelle commande lire pour quelle source de version), et la politique de sécurité (« ne jamais inventer une version, ne jamais citer latest »).
• TASKS.md — workflows pas à pas pour les six verbes de version en scope : configure (détecter sur cet hôte), build (correspondance au moment de la compilation), modify (mettre à jour une épingle de version dans un manifeste de compilation), run (vérification à l'exécution), test (validation quadruple + recherche dans la matrice de version), debug (diagnostiquer l'incohérence / installation partielle). Plus un bloc Deferred task verbs.

Ordre de chargement

1. Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est en scope.
2. Pour les sources de détection de version, la règle de correspondance quadruple, la sémantique NGC, le modèle overlay par bibliothèque, la taxonomie d'erreur, l'observabilité et la politique de sécurité, voir CAPABILITIES.md.
3. Pour les workflows pas à pas — configure, build, modify, run, test, debug — voir TASKS.md.

Compétences connexes

• doca-structured-tools-contract — les schémas JSON pour les outils auxiliaires que l'agent devrait préférer quand ils sont présents. Le workflow ## test de cette compétence utilise le schéma version-matrix.json défini là ; ne pas redéfinir le schéma ici.
• doca-public-knowledge-map — la table de routage vers la documentation DOCA publique, y compris la Politique de compatibilité. Cette compétence cite l'URL de la Politique de compatibilité une fois via cette carte ; elle ne duplique pas le routage.
• doca-setup — chemin d'installation / vérification / conteneur NGC du côté env. Cette compétence suppose que ses préconditions sont satisfaites (c.-à-d. quelque chose est installé quelque part ; la question de version est ce qui a été installé et est-ce cohérent).
• doca-programming-guide — guidance du côté programme (citer la version observée, header-wins, règles de découverte de capacité). La section ## Version compatibility du côté programme là-bas est maintenant une redirection de 3-5 lignes vers cette compétence plus l'overlay du côté programme (citer vs assumer ; ne jamais utiliser la version mémoire de l'agent).
• doca-debug — l'échelle de debug transversale. La couche 2 (incohérence de version) de cette échelle est possédée par le workflow ## debug de cette compétence.