thibaud-lclr
9ac814fda4
All checks were successful
CI / test (push) Successful in 12s
Ajoute CLAUDE.md comme symlink vers AGENTS.md. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
70 lines
2.5 KiB
Markdown
70 lines
2.5 KiB
Markdown
# AGENTS.md
|
|
|
|
Ces instructions s'appliquent à tout le dépôt `mcp-framework`.
|
|
|
|
## Forge
|
|
|
|
Le dépôt est hébergé sur Gitea.
|
|
|
|
Pour les actions distantes liées au dépôt, utiliser `tea` plutôt qu'un autre CLI.
|
|
Exemples : lire une issue, s'assigner une issue, créer une branche de travail, ouvrir une PR, commenter une PR.
|
|
|
|
## Issues
|
|
|
|
Quand on commence à travailler sur une issue, il faut se l'assigner immédiatement.
|
|
|
|
Si le travail correspond directement à une issue existante :
|
|
|
|
1. lire l'issue
|
|
2. se l'assigner
|
|
3. créer une branche dédiée
|
|
4. implémenter et valider localement
|
|
5. pousser la branche
|
|
6. ouvrir une PR liée à l'issue
|
|
|
|
## Branches
|
|
|
|
Préférer une branche de travail dédiée par issue ou sujet.
|
|
|
|
Nommer la branche de manière explicite, par exemple :
|
|
|
|
- `issue-4-structured-secrets`
|
|
- `issue-8-update-drivers`
|
|
- `docs-readme-installation`
|
|
|
|
Quand une branche est créée pour répondre à une issue et que cette issue porte le label `enhancement`, nommer la branche au format `feat/<issue_short_name>`.
|
|
|
|
Éviter de développer directement sur `main` quand le changement mérite une PR ou une validation fonctionnelle.
|
|
|
|
## Pull Requests
|
|
|
|
Par défaut, quand un changement doit être validé via un vrai use case, une intégration avec un autre dépôt, ou une revue fonctionnelle, ouvrir une PR plutôt que pousser directement sur `main`.
|
|
|
|
Le corps de PR doit en général contenir :
|
|
|
|
- un résumé clair de ce qui a été implémenté
|
|
- la validation locale déjà effectuée
|
|
- une proposition de test manuel ou d'intégration si pertinente
|
|
- le lien explicite avec l'issue, idéalement via `Closes #<numéro>`
|
|
|
|
Si le changement a un impact possible sur un dépôt consommateur comme `graylog-mcp` ou `email-mcp`, ajouter dans la PR ou dans un commentaire de PR un plan de validation ou d'adaptation pour ce dépôt.
|
|
|
|
## Validation
|
|
|
|
Avant d'ouvrir ou de mettre à jour une PR :
|
|
|
|
- exécuter les tests locaux pertinents
|
|
- signaler clairement ce qui a été validé
|
|
- signaler explicitement ce qui n'a pas pu être testé
|
|
|
|
## Commits
|
|
|
|
Conserver des messages de commit au format conventional commits, conformément aux règles globales.
|
|
|
|
## Changelog
|
|
|
|
Après chaque développement fonctionnel, mettre à jour la section `## [Unreleased]` du `CHANGELOG.md` avec une description claire des changements apportés.
|
|
|
|
Ne pas logger les changements purement liés à la CI ou au changelog lui-même.
|
|
|
|
La CI se charge de versioner automatiquement la section `[Unreleased]` lors du push d'un tag stable.
|