# AGENTS.md - modèle de harness de projet

Ce fichier sert de point de départ pour un dépôt utilisé avec Codex.
Gardez uniquement les règles qui aident vraiment l'agent à travailler sans deviner.

## Vue d'ensemble du dépôt

Décrire en quelques lignes le rôle du dépôt, ses grands modules et les contraintes qui changent la façon de travailler.

Exemple :

Ce dépôt contient l'API backend, l'application frontend et l'outillage partagé. Les changements doivent rester compatibles avec les contrats API publics et les scripts de validation documentés ci-dessous.

## Répertoires clés

- `backend/` : API et logique métier.
- `frontend/` : interface utilisateur.
- `docs/` : notes d'architecture et documentation opérationnelle.
- `scripts/` : utilitaires locaux pour les développeurs.
- `tests/` : tests automatisés.

## Commandes de validation

Indiquer les commandes fiables, pas une liste idéale jamais exécutée.

- Tests backend : `cd backend && pytest`
- Tests frontend : `cd frontend && npm test`
- Lint frontend : `cd frontend && npm run lint`
- Smoke check complet : `./scripts/smoke-check.sh`

Si une commande est trop lente ou instable, l'indiquer explicitement avec l'alternative attendue.

## Règles d’ingénierie

- Garder la logique métier hors des contrôleurs HTTP.
- Préférer les patterns existants de services, selectors et adapters.
- Ne pas introduire de nouvelles dépendances de production sans approbation explicite.
- Ne pas modifier les fichiers générés sauf si la tâche le demande explicitement.
- Ne pas mélanger refactoring opportuniste et changement fonctionnel sans accord.

## Zones sensibles

Lister les zones qui demandent une prudence particulière.

- Authentification et autorisations.
- Paiement, facturation ou données financières.
- Migrations de base de données.
- Jobs planifiés et traitements asynchrones.
- Contrats API consommés par des clients externes.

## Définition du done

Une tâche est done seulement lorsque :

- le comportement demandé est implémenté ;
- les tests pertinents passent ou l'écart est expliqué ;
- les commandes de validation demandées ont été exécutées ou justifiées ;
- les fichiers modifiés sont limités au scope annoncé ;
- les risques, limites et validations restantes sont signalés dans l'evidence note.

## Règles de collaboration avec Codex

- Commencer par lire les fichiers et conventions proches du changement.
- Préserver les modifications utilisateur non liées à la tâche.
- Ne pas ajouter de dépendance sans approbation explicite.
- Expliquer toute validation non exécutée.
- Pour les changements à risque, fournir une evidence note concise.