diff --git a/CODE_OF_CONDUCT_fr.md b/CODE_OF_CONDUCT_fr.md deleted file mode 100644 index 8ce79b16c4..0000000000 --- a/CODE_OF_CONDUCT_fr.md +++ /dev/null @@ -1,74 +0,0 @@ -# Code de Conduite du Pacte des Contributeurs - -## Notre Engagement - -Dans l'intérêt de favoriser un environnement ouvert et accueillant, nous en tant que -contributeurs et mainteneurs nous engageons à faire de la participation à notre projet et -notre communauté une expérience sans harcèlement pour tous, indépendamment de l'âge, de la corpulence, -du handicap, de l'appartenance ethnique, de l'identité et de l'expression de genre, du niveau d'expérience, -de la nationalité, de l'apparence personnelle, de la race, de la religion, ou de l'identité sexuelle et -de l'orientation. - -## Nos Standards - -Des exemples de comportement qui contribuent à créer un environnement positif -incluent : - -* Utiliser un langage accueillant et inclusif -* Être respectueux des points de vue et expériences différents -* Accepter gracieusement les critiques constructives -* Se concentrer sur ce qui est le mieux pour la communauté -* Montrer de l'empathie envers les autres membres de la communauté - -Des exemples de comportement inacceptable par les participants incluent : - -* L'utilisation d'un langage ou d'imagerie sexualisés et les avances sexuelles non souhaitées ou -l'attention -* Le trolling, les commentaires insultants/désobligeants, et les attaques personnelles ou politiques -* Le harcèlement public ou privé -* La publication d'informations privées d'autrui, comme une adresse physique ou électronique, - sans permission explicite -* Autre conduite qui pourrait raisonnablement être considérée comme inappropriée dans un - cadre professionnel - -## Nos Responsabilités - -Les mainteneurs du projet sont responsables de clarifier les standards de comportement acceptable -et sont attendus à prendre des mesures correctives appropriées et équitables en -réponse à toute instance de comportement inacceptable. - -Les mainteneurs du projet ont le droit et la responsabilité de supprimer, éditer, ou -rejeter les commentaires, commits, code, éditions de wiki, issues, et autres contributions -qui ne sont pas alignées à ce Code de Conduite, ou de bannir temporairement ou -définitivement tout contributeur pour d'autres comportements qu'ils jugent inappropriés, -menaçants, offensants, ou nuisibles. - -## Portée - -Ce Code de Conduite s'applique à la fois dans les espaces du projet et dans les espaces publics -quand un individu représente le projet ou sa communauté. Des exemples de -représentation d'un projet ou d'une communauté incluent l'utilisation d'une adresse e-mail officielle du projet, -la publication via un compte de média social officiel, ou agir comme un représentant désigné -lors d'un événement en ligne ou hors ligne. La représentation d'un projet peut être -davantage définie et clarifiée par les mainteneurs du projet. - -## Application - -Les instances de comportement abusif, harcelant, ou autrement inacceptable peuvent être -signalées en contactant l'équipe du projet à . Toutes -les plaintes seront examinées et enquêtées et résulteront en une réponse qui -est jugée nécessaire et appropriée aux circonstances. L'équipe du projet est -obligée de maintenir la confidentialité en ce qui concerne le rapporteur d'un incident. -Des détails supplémentaires de politiques d'application spécifiques peuvent être postés séparément. - -Les mainteneurs du projet qui ne suivent pas ou n'appliquent pas le Code de Conduite de bonne -foi peuvent faire face à des répercussions temporaires ou permanentes telles que déterminées par d'autres -membres de la direction du projet. - -## Attribution - -Ce Code de Conduite est adapté du [Pacte des Contributeurs][homepage], version 1.4, -disponible à [http://contributor-covenant.org/version/1/4][version] - -[homepage]: http://contributor-covenant.org -[version]: http://contributor-covenant.org/version/1/4/ \ No newline at end of file diff --git a/CONTRIBUTING_fr.md b/CONTRIBUTING_fr.md deleted file mode 100644 index 0060c077a5..0000000000 --- a/CONTRIBUTING_fr.md +++ /dev/null @@ -1,50 +0,0 @@ -## Contribuer au Kit de Spécifications - -Salut ! Nous sommes ravis que vous souhaitiez contribuer au Kit de Spécifications. Les contributions à ce projet sont [publiées](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license) au public sous la [licence open source du projet](LICENSE). - -Veuillez noter que ce projet est publié avec un [Code de Conduite des Contributeurs](CODE_OF_CONDUCT_fr.md). En participant à ce projet, vous acceptez de respecter ses termes. - -## Prérequis pour exécuter et tester le code - -Ce sont des installations uniques requises pour pouvoir tester vos changements localement dans le cadre du processus de soumission de pull request (PR). - -1. Installer [Python 3.11+](https://www.python.org/downloads/) -1. Installer [uv](https://docs.astral.sh/uv/) pour la gestion de paquets -1. Installer [Git](https://git-scm.com/downloads) -1. Avoir un agent de codage IA disponible : [Claude Code](https://www.anthropic.com/claude-code), [GitHub Copilot](https://code.visualstudio.com/), ou [Gemini CLI](https://github.com/google-gemini/gemini-cli) - -## Soumettre une pull request - -1. Forker et cloner le dépôt -1. Configurer et installer les dépendances : `uv sync` -1. S'assurer que la CLI fonctionne sur votre machine : `uv run specify --help` -1. Créer une nouvelle branche : `git checkout -b mon-nom-de-branche` -1. Faire votre changement, ajouter des tests, et s'assurer que tout fonctionne encore -1. Tester la fonctionnalité CLI avec un projet exemple si pertinent -1. Pousser vers votre fork et soumettre une pull request -1. Attendre que votre pull request soit examinée et fusionnée. - -Voici quelques choses que vous pouvez faire qui augmenteront la probabilité que votre pull request soit acceptée : - -- Suivre les conventions de codage du projet. -- Écrire des tests pour les nouvelles fonctionnalités. -- Mettre à jour la documentation (`README.md,` `spec-driven.md`) si vos changements affectent les fonctionnalités utilisateur. -- Garder votre changement aussi ciblé que possible. S'il y a plusieurs changements que vous aimeriez faire qui ne dépendent pas les uns des autres, considérez les soumettre comme des pull requests séparées. -- Écrire un [bon message de commit](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html). -- Tester vos changements avec le workflow de Développement Dirigé par les Spécifications pour assurer la compatibilité. - -## Workflow de développement - -Quand vous travaillez sur spec-kit : - -1. Tester les changements avec les commandes CLI `specify` (`/specify`, `/plan`, `/tasks`) dans votre agent de codage de choix -2. Vérifier que les modèles fonctionnent correctement dans le répertoire `templates/` -3. Tester la fonctionnalité des scripts dans le répertoire `scripts/` -4. S'assurer que les fichiers mémoire (`memory/constitution.md`) sont mis à jour si des changements majeurs de processus sont faits - -## Ressources - -- [Méthodologie de Développement Dirigé par les Spécifications](./spec-driven_fr.md) -- [Comment Contribuer à l'Open Source](https://opensource.guide/how-to-contribute/) -- [Utiliser les Pull Requests](https://help.github.com/articles/about-pull-requests/) -- [Aide GitHub](https://help.github.com) \ No newline at end of file diff --git a/README_fr.md b/README_fr.md deleted file mode 100644 index f91f13038f..0000000000 --- a/README_fr.md +++ /dev/null @@ -1,372 +0,0 @@ -
- -

🔧 Kit de Spécifications Matérielles

-

Créer des produits matériels de haute qualité plus rapidement.

-
- -

- Un effort pour permettre aux équipes matérielles de se concentrer sur les scénarios de produits plutôt que sur le travail de conception non différencié avec l'aide du Développement Dirigé par les Spécifications pour les produits et prototypes matériels. -

