Ajouter des fonctionnalités à une application de bureau en couches et tester chaque configuration

## Définir le rôle du noyau, de l’hôte de bureau et de l’interface Définissez les plateformes livrées, les clients pris en charge, la topologie des processus et les limites de confiance avant de modifier le code. - Conservez les règles métier, la persistance, l’exécution et le comportement du domaine dans un noyau de référence. - Confiez à l’hôte de bureau le cycle de vie, les capacités natives, la passerelle sécurisée et le conditionnement. - Confiez à l’interface Web la présentation, la navigation et l’orchestration ; ne dupliquez pas les règles du noyau dans le moteur de rendu. - Acheminez les appels de l’interface vers le noyau par une seule abstraction de transport authentifiée, plutôt que par des accès directs improvisés. - Traitez les clients expérimentaux comme des surfaces de compatibilité distinctes dont le transport, le chiffrement et l’état de publication sont explicites. - Tenez à jour une cartographie de l’architecture qui nomme chaque couche, l’état dont elle est responsable, ses interfaces publiques et les responsabilités qui lui sont interdites. ## Classer les commandes par risque et limiter les outils au dossier de l’utilisateur Centralisez la configuration et appliquez une politique unique de refus par défaut à chaque outil capable d’agir. - Lisez les valeurs d’environnement au moyen de modules de configuration typés ; le code des fonctionnalités ne doit pas accéder directement aux variables d’environnement du processus ni de la compilation. - Modélisez l’autonomie sous forme de niveaux explicites combinés aux limites de l’espace de travail, aux répertoires racines de confiance et à l’autorisation d’installation. - Classez les commandes en lecture, écriture, réseau, installation ou action destructrice ; traitez toute commande non reconnue comme une opération d’écriture. - Pour chaque classe, déterminez si elle est autorisée, soumise à confirmation ou bloquée selon le niveau actif. Bloquez toujours les emplacements du système et des identifiants. - Séparez la racine d’action de l’utilisateur de l’état interne de l’application. Les outils ne peuvent agir qu’à l’intérieur de cette racine et ne doivent jamais écrire directement dans l’état interne. - Laissez les contrôles d’approbation activés par défaut pour les modifications interactives, faites expirer les demandes sans réponse et refusez l’action à leur expiration. - Associez la validation des chemins au niveau de l’application à un bac à sable du système d’exploitation ou du conteneur ; le bac à sable constitue une défense en profondeur, pas un substitut aux contrôles de politique. ## Donner à chaque domaine son propre module dans le noyau Attribuez à chaque domaine un module dédié, avec une responsabilité claire et des fichiers petits et composables. ### Utiliser une structure de module canonique - Limitez la façade du module aux exportations et excluez-en toute logique métier. - Placez les types de domaine sérialisables, la persistance, les opérations, les schémas des contrôleurs, les outils des agents, les abonnés aux événements et les tests dans des fichiers distincts lorsque ces responsabilités existent. - Placez les outils propres à un domaine avec ce domaine et réservez l’infrastructure d’outils partagée aux comportements réellement transversaux. - Limitez les modules de transport à l’authentification, à l’acheminement, à la journalisation, à l’observabilité et aux questions de protocole. Exposez les contrôleurs au moyen d’un registre de paires schéma-gestionnaire. Un nouveau comportement doit ajouter un contrôleur de domaine et l’enregistrer en un seul point de composition, plutôt que multiplier les branches par nom de commande dans tout le code de transport. ## Garder les options d’exécution séparées des fonctionnalités de compilation Modélisez deux axes indépendants : - Un ensemble de services sélectionne les services d’arrière-plan et les transports en cours d’exécution. - Un ensemble de domaines sélectionne les familles de domaines disponibles à l’exécution. - Les fonctionnalités de compilation retirent du code et des dépendances pour créer des variantes du produit. Le filtrage à l’exécution doit retirer de la surface active les contrôleurs, outils, magasins de données et abonnés d’un domaine désactivé. Les barrières de compilation doivent se combiner à ce comportement sans modifier la version compilée par défaut. Faites du point d’enregistrement la référence afin d’éviter toute divergence entre les schémas, l’acheminement, les outils et les services de démarrage. ## Choisir comment désactiver les fonctionnalités optionnelles selon les vraies dépendances Choisissez la plus petite barrière qui préserve le comportement toujours actif. 1. Utilisez une barrière au niveau d’une feuille lorsque chaque référence externe est un point d’enregistrement ; les surfaces des fonctionnalités désactivées doivent être absentes, et non enregistrées sous forme d’implémentations factices vouées à l’échec. 2. Utilisez une façade avec des implémentations factices du comportement uniquement lorsque des appelants toujours compilés exigent des symboles invocables. 3. Isolez les types partagés sans dépendance dans des modules toujours compilés et ne remplacez que le comportement par une implémentation factice. Ne dupliquez jamais les définitions de types entre les versions activées et désactivées. 4. Scindez un répertoire lorsque certains utilitaires servent des domaines toujours actifs ; protégez les véritables arêtes de dépendance, pas les noms des dossiers. 5. Préservez les fonctions auxiliaires indispensables même lorsqu’elles se trouvent sous un domaine optionnel. Ne remplacez pas une implémentation nécessaire par une version factice qui simule une réussite. Lorsqu’une commande reste visible alors que sa fonctionnalité est exclue de la compilation, renvoyez une erreur explicite indiquant sa désactivation dans cette version compilée, plutôt qu’une erreur trompeuse de commande inconnue. Pour les données sans effet à la compilation qui nomment encore des composants désactivés, faites en sorte que la résolution tolère les identifiants absents et testez ce contrat. N’affirmez jamais qu’une barrière de fonctionnalité retire des dépendances en vous fondant uniquement sur une compilation réussie. Prouvez chaque retrait annoncé par une interrogation inverse de l’arbre des dépendances dans la configuration désactivée. ## Tester les configurations avec les fonctionnalités optionnelles activées et désactivées Traitez les tests comme une composante de l’architecture et couvrez le comportement, l’intégration et le conditionnement. - Placez les tests unitaires ciblés à proximité du code concerné et privilégiez le comportement observable aux détails d’implémentation. - Utilisez un service simulé partagé pour des tests d’intégration déterministes ; interdisez les accès réels au réseau et les attentes dépendantes du temps dans les suites de tests unitaires. - Définissez les scénarios de bout en bout avant l’implémentation, y compris les parcours réussis, les échecs, les contrôles d’autorisation et la récupération. - Testez les fonctionnalités optionnelles dans les deux sens : prouvez leur enregistrement lorsqu’elles sont activées et leur absence lorsqu’elles sont désactivées. - Exécutez explicitement la suite de tests de la version désactivée. Une étape de contrôle qui se contente de compiler ne compile pas le code des tests et ne peut pas prouver que les tests protégés restent valides. - Imposez un seuil de couverture des lignes modifiées et revenez à la suite complète lorsque la configuration partagée ou des contrats fondamentaux changent. - Construisez une seule fois les artefacts de plateforme coûteux, puis répartissez les tests à partir de cet artefact lorsque le système de construction le permet. ## Ajouter des journaux de diagnostic sans secrets ni données personnelles Les flux nouveaux et modifiés exigent des diagnostics à l’entrée, à la sortie, aux embranchements, aux appels externes, aux nouvelles tentatives, aux expirations, aux transitions d’état et aux erreurs. - Utilisez des préfixes de domaine stables et faciles à rechercher, ainsi que des champs de corrélation tels que les identifiants de requête et les noms de méthode. - Gardez les journaux ordinaires concis, tout en rendant les niveaux de débogage et de traçage suffisants pour des investigations ciblées. - Ne consignez jamais dans les données analytiques des secrets, des identifiants bruts, des données personnelles complètes, du contenu rédigé par l’utilisateur, des identifiants d’entité, des noms de fichiers ni des messages d’erreur bruts. - Acheminez les données analytiques par une seule API de fonctionnalité tenant compte du consentement et utilisez des noms d’événements stables dépourvus de contenu. - Considérez l’absence de diagnostics comme une implémentation incomplète lorsque la modification introduit un nouveau chemin d’exécution. ## Traduire tous les textes de l’interface et ne pas modifier à la main les documents générés Utilisez un état, un transport et une localisation centralisés plutôt que des raccourcis locaux. - Préférez la couche de gestion d’état prévue pour l’application au stockage dispersé dans le navigateur. - Utilisez le client partagé du noyau pour tous les appels au noyau et maintenez les transports parallèles alignés sur le plan comportemental. - Protégez les API réservées à l’environnement natif au moyen du détecteur d’environnement d’exécution et du périmètre de gestion des erreurs pris en charge. - Faites passer chaque chaîne visible par le système de localisation, ajoutez de véritables traductions pour chaque paramètre régional pris en charge et conservez exactement les espaces réservés d’interpolation. - Exécutez les contrôles de syntaxe de localisation, de résidus d’anglais et de couverture avant de terminer. - Ne modifiez jamais manuellement les blocs de documentation générés. Mettez à jour leur marqueur source, régénérez-les et faites échouer les contrôles de divergence lorsque la sortie est obsolète. - Évitez d’ajouter une injection de script aux vues tierces intégrées ; implémentez les nouveaux comportements au moyen de gestionnaires natifs, d’outils de protocole ou de points d’ancrage IPC contrôlés. ## Construire chaque fonctionnalité du noyau à l’interface en testant chaque couche Suivez un processus vertical fixe : 1. Spécifiez le comportement à partir des contrats de domaine existants, des conventions de nommage, de la politique de sécurité et des scénarios de bout en bout. 2. Implémentez la logique de domaine de référence avec des tests unitaires. 3. Validez la limite du contrôleur ou de RPC au moyen d’un test d’intégration. 4. Rendez le comportement accessible dans l’interface par le client partagé, tout en conservant les règles dans le noyau. 5. Ajoutez des tests unitaires de l’interface et une couverture de bout en bout sur les plateformes. 6. Mettez à jour les métadonnées des fonctionnalités destinées aux utilisateurs et la documentation d’architecture lorsqu’une fonctionnalité est ajoutée, retirée ou renommée. Ne passez pas à la couche suivante tant que la couche actuelle n’a pas été testée. Gardez les modules petits et consacrés à une seule fonction, et mettez à jour la documentation en même temps que le comportement qu’elle régit. ## Ne pas sauter les contrôles obligatoires et montrer leurs résultats avant de conclure Effectuez les modifications dans une branche dédiée, ciblez la branche d’intégration désignée du dépôt et maintenez les publications en production liées à la source de publication déclarée. - Utilisez, depuis la racine du dépôt, le gestionnaire de paquets canonique, la chaîne d’outils verrouillée, l’outil de formatage, l’analyseur statique, le vérificateur de types et les exécuteurs de tests. - Maintenez synchronisés les réglages équivalents des profils de compilation entre les composants natifs compilés séparément. - Ne contournez jamais les points d’accroche ou les contrôles requis pour masquer des échecs. Si un point d’accroche génère des fichiers, examinez et incluez les résultats, puis exécutez-le à nouveau. - Corrigez les échecs provoqués par la modification ; documentez les obstacles préexistants sans rapport au lieu d’affaiblir silencieusement les protections. - Examinez la différence finale pour vérifier la cohérence de l’implémentation, des tests, des schémas, des artefacts générés, de la localisation et de la documentation. - Ne déclarez pas la tâche terminée sans résultats directs des contrôles pertinents pour chaque couche modifiée et chaque configuration de compilation prise en charge.