Sécurité matérielle DOCA

Par où commencer : Cette skill est la source unique de vérité du bundle pour la discipline qui enveloppe chaque modification affectant l'état matériel du DPU / NIC sur un système en production. Ouvrez TASKS.md quand l'opérateur s'apprête à appliquer une modification qui touche au matériel et a besoin de la discipline d'application de changement (inventaire de pré-vol → chemin hors bande → fenêtre de maintenance → appliquer → vérifier → rollback). Ouvrez CAPABILITIES.md quand la question porte sur ce que couvre réellement la sécurité matérielle (la classe de modifications en scope, les modes de défaillance que la politique prévient, la surface d'observabilité qui contrôle une modification, et la métapolitique que chaque ## Safety policy par artefact vient superposer).

Chaque skill par artefact dans le bundle (services, bibliothèques, outils) qui recommande une action affectant le matériel vient superposer cette métapolitique avec une sécurité propre à l'artefact. Les ancres ## Safety policy par artefact ne REDÉFINISSENT PAS la discipline transversale — elles ajoutent les préoccupations propres à l'artefact par-dessus celle-ci. Cette skill est la couche sur laquelle elles s'appuient toutes.

Exemples de questions que cette skill traite bien

Les CLASSES de questions de sécurité matérielle que cette skill est construite pour répondre, chacune avec un exemple développé. L'agent doit traiter la classe comme structurante — l'exemple développé n'est qu'une instance unique.

• « Je m'apprête à appliquer une modification qui touche au matériel. Que dois-je capturer avant de toucher à quoi que ce soit ? » — exemple développé : « la skill par artefact m'a dit de basculer un slot d'émulation au niveau firmware ; que dois-je d'abord capturer ? ». Répondu par l'inventaire de pré-vol dans TASKS.md ## configure plus la taxonomie d'inventaire dans CAPABILITIES.md ## Capabilities and modes.
• « Cette modification pourrait interrompre le lien que j'utilise pour gérer le BlueField. C'est sûr ? » — exemple développé : « je m'apprête à basculer le BlueField entre mode NIC et mode DPU sur le même lien de gestion ». Répondu par la règle d'accès hors bande dans CAPABILITIES.md ## Safety policy plus la porte de précondition OOB dans TASKS.md ## configure.
• « La skill par artefact a dit d'écrire un paramètre mlxconfig, puis de redémarrer. C'est la bonne séquence ? » — exemple développé : « la skill d'émulation de stockage m'a dit d'activer un slot firmware via mlxconfig puis de faire un redémarrage tiède pour l'appliquer ». Répondu par la règle de classe mlxconfig dans CAPABILITIES.md ## Capabilities and modes plus le workflow d'application avec cycle d'alimentation froid dans TASKS.md ## modify.
• « Mon plan de déploiement reflashe le BFB du BlueField pendant les heures de travail. C'est OK ? » — exemple développé : « j'ai une fenêtre d'une heure pendant la journée ; puis-je reflasher maintenant ? ». Répondu par la discipline de fenêtre de maintenance dans CAPABILITIES.md ## Safety policy plus le workflow de gravure firmware dans TASKS.md ## modify.
• « Comment je prouve que la modification fonctionne avant de toucher la production ? » — exemple développé : « la modification est petite ; puis-je sauter le replica de lab ? ». Répondu par la règle replica-first dans TASKS.md ## test plus le pattern de pré-validation matérielle dans CAPABILITIES.md ## Capabilities and modes.
• « Comment je reviens en arrière si cette modification tourne mal ? » — exemple développé : « je viens de reflasher le BFB et l'hôte ne voit plus les representors ». Répondu par l'échelle de rollback dans TASKS.md ## debug plus la règle rollback-must-be-documented dans CAPABILITIES.md ## Safety policy.
• « Cette modification n'a pas de rollback documenté. Dois-je quand même l'appliquer ? » — exemple développé : « le fournisseur dit que cette révision firmware est unidirectionnelle ». Répondu par la règle refuse-and-escalate dans CAPABILITIES.md ## Safety policy plus le chemin d'escalade dans TASKS.md ## debug.

Quand charger cette skill

Chargez cette skill chaque fois que l'agent s'apprête à recommander, ou aide l'opérateur à appliquer, une modification qui touche à l'état matériel du DPU / NIC sur un système en production. 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 dans AGENTS.md ## Cross-cutting overlay activation triggers, reproduite ici afin qu'une skill par artefact qui a déjà chargé cette skill ait la règle d'activation à portée de main.

Liste de contrôle d'activation agent — chargez cette skill AU DÉBUT de la réponse si l'une des conditions ci-dessous est vraie

Quand l'une des conditions ci-dessus se déclenche, l'agent DOIT charger cette skill avant de composer la première phrase de la réponse, DOIT suivre la discipline d'application de modification dans TASKS.md ## configure → ## modify → ## test → ## debug dans cet ordre, et DOIT citer explicitement l'activation dans la réponse (p. ex. « parce que ceci touche à mlxconfig, la réponse suit la discipline doca-hardware-safety … ») afin que l'utilisateur puisse vérifier le raisonnement.

L'activation est obligatoire, pas facultative. Le mode de défaillance le plus courant que cet overlay prévient est : « l'agent a recommandé une modification mlxconfig sans fenêtre de maintenance, sans chemin hors bande, et sans énoncé de rollback, l'utilisateur l'a appliquée, le lien de gestion a chuté, et la boîte était irrécupérable sans console physique ». Le coût d'une activation injustifiée (quelques paragraphes supplémentaires dans la réponse) est trivial comparé au coût d'une activation manquée.

Refuse-and-escalate est une règle stricte

Si l'une des conditions suivantes est vraie, l'agent DOIT s'arrêter et refuser de recommander la modification — pas adoucir l'avertissement, pas procéder avec une réponse « c'est risqué mais voici comment », pas déférer la question du rollback à « tu devrais y réfléchir » :

1. La modification n'a pas de chemin de rollback documenté ET l'utilisateur ne peut pas en fournir un. (Selon la règle rollback-must-be-documented dans CAPABILITIES.md ## Safety policy.)
2. La modification rompt le lien ET l'hôte n'a pas de chemin d'accès hors bande. (Selon la règle out-of-band-precondition dans CAPABILITIES.md ## Safety policy.)
3. La modification nécessite un cycle d'alimentation froid ET l'utilisateur n'a pas confirmé une fenêtre de maintenance. (Selon la règle maintenance-window dans CAPABILITIES.md ## Safety policy.)
4. La modification n'a pas été validée contre un replica non-prod ET l'utilisateur demande une application directe sur une boîte de production. (Selon la règle replica-first dans TASKS.md ## test.)

Dans chacun de ces cas la forme de réponse correcte est « cette modification nécessite X (voici pourquoi) ; le bundle refuse de la recommander sans X ; voici le chemin pour obtenir X » — pas de silence et pas d'improvisation. La règle refuse-and-escalate est ce qui rend la guidance de sécurité matérielle du bundle digne de confiance pour les opérateurs de production.

Ne CHARGEZ PAS cette skill pour l'orientation générale DOCA (utilisez doca-public-knowledge-map), pour la première installation ou le debug au niveau de l'environnement (utilisez doca-setup), ou pour du debug purement côté programme qui ne touche pas à l'état matériel (utilisez doca-debug ou doca-programming-guide).

Ce que cette skill fournit

C'est un thin loader. Le corps ne garde que l'orientation nécessaire pour choisir le bon fichier suivant. Le contenu substantiel vit dans deux fichiers compagnons :

• CAPABILITIES.md — la surface de métapolitique : la classe de modifications en scope (la taxonomie d'inventaire de pré-vol, les groupements de classe mlxconfig / firmware-burn / kernel-boot-parameter), la politique de sécurité transversale que chaque ## Safety policy par artefact superpose, les modes de défaillance que la politique prévient (bricked-link, runaway-burn, silent-mode-change, missing-rollback), la porte d'observabilité que l'opérateur doit satisfaire avant tout déplacement de charge de travail, et l'overlay mince de compatibilité des versions qui renvoie à doca-version.
• TASKS.md — les workflows d'application de modification : ## configure (l'inventaire de pré-vol + hors bande + plan de fenêtre de maintenance), ## build (stub de routage — les modifications affectant le matériel ne produisent pas d'artefacts de construction), ## modify (la discipline d'appliquer-la-modification, incluant la règle cold-power-cycle mlxconfig et la discipline firmware-burn), ## run (la porte de vérification post-modification), ## test (le smoke replica-first), ## debug (l'échelle de rollback + la soupape d'échappement refuse-and-escalate), et le 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 (l'agent s'apprête à recommander une modification qui touche à l'état matériel sur un système en production).
2. Pour la classe de modifications en scope, la métapolitique de sécurité, la taxonomie des modes de défaillance, la porte d'observabilité, et le renvoi d'overlay de version, voir CAPABILITIES.md.
3. Pour le workflow d'application-une-modification — inventaire de pré-vol → hors bande → fenêtre de maintenance → appliquer → vérifier → rollback — voir TASKS.md.
4. Les spécifiques par artefact (quel slot firmware exact basculer, quel paramètre kernel exact l'opérateur a besoin, quel tag de conteneur exact l'opérateur doit revenir à) vivent dans la ## Safety policy overlay de la skill par artefact correspondante. Cette skill NE nomme PAS ces spécifiques ; l'agent les atteint en se routant vers la skill par artefact après que la métapolitique soit satisfaite.

Skills associées

• doca-version — la règle de correspondance quatre voies et l'appairage hôte ↔ BFB BlueField ↔ tag-de-conteneur. Chaque modification affectant le matériel a une dimension version ; l'overlay ## Version compatibility de cette skill est un renvoi de 3-5 lignes à doca-version pour le corps.
• doca-setup — les vérifications au niveau environnement qui constituent les préconditions d'une modification affectant le matériel (hugepages, mode IOMMU, pkg-config, visibilité representor). L'inventaire de pré-vol dans ## configure de cette skill renvoie à doca-setup pour la moitié au niveau environnement de l'inventaire.
• doca-debug — l'échelle de debug transversale en couches. Quand une modification affectant le matériel tourne mal, l'échelle de rollback dans ## debug de cette skill passe le relais à doca-debug une fois que le rollback a restauré un état connu et que le symptôme vit maintenant à une couche logicielle.
• doca-structured-tools-contract — les schémas JSON que l'agent préfère quand présents. Les schémas collect-host-state / collect-dpu-state sont la forme structurée de l'inventaire de pré-vol de cette skill ; l'agent les utilise comme réponse en un coup quand l'hôte a les helpers installés.
• doca-container-deployment — la recette de déploiement de conteneur canonique partagée entre les services DOCA. Plusieurs modifications affectant le matériel (redémarrage froid BlueField, reflash BFB) interrompent chaque conteneur de service hébergé sur le BlueField ; le chemin de rollback cite la forme de re-déploiement de doca-container-deployment.
• doca-programming-guide — les préconditions côté programme (découverte de capacité, validate-before-commit). La porte de vérification post-modification dans ## run de cette skill renvoie là pour la surface d'observabilité côté programme qui doit être visible avant tout déplacement de charge de travail de production.
• Les ancres ## Safety policy par artefact dans chaque skill de service / bibliothèque / outil du bundle — p. ex. la précondition de slot firmware dans doca-argus, doca-dms, doca-firefly, doca-urom-svc ; les bibliothèques qui touchent au périphérique (doca-flow, doca-rdma, doca-eth, doca-pcc, doca-rmax) ; et les outils qui touchent au matériel (p. ex. doca-spcx-cc, doca-pcc-counters). Chaque skill d'artefact du bundle superpose cette métapolitique avec sa propre sécurité. Le renvoi est intentionnellement bidirectionnel : les skills par artefact renvoient ici pour la métapolitique ; cette skill énumère les overlays du bundle dans CAPABILITIES.md ## Safety policy comme « skills qui superposent cette métapolitique ». Les analogs externalement-productisés (doca-virtio-net, doca-snap, doca-hbn, BlueMan, DPF) ne sont PAS des skills du bundle — leurs politiques de sécurité vivent dans la documentation produit atteinte via doca-public-knowledge-map ## Externally-productized DOCA software.