Écrire d'abord la spécification, puis développer par petites étapes en commençant par les tests

## Noter les exigences floues comme questions et attendre les réponses avant de planifier Ne planifiez ni ne mettez en œuvre tant qu’une exigence importante reste incertaine. Recensez les exigences non résolues, les attentes non fonctionnelles, le comportement, la télémétrie, les politiques et les critères d’acceptation avant de proposer des modifications. Avant de demander une décision, consignez chaque clarification à fort impact et chaque incertitude à impact moyen dans le registre des questions ouvertes prévu par le dépôt. Attribuez un identifiant stable à chaque question et maintenez la spécification de référence, le plan et la liste des tâches dans le périmètre de cet identifiant jusqu’à sa résolution. Lorsque vous présentez des solutions, enregistrez d’abord les mêmes choix, puis résumez-les directement pour l’utilisateur. Placez la solution recommandée en premier, exposez brièvement ses avantages et ses inconvénients, citez l’identifiant de la question et arrêtez-vous jusqu’à ce que la réponse requise soit disponible. Une fois la question résolue, intégrez la réponse aux sections normatives de la spécification et clôturez l’entrée du registre. ## Lire la spécification et la carte d'architecture avant de planifier Travaillez depuis la racine du dépôt et appliquez les instructions valables pour l’ensemble du dépôt ainsi que chaque règle imbriquée pertinente. Avant de planifier, lisez la feuille de route actuelle, la spécification de référence de la fonctionnalité, la carte des modules ou des connaissances, les conventions de code et les décisions architecturales liées à la fonctionnalité concernée. Cartographiez les modules, les contrats et les limites de responsabilité que la modification peut toucher. Utilisez l’instantané d’architecture tenu à jour par le dépôt plutôt que de déduire les relations d’un seul fichier voisin, et mettez cette carte à jour lorsque les modules, les dépendances ou les contrats changent. Utilisez les modèles approuvés pour les spécifications, les plans, les tâches et les décisions architecturales afin de préserver la cohérence des métadonnées, des notes de vérification et des renvois. ## Mettre à jour d'abord la spécification, puis le plan et la liste des tâches Créez ou actualisez la spécification de la fonctionnalité avant la mise en œuvre. Définissez les exigences, les exigences non fonctionnelles, les détails du comportement ou de l’interface, la télémétrie et les politiques, les branches d’acceptation ainsi qu’une esquisse de l’interface lorsque le comportement visuel change. Résolvez toutes les questions à impact fort ou moyen avant de produire le plan de mise en œuvre. Après avoir actualisé la spécification, consignez les résultats importants sur le plan architectural dans un registre de décisions architecturales et conservez les clarifications résolues dans les sections normatives plutôt que dans une liste héritée de clarifications distincte. Ce n’est qu’ensuite que vous devez actualiser le plan et la liste de tâches. Placez les tests avant la mise en œuvre, divisez le travail en incréments logiques prévus pour tenir dans un délai de 90 minutes et exécutez le contrôle d’analyse du dépôt une fois la spécification, le plan et les tâches alignés. N’inventez aucun comportement de repli ou de compatibilité, sauf demande explicite de l’utilisateur. ## Reprendre la session depuis un seul état enregistré et le mettre à jour avant la passation Au début d’une session dépourvue de contexte, suivez le guide du dépôt consacré à la réinitialisation ou à la transmission. Résumez l’état de la feuille de route, l’avancement du plan actif et les questions non résolues avant d’entreprendre une nouvelle mise en œuvre. Conservez un seul instantané désigné de la session actuelle comme état actif entre les sessions. Avant la transmission, mettez-le à jour avec la fonctionnalité active, le travail terminé, les questions en attente, l’état de la vérification et la prochaine action sûre. Ne créez pas de relevés d’avancement concurrents. Gardez explicite la responsabilité de chaque fonctionnalité et module afin que la documentation, l’automatisation, la sécurité, la persistance et le travail d’interface soient actualisés à leurs emplacements de référence. ## Écrire d'abord un test qui échoue pour chaque comportement Actualisez la spécification de référence et le plan avant de modifier le code. Pour chaque comportement, écrivez ou étendez d’abord un test exécutable unitaire, comportemental, contractuel ou de scénario, puis confirmez qu’il échoue pour la raison prévue. Pendant la planification, répertoriez les branches de réussite, de validation et d’échec, puis ajoutez à chaque parcours un test minimal qui échoue. Mettez en œuvre uniquement le code nécessaire pour faire réussir les tests, puis remaniez-le tout en maintenant leur réussite. Une fois la boucle terminée, consignez les modifications de couverture, les enseignements et les travaux de suivi dans le plan ou la feuille de route afin que le raisonnement reste vérifiable. ## Faire de petites modifications autonomes et cocher chaque tâche aussitôt Gardez chaque incrément autonome et respectez les conventions du dépôt relatives au langage, au cadre de développement, à la documentation et aux tests. Préférez une orchestration linéaire composée de petits auxiliaires de validation et de normalisation à des embranchements en ligne profondément imbriqués. Synchronisez la feuille de route, la spécification, le plan et la liste de tâches au fil des changements de comportement. Marquez immédiatement chaque tâche vérifiée comme terminée au lieu de regrouper les mises à jour d’état, et actualisez la carte d’architecture dès qu’une relation entre modules ou qu’un contrat change. N’utilisez les registres de décisions que pour les décisions architecturales confirmées. Évitez les remaniements sans rapport, le formatage massif et les travaux de compatibilité spéculatifs, et gardez la mise en œuvre alignée sur l’incrément approuvé. ## Lancer les contrôles des types de fichiers modifiés et analyser les échecs au lieu de les ignorer Pendant les itérations, exécutez le formateur, l’analyseur de style, l’analyse statique, la vérification des types et les tests ciblés dans le périmètre applicable le plus restreint. Avant de terminer, exécutez tous les contrôles exigés par le dépôt pour les types de fichiers modifiés et pour toute limite d’intégration directement touchée. Traitez l’échec d’un contrôle local ou d’intégration continue comme un défaut à examiner, et non comme un contrôle à contourner. Si la politique du dépôt autorise explicitement une dérogation temporaire à un test, désactivez uniquement le test concerné, ajoutez un `TODO` explicite avec sa justification et consignez le suivi dans le plan de référence. Ajoutez ou actualisez des tests pour chaque comportement modifié. Examinez les différences finales, confirmez que la documentation et la couverture des tests correspondent à la mise en œuvre et ne déclarez pas l’incrément terminé tant que des contrôles obligatoires échouent. ## Obtenir un accord avant d'ajouter des dépendances ou de faire des opérations Git risquées N’ajoutez à l’index Git que les fichiers appartenant à l’incrément. N’utilisez pas de mise en index globale lorsque des sorties générées, des artefacts de base de données ou des travaux parallèles peuvent exister. Préparez une description de commit atomique conforme aux conventions, en indiquant l’effet sur la spécification lorsque la documentation et le code changent ensemble, mais laissez l’opérateur désigné créer le commit sauf si l’exécution a été explicitement déléguée. Obtenez une autorisation explicite avant d’ajouter ou de mettre à niveau des dépendances, de supprimer des fichiers ou répertoires précis, de réécrire l’historique, de pousser des modifications ou de créer une revue externe. Consignez dans le plan de la fonctionnalité la justification d’une dépendance approuvée et accordez suffisamment de temps aux hooks gérés et aux processus de qualité. N’incluez jamais de secrets dans un commit et n’utilisez pas de nettoyage destructeur comme raccourci. Présentez pour examen tout fichier suivi ou non suivi inattendu et laissez intact le travail sans rapport. ## Ne pas ajouter de solutions de compatibilité sans demande et proposer d'abord les changements risqués Respectez la position déclarée du dépôt en matière de compatibilité. Lorsque les interfaces sont considérées comme entièrement nouvelles, n’ajoutez pas de solutions de repli, de couches d’adaptation ni de contrôles hérités, sauf si l’utilisateur les demande explicitement pour la tâche en cours. Consignez les résumés des consignes, les séquences de commandes importantes et leur justification dans le plan actif ou dans une annexe liée. Proposez avant toute modification les remaniements risqués, les changements de persistance, les modifications de la stratégie de sécurité et les compromis non fonctionnels majeurs, puis enregistrez les décisions architecturales approuvées dans le journal de décisions approprié. Suivez dans les plans les futurs tests de contrat, les analyses de mutation et les exercices de sécurité jusqu’à la mise en place de contrôles automatisés. Conservez les orientations opérationnelles à proximité de leur processus de référence et évitez de dupliquer entre plusieurs documents des instructions susceptibles de changer. ## Tester seulement sur la base de test et vérifier la connexion avant toute réinitialisation N’exécutez jamais de commande de réinitialisation, d’effacement complet ou de nouvelle migration d’une base de données au moyen d’une connexion non vérifiée. Avant toute migration ou réinitialisation, confirmez l’environnement actif, la cible de connexion et le fait que l’opération est limitée à une base de données de test jetable. Exécutez les tests de l’application sur la base de données de test isolée du dépôt et utilisez sa configuration documentée de transactions ou de migrations. Ne réinitialisez que la base de données de test explicitement désignée lorsque cela est nécessaire ; ne supposez pas qu’une commande de test et une commande interactive de l’application utilisent la même connexion. Créez les nouvelles migrations sous forme de fichiers et exercez-les au moyen du processus de test. Si le périmètre de la base de données est ambigu, arrêtez-vous et obtenez une confirmation plutôt que de mettre en danger les données de développement ou de production. ## Clore chaque étape par une passation de ce qui a changé et de ce qui a été vérifié Après qu’un incrément autonome a réussi les contrôles applicables, confirmez que les tâches terminées, l’état de la feuille de route, les modifications de la spécification, les registres de décisions et l’instantané de la session actuelle sont synchronisés. Fournissez une transmission concise qui répertorie les fichiers modifiés, les contrôles exécutés et leurs résultats, les blocages non résolus, les travaux de suivi et toutes les commandes prêtes à copier pour l’opérateur. Distinguez les travaux mis en œuvre de ceux qui sont seulement planifiés ou en attente d’autorisation. Préparez rapidement le commit de la fonctionnalité après la vérification, mais ne l’exécutez que dans le cadre de la politique de délégation du dépôt. Conservez suffisamment de preuves pour que la session suivante puisse reprendre sans répéter l’exploration.