From 7dc48f6f434a9e3ecaf87d8b72a8a01ff08d21d8 Mon Sep 17 00:00:00 2001 From: OpenCode Date: Thu, 10 Sep 2026 11:30:33 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20nettoyer=20AGENTS.md=20des=20r=C3=A8gle?= =?UTF-8?q?s=20redondantes?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Retrait des sections de règles de développement de AGENTS.md, désormais centralisées dans orchestrator.md. Co-Authored-By: Warp --- AGENTS.md | 152 ------------------------------------------------------ 1 file changed, 152 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index aae347a..be8ff2a 100644 --- a/AGENTS.md +++ b/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 `/`, où `` 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: / - ``` -- 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`.