Pourquoi est-il déconseillé d'avoir un fichier CloudMD gigantesque ?	Plus le fichier est long, plus l'IA a du mal à suivre les instructions correctement.
Citez les quatre emplacements où le fichier CloudMD peut exister.	Politique gérée, fichier utilisateur, fichier de projet et local.
Quel est l'usage principal du scope "local" dans CloudMD ?	Définir des décisions architecturales spécifiques à un projet sans affecter les fichiers partagés.
Comment peut-on organiser un grand fichier CloudMD pour le rendre plus maintenable ?	Utiliser la syntaxe de chemin de fichier pour diviser les instructions (imports).
Quel est le principal inconvénient de l'utilisation des imports dans CloudMD ?	Tout le contenu est chargé en amont (up front) et ne réduit pas le contexte.
Quel critère est essentiel pour qu'une règle CloudMD soit efficace ?	Elle doit être spécifique et vérifiable (pas vague).
Donnez un exemple de règle CloudMD spécifique plutôt que vague.	"Ajouter une nouvelle route API et un gestionnaire de source API, un par fichier" (plutôt que "suivre les meilleures pratiques").
Quelle convention d'exportation doit être utilisée pour éviter les interprétations erronées ?	Utiliser des exports nommés plutôt que des exports par défaut.
Comment doit-on gérer l'emphase (emphasis) dans un fichier CloudMD ?	L'emphase doit être utilisée avec parcimonie, uniquement pour les deux ou trois règles les plus critiques.
Quelle approche doit-on adopter pour traiter le fichier CloudMD ?	Le traiter comme du code de production (si vous ne pouvez pas justifier une ligne, supprimez-la).