Créer une Spécification

Votre objectif est de créer un nouveau fichier de spécification pour ${input:SpecPurpose}.

Le fichier de spécification doit définir les exigences, contraintes et interfaces des composants de solution d'une manière qui soit claire, non ambiguë et structurée pour une utilisation efficace par les IA génératives. Respectez les normes de documentation établies et assurez-vous que le contenu est lisible par machine et autonome.

Bonnes pratiques pour les spécifications prêtes pour l'IA

• Utilisez un langage précis, explicite et non ambigu.
• Distinguez clairement entre exigences, contraintes et recommandations.
• Utilisez une mise en forme structurée (en-têtes, listes, tableaux) pour faciliter l'analyse.
• Évitez les idiomes, métaphores ou références dépendantes du contexte.
• Définissez tous les acronymes et termes spécifiques au domaine.
• Incluez des exemples et cas limites le cas échéant.
• Assurez-vous que le document est autonome et ne dépend pas d'un contexte externe.

La spécification doit être enregistrée dans le répertoire /spec/ et nommée selon la convention suivante : spec-[a-z0-9-]+.md, où le nom doit être descriptif du contenu de la spécification et commencer par l'objectif haut niveau, qui est l'un de [schema, tool, data, infrastructure, process, architecture, ou design].

Le fichier de spécification doit être formaté en Markdown bien formé.

Les fichiers de spécification doivent suivre le modèle ci-dessous, en s'assurant que toutes les sections sont remplies de manière appropriée. Le frontmatter du markdown doit être structuré correctement selon l'exemple qui suit :

---
title: [Titre concis décrivant l'objectif de la spécification]
version: [Optionnel : par ex., 1.0, Date]
date_created: [YYYY-MM-DD]
last_updated: [Optionnel : YYYY-MM-DD]
owner: [Optionnel : Équipe/Personne responsable de cette spécification]
tags: [Optionnel : Liste des balises ou catégories pertinentes, par ex., `infrastructure`, `process`, `design`, `app` etc]
---

# Introduction

[Une introduction courte et concise à la spécification et à l'objectif qu'elle est destinée à atteindre.]

## 1. Objectif et étendue

[Fournissez une description claire et concise de l'objectif de la spécification et de l'étendue de son application. Précisez l'audience cible et les hypothèses.]

## 2. Définitions

[Listez et définissez tous les acronymes, abréviations et termes spécifiques au domaine utilisés dans cette spécification.]

## 3. Exigences, contraintes et directives

[Listez explicitement toutes les exigences, contraintes, règles et directives. Utilisez des listes à puces ou des tableaux pour plus de clarté.]

- **REQ-001** : Exigence 1
- **SEC-001** : Exigence de sécurité 1
- **[3 LETTRES]-001** : Autre exigence 1
- **CON-001** : Contrainte 1
- **GUD-001** : Directive 1
- **PAT-001** : Modèle à suivre 1

## 4. Interfaces et contrats de données

[Décrivez les interfaces, APIs, contrats de données ou points d'intégration. Utilisez des tableaux ou blocs de code pour les schémas et exemples.]

## 5. Critères d'acceptation

[Définissez des critères d'acceptation clairs et testables pour chaque exigence en utilisant le format Given-When-Then le cas échéant.]

- **AC-001** : Étant donné [contexte], Quand [action], Alors [résultat attendu]
- **AC-002** : Le système doit [comportement spécifique] quand [condition]
- **AC-003** : [Critères d'acceptation supplémentaires selon les besoins]

## 6. Stratégie d'automatisation des tests

[Définissez l'approche de test, les frameworks et les exigences d'automatisation.]

- **Niveaux de test** : Unitaire, Intégration, Bout en bout
- **Frameworks** : MSTest, FluentAssertions, Moq (pour les applications .NET)
- **Gestion des données de test** : [approche pour la création et le nettoyage des données de test]
- **Intégration CI/CD** : [tests automatisés dans les pipelines GitHub Actions]
- **Exigences de couverture** : [seuils minimums de couverture de code]
- **Tests de performance** : [approche pour les tests de charge et de performance]

## 7. Justification et contexte

[Expliquez le raisonnement derrière les exigences, contraintes et directives. Fournissez du contexte pour les décisions de conception.]

## 8. Dépendances et intégrations externes

[Définissez les systèmes externes, services et dépendances architecturales requis pour cette spécification. Concentrez-vous sur **ce qui** est nécessaire plutôt que sur **comment** c'est implémenté. Évitez les versions spécifiques de paquets ou bibliothèques sauf si elles représentent des contraintes architecturales.]

### Systèmes externes
- **EXT-001** : [Nom du système externe] - [Objectif et type d'intégration]

### Services tiers
- **SVC-001** : [Nom du service] - [Capacités requises et exigences SLA]

### Dépendances d'infrastructure
- **INF-001** : [Composant d'infrastructure] - [Exigences et contraintes]

### Dépendances de données
- **DAT-001** : [Source de données externe] - [Format, fréquence et exigences d'accès]

### Dépendances de plateforme technologique
- **PLT-001** : [Exigence de plateforme/runtime] - [Contraintes de version et justification]

### Dépendances de conformité
- **COM-001** : [Exigence réglementaire ou de conformité] - [Impact sur la mise en œuvre]

**Remarque** : Cette section doit se concentrer sur les dépendances architecturales et métier, non sur les implémentations de paquets spécifiques. Par exemple, précisez « bibliothèque d'authentification OAuth 2.0 » plutôt que « Microsoft.AspNetCore.Authentication.JwtBearer v6.0.1 ».

## 9. Exemples et cas limites

    ```code
    // Extrait de code ou exemple de données démontrant l'application correcte des directives, incluant les cas limites

10. Critères de validation

[Listez les critères ou tests qui doivent être satisfaits pour la conformité avec cette spécification.]

11. Spécifications connexes / Lectures complémentaires

[Lien vers la spécification connexe 1] [Lien vers la documentation externe pertinente]