# Task brief Codex

Utiliser ce template pour transformer une intention, un ticket ou une demande produit en tâche exploitable par Codex.

## Objectif

Décrire le comportement concret ou le changement attendu.

- Objectif :

## Contexte

Expliquer pourquoi ce changement est nécessaire, qui est concerné, et où il s'inscrit dans le projet.

- Pourquoi maintenant :
- Contexte produit ou technique :
- Information métier utile :

## Scope

Fichiers, dossiers ou modules que Codex peut inspecter ou modifier.

- Codex peut inspecter :
- Codex peut modifier :
- Codex peut ajouter :
- Codex ne doit pas modifier :

## Non-goals

Ce qui ne doit pas être changé dans cette tâche.

- 

## Contraintes

Règles d'architecture, limites de dépendances, contrats API, sécurité, performance ou compatibilité.

- Pas de nouvelle dépendance sans approbation explicite :
- Contrats API à préserver :
- Contraintes de sécurité :
- Contraintes de compatibilité :

## Comportement attendu

Décrire ce qui doit être observable après le changement.

- Cas nominal :
- Cas d'erreur :
- Comportement qui doit rester inchangé :

## Critères de done

Définir ce qui permet de considérer la tâche terminée.

- [ ] Le comportement demandé est implémenté.
- [ ] Le scope annoncé est respecté.
- [ ] Les non-goals sont respectés.
- [ ] Les tests pertinents passent ou l'écart est expliqué.
- [ ] Les validations non exécutées sont justifiées.
- [ ] Les risques ou limites connus sont signalés.

## Commandes de validation

Commandes que Codex doit exécuter avant d'annoncer que la tâche est terminée.

- ``

Si une commande échoue, Codex doit indiquer si l'échec semble lié au changement ou préexistant.
Si une commande ne peut pas être exécutée, Codex doit expliquer pourquoi et proposer une vérification alternative.

## Focus de review

Ce que la personne qui relit doit regarder en priorité.

- 

## Evidence attendue

Éléments à fournir en fin de tâche.

- Commandes exécutées :
- Résultats :
- Fichiers modifiés :
- Limites connues :
- Validations non exécutées :

## Clarification préalable

Si la demande est ambiguë, Codex doit commencer par reformuler la demande, puis poser jusqu'à cinq questions ciblées.

Questions utiles :

- Quel comportement observable doit changer ?
- Quels fichiers ou modules sont dans le scope ?
- Quels comportements ne doivent pas changer ?
- Quelle validation prouvera que la tâche est terminée ?
- Quel risque doit être regardé en priorité pendant la review ?