docs: nettoyer AGENTS.md des règles redondantes
Retrait des sections de règles de développement de AGENTS.md, désormais centralisées dans orchestrator.md. Co-Authored-By: Warp <agent@warp.dev>
This commit is contained in:
152
AGENTS.md
152
AGENTS.md
@@ -243,155 +243,3 @@ Le projet suit un plan séquentiel en **15 jalons** (M1-M15) décrits dans [`TOD
|
||||
|----------|------|
|
||||
| [`GUIDE_DEV_PYTHON.md`](./GUIDE_DEV_PYTHON.md) | Spécification complète (architecture, modèles, parsing, déploiement) |
|
||||
| [`TODO.md`](./TODO.md) | Plan de développement détaillé (15 jalons) |
|
||||
|
||||
---
|
||||
|
||||
## 9. Agents OpenCode
|
||||
|
||||
Cette section s'applique uniquement lorsque le travail est exécuté avec le système d'agents d'OpenCode.
|
||||
|
||||
Les rôles d'agents disponibles pour ce projet sont les suivants :
|
||||
|
||||
- `@architect` : Arbitrages d'architecture et choix techniques structurants. **Ne produit pas de code.**
|
||||
- `@coder` : Écrit et modifie du code, de la configuration et des scripts. **Ne valide pas** (ruff, mypy, pytest) — c'est le rôle de `@verifier`. **Ne diagnostique pas** — c'est le rôle de `@debugger`.
|
||||
- `@debugger` : Reproduit un symptôme et établit sa cause profonde. **Ne modifie pas le code.**
|
||||
- `@explorer` : Explore le dépôt en lecture seule. **Ne modifie rien, n'exécute pas de commandes.**
|
||||
- `@orchestrator` : Compréhension globale, définition des jalons, coordination et garantie du résultat. **N'écrit pas de code.**
|
||||
- `@planner` : Transforme une demande complexe en unités exécutables. **Ne dirige aucun technicien.**
|
||||
- `@reviewer` : Revues indépendantes de correction, régression, contrats et maintenabilité. **Ne modifie pas le code.**
|
||||
- `@security-auditor` : Audit indépendant d'une surface de sécurité. **Ne modifie pas le code.**
|
||||
- `@tech-writer` : Rédige et maintient la documentation. **N'écrit pas de code applicatif.**
|
||||
- `@test-engineer` : Conçoit, écrit et exécute des tests ciblés. **N'écrit pas de code de production.**
|
||||
- `@ui-designer` : Conçoit et implémente les interfaces Web et terminal.
|
||||
- `@verifier` : Vérifie indépendamment le comportement livré, les régressions et le respect des conventions (ruff, mypy, pytest, bandit, idempotence, mode dégradé). **Ne modifie pas le code.**
|
||||
- `@web-explorer` : Recherche et extrait des sources Web vérifiables. **Ne modifie pas le dépôt.**
|
||||
|
||||
> **Note** : Ne pas utiliser `@coder` pour les tâches de documentation (`@tech-writer`) ni pour les tests (`@test-engineer`).
|
||||
|
||||
### Séparation des rôles
|
||||
|
||||
| Type de tâche | Agent responsable | Ne pas confier à |
|
||||
|---|---|---|
|
||||
| Écrire/modifier du code | `@coder` | `@verifier`, `@explorer` |
|
||||
| Valider (ruff, mypy, pytest, bandit) | `@verifier` | `@coder` |
|
||||
| Diagnostiquer un bug | `@debugger` | `@coder` |
|
||||
| Écrire un test | `@test-engineer` | `@coder` |
|
||||
| Rédiger de la documentation | `@tech-writer` | `@coder` |
|
||||
| Explorer le dépôt (lecture) | `@explorer` | `@coder`, `@verifier` |
|
||||
| Arbitrage technique structurant | `@architect` | `@coder`, `@planner` |
|
||||
| Revue de code | `@reviewer` | `@coder`, `@verifier` |
|
||||
| Audit de sécurité | `@security-auditor` | `@coder`, `@verifier` |
|
||||
| Recherche web | `@web-explorer` | `@explorer` |
|
||||
| Découpage de travail complexe | `@planner` | `@coder` |
|
||||
|
||||
---
|
||||
|
||||
## 10. Workflow de modification
|
||||
|
||||
1. Lire la demande, [`TODO.md`](./TODO.md), les sections pertinentes de
|
||||
[`GUIDE_DEV_PYTHON.md`](./GUIDE_DEV_PYTHON.md), `git status` et les fichiers concernés.
|
||||
2. Préserver les changements existants de l'utilisateur.
|
||||
3. Pour une correction, reproduire d'abord le défaut avec un test automatisé lorsque c'est raisonnable.
|
||||
4. Faire une modification étroite et cohérente, en respectant les conventions du projet
|
||||
(idempotence, modes explicites stricts et repli iCal → `pronotepy` uniquement en mode `auto`).
|
||||
5. Faire vérifier le comportement par `@verifier` (ruff, mypy, pytest, bandit) et les cas d'erreur, notamment :
|
||||
- Succès de la synchronisation Pronote → CalDAV/XMPP.
|
||||
- Repli d'iCal vers `pronotepy` en mode `auto`, sans repli dans les modes explicites.
|
||||
- Distinction entre résultat vide et échec des sources.
|
||||
- Gestion des erreurs explicites sans fuite dans les causes ou tracebacks.
|
||||
6. Mettre à jour la documentation et les exemples dans le même changement si leur comportement public évolue.
|
||||
7. Cocher dans [`TODO.md`](./TODO.md) uniquement les éléments entièrement réalisés et validés.
|
||||
8. Terminer avec un *handoff* concis : fichiers modifiés, validations exécutées, limites et prochaine étape.
|
||||
|
||||
> **Pour les changements larges ou risqués** : Produire d'abord un audit ou un aperçu.
|
||||
> **Règle de commit** : Ne pas committer sans autorisation explicite. Une autorisation de commit ne vaut pas autorisation de push.
|
||||
|
||||
---
|
||||
|
||||
## 11. Branches et commits
|
||||
|
||||
- Une évolution cohérente se fait sur une **branche dédiée**.
|
||||
- Nommer les branches selon le format `<type>/<sujet-en-kebab-case>`, où `<type>` est l'un des suivants :
|
||||
`feature`, `fix`, `docs`, `chore` ou `refactor`.
|
||||
- Partir de l'état validé de la branche principale (`main` ou `dev`), sauf demande explicite.
|
||||
- Garder **un commit atomique par objectif vérifiable**. Utiliser les préfixes conventionnels pour les messages de commit :
|
||||
- `feat:` pour une nouvelle fonctionnalité.
|
||||
- `fix:` pour une correction de bug.
|
||||
- `docs:` pour une mise à jour de documentation.
|
||||
- `chore:` pour une tâche de maintenance.
|
||||
- `refactor:` pour une refactorisation de code.
|
||||
- Quand un agent a contribué au changement, ajouter un *trailer* Git standard au commit :
|
||||
```
|
||||
Co-authored-by: <harness>/<modèle> <adresse@agents.invalid>
|
||||
```
|
||||
- Avant un commit autorisé, vérifier :
|
||||
- `git status` (fichiers modifiés attendus).
|
||||
- Le diff complet (`git diff`).
|
||||
- L'absence de secret ou de configuration locale dans le diff.
|
||||
- Les validations pertinentes (`ruff`, `mypy`, `pytest`, `bandit`).
|
||||
- `git diff --check` (pas de problèmes d'espaces blancs).
|
||||
- Après le commit, rapporter :
|
||||
- Le hash du commit.
|
||||
- Le contenu du commit.
|
||||
- Les validations exécutées.
|
||||
|
||||
> **Règle absolue** : Ne jamais pousser (`git push`) sans demande distincte et explicite.
|
||||
|
||||
---
|
||||
|
||||
## 12. Définition de terminé
|
||||
|
||||
Un changement est considéré comme **terminé** lorsque :
|
||||
|
||||
- Le cas nominal et les échecs pertinents sont testés (ex. : synchronisation réussie, repli
|
||||
iCal → `pronotepy` en mode `auto`, modes explicites stricts, erreurs explicites).
|
||||
- Les outils de validation (`ruff`, `mypy`, `pytest`, `bandit`) passent sans erreur.
|
||||
- Aucun secret ni configuration locale n'apparaît dans le diff ou les fichiers suivis.
|
||||
- La documentation reste cohérente avec le code (ex. : mise à jour des exemples, des contrats ou des décisions d'architecture).
|
||||
- Le *handoff* distingue clairement :
|
||||
- Ce qui a été vérifié localement (ex. : tests unitaires, linter).
|
||||
- Ce qui nécessite encore une vérification manuelle (ex. : tests d'intégration avec un serveur CalDAV réel).
|
||||
|
||||
---
|
||||
|
||||
## 13. Versionnage et releases
|
||||
|
||||
### Politique de versionnage
|
||||
|
||||
Le projet suit **Semantic Versioning** (semver.org v2.0.0). Phase actuelle : `0.x` (pré-`1.0.0`).
|
||||
|
||||
| Changement | Incrément |
|
||||
|------------|----------|
|
||||
| Défaut constaté au déploiement | Patch (`0.1.Z`) — correction rétrocompatible |
|
||||
| Ajout ou cassure en phase `0.x` | Minor (`0.Y.0`) |
|
||||
| Déploiement réel validé | `1.0.0` |
|
||||
|
||||
### Règle absolue de validation
|
||||
|
||||
**Aucune montée de version (tag + release) ne peut être effectuée
|
||||
sans validation préalable en environnement réel.** Les tests automatisés et la revue de code
|
||||
ne suffisent pas ; le correctif ou la fonctionnalité doit avoir été testé avec succès
|
||||
sur le serveur de production (ou un environnement équivalent) avant de tagger.
|
||||
|
||||
### Procédure de release
|
||||
|
||||
1. **Valider en environnement réel** : le correctif ou la fonctionnalité est testé
|
||||
sur le serveur de production.
|
||||
2. **Mettre à jour `pyproject.toml`** : incrémenter le champ `version` à la nouvelle version.
|
||||
3. **Mettre à jour `CHANGELOG.md`** : ajouter une entrée sous le format
|
||||
[Keep a Changelog](https://keepachangelog.com/en/1.1.0/) avec la nouvelle version et la date.
|
||||
4. **Committer** : un commit `chore: monter en version x.y.z` regroupe
|
||||
les mises à jour de `pyproject.toml` et `CHANGELOG.md`.
|
||||
5. **Tagger** : créer un tag annoté `vx.y.z` sur le commit de version.
|
||||
6. **Pousser le tag** : `git push origin vx.y.z`.
|
||||
7. **Créer la release** sur Gitea avec le changelog correspondant.
|
||||
|
||||
### Cohérence des versions
|
||||
|
||||
Les trois sources de version doivent toujours être synchronisées au moment d'un tag :
|
||||
- Le tag Git (`vx.y.z`)
|
||||
- `pyproject.toml` (`version = "x.y.z"`)
|
||||
- `CHANGELOG.md` (`## [x.y.z] - YYYY-MM-DD`)
|
||||
|
||||
> **Rappel** : Ne jamais créer un tag sans avoir d'abord mis à jour
|
||||
> `pyproject.toml` et `CHANGELOG.md`.
|
||||
|
||||
Reference in New Issue
Block a user