Créer un enregistrement de décision architecturale

Créez un document ADR pour ${input:DecisionTitle} en utilisant un formatage structuré optimisé pour la consommation par IA et la lisibilité humaine.

Entrées

• Contexte : ${input:Context}
• Décision : ${input:Decision}
• Alternatives : ${input:Alternatives}
• Parties prenantes : ${input:Stakeholders}

Validation des entrées

Si l'une des entrées requises n'est pas fournie ou ne peut pas être déterminée à partir de l'historique de conversation, demandez à l'utilisateur de fournir les informations manquantes avant de procéder à la génération de l'ADR.

Exigences

• Utiliser un langage précis et sans ambiguïté
• Suivre le format ADR standardisé avec frontmatter
• Inclure les conséquences positives et négatives
• Documenter les alternatives avec justification du rejet
• Structurer pour l'analyse machine et la référence humaine
• Utiliser des codes de puces (codes de 3-4 lettres + numéros de 3 chiffres) pour les sections multi-éléments

L'ADR doit être enregistré dans le répertoire /docs/adr/ en utilisant la convention de nommage : adr-NNNN-[title-slug].md, où NNNN est le prochain numéro séquentiel à 4 chiffres (par exemple, adr-0001-database-selection.md).

Structure de documentation requise

Le fichier de documentation doit suivre le modèle ci-dessous, en veillant à ce que toutes les sections soient remplies correctement. Le frontmatter du markdown doit être structuré correctement comme dans l'exemple suivant :

---
title: "ADR-NNNN: [Decision Title]"
status: "Proposed"
date: "YYYY-MM-DD"
authors: "[Stakeholder Names/Roles]"
tags: ["architecture", "decision"]
supersedes: ""
superseded_by: ""
---

# ADR-NNNN: [Decision Title]

## Status

**Proposed** | Accepted | Rejected | Superseded | Deprecated

## Context

[Problem statement, technical constraints, business requirements, and environmental factors requiring this decision.]

## Decision

[Chosen solution with clear rationale for selection.]

## Consequences

### Positive

- **POS-001**: [Beneficial outcomes and advantages]
- **POS-002**: [Performance, maintainability, scalability improvements]
- **POS-003**: [Alignment with architectural principles]

### Negative

- **NEG-001**: [Trade-offs, limitations, drawbacks]
- **NEG-002**: [Technical debt or complexity introduced]
- **NEG-003**: [Risks and future challenges]

## Alternatives Considered

### [Alternative 1 Name]

- **ALT-001**: **Description**: [Brief technical description]
- **ALT-002**: **Rejection Reason**: [Why this option was not selected]

### [Alternative 2 Name]

- **ALT-003**: **Description**: [Brief technical description]
- **ALT-004**: **Rejection Reason**: [Why this option was not selected]

## Implementation Notes

- **IMP-001**: [Key implementation considerations]
- **IMP-002**: [Migration or rollout strategy if applicable]
- **IMP-003**: [Monitoring and success criteria]

## References

- **REF-001**: [Related ADRs]
- **REF-002**: [External documentation]
- **REF-003**: [Standards or frameworks referenced]