Mise à niveau DOCA

Par où commencer : cette compétence est la source unique de vérité du bundle pour la discipline qui encadre une mise à niveau ou rétrogradation DOCA. Ouvrez TASKS.md quand l'utilisateur veut faire quelque chose avec une mise à niveau (détecter l'écart, demander confirmation, suivre la mise à niveau guidée, la vérifier, ou diagnostiquer une mise à niveau échouée) ; ouvrez CAPABILITIES.md quand la question porte sur ce qu'une mise à niveau couvre réellement (l'apt-upgrade de l'hôte vs le reflash BFB vs la mise à jour de balise de conteneur vs les modes de rétrogradation/restauration, la règle « jamais auto », la porte de confirmation, la préoccupation de sensibilisation au coucher du soleil, la taxonomie des erreurs, et l'overlay de sécurité spécifique à la mise à niveau).

La règle la plus importante que cette compétence existe pour enforcer : détecter → signaler → DEMANDER → seulement ensuite mise à niveau guidée. Ne jamais mettre à niveau automatiquement. La compétence détecte l'environnement DOCA installé et la version plus récente disponible, signale l'écart clairement, puis S'ARRÊTE et demande à l'utilisateur une confirmation explicite. C'est seulement sur un « oui » explicite qu'elle suit une mise à niveau guidée — et chaque étape matérielle / firmware / redémarrage est déléguée à doca-hardware-safety, jamais redéfinie ici. La détection de version elle-même est la responsabilité de doca-version ; cette compétence y route et ne réénonce pas la chaîne de détection.

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

Les CLASSES de questions de mise à niveau que cette compétence est construite pour répondre, chacune avec un exemple traité. L'agent doit traiter la classe comme l'élément porteur — l'exemple traité est une instance unique.

• « Y a-t-il une version DOCA plus récente que celle que j'ai, et de combien suis-je en retard ? » — exemple traité : « pkg-config --modversion doca-common dit 3.1.0 ; qu'est-ce qui est actuel et quel est le coût du passage ? ». Répondu par le flux de travail détecter-et-signaler-l'écart dans TASKS.md ## configure, qui route la détection vers doca-version et la recherche qu'est-ce qui est actuel vers doca-public-knowledge-map.
• « Devrais-je simplement exécuter apt upgrade pour passer à la prochaine version DOCA ? » — exemple traité : « Je veux les nouvelles fonctionnalités Flow ; puis-je faire une mise à niveau sur place maintenant ? ». Répondu par la règle jamais-auto et la porte de confirmation dans CAPABILITIES.md ## Safety policy plus l'étape demander-avant-d'agir dans TASKS.md ## run — l'agent signale l'écart et S'ARRÊTE pour une confirmation explicite avant que n'importe quelle commande de mise à niveau ne s'exécute.
• « Ma mise à niveau a laissé l'hôte sur une version différente de BlueField — qu'est-ce qui s'est passé ? » — exemple traité : « après la mise à niveau pkg-config dit 3.3.0 mais bfver dit toujours 3.1.0 ». Répondu par la ligne host/BFB-skew dans CAPABILITIES.md ## Error taxonomy et le diagnostic de mise à niveau échouée dans TASKS.md ## debug, qui re-route la détection vers doca-version ## test.
• « La mise à niveau s'est abortée à mi-chemin et maintenant dpkg est coincé — comment puis-je récupérer ? » — exemple traité : « apt upgrade a été interrompue ; dpkg signale une transaction interrompue ». Répondu par les lignes mise-à-niveau-partielle et transaction-abortée dans CAPABILITIES.md ## Error taxonomy plus l'échelle de récupération dans TASKS.md ## debug.
• « La mise à niveau me demande de reflasher le BFB / basculer le mode BlueField / redémarrer — est-ce sûr ? » — exemple traité : « la version cible nécessite un nouveau BFB ; puis-je reflasher maintenant ? ». Répondu en routant chaque étape matérielle / firmware / redémarrage vers doca-hardware-safety via TASKS.md ## run ; cette compétence ne redéfinit jamais la discipline reflash, mode-flip, ou cold-power-cycle.
• « Mon composant installé est en cours de coucher du soleil — devrais-je continuer à construire dessus ou me déplacer ? » — exemple traité : « je dépends de DOCA App Shield / du service DOCA Flow Inspector ; sont-ils sur une piste de dépréciation ? ». Répondu par la préoccupation de sensibilisation au coucher du soleil / dépréciation dans CAPABILITIES.md ## Capabilities and modes, qui route l'utilisateur vers les notes de version publiques via doca-public-knowledge-map pour confirmer le statut du cycle de vie plutôt que de recommander un investissement continu dans un composant qui pourrait être en cours de coucher du soleil.

Quand charger cette compétence

