25.03.26

AGENTS.md

@@ -0,0 +1,98 @@
+# AGENTS.md
+
+Guide rapide pour les agents qui codent dans ce repository.
+
+## 1) Contexte du projet
+
+- Codebase Tryton monolithique (coeur + modules metier).
+- Noyau serveur a la racine: `application.py`, `wsgi.py`, `admin.py`, `worker.py`, `cron.py`.
+- Couches framework importantes:
+  - ORM: `model/`
+  - Meta/systeme (`ir`): `ir/`
+  - Protocoles RPC: `protocols/`
+  - Backend DB: `backend/`
+- Modules metier: `modules/<module_name>/` (~220 modules).
+
+## 2) Regles de travail pour agent
+
+- Ne jamais toucher des fichiers sans rapport avec la demande.
+- Limiter le scope de modif au minimum necessaire.
+- Respecter le style existant du module cible.
+- Ne pas supprimer du code legacy sans verifier les usages.
+- Si comportement incertain: preferer un patch conservateur + test.
+
+## 3) Zones de bruit a ignorer pendant l'exploration
+
+- `.venv/`
+- `__pycache__/`
+- `build/` (quand present dans des sous-modules)
+- Fichiers temporaires editeur (ex: `*.swp`)
+
+## 4) Comment choisir ou coder selon le besoin
+
+- Si bug ORM/champs:
+  - Lire `model/fields/*.py` et les tests `tests/test_field_*.py`.
+- Si bug transaction/DB:
+  - Lire `transaction.py`, `backend/*/database.py`, `tests/test_backend.py`.
+- Si bug API/RPC/HTTP:
+  - Lire `wsgi.py`, `rpc.py`, `protocols/*`, `tests/test_rpc.py`, `tests/test_wsgi.py`.
+- Si bug metier:
+  - Modifier uniquement `modules/<module>/` + ses tests.
+
+## 5) Workflow de modification (obligatoire)
+
+1. Identifier le module et le flux impacte.
+2. Localiser un test existant proche du comportement a changer.
+3. Implementer le plus petit patch possible.
+4. Ajouter/adapter les tests au plus pres du changement.
+5. Lancer la validation ciblee (pas toute la suite si inutile).
+6. Donner un resume du risque residuel.
+
+## 6) Checklist avant de rendre une modif
+
+- Le changement est-il limite au domaine demande ?
+- Le comportement existant non cible est-il preserve ?
+- Les droits/regles (`ir.rule`, acces) sont-ils impactes ?
+- Les vues XML et labels sont-ils coherents si un champ change ?
+- Les tests modifies couvrent-ils le bug/la feature ?
+- Le message de commit (si demande) explique clairement le pourquoi ?
+
+## 7) Tests: point de depart pratique
+
+- Suite coeur: `tests/test_tryton.py`
+- Tests coeur par domaine: `tests/test_*.py`
+- Tests module:
+  - `modules/<module>/tests/test_module.py`
+  - `modules/<module>/tests/test_scenario.py`
+  - `modules/<module>/tests/scenario_*.rst`
+
+Quand possible, lancer d'abord la cible minimale:
+
+- fichier de test touche
+- puis fichier voisin de regression
+- puis suite plus large uniquement si necessaire
+
+## 8) Contrat de sortie attendu de l'agent
+
+Toujours fournir:
+
+- Liste des fichiers modifies
+- Resume fonctionnel (ce qui change)
+- Resume technique (pourquoi ce design)
+- Tests executes + resultat
+- Risques residuels et impacts potentiels
+
+## 9) Cas sensibles (demander confirmation humaine)
+
+- Changement schema/structure de donnees
+- Changement de logique de securite/acces
+- Changement de comportement transverse (transaction, pool, RPC, worker)
+- Refactor multi-modules sans ticket explicite
+
+## 10) Raccourci de demarrage pour agent
+
+1. Lire ce fichier.
+2. Lire le(s) fichier(s) touche(s) et leurs tests.
+3. Proposer le patch minimal.
+4. Implementer + tester cible.
+5. Rendre avec le contrat de sortie (section 8).