- -[![Release](https://github.com/github/spec-kit/actions/workflows/release.yml/badge.svg)](https://github.com/github/spec-kit/actions/workflows/release.yml) - ---- - -## Table des Matières - -- [🤔 Qu'est-ce que le Développement Dirigé par les Spécifications ?](#-quest-ce-que-le-développement-dirigé-par-les-spécifications) -- [⚡ Commencer](#-commencer) -- [📚 Philosophie de base](#-philosophie-de-base) -- [🌟 Phases de développement](#-phases-de-développement) -- [🎯 Objectifs expérimentaux](#-objectifs-expérimentaux) -- [🔧 Prérequis](#-prérequis) -- [📖 En savoir plus](#-en-savoir-plus) -- [📋 Processus détaillé](#-processus-détaillé) -- [🔍 Dépannage](#-dépannage) -- [👥 Mainteneurs](#-mainteneurs) -- [💬 Support](#-support) -- [🙏 Remerciements](#-remerciements) -- [📄 Licence](#-licence) - -## 🤔 Qu'est-ce que le Développement Matériel Dirigé par les Spécifications ? - -Le Développement Dirigé par les Spécifications **renverse la situation** du développement matériel traditionnel. Pendant des décennies, les fichiers CAO et les schémas ont été rois — les spécifications n'étaient que des échafaudages que nous construisions et jetions une fois que le "vrai travail" de conception commençait. Le Développement Matériel Dirigé par les Spécifications change cela : **les spécifications deviennent exécutables**, générant directement des conceptions matérielles fonctionnelles, du code embarqué, et de la documentation de fabrication plutôt que de simplement les guider. - -## ⚡ Commencer - -### 1. Installer Specify - -Initialisez votre projet matériel en fonction de l'agent IA que vous utilisez : - -```bash -uvx --from git+https://github.com/LeFrenchPOC/hardware-spec-kit.git specify init -``` - -### 2. Créer la spécification matérielle - -Utilisez la commande `/specify` pour décrire ce que vous voulez construire. Concentrez-vous sur le **quoi** et le **pourquoi**, pas sur les détails d'implémentation. - -```bash -/specify Construire un dispositif intelligent de surveillance de température qui peut suivre les conditions environnementales dans plusieurs pièces. Le dispositif doit afficher la température et l'humidité en temps réel sur un écran local, enregistrer les données au fil du temps, et envoyer des alertes lorsque les conditions dépassent les seuils de sécurité. Le système doit être alimenté par batterie et communiquer sans fil avec un hub central. -``` - -### 3. Créer un plan d'implémentation technique - -Utilisez la commande `/plan` pour fournir votre plateforme matérielle et vos choix de conception. - -```bash -/plan Le dispositif utilise un microcontrôleur ESP32 avec des capteurs DHT22 pour la surveillance température/humidité. Boîtier mécanique conçu dans Fusion360 pour l'impression 3D. Layout PCB dans KiCAD avec gestion de batterie et communication sans fil. Le hub central fonctionne sur Raspberry Pi avec communication LoRa. -``` - -### 4. Décomposer et implémenter - -Utilisez `/tasks` pour créer une liste de tâches exploitables, puis demandez à votre agent d'implémenter la fonctionnalité. - -Pour des instructions détaillées étape par étape, consultez notre [guide complet](./spec-driven_fr.md). - -## 📚 Philosophie de base - -Le Développement Matériel Dirigé par les Spécifications est un processus structuré qui met l'accent sur : - -- **Développement dirigé par l'intention** où les spécifications définissent le "_quoi_" avant le "_comment_" -- **Création de spécifications riches** utilisant des garde-fous et des principes de conception matérielle -- **Coordination multidisciplinaire** entre les équipes de systèmes mécaniques, électriques et embarqués -- **Raffinement en plusieurs étapes** plutôt qu'une génération de conception en une seule fois à partir de prompts -- **Forte dépendance** aux capacités avancées des modèles IA pour l'interprétation des spécifications matérielles - -## 🌟 Phases de développement - -| Phase | Focus | Activités Clés | -|-------|-------|----------------| -| **Développement 0-à-1** ("Nouveau Produit") | Générer à partir de zéro | | -| **Exploration de Conception** | Implémentations parallèles | | -| **Amélioration Itérative** ("Évolution Produit") | Itération produit | | - -## 🎯 Objectifs expérimentaux - -Notre recherche et expérimentation se concentrent sur : - -### Indépendance de plateforme matérielle - -- Créer des produits matériels utilisant diverses plateformes (MCUs, SBCs, FPGA) -- Valider l'hypothèse que le Développement Dirigé par les Spécifications fonctionne à travers les systèmes mécaniques, électriques et embarqués -- Supporter divers processus de fabrication et choix de matériaux - -### Contraintes d'ingénierie - -- Démontrer le développement matériel prêt pour la production -- Incorporer les contraintes de fabrication (tolérances, matériaux, objectifs de coût) -- Supporter les systèmes de conception matérielle et les exigences de conformité (FCC, CE, normes de sécurité) - -### Développement multidisciplinaire - -- Construire des produits intégrant des systèmes mécaniques, électriques et embarqués -- Supporter diverses approches de développement et structures d'équipe -- Permettre la collaboration entre ingénieurs mécaniques, ingénieurs électriques et développeurs firmware - -### Processus itératifs et de prototypage - -- Valider le concept de prototypage rapide et d'itération de conception -- Fournir des workflows robustes pour la validation et les tests de conception -- Étendre les processus pour gérer l'évolution produit et l'optimisation de fabrication - -## 🔧 Prérequis - -- **Linux/macOS** (ou WSL2 sur Windows) -- Agent de codage IA : [Claude Code](https://www.anthropic.com/claude-code), [GitHub Copilot](https://code.visualstudio.com/), ou [Gemini CLI](https://github.com/google-gemini/gemini-cli) -- [uv](https://docs.astral.sh/uv/) pour la gestion de paquets -- [Python 3.11+](https://www.python.org/downloads/) -- [Git](https://git-scm.com/downloads) -- **Outils de Conception Matérielle** : - - [Fusion360](https://www.autodesk.com/products/fusion-360) pour la conception mécanique - - [KiCAD](https://www.kicad.org/) pour la conception électrique et le layout PCB - - Cartes de développement et matériel de prototypage selon les besoins - -## 📖 En savoir plus - -- **[Méthodologie Complète de Développement Matériel Dirigé par les Spécifications](./spec-driven_fr.md)** - Plongée profonde dans le processus complet -- **[Guide Détaillé](#processus-détaillé)** - Guide d'implémentation étape par étape - ---- - -## 📋 Processus détaillé - -
-Cliquer pour développer le guide étape par étape détaillé - -Vous pouvez utiliser la CLI Specify pour amorcer votre projet, ce qui apportera les artefacts requis dans votre environnement. Exécutez : - -```bash -specify init -``` - -Ou initialisez dans le répertoire courant : - -```bash -specify init --here -``` - -![CLI Specify amorçant un nouveau projet dans le terminal](./media/specify_cli.gif) - -Vous serez invité à sélectionner l'agent IA que vous utilisez. Vous pouvez aussi le spécifier directement dans le terminal : - -```bash -specify init --ai claude -specify init --ai gemini -specify init --ai copilot -# Ou dans le répertoire courant : -specify init --here --ai claude -``` - -La CLI vérifiera si vous avez Claude Code ou Gemini CLI installé. Si ce n'est pas le cas, ou si vous préférez obtenir les modèles sans vérifier les bons outils, utilisez `--ignore-agent-tools` avec votre commande : - -```bash -specify init --ai claude --ignore-agent-tools -``` - -### **ÉTAPE 1 :** Amorcer le projet - -Allez dans le dossier du projet et lancez votre agent IA. Dans notre exemple, nous utilisons `claude`. - -![Amorçage de l'environnement Claude Code](./media/bootstrap-claude-code.gif) - -Vous saurez que les choses sont configurées correctement si vous voyez les commandes `/specify`, `/plan`, et `/tasks` disponibles. - -La première étape devrait être la création d'un nouveau squelette de projet. Utilisez la commande `/specify` et puis fournissez les exigences concrètes pour le projet que vous voulez développer. - ->[!IMPORTANT] ->Soyez aussi explicite que possible sur _ce que_ vous essayez de construire et _pourquoi_. **Ne vous concentrez pas sur la pile technologique à ce stade**. - -Un exemple de prompt : - -```text -Développer TempSense, un système de surveillance environnementale sans fil pour les opérations de serre. Il devrait permettre aux agriculteurs de surveiller la température, l'humidité et l'humidité du sol à travers plusieurs zones de serre. Le système devrait afficher des données en temps réel sur un tableau de bord central, envoyer des alertes automatisées lorsque les conditions sortent des plages optimales, et enregistrer des données historiques pour l'analyse. Dans cette phase initiale, appelons-la "Créer TempSense", supportons la surveillance de cinq zones de serre avec trois types de capteurs par zone. Chaque zone devrait avoir des capteurs de température, d'humidité et d'humidité du sol. Le hub central devrait être alimenté par batterie avec capacité de charge solaire. Les nœuds de capteurs individuels devraient être des dispositifs sans fil basse consommation qui peuvent fonctionner pendant des mois sans remplacement de batterie. Le système devrait envoyer des alertes SMS à des numéros de téléphone prédéfinis lorsque les lectures de capteurs dépassent les seuils de sécurité. L'affichage principal devrait montrer les lectures actuelles pour toutes les zones dans un layout en grille, avec des graphiques historiques disponibles pour chaque capteur. Les données devraient être stockées localement et optionnellement téléchargées vers le stockage cloud pour la surveillance à distance. -``` - -Après que ce prompt soit entré, vous devriez voir Claude Code lancer le processus de planification et de rédaction de spécifications. Claude Code déclenchera aussi certains des scripts intégrés pour configurer le dépôt. - -Une fois cette étape terminée, vous devriez avoir une nouvelle branche créée (ex., `001-create-tempsense`), ainsi qu'une nouvelle spécification dans le répertoire `specs/001-create-tempsense`. - -La spécification produite devrait contenir un ensemble d'histoires utilisateur, d'exigences fonctionnelles, et de contraintes matérielles, comme défini dans le modèle. - -À ce stade, le contenu de votre dossier de projet devrait ressembler à ceci : - -```text -├── memory -│ ├── constitution.md -│ └── constitution_update_checklist.md -├── scripts -│ ├── check-task-prerequisites.sh -│ ├── common.sh -│ ├── create-new-feature.sh -│ ├── get-feature-paths.sh -│ ├── setup-plan.sh -│ └── update-claude-md.sh -├── specs -│ └── 001-create-tempsense -│ └── spec.md -└── templates - ├── CLAUDE-template.md - ├── plan-template.md - ├── spec-template.md - └── tasks-template.md -``` - -### **ÉTAPE 2 :** Clarification de spécification fonctionnelle - -Avec la spécification de base créée, vous pouvez aller de l'avant et clarifier toutes les exigences qui n'ont pas été capturées correctement dans la première tentative. Par exemple, vous pourriez utiliser un prompt comme celui-ci dans la même session Claude Code : - -```text -Pour le système de surveillance environnementale, chaque nœud de capteur devrait avoir un boîtier étanche classé pour utilisation extérieure en serre. La durée de vie de la batterie devrait être d'au moins 6 mois sous fonctionnement normal. La portée de communication sans fil devrait couvrir jusqu'à 500 mètres en ligne de vue entre les nœuds de capteurs et le hub central. Ajouter des seuils d'alerte température entre 15-35°C, humidité entre 40-80%, et humidité du sol en-dessous de 30%. -``` - -Vous devriez aussi demander à Claude Code de valider la **Liste de Contrôle d'Examen et d'Acceptation**, en cochant les choses qui sont validées/passent les exigences, et laisser celles qui ne le sont pas non cochées. Le prompt suivant peut être utilisé : - -```text -Lisez la liste de contrôle d'examen et d'acceptation, et cochez chaque élément dans la liste de contrôle si la spécification de fonctionnalité répond aux critères. Laissez-le vide si ce n'est pas le cas. -``` - -Il est important d'utiliser l'interaction avec Claude Code comme une opportunité de clarifier et poser des questions autour de la spécification - **ne traitez pas sa première tentative comme finale**. - -### **ÉTAPE 3 :** Générer un plan - -Vous pouvez maintenant être spécifique sur la plateforme matérielle et autres exigences techniques. Vous pouvez utiliser la commande `/plan` qui est intégrée dans le modèle de projet avec un prompt comme celui-ci : - -```text -Nous allons implémenter ceci en utilisant des microcontrôleurs ESP32-S3 pour les nœuds de capteurs avec communication LoRaWAN. Les boîtiers mécaniques seront conçus dans Fusion360 pour l'impression 3D en PETG. La conception PCB utilisera KiCAD avec gestion de batterie intégrée et conception basse consommation. Le hub central utilise Raspberry Pi 4 avec module de passerelle LoRaWAN. La gestion d'alimentation inclut des batteries lithium 18650 avec contrôleurs de charge solaire. Les interfaces de capteurs incluent des capteurs I2C température/humidité et des sondes d'humidité du sol analogiques. -``` - -La sortie de cette étape inclura un nombre de documents de détails d'implémentation, avec votre arbre de répertoires ressemblant à ceci : - -```text -. -├── CLAUDE.md -├── memory -│ ├── constitution.md -│ └── constitution_update_checklist.md -├── scripts -│ ├── check-task-prerequisites.sh -│ ├── common.sh -│ ├── create-new-feature.sh -│ ├── get-feature-paths.sh -│ ├── setup-plan.sh -│ └── update-claude-md.sh -├── specs -│ └── 001-create-tempsense -│ ├── hardware -│ │ ├── mechanical-spec.md -│ │ ├── electrical-spec.md -│ │ └── embedded-spec.md -│ ├── data-model.md -│ ├── plan.md -│ ├── quickstart.md -│ ├── research.md -│ └── spec.md -└── templates - ├── CLAUDE-template.md - ├── plan-template.md - ├── spec-template.md - └── tasks-template.md -``` - -Vérifiez le document `research.md` pour vous assurer que la bonne plateforme matérielle et les bons outils de conception sont utilisés, basés sur vos instructions. Vous pouvez demander à Claude Code de l'affiner si certains composants se démarquent, ou même lui faire vérifier la compatibilité entre différents composants matériels et contraintes de conception. - -Additionnellement, vous pourriez vouloir demander à Claude Code de rechercher des détails sur la plateforme matérielle choisie si c'est quelque chose qui nécessite des considérations spécifiques (ex., consommation d'énergie, réglementations sans fil, contraintes de fabrication), avec un prompt comme celui-ci : - -```text -Je veux que vous parcouriez le plan d'implémentation et les détails d'implémentation, en cherchant des zones qui pourraient -bénéficier de recherche supplémentaire car les conceptions sans fil basse consommation et la gestion de batterie nécessitent une considération attentive des budgets d'alimentation, de la conception d'antenne, et de la conformité réglementaire. Pour ces zones que vous identifiez qui nécessitent une recherche plus poussée, je veux que vous mettiez à jour le document de recherche avec des détails spécifiques sur les objectifs de consommation d'énergie, les protocoles de communication, et les contraintes de conception mécanique pour ce système TempSense. -``` - -Pendant ce processus, vous pourriez trouver que Claude Code se bloque en recherchant la mauvaise chose - vous pouvez l'aider à aller dans la bonne direction avec un prompt comme celui-ci : - -```text -Je pense que nous devons décomposer ceci en une série d'étapes. D'abord, identifiez une liste de tâches de conception matérielle -que vous auriez besoin de faire pendant l'implémentation dont vous n'êtes pas sûr ou qui bénéficieraient -de recherche supplémentaire. Écrivez une liste de ces tâches. Et puis pour chacune de ces tâches, -je veux que vous lanciez une tâche de recherche séparée pour que le résultat net soit que nous recherchons -toutes ces tâches très spécifiques en parallèle. Ce que j'ai vu que vous faisiez, c'est qu'il semblait que vous -recherchiez les microcontrôleurs ESP32 en général et je ne pense pas que cela va nous aider beaucoup dans ce cas. -C'est beaucoup trop de recherche non ciblée. La recherche doit vous aider à résoudre une question ciblée spécifique -comme les calculs de consommation d'énergie, les exigences de conception d'antenne, ou l'analyse de contrainte mécanique. -``` - ->[!NOTE] ->Claude Code pourrait être trop enthousiaste et ajouter des composants que vous n'avez pas demandés. Demandez-lui de clarifier la justification et la source du changement. - -### **ÉTAPE 4 :** Avoir Claude Code valider le plan - -Avec le plan en place, vous devriez avoir Claude Code le parcourir pour vous assurer qu'il n'y a pas de pièces manquantes. Vous pouvez utiliser un prompt comme celui-ci : - -```text -Maintenant je veux que vous alliez et auditer le plan d'implémentation et les fichiers de détails d'implémentation. -Lisez-le avec un œil sur la détermination s'il y a ou non une séquence de tâches que vous devez -faire qui sont évidentes en lisant ceci. Parce que je ne sais pas s'il y a assez ici. Par exemple, -quand je regarde l'implémentation principale, il serait utile de référencer les endroits appropriés dans les détails d'implémentation où il peut trouver l'information pendant qu'il parcourt chaque étape dans l'implémentation principale ou dans le raffinement. -``` - -Cela aide à affiner le plan d'implémentation et vous aide à éviter les angles morts potentiels que Claude Code a manqués dans son cycle de planification. Une fois le premier passage de raffinement terminé, demandez à Claude Code de passer par la liste de contrôle une fois de plus avant que vous puissiez arriver à l'implémentation. - -Vous pouvez aussi demander à Claude Code (si vous avez la [CLI GitHub](https://docs.github.com/en/github-cli/github-cli) installée) d'aller de l'avant et créer une pull request de votre branche actuelle vers `main` avec une description détaillée, pour vous assurer que l'effort est correctement suivi. - ->[!NOTE] ->Avant que vous ayez l'agent l'implémenter, il vaut aussi la peine de demander à Claude Code de vérifier les détails pour voir s'il y a des pièces sur-ingénieurées (rappelez-vous - il peut être trop enthousiaste). Si des composants ou décisions sur-ingénieurés existent, vous pouvez demander à Claude Code de les résoudre. Assurez-vous que Claude Code suit la [constitution](base/memory/constitution.md) comme la pièce fondamentale à laquelle il doit adhérer lors de l'établissement du plan. - -### ÉTAPE 5 : Implémentation - -Une fois prêt, instruisez Claude Code d'implémenter votre conception matérielle (chemin d'exemple inclus) : - -```text -implémenter specs/001-create-tempsense/plan.md -``` - -Claude Code va se mettre en action et commencera à créer l'implémentation incluant : -- Fichiers de conception mécanique Fusion360 pour les boîtiers -- Fichiers de schéma et layout PCB KiCAD -- Code firmware embarqué pour les microcontrôleurs ESP32 -- Scripts de configuration et de déploiement - ->[!IMPORTANT] ->Claude Code exécutera des commandes CLI locales pour l'automatisation des outils de conception et la compilation firmware - assurez-vous d'avoir les outils nécessaires installés sur votre machine. - -Une fois l'étape d'implémentation terminée, demandez à Claude Code d'essayer de valider la conception et résoudre tous les problèmes émergents. Cela inclut vérifier les ajustements mécaniques, la compatibilité électrique, et la compilation firmware. S'il y a des erreurs de vérification de règles de conception (DRC) dans KiCAD ou des conflits d'assemblage dans Fusion360, copiez et collez les messages d'erreur dans Claude Code et demandez-lui de tenter de les résoudre. - -
- ---- - -## 🔍 Dépannage - -### Git Credential Manager sur Linux - -Si vous avez des problèmes avec l'authentification Git sur Linux, vous pouvez installer Git Credential Manager : - -```bash -#!/usr/bin/env bash -set -e -echo "Téléchargement de Git Credential Manager v2.6.1..." -wget https://github.com/git-ecosystem/git-credential-manager/releases/download/v2.6.1/gcm-linux_amd64.2.6.1.deb -echo "Installation de Git Credential Manager..." -sudo dpkg -i gcm-linux_amd64.2.6.1.deb -echo "Configuration de Git pour utiliser GCM..." -git config --global credential.helper manager -echo "Nettoyage..." -rm gcm-linux_amd64.2.6.1.deb -``` - -## 👥 Mainteneurs - -- Den Delimarsky ([@localden](https://github.com/localden)) -- John Lam ([@jflam](https://github.com/jflam)) - -## 💬 Support - -Pour le support, veuillez ouvrir un [GitHub issue](https://github.com/github/spec-kit/issues/new). Nous accueillons les rapports de bogues, les demandes de fonctionnalités, et les questions sur l'utilisation du Développement Dirigé par les Spécifications. - -## 🙏 Remerciements - -Ce projet est fortement influencé par et basé sur le travail et la recherche de [John Lam](https://github.com/jflam). - -## 📄 Licence - -Ce projet est sous licence selon les termes de la licence open source MIT. Veuillez vous référer au fichier [LICENSE](./LICENSE) pour les termes complets. \ No newline at end of file diff --git a/SECURITY_fr.md b/SECURITY_fr.md deleted file mode 100644 index e383833de3..0000000000 --- a/SECURITY_fr.md +++ /dev/null @@ -1,31 +0,0 @@ -Merci d'aider à rendre GitHub sûr pour tout le monde. - -# Sécurité - -GitHub prend la sécurité de nos produits logiciels et services au sérieux, y compris tous les dépôts de code open source gérés à travers nos organisations GitHub, comme [GitHub](https://github.com/GitHub). - -Même si [les dépôts open source sont en dehors de la portée de notre programme de prime aux bogues](https://bounty.github.com/index.html#scope) et ne sont donc pas éligibles aux récompenses de prime, nous nous assurerons que votre découverte soit transmise aux mainteneurs appropriés pour remédiation. - -## Signaler les Problèmes de Sécurité - -Si vous croyez avoir trouvé une vulnérabilité de sécurité dans tout dépôt appartenant à GitHub, veuillez nous le signaler par divulgation coordonnée. - -**Veuillez ne pas signaler les vulnérabilités de sécurité par les issues publiques GitHub, discussions, ou pull requests.** - -Au lieu de cela, veuillez envoyer un e-mail à opensource-security[@]github.com. - -Veuillez inclure autant d'informations listées ci-dessous que vous pouvez pour nous aider à mieux comprendre et résoudre le problème : - - * Le type de problème (ex., débordement de tampon, injection SQL, ou script intersites) - * Chemins complets des fichier(s) source liés à la manifestation du problème - * L'emplacement du code source affecté (tag/branche/commit ou URL directe) - * Toute configuration spéciale requise pour reproduire le problème - * Instructions étape par étape pour reproduire le problème - * Code de preuve de concept ou d'exploit (si possible) - * Impact du problème, y compris comment un attaquant pourrait exploiter le problème - -Cette information nous aidera à trier votre rapport plus rapidement. - -## Politique - -Voir [la Politique de Refuge Sûr de GitHub](https://docs.github.com/en/site-policy/security-policies/github-bug-bounty-program-legal-safe-harbor#1-safe-harbor-terms) \ No newline at end of file diff --git a/SUPPORT_fr.md b/SUPPORT_fr.md deleted file mode 100644 index 671f8bae17..0000000000 --- a/SUPPORT_fr.md +++ /dev/null @@ -1,19 +0,0 @@ -# Support - -## Comment signaler des problèmes et obtenir de l'aide - -Ce projet utilise les issues GitHub pour suivre les bogues et les demandes de fonctionnalités. Veuillez rechercher les issues existantes avant de signaler de nouvelles issues pour éviter les doublons. Pour de nouvelles issues, signalez votre bogue ou demande de fonctionnalité comme une nouvelle issue. - -Pour l'aide ou les questions sur l'utilisation de ce projet, veuillez : - -- Ouvrir une [issue GitHub](https://github.com/github/spec-kit/issues/new) pour les rapports de bogues, demandes de fonctionnalités, ou questions sur la méthodologie de Développement Dirigé par les Spécifications -- Vérifier le [guide complet](./spec-driven_fr.md) pour la documentation détaillée sur le processus de Développement Dirigé par les Spécifications -- Examiner le [README](./README_fr.md) pour les instructions de démarrage et conseils de dépannage - -## Statut du Projet - -**Spec Kit** est en développement actif et maintenu par le personnel GitHub **ET LA COMMUNAUTÉ**. Nous ferons de notre mieux pour répondre au support, aux demandes de fonctionnalités, et aux questions de la communauté de manière opportune. - -## Politique de Support GitHub - -Le support pour ce projet est limité aux ressources listées ci-dessus. \ No newline at end of file diff --git a/docs/README_fr.md b/docs/README_fr.md deleted file mode 100644 index f359824f99..0000000000 --- a/docs/README_fr.md +++ /dev/null @@ -1,33 +0,0 @@ -# Documentation - -Ce dossier contient les fichiers source de documentation pour Spec Kit, construit en utilisant [DocFX](https://dotnet.github.io/docfx/). - -## Construction Locale - -Pour construire la documentation localement : - -1. Installer DocFX : - ```bash - dotnet tool install -g docfx - ``` - -2. Construire la documentation : - ```bash - cd docs - docfx docfx.json --serve - ``` - -3. Ouvrir votre navigateur à `http://localhost:8080` pour voir la documentation. - -## Structure - -- `docfx.json` - Fichier de configuration DocFX -- `index.md` - Page d'accueil principale de la documentation -- `toc.yml` - Configuration de la table des matières -- `installation.md` - Guide d'installation -- `quickstart.md` - Guide de démarrage rapide -- `_site/` - Sortie de documentation générée (ignorée par git) - -## Déploiement - -La documentation est automatiquement construite et déployée sur GitHub Pages quand des changements sont poussés vers la branche `main`. Le workflow est défini dans `.github/workflows/docs.yml`. \ No newline at end of file diff --git a/docs/index_fr.md b/docs/index_fr.md deleted file mode 100644 index 97ebad5faf..0000000000 --- a/docs/index_fr.md +++ /dev/null @@ -1,61 +0,0 @@ -# Kit de Spécifications - -*Construire des logiciels de haute qualité plus rapidement.* - -**Un effort pour permettre aux organisations de se concentrer sur les scénarios de produits plutôt que d'écrire du code non différencié avec l'aide du Développement Dirigé par les Spécifications.** - -## Qu'est-ce que le Développement Dirigé par les Spécifications ? - -Le Développement Dirigé par les Spécifications **renverse la situation** du développement logiciel traditionnel. Pendant des décennies, le code a été roi — les spécifications n'étaient que des échafaudages que nous construisions et jetions une fois que le "vrai travail" de codage commençait. Le Développement Dirigé par les Spécifications change cela : **les spécifications deviennent exécutables**, générant directement des implémentations fonctionnelles plutôt que de simplement les guider. - -## Commencer - -- [Guide d'Installation](installation_fr.md) -- [Guide de Démarrage Rapide](quickstart_fr.md) - -## Philosophie de Base - -Le Développement Dirigé par les Spécifications est un processus structuré qui met l'accent sur : - -- **Développement dirigé par l'intention** où les spécifications définissent le "_quoi_" avant le "_comment_" -- **Création de spécifications riches** utilisant des garde-fous et des principes organisationnels -- **Raffinement en plusieurs étapes** plutôt qu'une génération de code en une seule fois à partir de prompts -- **Forte dépendance** aux capacités avancées des modèles IA pour l'interprétation des spécifications - -## Phases de Développement - -| Phase | Focus | Activités Clés | -|-------|-------|----------------| -| **Développement 0-à-1** ("Greenfield") | Générer à partir de zéro | | -| **Exploration Créative** | Implémentations parallèles | | -| **Amélioration Itérative** ("Brownfield") | Modernisation brownfield | | - -## Objectifs Expérimentaux - -Notre recherche et expérimentation se concentrent sur : - -### Indépendance Technologique -- Créer des applications utilisant diverses piles technologiques -- Valider l'hypothèse que le Développement Dirigé par les Spécifications est un processus non lié à des technologies, langages de programmation, ou frameworks spécifiques - -### Contraintes d'Entreprise -- Démontrer le développement d'applications mission-critiques -- Incorporer les contraintes organisationnelles (fournisseurs cloud, piles technologiques, pratiques d'ingénierie) -- Supporter les systèmes de conception d'entreprise et les exigences de conformité - -### Développement Centré Utilisateur -- Construire des applications pour différentes cohortes d'utilisateurs et préférences -- Supporter diverses approches de développement (du vibe-coding au développement IA-natif) - -### Processus Créatifs et Itératifs -- Valider le concept d'exploration d'implémentation parallèle -- Fournir des workflows robustes de développement de fonctionnalités itératifs -- Étendre les processus pour gérer les mises à niveau et tâches de modernisation - -## Contribuer - -Veuillez consulter notre [Guide de Contribution](CONTRIBUTING_fr.md) pour des informations sur comment contribuer à ce projet. - -## Support - -Pour le support, veuillez vérifier notre [Guide de Support](SUPPORT_fr.md) ou ouvrir une issue sur GitHub. \ No newline at end of file diff --git a/docs/installation_fr.md b/docs/installation_fr.md deleted file mode 100644 index 8e917465fd..0000000000 --- a/docs/installation_fr.md +++ /dev/null @@ -1,69 +0,0 @@ -# Guide d'Installation - -## Prérequis - -- **Linux/macOS** (ou WSL2 sur Windows) -- Agent de codage IA : [Claude Code](https://www.anthropic.com/claude-code), [GitHub Copilot](https://code.visualstudio.com/), ou [Gemini CLI](https://github.com/google-gemini/gemini-cli) -- [uv](https://docs.astral.sh/uv/) pour la gestion de paquets -- [Python 3.11+](https://www.python.org/downloads/) -- [Git](https://git-scm.com/downloads) - -## Installation - -### Initialiser un Nouveau Projet - -La façon la plus facile de commencer est d'initialiser un nouveau projet : - -```bash -uvx --from git+https://github.com/github/spec-kit.git specify init -``` - -Ou initialiser dans le répertoire courant : - -```bash -uvx --from git+https://github.com/github/spec-kit.git specify init --here -``` - -### Spécifier l'Agent IA - -Vous pouvez spécifier de manière proactive votre agent IA pendant l'initialisation : - -```bash -uvx --from git+https://github.com/github/spec-kit.git specify init --ai claude -uvx --from git+https://github.com/github/spec-kit.git specify init --ai gemini -uvx --from git+https://github.com/github/spec-kit.git specify init --ai copilot -``` - -### Ignorer la Vérification des Outils d'Agent - -Si vous préférez obtenir les modèles sans vérifier les bons outils : - -```bash -uvx --from git+https://github.com/github/spec-kit.git specify init --ai claude --ignore-agent-tools -``` - -## Vérification - -Après l'initialisation, vous devriez voir les commandes suivantes disponibles dans votre agent IA : -- `/specify` - Créer des spécifications -- `/plan` - Générer des plans d'implémentation -- `/tasks` - Décomposer en tâches exploitables - -## Dépannage - -### Git Credential Manager sur Linux - -Si vous avez des problèmes avec l'authentification Git sur Linux, vous pouvez installer Git Credential Manager : - -```bash -#!/usr/bin/env bash -set -e -echo "Téléchargement de Git Credential Manager v2.6.1..." -wget https://github.com/git-ecosystem/git-credential-manager/releases/download/v2.6.1/gcm-linux_amd64.2.6.1.deb -echo "Installation de Git Credential Manager..." -sudo dpkg -i gcm-linux_amd64.2.6.1.deb -echo "Configuration de Git pour utiliser GCM..." -git config --global credential.helper manager -echo "Nettoyage..." -rm gcm-linux_amd64.2.6.1.deb -``` \ No newline at end of file diff --git a/docs/quickstart_fr.md b/docs/quickstart_fr.md deleted file mode 100644 index 2b0956bde3..0000000000 --- a/docs/quickstart_fr.md +++ /dev/null @@ -1,114 +0,0 @@ -# Guide de Démarrage Rapide - -Ce guide vous aidera à commencer avec le Développement Dirigé par les Spécifications en utilisant Spec Kit. - -## Le Processus en 4 Étapes - -### 1. Installer Specify - -Initialisez votre projet en fonction de l'agent de codage que vous utilisez : - -```bash -uvx --from git+https://github.com/github/spec-kit.git specify init -``` - -### 2. Créer la Spécification - -Utilisez la commande `/specify` pour décrire ce que vous voulez construire. Concentrez-vous sur le **quoi** et le **pourquoi**, pas sur la pile technologique. - -```bash -/specify Construire une application qui peut m'aider à organiser mes photos dans des albums photo séparés. Les albums sont groupés par date et peuvent être réorganisés en glissant-déposant sur la page principale. Les albums ne sont jamais dans d'autres albums imbriqués. Dans chaque album, les photos sont prévisualisées dans une interface de type tuile. -``` - -### 3. Créer un Plan d'Implémentation Technique - -Utilisez la commande `/plan` pour fournir votre pile technologique et choix d'architecture. - -```bash -/plan L'application utilise Vite avec un nombre minimal de bibliothèques. Utiliser HTML, CSS, et JavaScript vanille autant que possible. Les images ne sont téléchargées nulle part et les métadonnées sont stockées dans une base de données SQLite locale. -``` - -### 4. Décomposer et Implémenter - -Utilisez `/tasks` pour créer une liste de tâches exploitables, puis demandez à votre agent d'implémenter la fonctionnalité. - -## Exemple Détaillé : Construire Taskify - -Voici un exemple complet de construction d'une plateforme de productivité d'équipe : - -### Étape 1 : Définir les Exigences avec `/specify` - -```text -Développer Taskify, une plateforme de productivité d'équipe. Elle devrait permettre aux utilisateurs de créer des projets, ajouter des membres d'équipe, -assigner des tâches, commenter et déplacer des tâches entre des tableaux en style Kanban. Dans cette phase initiale pour cette fonctionnalité, -appelons-la "Créer Taskify," ayons plusieurs utilisateurs mais les utilisateurs seront déclarés à l'avance, prédéfinis. -Je veux cinq utilisateurs dans deux catégories différentes, un chef de produit et quatre ingénieurs. Créons trois -projets d'exemple différents. Ayons les colonnes Kanban standard pour le statut de chaque tâche, comme "À Faire," -"En Cours," "En Révision," et "Terminé." Il n'y aura pas de connexion pour cette application car c'est juste la toute -première chose de test pour s'assurer que nos fonctionnalités de base sont configurées. Pour chaque tâche dans l'UI pour une carte de tâche, -vous devriez pouvoir changer le statut actuel de la tâche entre les différentes colonnes dans le tableau de travail Kanban. -Vous devriez pouvoir laisser un nombre illimité de commentaires pour une carte particulière. Vous devriez pouvoir, à partir de cette carte de tâche, -assigner un des utilisateurs valides. Quand vous lancez d'abord Taskify, ça va vous donner une liste des cinq utilisateurs parmi lesquels choisir. -Il n'y aura pas de mot de passe requis. Quand vous cliquez sur un utilisateur, vous allez dans la vue principale, qui affiche la liste des -projets. Quand vous cliquez sur un projet, vous ouvrez le tableau Kanban pour ce projet. Vous allez voir les colonnes. -Vous pourrez glisser-déposer les cartes d'avant en arrière entre différentes colonnes. Vous verrez toutes les cartes qui sont -assignées à vous, l'utilisateur actuellement connecté, dans une couleur différente de toutes les autres, pour que vous puissiez rapidement -voir les vôtres. Vous pouvez éditer tous les commentaires que vous faites, mais vous ne pouvez pas éditer les commentaires que d'autres personnes ont faits. Vous pouvez -supprimer tous les commentaires que vous avez faits, mais vous ne pouvez pas supprimer les commentaires que quelqu'un d'autre a faits. -``` - -### Étape 2 : Affiner la Spécification - -Après que la spécification initiale soit créée, clarifiez toutes les exigences manquantes : - -```text -Pour chaque projet d'exemple ou projet que vous créez, il devrait y avoir un nombre variable de tâches entre 5 et 15 -tâches pour chacun distribuées aléatoirement dans différents états d'achèvement. Assurez-vous qu'il y a au moins -une tâche dans chaque étape d'achèvement. -``` - -Validez aussi la liste de contrôle de spécification : - -```text -Lisez la liste de contrôle d'examen et d'acceptation, et cochez chaque élément dans la liste de contrôle si la spécification de fonctionnalité répond aux critères. Laissez-le vide si ce n'est pas le cas. -``` - -### Étape 3 : Générer le Plan Technique avec `/plan` - -Soyez spécifique sur votre pile technologique et exigences techniques : - -```text -Nous allons générer ceci en utilisant .NET Aspire, en utilisant Postgres comme base de données. Le frontend devrait utiliser -Blazor server avec des tableaux de tâches glisser-déposer, des mises à jour en temps réel. Il devrait y avoir une API REST créée avec une API de projets, -une API de tâches, et une API de notifications. -``` - -### Étape 4 : Valider et Implémenter - -Demandez à votre agent IA d'auditer le plan d'implémentation : - -```text -Maintenant je veux que vous alliez et auditiez le plan d'implémentation et les fichiers de détails d'implémentation. -Lisez-le avec un œil sur la détermination s'il y a ou non une séquence de tâches que vous devez -faire qui sont évidentes en lisant ceci. Parce que je ne sais pas s'il y a assez ici. -``` - -Finalement, implémentez la solution : - -```text -implémenter specs/002-create-taskify/plan.md -``` - -## Principes Clés - -- **Être explicite** sur ce que vous construisez et pourquoi -- **Ne pas se concentrer sur la pile technologique** pendant la phase de spécification -- **Itérer et affiner** vos spécifications avant l'implémentation -- **Valider** le plan avant que le codage commence -- **Laisser l'agent IA gérer** les détails d'implémentation - -## Prochaines Étapes - -- Lire la méthodologie complète pour des conseils approfondis -- Consulter plus d'exemples dans le dépôt -- Explorer le code source sur GitHub \ No newline at end of file diff --git a/memory/constitution_fr.md b/memory/constitution_fr.md deleted file mode 100644 index 4500def3c7..0000000000 --- a/memory/constitution_fr.md +++ /dev/null @@ -1,82 +0,0 @@ -# Constitution du Kit de Spécifications Matérielles - -## Principes Fondamentaux - -### I. Principe Conception-d'Abord -Chaque fonctionnalité matérielle commence comme une spécification de conception complète avec composants mécaniques, électriques et embarqués clairement définis. Aucune implémentation ne commence sans : -- Contraintes de conception mécanique et exigences de boîtier -- Schéma électrique et budgets d'alimentation -- Architecture firmware embarquée et protocoles de communication -- Interfaces claires entre sous-systèmes - -### II. Interface Multi-Disciplinaire -Chaque système matériel expose la fonctionnalité à travers des interfaces bien définies : -- Mécanique : Points de montage standard, placements de connecteurs, et procédures d'assemblage -- Électrique : Brochages documentés, exigences d'alimentation, et spécifications de signal -- Embarqué : Points de terminaison API, protocoles de communication, et interfaces de configuration -- Supporter à la fois des formats de documentation lisibles par l'humain et lisibles par machine (JSON, YAML) - -### III. Conception Test-d'Abord (NON-NÉGOCIABLE) -Toute implémentation matérielle DOIT suivre des principes stricts de Conception-pour-Test : -1. Les procédures de test sont définies pendant la phase de spécification -2. Les procédures de test sont validées et approuvées avant l'implémentation -3. Les tests de validation de conception sont confirmés d'exister avant le prototypage -- Mécanique : Tests de contrainte, validation d'ajustement/dégagement, vérification des propriétés des matériaux -- Électrique : Vérifications de règles de conception, intégrité du signal, validation de consommation d'énergie -- Embarqué : Tests unitaires, tests d'intégration, tests de communication du monde réel - -### IV. Validation Intégration-d'Abord -Les systèmes matériels DOIVENT être testés comme systèmes intégrés : -- Préférer les interfaces capteur/actionneur réelles aux entrées simulées -- Utiliser les protocoles de communication actuels et connexions physiques -- Tests environnementaux sous conditions d'opération réalistes -- Tests de contrat obligatoires entre interfaces mécaniques/électriques/embarquées - -### V. Modularité de Plateforme -Les conceptions matérielles DOIVENT supporter l'implémentation modulaire : -- Mécanique : Interfaces de montage standardisées et systèmes de boîtier -- Électrique : Conceptions PCB modulaires avec connecteurs standard -- Embarqué : Couches d'abstraction matérielle et communication standardisée -- Séparation claire entre composants spécifiques à la plateforme et spécifiques à l'application - -## Contraintes Spécifiques au Matériel - -### Standards d'Outils de Conception -- **Conception Mécanique** : Fusion360 comme outil CAO principal avec organisation de fichiers standardisée -- **Conception Électrique** : KiCAD pour la capture schématique et le layout PCB avec conformité aux règles de conception -- **Développement Embarqué** : IDEs spécifiques à la plateforme (Arduino IDE, PlatformIO, ESP-IDF) avec contrôle de version -- **Documentation** : Conventions de nommage cohérentes et structures de fichiers à travers tous les outils - -### Préparation de Fabrication -- Toutes les conceptions mécaniques DOIVENT inclure les contraintes de fabrication (tolérances, matériaux, processus) -- Les conceptions électriques DOIVENT passer les vérifications de règles de conception pour le processus de fabrication choisi -- Nomenclature (BOM) avec informations d'approvisionnement et objectifs de coût -- Procédures d'assemblage documentées avec exigences d'outillage - -### Contraintes d'Alimentation et Environnementales -- Budgets de consommation d'énergie définis pour tous les sous-systèmes électriques -- Plages de température et d'humidité d'opération spécifiées -- Indices de protection d'entrée (IP) définis pour les boîtiers mécaniques -- Exigences de conformité réglementaire (FCC, CE, normes de sécurité) identifiées - -## Workflow de Développement - -### Portes de Phase de Conception -Le développement matériel procède à travers des portes de phase obligatoires : -1. **Porte de Spécification** : Exigences complètes et validées -2. **Porte de Conception** : Toutes les conceptions de sous-systèmes complètes et interfaces définies -3. **Porte de Validation** : Les tests de vérification de conception passent -4. **Porte d'Implémentation** : Prototypes construits et tests fonctionnels passent -5. **Porte de Fabrication** : Examen de conception pour fabrication complet - -### Contrôle de Version et Documentation -- Tous les fichiers de conception maintenus sous contrôle de version (Git LFS pour fichiers binaires) -- Changements de conception suivis avec justification et analyse d'impact -- Documentation de fabrication générée automatiquement à partir des fichiers de conception -- Procédures de test et résultats maintenus aux côtés des fichiers de conception - -## Gouvernance - -Cette constitution supplante toutes les autres pratiques de développement matériel. Toutes les revues de conception et implémentations doivent vérifier la conformité avec ces principes. La complexité et les déviations doivent être explicitement justifiées et documentées. - -**Version** : 1.0.0 | **Ratifiée** : 2025-01-23 | **Dernière Modification** : 2025-01-23 \ No newline at end of file diff --git a/memory/constitution_update_checklist_fr.md b/memory/constitution_update_checklist_fr.md deleted file mode 100644 index d4ed340de6..0000000000 --- a/memory/constitution_update_checklist_fr.md +++ /dev/null @@ -1,85 +0,0 @@ -# Liste de Contrôle de Mise à Jour de Constitution - -Lors de la modification de la constitution (`/memory/constitution.md`), assurez-vous que tous les documents dépendants sont mis à jour pour maintenir la cohérence. - -## Modèles à Mettre à Jour - -### Lors de l'ajout/modification de TOUT article : -- [ ] `/templates/plan-template.md` - Mettre à jour la section Vérification Constitution -- [ ] `/templates/spec-template.md` - Mettre à jour si exigences/portée affectées -- [ ] `/templates/tasks-template.md` - Mettre à jour si nouveaux types de tâches nécessaires -- [ ] `/.claude/commands/plan.md` - Mettre à jour si processus de planification change -- [ ] `/.claude/commands/tasks.md` - Mettre à jour si génération de tâches affectée -- [ ] `/CLAUDE.md` - Mettre à jour les directives de développement runtime - -### Mises à jour spécifiques aux articles : - -#### Article I (Bibliothèque-d'Abord) : -- [ ] S'assurer que les modèles mettent l'accent sur la création de bibliothèque -- [ ] Mettre à jour les exemples de commandes CLI -- [ ] Ajouter les exigences de documentation llms.txt - -#### Article II (Interface CLI) : -- [ ] Mettre à jour les exigences de drapeaux CLI dans les modèles -- [ ] Ajouter des rappels de protocole I/O texte - -#### Article III (Test-d'Abord) : -- [ ] Mettre à jour l'ordre des tests dans tous les modèles -- [ ] Mettre l'accent sur les exigences TDD -- [ ] Ajouter des portes d'approbation de test - -#### Article IV (Tests d'Intégration) : -- [ ] Lister les déclencheurs de tests d'intégration -- [ ] Mettre à jour les priorités de types de test -- [ ] Ajouter les exigences de dépendances réelles - -#### Article V (Observabilité) : -- [ ] Ajouter les exigences de journalisation aux modèles -- [ ] Inclure le streaming de logs multi-niveaux -- [ ] Mettre à jour les sections de surveillance de performance - -#### Article VI (Versionnage) : -- [ ] Ajouter des rappels d'incrémentation de version -- [ ] Inclure les procédures de changements cassants -- [ ] Mettre à jour les exigences de migration - -#### Article VII (Simplicité) : -- [ ] Mettre à jour les limites de compte de projets -- [ ] Ajouter des exemples de prohibition de modèles -- [ ] Inclure des rappels YAGNI - -## Étapes de Validation - -1. **Avant de commettre les changements de constitution :** - - [ ] Tous les modèles référencent les nouvelles exigences - - [ ] Exemples mis à jour pour correspondre aux nouvelles règles - - [ ] Aucune contradiction entre documents - -2. **Après mise à jour des modèles :** - - [ ] Exécuter un exemple de plan d'implémentation - - [ ] Vérifier que toutes les exigences de constitution sont adressées - - [ ] Vérifier que les modèles sont autonomes (lisibles sans constitution) - -3. **Suivi de version :** - - [ ] Mettre à jour le numéro de version de constitution - - [ ] Noter la version dans les pieds de page de modèles - - [ ] Ajouter un amendement à l'historique de constitution - -## Oublis Courants - -Surveillez ces mises à jour souvent oubliées : -- Documentation de commandes (`/commands/*.md`) -- Éléments de liste de contrôle dans les modèles -- Code/commandes d'exemple -- Variations spécifiques au domaine (web vs mobile vs CLI) -- Références croisées entre documents - -## Statut de Synchronisation des Modèles - -Dernière vérification de synchronisation : 2025-07-16 -- Version de constitution : 2.1.1 -- Modèles alignés : ❌ (détails de versionnage et observabilité manquants) - ---- - -*Cette liste de contrôle assure que les principes de la constitution sont appliqués de manière cohérente à travers toute la documentation du projet.* \ No newline at end of file diff --git a/spec-driven_fr.md b/spec-driven_fr.md deleted file mode 100644 index 348b0798cf..0000000000 --- a/spec-driven_fr.md +++ /dev/null @@ -1,375 +0,0 @@ -# Développement Matériel Dirigé par les Spécifications (SDD) - -## L'Inversion du Pouvoir - -Pendant des décennies, les fichiers CAO et les schémas de circuits ont été rois. Les spécifications servaient les fichiers de conception—elles étaient l'échafaudage que nous construisions puis jetions une fois que le "vrai travail" de conception commençait. Nous écrivions des PRD pour guider le développement, créions des documents d'exigences pour informer l'implémentation, dessinions des diagrammes système pour visualiser l'architecture. Mais ceux-ci étaient toujours subordonnés aux fichiers de conception eux-mêmes. Les modèles CAO étaient vérité. Les layouts PCB étaient vérité. Le code firmware était vérité. Tout le reste était, au mieux, de bonnes intentions. Les fichiers de conception étaient la source de vérité, car ils progressaient, et les spécifications suivaient rarement le rythme. Comme l'actif (fichiers de conception) et l'implémentation sont un, il n'est pas facile d'avoir une implémentation parallèle sans essayer de reconstruire à partir des fichiers de conception. - -Le Développement Matériel Dirigé par les Spécifications (SDD) inverse cette structure de pouvoir. Les spécifications ne servent pas les fichiers de conception—les fichiers de conception servent les spécifications. Le PRD (Document d'Exigences Produit-Spécification) n'est pas un guide pour l'implémentation ; c'est la source qui génère l'implémentation. Les plans techniques ne sont pas des documents qui informent la conception ; ils sont des définitions précises qui produisent des conceptions mécaniques, des schémas électriques, des layouts PCB, et du firmware embarqué. Ce n'est pas une amélioration incrémentale de la façon dont nous construisons le matériel. C'est une reconceptualisation fondamentale de ce qui pilote le développement matériel. - -L'écart entre spécification et implémentation a tourmenté le développement matériel depuis sa création. Nous avons essayé de le combler avec une meilleure documentation, des exigences plus détaillées, des revues de conception plus strictes. Ces approches échouent parce qu'elles acceptent l'écart comme inévitable. Elles essaient de le réduire mais ne l'éliminent jamais. SDD élimine l'écart en rendant les spécifications et leurs plans d'implémentation concrets exécutables. Quand les spécifications et les plans d'implémentation génèrent des conceptions matérielles, il n'y a pas d'écart—seulement transformation. - -Cette transformation est maintenant possible parce que l'IA peut comprendre et implémenter des spécifications matérielles complexes, et créer des plans d'implémentation détaillés couvrant les systèmes mécaniques, électriques et embarqués. Mais la génération IA brute sans structure produit le chaos. SDD fournit cette structure à travers des spécifications et des plans d'implémentation subséquents qui sont précis, complets, et non ambigus suffisamment pour générer des systèmes matériels fonctionnels. La spécification devient l'artefact principal. Les fichiers de conception deviennent leur expression comme une implémentation du plan d'implémentation pour des processus de fabrication et des choix de composants particuliers. - -Dans ce nouveau monde, maintenir le matériel signifie faire évoluer les spécifications. L'intention de l'équipe de développement est exprimée en langage naturel ("**développement dirigé par l'intention**"), actifs de conception, principes de base et autres directives. La **lingua franca** du développement se déplace vers un niveau plus élevé, et les fichiers de conception sont l'approche de dernière mile. - -Déboguer signifie corriger les spécifications et leurs plans d'implémentation qui génèrent des conceptions incorrectes. Refactoriser signifie restructurer pour la clarté et la fabricabilité. L'ensemble du workflow de développement se réorganise autour des spécifications comme source centrale de vérité, avec des plans d'implémentation et des fichiers de conception comme sortie régénérée en continu. Mettre à jour les produits avec de nouvelles fonctionnalités ou créer une nouvelle implémentation parallèle parce que nous sommes des êtres créatifs, signifie revisiter la spécification et créer de nouveaux plans d'implémentation. Ce processus est donc un 0 -> 1, (1', ..), 2, 3, N. - -L'équipe de développement se concentre sur leur créativité, expérimentation, leur pensée critique. - -## Le Workflow SDD en Pratique - -Le workflow commence avec une idée—souvent vague et incomplète. À travers un dialogue itératif avec l'IA, cette idée devient un PRD matériel compréhensif. L'IA pose des questions de clarification, identifie les contraintes de conception, et aide à définir des critères d'acceptation précis couvrant les exigences mécaniques, électriques et embarquées. Ce qui pourrait prendre des semaines de réunions et de documentation dans le développement matériel traditionnel se fait en heures de travail de spécification ciblé. Cela transforme le cycle de vie de développement matériel traditionnel—les exigences et la conception deviennent des activités continues plutôt que des phases discrètes. Cela soutient un **processus d'équipe**, où les spécifications examinées par l'équipe sont exprimées et versionnées, créées dans des branches, et fusionnées. - -Quand un chef de produit met à jour les critères d'acceptation, les plans d'implémentation signalent automatiquement les conceptions mécaniques, schémas électriques, et architectures firmware affectés. Quand un ingénieur découvre un meilleur composant ou processus de fabrication, le PRD se met à jour pour refléter les nouvelles possibilités. - -Tout au long de ce processus de spécification, les agents de recherche rassemblent un contexte critique. Ils enquêtent sur la disponibilité des composants, les contraintes de fabrication, les exigences réglementaires, et les implications de coût. Les contraintes organisationnelles sont découvertes et appliquées automatiquement—les partenaires de fabrication de votre entreprise, les standards d'approvisionnement en composants, les exigences de certification, et les directives de conception pour fabrication (DFM) s'intègrent sans couture dans chaque spécification. - -Du PRD, l'IA génère des plans d'implémentation qui mappent les exigences aux décisions techniques à travers les domaines mécaniques, électriques et embarqués. Chaque choix de composant a une justification documentée. Chaque décision de conception remonte à des exigences spécifiques. Tout au long de ce processus, la validation de cohérence améliore continuellement la qualité. L'IA analyse les spécifications pour l'ambiguïté, les contradictions, et les lacunes—pas comme une porte unique, mais comme un raffinement continu. - -La génération de conception commence dès que les spécifications et leurs plans d'implémentation sont suffisamment stables, mais ils n'ont pas à être "complets." Les premières générations peuvent être exploratoires—testant si la spécification a du sens en pratique. Les concepts système deviennent des assemblages mécaniques. Les interactions utilisateur deviennent des interfaces électriques. Les exigences de performance deviennent des algorithmes embarqués. Cela fusionne développement et test à travers la spécification—les scénarios de test ne sont pas écrits après la conception, ils font partie de la spécification qui génère à la fois l'implémentation et les procédures de validation. - -La boucle de rétroaction s'étend au-delà du développement initial. La rétroaction de fabrication, les données de performance sur le terrain, et l'analyse des défaillances ne déclenchent pas seulement des révisions de conception—elles mettent à jour les spécifications pour la prochaine régénération. Les problèmes thermiques deviennent de nouvelles exigences de refroidissement. Les problèmes de disponibilité des composants deviennent de nouvelles contraintes d'approvisionnement. La rétroaction utilisateur devient des spécifications d'interface raffinées. Cette danse itérative entre spécification, implémentation, et réalité opérationnelle est où la vraie compréhension émerge et où le cycle de vie de développement matériel traditionnel se transforme en évolution continue. - -## Pourquoi SDD Importe Maintenant pour le Matériel - -Trois tendances rendent SDD non seulement possible mais nécessaire pour le développement matériel : - -Premièrement, les capacités IA ont atteint un seuil où les spécifications en langage naturel peuvent générer de manière fiable des conceptions matérielles fonctionnelles. Il ne s'agit pas de remplacer les ingénieurs—il s'agit d'amplifier leur efficacité en automatisant la traduction mécanique de spécification à implémentation à travers les domaines mécaniques, électriques et embarqués. Elle peut amplifier l'exploration et la créativité, elle peut supporter "recommencer" facilement, elle supporte addition soustraction et pensée critique. - -Deuxièmement, la complexité matérielle continue à croître exponentiellement. Les produits modernes intègrent des systèmes mécaniques sophistiqués, de l'électronique complexe, la communication sans fil, l'IA embarquée, et les exigences de conformité réglementaire. Garder toutes ces pièces interdisciplinaires alignées avec l'intention originale à travers des processus manuels devient de plus en plus difficile. SDD fournit un alignement systématique à travers la génération dirigée par spécification. Les outils de conception peuvent évoluer pour fournir un support IA-first, pas humain-first, ou architecturer autour de bibliothèques de composants réutilisables. - -Troisièmement, le rythme du développement matériel s'accélère. Les exigences changent plus rapidement que le développement matériel traditionnel ne peut s'adapter. Les demandes du marché, les perturbations de chaîne d'approvisionnement, les changements réglementaires, et les avances technologiques créent une pression constante pour l'adaptation. Le développement matériel traditionnel traite ces changements comme des perturbations coûteuses nécessitant des cycles de reconception complète. Chaque pivot nécessite de propager manuellement les changements à travers les conceptions mécaniques, schémas électriques, layouts PCB, firmware, et processus de fabrication. Le résultat est soit des mises à jour lentes et prudentes qui limitent le temps de mise sur le marché, soit des changements rapides et imprudents qui accumulent la dette de conception et les problèmes de qualité. - -SDD peut supporter des expériences what-if/simulation, "Si nous devons réimplémenter ou changer le produit pour cibler un segment de marché différent avec des exigences d'alimentation différentes, comment redessinerions-nous le système de gestion d'alimentation et quel serait l'impact de fabrication ?". - -SDD transforme les changements d'exigences d'obstacles en workflow normal. Quand les spécifications pilotent l'implémentation, les changements de conception deviennent des régénérations systématiques plutôt que des reconceptions manuelles. Changer une exigence de performance centrale dans le PRD, et les conceptions mécaniques, électriques et embarquées affectées se mettent à jour automatiquement. Modifier une exigence d'interface utilisateur, et les contrôles mécaniques correspondants, interfaces électriques, et implémentations firmware régénèrent. Il ne s'agit pas seulement du développement initial—il s'agit de maintenir la vélocité d'ingénierie à travers les changements inévitables tout en préservant l'intégrité de conception. - -## Principes Fondamentaux - -**Spécifications comme Lingua Franca** : La spécification devient l'artefact principal. Les fichiers de conception deviennent leur expression pour des processus de fabrication et choix de composants particuliers. Maintenir le matériel signifie faire évoluer les spécifications. - -**Spécifications Exécutables** : Les spécifications doivent être précises, complètes, et non ambiguës suffisamment pour générer des systèmes matériels fonctionnels à travers les domaines mécaniques, électriques et embarqués. Cela élimine l'écart entre intention et implémentation. - -**Raffinement Continu** : La validation de cohérence se fait continuellement, pas comme une porte unique. L'IA analyse les spécifications pour l'ambiguïté, contradictions, et lacunes comme un processus continu à travers toutes les disciplines d'ingénierie. - -**Contexte Dirigé par la Recherche** : Les agents de recherche rassemblent un contexte critique tout au long du processus de spécification, enquêtant sur les spécifications de composants, contraintes de fabrication, exigences réglementaires, et implications de coût. - -**Rétroaction Bidirectionnelle** : La réalité de fabrication et la performance sur le terrain informent l'évolution de spécification. La rétroaction de conception pour fabrication, disponibilité des composants, défaillances sur le terrain, et expérience utilisateur deviennent des entrées pour le raffinement de spécification. - -**Intégration Multi-Disciplinaire** : Générer des implémentations coordonnées à travers les systèmes mécaniques, électriques et embarqués à partir de spécifications unifiées, assurant que les interfaces et contraintes appropriées sont maintenues à travers les domaines. - -## Approches d'Implémentation - -Aujourd'hui, pratiquer SDD pour le matériel nécessite d'assembler les outils existants et maintenir la discipline tout au long du processus. La méthodologie peut être pratiquée avec : - -- Assistants IA pour le développement de spécification itératif -- Agents de recherche pour rassembler le contexte technique et l'information sur les composants -- Outils de génération de conception pour traduire les spécifications en conceptions mécaniques (Fusion360), schémas électriques (KiCAD), et firmware embarqué -- Systèmes de contrôle de version adaptés pour les workflows spécification-first avec de gros fichiers de conception binaires -- Vérification de cohérence à travers l'analyse IA des documents de spécification à travers les disciplines d'ingénierie - -La clé est de traiter les spécifications comme la source de vérité, avec les fichiers de conception comme la sortie générée qui sert la spécification plutôt que l'inverse. - -## Rationaliser SDD avec les Commandes Claude pour le Matériel - -La méthodologie SDD est significativement améliorée à travers deux commandes Claude puissantes qui automatisent le workflow de spécification et planification pour le développement matériel : - -### La Commande `new_feature` - -Cette commande transforme une description simple de fonctionnalité matérielle (le prompt utilisateur) en une spécification complète et structurée avec gestion automatique du dépôt : - -1. **Numérotation Automatique de Fonctionnalité** : Scanne les spécifications existantes pour déterminer le prochain numéro de fonctionnalité (ex., 001, 002, 003) -2. **Création de Branche** : Génère un nom de branche sémantique à partir de votre description et la crée automatiquement -3. **Génération Basée sur Modèle** : Copie et personnalise le modèle de spécification de fonctionnalité matérielle avec vos exigences -4. **Structure de Répertoire** : Crée la structure appropriée `specs/[nom-branche]/` pour tous les documents liés - -### La Commande `generate_plan` - -Une fois qu'une spécification de fonctionnalité matérielle existe, cette commande crée un plan d'implémentation compréhensif : - -1. **Analyse de Spécification** : Lit et comprend les exigences de fonctionnalité, histoires utilisateur, et critères d'acceptation -2. **Conformité Constitutionnelle** : Assure l'alignement avec la constitution du projet matériel et les principes de conception -3. **Traduction Technique** : Convertit les exigences produit en architectures de systèmes mécaniques, électriques et embarqués -4. **Documentation Détaillée** : Génère des documents de support pour les spécifications matérielles, listes de composants, et procédures de test -5. **Plans de Test Manuel** : Crée des procédures de validation étape par étape pour chaque sous-système matériel - -### Exemple : Construire un Nœud de Capteur Sans Fil - -Voici comment ces commandes transforment le workflow de développement matériel traditionnel : - -**Approche Traditionnelle :** -``` -1. Écrire un PRD dans un document (2-3 heures) -2. Créer des documents de conception mécanique (4-6 heures) -3. Créer des schémas électriques et spécifications (4-6 heures) -4. Définir l'architecture du système embarqué (3-4 heures) -5. Configurer la structure de projet manuellement (1 heure) -6. Créer des plans de test et validation (3-4 heures) -Total : ~20-25 heures de travail de documentation -``` - -**Approche SDD avec Commandes :** -```bash -# Étape 1 : Créer la spécification de fonctionnalité matérielle (5 minutes) -/new_feature Nœud de capteur environnemental sans fil avec surveillance température, humidité, durée de vie batterie 1 an, et connectivité LoRaWAN - -# Cela automatiquement : -# - Crée la branche "003-sensor-node" -# - Génère specs/003-sensor-node/feature-spec.md -# - La remplit avec des exigences matérielles structurées - -# Étape 2 : Générer le plan d'implémentation (10 minutes) -/generate_plan Microcontrôleur ESP32-S3, capteurs DHT22, module LoRa, boîtier PETG imprimé 3D, batterie 18650 avec charge solaire, conception PCB KiCAD - -# Cela crée automatiquement : -# - specs/003-sensor-node/implementation-plan.md -# - specs/003-sensor-node/hardware/ -# - mechanical-spec.md (Conception boîtier, matériaux, montage) -# - electrical-spec.md (Schéma, layout PCB, gestion alimentation) -# - embedded-spec.md (Architecture firmware, protocoles communication) -# - specs/003-sensor-node/research.md (Comparaisons composants, analyse alimentation) -# - specs/003-sensor-node/data-model.md (Formats données capteur, protocoles communication) -# - specs/003-sensor-node/manual-testing.md (Procédures validation) -``` - -En 15 minutes, vous avez : -- Une spécification complète de fonctionnalité matérielle avec histoires utilisateur et critères d'acceptation -- Un plan d'implémentation détaillé avec choix de composants et justification de conception -- Spécifications matérielles pour sous-systèmes mécaniques, électriques et embarqués prêts pour la conception -- Scénarios de test compréhensifs pour tests au niveau composant et système -- Tous les documents correctement versionnés dans une branche de fonctionnalité - -### Le Pouvoir de l'Automatisation Structurée - -Ces commandes ne font pas que gagner du temps—elles imposent cohérence et complétude à travers les disciplines : - -1. **Aucun Détail Oublié** : Les modèles assurent que chaque aspect est considéré, des exigences environnementales à la conformité réglementaire -2. **Décisions Traçables** : Chaque choix de composant et décision de conception relie à des exigences spécifiques -3. **Documentation Vivante** : Les spécifications restent synchronisées avec les fichiers de conception parce qu'elles les génèrent -4. **Itération Rapide** : Changer les exigences et régénérer les plans de conception en minutes, pas jours -5. **Coordination Multi-Disciplinaire** : Assure que les systèmes mécaniques, électriques et embarqués sont correctement intégrés - -Les commandes incarnent les principes SDD en traitant les spécifications comme des artefacts exécutables plutôt que documents statiques. Elles transforment le processus de spécification d'un mal nécessaire en force motrice du développement matériel. - -### Qualité Dirigée par Modèle : Comment la Structure Contraint les LLMs pour de Meilleurs Résultats Matériels - -Le vrai pouvoir de ces commandes réside non seulement dans l'automatisation, mais dans comment les modèles guident le comportement LLM vers des spécifications matérielles de meilleure qualité. Les modèles agissent comme des prompts sophistiqués qui contraignent la sortie du LLM de manières productives : - -#### 1. **Prévenir les Détails d'Implémentation Prématurés** - -Le modèle de spécification de fonctionnalité matérielle instruit explicitement : -``` -- ✅ Se concentrer sur CE QUE les utilisateurs ont besoin et POURQUOI, et CE QUE le matériel doit faire -- ❌ Éviter COMMENT implémenter (pas de modèles MCU/SBC spécifiques, outils CAO, layouts PCB) -``` - -Cette contrainte force le LLM à maintenir des niveaux d'abstraction appropriés. Quand un LLM pourrait naturellement sauter à "implémenter en utilisant ESP32 avec Arduino IDE," le modèle le garde focalisé sur "les utilisateurs ont besoin de surveillance environnementale sans fil avec durée de vie batterie 1 an." Cette séparation assure que les spécifications restent stables même quand les technologies d'implémentation et choix de composants changent. - -#### 2. **Forcer les Marqueurs d'Incertitude Explicites** - -Les deux modèles mandatent l'utilisation de marqueurs `[NEEDS CLARIFICATION]` : -``` -Lors de la création de cette spécification à partir d'un prompt utilisateur : -1. **Marquer toutes les ambiguïtés** : Utiliser [NEEDS CLARIFICATION: question spécifique] -2. **Ne pas deviner** : Si le prompt ne spécifie pas quelque chose, le marquer -``` - -Cela prévient le comportement LLM commun de faire des suppositions plausibles mais potentiellement incorrectes. Au lieu de deviner qu'un "capteur sans fil" utilise la communication WiFi, le LLM doit le marquer comme `[NEEDS CLARIFICATION: protocole non spécifié - WiFi, LoRa, Bluetooth, Zigbee ?]`. - -#### 3. **Pensée Structurée à Travers des Listes de Contrôle** - -Les modèles incluent des listes de contrôle compréhensives qui agissent comme "tests unitaires" pour la spécification : -``` -### Complétude des Exigences -- [ ] Aucun marqueur [NEEDS CLARIFICATION] ne reste -- [ ] Les exigences sont testables et mesurables -- [ ] Contraintes physiques et environnementales définies -- [ ] Exigences d'alimentation et communication spécifiées -``` - -Ces listes de contrôle forcent le LLM à auto-examiner sa sortie systématiquement, attrapant les lacunes qui pourraient autrement passer inaperçues. C'est comme donner au LLM un cadre d'assurance qualité spécifiquement accordé pour le développement matériel. - -#### 4. **Conformité Constitutionnelle à Travers des Portes** - -Le modèle de plan d'implémentation impose les principes de conception à travers des portes de phase : -``` -### Phase -1 : Portes Pré-Implémentation -#### Porte de Modularité de Conception -- [ ] Utiliser ≤3 sous-systèmes ? -- [ ] Interfaces standard définies ? -#### Porte de Conception-pour-Test -- [ ] Procédures de test définies ? -- [ ] Plan de validation existe ? -``` - -Ces portes préviennent la sur-ingénierie en faisant explicitement justifier toute complexité au LLM. Si une porte échoue, le LLM doit documenter pourquoi dans la section "Suivi de Complexité," créant une responsabilité pour les décisions de conception. - -#### 5. **Gestion de Détail Hiérarchique** - -Les modèles imposent une architecture d'information appropriée : -``` -**IMPORTANT** : Ce plan d'implémentation doit rester de haut niveau et lisible. -Toutes spécifications de composants détaillées, modèles CAO, ou spécifications -techniques extensives doivent être placées dans les sous-répertoires `hardware/` appropriés -``` - -Cela prévient le problème commun des spécifications devenant des décharges techniques illisibles. Le LLM apprend à maintenir des niveaux de détail appropriés, extrayant la complexité vers des fichiers spécifiques au domaine séparés tout en gardant le document principal navigable. - -#### 6. **Pensée Conception-d'Abord** - -Le modèle d'implémentation impose le développement conception-pour-test : -``` -### Ordre de Création de Conception -1. Créer des spécifications matérielles pour chaque sous-système -2. Créer des procédures de validation dans l'ordre : composant → sous-système → système -3. Créer des fichiers de conception pour répondre aux spécifications -``` - -Cette contrainte d'ordonnancement assure que le LLM pense à la testabilité et validation avant l'implémentation, menant à des conceptions matérielles plus robustes et vérifiables. - -#### 7. **Prévenir les Fonctionnalités Spéculatives** - -Les modèles découragent explicitement la spéculation : -``` -- [ ] Aucune fonctionnalité spéculative ou "pourrait avoir besoin" -- [ ] Tous les sous-systèmes ont des interfaces et livrables clairs -- [ ] Exigences environnementales et réglementaires identifiées -``` - -Cela arrête le LLM d'ajouter des fonctionnalités "agréables à avoir" qui compliquent la conception et fabrication. Chaque fonctionnalité doit remonter à une histoire utilisateur concrète avec des critères d'acceptation clairs. - -### L'Effet Composé - -Ces contraintes travaillent ensemble pour produire des spécifications matérielles qui sont : -- **Complètes** : Les listes de contrôle assurent que rien n'est oublié à travers les domaines mécaniques, électriques et embarqués -- **Non Ambiguës** : Les marqueurs de clarification forcés mettent en évidence les incertitudes dans les spécifications -- **Testables** : Pensée conception-pour-test intégrée dans le processus -- **Maintenables** : Niveaux d'abstraction appropriés et hiérarchie d'information à travers les disciplines d'ingénierie -- **Implémentables** : Phases claires avec livrables concrets pour chaque domaine d'ingénierie - -Les modèles transforment le LLM d'un écrivain créatif en un ingénieur de spécification matérielle discipliné, canalisant ses capacités vers la production de spécifications de haute qualité, exécutables de manière cohérente qui pilotent vraiment le développement matériel. - -## La Fondation Constitutionnelle : Imposer la Discipline de Conception - -Au cœur de SDD réside une constitution—un ensemble de principes immuables qui gouvernent comment les spécifications deviennent des conceptions matérielles. La constitution (`memory/constitution.md`) agit comme l'ADN de conception du système, assurant que chaque implémentation générée maintient cohérence, modularité, et qualité à travers les domaines mécaniques, électriques et embarqués. - -### Les Cinq Articles du Développement Matériel - -La constitution définit cinq articles qui façonnent chaque aspect du processus de développement matériel : - -#### Article I : Principe Conception-d'Abord -Chaque fonctionnalité matérielle commence comme une spécification de conception complète avec composants mécaniques, électriques et embarqués clairement définis : -``` -Chaque fonctionnalité matérielle DOIT commencer avec des spécifications de conception compréhensives. -Aucune implémentation ne commence sans : -- Contraintes de conception mécanique et exigences de boîtier -- Schéma électrique et budgets d'alimentation -- Architecture firmware embarquée et protocoles de communication -``` - -Ce principe assure que les spécifications génèrent des conceptions coordonnées, intégrées plutôt que des sous-systèmes déconnectés. Quand le LLM génère un plan d'implémentation, il doit structurer les fonctionnalités avec des interfaces claires entre les domaines mécaniques, électriques et embarqués. - -#### Article II : Interface Multi-Disciplinaire -Chaque système matériel expose la fonctionnalité à travers des interfaces bien définies : -``` -Toutes les interfaces matérielles DOIVENT : -- Mécanique : Points de montage standard, placements de connecteurs, procédures d'assemblage -- Électrique : Brochages documentés, exigences d'alimentation, spécifications de signal -- Embarqué : Points de terminaison API, protocoles de communication, interfaces de configuration -``` - -Cela impose l'intégration et la testabilité. Le LLM ne peut pas cacher la fonctionnalité dans des interfaces propriétaires—tout doit être accessible et vérifiable à travers des interfaces standard. - -#### Article III : Impératif Conception-pour-Test -L'article le plus transformateur—aucune implémentation avant les procédures de test : -``` -Ceci est NON-NÉGOCIABLE : Toute implémentation matérielle DOIT suivre une Conception-pour-Test stricte. -Aucune implémentation ne doit commencer avant : -1. Les procédures de test sont définies pendant la phase de spécification -2. Les procédures de test sont validées et approuvées -3. Les tests de validation de conception sont confirmés d'exister -``` - -Cela inverse complètement le développement matériel traditionnel. Au lieu de concevoir le matériel et espérer qu'il fonctionne, le LLM doit d'abord générer des procédures de test compréhensives qui définissent les critères de validation, les faire approuver, et seulement alors générer l'implémentation. - -#### Article IV : Validation Intégration-d'Abord -Priorise les tests du monde réel sur les tests de composants isolés : -``` -Les systèmes matériels DOIVENT être testés comme systèmes intégrés : -- Préférer les interfaces capteur/actionneur réelles aux entrées simulées -- Utiliser les protocoles de communication actuels et connexions physiques -- Tests environnementaux sous conditions d'opération réalistes -``` - -Cela assure que les conceptions générées fonctionnent en pratique, pas seulement en théorie. - -#### Article V : Modularité de Plateforme -Les conceptions matérielles doivent supporter l'implémentation modulaire : -``` -Les conceptions matérielles DOIVENT supporter la modularité : -- Mécanique : Interfaces de montage standardisées et systèmes de boîtier -- Électrique : Conceptions PCB modulaires avec connecteurs standard -- Embarqué : Couches d'abstraction matérielle et communication standardisée -``` - -Quand un LLM pourrait naturellement créer des conceptions monolithiques, cet article force la pensée modulaire avec des limites de sous-système claires. - -### Enforcement Constitutionnel à Travers les Modèles - -Le modèle de plan d'implémentation opérationnalise ces articles à travers des points de contrôle concrets : - -```markdown -### Vérification Constitution -#### Modularité de Conception -- [ ] Utiliser ≤3 sous-systèmes ? -- [ ] Interfaces standard définies ? - -#### Conception-pour-Test (NON-NÉGOCIABLE) -- [ ] Procédures de test définies avant implémentation ? -- [ ] Plan de validation de conception existe ? - -#### Intégration-d'Abord -- [ ] Tests d'environnement réel planifiés ? -- [ ] Interfaces matérielles actuelles spécifiées ? -``` - -Ces portes agissent comme vérifications de revue de conception pour les principes matériels. Le LLM ne peut pas procéder sans soit passer les portes soit documenter des exceptions justifiées dans la section "Suivi de Complexité." - -### Le Pouvoir des Principes Immuables - -Le pouvoir de la constitution réside dans son immutabilité. Alors que les détails d'implémentation peuvent évoluer, les principes de base restent constants. Cela fournit : - -1. **Cohérence à Travers le Temps** : Les conceptions générées aujourd'hui suivent les mêmes principes que les conceptions générées l'année prochaine -2. **Cohérence à Travers les LLMs** : Différents modèles IA produisent des conceptions architecturalement compatibles -3. **Intégrité de Conception** : Chaque fonctionnalité renforce plutôt que mine la conception système -4. **Garanties de Qualité** : Les principes conception-pour-test, modularité, et intégration assurent un matériel fabricable - -### Évolution Constitutionnelle - -Alors que les principes sont immuables, leur application peut évoluer : -``` -Section 4.2 : Processus d'Amendement -Les modifications à cette constitution nécessitent : -- Documentation explicite de la justification pour le changement -- Examen et approbation par les mainteneurs du projet -- Évaluation de compatibilité rétroactive -``` - -Cela permet à la méthodologie d'apprendre et s'améliorer tout en maintenant la stabilité. La constitution montre sa propre évolution avec des amendements datés, démontrant comment les principes peuvent être raffinés basés sur l'expérience de développement matériel du monde réel. - -### Au-delà des Règles : Une Philosophie de Conception - -La constitution n'est pas seulement un règlement—c'est une philosophie qui façonne comment les LLMs pensent à la génération de conception matérielle : - -- **Intégration sur Isolation** : Tester dans des environnements réels avec du matériel actuel, pas simulé -- **Modularité sur Monolithes** : Chaque sous-système a des interfaces et limites claires -- **Validation sur Supposition** : Les procédures de validation de conception sont obligatoires avant l'implémentation -- **Standards sur Personnalisé** : Utiliser des interfaces et composants standard sauf si des solutions personnalisées sont justifiées - -En intégrant ces principes dans le processus de spécification et planification, SDD assure que les conceptions générées ne sont pas seulement fonctionnelles—elles sont fabricables, testables, et architecturalement saines. La constitution transforme l'IA d'un générateur de conception en un partenaire de conception qui respecte et renforce les principes d'ingénierie matérielle. - -## La Transformation - -Il ne s'agit pas de remplacer les ingénieurs ou automatiser la créativité. Il s'agit d'amplifier la capacité humaine en automatisant la traduction mécanique des spécifications aux conceptions. Il s'agit de créer une boucle de rétroaction serrée où spécifications, recherche, et conceptions matérielles évoluent ensemble, chaque itération apportant une compréhension plus profonde et un meilleur alignement entre intention et implémentation. - -Le développement matériel a besoin de meilleurs outils pour maintenir l'alignement entre intention et implémentation à travers les domaines mécaniques, électriques et embarqués. SDD fournit la méthodologie pour atteindre cet alignement à travers des spécifications exécutables qui génèrent des conceptions matérielles coordonnées plutôt que de simplement les guider. \ No newline at end of file diff --git a/templates/agent-file-template_fr.md b/templates/agent-file-template_fr.md deleted file mode 100644 index 821a686eff..0000000000 --- a/templates/agent-file-template_fr.md +++ /dev/null @@ -1,23 +0,0 @@ -# [NOM PROJET] Directives de Développement - -Auto-généré à partir de tous les plans de fonctionnalités. Dernière mise à jour : [DATE] - -## Technologies Actives -[EXTRAIT DE TOUS LES FICHIERS PLAN.MD] - -## Structure de Projet -``` -[STRUCTURE RÉELLE DES PLANS] -``` - -## Commandes -[SEULEMENT COMMANDES POUR TECHNOLOGIES ACTIVES] - -## Style de Code -[SPÉCIFIQUE AU LANGAGE, SEULEMENT POUR LANGAGES UTILISÉS] - -## Changements Récents -[3 DERNIÈRES FONCTIONNALITÉS ET CE QU'ELLES ONT AJOUTÉ] - - - \ No newline at end of file diff --git a/templates/commands/plan_fr.md b/templates/commands/plan_fr.md deleted file mode 100644 index 57448adc81..0000000000 --- a/templates/commands/plan_fr.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -name: plan -description: "Planifier comment implémenter la fonctionnalité spécifiée. C'est la deuxième étape du cycle de vie de Développement Dirigé par les Spécifications." ---- - -Planifier comment implémenter la fonctionnalité spécifiée. - -C'est la deuxième étape du cycle de vie de Développement Dirigé par les Spécifications. - -Étant donné les détails d'implémentation fournis comme argument, faire ceci : - -1. Exécuter `scripts/setup-plan.sh --json` depuis la racine du dépôt et analyser JSON pour FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH. Tous les futurs chemins de fichiers doivent être absolus. -2. Lire et analyser la spécification de fonctionnalité pour comprendre : - - Les exigences de fonctionnalité et histoires utilisateur - - Exigences fonctionnelles et non-fonctionnelles - - Critères de succès et critères d'acceptation - - Toutes contraintes techniques ou dépendances mentionnées - -3. Lire la constitution à `/memory/constitution.md` pour comprendre les exigences constitutionnelles. - -4. Exécuter le modèle de plan d'implémentation : - - Charger `/templates/plan-template.md` (déjà copié vers le chemin IMPL_PLAN) - - Définir le chemin d'entrée vers FEATURE_SPEC - - Exécuter les étapes 1-10 de la fonction Flux d'Exécution (principal) - - Le modèle est autonome et exécutable - - Suivre la gestion d'erreur et vérifications de porte comme spécifié - - Laisser le modèle guider la génération d'artefacts dans $SPECS_DIR : - * Phase 0 génère research.md - * Phase 1 génère data-model.md, contracts/, quickstart.md - * Phase 2 génère tasks.md - - Incorporer les détails fournis par l'utilisateur des arguments dans Contexte Technique : {ARGS} - - Mettre à jour le Suivi de Progrès en complétant chaque phase - -5. Vérifier que l'exécution s'est terminée : - - Vérifier que le Suivi de Progrès montre toutes les phases complètes - - S'assurer que tous les artefacts requis ont été générés - - Confirmer aucun état ERROR dans l'exécution - -6. Rapporter les résultats avec nom de branche, chemins de fichiers, et artefacts générés. - -Utiliser des chemins absolus avec la racine du dépôt pour toutes les opérations de fichiers pour éviter les problèmes de chemin. \ No newline at end of file diff --git a/templates/commands/specify_fr.md b/templates/commands/specify_fr.md deleted file mode 100644 index 52f94eabfb..0000000000 --- a/templates/commands/specify_fr.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -name: specify -description: "Commencer une nouvelle fonctionnalité en créant une spécification et une branche de fonctionnalité. C'est la première étape du cycle de vie de Développement Dirigé par les Spécifications." ---- - -Commencer une nouvelle fonctionnalité en créant une spécification et une branche de fonctionnalité. - -C'est la première étape du cycle de vie de Développement Dirigé par les Spécifications. - -Étant donné la description de fonctionnalité fournie comme argument, faire ceci : - -1. Exécuter le script `scripts/create-new-feature.sh --json "{ARGS}"` depuis la racine du dépôt et analyser sa sortie JSON pour BRANCH_NAME et SPEC_FILE. Tous les chemins de fichiers doivent être absolus. -2. Charger `templates/spec-template.md` pour comprendre les sections requises. -3. Écrire la spécification vers SPEC_FILE en utilisant la structure de modèle, remplaçant les placeholders avec des détails concrets dérivés de la description de fonctionnalité (arguments) tout en préservant l'ordre des sections et les en-têtes. -4. Rapporter l'achèvement avec le nom de branche, le chemin du fichier de spécification, et la préparation pour la phase suivante. - -Note : Le script crée et bascule vers la nouvelle branche et initialise le fichier de spécification avant écriture. \ No newline at end of file diff --git a/templates/commands/tasks_fr.md b/templates/commands/tasks_fr.md deleted file mode 100644 index cb75a5d4a0..0000000000 --- a/templates/commands/tasks_fr.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -name: tasks -description: "Décomposer le plan en tâches exécutables. C'est la troisième étape du cycle de vie de Développement Dirigé par les Spécifications." ---- - -Décomposer le plan en tâches exécutables. - -C'est la troisième étape du cycle de vie de Développement Dirigé par les Spécifications. - -Étant donné le contexte fourni comme argument, faire ceci : - -1. Exécuter `scripts/check-task-prerequisites.sh --json` depuis la racine du dépôt et analyser FEATURE_DIR et la liste AVAILABLE_DOCS. Tous les chemins doivent être absolus. -2. Charger et analyser les documents de conception disponibles : - - Toujours lire plan.md pour la pile technologique et bibliothèques - - SI EXISTE : Lire data-model.md pour les entités - - SI EXISTE : Lire contracts/ pour les points de terminaison API - - SI EXISTE : Lire research.md pour les décisions techniques - - SI EXISTE : Lire quickstart.md pour les scénarios de test - - Note : Tous les projets n'ont pas tous les documents. Par exemple : - - Les outils CLI pourraient ne pas avoir contracts/ - - Les bibliothèques simples pourraient ne pas avoir besoin de data-model.md - - Générer les tâches basées sur ce qui est disponible - -3. Générer les tâches en suivant le modèle : - - Utiliser `/templates/tasks-template.md` comme base - - Remplacer les tâches d'exemple avec des tâches réelles basées sur : - * **Tâches de configuration** : Init projet, dépendances, linting - * **Tâches de test [P]** : Une par contrat, une par scénario d'intégration - * **Tâches principales** : Une par entité, service, commande CLI, point de terminaison - * **Tâches d'intégration** : Connexions DB, middleware, logging - * **Tâches de finition [P]** : Tests unitaires, performance, docs - -4. Règles de génération de tâches : - - Chaque fichier de contrat → tâche de test de contrat marquée [P] - - Chaque entité dans data-model → tâche de création de modèle marquée [P] - - Chaque point de terminaison → tâche d'implémentation (pas parallèle si fichiers partagés) - - Chaque histoire utilisateur → test d'intégration marqué [P] - - Fichiers différents = peuvent être parallèles [P] - - Même fichier = séquentiel (pas de [P]) - -5. Ordonner les tâches par dépendances : - - Configuration avant tout - - Tests avant implémentation (TDD) - - Modèles avant services - - Services avant points de terminaison - - Principal avant intégration - - Tout avant finition - -6. Inclure des exemples d'exécution parallèle : - - Grouper les tâches [P] qui peuvent fonctionner ensemble - - Montrer les commandes d'agent Task réelles - -7. Créer FEATURE_DIR/tasks.md avec : - - Nom de fonctionnalité correct du plan d'implémentation - - Tâches numérotées (T001, T002, etc.) - - Chemins de fichiers clairs pour chaque tâche - - Notes de dépendance - - Conseils d'exécution parallèle - -Contexte pour la génération de tâches : {ARGS} - -Le tasks.md devrait être immédiatement exécutable - chaque tâche doit être suffisamment spécifique pour qu'un LLM puisse la compléter sans contexte additionnel. \ No newline at end of file diff --git a/templates/plan-template_fr.md b/templates/plan-template_fr.md deleted file mode 100644 index 4b6aa1f67e..0000000000 --- a/templates/plan-template_fr.md +++ /dev/null @@ -1,211 +0,0 @@ -# Plan d'Implémentation Matérielle : [FONCTIONNALITÉ] - -**Branche** : `[###-nom-fonctionnalité]` | **Date** : [DATE] | **Spéc** : [lien] -**Entrée** : Spécification de fonctionnalité matérielle de `/specs/[###-nom-fonctionnalité]/spec.md` - -## Flux d'Exécution (portée commande /plan) -``` -1. Charger spéc fonctionnalité matérielle depuis chemin Entrée - → Si pas trouvé : ERROR "Aucune spéc fonctionnalité à {chemin}" -2. Remplir Contexte Technique (scanner pour NEEDS CLARIFICATION) - → Détecter Type Matériel depuis contexte (iot=mcu+capteurs, robotique=actionneurs+contrôle, mesure=capteurs+affichage) - → Définir Décision Structure Conception basée sur type matériel -3. Évaluer section Vérification Constitution ci-dessous - → Si violations existent : Documenter dans Suivi Complexité - → Si aucune justification possible : ERROR "Simplifier approche d'abord" - → Mettre à jour Suivi Progrès : Vérification Constitution Initiale -4. Exécuter Phase 0 → research.md - → Si NEEDS CLARIFICATION restent : ERROR "Résoudre inconnues" -5. Exécuter Phase 1 → spécs matérielles, conceptions mécaniques/électriques/embarquées, quickstart.md, fichier modèle spécifique agent -6. Réévaluer section Vérification Constitution - → Si nouvelles violations : Refactoriser conception, retourner à Phase 1 - → Mettre à jour Suivi Progrès : Vérification Constitution Post-Conception -7. Planifier Phase 2 → Décrire approche génération tâches (NE PAS créer tasks.md) -8. ARRÊT - Prêt pour commande /tasks -``` - -**IMPORTANT** : La commande /plan S'ARRÊTE à l'étape 7. Phases 2-4 sont exécutées par d'autres commandes : -- Phase 2 : Commande /tasks crée tasks.md -- Phase 3-4 : Exécution implémentation matérielle (outils conception, prototypage, tests) - -## Résumé -[Extraire de spéc fonctionnalité matérielle : exigence principale + approche technique de recherche] - -## Contexte Technique -**Plateforme Matérielle** : [ex., ESP32-S3, Raspberry Pi 4, STM32F4 ou NEEDS CLARIFICATION] -**Composants Principaux** : [ex., capteurs DHT22, écran OLED, module LoRa ou NEEDS CLARIFICATION] -**Système d'Alimentation** : [ex., 18650 Li-ion avec solaire, USB-C PD, pile bouton ou NEEDS CLARIFICATION] -**Conception Mécanique** : [ex., boîtier PETG imprimé 3D, extrusion aluminium, ABS moulé injection ou NEEDS CLARIFICATION] -**Communication** : [ex., WiFi, LoRaWAN, Bluetooth LE, bus CAN ou NEEDS CLARIFICATION] -**Processus de Fabrication** : [ex., prototype/petit lot, moulage injection, maison assemblage PCB ou NEEDS CLARIFICATION] -**Type Matériel** : [iot/robotique/mesure/contrôle - détermine structure conception] -**Objectifs Performance** : [spécifiques domaine, ex., durée vie batterie 1 an, réponse <100ms, précision ±0.1% ou NEEDS CLARIFICATION] -**Exigences Environnementales** : [ex., IP65, -20°C à +60°C, EMC automobile ou NEEDS CLARIFICATION] -**Conformité Réglementaire** : [ex., FCC Part 15, marquage CE, listé UL ou NEEDS CLARIFICATION] - -## Vérification Constitution -*PORTE : Doit passer avant recherche Phase 0. Revérifier après conception Phase 1.* - -**Modularité Conception** : -- Sous-systèmes : [#] (max 3 - ex., mécanique, électrique, embarqué) -- Utiliser interfaces standard ? (pas connecteurs personnalisés sans justification) -- Conception mécanique modulaire ? (montage standardisé, assemblages séparables) -- Conception électrique modulaire ? (connecteurs standard, points test, PCBs modulaires) - -**Architecture Matérielle** : -- CHAQUE sous-système comme module ? (pas conceptions monolithiques) -- Modules listés : [nom + fonction pour chaque] -- Interfaces test par module : [spécifications connecteur/port] -- Format documentation : fiches techniques standardisées planifiées ? - -**Conception-pour-Test (NON-NÉGOCIABLE)** : -- Conception-Test-d'Abord appliquée ? (procédures test DOIVENT être définies avant implémentation) -- Plan validation conception existe ? (stress mécanique, validation électrique, tests embarqués) -- Ordre : Exigences→Plan Test→Conception→Validation strictement suivi ? -- Tests environnement réel ? (capteurs réels, charges, communication) -- Tests intégration pour : interfaces mécaniques, connexions électriques, communication embarquée ? -- INTERDIT : Implémentation avant plan test, sauter phase validation - -**Documentation Conception** : -- Fichiers conception sous contrôle version ? -- Documentation fabrication incluse ? -- Procédures assemblage documentées ? -- Justification conception capturée ? - -**Contraintes Conception** : -- Exigences fabrication spécifiées ? -- Plan approvisionnement composants existe ? -- Objectifs coût établis ? -- Conformité réglementaire adressée ? - -## Structure Conception Matérielle - -### Documentation (cette fonctionnalité) -``` -specs/[###-fonctionnalité]/ -├── plan.md # Ce fichier (sortie commande /plan) -├── research.md # Sortie Phase 0 (commande /plan) -├── data-model.md # Sortie Phase 1 (commande /plan) - données capteur, protocoles communication -├── quickstart.md # Sortie Phase 1 (commande /plan) -├── hardware/ # Sortie Phase 1 (commande /plan) -│ ├── mechanical-spec.md # Boîtier, montage, matériaux -│ ├── electrical-spec.md # Schéma, PCB, conception alimentation -│ └── embedded-spec.md # Firmware, communication, interfaces -└── tasks.md # Sortie Phase 2 (commande /tasks - PAS créé par /plan) -``` - -### Fichiers Conception (racine dépôt) -``` -# Option 1 : Dispositif IoT (DÉFAUT) -hardware/ -├── mechanical/ -│ ├── enclosures/ # Fichiers Fusion360 (.f3d) -│ ├── assemblies/ # Dessins assemblage -│ └── manufacturing/ # Fichiers STL, STEP pour production -├── electrical/ -│ ├── schematics/ # Fichiers projet KiCAD (.kicad_pro, .kicad_sch) -│ ├── pcb/ # Layouts PCB (.kicad_pcb) -│ └── gerbers/ # Fichiers fabrication -└── embedded/ - ├── firmware/ # Code MCU/SBC (Arduino, ESP-IDF, etc.) - ├── libraries/ # Couches abstraction matérielle - └── tests/ # Tests unitaires et intégration - -docs/ -├── datasheets/ # Spécifications composants -├── assembly/ # Instructions assemblage -└── testing/ # Procédures test et résultats - -# Option 2 : Système Robotique (quand "actionneurs" + "contrôle" détecté) -hardware/ -├── mechanical/ -│ ├── chassis/ # Conception structure principale -│ ├── joints/ # Montures actionneur et joints -│ └── end-effectors/ # Outils, préhenseurs, capteurs -├── electrical/ -│ ├── power/ # Distribution alimentation, gestion batterie -│ ├── control/ # Pilotes moteur, interfaces capteur -│ └── communication/ # Bus CAN, protocoles industriels -└── embedded/ - ├── control-system/ # Firmware contrôle temps réel - ├── safety/ # Verrouillages sécurité et surveillance - └── interface/ # Interface homme-machine - -# Option 3 : Système Mesure (quand "capteurs" + "journalisation données" détecté) -hardware/ -├── mechanical/ -│ ├── sensor-mounts/ # Systèmes montage précision -│ ├── calibration/ # Fixations calibration -│ └── shielding/ # Protection EMI/RFI -├── electrical/ -│ ├── analog-frontend/ # Conditionnement signal -│ ├── data-acquisition/ # ADC, timing, synchronisation -│ └── interfaces/ # Communication, affichage -└── embedded/ - ├── acquisition/ # Firmware collecte données - ├── processing/ # Algorithmes traitement signal - └── calibration/ # Routines calibration -``` - -**Décision Structure Conception** : [DÉFAUT Option 1 sauf si Contexte Technique indique système robotique/mesure] - -## Phase 0 : Recherche *(commande /plan exécute)* - -### Architecture Système -[Architecture niveau système basée sur Type Matériel détecté] - -### Considérations Conception -- **Contraintes Physiques** : [taille, poids, montage, environnement] -- **Alimentation** : [consommation, type batterie, gestion énergie] -- **Refroidissement** : [dissipation thermique, ventilation] -- **EMI/EMC** : [blindage, filtrage, conformité réglementaire] - -### Sélection Composants -[Recherche composants avec justifications basées sur exigences] - -## Phase 1 : Conception Détaillée *(commande /plan exécute)* - -### Spécifications Matérielles -*Auto-générées dans hardware/ selon Type Matériel* - -### Modèle Données & Communication -*Auto-généré dans data-model.md* - -### Guide Démarrage Rapide -*Auto-généré dans quickstart.md* - -### Validation Conception -[Tests et procédures validation basés sur constitution] - -## Phase 2 : Génération Tâches *(commande /tasks)* - -### Approche Génération Tâches -[Plan comment créer tasks.md - PAS création réelle] - -### Ordre Dépendances -[Ordre exécution tâches basé sur dépendances matérielles] - -### Tests Parallèles -[Stratégie tests parallèles pour sous-systèmes] - -## Suivi Complexité -*Violations constitution avec justifications* - -[Documentation exceptions constitution si nécessaires] - -## Suivi Progrès -*Mis à jour pendant exécution* - -- [ ] Spéc fonctionnalité matérielle chargée -- [ ] Contexte technique rempli -- [ ] Type matériel détecté -- [ ] Vérification constitution initiale passée -- [ ] Phase 0 recherche terminée -- [ ] Phase 1 conception détaillée terminée -- [ ] Vérification constitution post-conception passée -- [ ] Phase 2 planifiée -- [ ] Prêt pour commande /tasks - ---- - -**IMPORTANT** : Ce plan d'implémentation doit rester haut niveau et lisible. Toutes spécifications composants détaillées, modèles CAO, ou spécifications techniques extensives doivent être placées dans les sous-répertoires `hardware/` appropriés. \ No newline at end of file diff --git a/templates/spec-template_fr.md b/templates/spec-template_fr.md deleted file mode 100644 index b98cd1ff03..0000000000 --- a/templates/spec-template_fr.md +++ /dev/null @@ -1,139 +0,0 @@ -# Spécification de Fonctionnalité Matérielle : [NOM FONCTIONNALITÉ] - -**Branche de Fonctionnalité** : `[###-nom-fonctionnalité]` -**Créée** : [DATE] -**Statut** : Brouillon -**Entrée** : Description utilisateur : "$ARGUMENTS" - -## Flux d'Exécution (principal) -``` -1. Analyser la description utilisateur depuis l'Entrée - → Si vide : ERROR "Aucune description de fonctionnalité fournie" -2. Extraire les concepts clés de la description - → Identifier : besoins utilisateur, contraintes physiques, exigences environnementales, interfaces -3. Pour chaque aspect peu clair : - → Marquer avec [NEEDS CLARIFICATION: question spécifique] -4. Remplir la section Scénarios Utilisateur & Tests - → Si pas de cas d'usage clair : ERROR "Impossible de déterminer les scénarios utilisateur" -5. Générer les Exigences Fonctionnelles - → Chaque exigence doit être testable et mesurable - → Marquer les exigences ambiguës -6. Identifier les Composants Matériels (si produit physique impliqué) -7. Définir les Exigences Environnementales & Réglementaires -8. Exécuter la Liste de Contrôle d'Examen - → Si des [NEEDS CLARIFICATION] : WARN "Spec a des incertitudes" - → Si détails d'implémentation trouvés : ERROR "Supprimer détails techniques" -9. Retourner : SUCCESS (spec prête pour planification matérielle) -``` - ---- - -## ⚡ Directives Rapides -- ✅ Se concentrer sur CE QUE les utilisateurs ont besoin et POURQUOI, et CE QUE le matériel doit faire -- ❌ Éviter COMMENT implémenter (pas de modèles MCU/SBC spécifiques, outils CAO, layouts PCB) -- 🔧 Écrit pour chefs de produit et ingénieurs systèmes, pas concepteurs matériels -- 🌍 Considérer les contraintes du monde réel (alimentation, taille, environnement, réglementations) - -### Exigences de Section -- **Sections obligatoires** : Doivent être complétées pour chaque fonctionnalité -- **Sections optionnelles** : Inclure seulement quand pertinent pour la fonctionnalité -- Quand une section ne s'applique pas, la supprimer entièrement (ne pas laisser comme "N/A") - -### Pour la Génération IA -Lors de la création de cette spec à partir d'un prompt utilisateur : -1. **Marquer toutes les ambiguïtés** : Utiliser [NEEDS CLARIFICATION: question spécifique] pour toute supposition que vous devriez faire -2. **Ne pas deviner** : Si le prompt ne spécifie pas quelque chose (ex., "capteur sans fil" sans protocole), le marquer -3. **Penser comme un ingénieur de test** : Chaque exigence vague devrait échouer l'élément de liste de contrôle "testable et mesurable" -4. **Zones communes sous-spécifiées pour le matériel** : - - Environnement d'opération (température, humidité, vibration, classification IP) - - Exigences d'alimentation et attentes de durée de vie batterie - - Taille physique, poids, et contraintes de montage - - Protocoles de communication et exigences de portée - - Exigences d'interface utilisateur (écrans, boutons, indicateurs) - - Besoins de conformité réglementaire et sécurité - - Volume de fabrication et objectifs de coût - - Exigences de maintenance et service - ---- - -## Scénarios Utilisateur & Tests *(obligatoire)* - -### Histoire Utilisateur Principale -[Décrire le parcours utilisateur principal et comment ils interagissent avec le produit matériel] - -### Scénarios d'Acceptation -1. **Étant donné** [conditions initiales], **Quand** [action utilisateur], **Alors** [comportement matériel attendu] -2. **Étant donné** [condition environnementale], **Quand** [opération système], **Alors** [performance attendue] -3. **Étant donné** [condition d'alimentation], **Quand** [opération prolongée], **Alors** [comportement batterie/alimentation attendu] - -### Cas Limites & Tests Environnementaux -- Que se passe-t-il quand [extrême environnemental - température, humidité, perte d'alimentation] ? -- Comment le système gère-t-il [stress physique - vibration, impact, humidité] ? -- Quels sont les modes de défaillance quand [défaillance de composant ou perte de communication] ? - -## Exigences *(obligatoire)* - -### Exigences Fonctionnelles -- **FR-001** : Le système DOIT [capacité physique spécifique, ex., "mesurer la température avec précision ±0.5°C"] -- **FR-002** : Le système DOIT [interaction spécifique, ex., "fournir indication visuelle du statut d'opération"] -- **FR-003** : Les utilisateurs DOIVENT pouvoir [interaction clé, ex., "configurer paramètres système via app mobile"] -- **FR-004** : Le système DOIT [exigence données/communication, ex., "transmettre données capteur toutes les 60 secondes"] -- **FR-005** : Le système DOIT [exigence sécurité/protection, ex., "s'arrêter automatiquement en cas de surchauffe"] - -*Exemple de marquage d'exigences peu claires :* -- **FR-006** : Le système DOIT communiquer sans fil via [NEEDS CLARIFICATION: protocole non spécifié - WiFi, LoRa, Bluetooth, Zigbee ?] -- **FR-007** : Le système DOIT fonctionner pendant [NEEDS CLARIFICATION: objectif durée de vie batterie non spécifié - heures, jours, mois ?] - -### Exigences Environnementales & d'Opération *(inclure pour produits physiques)* -- **Température d'Opération** : [NEEDS CLARIFICATION: plage non spécifiée, ex., -20°C à +60°C] -- **Plage d'Humidité** : [NEEDS CLARIFICATION: humidité d'opération non spécifiée] -- **Exigences d'Alimentation** : [NEEDS CLARIFICATION: tension, courant, type batterie non spécifiés] -- **Contraintes Physiques** : [NEEDS CLARIFICATION: taille, poids, exigences montage non spécifiés] -- **Protection d'Entrée** : [NEEDS CLARIFICATION: classification IP pour protection poussière/eau non spécifiée] - -### Composants Matériels *(inclure si fonctionnalité implique dispositifs physiques)* -- **[Type Composant 1]** : [Ce qu'il fait, spécifications clés sans numéros de pièce spécifiques] -- **[Type Composant 2]** : [Fonction, exigences d'interface, objectifs de performance] -- **[Module Communication]** : [Exigences protocole, portée, objectifs consommation énergie] - -### Exigences Réglementaires & Conformité *(inclure si applicable)* -- **Standards de Sécurité** : [Certifications sécurité applicables, ex., UL, IEC] -- **Compatibilité Électromagnétique** : [Exigences EMC, ex., FCC Part 15, CE] -- **Réglementations Sans Fil** : [Si applicable, ex., allocations fréquence, limites puissance] - ---- - -## Liste de Contrôle d'Examen & Acceptation -*PORTE : Vérifications automatisées exécutées pendant l'exécution main()* - -### Qualité de Contenu -- [ ] Aucun détail d'implémentation (modèles MCU/SBC spécifiques, outils CAO, layouts PCB) -- [ ] Concentré sur valeur utilisateur et exigences produit -- [ ] Écrit pour chefs de produit et ingénieurs systèmes -- [ ] Toutes les sections obligatoires complétées -- [ ] Exigences environnementales et réglementaires considérées - -### Complétude des Exigences -- [ ] Aucun marqueur [NEEDS CLARIFICATION] ne reste -- [ ] Les exigences sont testables et mesurables -- [ ] Les critères de succès incluent des objectifs quantitatifs -- [ ] Contraintes physiques et environnementales définies -- [ ] Exigences d'alimentation et communication spécifiées -- [ ] Considérations sécurité et réglementaires identifiées - ---- - -## Statut d'Exécution -*Mis à jour par main() pendant le traitement* - -- [ ] Description utilisateur analysée -- [ ] Concepts clés extraits -- [ ] Ambiguïtés marquées -- [ ] Scénarios utilisateur définis -- [ ] Exigences générées -- [ ] Composants matériels identifiés -- [ ] Exigences environnementales spécifiées -- [ ] Exigences réglementaires considérées -- [ ] Liste de contrôle d'examen passée - ---- \ No newline at end of file diff --git a/templates/tasks-template_fr.md b/templates/tasks-template_fr.md deleted file mode 100644 index a035c541b7..0000000000 --- a/templates/tasks-template_fr.md +++ /dev/null @@ -1,127 +0,0 @@ -# Tâches : [NOM FONCTIONNALITÉ] - -**Entrée** : Documents de conception de `/specs/[###-nom-fonctionnalité]/` -**Prérequis** : plan.md (requis), research.md, data-model.md, contracts/ - -## Flux d'Exécution (principal) -``` -1. Charger plan.md du répertoire de fonctionnalité - → Si pas trouvé : ERROR "Aucun plan d'implémentation trouvé" - → Extraire : pile technologique, bibliothèques, structure -2. Charger documents de conception optionnels : - → data-model.md : Extraire entités → tâches modèle - → contracts/ : Chaque fichier → tâche test contrat - → research.md : Extraire décisions → tâches configuration -3. Générer tâches par catégorie : - → Configuration : init projet, dépendances, linting - → Tests : tests contrat, tests intégration - → Principal : modèles, services, commandes CLI - → Intégration : DB, middleware, logging - → Finition : tests unitaires, performance, docs -4. Appliquer règles de tâches : - → Fichiers différents = marquer [P] pour parallèle - → Même fichier = séquentiel (pas de [P]) - → Tests avant implémentation (TDD) -5. Numéroter tâches séquentiellement (T001, T002...) -6. Générer graphe de dépendances -7. Créer exemples d'exécution parallèle -8. Valider complétude des tâches : - → Tous les contrats ont des tests ? - → Toutes les entités ont des modèles ? - → Tous les points de terminaison implémentés ? -9. Retourner : SUCCESS (tâches prêtes pour exécution) -``` - -## Format : `[ID] [P?] Description` -- **[P]** : Peut fonctionner en parallèle (fichiers différents, pas de dépendances) -- Inclure chemins de fichiers exacts dans descriptions - -## Conventions de Chemin -- **Projet unique** : `src/`, `tests/` à la racine du dépôt -- **App web** : `backend/src/`, `frontend/src/` -- **Mobile** : `api/src/`, `ios/src/` ou `android/src/` -- Chemins montrés ci-dessous supposent projet unique - ajuster basé sur structure plan.md - -## Phase 3.1 : Configuration -- [ ] T001 Créer structure de projet selon plan d'implémentation -- [ ] T002 Initialiser projet [langage] avec dépendances [framework] -- [ ] T003 [P] Configurer outils de linting et formatage - -## Phase 3.2 : Tests d'Abord (TDD) ⚠️ DOIT ÊTRE COMPLÉTÉ AVANT 3.3 -**CRITIQUE : Ces tests DOIVENT être écrits et DOIVENT échouer avant TOUTE implémentation** -- [ ] T004 [P] Test contrat POST /api/users dans tests/contract/test_users_post.py -- [ ] T005 [P] Test contrat GET /api/users/{id} dans tests/contract/test_users_get.py -- [ ] T006 [P] Test intégration inscription utilisateur dans tests/integration/test_registration.py -- [ ] T007 [P] Test intégration flux auth dans tests/integration/test_auth.py - -## Phase 3.3 : Implémentation Principale (SEULEMENT après que les tests échouent) -- [ ] T008 [P] Modèle utilisateur dans src/models/user.py -- [ ] T009 [P] UserService CRUD dans src/services/user_service.py -- [ ] T010 [P] CLI --create-user dans src/cli/user_commands.py -- [ ] T011 Point de terminaison POST /api/users -- [ ] T012 Point de terminaison GET /api/users/{id} -- [ ] T013 Validation d'entrée -- [ ] T014 Gestion d'erreur et logging - -## Phase 3.4 : Intégration -- [ ] T015 Connecter UserService à DB -- [ ] T016 Middleware auth -- [ ] T017 Logging requête/réponse -- [ ] T018 CORS et headers de sécurité - -## Phase 3.5 : Finition -- [ ] T019 [P] Tests unitaires pour validation dans tests/unit/test_validation.py -- [ ] T020 Tests de performance (<200ms) -- [ ] T021 [P] Mettre à jour docs/api.md -- [ ] T022 Supprimer duplication -- [ ] T023 Exécuter manual-testing.md - -## Dépendances -- Tests (T004-T007) avant implémentation (T008-T014) -- T008 bloque T009, T015 -- T016 bloque T018 -- Implémentation avant finition (T019-T023) - -## Exemple Parallèle -``` -# Lancer T004-T007 ensemble : -Task: "Test contrat POST /api/users dans tests/contract/test_users_post.py" -Task: "Test contrat GET /api/users/{id} dans tests/contract/test_users_get.py" -Task: "Test intégration inscription dans tests/integration/test_registration.py" -Task: "Test intégration auth dans tests/integration/test_auth.py" -``` - -## Notes -- Tâches [P] = fichiers différents, pas de dépendances -- Vérifier que les tests échouent avant implémentation -- Commiter après chaque tâche -- Éviter : tâches vagues, conflits de même fichier - -## Règles de Génération de Tâches -*Appliquées pendant l'exécution main()* - -1. **À partir des Contrats** : - - Chaque fichier contrat → tâche test contrat [P] - - Chaque point de terminaison → tâche implémentation - -2. **À partir du Modèle de Données** : - - Chaque entité → tâche création modèle [P] - - Relations → tâches couche service - -3. **À partir des Histoires Utilisateur** : - - Chaque histoire → test intégration [P] - - Scénarios quickstart → tâches validation - -4. **Ordonnancement** : - - Configuration → Tests → Modèles → Services → Points de terminaison → Finition - - Dépendances bloquent exécution parallèle - -## Liste de Contrôle de Validation -*PORTE : Vérifiée par main() avant retour* - -- [ ] Tous les contrats ont des tests correspondants -- [ ] Toutes les entités ont des tâches modèle -- [ ] Tous les tests viennent avant implémentation -- [ ] Tâches parallèles vraiment indépendantes -- [ ] Chaque tâche spécifie chemin de fichier exact -- [ ] Aucune tâche ne modifie le même fichier qu'une autre tâche [P] \ No newline at end of file