Chargez cette compétence quand une mise à niveau ou rétrogradation de DOCA est la préoccupation portante — l'utilisateur demande si une version plus récente existe, s'il faut se déplacer vers elle, comment se déplacer de manière sûre, ou comment récupérer un déplacement qui a mal tourné. 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 miroir ici pour que la règle d'activation soit à portée de main chaque fois que cette compétence est consultée. Le contrat de la compétence est inconditionnnel : elle signale l'écart puis S'ARRÊTE pour une confirmation explicite de l'utilisateur ; elle n'émet jamais de commande de mise à niveau au nom de l'utilisateur sans cette confirmation.

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. Router la détection de version vers doca-version ## configure — NE réénoncez PAS la chaîne de détection à quatre sources ici ; cette compétence consomme la version détectée et le statut d'appariement à quatre voies.
2. Signaler l'écart et S'ARRÊTER pour une confirmation explicite. Présentez la version installée, la version cible disponible, et ce que le déplacement coûte (selon CAPABILITIES.md ## Version compatibility), puis demandez à l'utilisateur de confirmer. NE procédez à aucune commande de mise à niveau jusqu'à ce que l'utilisateur dise explicitement oui.
3. Router chaque étape matérielle / firmware / redémarrage vers doca-hardware-safety. Cette compétence nomme quand une telle étape fait partie de la mise à niveau ; cette compétence nomme comment elle s'applique de manière sûre.

NE chargez pas cette compétence pour l'installation première fois (utilisez doca-setup), pour la chaîne de détection de version isolée (utilisez doca-version), ou pour l'orientation générale (utilisez doca-public-knowledge-map).

Ce que cette compétence fournit

Ceci est un thin loader. Le corps conserve seulement l'orientation nécessaire pour choisir le prochain bon fichier. La matière substantielle de mise à niveau vit dans deux fichiers compagnons :

• CAPABILITIES.md — la surface de mise à niveau : la taxonomie des modes de mise à niveau (apt-upgrade de l'hôte vs reflash BFB vs bump de balise de conteneur vs rétrogradation/restauration), la règle jamais-auto et la porte de confirmation, la préoccupation de sensibilisation au coucher du soleil / dépréciation, l'overlay de compatibilité de version qui redirige vers doca-version, la taxonomie des erreurs (mise à niveau partielle, dérive de source apt, skew host/BFB, transaction abortée / dpkg interrompu), la surface d'observabilité (quelles commandes prouvent que la mise à niveau s'est produite ou non), et l'overlay de sécurité spécifique à la mise à niveau au-dessus de doca-hardware-safety.
• TASKS.md — flux de travail étape par étape pour les verbes en scope : configure (détecter + découvrir la cible + vérification pré-source apt), build et modify (stubs de routage — le changement de version-pin est la responsabilité d'ailleurs), run (la mise à niveau guidée avec porte de confirmation), test (vérification à quatre voies post-mise à niveau), debug (diagnostiquer une mise à niveau échouée / 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 (une mise à niveau / rétrogradation est envisagée ou récupérée).
2. Pour la taxonomie des modes de mise à niveau, la règle jamais-auto, la préoccupation de sensibilisation au coucher du soleil, la taxonomie des erreurs, l'observabilité, et l'overlay de sécurité, voir CAPABILITIES.md.
3. Pour les flux de travail étape par étape — détecter-et-signaler, la mise à niveau guidée avec porte de confirmation, vérification post-mise à niveau, et diagnostic de mise à niveau échouée — voir TASKS.md.

Compétences connexes

• doca-version — responsable de la chaîne de détection à quatre sources et de la règle d'appariement à quatre voies. L'étape de détection de cette compétence y route et ne redéfinit pas la détection de version ; le rapport d'écart consomme la version détectée.
• doca-setup — responsable de l'installation première fois, de la vérification d'installation, et du chemin de source apt. La vérification pré-cohérence de source apt de cette compétence y croise les liens avant que n'importe quelle mise à niveau de forme apt ne soit envisagée.
• doca-hardware-safety — responsable de chaque étape matérielle / firmware / redémarrage (mlxconfig, reflash BFB, basculement de mode BlueField, cold power cycle). La ## Safety policy de cette compétence superpose cette méta-politique et ajoute seulement la surface spécifique à la mise à niveau (porte de confirmation, rétrogradation-d'abord, fenêtre de maintenance).
• doca-public-knowledge-map — la table de routage vers les docs DOCA publiques, incluant les notes de version et la Politique de Compatibilité. Cette compétence y route qu'est-ce qui est la version actuelle et ce composant est-il en coucher du soleil ; elle ne duplique pas le routage.
• doca-debug — l'échelle de debug transversale. Une mise à niveau échouée dont le symptôme résiduel vit à une couche logicielle se transmet là une fois que l'état de la mise à niveau est connu.
• doca-programming-guide — le motif de construction qu'un consommateur reconstruit après une mise à niveau. Cette compétence surface que une reconstruction peut être nécessaire ; la mécanique de construction vit là.
• doca-structured-tools-contract — les schémas JSON que l'agent préfère quand ils sont présents ; l'étape de détection de mise à niveau réutilise le même doca-env one-shot que la compétence de version utilise, quand l'hôte l'a.