Mise à jour de la spécification

Votre objectif est de mettre à jour le fichier de spécification existant ${file} en fonction de nouvelles exigences ou de mises à jour du code existant.

Le fichier de spécification doit définir les exigences, contraintes et interfaces des composants de la solution de manière claire, sans ambiguïté 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 adaptées à l'IA

• Utilisez un langage précis, explicite et sans ambiguïté.
• Distinguez clairement les exigences, contraintes et recommandations.
• Utilisez un formatage structuré (titres, listes, tableaux) pour faciliter l'analyse.
• Évitez les idiomes, métaphores ou références contextuelles.
• 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 : [a-z0-9-]+.md, où le nom doit être descriptif du contenu de la spécification et commencer par le but de 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 veillant à ce que toutes les sections soient remplies de manière appropriée. Le frontmatter du markdown doit être structuré correctement comme dans l'exemple suivant :

---
title: [Titre concis décrivant le focus de la spécification]
version: [Optionnel : p. 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 de tags ou catégories pertinents, p. ex., `infrastructure`, `process`, `design`, `app` etc]
---

# Introduction

[Une introduction courte et concise de la spécification et de l'objectif qu'elle vise à atteindre.]

## 1. Purpose & Scope

[Fournissez une description claire et concise du but de la spécification et de la portée de son application. Énoncez le public visé et toute hypothèse.]

## 2. Definitions

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

## 3. Requirements, Constraints & Guidelines

[Énumérez 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**: Motif à suivre 1

## 4. Interfaces & Data Contracts

[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. Acceptance Criteria

[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**: Given [contexte], When [action], Then [résultat attendu]
- **AC-002**: Le système shall [comportement spécifique] when [condition]
- **AC-003**: [Critères d'acceptation supplémentaires selon les besoins]

## 6. Test Automation Strategy

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

- **Test Levels**: Unit, Integration, End-to-End
- **Frameworks**: MSTest, FluentAssertions, Moq (pour les applications .NET)
- **Test Data Management**: [approche pour la création et le nettoyage des données de test]
- **CI/CD Integration**: [test automatisé dans les pipelines GitHub Actions]
- **Coverage Requirements**: [seuils minimums de couverture de code]
- **Performance Testing**: [approche pour les tests de charge et de performance]

## 7. Rationale & Context

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

## 8. Dependencies & External Integrations

[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 de bibliothèques sauf si elles représentent des contraintes architecturales.]

### External Systems
- **EXT-001**: [Nom du système externe] - [But et type d'intégration]

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

### Infrastructure Dependencies
- **INF-001**: [Composant d'infrastructure] - [Exigences et contraintes]

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

### Technology Platform Dependencies
- **PLT-001**: [Exigence de plateforme/runtime] - [Contraintes de version et rationnelle]

### Compliance Dependencies
- **COM-001**: [Exigence réglementaire ou de conformité] - [Impact sur l'implémentation]

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

## 9. Examples & Edge Cases

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

10. Validation Criteria

[Énumérez les critères ou tests qui doivent être satisfaits pour la conformité à cette spécification.]

11. Related Specifications / Further Reading

[Lien vers la spec associée 1] [Lien vers la documentation externe pertinente]